DEBRE MARKOS UNIVERSITY

BURIE CAMPUS
DEPARTMENT OF COMPUTER SCIENCE
Fundamentals of Software Engineering
By:
Amare W.

1
 2

Chapter Three

Requirement Engineering

What is requirement engineering?

♥The software requirements are description of features and functionalities of the target system.
♥Requirements convey the expectations of users from the software product.
♥The requirements for a system are the descriptions of what the system should do the services
that it provides and the constraints on its operation.
 3 02/11/2022

♥ Requirements are described in the system requirements

specification.
♥ Requirements engineering is the process of:
 finding out,
 analysing,
services and constraints
 documenting and
 checking

♥ The system requirements document is created and maintained

during requirements engineering.
3/2/2018
 4 02/11/2022

♥ The goal of requirement engineering is to develop and

maintain sophisticated and descriptive ‘System Requirements
Specification’ document.
♥ The analyst starts requirement gathering and analysis activity
by collecting all information from the customer.
♥ then analyzes the collected information to obtain a clear and
thorough understanding of the product to be developed, with a
view to remove all ambiguities and inconsistencies from the
3/2/2018
initial customer perception of the problem.
 5 02/11/2022

♥ Project should be clearly understood by the analyst in order to

obtain a good grasp of the problem the following basic
questions
 What is the problem?
 Why is it important to solve the problem?
 What are the possible solutions to the problem?
 What are the data input to the system and what are the data output by the
system?
 What are the likely complexities that might arise while solving the
problem?
 what exactly would the data interchange formats with the external
system? 3/2/2018
 6 02/11/2022

♥ User requirements and system requirements may be defined as follows:

♥ User requirements: -high-level abstract requirements.
♥ are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under
which it must operate.
♥ System requirements: - detailed description of what the system should
do.
 Functions,
 Services,and
 Operational constraints.
3/2/2018
 7 02/11/2022

….cont’d
♥ The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented.
♥ It may be part of the contract between the system buyer and the
software developers.
♥ Example:-Mental health care patient management system (MHC
PMS).

1. User requirement:- The MHC-PMS shall generate monthly

management reports showing the cost of drugs arranged by each
clinic during that month. 3/2/2018
 8 02/11/2022

2. System requirements
♥On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
♥The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
♥A report shall be created for each clinic and shall list the individual
drug names, the total number of prescriptions, the number of doses
prescribed, and the total cost of the prescribed drugs.
3/2/2018
 9 02/11/2022

♥ If drugs are available in different dose units (e.g., 10 mg, 20

mg) separate reports shall be created for each dose unit.
♥ Access to all cost reports shall be restricted to authorized users
listed on a management access control list.

3/2/2018
 10 02/11/2022

Characteristics of a Good Requirement

♥ Clear and Unambiguous

 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent 3/2/2018

What is the importance of requirements?

 11 02/11/2022

Requirements Engineering Process

♥ Requirements engineering process aims to produce an agreed

requirements document that specifies a system satisfying
stakeholder requirements.
♥ The process of establishing what services are required and the
constraints on the system’s operation and development.

3/2/2018
 12 02/11/2022

♥ There are four main activities in the requirements engineering

process:

3/2/2018
 13 02/11/2022

1. Feasibility study

♥ An estimate is made of whether the identified user needs may be satisfied using
current software and hardware technologies.
♥ The study considers whether the proposed system will be cost-effective from a
business point of view and if it can be developed within existing budgetary constraints.
♥ all functions the software must perform and which all features are expected from the
software.
♥ This study analyzes whether the software product can be
 practically materialized in terms of implementation
 contribution of project to organization
 cost constraints and
 as per values and objectives of the organization.

Operational feasibility, Technical feasibility, Economic feasibility, Political feasibility,

Schedule feasibility 3/2/2018
 14 02/11/2022

2. Requirements elicitation and analysis:-

♥ Requirement gathering (discovering requirements).

♥ Elicit means to gather, acquire, extract, and obtain.
♥ Process of deriving the system requirements through observation
of existing systems, discussions with potential users and buyers,
task analysis, and so on.
♥ There are various techniques of requirements elicitation which
may be used including:
 Interviews - Questionnaires
 Use cases - Observing the existing system
 Ethnography - Documents 3/2/2018
 Scenarios
 15 02/11/2022

♥ Use cases:- are a scenario based technique in the UML 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.

3/2/2018
 16 02/11/2022

♥ In their simplest form, a use case identifies the actors involved in an

interaction and names the type of interaction.
♥ Use cases are documented using a high-level use case diagram. The
set of use cases represents all of the possible interactions that will be
described in the system requirements.
♥ Actors in the process, who may be human or other systems, are
represented as stick figures. Each class of interaction is represented as
a named ellipse.
♥ Lines link the actors with the interaction. Optionally, arrowheads may
3/2/2018

be added to lines to show how the interaction is initiated.

 17 02/11/2022

