SE-3263

Software Requirements
Engineering
Lecture: 02
 Overview [Last Lecture]
Content:
Introduction
Different State-of-the-art definitions
Sources, levels & Importance of Software Requirements
Scope of Requirement Engineering
Role of requirements in Software Engineering
The challenges of the Requirements Engineering
Requirements Engineering Process
 Sequence [Todays Agenda]
Content of Lecture
Process & Software Processes
Process Model & its Types
Requirement Engineering Process
RE Process Variability and its factors
RE Activities
Actors in RE Process
Human and Social Factors
Process Improvement and Process Maturity
Process 6

 A process is an organized set of activities, which transforms inputs to

outputs
 We can use synonyms of process such as: procedure, method, course of
action, etc.
 Processes are essential for dealing with complexity in real world
Examples of Processes 7

 An instruction manual for operating a microwave oven

 An instruction manual for assembling a computer or its

parts

 A procedure manual for operating a motor vehicle radio and

CD player
Software Processes 8

 Software engineering, as a discipline, has many processes

 These processes help in performing different software
engineering activities in an organized manner
 Requires creativity
 Provides interactions between a wide range of different
people
 Helps in engineering judgment
 Requires background knowledge
Examples of Software 9

Processes
 Software engineering development process (SDLC)
 Requirements engineering process
 Design process
 Quality assurance process
 Change management process
Process Models 10

 A process model is a simplified description of a process

presented from a particular perspective
 There may be several different models of the same process
 No single model gives a complete understanding of the
process being modeled
Variations in Process Models 11

 A process model is produced on the anticipated need for

that model. We may need
 A model to help explain how process information has been
organized
 A model to help understand and improve a process
 A model to satisfy some quality management standard
Types of Process Model 12

 Coarse-grain activity models

 Fine-grain activity models
 Role-action models
 Entity-relation models
Coarse-grain Activity Model 13

 This type of model provides an overall picture of the

process
 Describes the context of different activities in the process
 It doesn’t document how to enact a process
 Requirements engineering process is an example of
coarse-grain activity model
Coarse-grain Activity Model of the
14
Requirements Engineering Process

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.
Fine-grain Activity Models 15

 These are more detailed models of a specific process,

which are used for understanding and improving existing
processes
 For Example: Interface Specification
Role-action Models 16

 These are models, which show the roles of different people

involved in the process and the actions which they take
 They are useful for process understanding and automation
 For Example: Stakeholder Model for organization.
Entity-relation Models 17

 The models show the process inputs, outputs, and

intermediate results and the relationships between them
 They are useful in quality management systems
Requirements Engineering 18

Process

The process(es) involved in developing system

requirements is collectively known as Requirements
Engineering Process
RE Process - Inputs and 19
Outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Organizational Requirements System

standards Engineering Process specification

System
Regulations models

Domain
information
RE Process – Inputs 20

 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
RE Process – Inputs 21

 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.
RE Process – Inputs 22

 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
 RE Process – Outputs 23

It includes:
Agreed requirements
A description of the system requirements, which is understandable by
stakeholders and which has been agreed by them
System specification
This is a more detailed specification of the system, which may be produced in
some cases
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
RE Process Variability 24

 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
Variability Factors 25

There are four factors which count towards the

variability of the Requirements Engineering
Process
 Technical maturity
 Disciplinary involvement
 Organizational culture
 Application domain
Variability Factors 26

 Technical maturity
The technologies and methods used for requirements
engineering vary from one organization to other
 Disciplinary involvement
The types of engineering and managerial disciplines
involved in requirements vary from one organization to another
Variability Factors 27

 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
Two Main Tasks of RE 28

There are two main tasks which needs 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
Problem Analysis 29

Problem analysis is the first and foremost task

of requirements engineering process. It
includes:
 Brainstorming, interviewing, eliciting requirements
 Identifying all possible constraints
 Expansion of information
 Trading off constraints and organizing information
 Complete understanding should be achieved
Product Description 30

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 and ambiguities
 What Really Happens 31

It should be kept in mind that :

“Both problem analysis and product description run in parallel and
iteratively throughout the requirements engineering process”
Requirements Engineering 32
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.
Requirements Elicitation 33

Requirements Elicitation activity is performed by

 Determining the system requirements through consultation
with stakeholders, from system documents, domain
knowledge, and market studies
 Requirements acquisition or requirements discovery
Requirements Analysis and 34

Negotiation
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
Requirements Specification 35

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
Requirements Document 36

 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
Requirements Validation 37

 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
Requirements Management 38

 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
