Lecture 4: Product Vision and Project

Scope
Requirements Management and Systems Engineering
(ITKS451), Autumn 2008

Artem Katasonov
University of Jyväskylä

University of Jyväskylä
 In the previous episode:
g Quality of requirements starts with providing basic training in RE for both
analysts and customers, and other strategic quality management activities
(“cleaning the kitchen”). Quality assurance (“keeping the lid closed”) and
quality control (“inspecting soup and removing bugs”) are important also, but
without knowledge will hardly be effective.

g The quality of requirements is usually defined with a set of factors, including

completeness, correctness, consistency, etc.

University of Jyväskylä
 In the previous episode (2):
g The most risky factor of all is completeness. Missing requirements are
difficult to detect, and software defects due to missing requirements are
usually very difficult to fix.
g In assuring or verifying the completeness of requirements, identifying all the
stakeholders of the software system is an important task. For this, orthogonal
3-dimensional framework (domain, system level, goal/means) is a useful tool.
Development domain Operation domain

supra-system:
system: Development system: supra-system1: supra-system2:
Project company Software Organization Society

Goals
Goals

Company
Sponsor Users Owners Subjects
owners

Means
Means

Company Maintenance Government,

Developers Management
management staff Police

University of Jyväskylä
 The first step

Business
Features
Requirements
Business
Rules

Vision and Scope Document

User Quality
Requirements Attributes

Use-Case Document
Constraints

System Functional
Requirements Requirements External
Interfaces

Software Requirements
Specification (SRS)

University of Jyväskylä
 Business requirements and vision (features)
g Business requirements – represent high-level objectives of the organization
or the customer requesting the system.
– Correspond to Jackson’s outer requirements.

g Features
– Provide the original abstract solution to the business requirements to be
later elaborated into specific requirements.
– Later used as bulleted items in the product description.
– Wiegers (2003): A feature is a set of logically related functional
requirements that provides a capability to the user and enables the
satisfaction of a business objective.. Why necessarily functional??
– A feature may look as a requirement of any type (user, functional,
external interface, etc.).

University of Jyväskylä
 Features
g Examples of features – Location-based restaurants information system for
mobile phones:
– Allows the user to search for restaurants in his/her present neighborhood, based
on restaurants’ attributes (user requirement).
– Automatically determines the user’s present location from the GSM network
(functional requirement).
– A request is handled in less than 2 seconds (quality attribute - performance)
– Written in JAVA (constraint).
– Restaurants data in Geography Markup Language 3.0 (external interface
requirement).
– Fully compliant with the EU privacy legislation (compliance to a business rule).

g Business requirements for such a system are e.g.:

– Help a city visitor to find quickly a restaurant according to his/her preferences.
– Get more customers for participating restaurants.
– Create revenues for the service provider and the mobile operator.

University of Jyväskylä
 Vision vs. scope
g Product Vision – a long-term strategic concept of the ultimate purpose and
form of a new system.
g Project Scope – the portion of the ultimate product vision that the current
project will address. The scope draws the line boundary what is in and what
is out for the current project.

Product Vision

Project Scope Project Scope Project Scope

for release 1.0 for release 1.1 … for release N

Wiegers, 2003

University of Jyväskylä
 Project priorities
g To enable effective decision making, stakeholders should agree on the project
priorities.
g 5 main dimensions of a software project: features (scope), quality,
schedule, cost, and staff.
g Those must be classified into one of the following categories:
– Constraint – a limiting factor within which the project manager must
operate.
– Driver – a significant success objective with limited flexibility for
adjustment.
– Degree of freedom – a factor that the project manager has some latitude
to adjust and balance against the other dimensions.
g The project manager can then to adjust, if needed, those factors that are
degrees of freedom to achieve the project’s success drivers within the limits
imposed by the constraints.
Wiegers, 2003

University of Jyväskylä
 Project priorities (2)
