1. Chapter 05: Evolutionary Requirements

2. 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”.

3.  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

4.  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…

5.  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?

6.  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

7.  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)

8.  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?

9.  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