CSE291 - Introduction To Software

Engineering
(Fall 2018)

Lecture 5
Requirements
Engineering
Process
10/9/2018 CSE291 - Introduction to Software Engineering 2

Outline

Requirement Engineering Process

• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management
10/9/2018 CSE291 - Introduction to Software Engineering 3

Requirements Engineering

“Requirement Engineering (RE) is the science and

discipline concerned with analyzing and documenting
requirements.”
10/9/2018 CSE291 - Introduction to Software Engineering 4

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)
10/9/2018 CSE291 - Introduction to Software Engineering 5

The Requirements Engineering Process

10/9/2018 CSE291 - Introduction to Software Engineering 6

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
10/9/2018 CSE291 - Introduction to Software Engineering 7

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.
10/9/2018 CSE291 - Introduction to Software Engineering 8

Feasibility Study Implementation

Carrying out feasibility study involves
• Information assessment (what is required)
• Information collection
• Report writing

* Questions for people in the organisation

• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?
10/9/2018 CSE291 - Introduction to Software Engineering 9

Feasibility Study Implementation

In feasibility study you may consult information sources such as

• Managers of department where the system will be used

• Software engineers who are familiar with the type of proposed
system
• Technology experts
• End user of system

Should complete a feasibility study in two or three weeks

• Once you have information  write feasibility report
• Make a recommendation  whether or not the system should
continue
• In a report  you may propose changes to scope ,budget and
schedule of the system.
10/9/2018 CSE291 - Introduction to Software Engineering 10

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
10/9/2018 CSE291 - Introduction to Software Engineering 11

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.
10/9/2018 CSE291 - Introduction to Software Engineering 12

Requirements Elicitation and Analysis Process

10/9/2018 CSE291 - Introduction to Software Engineering 13

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.
10/9/2018 CSE291 - Introduction to Software Engineering 14

Requirements Discovery

• The process of gathering information about the proposed

and existing systems

• Distilling the user and system requirements from this

information.

• Sources of information include system stakeholders and

the specifications of similar systems.
10/9/2018 CSE291 - Introduction to Software Engineering 15

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.
10/9/2018 CSE291 - Introduction to Software Engineering 16

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.
10/9/2018 CSE291 - Introduction to Software Engineering 17

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.

10/9/2018 CSE291 - Introduction to Software Engineering 18

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.
 10/9/2018 CSE291 - Introduction to Software Engineering 19

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.
 10/9/2018 CSE291 - Introduction to Software Engineering 20

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.
10/9/2018 CSE291 - Introduction to Software Engineering 21

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.
10/9/2018 CSE291 - Introduction to Software Engineering 22

LIBSYS Use Cases

10/9/2018 CSE291 - Introduction to Software Engineering 23

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.

10/9/2018 CSE291 - Introduction to Software Engineering 24

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.

10/9/2018 CSE291 - Introduction to Software Engineering 25

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.
10/9/2018 CSE291 - Introduction to Software Engineering 26

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
10/9/2018 CSE291 - Introduction to Software Engineering 27

Requirements Validation Techniques

• Requirements reviews:
• Systematic manual analysis of the requirements(by a team of
reviewers) who check for error and inconsisitencies.

• Prototyping:
• Using an executable model of the system to check
requirements.

• Test-case generation:
• Developing tests for requirements to check testability.
10/9/2018 CSE291 - Introduction to Software Engineering 28

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
10/9/2018 CSE291 - Introduction to Software Engineering 29

Requirements Evolution
10/9/2018 CSE291 - Introduction to Software Engineering 30

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.
10/9/2018 CSE291 - Introduction to Software Engineering 31

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.
10/9/2018 CSE291 - Introduction to Software Engineering 32

Change Management
10/9/2018 CSE291 - Introduction to Software Engineering 33

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.
10/9/2018 CSE291 - Introduction to Software Engineering 34

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.
10/9/2018 CSE291 - Introduction to Software Engineering 35

Chapter Reading
• Chapter 4, Requirement Engineering,
Software Engineering by Ian Sommerville