Software Engineering

Mattu University
Engineering and Technology College
Department of Computer Science

Software
Engineering

Target Dept.:- Computer Science 3rd year Regular

 Lecture Three

Requirements Elicitation

Engineering and Technology College Mattu University

 Diriba G. (Department of Computer Science)

Outline

3.1. An overview of requirements elicitation.

3.2. Requirements elicitation concepts
3.2.1. Functional requirements
3.2.2. Non-functional and pseudo requirements
3.2.3. Levels of description
3.2.4. Correctness, completeness, consistency, clarity, and realism
3.2.5. Verifiability and traceability
3.3. Requirements elicitation activities.
3.3.1. Identifying actors
3.3.2. Identifying scenarios
3.3.3. Identifying use cases
3.3.4. Refining use cases
3.3.5. Identifying relationships among actors and use cases
3.3.6. Identifying initial analysis objects
3.3.7. Identifying non-functional requirements
3.4. Managing requirements elicitation
3.4.1. Eliciting information from users:
3.4.2. Validating requirements: Usability testing
3.4.3. Documenting requirements elicitation
Engineering and Technology College Mattu University
 Requirement Engineering
 A requirement is a feature that the system must have

or a constraint that it must satisfy to be accepted by

the client.
 Requirements engineering aims at defining the
requirements of the system under construction.
 Requirements engineering includes two main
activities;
 requirements elicitation, which results in the specification
of the system that the client understands, and
 analysis, which results into an analysis model that the
developers can unambiguously interpret.
 Requirement Engineering …
 The process of establishing the services that the

customer requires from a system and the constraints

under which it operates and is developed.
 The requirements themselves are the descriptions of

the system services and constraints that are generated

during the requirements engineering process.
 Requirements elicitation is about communication
among developers, clients, and users for defining a new
system.
 Requirement Engineering …

Software requirements may be:

 Abstract statements of services
 Detailed mathematical functions
 Part of the bid of contract
 The contract itself
 Part of the technical document, which describes a
product
 Requirement Engineering …

Figure 3-1 Products of requirements elicitation and analysis (UML activity

diagram).
 Types of Requirement
 User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
 Written for customers.

 System requirements
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints.
 Defines what should be implemented so may be part of a
contract between client and contractor.
Cont’d…

1. User requirements
Cont’d…

Problems with natural language

Cont’d…

Guidelines for writing requirement

Cont’d…

2. System requirement

Requirements and Design

Cont’d…
Problems with Natural Language Specification
Cont’d…
Alternative to NL Specification
Cont’d…
Form Based Specification
Cont’d…
Form Based Specification …
Cont’d…
Tabular Specification
Cont’d…
Graphical Models
Cont’d…
Graphical Models … example
Requirements Readers
Cont’d…
 What Requirements should be
gathered?
 Functional: What the product should do.
 Data requirements: Capture the type, volatility,
size/amount, persistence, accuracy and the amounts of the
required data.
 Environmental requirements: a) context of use b) Social
environment (eg. Collaboration and coordination) c) how
good is user support likely to be d) what technologies will it
run on
 User Requirements: Capture the characteristics of the
Cont’d…
 Requirements gathering techniques
 Questionnaires: Series of questions designed to elicit
specific information from us. The questions may require
different kinds of answers: some require a simple Yes/No,
others ask us to choose from a set of pre-supplied answers.
 Interviews: Interviews involve asking someone a set of
questions. Often interviews are face-to-face, but they don’t
have to be.
 Focus groups and workshops: Interviews tend to be one on
one, and elicit only one person’s perspective. It can be very
revealing to get a group of stakeholders together to discuss
issues and requirements.
Cont’d…
 Source of Requirement
 Stakeholders
 People affected in some way by the system
 Documents
 Existing system
 Application Domain
Cont’d…

System Stakeholders
 Any person or organization who is affected by the
system in some way and so who has a legitimate
interest
 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders
Cont’d…
Cont’d…
Example: Stakeholders in the Mentcare system
 Patients whose information is recorded in the
system.
 Doctors who are responsible for assessing and
treating patients.
 Nurses who coordinate the consultations with
doctors
 Medical receptionists who manage patients’
appointments.
 IT staff who are responsible for installing and
3.2. Requirements elicitation concept

 functional requirements (Section 3.2.1)

 non-functional and pseudo requirements
(Section 3.2.2)
 levels of descriptions (Section 3.2.3)
 correctness, completeness, consistency,
clarity, and realism (Section 3.2.4)
 verifiability and traceability (Section 3.2.5)
 greenfield engineering, reengineering, and
interface engineering (Section 3.2.6)
 3.2.1. Functional requirements

 Statements of services the system should provide,

 how the system should react to particular inputs and
 how the system should behave in particular
situations.
 It describe functionality of the system.
 Depend on the type of software, expected users
and the type of system where the software is
used.
 Functional user requirements may be high-level
statements of what the system should do
Cont’d…

 Examples of functional requirements

(ex1)
 The user shall be able to search either all of the
