Vision and Scope Document for <Project> Version 1.0 approved Prepared by <author> <organization> <date created> Table of Contents Table of Contents ii Revision History ii…

Vision and Scope Document

for

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Table
of Contents

Table
of Contents ii

Revision
History ii

1. Business
Requirements 1

1.1. Background 1

1.2. Business
Opportunity 1

1.3. Business
Objectives and Success Criteria 1

1.4. Customer
or Market Needs 1

1.5. Business
Risks 1

2. Vision
of the Solution 2

2.1. Vision
Statement 2

2.2. Major
Features 2

2.3. Assumptions
and Dependencies 2

3. Scope
and Limitations 2

3.1. Scope
of Initial Release 2

3.2. Scope
of Subsequent Releases 2

3.3. Limitations
and Exclusions 3

4. Business
Context 3

4.1. Stakeholder
Profiles 3

4.2. Project
Priorities 4

4.3. Operating
Environment 4

Revision
History

Name

Date

Reason
For Changes

Version

<The business requirements provide
the foundation and reference for all detailed requirements
development. You may gather business requirements from the customer
or development organization’s senior management, an executive
sponsor, a project visionary, product management, the marketing
department, or other individuals who have a clear sense of why the
project is being undertaken and the ultimate value it will provide,
both to the business and to customers.>

1.1.Background

<This section summarizes the
rationale for the new product. Provide a general description of the
history or situation that leads to the recognition that this product
should be built.>

1.2.Business Opportunity

<Describe the market opportunity
that exists or the business problem that is being solved. Describe
the market in which a commercial product will be competing or the
environment in which an information system will be used. This may
include a brief comparative evaluation of existing products and
potential solutions, indicating why the proposed product is
attractive. Identify the problems that cannot currently be solved
without the product, and how the product fits in with market trends
or corporate strategic directions.>

1.3.Business Objectives and Success Criteria

<Describe the important business
objectives of the product in a way that is quantitative and
measurable. The value provided to customers is described in section
1.4, so this section should focus on the value provided to the
business. This could include estimates of revenue or cost savings,
return on investment analysis, or target release dates. Determine how
success will be defined and measured on this project, and describe
the factors that are likely to have the greatest impact on achieving
that 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.>

1.4.Customer or Market Needs

<Describe the needs of typical
customers or market segments, including needs that are not yet met by
the marketplace or by existing systems. You may wish to describe
problems customers currently encounter that the new product will (or
will not) address and how the product would be used by customers.
Identify the customer hardware and software environment in which the
product must operate. Define at a high level any known critical
interface or performance requirements. Avoid including any design or
implementation details. Present the requirements in a numbered list
so that more detailed user or functional requirements can be traced
to them.>

1.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.>

<This section establishes a
long-term vision for the system to be built to address the business
objectives. This vision will provide the context for making decisions
throughout the course of the product development life cycle. The
vision should not include detailed functional requirements or project
planning information.>

2.1.Vision Statement

<Write a concise vision statement
that summarizes the purpose and intent of the new product and
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 customers 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 customer
markets, enterprise architectures, organizational strategic
directions, and cost and resource limitations.>

2.2.Major Features

<Include a numbered list of the
major features of the new product, emphasizing those features that
distinguish it from previous or competing products. Specific user
requirements and functional requirements may be traced back to these
features.>

2.3.Assumptions and Dependencies

<Record any assumptions that were
made when conceiving the project and writing this vision and scope
document. Note any major dependencies the project must rely upon for
success, such as specific technologies, third-party vendors,
development partners, or other business relationships.>

<The project scope defines the
concept and range of the proposed solution. It’s also important to
define what will not be included in the product. Clarifying the scope
and limitations helps to establish realistic expectations of the many
stakeholders. It also provides a reference frame against which
proposed features and requirements changes can be evaluated. Proposed
requirements that are out of scope for the envisioned product must be
rejected, unless they are so beneficial that the scope should be
enlarged to accommodate them (with accompanying changes in budget,
schedule, and/or resources).>

3.1.Scope of Initial Release

<Describe the intended major
features that will be included in the initial release of the product.
Consider the benefits the product is intended to bring to the various
customer communities, and generally describe the product features and
quality characteristics that will enable it to provide those
benefits. Avoid the temptation to include every possible feature that
any potential customer category might conceivably want some day.
Focus on those features and product characteristics that will provide
the most value, at the most acceptable development cost, to the
broadest community.>

3.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.>

3.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.>

<This section summarizes some of
the business issues around the project, including profiles of major
customer categories, assumptions that went into the project concept,
and the management priorities for the project.>

4.1.Stakeholder Profiles

<Stakeholders are individuals,
groups, or organizations that are actively involved in a project, are
affected by its outcome, or can influence its outcome. The
stakeholder profiles identify the customers for this product and
other stakeholders, and states their major interests in the product.
Characterize business-level customers, target market segments, and
different user classes, to reduce the likelihood of unexpected
requirements surfacing later that cannot be accommodated because of
schedule or scope constraints. For each stakeholder category, the
profile includes the major value or benefits they will receive from
the product, their likely attitudes toward the product, major
features and characteristics of interest, and any known constraints
that must be accommodated. Examples of stakeholder value include:

improved productivity

reduced rework

cost savings

streamlined business processes

automation of previously
manual tasks

ability to perform entirely
new tasks or functions

conformance to current
standards or regulations

improved usability or reduced
frustration level compared to current applications

Example:>

Stakeholder

Major Value

Attitudes

Major Interests

Constraints

executives

increased
revenue

see
product as avenue to 25% increase in market share

richer
feature set than competitors; time to market

maximum
budget = $1.4M

editors

fewer
errors in work

highly
receptive, but expect high usability

automatic
error correction; ease of use; high reliability

must
run on low-end workstations

legal
aides

quick
access to data

resistant
unless product is keystroke-compatible with current system

ability
to handle much larger database than current system; easy to learn

no
budget for retraining

4.2.Project Priorities

<Describe the priorities among the
project’s requirements, schedule, and budget. The table below may
be helpful in identifying the parameters around the project’s key
drivers (top priority objectives), constraints to work within, and
dimensions that can be balanced against each other to achieve the
drivers within the known constraints. For more information, see
chapter 2 of Creating a Software
Engineering Culture by Karl E. Wiegers (Dorset House, 1996).
Examples:>

Dimension

Driver(state objective)

Constraint(state limits)

Degree of Freedom(state allowable range)

Schedule

release 1.0 to be available
by 10/1, release 1.1 by 12/1

Features

70-80% of high priority
features must be included in release 1.0

Quality

90-95% of user acceptance
tests must pass for release 1.0, 95-98% for release 1.1

Staff

maximum team size is 6
developers + 4 testers

Cost

budget overrun up to 15%
acceptable without executive review

4.3.Operating Environment

<Describe the environment in which
the system will be used and define the major availability,
reliability, performance, and integrity requirements. This
information will significantly influence the definition of the
system’s architecture. Consider questions such as:

Are the users widely distributed
geographically or located close to each other? How many time zones
are they in?

When do the users in various locations need
to access the system?

Where is the data generated and used? How
far apart are these locations? Does the data from multiple locations
need to be combined?

Are specific
maximum response times known for accessing data that might be stored
remotely?

Can the users
tolerate service interruptions or is continuous access to the system
critical for the operation of their business?

What access security controls and data
protection requirements are needed?>

Let’s block ads! (Why?)

Do you need any assistance with this question?
Send us your paper details now
We’ll find the best professional writer for you!

 



error: Content is protected !!