0% found this document useful (0 votes)
21 views29 pages

Chapter#01 Requirement Engineering Process

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process, involving activities like inception, elicitation, specification, negotiation, validation, and management. The RE process includes a feasibility study, requirement elicitation and analysis, software requirement specification, validation, and management, with various methods such as interviews, surveys, and prototyping used to gather requirements. Effective change management is also crucial in adapting to evolving requirements throughout the project lifecycle.

Uploaded by

mk4867044
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views29 pages

Chapter#01 Requirement Engineering Process

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process, involving activities like inception, elicitation, specification, negotiation, validation, and management. The RE process includes a feasibility study, requirement elicitation and analysis, software requirement specification, validation, and management, with various methods such as interviews, surveys, and prototyping used to gather requirements. Effective change management is also crucial in adapting to evolving requirements throughout the project lifecycle.

Uploaded by

mk4867044
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 29

Software Requirement

Engineering
Lecture#01
Requirements Engineering (RE)
 Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering
design process. Requirement engineering provides the
appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly,
validating the specifications and managing the requirements as
they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.
Requirement Engineering Process
 Process involves following activities:
Inception:
The initial phase where the project is conceptualized. The primary focus is on understanding the problem, identifying stakeholders, and defining high-level
project goals. The aim is to gather preliminary requirements and set the scope.

Elicitation
This phase involves gathering detailed requirements from stakeholders through interviews, surveys, observations, brainstorming sessions, etc. The
objective is to collect as much information as possible about the system’s functionalities, constraints, and business needs.

Specification:
In this stage, the gathered requirements are documented clearly and precisely, often using formal methods such as requirements specifications, use cases,
or user stories. The purpose is to ensure that all stakeholders have a shared understanding of what the system should do.

Negotiation:
Requirements can sometimes be conflicting or infeasible within the given constraints (time, budget, technology). In the negotiation phase, stakeholders
prioritize and resolve any conflicts. Compromises are made to balance stakeholder expectations and system feasibility.

Validation:
Once the requirements are documented and agreed upon, validation ensures that the documented requirements accurately represent what the
stakeholders need and are feasible to implement. This process might include reviews, prototyping, or simulations.

Management:
Managing requirements throughout the project lifecycle is critical to adapting to changes. This involves tracking requirements, maintaining their integrity,
and ensuring that any modifications align with project goals. Effective requirement management ensures that the project stays on track despite changes or
evolving needs.
Requirement Engineering Process
 It is a five-step process, which includes -
i. Feasibility Study
ii. Requirement Elicitation and Analysis
iii. Software Requirement Specification
iv. Software Requirement Validation
v. Software Requirement Management
Feasibility Study:

The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to
change and conformable to established standards.
 Technical Feasibility - Technical feasibility evaluates the current

technologies, which are needed to accomplish customer


requirements within the time and budget.
 Operational Feasibility - Operational feasibility assesses the

range in which the required software performs a series of levels to


solve business problems and customer requirements.
 Economic Feasibility - Economic feasibility decides whether the

necessary software can generate financial profits for an


organization.
Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements


are identified with the help of customers and existing systems processes, if
available.
Analysis of requirements starts with requirement elicitation. The requirements
are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.
 Problems of Elicitation and Analysis

◦ Getting all, and only, the right people involved.


◦ Stakeholders often don't know what they want
◦ Stakeholders express requirements in their terms.
◦ Stakeholders may have conflicting requirements.
◦ Requirement change during the analysis process.
◦ Organizational and political factors may influence system requirements.
Requirements Elicitation Activities:
Requirements elicitation includes the subsequent activities.
Few of them are listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the

system is going to be applied must be understood.


 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements Elicitation Methods:
There are a number of requirements elicitation methods. Few
of them are listed below –
 Interviews
 Brainstorming Sessions
 Questionnaires
 Surveys
 Use Case Approach
 Prototyping
 Observations
Interviews:

 Objective of conducting an interview is to understand the


customer’s expectations from the software.
 It is impossible to interview every stakeholder hence
representatives from groups are selected based on their
expertise and credibility.
 Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context
free questions may be asked to understand the problem.
 In structured interview, agenda of fairly open questions is
prepared.
 Sometimes a proper questionnaire is designed for the interview.
Brainstorming Sessions:

 It is a group technique
 It is intended to generate lots of new ideas hence providing

a platform to share views


 A highly trained facilitator is required to handle group bias

and group conflicts.


 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of

requirements and their priority if possible.


Use Case Approach
 This technique combines text and pictures to provide a better understanding of the requirements. The use
cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the
system. The components of the use case design includes three major things – Actor, Use cases, use case
diagram.
 Actor –
It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a
person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
◦ Primary actors – It requires assistance from the system to achieve a goal.
◦ Secondary actor – It is an actor from which the system needs assistance.
 Use cases –
They describe the sequence of interactions between actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of use cases specifies all possible ways to use the
system.
 Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a system. It
captures the functional aspect of the system.
◦ A stick figure is used to represent an actor.
◦ An oval is used to represent a use case.
◦ A line is used to represent a relationship between an actor and a use case.
 Surveys
Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
 Questionnaires

A document with pre-defined set of objective questions


