Vision and Scope Document

for

<Project>
Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Vision and Scope for <Project>

Page ii

Table of Contents
1. 2. 3. 4. 5. 6. 7. 8. Introduction..................................................................................................1 Business Requirements................................................................................1 Stakeholders and Users Profiles...................................................................5 Vision Statement..........................................................................................7 Product Overview.........................................................................................7 Scope and Limitations................................................................................11 Documentation Requirements ..................................................................11 Glossary.....................................................................................................13

Vision and Scope for <Project>

Page iii

Revision History
Name Date Reason For Changes Version

Vision and Scope for <Project>

Page 1

1. Introduction
This section provides an overview of the entire document. It should include the following: Section 1: Purpose of the document Section 2: Brief description of the scope of the document, what project(s) it is associated with and anything else that is affected or influenced by this document Section 3: An overview that contains and explains how the document is organized

2. Business Requirements
2.1. Background This section summarizes the rationale for the new product or the proposed enhancements. It provides a general description of the history or situation that leads to the recognition that this product should be built or why the product should be enhanced. 2.2. Business Opportunity For new product Describe the market opportunity that exists for the new product. Identify the following: problems that cannot be solved without the product,; how the product fits in with the corporate strategic direction, ; and alternatives and known competitive products that exist or may become available. Include the major strengths and weaknesses of each competitor.

For enhancements Describe the problem that will be solved by the proposed enhancement. Identify the following: problems that cannot be solved without the product,; how the product fits in with the corporate strategic direction, ; and 2.3. Business Objectives and Success Criteria List the important business objectives of the product. The business objectives should be quantitative and measurable. It should focus on the value provided to the client. This may include the following:

Vision and Scope for <Project>

Page 2

estimates of revenue or cost savings return on investment analysis

Describe how success will be defined and measured on this project. Identify the factors that are likely to have the greatest impact on achieving success. Include things within the direct control of the organization, as well as external factors. Establish measurable criteria to assess whether the business objectives have been met. 2.4. Client Needs (NEED) Describe the clients problems and needs that the new product or the enhancements will address. Avoid including any design or implementation details. Present the needs in a numbered list so that detailed user or functional requirements can be traced to them. The following format may be used for the problem statement. You may not use the suggested format but make sure that the problem statement includes the problem, the stakeholder affected by the problem and the impact of the problem. Problem No 1 Problem statement The problem of < describe the problem > affects < the stakeholders affected by the problem > the impact of which is < what is the impact of the problem>. < another problem statement > Source Name of the stakeholder / user who identified the problem

2.5. Business Risks Summarize the major business risks associated with developing this product such as marketplace competition, timing issues, user acceptance, implementation issues, or possible negative impacts on the business. Estimate the severity of the risks and identify any risk mitigation actions that could be taken. Risks should be arranged by probability of occurrence starting with the highest risk exposure. Listed below are some of the risks that may be encountered during product development. You may add or delete a risk category from the list. ID 1 Risk Category Project requirements are poorly structured and lack P L E Mitigation Approaches Ensure that the author who will conduct the interview Who Project Manage r Date Due Prior to the interview

Vision and Scope for <Project>

Page 3

essential information.

understands the software development process. Also, make sure that the author was trained on the following areas: interviewing techniques technical writing If the author is not trained on interviewing techniques, the author must be accompanied by somebody who was trained on this area.

Project does not have effective sponsorship or management support Project champion leaves the company

Find a person with authority who could be a project sponsor. When a project sponsor is appointed, a person who can act as his/her alter ego should also be appointed. Provide training to upgrade the IT skills of the users. If client is amenable, include in the proposal that IT training will be provided by Vendor Train the stakeholder in SDLC appreciation in phases where the stakeholder will be involved

Client

Before the interview Before the interview

Client

Intended users of the product lack IT skills

Client

Before developm ent of software requireme nts

Stakeholder involved in the various phases of the software development lifecycle (SDLC) was not previously involved in software development

Client

Before developm ent of software requireme nts

Vision and Scope for <Project>

Page 4

Loss of key staff

Stakeholder assigned to do user testing and validation do not have knowledge on software testing Inadequate testing facilities, including hardware and software Inadequate hardware and software

Ensure proper documentation of all project activities. Identify alternates Provide training on software testing. Outsource user testing and validation Provide the required facilities. Outsource testing to companies that have the required facilities. Before starting the project, make sure that all required hardware and software are available. Perform progress review. Monitor stakeholder commitments. Ensure that the stakeholders compliance to commitments. Negotiated deadlines. Explore alternative means or stop gap measures. Inquire from regulatory/policymaking bodies if there will be changes in the regulations / policies.

Client

Client

Before the start of the test phase

Client

Before the start of the test phase Before the start of the software developm ent.

Client

