W5-Lecture 9&10 - Requirement Engineering Process & Discovery Techniques

CSC291 - Software Engineering
Concepts
Lecture 9&10
Requirements Engineering Process &
Discovery Techniques
04/30/2024 CSC291 - Software Engineering Concepts 2
Outline
Requirement Engineering Process
• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management
Requirements Engineering
“Requirement Engineering (RE) is the science and

discipline concerned with analyzing and documenting
requirements.”
Requirements Engineering Process

Goal of RE Process  to create and maintain a system
requirement document
• RE processes may Include four high level activities
 Assessing whether the system is useful to business

and customer (Feasibility Study)
 Discovering requirements (elicitation and analysis)
 Converting theses requirements into some standard
form (specification)
 Checking that the requirements actually define the
system that the customer wants (validation)
The Requirements Engineering Process

Requirements
Feasibility
elicitation and
stud y
anal ysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system

requirements
Requirements
document
Requirements Engineering Process
• The process used for RE vary widely depending on the

application domain, the people involved and the
organization developing the requirements.
• However, there are a number of generic activities common to

all processes.
• Requirements Elicitation
• Requirements Analysis
• Requirements Validation
• Requirements Management
Feasibility Study
• A feasibility study decides whether or not the proposed system
is worth implementing.
• A feasibility study is short, focused study that take place early

in the RE Process
• Does the system contributes to organizational objectives?
• Can the system be implemented within schedule and
budget using current technology?
• Can the system can be integrated with other systems that
are used?
• If the answer to any of these questions is no, you should

probably not go ahead with the project.
Requirement Elicitation and Analysis

• Sometimes called requirement discovery.
• Involves technical staff (software engineers) working with

customers to find out about the
• application domain
• the services that the system should provide and
• the system’s operational constraints.
May involve a variety of people in an organization

• End-users, managers, engineers involved in maintenance,
domain experts etc. These are called stakeholders
Requirement Elicitation and Analysis

Process Activities
Requirements discovery
• Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organization

• Groups related requirements and organizes them into coherent
clusters.
Prioritization and negotiation

• Prioritizing requirements and resolving requirements conflicts
through negotiation.
Requirements documentation(Specification)
• Requirements are documented.
Requirements Elicitation and Analysis Process

Problems of Requirements Analysis

Understanding stakeholder requirements is difficult for
several reasons
• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the
system requirements.
• The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.
Requirements Discovery
• The process of gathering information about the proposed

and existing systems
• Refining the user and system requirements from this

information.
• Sources of information include system stakeholders and

the specifications of similar systems.
Techniques of Requirement Discovery

Interview:
• Formal or informal interview with the system stakeholders
• In this, the RE team puts questions to stakeholders about the
system that they currently use and the system to be developed.
• There are two types of interview

• Closed interviews: where the stakeholders answers a pre-
defined set of questions.
• Open interviews: in which there is no pre-defined agenda

and a range of issues are explored with stakeholders.
Effective Interviewers
• Interviewers should be open-minded.
• Avoid pre-conceived ideas about the requirements, and
willing to listen to stakeholders.

• If the stakeholder comes up with surprising requirements ,
willing to change their minds about the system.

• They prompt the interviewee to get with discussion using
a question or a proposal.
User Stories
• User stories are commonly used in adaptive or agile methodologies
• Short, high-level descriptions of required functionality expressed in

customer terms.
• A typical user story has the form: “As a <role>, I want <goal/desire>
so that <benefit>.”
• Just enough information so that the developers can produce a

reasonable estimate of the effort to implement it.
• The aim is to avoid some of the waste that often happens in

projects where detailed requirements are gathered early but
become invalid before the work begins.
Example
Downloading and printing an article
First, you select the article that you want from a displayed list. You
then have to tell the system how you will pay for it - this can either
be through a subscription, through a company account or by credit
card.
After this, you get a copyright form from the system to fill in and,
when you have submitted this, the article you want is downloaded
onto your computer.
You then choose a printer and a copy of the article is printed. You
tell the system if printing has been successful.
If the article is a print-only article, you canÕ t keep the PDF version
so it is automatically deleted from your computer .
Scenarios
• People usually find it easier to relate to real-life examples
rather than abstract descriptions.

