VISION AND SCOPE DOCUMENT: The vision and scope document is one of the most important tools that

a project manager has; it is also one of the easiest to implement. A good vision and scope document will help a project avoid some of the costliest problems that a project can face. By writing the document and circulating it among everyone involved in the project, the project manager can ensure that each of the stakeholders and engineers share a common understanding of the needs being addressedand that the software must address them.
Vision and Scope Document Outline 1. a) b) c) d) e) 2. a) b) c) d) Problem Statement Project background Stakeholders Users Risks Assumptions Vision of the Solution Vision statement List of features Scope of phased release (optional) Features that will not be developed

Project background:
This section contains a summary of the problem that the project will solve. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should cover the reasons that the problem exists, the organizations history with this problem, any previous projects which were undertaken to try to address it, and the way that the decision to begin this project was reached.

Stakeholders: This is a bulleted list of the stakeholders. Each stakeholder may be referred to by name or by title or role (support group manager, CTO, senior manager). The needs of each stakeholder are described in a few sentences.

Users: This is a bulleted list of the users. As with the stakeholders, each user can either be referred to by name or role (support rep, call quality auditor, home website user)however, if there are many users, it is usually inefficient to try to name each one. The needs of each user

are described.

Risks This section lists any potential risks to the project (see Figure 2-1 for examples). It should be generated by a project teams brainstorming session. It could include external factors that could impact the project, issues or problems that could potentially cause project delays or raise issues. (The process for assessing and mitigating risk below can be used to generate the risks for this section.)

Assumptions

This is the list of assumptions that the stakeholders, users or project team have made. Often, these assumptions are generated during a Wideband Delphi estimation session (see Chapter 3). If Wideband Delphi is being used, the rest of the vision and scope document should be ready before the Delphi meeting and used as the basis for estimation. The assumptions generated during the estimation kickoff meeting should then be reviewed, and any nontechnical assumptions should be copied into this section. (Technical assumptionsmeaning assumptions that affect the design and development but not the scope of the project should not be included in this document. The estimate results will still contain a record of these assumptions, but they are not useful for this particular audience.) If Wideband Delphi is not being used to generate the assumptions, the project manager should hold a brainstorming session with the team to come up with a list of assumptions instead. (See Chapter 3 for more information on assumptions.)

Vision statement The goal of the vision statement is to describe what the project is expected to accomplish. It should explain what the purpose of the project is. This should be a compelling reason, a solid justification for spending time, money and resources on the project. The best time to write the vision statement is after talking to the stakeholders and users and writing down their needs; by this time, a concrete understanding of the project should be starting to jell.

List of features This section contains a list of features. A feature is as a cohesive area of the software that fulfills a specific need by providing a set of services or capabilities. Any software package in fact, any engineered productcan be broken down into features. The project manager can

choose the number of features in the vision and scope document by changing the level of detail or granularity of each feature, and by combining multiple features into a single one. Sometimes those features are small (screw-top cap, holds one liter of liquid); sometimes they are big (four wheel drive, seats seven passengers). It is useful to describe a product in about ten features in the vision and scope document, because this usually yields a level of complexity that most people reading it are comfortable with. Adding too many features will overwhelm most readers, and each extra feature adds time and effort to the project and makes it difficult or unrealistic to accomplish. Each feature should be listed in a separate paragraph or bullet point. It should be given a name, followed by a description of the functionality that it provides. This description does not need to be detailed; it can simply be a few sentences that give a general explanation of the feature. However, if there is more information that a stakeholder or project team member feels should be included, it is important to include that information. For example, it is sometimes useful to include a use case in a specific feature (see Chapter 6), as long as it is written in such a way that all of the stakeholders can read and understand it.

Scope of phased release (Optional) Sometimes software projects are released in phases: a version of the software with some subset of the features is released first, and a newer, more complete version is released later. This section describes the plan for a phased release, if that approach is to be taken. This is useful when there is an important deadline for the software, but developing the entire software project by that deadline would be unrealistic. The most common way to compromise on this release date is to divide the features into two or more releases. In that case, this section should identify specifically when those versions will be released, and which features will be included in each version. Its reasonable to divide one feature up between two releases, as long as it is made clear exactly how that will happen. If a project manager needs to release a project in phases, it is critical that the project team be consulted. Some features are much more difficult to divide than others, and the engineers might see dependencies between features that are not clear to the stakeholders and project manager. After the phased release plan is written down and agreed upon, the project team should always be asked to re-estimate the effort and a new project plan should be generated (see below). This will ensure that the phased release is feasible and compatible with the companys priorities.

Features that will not be developed Features are often left out of a project on purpose. When a feature is explicitly left out of the software, it should be added to this section to tell the reader that a decision was made to exclude it. For example, one way to handle an unrealistic deadline is by removing one or

more features from the software, in which case the removed features should be moved into this section. The reason these features should be moved rather than deleted from the document is that otherwise readers might assume that they were overlooked and bring the up in a review. This is especially important during the review of the document because it allows everyone to agree on the exclusion of the feature (or object to it).

VISIONA ND SCOPE DOCUMENT: The scope description establishes the boundary and connections between the systems we are developing and everything else in the universe. The context diagram graphically illustrates this boundary. It identifies terminators outside the system that interface to it in some way, as well as data, control, and material flow between the terminators and the system. The context diagram is the top level of abstraction in a data flow diagram developed according to the principles of structured analysis., but itsg a useful model for projects that follow any development methodology. You can include the context diagram in the vision and scope document, in or as an appendix to then SRS, or as part of a data flow model for the system.