Software Requirements

Engineering

Lecture: 04
 Overview of Lecture 3
Content of Lecture
• Six Team Skills
• Analyzing the Problem
• Understanding User and Stakeholder Needs
• Defining the System
• Managing Scope
• Refining the System Definition
• Building the Right System
• The Case Study – HOLIS
• Characteristics of INDIVIDUAL Requirement Statements
• Characteristics of Requirement Specification SET (SRS)
 Sequence [Todays Agenda]
Content of Lecture
• Requisite Team Skills for Effective Requirements Management
• Team Skill1 - Analyzing the Problem
• Definition of Problem & Problem Analysis
• How to address the problem:
• Step 1: Gain agreement on the problem definition
• Step 2: Understand the root causes
• Step 3: Identify the stakeholders and the users
• Step 4: Define the solution system boundary.
• Step 5: Identify constraints to be imposed on the solution
• Key Points
Requirement Engineering

Analyzing the Problem

(Team Skill 1)

Textbook – Chapters 5

Managing Software Requirements: A Use Case Approach, Second Edition, By

Dean Leffingwell, Don Widrig
4
Requisite Team Skills for Effective
Requirements Management
• Effective requirements engineering can be
accomplished only via an effective software
team.
• Six Team skills that are necessary for a modern
software team to successfully address the
requirements challenge
— Team Skill 1, Analyzing the Problem
— Team Skill 2, Understanding User and Stakeholder
Needs
— Team Skill 3, Defining the System
— Team Skill 4, Managing Scope
— Team Skill 5, Refining the System Definition
— Team Skill 6, Building the Right System
Team Skill1 - Analyzing the Problem
Facts
• There is a history of poorly understanding
and satisfying user needs.

• Development teams spend too little time

for understanding the real business
problems

• Development teams tend to move ahead,

providing solutions based on an
inadequate understanding of the problem
to be solved
Agenda

• Definition of Problem & Problem Analysis

• How to address the problem:

—Step 1: Gain agreement on the problem definition
—Step 2: Understand the root causes
—Step 3: Identify the stakeholders and the users
—Step 4: Define the solution system boundary.
—Step 5: Identify constraints to be imposed on the
solution

7
Definitions
• Problem is not necessarily something wrong.
• Problem is gap between the way things are
and the way we would like things to be.
• Problem is a gap between current and
desired state

Problem is:
the difference between things as
perceived and things as desired
8
Definitions
Problem Analysis is:
the process of understanding real-
world problems and user needs and proposing
solutions to meet those needs
• The goal of problem analysis is to gain a
better understanding of the problem being
solved before development begins
• The steps to achieve the goal
1. Gain agreement on the problem definition
2. Understand the root causes—the problem behind
the problem
3. Identify the stakeholders and the users.
4. Define the solution system boundary.
5. Identify the constraints to be imposed on the
solution 9
Step 1: Gain Agreement on the Problem
Definition

• To gain agreement:
Write Down the Problem Definition – does
everyone agree?

10
Sample Problem Statement (Lumenations)
Step 2: Understanding the Root Causes

• Once you have an understanding of the

larger problem, your team can use a
variety of techniques to gain an
understanding of its causes.

• One such technique is root cause analysis,

which is a systematic way of uncovering
the root, or underlying, cause of an
identified problem or a symptom of a
problem

12
Step 2: Understanding the Root Causes

• Root Cause Analysis

—basic and contributing causes are discovered in a
process similar to diagnosis of disease.
• The goal is to find out:
—what happened
—why did it happen
—what do you do to prevent it from happening
again.

13
Understanding the Root Causes

• OK, so how do you determine the root causes?

• Well, it just depends
— In many cases, it's a simple matter of asking the people
directly involved
— If the problem is more serious, it may be necessary to
perform a detailed investigation of each contributing
problem and to quantify its individual impact
• So, when the causes are determined, a question:
are all the causes worth fixing?
— cost of the fix exceeds the cost of the problem?
• which ones to fix?

14
GoodsAreUs: Problem behind the
Problem?...

Problem: insufficient profitability