• Scenarios are real-life examples of how a system can be used.
• Through Scenario user can understand and criticize….how
they might interact with a software system.

• Requirement engineers can use the information gained from
this discussion to formulate the actual system requirements.

Scenarios
They should include:
• A description of the starting situation

• A description of the normal flow of events
• A description of what can go wrong
• Information about other concurrent activities
• A description of the state when the scenario finishes.
LIBSYS Scenario
Initial assumption: The user has logged on to the LIBSYS system and has located the
journal containing the copy of the article.
Normal: The user selects the article to be copied. He or she is then prompted by the
system to either provide subscriber information for the journal or to indicate how they
will pay for the article. Alternative payment methods are by credit card or by quoting an
organisational account number.
The user is then asked to fill in a copyright form that maintains details of the transaction
and they then submit this to the LIBSYS system.
The copyright form is checked and, if OK, the PDF version of the article is downloaded
to the LIBSYS working area on the user’s computer and the user is informed that it is
available. The user is asked to select a printer and a copy of the article is printed. If the
article has been flagged as ‘print-only’ it is deleted from the user’s system once the user
has confirmed that printing is complete.
LIBSYS Scenario
What can go wrong: The user may fail to fill in the copyright form correctly. In this
case, the form should be re-presented to the user for correction. If the resubmitted form is
still incorrect then the user’s request for the article is rejected.
The payment may be rejected by the system. The user’s request for the article is rejected.
The article download may fail. Retry until successful or the user terminates the session.
It may not be possible to print the article. If the article is not flagged as ‘print-only’ then it
is held in the LIBSYS workspace. Otherwise, the article is deleted and the user’s account
credited with the cost of the article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has been deleted
from LIBSYS workspace if it has been flagged as print-only.
Use Cases
• Use-cases are a scenario based technique for
requirement elicitation
• Which identify the actors in an interaction and which

describe the interaction itself.
•A set of use cases should describe all possible

interactions with the system.
• Sequence diagrams may be used to add detail to use-

cases by showing the sequence of event processing in
the system.
LIBSYS Use Cases
Article search
Library Article p rin ting

User
User ad m inistratio n Library

Staff
Su pp lier Catalog u e serv ices

Social and Organizational Factors
• Software systems do not exist in isolation – they are used

in a social and organizational context.
• This can influence or even dominate the system

requirements.
• Good analysts must be sensitive to these factors.

Example
• Consider a system which allows senior management to
access information without going through middle
managers
• Managerial status. Senior managers may feel that they are too
important to use a keyboard. This may limit the type of system
interface used
• Managerial responsibilities. Managers may have no uninterrupted
time where they can learn to use the system
• Organisational resistance. Middle managers who will be made
redundant may deliberately provide misleading or incomplete
information so that the system will fail
Ethnography
• Ethnography isan observational technique that can be

used to understand social and organizational
requirements.
• An analyst immerses him or herself in the working

environment (where the system will be used)
• Help analyst to discover implicit system requirements.

Requirements Validation
• Concerned with demonstrating that the requirements

define the system that the customer really wants.
• Requirements error costs are high so validation is very

important
• Fixing a requirements error after delivery may cost up to

100 times the cost of fixing an implementation error.
Requirements Checking
Checks include
• Validity. Does the system provide the functions which

best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the
customer included?
• Realism. Can the requirements be implemented given
available budget and technology
Requirements Validation Techniques
• Requirements reviews:
• Systematic manual analysis of the requirements(by a team of
reviewers) who check for error and inconsistencies.
• Prototyping:
• Using an executable model of the system to check
requirements.
• Test-case generation:
• Developing tests for requirements to check testability.
Requirements Management
• Requirements management is the process of managing

changing requirements during the requirements engineering
process and system development.
• New requirements emerge during the process as business