Dimension Driver Constraint Degree of Freedom
(state objective) (state limits) (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

K. Wiegers
9

University of Jyväskylä
 Project priorities (3)
g In practice, often:
– Features and schedule are drivers, staff and cost are constraints..
– .. quality is forced to be a degree of freedom.

© Juba
- Juba Production Oy - From now on, balloons - And drawings will be
has decided to will be typed by some made by some middle-
outsource production of communication agency size engineering office
this comic strip. from Kankaanpää. from Joensuu.
- F.. Juba!

10

University of Jyväskylä
 Vision and scope document
g Karl Wiegers’ web-site - http://www.processimpact.com/goodies.shtml
g The vision and scope document template and an example

11

University of Jyväskylä
 Vision and scope document (2)
g Wiegers’ proposition for the structure of the vision and scope
document:
1. Business Requirements
1.1. Background
1.2. Business Opportunity
1.3. Business Objectives and Success
Criteria
1.4. Customer or Market Needs
1.5. Business Risks
2. Vision of the Solution
2.1. Vision Statement
2.2. Major Features
2.3. Assumptions and Dependencies
3. Scope and Limitations
3.1. Scope of Initial Release
3.2. Scope of Subsequent
Releases
3.3. Limitations and Exclusions
4. Business Context
4.1. Stakeholder Profiles
4.2. Project Priorities
4.3. Operating Environment

12

University of Jyväskylä
 Recall: Bergman et al. formalism (Lecture 2)
“Objective” requirements “Constraining”
- business (outer) requirements - inner

Bergman, King, and Lyytinen, 2002

13

University of Jyväskylä
 1.1. Background
g Provides a general description of the history or situation that leads to the
recognition that this product should be built.

g Is a description of the current solution space (as in Bergman, King, and

Lyytinen, 2002, see Lecture 2).

g Example:
A majority of Process Impact employees presently spend an average of 60 minutes
per day going to the cafeteria to select, purchase, and eat lunch. About 20 minutes
of this time is spent walking to and from the cafeteria, selecting their meals, and
paying for their meals by cash or credit card. When employees go out for lunch,
they spend an average of 90 minutes off-site. Some employees phone the cafeteria
in advance to order a meal to be ready for them to pick up.

14

University of Jyväskylä
 1.2. Business opportunity
g Describes the market opportunity that exists or the business problem that is
being solved. Identifies the problems that cannot currently be solved without
the product.

g Is a description of the proposed problem space (as in Bergman, King, and

Lyytinen, 2002).

g Example:
Working time is wasted. Also, employees don’t always get the selections they want
because the cafeteria runs out of certain items. The cafeteria wastes a significant
quantity of food that is not purchased and must be thrown away.

15

University of Jyväskylä
 1.3. Business objectives and success criteria
g Describes the important business objectives of the product in a way that is
quantitative and measurable. Focuses on the value provided to the business.

g A part of business (outer) requirements, those relevant to business

stakeholders.

g Example:
– BO-1: Reduce cafeteria food wastage by 50% .
– BO-2: Reduce cafeteria operating costs by 15%.
– BO-3: Increase average effective work time by 20 minutes per employee per day.
– SC-1: Have 75% of those employees who presently use the cafeteria use the
Cafeteria Ordering System within 6 months following initial release.
– SC-2: Achieve an increase in the average rating on the quarterly cafeteria
satisfaction survey of 0.5 within 3 months following initial release.

16

University of Jyväskylä
 1.4. Customer or market needs
g Describes the needs of typical customers or market segments, including
needs that are not yet met by the marketplace or by existing systems.

g A part of outer (business) requirements, those relevant to users.

g Example:
– Employees request a system that would permit a cafeteria user to order meals on-
line, to be delivered to a designated company location at a specified time and date.
Such a system would save those employees who use the service considerable time
and it would increase the chance of them getting the food items they prefer.
– The future ability for employees to order meals for delivery from local restaurants
would make a wider range of choices available to employees and provides the
possibility of cost savings through volume purchase agreements with the
restaurants.

17

University of Jyväskylä
 1.5. Business risks
g Summarizes 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.

g Analysis of potential conflicts between business requirements of different

stakeholders.

g Example:
– RI-1: The Cafeteria Employees Union might require that their contract be renegotiated to reflect
the new employee roles and cafeteria hours of operation. (Probability = 0.6; Impact = 3).
– RI-2: Too few employees might use the system, reducing the return on investment from the
system development and the changes in cafeteria operating procedures. (Probability =0.3;
Impact = 9).
– RI-3: Local restaurants might not agree to offer price reductions to justify employees using the
system, which would reduce employee satisfaction with the system and possibly their usage of
it. (Probability = 0.4; Impact = 3).

18

University of Jyväskylä
 2.1. Vision statement
g Summarizes the purpose and intent of the new product and describes what
the world will be like when it includes the product.

g Is an abstract description of the proposed solution space (as in Bergman,

King, and Lyytinen, 2002).

g The following keyword template may be used:

– For [target user]
– 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 competing system, or current state of practice]
– Our product [statement of primary differentiation and advantages]