• Total Quality Management (TQM)
technique =>
—Cause 1: the problem is due to the high cost
of nonconformance - cost of all the things that go
wrong and produce waste, scrap, and other excess costs
– Cause 1.1: Largest contributor is Excess Scrap

• The problem behind the problem in scrap?

15
 Understanding the Root Causes (cont.)

• TQM Technique: Fishbone Diagram

—Ask the people!
• GoodsAreUs: sources contributing to the
too much
scrap ?...

Are all “bones”

contributing
equally to the
excess scrap?

16
 Addressing THE Root Cause
• Determine the contribution of each
cause
• Technique: Pareto Chart
• GoodsAreUs: Quality data demonstrates that
many root causes are simply not worth fixing

The existing sales

order system is a
poor legacy code

17
 The Root Causes and The Possible
Solution
• Solution : replacement for the existing sales
order entry system

18
 Step 2: Output Example

• GoodsAreUs:

• Give to the stakeholders for comments and

feedback
19
Step 3: Identify the Stakeholders and the
Users

• Stakeholder:
—Anyone who could be materially affected by the
implementation of a new system or application
—Many stakeholders are users of the system, and
their needs are easy to focus on
—However, some stakeholders are only indirect
users
• Non-user stakeholder needs must also be
identified and addressed

20
 Step 3: Identify the Stakeholders and the
Users
• How we identify stakeholders?

• Ask questions:
— Who are the users of the system?
— Who is the customer (economic buyer) for the system?
— Who else will be affected by the outputs the system produces?
— Who will evaluate and approve the system when it is deployed?
— Are there any other internal or external users of the system
whose needs must be addressed?
— Who will maintain the new system?
— Is there anyone else who cares?

21
Step 4: Define the Solution System
Boundary

• System Boundary:
—defines the border between the Solution (our
system) and the Real World (things that interact
with our system)
• Technique:
—Identify the Input/Output information

in System out

22
 Identify the Actors: Key Analytical Step!

• Actor:
—someone or
something outside
the system that
interacts with the
system
—Plays a ROLE in
making our system
to do its things

23
How to identify the actors?

• The following questions might be helpful:

—Who will supply, use, or remove information
from the system?
—Who will operate the system?
—Who will perform any system maintenance?
—Where will the system be used?
—What other external systems will interact with
the system?

24
 Step 4 Output: System Perspective

• A block diagram that describes the boundaries

of the system, the users, and other interfaces
• GoodsAreUs :

25
Step 5: Identify the Constraints to be
Imposed on the Solution

• Constraint: A restriction on the degree of freedom

we have in providing a solution
• Constraint has the potential to severely restrict our
ability to deliver a solution as we envision it
• A variety of sources of constraints must be
considered – e.g.
— schedule,
— political issues within the
— return on investment,
organization,
— budget for labor and
— company policies and procedures,
equipment,
— choices of tools and languages,
— environmental issues,
— personnel or other resource
— operating systems,
constraints
— databases

26
Step 5: Identify the Constraints to be
Imposed on the Solution
• If we have to elicit, it would be helpful to know
what kinds of things we should be looking for

• Table below lists potential sources of system

constraints. Asking the questions listed in the table
should elicit the majority of the constraints that will
affect your solution

27
Step 5: Identify the Constraints to be
Imposed on the Solution (cont.)

• Potential Sources of System Constraints

(cont.):

28
Step 5: Identify the Constraints to be
Imposed on the Solution (cont.)

• GoodsAreUs :

29
Key Points?

• Problem Analysis is:

—process of understanding the causes of real-
world problems
—Identification of stakeholders and their needs
—Understanding of the likely boundaries of the
solution
—Elicitation of constraints
before development begins!

30
Assignment 1
• Consider any one problem of the College
which is bugging you the most, e.g.,
regarding hostels, messes, tuck-shops
/cafes, transport, depts. admin, finances
registration matters, etc.
• Perform following Steps: -
1. Gain agreement on the problem definition.
2. Understand the root causes—the problem behind the
problem.
3. Identify the stakeholders and the users.
4. Define the solution system boundary.
5. Identify the constraints to be imposed on the solution.