1. Chapter 5 Evolutionary Requirements

2. Introduction 5.1 Definition: Requirements 5.2 Evolutionary vs. Waterfall Requirements 5.3 What are Skillful Means to Find Requirements? 5.4 What are the Types and Categories of Requirements? 5.5 How are Requirements Organized in UP Artifacts? 5.6 Does the Book Contain Examples of These Artifacts?

3. Introduction This chapter briefly introduces iterative and evolutionary requirements, and describes specific UP requirement artifacts, to provide context for the coming requirements-oriented chapters. It also explores some evidence illustrating the futility and unskillfulness of waterfall-oriented requirements analysis approaches, in which there is an attempt to define so-called “complete” specifications before starting development.

4. 5.1 Definition: Requirements Requirements are capabilities and conditions to which the system—and more broadly, the project—must conform. A prime challenge of requirements work is to find, communicate, and remember (that usually means record) what is really needed, in a form that clearly speaks to the client and development team members.

5. The UP promotes a set of best practices, one of which is manage requirements. This does not refer to the waterfall attitude of attempting to fully define and stabilize the requirements in the first phase of a project, but rather—in the context of inevitably changing and unclear stakeholder’s wishes– “a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system”.

6. 5.2 Evolutionary vs. Waterfall Requirements Notice the word changing in the definition of what it means to manage requirements. The UP embraces change in requirements as a fundamental driver on projects. That’s incredibly important and at the heart of waterfall versus iterative and evolutionary thinking.

7. In the UP and other evolutionary methods, we start production-quality programming and testing long before most of the requirements have been analyzed or specified—perhaps when only 10% or 20% of the most architecturally significant, risky, and high- business-value requirements have been specified.

8. Figure 5.1 Actual use of waterfall-specified features. Always, 7% Often, 13% Sometimes, 16% Rarely, 19% Never, 45%

9. 5.3 What are Skillful Means to Find Requirements? Besides changing, the word finding is important; that is, the UP encourages skillful elicitation via techniques such as writing use cases with customers, requirements workshops that include both developers and customers, focus groups with proxy customers, and a demo of the results of each iteration to the customers, to solicit feedback.

10. 5.4 What are the Types and Categories of Requirements? In the UP, requirements are categorized according to the FURPS+ model, a useful mnemonic with the following meaning: Functional—features, capabilities, security. Usability—human factors, help, documentation.

11. Reliability—frequency of failure, recoverability, predictability. Performance—response times, throughput, accuracy, availability, resource usage. Supportability—adaptability, maintainability, internationalization, configurability.

12. The “+” in FURPS+ indicates ancillary and sub-factors, such as: Implementation—resource limitations, languages and tools, hardware,… Interface—constraints imposed by interfacing with external systems. Operations—system management in its operational setting. Packaging—for example, a physical box. Legal—licensing and so forth.

13. It is helpful to use FURPS+ categories (or some categorization scheme) as a checklist for requirements coverage, to reduce the risk of not considering some important facet of the system.

14. In common usage, requirements are categorized as functional (behavioral) or non-functional (everything else);Some dislike this broad generalization, but it is very widely used.

15. Functional requirements are explored and recorded in the Use-Case Model, the subject of the next chapter, and in the system features list of the Vision artifact. Other requirements can be recorded in the use cases they relate to, or in the Supplementary Specifications artifact.

16. The Vision artifact summarizes high-level requirements that are elaborated in these other documents. The Glossary records and clarifies terms used in the requirements. The Glossary in the UP also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth. Prototypes are a mechanism to clarify what is wanted or possible.

17. As indicated in Figure 5.1, one study of factors on challenged projects revealed that 37% of factors related to problems with requirements, making requirements issues the largest single contributor to problems. Consequently, masterful requirements management is important.

18. Other 50% Poor user input 13% Incomplete requirements 12% Changing requirement 12% Poor technical skills 7% Poor staffing 6% Figure 5.1 Factors on challenged software projects