and respective options is handed over to all stakeholders to
answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some
issue is not mentioned in the questionnaire, the issue might be
left unattended.
 Prototyping
Prototyping is building user interface without adding detail functionality
for user to interpret the features of intended software product. It helps giving
better idea of requirements. If there is no software installed at client’s end for
developer’s reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
 Observation

Team of experts visit the client’s organization or workplace. They observe


the actual working of the existing installed systems. They observe the workflow
at client’s end and how execution problems are dealt. The team itself draws
some conclusions which aid to form requirements expected from the software.
Software Requirement Specification:

Software requirement specification is a kind of document


which is created by a software analyst after the requirements
collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of
the analyst to write the requirement in technical language so
that they can be understood and beneficial by the
development team.
The models used at this stage include ER diagrams, data flow
diagrams (DFDs), function decomposition diagrams (FDDs),
data dictionaries, etc.
Software Requirement Validation:

After requirement specifications developed, the requirements


discussed in this document are validated. The user might
demand illegal, impossible solution or experts may misinterpret
the needs. Requirements can be the check against the following
conditions -
 If they can practically implement

 If they are correct and as per the functionality and specially of

software
 If there are any ambiguities

 If they are full

 If they can describe


Requirements Validation Techniques

 Requirements reviews/inspections: systematic manual


analysis of the requirements.
 Prototyping: Using an executable model of the system to

check requirements.
 Test-case generation: Developing tests for requirements

to check testability.
 Automated consistency analysis: checking for the
consistency of structured requirements descriptions.
Software Requirement Management
 Requirement management is the process of managing
changing requirements during the requirements
engineering process and system development.
 New requirements emerge during the process as business

needs a change, and a better understanding of the system


is developed.
 The priority of requirements from different viewpoints

changes during development process.


 The business and technical environment of the system

changes during the development.


Change Management in Software
Engineering
 Change management is a systematic approach to
identifying and managing changes to objectives and
artifacts caused either by shifting market requirements or
poor understanding of what a client expects. It is
represented by techniques and manners for a company to
track and manage a change during the development
process. Whenever there is a change to requirements,
technologies, or code in the software, the management
process begins.
 Changes may be introduced for different reasons in every
organization, no matter how big or small it is. For example,
it can be a new idea accepted in a business environment, a
new vision of a product, introduced by a client, a poor
analysis of a process, an improvement in design,
miscommunication in requirements, or not meeting clients’
expectations by understanding the needs improperly.
Management is a structured process with a set of specific
principles and steps.
Process of Change Management :
When any software application/product goes for any changes in an
IT environment, it undergoes a series of sequential processes as
follows:
1. Creating a request for change

2. Reviewing and assessing a request for change

3. Planning the change

4. Testing the change

5. Creating a change proposal

6. Implementing changes

7. Reviewing change performance

8. Closing the process


Importance of Change
Management :
 For improving performance
 For increasing engagement
 For enhancing innovation
 For including new technologies
 For implementing new requirements
 For reducing cost
Source of Change :

There may be multiple reasons involved during the


development process for which certain changes are required to
be implemented in the product. These sources are as follows :
 Business reorganization
 New Market conditions
 New equipment
 Fixing any bugs/errors
 New customer needs
 Performance or reliability improvement
 Budgetary or scheduling constraints
Inputs and outputs for RE Process
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
RE process variability
 RE processes vary radically from one organisation to another
◦ Factors contributing to this variability include
◦ Technical maturity
 The technology and methods used for requirements engineering vary from one
organization to another
◦ Disciplinary involvement
 The types of engineering and managerial disciplines involved in requirements
engineering vary from one organization to another
◦ Organisational culture
 The culture has an important effect on all processes , as the culture varies, so does
the requirements engineering process
◦ Application domain
 Different types of application domains have different types of requirements
engineering process
There is therefore no ‘ideal’ requirements engineering process
Actors in the RE process
 Actors in a process are the people involved in the execution
of that process
 Actors are normally identified by their roles rather than individually
 Requirements engineering involves actors who are primarily
interested in the problem to be solved (end-users, etc) as well
actors interested in the solution (system designers, etc.)
 Role-action diagrams document which actors are involved in
different activities
RAD for software prototyping

ACTIONS

Establish Select Develop Evaluate


Understand prototyping
problem outline prototype prototype
requirements system

Req. engineer Software Req. engineer End-user


Req. engineer engineer Domain expert
Domain expert End-user Software
End-user Project manager engineer Req. engineer
Software engineer

RO LES
Role descriptions

Ro l e Des cri pti o n


Domain expert Responsible for providing information about the
application domain and the specific problem in that
domain which is to be solved.
System end-user Responsible for using the system after delivery
Requirements engineer Responsible for eliciting and specifying the system
requirements
Software engineer Responsible for developing the prototype software
system
Project manager Responsible for planning and estimating the
prototyping project
Benefits from a High-Quality
Requirements Process
 Fewer requirements defects
 Reduced development rework
 Fewer unnecessary features
 Lower enhancement costs
 Faster development
 Reduced scope creep
 Reduced project chaos
 More accurate system-testing
 Higher customer and team member satisfaction

You might also like