SEG3101 (Fall 2010)

Requirements Inception

Gregor v. Bochmann, University of Ottawa

Based on Powerpoint slides by Gunter Mussbacher
with material from:
Wiegers: Software Requirements, Chapter 5
Leffingwell & Widrig: Managing Software Requirements…, Chapter 5
Table of Contents
• Problem Analysis
• Business Requirements
• Five Steps for Problem Analysis
• Gain Agreement on the Problem Definition
• Understand the Root Causes
• Identify the Stakeholders
• Product Vision and Project Scope
• Identify the Constraints

• Vision and Scope Document

• The important thing is not to stop questioning. Curiosity has

its own reason for existing.1
[1] Albert Einstein (1879 - 1955)
2
SEG3101 (Fall 2010). Requirements Inception.
 3
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis
• Goal: gain a better understanding of the problem being
solved before development begins
• Identify root cause
• Identify stakeholders and their needs (or problems)
• Identify solution boundary

• Uses business requirements obtained from stakeholders

• Results in Product Vision and Project Scope

4
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Business Requirements (1)

• Business Opportunity
• Description of market opportunity, competing market, business
problem being solved or improved, advantage of proposed solution,
problems that will be solved...
• Business Objective and Success Criteria
• Important business benefits the product will provide in a quantitative
and measurable way, how success will be measured, factors that have
great impact on success...
• Customer or Market Needs
• Problems that customers currently encounter that will be addressed
• Business Risks
• Major risks associated with developing or not developing the product
(marketplace competition, timing, user acceptance, implementation
issues...)

5
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Business Requirements – Example

• Business Opportunity
• Exploit the poor security record of a competing product

• Business Objective and Success Criteria

• Capture a market share of 80 percent by being recognized as the most
secure product in the market through trade journal reviews and
consumer surveys
• Achieve positive cash flow on the product within 6 months

6
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Business Requirements (2)

• Important for:
• Ensuring that all project participants work for the same reasons
• Getting stakeholders agreement on requirements

• User and software requirements must align with the context

and objective defined by business requirements

• Requirements that do not help achieve business objective

should not be included

7
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Five Steps

• Leffingwell and Widrig propose five steps for problem
analysis
• Gain agreement on the problem definition
• Understand the root causes – the problem behind the problem
• Identify the stakeholders
• Define the solution system vision and boundary
• Identify the constraints to be imposed on the solution

8
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Gain Agreement

• Document the problem and seek agreement
• Ask stakeholders to write a problem statement in an agreed format
• Statement should include
• What the problem is
• Who is affected by it?
• What is the impact?
• Is there a proposed solution?
• What are key benefits?

9
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Understand Root Causes (1)

• There is often a problem behind the problem
• Root cause analysis consists of finding underlying causes
that may not be immediately apparent

• Example: Our e-commerce site is not profitable

• Why is it not profitable?
• Poor site design?
• Bad pricing?
• Poor customer management after the sale?
• Some or all of the above?

10
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Understand Root Causes (2)

• Root cause analysis can be used to understand root causes
• Determine what factors contribute to the problem (sub-problems)
• Recursively determine what factors contribute to these problems
• Decompose until causes are understood (possible solution
clear)
• Decomposition can be represented using a Fishbone diagram, an
itemized list...

Source: Leffingwell & Widrig

11
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Understand Root Causes (3)

• Address Root Causes
• Root causes do not all have same impact
• Some may not be worth fixing, at least not now
• Estimate relative impact of root causes (e.g., with the help of
a Pareto (bar) chart)

• Create problem
statement for root
cause problem
identified as worth
solving (and with
computer solution)

Source: Leffingwell & Widrig

12
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Statement

Source: Leffingwell & Widrig

13
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Stakeholder Profiles (1)

• Stakeholder Profiles
• Stakeholders are individuals, groups, organizations who are actively
involved in the project, are affected by its outcome or are able to
influence its outcome
• Profile should include:
• Major value or benefit that stakeholder will receive from product (e.g.,
improved productivity, reduced rework, cost saving, ability to perform new
tasks...)
• Likely attitude toward the product
• Major features and characteristics of interest
• Any known constraints that must be accommodated

14
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Stakeholder Profiles (2)

• How to identify Stakeholders?

• Elicitation would ask questions such as

• Who uses the system?
• Who is the customer?
• Who is affected by outputs?
• Who evaluates/approves system?
• Other external/internal users?
• Who maintains the system?
• Anyone who cares? (e.g., legal/regulatory, etc.)

15
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Product Vision and Project Scope

• Product Vision: describes what the product is about and what
it could eventually become
• Aligns all stakeholders in a common direction

• Project Scope: identifies what portion of the ultimate long-

term product vision the current project will address
• Draws boundary between what is in and what is out

Product Vision

Project Scope Project Scope Project Scope

…..
for release 1.0 for release 1.1 for release n

16
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Vision Statement (1)

• Vision Statement template (according to Moore)
• 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]

17
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Vision Statement (2)

• Example
• 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 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 location and usage. This system will save
the company 25% 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 government regulations that require the
reporting of chemical usage, storage, and disposal.

18
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Definition of Scope (1)

• Definition of solution system boundaries
• Requirements baseline is defined according to the release
scope

• New requirements during development are evaluated

according to the scope
• New in-scope requirements can be incorporated if they are of
high priority relative to the other requirements in the baseline
• Usually implies deferring or canceling other requirements or negotiating a
new schedule
• Out-of-scope requirements should be deferred to a following release

19
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Definition of Scope (2)

• Context Diagram
• Top-level view of a system that shows the system’s boundaries and
scope
• Identifies terminators outside the system
• Data, control, and material flow between terminators and the system

Source: Leffingwell & Widrig

20
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Problem Analysis – Identify Constraints

• Restrictions on the solution space
• Put limitations on the ability to deliver a solution as envisioned
• Usually non-functional requirements that impose major restrictions on
the system
• Sources of constraints include:
• Economics (e.g., costs, licensing issues)
• Politics (e.g., internal or external, interdepartmental issues)
• Technology (e.g., choice of technology/platform)
• Systems (e.g., existing system, compatibility issues)
• Environment (e.g., legal/environmental/security/standards)
• Schedule and resources (e.g., fixed schedule, team)

21
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Vision and Scope Document (1)

• Contents:
• Business requirements
• Vision of the solution
• Vision statement
• Major features (numbered list of major features or user capabilities unique
to the new product)
• Assumptions (made while developing vision and scope)
• Major dependencies to external factors outside of the project’s control
(e.g., pending industry standards, government regulations, other projects,
third party suppliers, development partners)
• Scope and limitation (for initial and subsequent releases)
• Business context

22
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Vision and Scope Document (2)

• Contents – Scope and limitations:
• Concept and range of proposed solution
• What the system is
• Limitations
• Capabilities that the product won't include (what the system is not)
• Record rejected requirements with the reason for rejecting them
• Scope of initial release
• Major features planned for initial release
• Acceptable quality characteristics of initial release
• Scope of subsequent releases

23
SEG3101 (Fall 2010). Requirements Inception.
Problem Analysis Business Requirements Agreement Root Causes Stakeholders Vision & Scope Constraints Document

Vision and Scope Document (3)

• Contents – Business context:
• Project Priorities
• Stakeholders must agree on the project priorities
• Help effective decision making
• Operating Environment
• Environment in which system will be used (e.g., distributed environment)
• Vital availability, reliability, performance and integrity requirements linked
to operating environment

24
SEG3101 (Fall 2010). Requirements Inception.