CAPTURING AND MANAGING REQUIREMENTS

For each project, you can now see a common structure among these expressions of requirements, as depicted in Figure 9-1. First, you collect the stakeholder requests , which encompass all the requests and wish lists you get from end users, customers, marketing, and other project stakeholders.

Figure 9-1. Requirement types and relationships with artifacts

The set of stakeholder requests is used to develop a vision document containing the set of key stakeholder and user needs and the high-level features of the system. These system features express services that must be delivered by the system in order to fulfill the stakeholder needs. We call this relationship requirements traceability. The features you decide to include in the vision document are based on an analysis of the cost of implementing a desired feature and a determination of the return on that investment. This analysis is found in the business case for the project.

Before coding begins, you must translate these features into detailed software requirements at a level at which you can design and build an actual system and identify test cases to test the system behavior. These detailed requirements are captured in the use-case model and other supplementary specifications, which capture those requirements that do not fit well in the use cases.

As you are detailing the requirements, you must keep in mind the original stakeholder needs and the system features to ensure that you are interpreting the vision correctly. This constant consideration of features and software requirements implies a traceability relationship wherein software requirements are derived from one or more features of the system, which in turn fulfill one or more stakeholder needs.

The detailed requirements are then realized in a design model and end-user documentation and are verified by a test model.

Gathering stakeholder requests and determining the needs and features specified in the vision document are started early in the project. Throughout the project lifecycle, you can use these features, based on customer priority, risk, and architectural stability, to divide the set of requirements into "slices" and detail them in an incremental fashion. As you are detailing these requirements, you will undoubtedly find flaws and inconsistencies that make it necessary to go back to the stakeholders for clarifications and trade-offs and to update the stakeholder needs and vision. So, the requirements workflow repeats in an iterative manner until all requirements are defined, feedback is considered , and the inevitable changes are managed.