1

REQUIREMENTS
ENGINEERING PROCESS – 1
LECTURE # 6
2 REQUIREMENTS ENGINEERING PROCESS

The process(es) involved in developing system

requirements is collectively known as the
Requirements Engineering Process
3 RE PROCESS - INPUTS AND OUTPUTS

Existing
systems
information

Stakeholder Agreed
needs requirements

Organizational Requirements System

standards Engineering Process specification

System
Regulations models

Domain
information
4 RE PROCESS – INPUTS

It includes:
• Existing system information
• Information about the functionality of systems to be replaced
• Information about other systems, which interact with the system being
specified
5 RE PROCESS – INPUTS

• Stakeholder needs
• Description of what system stakeholders need from the system to support
their work

• Organizational standards
• Standards used in an organization regarding system development practice,
quality management, etc.
6 RE PROCESS – INPUTS

• Regulations
• External regulations such as health and safety regulations, which apply to
the system

• Domain information
• General information about the application domain of the system
7 RE PROCESS – OUTPUTS

It includes
• Agreed requirements
• A description of the system requirements, which is understandable by
stakeholders and which has been agreed by them
8 RE PROCESS – OUTPUTS

• System specification
• This is a more detailed specification of the system, which may be produced
in some cases
9 RE PROCESS – OUTPUTS

• System models
• A set of models such as a data-flow model, an object model, a process
model, etc., which describes the system from different perspectives
10 RE PROCESS VARIABILITY

• RE processes vary radically from one organization to

another, and even within an organization in different
projects

• Unstructured process rely heavily on the experience of the

people, while systematic processes are based on
application of some analysis methodology , but they still
require human judgment
11 VARIABILITY FACTORS - 1

There are four factors which count towards

the variability of the Requirements
Engineering Process
• Technical maturity
• Disciplinary involvement
• Organizational culture
• Application domain
12 TECHNICAL MATURITY

The technologies and methods used for requirements engineering vary from
one organization to other
• Example Cybersecurity
• Low Maturity: Basic security controls, like firewalls and antivirus software, no
formal policies, and reactive response to security incidents.
• Medium Maturity: Implemented formal cybersecurity frameworks (e.g., NIST,
ISO 27001), regular vulnerability assessments, firewalls, intrusion detection
systems, and employee security training.
• High Maturity: Advanced threat detection systems, automated security
incident response, secure software development lifecycle, continuous monitoring
of networks and systems.
 DISCIPLINARY INVOLVEMENT

The types of engineering and managerial disciplines involved in requirements vary from one organization to another
• Education (Academic Research)
• Example: A university department may initiate a project on the impact of online learning on student performance. This
would involve educational psychologists, computer scientists, data analysts, and faculty members from various subject
areas to design and analyze the research. The team would ensure the findings are valid, reliable, and applicable across
different educational contexts.
• Disciplinary Involvement: Researchers from different academic disciplines—such as psychology, computer science,
and pedagogy—work together to understand and improve educational methods and tools.
14 VARIABILITY FACTORS - 3

• Organizational culture
• The culture of an organization has important effect on all business and
technical processes

• Application domain
• Different types of application system need different types of requirements
engineering process
15 RE PROCESS - 1

Requirement Engineering Process has a formal

starting and ending point in the overall software
development life cycle.
• Begins
• There is recognition that a problem exists and requires
a solution
• A new software idea arises
• Ends
• With a complete description of the external behavior
of the software to be built
16 RE PROCESS - 2

• It is a continuous process in which the related activities are repeated

until requirements are of acceptable quality.
• It is one of the most critical processes of system development
17 RE PROCESS - 3

• Based on the need of individual software projects and

organizational needs, requirements engineering
processes are tailored

• An important point to remember is that

“There is no ideal requirements engineering process!”
18 TWO MAIN TASKS OF RE

Two main tasks need to be performed in the

requirements engineering process.
• Problem analysis
• Analysis of a software problem
• Product description
• Complete specification of the desired external
behavior of the software system to be built. Also
known as functional description, functional
requirements, or specifications
19 PROBLEM ANALYSIS - 1

Problem analysis is the first and

foremost task of requirements
engineering process. It includes:
• Brainstorming, and interviewing.

• Identifying all possible constraints

• Expansion of information
20 PROBLEM ANALYSIS - 2

• Trading off constraints and organizing information

• Complete understanding should be achieved

21 PRODUCT DESCRIPTION

Product description is another task of

requirements engineering process. In
this task we:
• Make decisions to define the
external behavior of the software
product

• Organize ideas, resolve conflicting

views, and eliminate
inconsistencies.
22 WHAT REALLY HAPPENS

It should be kept in mind that

:
“Both problem analysis and product description run in parallel
and iteratively throughout the requirements engineering
process”
23 REQUIREMENTS ENGINEERING
ACTIVITIES

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.
24
REQUIREMENTS ELICITATION

Requirements elicitation activity is performed by

• Determining the system requirements

through consultation with stakeholders,
from system documents, domain
knowledge, and market studies
• Requirements discovery
25 REQUIREMENTS ANALYSIS AND NEGOTIATION
-1
Requirements analysis and negotiation
activity is
performed by
• Understanding the relationships among various
customer requirements and shaping those
relationships to achieve a successful result
• Negotiations among different stakeholders and
requirements engineers
26 REQUIREMENTS ANALYSIS AND NEGOTIATION
-2

• Incomplete and inconsistent information

needs to be tackled here

• Some analysis and negotiation needs to be

done on account of budgetary constraints
27 REQUIREMENTS SPECIFICATION

Requirements specification
includes
• Building a tangible model of requirements
using natural language and diagrams

• Building a representation of requirements

that can be assessed for correctness,
completeness, and consistency
28 REQUIREMENTS DOCUMENT

• Detailed descriptions of the required software system in

form of requirements is captured in the requirements
document

• Software designers, developers and testers are the primary

users of the document
29 REQUIREMENTS VALIDATION

• It involves reviewing the requirements model for consistency and

completeness

• This process is intended to detect problems in the requirements

document, before they are used as a basis for the system development
30 REQUIREMENTS MANAGEMENT

• Although, it is not shown as a separate

activity in RE Process, it is performed
through out the requirements engineering
activities.

• Requirements management asks to

identify, control and track requirements
and the changes that will be made to them
31 SUMMARY

• Requirements engineering is the process by which we

can systematically determine the requirements for a
software product
• It is one of the most critical processes of software life
cycle
• If performed correctly, it sets the software project on a
track which results in a successful project
32 REFERENCES

• ‘Requirements Engineering: Processes and

Techniques’ by G. Kotonya and I. Sommerville,
John Wiley & Sons, 1998
• Software Requirements: Objects, Functions, and
States by A. Davis, PH, 1993
• Software Engineering 6th Edition, by I.
Sommerville, 2000
• Software Engineering 5th Edition, by R. Pressman