♥ Scenarios:- particularly useful for adding detail to an outline

requirements description.
♥ Each scenario usually covers one or a small number of possible
interactions.
♥ Different forms of scenarios are developed and they provide different
types of information at different levels of detail about the system.
♥ A scenario starts with an outline of the interaction. During the
elicitation process, details are added to this to create a complete
description of that interaction.
3/2/2018
 18 02/11/2022

♥ At its most general, a scenario may include:

1. A description of what the system and users expects when the
scenario starts.

2. A description of the normal flow of events in the scenario.

3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at
the same time.
5. A description of the system state when the scenario finishes.
3/2/2018
 19 02/11/2022

♥ Scenarios may be written as text, supplemented by diagrams, screen

shots.
♥ As an example of a simple text scenario, consider how the MHC-
PMS may be used to enter data for a new patient in the above
example.
♥ Example:-Scenario for collecting medical history in mental health
care patient management system (MHC PMS).
Initial assumption
Normal flow of events
What can go wrong 3/2/2018

Other activities and System state on completion

 20 02/11/2022

♥ Initial assumption:-created a record in the system and collected the

patient’s personal information. A nurse is logged on to the system
and is collecting medical history.
♥ Normal flow of events: The nurse searches for the patient by family
name and add medical history.
♥ If there is more than one patient with the same surname, the given
name and date of birth are used to identify the patient.
♥ What can go wrong: The patient’s record does not exist or cannot
be found. The nurse should create a new record and record personal
3/2/2018

information.
 21 02/11/2022

♥ Other activities: Record may be consulted but not edited by

other staff while information is being entered.
♥ System state on completion: User is logged on. The patient
record including medical history is entered in the database, a
record is added to the system log showing the start and end
time of the session and the nurse involved.

3/2/2018
 22 02/11/2022

♥ Ethnography: is an observational technique that can be used to

understand operational processes and help derive support
requirements for these processes.
♥ An analyst immerses himself or herself in the working environment
where the system will be used.
♥ The day-to-day work is observed and notes made of the actual tasks
in which participants are involved.
♥ The value of ethnography is that it helps discover implicit system
requirements that reflect the actual ways that people work, rather
3/2/2018

than the formal processes defined by the organization.

 23 02/11/2022

♥ Ethnography is particularly effective for discovering two types

of requirements:
1. Requirements that are derived from the way in which people
actually work, rather than the way in which process
definitions say they ought to work.
2. Requirements that are derived from cooperation and
awareness of other people’s activities.

3/2/2018
 24 02/11/2022

Requirements elicitation includes the following activities

♥ Identifying actors: - During this activity, developers identify the different

types of users the future system will support.
♥ Identifying scenarios: - During this activity, developers observe users and
develop a set of detailed scenarios for typical functionality provided by the
future system. Scenarios are real-life examples of how a system can be used.
♥ Identifying use cases: - developers derive from the scenarios a set of use
cases that completely represent the future system. Use cases are abstractions
describing all possible cases.
♥ Refining use cases: - developers ensure that the system specification is
complete, by detailing each use case and describing the behavior of the
3/2/2018
system in the presence of errors and exceptional conditions.
 25 02/11/2022

♥ Identifying relationships among use cases:- developers consolidate the

use case model by eliminating redundancies. This ensures that the system
specification is consistent.
♥ Identifying nonfunctional requirements: - developers, users, and clients
agree on aspects that are visible to the user but not directly related to
functionality.
♥ These include:
constraints on the performance of the system
its documentation
 the resources it consumes
its security and 3/2/2018
its quality.
 26 02/11/2022

♥ ** Requirements Analysis determining whether the stated

requirements are clear, complete, consistent and unambiguous.
♥ ** Requirement elicitation and analysis stages (process)

3/2/2018
 27 02/11/2022

♥ Requirements discovery – Interacting with stakeholders to discover their

requirements.
♥ Requirements classification and organisation – Groups related
requirements and organises them into coherent clusters.
♥ Prioritization and negotiation – Prioritising requirements and resolving
requirements conflicts. This activity is concerned with prioritizing
requirements and finding and resolving requirements conflicts through
negotiation.
♥ Requirements specification – All formal & informal, functional and non-
functional requirements are documented and made available for next phase
3/2/2018

processing.
 28 02/11/2022

Problems of requirement analysis

♥Problems of scope: The boundary of system is ill-defined. Or unnecessary details are
provided.
♥Problems of understanding: The users are not sure of what they need, and don’t have full
understanding of the problem domain.
♥Problems of volatility: the requirements change overtime.
♥Stakeholders don’t know what they really want.
♥Stakeholders express requirements in their own terms.
♥Different stakeholders may have conflicting requirements.
♥Organisational and political factors may influence the system requirements.
♥The requirements change during the analysis process. New stakeholders may emerge and the
3/2/2018
business environment change.
 29 02/11/2022

3. Requirements specification

