How is all this translated concretely in terms of roles, artifacts, and activities? Figure 9-3 shows the main roles and artifacts in the requirements discipline:
Figure 9-3. Roles and artifacts in the requirements discipline
Working with stakeholders of the project, the System Analyst analyzes the problem and works with stakeholders to understand what they need and to define what the system must do and perhaps what it should not do ”also identifying nonfunctional requirements. The System Analyst can then develop a vision for the project. This vision, expressed as a set of features written from the stakeholder's perspective, is a basis for developing an outline of a Use-Case Model. The Requirements Specifier is assigned a set of use cases and supplementary requirements, which he or she will detail and make consistent with other requirements discipline artifacts. The Requirements Specifier does not work in isolation but rather should communicate regularly with other individual Requirements Specifiers as well as with the System Analyst. Requirement Specifiers and System Analysts work closely with the User-Interface Designers (see Chapter 10). Another role involved in the requirements discipline is the Software Architect, who is involved primarily in earlier iterations and works with the System Analyst and Requirements Specifier to ensure the integrity of the architecturally significant use cases. The Requirements Reviewer is another important role, representing all the different kinds of people you bring in to verify that the requirements are perceived and interpreted correctly by the development team. Because reviews have different purposes, they are performed several times during the execution of the requirements workflow by requirements reviewers with different profiles. Together, the individuals acting in these roles form a team that exercises the requirements workflow iteratively throughout the project lifecycle. |