Chapter 5

Evolutionary Requirements

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?

Introduction This chapter briefly introduces iterative and evo

lutionary 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.

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.

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

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.

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.

Figure 5.1 Actual use of waterfall-specified features.

Always, 7%

Often, 13%

Sometimes, 16%

Rarely, 19%

Never, 45%

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.

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.

Reliability—frequency of failure, recoverability, predictability.

Performance—response times, throughput, accuracy, availability, resource usage.

Supportability—adaptability, maintainability, internationalization, configurability.

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.

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.

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.

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.

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.

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.

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