needs change and a better understanding of the system is
developed
Requirements Evolution
Initial Changed
understanding understanding
of problem of prob lem
Initial Changed
requirements requirements
Time
Enduring and Volatile Requirements
From an evolution perspective
• Enduring requirements. Stable requirements derived

from the core activity of the customer organization. E.g. a
hospital will always have doctors, nurses, etc. May be
derived from domain models
• Volatile requirements. Requirements which change

during development or when the system is in use.
Requirements Change Management

• Should be apply to all proposed changes to the requirements.
• There are three principal stages to change management

process:
• Problem analysis: Discuss requirements problem and

propose change
• Change analysis and costing: Assess effects of change on

other requirements;
• Change implementation: Modify requirements document

and other documents to reflect change.
Change Management
Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation
Key Points
• The requirements engineering process includes a

feasibility study, requirements elicitation and analysis,
requirements specification and requirements
management.
• Requirements elicitation and analysis is iterative involving

domain understanding, requirements collection,
classification, structuring, prioritization and validation.
• Systems have multiple stakeholders with different

requirements.
Key Points
• Social and organization factors influence system

requirements.
• Requirements validation is concerned with checks for

validity, consistency, completeness, realism and
verifiability.
• Requirements management includes planning and

change management.
Chapter Reading
Chapter 4, Requirement Engineering,
Software Engineering by Ian Sommerville
Chapter 5: Understanding Requirement
by “Software Engineering- A Practitioner's Approach”
(Book and Lecture Slides are already uploaded on resource
link.)
Resource Link:
https://sites.google.com/cuilahore.edu.pk/sec

W5-Lecture 9&10 - Requirement Engineering Process & Discovery Techniques

Uploaded by

Copyright:

Available Formats

W5-Lecture 9&10 - Requirement Engineering Process & Discovery Techniques

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

W5-Lecture 9&10 - Requirement Engineering Process & Discovery Techniques

Uploaded by

Copyright:

Available Formats

CSC291 - Software Engineering

Requirement Engineering Process

“Requirement Engineering (RE) is the science and

Requirements Engineering Process

• RE processes may Include four high level activities

 Assessing whether the system is useful to business

The Requirements Engineering Process

User and system

Requirements Engineering Process

• The process used for RE vary widely depending on the

• However, there are a number of generic activities common to

• A feasibility study is short, focused study that take place early

• If the answer to any of these questions is no, you should

Requirement Elicitation and Analysis

• Involves technical staff (software engineers) working with

May involve a variety of people in an organization

Requirement Elicitation and Analysis

Requirements classification and organization

Prioritization and negotiation

Requirements Elicitation and Analysis Process

Problems of Requirements Analysis

• Stakeholders don’t know what they really want.

• The process of gathering information about the proposed

• Refining the user and system requirements from this

• Sources of information include system stakeholders and

Techniques of Requirement Discovery

• There are two types of interview

• Open interviews: in which there is no pre-defined agenda

• Avoid pre-conceived ideas about the requirements, and

willing to listen to stakeholders.

willing to change their minds about the system.

• Short, high-level descriptions of required functionality expressed in

• Just enough information so that the developers can produce a

• The aim is to avoid some of the waste that often happens in

rather than abstract descriptions.

• Through Scenario user can understand and criticize….how

they might interact with a software system.

this discussion to formulate the actual system requirements.

They should include:

• A description of the starting situation

• Which identify the actors in an interaction and which

•A set of use cases should describe all possible

• Sequence diagrams may be used to add detail to use-

LIBSYS Use Cases

Library Article p rin ting

User ad m inistratio n Library

Su pp lier Catalog u e serv ices

Social and Organizational Factors

• Software systems do not exist in isolation – they are used

• This can influence or even dominate the system

• Good analysts must be sensitive to these factors.

• Ethnography isan observational technique that can be

• An analyst immerses him or herself in the working

• Help analyst to discover implicit system requirements.

• Concerned with demonstrating that the requirements

• Requirements error costs are high so validation is very

• Fixing a requirements error after delivery may cost up to

• Validity. Does the system provide the functions which

Requirements Validation Techniques

• Requirements management is the process of managing