CHAPTER 3

Requirements Engineering, Elicitation, and

UML

1
Software Requirements

In the software development process,

requirement phase is the first software
engineering activity.
“This phase is a user-dominated phase and
translates the ideas or views into a
requirements document”.

2
Software Requirements
❖ Requirements are descriptions of the services that a
software system must provide and the constraints under
which it must operate

❖ Requirements Engineering is the process of establishing

the services that the customer requires from the system
and the constraints under which it is to be developed
and operated
Requirement Engineering Process
Feasibility Study
Requirements elicitation and analysis
Requirements Specification
Requirements Validation
3
“In SE, Requirements describe features that the
product should include and how those features should
work”. 4
 Requirements Elicitation
It is the practice of obtaining the requirements of a system
from users, customers and other stakeholders.
The practice is also sometimes referred to as Requirement
gathering.

Requirements elicitation practice include the following:

❖ Interviews
❖ Questionnaires
❖ User observation
❖ Workshops
❖ Brain storming
❖ Use cases
❖ Role playing
❖ And prototyping

5
 Requirements Elicitation
Problems of Requirement Elicitation
Scope-related issues: The system's boundaries are unclear
or excessive details are provided, causing confusion or
ambiguity.
Understanding-related issues: Users lack clarity about
their needs and have limited knowledge of the problem
domain, leading to difficulties in accurately defining
requirements.
Volatility-related issues: The requirements undergo
changes over time, introducing uncertainty and making it
challenging to maintain consistent and stable project
specifications.

6
 Types of requirements

There can be several types of requirements in software development.

The most important is to know Business requirements

➢ Why does the client need the app?
❖ The importance of business requirements is that they
provide a vision of the final goal.
✓ With the goal in sight, developers can set priorities.
➢ Without clear business requirements, poor decisions can be made.
➢ It make slow down the development process,
➢ Disrupt deadlines, and
➢ Result in additional development stages.
7
 Types of requirements
Functional requirements are the what requirements
o What is this system designed to do?
o As the name suggests, they describe the functionality of the software.
Non-functional requirements are the how requirements
o How will this system do what it’s designed to do?
o These requirements describe how each feature should behave under what
conditions, what limitations there should be, etc.

Please keep in mind

Functional requirements define what the system is
supposed to do,
whereas non-functional requirements define how a
system is supposed to be.
8
 Types of requirements
For example, let’s imagine we’re making a messaging app.

The main functional requirements, in this case, would be:

❖ The app must be able to send messages
❖ The app must support file and media transfer, etc
The non-functional requirements might be as follows:
❖ The service must offer full functionality in all major browsers: Microsoft
Edge, Google Chrome, Mozilla Firefox ,Opera, Safari
❖ Mobile layouts must be supported, Etc.

9
 Software Requirement Specifications
(SRS)
What is SRS
It is documenting the gathered requirements in a
structured and detailed manner
Software Requirements Specifications (SRS) (also called a
requirements document)
SRS is a formal report, which acts as a representation of software
that enables the customers to review whether it (SRS) is according
to their requirements.
The SRS is a specification for a specific software product,
program, or set of applications that perform particular functions in
a specific environment.

10
Cont’d

➢ First, the SRS could be written

by the client of a system

✓ Second, the SRS could be

written by a developer of the
system.

o Finally the SRS may be used as a

contract document between
customer and developer
11
Characteristics of good SRS

12
Cont’d

❖ Correctness:
✓User review is used to provide the accuracy of
requirements stated in the SRS.
✓SRS is said to be perfect if it covers all the
needs that are truly expected from the system.

13
Cont’d
❖ Completeness: The SRS is complete if, and only if, it
includes the following elements

Full File All

essential
requirements

Responses to
Completeness both valid and
invalid values

Full labels and

references to all
figures, tables, etc

14
Cont’d
❖ Consistency
▪ The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict.
❖ Unambiguousness
▪ SRS is unambiguous when every fixed requirement has only one
interpretation.
❖ Ranking for importance and stability
▪ The SRS is ranked for importance and stability.
▪ Typically, all requirements are not equally important.
❖ Modifiability
▪ SRS should be made as modifiable as likely and should be capable
of quickly obtain changes to the system to some extent.
▪ Modifications should be cross-referenced.
15
Cont’d
❖ Testability
▪ An SRS should be written in such a method that it is simple to
generate test cases and test plans from the report.
❖ Understandable by the customer
▪ An end user may be an expert in his/her explicit domain but might
not be trained in computer science.
▪ Hence, the purpose of formal notations and symbols should be
avoided too as much extent as possible.
▪ The language should be kept simple and clear.

16
Metrics, Verification and Validation
❖Metrics:
A metrics is a measurement of the level that any
impute belongs to a system product or process.
There are 4 functions related to software metrics:
Planning
Organizing
Controlling
Improving

17
Cont’d
Classification of Software Metrics:
Product Metrics:
Product metrics are used to evaluate the state of the
product, tracing risks and under covering prospective
problem areas.
The ability of team to control quality is evaluated.
Process Metrics:
Process metrics pay particular attention on enhancing the
long term process of the team or organisation.

18
 What is Verification and Validation?
Verification and Validation is the process of investigating that a software
system satisfies specifications and standards and it fulfils the required
purpose.
▪ Verification: Are we building the product right?
▪ Verification is the process of checking that a software achieves its goal without
any bugs.
▪ It verifies whether the developed product fulfils the requirements that we have.
Requirements are verified by the analysts mainly

▪ Validation: Are we building the right product?

▪ Validation is the process of checking whether the software product is up to
the mark or in other words product has high level requirements
Requirements are validated by stakeholders

19
Cont’d

Activities involved in verification

1.Inspections
2.Reviews
3.Walkthroughs
Activities involved in validation
1.Box testing
2.Unit testing
3.Integration testing

20
Verification Vs. Validation

21
 Thank You

The Next UML →

22