10

Late product delivery.

Project Manage r

11

Deadlines are unrealistic

12

Potential regulatory/policy changes

Client

P = probability of occurrence (0 to 1) L = relative loss factor (0 to 10) E = risk exposure = P*L

Vision and Scope for <Project>

Page 5

3. Stakeholders and Users Profiles

3.1. Stakeholders Profiles Stakeholders are individuals, groups, or organizations that are actively involved in the development of the product. They can influence the projects outcome and are affected by its outcome. Stakeholders are not the end users of the product to be developed but they may be the users of the output of the product (e.g. reports, interface files). Some stakeholders have sign-off authority and are the only one who may request or approve any changes to the project requirements and scope. Vendor is also a stakeholder who is represented by the Project Manager of the team that will develop the product. [This should state the stakeholders / users duties and responsibilities, expertise, level of involvement, and attitudes toward the project.] 3.1.1 Stakeholders Summary Name Position / Job Title < a stakeholder > Responsibilities List the stakeholders key responsibilities in relation to the system being developed, that is, their interest as a stakeholder. Role At what point in the software development cycle is the stakeholder involved (during project initiation, Planning, Development, Implementation and Delivery)? How is the stakeholder involved in the project? Relate where possible to Rational Unified Process role, that is, Requirements Reviewer, etc. e.g. Project Initiation Requirement specifier Planning Approves changes to requirements Development Tester Implementation and Delivery Deployment Manager

< another stakeholder >

Vision and Scope for <Project>

Page 6

3.1.2 Stakeholders Details 3.1.2.1 Stakeholder Name, Position / Job Title Department / Unit and contact number Representative

Type Success Criteria Expected Deliverables Comments / Issues

Who is the stakeholder representative to the project? If the stakeholder is an institution, identify the contact person and contact number. If not applicable, put NA. Qualify the stakeholders expertise and technical background. How does the stakeholder define success of the system being developed? What are the deliverables required by stakeholders? These could be project deliverables or outputs from the system under development. Problems that interfere with success and any other relevant information go here.

3.1.3 <another Stakeholder Name, Position / Job Title> 3.2. User Profiles This section identifies the users of the product that will be developed. 3.2.1 User Summary Name Position / Job Title < a user > Responsibilities List the users key responsibilities in relation to the system being developed, that is, captures details, produces reports, coordinates work and so on. Roles At what point in the software development cycle is the stakeholder involved (during project initiation, Planning, Development, Implementation and Delivery)? How is the user involved in the project? Relate where possible to Rational Unified Process role. e.g. Project Initiation Requirements Reviewer Planning test designer

Vision and Scope for <Project>

Page 7

< another user > 3.2.2 User Details 3.2.2.1 <User Name, Position / Job Title>

Development Tester Implementation and Delivery Trainor

User name may be blank. For example, a time deposit system is implemented branch wide, you may say that the user of the system are bank tellers. Department / Unit and contact number Representative

Type Success Criteria Deliverables Training considerations Comments / Issues

Who is the user representative to the project? This refers to the stakeholder that represents the set of users. If not applicable, put NA. Qualify the users expertise and technical background. How does the user define success of the system being developed? Are there any deliverables the user produces? If so, for whom? Describe the kind of training and training time that must be provided to the user. Problems that interfere with success and any other relevant information go here.

3.2.3 <another User Name, Position / Job Title>

4. Vision Statement
Write a concise vision statement that summarizes the purpose and intent of the new product. This section describes what the world will be like when it includes the product. The vision statement should reflect a balanced view that will satisfy the needs of diverse clients as well as those of the developing organization. It may be somewhat idealistic, but it should be grounded in the realities of existing or anticipated client markets, enterprise architectures, organizational strategic directions, and cost and resource limitations.

5. Product Overview
This section provides a high level view of the product capabilities, interfaces to other applications, and systems configuration. This section usually consists of three subsections, as follows:

Vision and Scope for <Project>

Page 8

Product Perspective Product Features Assumptions and Dependencies

5.1. Product Perspective This section puts the product in perspective to other related products and the users environment. If the product is a component of a larger system or has interface with other application systems, then this section relates how the product interact with the other systems and identifies the relevant interfaces between the systems. It should be able to answer the following questions: What does the product do to / for the other application systems? What does the other application systems do to / for the product?

One easy way to display the major components of the larger system, interconnections and external interfaces is with a block diagram. If the product is independent and totally self-contained, state it here. 5.2. Product Features (FEAT) List and briefly describe the product features. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users. Each feature is an externally desired service that typically requires a series of inputs to achieve the desired result. The level of detail needs to be general enough for everyone to understand. However, enough detail must be provided to the team to be able to create a use-case model. Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented. Feature No 1 Feature Description < a Feature> Trace to Client Need No Source Name of the stakeholder / user who requested the feature

