Software Requirements &

Specifications

Chapter 5:
Establishing the Product Vision and
Project Scope
Overview
• The business requirements represent the top level of abstraction
in the requirements chain: they define the vision and scope for
the software system.
• The user requirements and software functional requirements must
align with the context and objectives that the business
requirements establish.
• Requirements that don't help the project achieve its business
objectives shouldn't be included.
• The stakeholders will never agree on the requirements if they lack
a common understanding of the business objectives for the
product.
• A clear vision and scope is especially critical for multisite
development projects, where geographical separation inhibits the
day-today interactions that facilitate teamwork.
Overview
• One sign that the business requirements are insufficiently defined
is that certain features are initially included, then deleted, and
then added back in later.
• Some companies print the vision and scope highlights on a poster
board that's brought to every project meeting so that they can
quickly judge whether a proposed change is in or out of scope.
Defining the Vision Through Business
Requirements
• The product vision aligns all stakeholders in a common direction.
• The vision describes what the product is about and what it
eventually could become.
• The project scope identifies what portion of the ultimate long
term product vision the current project will address.
• The statement of scope draws the boundary between what's in
and what's out. That is, the scope also defines the project's
limitations.
• The details of a project's scope are represented by the
requirements baseline that the team defines for that project.
• The vision applies to the product as a whole.
• The scope pertains to a specific project or iteration.
• Scope is more dynamic than vision
• The planner's goal is to manage the scope of a specific
development or enhancement project as a defined subset of the
grand strategic vision.
Defining the Vision Through Business
Requirements Cont’d
• The product vision encompasses the scope for each planned
release.

>>> >>> >>>

Business Requirements and Use Cases

• The business requirements determine both the set of business

tasks (use cases) that the application enables (the application
breadth) and the depth or level to which each use case is
implemented.
• If the business requirements help you determine that a particular
use case is outside the project's scope, you're making a breadth
decision.
• The depth of support can range from a trivial(minor)
implementation to full automation with many usability aids.
• The business requirements influence the implementation priorities
for use cases.
Vision and Scope Document
• The vision and scope document collects the business
requirements into a single document that sets the stage for the
subsequent development work.
• Template for a vision and scope document:
Vision and Scope Document
1. Business Requirements
• The business requirements describe the primary benefits that the
new system will provide to its sponsors, buyers, and users.
1.1 Background
• Provide a general description of the history or situation that led to
the decision to build this product.
1.2 Business Opportunity
• For a commercial product, describe the market opportunity that
exists and the market in which the product will be competing.
• For a corporate information system, describe the business
problem that is being solved
• Include a comparative evaluation of existing products
• Describe the problems that cannot currently be solved without the
product.
Vision and Scope Document Cont’d
1.3 Business Objectives and Success Criteria
• Summarize the important business benefits the product will provide
in a quantitative and measurable way.
• Determine how the stakeholders will define and measure success on
this project
• Example of financial and non-financial business objectives:
— Financial: Capture a market share of X% within Y months.
— Non-Financial: Be rated as the top product for reliability in
published product reviews by a specified date.
1.4 Customer or Market Needs
• Describe the needs of typical customers or of the target market
segment, including needs that current products or information
systems do not meet.
1.5 Business Risks
• Summarize the major business risks associated with developing—or
not developing—this product.
• Estimate the potential loss from each risk
• Identify any potential mitigation actions.
Vision and Scope Document Cont’d
2. Vision of the Solution
• It should not include detailed functional requirements or project
planning information.
2.1 Vision Statement
• The following keyword template works well for a product vision
statement:
— For [target customer]
— Who [statement of the need or opportunity]
— The [product name]
— Is [a product category]
— That [key benefit, compelling reason to buy or use]
— Unlike [primary competitive alternative, current
system, or current business process],
— Our product [statement of primary differentiation and
advantages of new product].
Sample Vision Statement
Sample Vision Statement for Chemical Tracking System
project :

For scientists who need to request containers of chemicals, the

Chemical Tracking System is an information system that will
provide a single point of access to the chemical stockroom and to
vendors. The system will store the location of every chemical
container within the company, the quantity of material remaining
in it, and the complete history of each container's locations and
usage. This system will save the company 25 percent on chemical
costs in the first year of use by allowing the company to fully
exploit chemicals that are already available within the company,
dispose of fewer partially used or expired containers, and use a
single standard chemical purchasing process. Unlike the current
manual ordering processes, our product will generate all reports
required to comply with federal and state government regulations
that require the reporting of chemical usage, storage, and
disposal.
Vision and Scope Document Cont’d
2.2 Major Features
• Name or number each of the new product's major features or
user capabilities
• Giving each feature a unique label (as opposed to a bullet)
permits tracing it to individual user requirements, functional
requirements, and other system elements.
• 2.3 Assumptions and Dependencies
• Record any assumptions that the stakeholders made when
conceiving the project and writing this vision and scope
document.
• Also record major dependencies the project has on external
factors outside its control.

(NEXT: 3. Scope and Limitations)