♥ Requirements specification is the activity of translating the

information gathered during the analysis activity into a document
that defines a set of requirements.
♥ The process of writing down the user and system requirements in a
requirements document.
♥ SRS document is a contract between the development team and the
customer.
♥ The user requirements for a system should describe the functional
and nonfunctional requirements so that they are understandable by
3/2/2018

system users who don’t have detailed technical knowledge.

 30 02/11/2022

♥ System requirements are expanded versions of the user

requirements that are used by software engineers as the
starting point for the system design.
♥ They add detail and explain how the user requirements should
be provided by the system.

3/2/2018
 31 02/11/2022

4. Requirements validation

♥ Requirements validation is the process of checking that

requirements actually define the system that the customer
really wants.
♥ The specification is examined to ensure that
 All software requirements have been stated unambiguously.
 Inconsistencies, omissions, and errors have been detected and
corrected
 The work products conform to the standards established for
the process, the project, and the product.
 Certifies that the requirements document is an acceptable
3/2/2018
description of the system to be implemented.
 32 02/11/2022

♥ During the requirements validation process, different types of

checks should be carried out on the requirements in the
requirements document. These 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
 Verifiability:- Can the requirements be checked? 3/2/2018
 33 02/11/2022

Requirements document

♥ The requirements document (sometimes called the software

requirements specification or SRS).
♥ is an official statement of what the system developers should
implement.
♥ It should include both the user requirements for a system and a
detailed specification of the system requirements.
♥ are essential when an outside contractor is developing the
software system.
3/2/2018
 34 02/11/2022

Types of software requirements

Functional requirement: -
♥ defines a system or its component.
♥ It describes the functions a software must perform.
♥ A function is nothing but inputs, its behaviour, and outputs.
♥ It can be a calculation of
 data manipulation
business process
user interaction
 or any other specific functionality which defines what
function a system is likely to perform.
3/2/2018
 35 02/11/2022

♥ What the system should do.

♥ This behaviour may be expressed as functions, services or
tasks or which system is required to perform.
♥ Some of the more typical functional requirements
 Business Rules
 Transaction corrections, adjustments and cancellations
 Administrative functions
 Authentication, Authorization levels
 Audit Tracking, External Interfaces
 Certification Requirements, Reporting Requirements 3/2/2018
 36 02/11/2022

♥ Non-Functional Requirement
♥ A non-functional requirement defines the quality attribute of a
software system.
♥ They represent a set of standards used to judge the specific
operation of a system. Example, how fast does the website
load?
♥ is essential to ensure the usability and effectiveness of the
entire software system.
3/2/2018
♥ Describe how the system works.
37 02/11/2022

3/2/2018
 38 02/11/2022

User interface requirements

♥ UI is an important part of any software or hardware or hybrid
system.
♥ A software is widely accepted if it is -
easy to operate
quick in response
effectively handling operational errors
providing simple yet consistent user interface

3/2/2018
 39 02/11/2022

♥ User interface requirements are briefly mentioned below -

Content presentation, Easy Navigation
Simple interface, Responsive
Consistent UI elements, Feedback mechanism
Default settings, Purposeful layout
Strategical use of color and texture.
Provide help information
User centric approach
Group based view settings

3/2/2018
 40 02/11/2022

Requirements management

♥ Process of managing changing requirements during the

requirements engineering process and system development.
♥ The process of understanding and controlling changes to
system requirements.
♥ Once a system has been installed and is regularly used, new
requirements inevitably emerge.

3/2/2018
 41 02/11/2022

Why change is inevitable?

♥The business and technical environment of the system always changes after
installation
New hardware may be introduced


business priorities may change



new legislation and regulations may be introduced



♥The people who pay for a system and the users of that system are rarely the
same people.
System customers impose requirements because of organizational and

budgetary constraints.
♥Large systems usually have a diverse user community, with many users
3/2/2018

having different requirements and priorities that may be conflicting

 42 02/11/2022

Requirements evolution
3/2/2018
 43 02/11/2022

Requirements change management

♥ There are three principal stages to a change management

process:
♥ Problem analysis and change specification
 change proposal is analyzed to check that it is valid
 decide to withdraw the request

♥ Change analysis and costing

 effect of the proposed change is assessed
 The cost of making the change is estimated

♥ Change implementation
3/2/2018
 system design and implementation, are modified
 44 02/11/2022

Cont.….

3/2/2018
 45 02/11/2022

Requirements management planning

♥ Planning is an essential first stage.

♥ Establishes the level of requirements management detail that
is required.
♥ Requirements management decisions:
 Requirements identification
 Each requirement must be uniquely identified
 A change management process:
 assess the impact and cost of changes
 Traceability policies
 relationships between each requirement and between the
requirements and the system design 3/2/2018

 how these records should be maintained

 46 02/11/2022

 Tool support
 involves the processing of large amounts of information
 needs automated support and the software tools

3/2/2018
 47

Thank you