Develop a Vision

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:

• Stakeholders list: Customers, users, investors, product managers, designers, testers, and so on.

• Constraints: Budgetary constraints, a list of technology selections, operating systems, and required coexistence or compatibility with existing systems.

• Problem statement: A distinct description of the problem you are attempting to solve (described in more detail later).

• Feature list: A list of services provided by the system for the users of that system (described in more detail later).

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 Statement

The problem statement forces the team to specify concretely the problem they are attempting to solve. The following format can be used:

The problem of <describe the problem> affects <the stakeholders affected by the problem>.

The impact of which is <what the impact of the problem is>.

A successful solution would <list some key benefits of a successful solution>.

A problem statement could look like the following:

The problem of untimely and improper resolution of customer service issues

affects our customers, customer support reps, and service technicians.

The impact of which is customer dissatisfaction, perceived lack of quality, unhappy employees , and loss of revenue.

A successful solution would provide real-time access to a troubleshooting database by support representatives and facilitate dispatch of service technicians, in a timely manner, to only those locations in genuine need of assistance.

Feature List

A 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:

• A short description

• A value attribute indicating the business value the feature provides (for example, low, medium, or high)

• A cost attribute indicating how complex/costly the feature is to implement

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:

^[3] It should be noted that in some rare cases, especially for embedded systems, all features really should be of Priority 1 because the system cannot be delivered without all of the specified features.

• Assume that you have only 50 percent or less of available resources. Assign the highest priority features you expect to be able to develop with those resources (yes, it will be a big guess, but when in doubt, be pessimistic) as Priority 1.

• Assume that you have only 80 percent of available resources. Assign the next set of high-priority features you expect to be able to develop with those resources as Priority 2.

• Assume that you have 100 percent of available resources. Assign the next set of high-priority features you expect to be able to develop with those resources as Priority 3.

• Assign the remaining features as Priorities 4 and 5 (that is, as candidates for future projects).

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.