Vision and Scope Document Cont’d
3. Scope and Limitations
• A software project should define its scope and limitations. You
need to state both what the system is and what it is not.
• The project scope defines the concept and range of the proposed
solution.
• Out-of-scope requirements must be rejected unless they are so
valuable that the scope should be enlarged to accommodate
them, with corresponding changes in budget, schedule, and staff.
• Keep a record of rejected requirements and why they were
rejected because they have a way of reappearing.
3.1 Scope of Initial Release
• Summarize the major features that are planned for inclusion in
the initial release of the product.
• If your goals are to focus the development effort and to maintain
a reasonable project schedule, avoid the temptation to include in
release 1.0 every feature that any potential customer might
conceivably want someday. (Cont’d)
Vision and Scope Document Cont’d
3.1 Scope of Initial Release Cont’d
• Bloatware and slipped schedules are common outcomes of such
insidious scope creep.
• Focus on those features that will provide the most value e.g.
Version-1 need not to be fast, pretty, or easy to use, but perhaps
it has to be reliable…
3.2 Scope of Subsequent Releases
• Indicate which features will be deferred and the desired timing of
later releases.
• Subsequent releases let you implement additional use cases and
features and enrich the capabilities of the initial use cases and
features.
• You can also improve system performance, reliability, and other
quality characteristics as the product matures.
Vision and Scope Document Cont’d
3.3 Limitations and Exclusions
• Defining the boundary between what's in and what's out is a way
to manage scope creep and customer expectations.
• List any product capabilities or characteristics that a stakeholder
might anticipate but that are not planned for inclusion in the
product or in a specific release.
4. Business Context
• This section summarizes some of the project's business issues,
including profiles of major stakeholder categories and
management's priorities for the project.
4.1 Stakeholder Profiles
• Stakeholders are the individuals, groups, or organizations who
are actively involved in a project, are affected by its outcome, or
are able to influence its outcome.
• The stakeholder profiles describe different categories of
customers and other key stakeholders for this project.
• You needn't describe every stakeholder group (Cont’d)
Vision and Scope Document Cont’d
4.1 Stakeholder Profiles Cont’d
• Each stakeholder profile should include the following information:
— The major value or benefit that the stakeholder will receive
from the product and how the product will generate high
customer satisfaction. Stakeholder value might include:
– Improved productivity.
– Reduced rework.
– Cost savings.
– Automation of previously manual tasks.
— Their likely attitudes toward the product.
— Major features and characteristics of interest.
— Any known constraints that must be accommodated.

>>> >>> >>>

Vision and Scope Document Cont’d
4.2 Project Priorities
• The stakeholders must agree on the project's priorities.
• Consider the five dimensions of a software project: features (or
scope), quality, schedule, cost, and staff.
• Each dimension fits in one of the following three categories on
any given project:
— A constraint A limiting factor within which the project
manager must operate
— A driver A significant success objective with limited flexibility
for adjustment
— A degree of freedom A factor that the project manager has
some latitude (freedom) to adjust and balance against the
other dimensions /Cont’d
Vision and Scope Document Cont’d
4.2 Project Priorities Cont’d
• The project manager's goal is to adjust those factors that are
degrees of freedom to achieve the project's success drivers within
the limits imposed by the constraints.
• The project manager needs some degrees of freedom to be able
to respond appropriately when project requirements or realities
change.
• Suppose marketing suddenly demands that you release the
product one month earlier than scheduled.
• How do you respond?
— Defer certain requirements to a later release?
— Shorten the planned system test cycle?
— Pay your staff overtime or hire contractors to accelerate
development?
— Shift resources from other projects to help out?
• The project priorities dictate the actions you take when such
eventualities arise.
Vision and Scope Document Cont’d
4.3 Operating Environment
Describe the environment in which the system will be used
• Ask the stakeholders questions such as the following:
— Are the users widely distributed geographically or located
close to each other? How many time zones are they in?
— Where is the data generated and used? How far apart are
these locations? Does data from multiple locations need to be
combined?
— Can the users tolerate service interruptions or is continuous
access to the system critical for the operation of their
businesses?
— What access security controls and data protection
requirements are needed?
The Context Diagram
• The scope description establishes the boundary and connections
between the system 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 flows between
the terminators and the system.
• You can include the context diagram in the vision and scope
document, in or as an appendix to the SRS

(Diagram on next Slide)

The Context Diagram Cont’d
The Context Diagram Cont’d
• The entire system is depicted as a single circle
• The "system" inside the circle could encompass any combination
of software, hardware, and human components.
• The terminators in the rectangles can represent user classes,
organizations, other systems, or hardware devices
• The arrows on the diagram represent the flow of data between
the system and the terminators.
• Suppose you were to use a triangle for the system instead of a
circle and ovals rather than rectangles for terminators. Your
colleagues would have difficulty reading a diagram that follows
your personal preferences rather than a team standard.
Keeping the Scope in Focus
• Whenever someone requests a new requirement, the analyst
needs to ask, "Is this in scope?“
• You can incorporate new in-scope requirements in the project if
they are of high priority relative to the other requirements that
were already committed.
— Including new requirements often involves making a decision
to defer or cancel other planned requirements.
• If new requirement is out of scope but it's such a good idea that
the project scope should be modified to accommodate it.
— Will require that you update the vision and scope document
— You will usually have to renegotiate the planned budget,
resources, schedule, and perhaps staff
— Quality often suffers if the allocated resources or time are not
increased when new functionality is added.
(End)