Chapter 4: Software

Requirements Elicitation
 Key Takeaway Points
• Requirements are capabilities that the system
must deliver.
• The hardest single part of building a software
system is deciding precisely what to build—
i.e., the requirements. (Frederick P. Brooks, Jr.)
• Software requirements elicitation is aimed to
identify the real requirements for the system.

4-2
 The Planning Phase
• The planning phase has three activities:
– requirements elicitation
– deriving use cases from the requirements, and
– producing an iterative development plan
• It requires the team to work closely with the
customer and users
– to help them identify the needs for their business
– to help them determine the real requirements for
the future system
– to help them prioritize the requirements
4-3
 Requirements Elicitation
• Requirements are capabilities (stated as part of
a contract) that the system must deliver.
• Requirements are documented in a
requirements specification, which serves as
part of the contract.
• Requirements elicitation is the process to
identify and formulate the capabilities for
the software system.

4-4
Requirements Elicitation in Software Lifecycle
System Engineering

Requirements Engineering/
Requirements Elicitation

Software Design

Implementation

Testing

Deployment & Maintenance

4-5
 Requirements Elicitation in Methodology Context
Use case-iteration
Business goals allocation matrix
& needs
Current situation Accommodating Customer
Requirements Change feedback
Requirements Elicitation Iteration use cases

Domain Modeling
Preliminary requirements
Domain model Domain model
Deriving Use Cases
from Requirements Actor-System Interaction
Modeling
Abstract & high level use cases, Expanded use cases &
use case diagrams UI design
Allocating Use Cases & Behavior Modeling &
Subsystems Responsibility Assignment
to Iterations
Behavior models
Use case-iteration
allocation matrix Deriving Design Class
Diagram
Producing an Architecture
Design Design class diagram
Software
architecture Test Driven Development,
Integration, & Deployment

(a) Planning Phase (b) Iterative Phase – activities during each iteration
control flow data flow control flow & data flow
4-6
 Requirements Elicitation Activities
• Identifying problems and needs
• Constructing analysis models to help
understanding
• Formulating system/software requirements
• Conducting feasibility study
• Checking the requirements and models for
desired properties such as correctness, and
consistency
• Specifying acceptance tests
• Formulating an iterative development plan
4-7
 Importance of Requirements Elicitation
• The requirements specification is part of the
contract, which bears legal consequences.
– Numerous lawsuits are related to systems not
satisfying the requirements and constraints.
• 37% of all software development problems are
related to requirements.
• Poorly identified requirements significantly
increase the development costs.

4-8
 Importance of Requirements Elicitation

Poor user input

13%

Incomplete
requirements
12%
Other
50%
Changing
requirements
12%
Poor technical
skills
7%
Poor staffing
6%

37% of problems are related to requirements

Source: Jim Johnson, "Chaos: Charting the Seas of Information Technology."
The Standish Group, 1994.
4-9
 Importance of Requirements Engineering
50
Relative cost of defect detection/
20 removal along the lifecycle

10
5
2 Average $15K to fix a
1 bug in the field (1991)

.5
.2
Requirements Design Code Development Acceptance Operation
Berry Boehm 1982 Test Test
4-10
 Challenges of Requirements Elicitation
"The hardest single part of building a software
systems is deciding precisely what to build. No
other part of the conceptual work is as difficult
as establishing that detailed technical
requirements, including all the interfaces to
people, to machines, and to other software
systems. No other part of the work so cripples
the resulting system if done wrong. No other
part is more difficult to rectify later."
Frederick Brooks 1987
4-11
 Challenges of Requirements Elicitation
As an analyst, I need But what do you
I want you to design
to know what do you want to do with
the software for me.
want? the software?

I don’t know until Well, I can design Can you design the
you tell me what the the software to do software to tell you
software can do. anything! my requirements?!

4-12
 Challenges of Requirements Elicitation
• Software development in general is a wicked problem.
• Communication barrier between the team and the
customer and users.
– The team does not know the application domain, and the
needs of the customer and users.
– The customer and users do not know what the software can
do for them.
• The importance and challenges of requirements
elicitation are often underestimated.
• Nonfunctional requirements are not identified or
understated.
• Requirements change throughout the software
lifecycle.
4-14
 Types of Requirement
• Functional requirements – statements of
information processing capabilities that the
software system must possess.
• Nonfunctional requirements include
– Performance requirements
– Quality requirements
– Safety requirements
– Security requirements
– Interface requirements

4-15
 Examples of Functional Requirements
• For a car rental system:
– The system must allow a potential customer to
inquire information and availability of rental cars
using various combinations of search criteria
including make, model, from date, to date, price
range, and class (small size, medium size, large
size, and luxury cars).
• For a study abroad system:
– The system must provide interactive as well as
batch-processing means for an OIE (Office of
International Education) staff to enter the exchange
programs into the database. 4-16
 Examples of Non-Functional Requirements
• Workload:
– The system must be capable of handling a typical
workload of 10,000 (ten thousand) inquiries at the
same time.
• Response time:
– The system's response time must not exceed 3
(three) seconds under the typical workload.

4-17
 Examples of Quality Requirements
• Security:
– The system must protect the contents of the
website from malicious attacks and protect the
privacy of its users.
• Platform independence:
– The system must run on Windows 2000 and later,
Unix, Linux, Mac and support popular relational
database management systems including Oracle,
SQL Server, Access, and MySQL.

4-18
 Examples of Quality/Interface Requirements
• User friendliness:
– The system must provide a user friendly interface
that conforms to commonly used web-application
user interface look-and-feel and man-machine
interaction conventions.
• User interface:
– The system must support the following user
interfaces:
• web-based
• stand-alone
• voice
• cellular phone 4-19
 Requirements Elicitation Steps