Who are Actors? 39

 Actors in a process are the people involved in the

execution of that process
 Actors are normally identified by their roles rather than
individually, e.g., project manager, purchasing director,
and system engineer
Actors in the RE Process 40

 Requirements engineering involves people who are

primarily interested in the problem to be solved (end-users,
etc) as well as people interested in the solution (system
designers, etc.)

 Another group of people, such as health & safety regulators,

and maintenance engineers may be effected by the existence
of the system
Actors in the RE Process 41

 Role-action diagrams are process models which show the

actors associated with different process activities
 They document the information needs of different people
involved in the process
 They use model of prototype software system as part of
requirements elicitation process
 Role-Action Diagram for
42
Software Prototyping
ACTIONS

Establish Select
Understand Develop Evaluate
outline prototyping
problem prototype prototype
requirements system

Req. Engineer End-user

Domain expert Req. Engineer SW Engineer Req. Engineer Domain expert
End-user End-user Project Mgr SW Engineer Req. Engineer
SW Engineer

ROLES
Role Descriptions 43

Role Description
Domain Responsible for proving
Expert information about the
application domain and the
specific problem in that
domain, which is to be solved
Role Descriptions 44

Role Description
System End- Responsible for using the
user system after delivery

Role Description
Requirements Responsible for eliciting and
Engineer specifying the system
requirements
Role Descriptions 45

Role Description
Software Responsible for developing
Engineer the prototype software system

Role Description
Project Responsible for planning and
Manager estimating the prototyping
project
Human and Social Factors 46

 Requirements engineering processes are dominated by

human, social and organizational factors because they always
involve a range of stakeholders from different backgrounds
and with different individual and organizational goals
 System stakeholders may come from a range of technical and
non-technical background and from different disciplines
Stakeholder Types 47

 Software engineers
 System end-users
 Managers of system end-users
 External regulators
 Domain experts
Factors Influencing 48

Requirements
 Personality and status of stakeholders
 The personal goals of individuals within an organization
 The degree of political influence of stakeholders within an
organization
Process Support 49

 One way to minimize errors in the requirements engineering is

to use process models and to use CASE tools
 The most mature CASE tools support well-understood
activities such as programming and testing and the use of
structured methods
 Support for requirements engineering is still limited because
of the informality and the variability of the process
CASE Tools for RE 50

 Modeling and validation tools support the development of

system models which can be used to specify the system and
the checking of these models for completeness and
consistency
 Management tools help manage a database of requirements
and support the management of changes to these
requirements
Requirement Engineering CASE51
Tools
 TopCased— Open Source
 ArgoUML — Open Source
 MonoUML— Open Source
 UMLlet— Open Source
 Other RE tools can be seen at:
 http://www.academia.edu/4407131/Flexible_CASE_Tools_for
_Requirements_Engineering_A_benchmarking_Survey
Requirement Management Tools52

 aNimble — Open Source

 mToo — Open Source
 iPlan —Open Source
 Process Street —Free for initial thirty days
 Other RM tools can be seen at:
 https://www.capterra.com/requirements-management-software
/
Process Improvement 53

 Process improvement is concerned with modifying processes

in order to meet some improvement objectives
 Improvement objectives
 Quality improvement
 Schedule reduction
 Resource reduction
RE Process Problems 54

 Lack of stakeholder involvement

 Business needs not considered
 Lack of requirements management
 Lack of defined responsibilities
 Stakeholder communication problems
 Over-long schedules and poor quality requirements
documents
Process Maturity 55

 Process maturity can be thought of as the extent that an

organization has defined its processes, actively controls these
processes and provides systematic human and computer-
based support for them
 The SEI’s Capability Maturity Model is a framework for
assessing software process maturity in development
organizations
Capability Maturity Model 56

Optimizing
Level 5
Managed
Level 4
Defined
Level 3
Repeatable
Level 2
Initial
Level 1
Capability Maturity Model 57

 CMM Level 1: Initial:- Organizations have an undisciplined process and

it is left to individuals that how to manage the process and which
development techniques to use
 CMM Level 2: Repeatable:- Organizations have basic cost and schedule
management procedures in place. They are likely to be able to make
consistent budget and schedule predictions for projects in the same
application area
 CMM Level 3: Defined:- The software process for both management and
engineering activities is documented, standardized and integrated into a
standard software process for the organization
Capability Maturity Model 58

 CMM Level 4: Managed:- Detailed measurements of both process and

product quality are collected and used to control the process
 CMM Level 5: Optimizing :- The organization has a continuous process
improvement strategy, based on objective measurements, in place
59