19

University of Jyväskylä
 2.1. Vision statement (2)
g Example:

For employees who wish to order meals from the company cafeteria or from
local restaurants on-line, the Cafeteria Ordering System is an Internet-
based application that will accept individual or group meal orders,
process payments, and trigger delivery of the prepared meals to a
designated location on the Process Impact campus. Unlike the current
telephone and manual ordering processes, employees who use the
Cafeteria Ordering System will not have to go to the cafeteria to get their
meals, which will save them time and will increase the food choices
available to them.

20

University of Jyväskylä
 2.2. Major features
g A numbered list of the major features of the product, emphasizing those
features that distinguish it from previous or competing products.

g Example:
– FE-1: Order meals from the cafeteria menu to be picked up or delivered
– FE-2: Order meals from local restaurants to be delivered
– FE-3: Create, view, modify, and delete meal service subscriptions
– FE-4: Register for meal payment options
– FE-5: Request meal delivery
– FE-6: Create, view, modify, and delete cafeteria menus
– FE-7: Order custom meals that aren’t on the cafeteria menu
– FE-8: Produce recipes and ingredient lists for custom meals from cafeteria
– FE-9: Provide system access through corporate Intranet or through outside Internet
access by authorized employees

21

University of Jyväskylä
 2.3. Assumptions and dependencies
g Explicitly states assumptions that were made when conceiving the project.
Note any major dependencies the project must rely upon for success, such as
specific technologies, third-party vendors, development partners, or other
business relationships.

g Similar to “business risks”, but about the inner requirements

g Example:
– AS-1: Intranet-enabled computers and printers will be available in the cafeteria to
permit cafeteria employees to process the expected volume of orders without
missing any delivery time windows.
– AS-2: Cafeteria staff and vehicles will be available to deliver all orders within 15
minutes of the requested delivery time.
– DE-1: If a restaurant has its own on-line ordering system, the Cafeteria Ordering
System must be able to communicate with it bidirectionally.

22

University of Jyväskylä
 All the components
1.1. Background 1.2. Business 2.1. Vision
Opportunity Statement

1.3. Business Objectives

2.2. Major Features
1.4. Customer Needs

1.5. Business Risks 2.3. Assumptions

23

University of Jyväskylä
 3. Scope and limitations

g 3.1. Scope of Initial Release - the intended major features that will be included
in the initial release of the product
g 3.2. Scope of Subsequent Releases - if a staged evolution of the product is
envisioned over time, describes which major features will be deferred to later
releases.
g 3.3. Limitations and Exclusions - describes product features or characteristics
that a stakeholder might anticipate, but which are not planned to be included
in the new product.

g Example of limitations:
– LI-1: Some food items that are available from the cafeteria will not be suitable for
delivery, so the menus available to patrons of the Cafeteria Ordering System will be
a subset of the full cafeteria menus.
– LI-2: The Cafeteria Ordering System shall be used only for the cafeteria at the main
Process Impact campus in Clackamas, Oregon.

24

University of Jyväskylä
 3. Scope and limitations (2)
Feature Release 1
FE-1 Standard meals from lunch
menu only; delivery orders
may be paid for only by
payroll deduction
FE-2 Not implemented
FE-3 Implemented if time
permits (medium priority)
FE-4 Register for payroll
deduction payments only
FE-5 Meals will be delivered only
to company campus sites
FE-6 Fully implemented
FE-7 Not implemented
FE-8 Not implemented
FE-9 Fully implemented
University of Jyväskylä
Release 2 Release 3
Accept orders also for breakfasts
and dinners; accept credit and
debit card payments
Not implemented Fully implemented
Fully implemented
Register for credit card and debit
card payments
Add delivery from cafeteria to
selected off-site locations
Not implemented Fully implemented
Fully implemented
25
 4.1. Stakeholder profiles
