Software requirement enginering

Software Requirements Engineering
Dr. Muhammad Imran Babar
PhD SE
Assistant Professor
Faculty of Engineering Systems
APCOMS, UET Taxila.

ARMY PUBLIC COLLEGE OF MANAGEMENT & SCIENCES, UET TAXILA

Software Requirements
Engineering
Lecture 1

Software Requirement
• A software requirement is an abstract
statement about a service or functionality of
the system.
• Descriptions or specifications of the services
of a system.

Software Requirements Engineering (SRE)
SRE is a process to establish the services
required by the stakeholders from a given
system under given constraints.

Software Requirements Specification (SRS)
A detailed and structured document which
describes the services of the system and is a
kind of contract between client and
contractor.

Types of Software Requirements
 User Requirements
User requirements are written in natural
language and in the forms of diagrams that
a system must fulfill under given constraints.
 System Requirements
A document which describes the different
functions of the system, operational
constraints and services.

Types of Software Requirements
 User Requirements
1. Natural language
2. Structured and in natural language like
forms/templates
3. Graphical notations like boxes, arrows etc.
4. Formal specifications like logic and state
machines.

Requirements Engineering Problems
 Incomplete user and system requirements
 Lack of understanding of requirements
 The requirements are written in a
disorganized way
 Lack of control on change

Reasons of RE Problems
 Different users have different requirements
hence there is a continuous compromise
on the requirements.
 System end-users they have different
requirements.
 The organization who pay has different
requirements.

Requirements Practices
Software professionals are of the view that
 Software development is easy just start
coding.
 Stakeholders will help for next changes after
reviewing the initial iterations of the software
 Requirements engineering is a mere wastage
of time.
These practices are only suitable for smaller
projects and not for large and complex
projects.

RE Tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management

RE Tasks
 Some of these tasks run in parallel
 Are carried out to develop a solid design
of the software
 Are performed to find out the key needs
of the users or stakeholders.

Inception
 A set of questions is asked by the
requirements engineer
 The problem understanding is built
 Who are the stakeholders
 To find out solution for the problem
 The step towards collaboration and
communication
 Sharing of viewpoints.

Set of Questions
 What are the job descriptions of the people?
 Is there any other existing solution that is
currently in use?
 Who are the users?
 What are the current problems that should be
focused?
 What will be the economic benefit of the
given solution?

Requirements Elicitation
 The system boundaries are identified.
 The technical details of the system are
written in an elaborative way.
 What the system should perform?
 To find out the problem domain.
 To manage the requirements change

Requirements Elicitation
 The requirements elicitation is carried out
either by collaborative requirements
gathering or by quality function
deployment.

Quality Function Deployment
 Normal requirements are objectives and
goals of the system as defined during
meetings with the stakeholders or customers
 The expected requirements are implicit
requirements and are not described by the
customer explicitly.
 The exciting requirements are the features of
the system that are beyond customers’
expectations and serve as a satisfying
element for the stakeholders.

Collaborative Requirements Gathering
 Meetings among stakeholders
 Establishment of rules
 An agenda is defined for flow of ideas.
 A definition mechanism is used for
information flow.
 A preliminary solution is given for the said
problem.

 The technique used to translate customer
needs into technical requirements of the
system.
 Helps in finding out the valuable features
and functions for the customer that need
to be deployed.

Helps in identification of three types of
requirements
 Normal requirements
 Expected requirements
 Exciting requirements

Elaboration
 The information gathered during Inception
and Elicitation is refined in this task.
 The refined information is based on technical
details like functions, features and constraint
of the system.
 Use cases are developed
 Classes are identified with their attributes and
relationships

Elaboration
 State machine diagrams are defined
 In this task the functional and behavioral
features of the system are analyzed and
modeled.

Elaboration
Steps Developing Use Cases
 Define actors
 Develop use cases

Elaboration
To analyze a Use Case
 Who are the primary and secondary actors?
 What are the goals of the actors?
 Find out the preconditions.
 Find out the main tasks or functions performed by the
actors.
 The exceptions that should be considered in a
scenario.
 The variations in the interactions of the actors.
 The information needed by an actor from the system.

Negotiation
In this task.
 The conflicts are resolved between
customer and software engineer.
 The requirements priority is defined.
 Risk analysis is carried out.
 The effort is estimated.
 The parties reach to an agreement on a
final set of requirements.

Specification
 The specification or software requirements
specification (SRS) is a final set of
requirements that is required to be
implemented.
 SRS defines all negotiated functional and non-
functional requirements along with given
constraints.
 SRS documents all requirements in graphical
and textual format.

Specification
 The specification or software requirements
specification (SRS) provides information about
functions and objects.
 SRS provides information about internal and
external interfaces.
 Its also about system constraints.
 Describes data requirements.
 SRS explains non-functional requirements like
privacy, security, safety, quality etc.

Validation
 The quality of the requirements is assessed.
 The requirements’ ambiguity is analyzed.
 The ambiguous requirements are detected and
corrective measures are taken.
 The detection of errors and omissions is also
performed for corrective measures.
 Technical reviews are carried out for validation
purposes.
 Prototyping is used for requirements validation

Requirements Management
 During requirements management the
changes in the requirements are
controlled and tracked.
 Requirements are identified by a unique
identifier
 For traceability purposes the requirements
are placed in traceability tables.

HAVE A NICE DAY
Q/A

Software requirement enginering

More Related Content

What's hot

Similar to Software requirement enginering

Recently uploaded

Software requirement enginering