< another Feature >

5.3.

Other Product Requirements (Optional) At a high-level, list applicable standards, hardware or platform requirements, performance requirements and environmental requirements.

Vision and Scope for <Project>

Page 9

5.3.1 Applicable Standards (AS) List all standards with which the product must comply. These can include legal and mandatory, communication standards (TCP/IP, ISDN), platform compliance standards (Windows, Unix, etc), and quality and safety standards (UL, ISO, CMM. Requiremen t No 1 Trace to Client Need No

Requirement Description < a Requirement>

< another Requirement >

Source Name of the stakeholder / user who requested the feature

5.3.2 System Requirements (SR) Define system requirements necessary to support the application. These can include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software. Requiremen t No 1 Requirement Description < a Requirement> Trace to Client Need No Source Name of the stakeholder / user who requested the feature

< another Requirement >

5.3.3 Performance Requirements (PR) Use this section to enumerate performance requirements. Performance issues can include user load factors, bandwidth or communication capacity, throughput, accuracy and reliability or response times under a variety of loading conditions. Requiremen t No 1 Requirement Description < a Requirement> Trace to Client Need No Source Name of the stakeholder / user who requested the feature

< another Requirement >

5.3.4 Environmental Requirements (ER)

Vision and Scope for <Project>

Page 10

Identify environmental requirements as needed. For hardware-based systems, environmental issues can include temperature, shock, humidity, radiation and so forth. For software applications, environmental factors can include usage condition, user environment, resource availability, maintenance issues, and error handling and recovery Requiremen t No 1 Trace to Client Need No

Requirement Description < a Requirement>

< another Requirement >

Source Name of the stakeholder / user who requested the feature

5.3.5 Security Requirements (CR) Discuss the data protection and access security controls requirements Requiremen t No 1 Trace to Client Need No

Requirement Description < a Requirement>

< another Requirement >

Source Name of the stakeholder / user who requested the feature

5.4. Assumptions and Dependencies 5.4.1 Assumptions Record any assumptions that were made when conceiving the project and writing this document. List assumptions that, if changed, will alter the document. Examples: A specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the document will need to change. The stakeholder assigned to do user acceptance testing and validation is trained on the software testing process. If the stakeholder is not trained on the process, the stakeholders roles and business risks of the document will change.

Vision and Scope for <Project>

Page 11

The intended users of the product are computer literate. If the users are not computer literate, the training needs and business risks sections of the document will change. 5.4.2 Dependencies Note any major dependencies the project must rely upon for success, such as specific technologies, third-party vendors, development partners, or other business relationships.

6. Scope and Limitations

6.1. Scope of Initial Release Describe the intended major features that will be included in the initial release of the product. Focus on those features and product characteristics that will provide the most value, at the most acceptable development cost, to the broadest community. Feature No 1 2

Feature Description < a Feature> < another Feature >

Priority

Priority 1 = feature is essential, mandatory, non-negotiable or urgent requirements Priority 2 = feature is useful, negotiable or slightly deferrable requirements Priority 3 = feature is desirable if low cost, can be readily descoped, flexible or longer delay requirements 6.2. Scope of Subsequent Releases If a staged evolution of the product is envisioned over time, indicate which major features will be deferred to later releases. 6.3. Limitations and Exclusions Identify any product features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the new product.

7. Documentation Requirements
7.1. Users Manual

Vision and Scope for <Project>

Page 12

Describes the purpose and content of the User Manual. Discuss the desired length, level of detail, need for index, glossary of term, tutorial versus reference manual strategy, and so on. Formatting and printing constraints must be identified also. The source of the requirement must be identified. 7.2. Online Help Many applications provide an online help system to assist the user. The nature of these systems is unique to application development as they combine aspects of programming with aspects of a technical writing such as organization and presentation. Many have found the development of online help system is a project within a project that benefits from up-front scope management and planning activity. The source of the requirement must be identified.

7.3. Installation Guides, Configuration and Read Me File A document that includes installation instructions and configuration guidelines is important to a full solution offering. Also, a Read Me file is typically included as a standard component. The Read Me file can include a Whats New With This Release section, and a discussion of compatibility issues with earlier releases. Most users also appreciate documentation defining any known bugs and workarounds in the Read Me file. The source of the requirement must be identified.

7.4. Labeling and Packaging Todays state-of-the-art applications provide a consistent look and feel that begins with product packaging and manifests through installation menu, splash screens, help systems, GUI dialogs, and so on. This section defines the needs and types of labeling to be incorporated into the code. Examples include copyright and patent notices, corporate logos, standardized icons and other graphic elements, and so forth. The source of the requirement must be identified.

Vision and Scope for <Project>

Page 13

8. Glossary