A Vision defines the stakeholders' view of the product to be developed, specified in terms of the stakeholders' key needs and features, and provides the contractual basis for the more detailed technical requirements. The most essential things captured in a Vision include the following:
As we discussed in Chapter 6, for very small projects this could be an informal document, maybe even an e-mail message capturing what was on a whiteboard. For average- sized projects, you might write a Vision Document of a few pages; large projects may require quite an extensive Vision Document. Let's take a closer look at some of these sections. Problem StatementThe problem statement forces the team to specify concretely the problem they are attempting to solve. The following format can be used:
A problem statement could look like the following:
Feature ListA feature is a service provided by the system that can be observed by a user of the system, and that directly fulfills a stakeholder need. To identify the right set of features, you need to analyze the stakeholder requests and understand how they help provide the benefits described in the problem statement. Each feature should have the following:
By looking at the value and cost, you can now prioritize the features. You may, for example, choose to use priority levels of 1 through 5. A common problem in projects is assigning almost all features to Priority 1 ”this makes prioritization meaningless. [3] To avoid this, you can force separation of requirements so they are not all of the same priority level. There are many ways to achieve this ”here is a typical approach to prioritization:
Prioritization forces you to make some preliminary, but tough, decisions on how to use your resources. If progress is slower than expected and, for example, you have to cut 20 percent of the features, you would in the example cut all Priority 3 features and postpone them to later projects. You will revisit and fine-tune the priority list many times during Inception and Elaboration. And you will use the list frequently in Construction and Transition to make sure that you make the right decisions if you need to descope the project to handle unexpected delays. The analyst typically proposes the initial prioritization of features, reviews them with the project manager, architect, and the stakeholder team, and then modifies the list based on feedback. |