g Attempts to identify all the different stakeholders for the product, and states
their major interests in the product.
g For identification, orthogonal 3-dimensional framework (domain, system level,
goal/means), discussed in Lecture 3, may be used.
g Then, for each identified stakeholder, 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.
g Example of a profile:

Stakeholder Major Value Attitudes Major Interests Constraints

Users Better food Strong enthusiasm, but Simplicity of use; Access to
selection; might not use it as much as reliability of corporate
time expected because of social delivery; Intranet is
savings; value of eating lunches in availability of food needed
convenience cafeteria and restaurants choices

26

University of Jyväskylä
 Other sections

g 4.2. Project Priorities – defines which of project dimensions are drivers,

constraints, and degrees of freedom. Discussed earlier.

g 4.3. Operating Environment - describes the environment in which the system

will be used.
– States requirements of “constraints” and “external interfaces” types, if any are
known at this stage.

27

University of Jyväskylä
 Scope management
g Product vision is relatively static. It changes slowly as a product’s strategic
positioning and business objectives evolve over time.

g In contrast, scope is more dynamic. It needs to be adjusted within existing

schedule, budget, resource, and quality constraints. The customer’s idea
about which features are more important also tends to change.

g Scope creep is undesirable. Scope creep is a condition in which the scope of

the project continues to increase, typically in an uncontrolled fashion,
throughout the development process.

g Therefore, explicit documentation of the project scope and scope

management (i.e. making changes to the scope in a controlled way) are
important.

28

University of Jyväskylä
 Scope management (2)

Scope Initiation - selecting among possible alternative projects

- writing the scope statement, e.g. in a vision and

Scope Planning scope document

Scope Definition - decomposition of the project into tasks sufficiently

detailed for estimating required time, cost, resources

Scope Verification - review and acceptance of the project scope

Scope Change - as the project goes on, making changes to the scope
Control in a controlled way

Schwalbe, 2003

29

University of Jyväskylä
 Project selection
g Different possible sets of features to
implement may be seen as alternative
projects – need to select one.

g In general, it is recommended to select

projects with high benefit and low cost and
risk.

g A Weighted Scoring Model (WSM) is a tool that allows systematic

selection among projects based on multiple criteria:
– Identify criteria important to the project selection process,
– Assign weights (in percents) to each criterion so they add up to 100%,
– Assign scores to each criterion for each project,
– Multiply the scores by the weights and sum them up,
– The project with the highest total score wins.
Schwalbe, 2003

30

University of Jyväskylä
 Project selection (2)

Schwalbe, 2003
31

University of Jyväskylä
 Project decomposition
g The Work Breakdown
Structure (WBS) - an
outcome-oriented analysis
of the work involved in a
project.
– Graphic portrayal of the
project scope
– Basis for planning and
managing project
schedules and costs

Schwalbe, 2003

32

University of Jyväskylä
 Activity Sequencing
g Needed for estimating the required time for completing the project
g Involves analysis of dependencies between activities
g Activity-on-Arrow (AOA) Network Diagram may be utilized for graphic
representation

“A=1” means that activity A is going to take 1 day

Schwalbe, 2003

33

University of Jyväskylä
 Lecture 4: Main points
g RE, and a software/system development project as such, starts with defining
business requirements, and a vision of the solution, consisting of set of
features enabling satisfaction of those business requirements.

g Those are documented in the project’s vision and scope document.

g Vision and scope document should also include the stakeholders analysis
and a definition of project priorities.

g Project scope is the portion of the ultimate product vision that the current
project will address. Definition of the scope should be based on quantitative
analysis (using e.g. WSM, WBS, AOA): implementation of which portion of
the vision will be the most cost-effective, and whether it is possible to
implement it under given constraints on schedule and budget.

34

University of Jyväskylä
 Following next:

g Requirements elicitation, including:

g Finding voice of users..

g Interpreting users’ input..

g Use Case analysis..

g Wagner falls a victim to an overlooked

exception in a use case..
© Juba

35

University of Jyväskylä