Selecting Your Requirements Approach

With an understanding of how to apply different requirements methods to different project contexts, we can now proceed to provide a prescription. However, if we are going to simplify the prescription, as is necessary to manage our level of abstraction ”and to help us manage the scope of the prescription ”we must first make some simplifying assumptions.

The Simplifying Assumptions

The following assumptions help us communicate more clearly what type of system the prescription can be applied to and also help manage your expectations for what the prescription can deliver.

The followers of the prescription have read and understood this book and/or received some training reasonably consistent with its methodology and practices.
The application being developed is a stand-alone application, not a complex system of subsystems or a project with a much larger scope. In addition, there are no contractual requirements for processes or documents in a specific format.
The team size is small to moderate, perhaps 10 “30 members .
The software is being designed for use by others: an external customer who is reasonably available to the team.
It's a new application, so the team can "start from scratch" when building the project.
The team members will use modern software methods and are familiar with the basic concepts of use cases and iterative development.
The team members have reasonable tool support, including requirements management tools, modeling tools, a change request system, and change management tools.

In other words, this looks like the right project context in which to deploy the agile requirements method we described in Chapter 30.

The Prescription

So finally, with this context in hand, here is a step-by-step prescription for a requirements method in the agile style.

Step 1: Get Organized

Meet with your team and agree on the basic software processes you will employ .
Decide how you will manage requirements on the project and document this process in a short one- to two-page requirements management plan.
Decide what types of software tooling you will apply to the project.
Determine a configuration management plan for your code and requirements artifacts.
Establish an iteration plan and determine the basic project metrics and reporting disciplines.

Step 2: Understand the Problem Being Solved

Execute the five-step problem analysis process.
1. Gain agreement on the problem being solved. Write it down.
2. Understand the root cause of the problem (if applicable to your situation).
3. Identify the stakeholders and users, or actors, in your system.
4. Define the system boundary. Document the boundary and the identified stakeholders and actors in a system context diagram or preliminary use-case model.
5. Identify constraints imposed on the solution. Write them down.
Circulate the problem statement to external stakeholders and insist that you gain agreement on the problem statement before moving forward.

Step 3: Understand User and Stakeholder Needs

Create a structured interview, using the generic template from Chapter 10, pertinent to your application.
Interview 5 “15 users/stakeholders identified in step 2.
Summarize the interviews by aggregating the top 10 “15 user needs, or use the "pithy quote approach"; that is, document 10 or 15 particularly memorable stakeholder's quotes that reflect their needs in their own words.
Use the quotes or the restated needs to start your requirements pyramid.
Facilitate a requirements workshop for your project. Use "out-of-the-box" and "in-the-box" warm-up papers (use "in-the-box" data from step 3c).
1. Run a brainstorming session to identify/refine features.
2. Perform idea reduction and feature prioritization.
3. Use the critical, important , and useful classification.
Rerun the workshop once or twice during the project to provide a format for ongoing customer input.
Create storyboards for all innovative concepts. Present them, propose an initial set of use cases to your users, and get user feedback.
Ensure that your process yields early iterations that the users can test in their environment.

Step 4: Define the System

Adopt the Vision document concept and create a template to suit your project's needs.
Create a product position statement. Circulate it widely and make sure your customer agrees with it. If you don't have agreement, stop and get it.
Enter in the Vision document all features identified in step 3 and through other inputs, such as development, help desk, and marketing. Trace these features back to user needs. Use attributes of priority (critical, important, useful), risk (high, medium, low), effort (team-months), stability (high, medium, low), and release (v1.0 and so on). Define the commercial requirements (licensing, documentation, legal, regulatory, and so on) in the whole product plan.
Make the Vision document be the living document for your project. Publish it for easy access and review. Make the project champion, by default, the official channel for changing features. Use a Delta Vision document as you move forward.
Develop the use-case model for your project so that all stakeholders can see what actors the system supports and how it supports them.

Step 5: Continuously Manage Scope and Manage Change

Based on effort estimates from the team, determine the baseline for each release in the Vision document, using an attribute of "version number."
Get customer agreement on scope. Help the team make the hard scope decisions and get the decisions behind you .
Preach and teach iterative development. Build iterations monthly or weekly. Communicate and manage expectations everywhere.
Manage change by using the baseline. Use the Delta Vision document to capture all new features that arise through the normal course of events. Make sure that all suggested features are recorded so that none are lost. Empower a change control board to make the hard decisions.
Install a change request management system to capture all requests for change, and ensure that all requests go through that system to the change control board.

Step 6: Refine the System Definition

Refine the use-case model, use-case specifications, and supplementary specifications to whatever level of detail is necessary to assure that your team members are all developing the same system.
Have the development team and test team adopt and manage this workload. Assist them with training and find them help if they need it. Use formal analysis methods only when you cannot afford to be misunderstood.
Trace nonfunctional requirements to and from use cases and features.
Ensure that you have discovered all the nonfunctional requirements for your system, including design constraints. The template you use should prompt you to make sure that you have asked the right questions.

Step 7: Build the Right System

Engage the test department in the requirements management challenge now. Have testers involved in test planning from the beginning. Have the test team review the use cases as they are developed, and look for additional alternative flows and events. Brainstorm potential exception conditions. Develop scenarios and test cases directly from the use cases. Deter -mine a strategy for testing nonfunctional requirements.
Rely on the use cases and use-case realizations in the design model to integrate design elements with the requirements. Use implicit traceability through the use-case realizations for impact assessment as change occurs.
Develop regression testing processes that are as automated and efficient as possible, with the goal being the ability to fully regression test the system at every new iteration.

Step 8: Manage the Requirements Process

The product manager or project champion should maintain responsibility for the Vision document, attend weekly reviews with the team to assess status, and set up default reports and queries to assist this effort.
Monitor the software requirements management process to assure that the vision is fulfilled in the use-case model and in the implementation.
Engage the quality assurance team to help monitor the requirements maintenance, change management, and test processes.
Participate or drive the change control process, assuring that impact is assessed before significant changes are allowed into the system.