2. Constructing analysis
models, if desired.

1. Collecting 3. Deriving requirements

information about & constraints.
the application.

5. Reviewing the
requirements 4. Conducting
specification. feasibility study.
4-20
 Information Collection Techniques

business operating
forms procedures regulations &
Customer presentation Literature survey standards

Writing user stories

Stakeholder survey User interviewing
4-21
 Focuses of Information Collection Activities
• What is the business, the current business situation, and
how does it operate?
• What is the system’s environment or context?
• What are existing business processes, their input and
output, and how do they relate to each other?
• What are the problems with the current system?
• What are the business or product goals?
• Who are the users of the current and future systems,
respectively?
• What do the customer and users want, and what are their
business priorities?
• What are the quality, performance, and security
considerations?
4-22
 Constructing Analysis Models

fac
xxx
vvv
bbb
nnn

Intuitive models
fac1 fac2

Purpose: to aid understanding yyy jjj

of the application, requirements, Formal or informal models

and constraints.
4-23
 Businesses in Different Domains

Finance Insurance Health Care

Transportation Defense Telecommunication Retailing

and more

government Education
Energy Manufacturing
4-24
 Deriving Requirements and Constraints
Current
Situation

Discrepancies/
Problems Industry standards
Business and government
Goals policies

Needs &
wish list

Requirements &
constraints

4-25
 Priorities and Timing
• Ask the customer and users
– How much would he/she pay to
include a given requirement?
• for example, between $1 and $100, how much he/she
would pay to have it delivered?
– How soon would he/she like the requirement
delivered?
– Between $X and $Y, how much would he/she pay
to have it delivered in this version than in next
version?

4-26
 Requirements Specification
1. Introduction to Document 3.1.1 User Interfaces
1.1 Purpose of Product 3.1.2 Hardware Interfaces
1.2 Scope of Product 3.1.3 Software Interfaces
1.3 Acronyms, Abbreviations, 3.1.4 Communication Interfaces
Definitions
1.4 References 3.2 Functional Requirements
1.5 Outline of the Rest of the SRS 3.2.1 Class 1
2. General Description of Product 3.2.2 Class 2
2.1 Context of Product 3.2.3 ...
2.2 Product Function 3.3 Performance Requirements
2.3 User Characteristics 3.4 Design Constraints
2.4 Constraints 3.5 Quality Requirements
2.5 Assumptions and Dependencies 3.6 Other Requirements
3. Specific Requirements 4. Appendices
3.1 External Interface
Requirements
IEEE SRS Standard by Objects, 1998
4-27
 Requirements Specification
1. Introduction to Document 3.2 External Interface Requirements
1.1 Purpose of Product 3.2.1 User Interfaces
1.2 Scope of Product 3.2.2 Hardware Interfaces
1.3 Acronyms, Abbreviations, Definitions 3.2.3 Software Interfaces
1.4 References 3.2.4 Communication Interfaces
1.5 Outline of the Rest of the SRS 3.3 Performance Requirements
2. General Description of Product 3.4 Design Constraints
2.1 Context of Product 3.4.1 Standards Compliance
2.2 Product Function 3.4.2 Hardware Limitations
2.3 User Characteristics ...
2.4 Constraints 3.5 Attributes
2.5 Assumptions and Dependencies 3.5.1 Availability
3. Specific Requirements 3.5.2 Security
3.1 Functional Requirements 3.5.3 Maintainability
3.1.1 Functional Requirement 1 ...
3.1.1.1 Introduction 3.6 Other Requirements
3.1.1.2 Inputs 3.6.1 Database
3.1.1.3 Processing 3.6.2 Operations
3.1.1.4 Outputs ...
3.1.2 Functional Requirement 2 4. Appendices
... IEEE SRS Standard 830-1984
4-28
 Feasibility Study
• Not all projects are practically doable with
technology, time, and resource constraints.
• Feasibility study aims at determining if the
project is doable under the given constraints.
• Feasibility study in RE is concerned with
– the feasibility of the functional, performance,
nonfunctional, and quality constraints
– adequacy of the technology
– timing and cost constraints
– constraints imposed by the customer, industry and
government agencies 4-29
 Requirements Verification and Validation
• Verification: Are we building the product
right?
– Are we building the product in the right way?
– It concerns the product building process.
• Validation: Are we building the right product?
– Are we building the product that the customer
wants?
– It concerns the correctness of the product being
built.

4-30
 Three Types of Requirements Review
• Technical review is an internal review
performed by the technical team. Techniques
include:
– peer review, peers are guided by a review
questionnaire
– walkthrough, the analyst explains each
requirement while the reviewers examine it and
raise doubts
– inspection, inspector is guided by a checklist of
commonly encountered problems in SRS (e.g.,
incompleteness, duplicate definition,
inconsistency, etc.) 4-31
 Three Types of Requirements Review
• Expert review means review of the
requirements specification by domain experts.
• Customer/user reviews are performed by
involving the customer and/or users of the
system.

4-32
 Using Review/Inspection Lists
• Develop different peer review questionnaires
and inspection checklists for different types of
review:
peer review inspection

technical internal internal inspection

review review questionnaire checklist

expert expert expert inspection

review review questionnaire checklist
customer customer
review review questionnaire
4-33
 Applying Agile Principles
1. Customer collaboration and active user
involvement are imperative.
2. Capture requirements at a high level; leave
the detail to subsequent iterations.
3. Good enough is enough---produce a list of
prioritized software requirements quickly and
move on to the next step.
4. Just barely enough modeling---construct the
minimum model quickly, just enough to serve
the purpose and no more.

4-34