Requirements Management in the Rational Unified Process

The best practice of requirements management is captured in the Rational Unified Process in the requirements discipline , one of nine core disciplines described in the process. This requirements discipline produces and updates the artifacts shown in Figure E-2.

Figure E-2. Requirements discipline

Many of these artifacts are consistent with those described in this book, including the following:

• Stakeholder requests and the collection of any type of requests (including formal change requests , needs, or other input from any stakeholders) during the lifecycle of the project that might affect the product requirements

• The Vision document, which summarizes the overall vision of the system under consideration: main characteristics, major features, key stakeholder needs, and key services provided

• The use-case model, the organized set of use cases that constitute the bulk of the requirements

• The supplementary specification, which captures any requirements that cannot be tied directly to any specific use case, in particular, many of the nonfunctional requirements and design constraints

Other artifacts are also developed as a result of this discipline, including

• Requirements attributes, a repository of information containing requirements- related information that is used to track requirements status and to maintain traceability to other project elements

• Use-case storyboards, systematically derived from the essential use cases involving human actors to model the user interface and to elaborate some of the usability requirements

• User interface prototypes , developed to get feedback from the various stakeholders

• A project glossary, which captures and defines the terms used in the project domain

Workers involved in this discipline include

• Stakeholder, customer, end user, or whoever within the development organization represents the role of anyone providing input to the requirements process (the marketing manager in some companies)

• System analyst, who leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system: for example, establishing what actors and use cases exist and how they interact, along with nonfunctional requirements and design constraints

• Use-case specifier , who details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases

• User interface designer, who develops use-case storyboards and user interface prototypes and involves other stakeholders in their evaluation

• Requirements reviewer (a role usually played by several team members ), who plans and conducts the formal review of the use-case model and other requirements specified in the supplementary specification

The description of the requirements discipline activities and steps is organized in the Rational Unified Process into six smaller disciplines (called discipline details ), which parallels many of the team skills described in this book.

Analyzing the Problem

As shown in Figure E-3, the purpose of this discipline detail is to

• Produce a Vision document for the project

• Agree on system features and goals

Figure E-3. Analyzing the problem

This discipline detail may be revisited several times during inception and early elaboration. As requests from stakeholders are more clearly understood , both business process solutions and technical solutions will evolve .

The primary activity in this discipline is to develop the Vision document, which identifies the high-level user or customer view of the system to be built. In the Vision document, initial requirements are expressed as key features the system must possess in order to solve the most critical problems. The features should be assigned attributes, such as rationale, relative value or priority, source of request, and so on, so that dependencies can begin to be managed. As the vision develops, the system analyst identifies users and system interfaces ”the actors of the system.

Understanding User and Stakeholder Needs

The purpose of this discipline detail is to elicit and collect information from stakeholders of the project (Figure E-4). The collected stakeholder requests can be regarded as a "wish list" that will be used as primary input to defining the use-case model, use cases, and supplementary specification. Typically, this is performed only during iterations in the inception and elaboration phases.

Figure E-4. Understanding user and stakeholder needs

The key activity is to elicit stakeholder requests . The primary outputs are collection(s) of prioritized stakeholder requests, which enable refinement of the Vision document, as well as a better understanding of the requirements attributes. Also, during this discipline, you may start discussing the system in terms of its use cases and actors. Another important output is an updated glossary of terms to facilitate a common vocabulary among team members.

Defining the System

The purpose of this discipline detail (Figure E-5) is to

• Align the project team in its understanding of the system

• Perform a high-level analysis of the results of collecting stakeholder requests

• More formally document the results in models and documents

Figure E-5. Defining the system

Typically, this is performed only in iterations during the inception and elaboration phases.

Problem analysis and understanding stakeholder needs create early iterations of key system definitions, including the Vision document, a first outline to the use-case model, and the requirements attributes. In defining the system, you focus on identifying actors and use cases more completely and adding supplementary specifications.

Managing Scope

The purpose of this discipline detail (Figure E-6) is to

• Define input to the selection of requirements to be included in the current iteration

• Define the set of features and use cases (or scenarios) that represent some significant, central functionality

• Define which requirement attributes and traceabilities to maintain

Figure E-6. Managing the scope of the system

Although project scope should be managed continuously, the better understanding of system functionality obtained from identifying most actors, use cases, and supplementary specifications will allow the system analyst to apply priority, effort, cost, risk values, and so on to requirements attributes more accurately and will enable the architect to identify the architecturally significant use cases. An input to managing scope not seen in other discipline details of the requirements discipline is the iteration plan , developed in parallel by project and development management. The iteration plan defines the number and frequency of iterations planned for the release. The scope of the project defined in managing scope will have a significant impact on the iteration plan since the highest-risk elements within scope will be planned for early iterations. Other important outputs from managing scope include the initial iteration of the software architecture document and a revised Vision document that reflects the system analyst's and key stakeholders' better understanding of system functionality and project resources.

Refining the System Definition

The purpose of this discipline detail (Figure E-7) is to further refine the requirements in order to

• Describe the use case's flow of events in detail

• Detail supplementary specifications

• Model and prototype the user interfaces

Figure E-7. Refining the system definition

Refining the system begins with use cases outlined, actors described at least briefly , and a revised understanding of project scope reflected in reprioritized features in the vision and believed to be achievable by fairly firm budgets and dates. The output of this discipline is more in-depth understanding of system functionality expressed in detailed use cases, revised and detailed supplementary specifications, and user interface elements.

Managing Changing Requirements

The purpose of this discipline detail (Figure E-8) is to

• Structure the use-case model

• Set up appropriate requirements attributes and traceabilities

• Formally verify that the results of the requirements discipline conform to the customer's view of the system

Figure E-8. Managing changing requirements

Changes to requirements naturally impact the models produced in the analysis and design discipline, as well as the test model created as part of the test discipline. Traceability relationships between requirements identified in the manage dependency activity of this discipline and others are the key to understanding these impacts.

Another important concept is the tracking of requirements history. By capturing the nature and rationale of requirements changes, reviewers (in this case, the role is played by anyone on the software project team whose work is affected by the change) receive the information needed to respond to the change properly.