Presentation on theme: "Chapter 05: Evolutionary Requirements. 5.1. Definition : Requirements “Requirements are capabilities and conditions to which the system, and more broadly."— Presentation transcript:
Chapter 05: Evolutionary Requirements
5.1. Definition : Requirements “Requirements are capabilities and conditions to which the system, and more broadly the project, must conform” The UP does not attempt to fully define the requirements before programming but instead, promotes a systematic approach to finding, documenting, organising and tracking the changing requirements of a system: This is about embracing change; Tackling software development as a problem solving activity; It also emphasises a disciplined way to handling change: iteratively and skilful yes but not in an haphazard or sloppy way. The UP-way entails continuous, multi-way, communication between the developers, the clients and all other stakeholders to discover and track requirements but also the documenting of requirements: the UP “manage changing requirements”.
The UP embraces change in requirements, the Waterfall model tries to deny that requirements will change by requesting that a full, detailed, specification be written prior to design and coding. On average 25% of the requirements change during a software project; Writing a detailed, accurate, specification even with frozen requirements with difficult and error prone (which means that the actual requirements are not actually captured implying change anyway later on in the specification); Why do you think people tried the waterfall-way of doing things (and still do)? In the UP and other evolutionary methods, we start release-grade programming and testing long before most of the requirements have been analysed (perhaps only 10% of the requirements have been specified whenever coding starts). 5.2 Evolutionary vs. Waterfall Requirements
The UP does not advocate that the solution is to start coding on day two of the project and forget about requirements analysis or requirements documentation … There is a middle way: iterative and evolutionary requirements analysis combined with early time-boxed iterative development and frequent stakeholder participation, evaluation, and feedback on partial results: It not easier to do than writing the full requirements up-front; It is just more likely to succeed…
Surely the client will know them all … Do they? Eliciting the real requirements is in general difficult. You must use whatever technique is necessary: Writing use cases; Requirements workshop; Maximum involvement of the client; Prototypes; Focus groups with proxy customers; Increment demonstration after each iteration; Active feedback solicitation; Friendly client/developers team building; Good communication practices; 5.3 Means to Find Requirements?
In the UP requirements are categorised according to the FURPS+ model: Functional : features; Usability : human factors, help, documentation; Reliability : frequency of failure, recoverability; Performance : response times, throughput, resource usage; Supportability : adaptability, maintainability, internationalisation; in addition the ‘+’ in FURPS+ indicates ancillary requirements or constraints such as: Implementation : language and tools, hardware restrictions; Interface : interfacing constraints ; Packaging : physical box; Legal : licensing; 5.4 Types and Categories of Requirements
Another, much coarser, categorisation is functional and non-functional requirements. Categories are good (up to a point …) as a checklist : we are less likely to forget some of the requirements. 5.4 Types and Categories of Requirements (cont’d)
The UP includes the following optional artifacts to record, keep track of and more generally manage requirements: Use Case Model : a set of typical scenarios (primarily for functional requirements); Supplementary Specification : basically for non-functional requirements; Glossary : a central repository of noteworthy terms; Vision : summarises the requirements and the business case for the project. Includes a short executive overview; Business Rules (aka Domain Rules) : external constraints that the project will have to respect, e.g. Banking procedures, network protocols, safety critical software regulations; To this I would add: Prototypes; Existing applications; The format for these documents is pretty free: but templates do exist and software companies may impose their own version; 5.5 How are Requirements Organised in UP Artifacts?
Since software requirements are hard to capture and do change over time an evolutionary approach to requirements gathering is more suitable than a big- bang, waterfall, approach. However this does not imply sloppiness during their analysis, documentation and change management. Questions Please 5.6 Conclusion