initial set of databases or select a subset from it.
 The system shall provide appropriate viewers
for the user to read documents in the document
store.
 Every order shall be allocated a unique
identifier (ORDER_ID) which the user shall be
Cont’d…
 Example 2, the following is an example of functional
requirements for SatWatch, a watch that resets itself without
user intervention:

 The above functional requirements only focus on the possible

interactions between SatWatch and its external world
Cont’d…

Example 3:

online banking system

 Its functional requirements are:

 The user should able to search. (the system must provide search functionality(i/o
functionality))
 The user should able to delete, update, ...etc.
 The system provide appropriate reading documents:(help functionality)
 Provide unique acknowledgement. (positive response from the system)
 Information must be stored in the database and also enable the user to retrieve back.
(storage functionality)
Cont’d…
In principle, requirements should be both
complete and consistent.

 Complete: They should include descriptions of all

facilities required.
 Consistent: There should be no conflicts or

contradictions in the descriptions of the system

facilities.

 In practice, it is impossible to produce a complete

and consistent requirements document.
3.2.2. Non – functional and pseudo requirements

Non-functional requirements

 These define system properties and constraints:

 e.g. reliability,
 response time and
 storage requirements.

Constraints are I/O device capability, system representations,

etc.

 Non-functional requirements may be more critical

than functional requirements. If these are not met,
the system is useless.
Cont’d…
Non-functional requirements
 describe user-visible aspects of the system that are
not directly related with the functional behaviour of
the system.
 Non-functional requirements include quantitative constraints, such
as:
 response time (i.e., how fast the system reacts to user commands) or
 accuracy (i.e., how precise are the system’s numerical answers
 constraints on the services or functions offered by the system
such as:
 timing constraints,
 constraints on the development process,
 standards, etc.
Pseudo requirements
 are requirements imposed by the client that restrict the
implementation of the system.
 Typical pseudo requirements are the implementation language and

the platform on which the system is to be implemented.

Cont’d…
The following are the pseudo functional requirements
for SatWatch:
Cont’d…
Non-functional requirement classifications

 Product requirements
 Requirements which specify that the delivered product must

behave in a particular way

 e.g. execution speed, reliability, etc.

 Organisational requirements
 Requirements which are a consequence of organisational

policies and procedures

 e.g. process standards used, implementation requirements, etc.

 External requirements
 Requirements which arise from factors which are external to the

system and its development process

 e.g. interoperability requirements, legislative requirements, etc.
Cont’d…
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
Cont’d…
Non-functional requirements examples

 Product requirement
 The user interface for LIBSYS shall be implemented
as simple HTML without frames or Java applets.

 Organisational requirement
 The system development process and deliverable
documents shall conform to the process and
deliverables defined in XYZCo-SP-STAN-95.

 External requirement
 The system shall not disclose any personal
information about customers apart from their name
and reference number to the operators of the system.
Cont’d…
Requirement Measures
Property Measure

Speed Processed transactions/second

User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
3.2.3. Levels of Description
 Requirements describe a system and its interaction with
the surrounding environment, such as the users, their
work processes, and other systems.
 Most requirements analysis methods have focused on
describing the system.

Figure 3-2. A System is a collection of real world Phenomena. A model is a collection

of concepts that represent the system’s phenomena. Many models can represent
different aspects of the same system. An unambiguous model corresponds to only one
system.
3.2.4. Correctness, completeness, consistency, clarity, and realism

 Requirements are continuously validated with the client and

the user.
 Validation is a critical step in the development process, given

that both the client and the developer are dependent on the
system specification.
 Requirement validation involves checking if the
specification is:
 correct,
 complete,
 consistent,
 unambiguous, and
 realistic.
Cont’d…
 A specification is correct if it represents the client’s view of the

system
 (i.e., everything in the requirements model accurately represents an aspect of
the system).

 It is complete if all possible scenarios through the system are

described, including exceptional behavior.

 (i.e., all aspects of the system are represented in the requirements model).
 The system specification is consistent if it does not contradict itself.

 The system specification is unambiguous if exactly one system is

defined
 (i.e., it is not possible to interpret the specification two or more different ways).

 it is realistic if the system can be implemented within constraints.

3.2.5. Verifiability and Traceability
Cont’d…
3.2.6. greenfield, reengineering and interface
engineering
3.3. Requirement elicitation activities
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
3.4. Managing Requirements Elicitations
Requirements Engineering Process
Cont’d…
Cont’d…
3.4.1. Requirements elicitation and analysis
Cont’d…
Cont’d…
Requirements elicitation and analysis process
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…
Cont’d…

Interviews in Practice
 Normally a mix of closed and open-ended

interviewing.
 Interviews are good for getting an overall
understanding of what stakeholders do and how they
might interact with the system.
Interviewers need to be open-minded without

pre-conceived ideas of what the system should

do
Cont’d…

Problems with Interview

3.4.2. Requirement Validation (usability testing)
Cont’d…
Cont’d…
3.4.3. Requirements Management
 Worku.B. (Department of Computer Science)

End of Chapter Three