Requirement

Engineering
Requirement Engineering Process
 Requirement Engineering (RE) is the process that
requires all of the activities required to create and
maintain a system requirements document.
 RE provides the appropriate mechanism for
understanding ;
1. What customer needs
2. Analyzing need
3. Assessing feasibility
4. Negotiating a reasonable solution
5. Specifying the solution unambiguously
6. Validating the specification
7. Managing requirements as they are transformed into an
operational system.
Requirement Engineering Process
 RE process can be described in five distinct steps

 Requirement Elicitation
 Requirement analysis and negotiation
 Requirement Specification
 System Modeling
 Requirement Validation
 Requirement Management
The Requirements Engineering Process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
Requirement Elicitation

 Ask the customer, user and others what are the

objectives for the system or product.
 What is to be accomplished
 How the system or product fits into the needs of the
business
 How the system or product is to be used on a day to
day basis which quite hard and difficult.
 Somerville and Sawyer suggest a set of detailed
guidelines for requirement elicitation:
 Assess the business & technical feasibility for the
proposed system
 Identify the people who will help specify
requirements and understand their organizational
bias.
 Define the technical environment (e.g Computing
architecture, operating system, telecommunications
needs) into which the system or ;product will be
placed.
 Identify domain constraints
 Define one or more requirement elicitation methods
(e.g interviews, focus groups, team meetings)
 Solicit participation for the collection of different point
of views.
 Identify ambiguous requirements as candidates for
prototyping
 Create usage scenarios
 Factors due to which requirement Elicitation
is difficult

 Scope : If the boundary of the system is ill defined

or the customer / user specify unnecessary details
that may confuse.
 Understanding The customers are not sure what is
needed.
 Volatility The requirements change over time.
 Requirement Elicitation work products :
 A statement of need and feasibility
 A bounded statement of scope for the system or product
 A list of customers, users and stakeholders who participated in
the Reqt Elicitation activity
 A description of system’s technical environment.
 A list of requirements (preferably organized by function) and
domain constraints that apply to each.
 A set omf usage scenarios
 Any prototype developed tobetter define requirements

Each requirement is reviewed by people who participated in

requirement elicitation.
 Requirement Engineering Process

 In reality these processes cannot be performed sequentially

 All process are intertwined and performed repeatedly
 Elicitation is not universally accepted
 Identifying
 Gathering
 Determining
 Formulating
 Extracting
 Exposing
Requirement
 The hardest single part of building a software
system is deciding what to build…. No other part
of the work so cripples the resulting system if
done wrong. No other part is more difficult to
rectify later.
*F.P Brooks

“How can we ensure the specified system properly meets

customer’s needs and satisfy the customer expectation?”
Requirements
 A Software Requirement is a software capability that
must be met or possessed by a software component in
order to satisfy a contract, standard, or specification.
 The source of these Requirements could come from
 Client
 Customer
 Buyers,
 Operators, People
 Users/End user, or system specifications
Requirement Engineering
 The description of the services and constraints are
the requirements for the system and
 The process of
 Finding out,
 Analyzing,
 Documenting and
 Checking these services and Constraints are called
Requirements Engineering.”

Ian Sommerville
Requirement Engineering

 A process in which “what is to be

done” is
 Elicited (produce or draw out a response or reaction)
 Modeled and
 Communicated.
Freeman
Requirement Engineering
 It is the process that involves all of the
activities required to create and maintain a
system requirements document.
Why are requirements important?
 The requirements are how we communicate
 They are the only part that everyone understand

CUSTOMER

USER DEVELOPER

Requirements
 How Programs Are Usually
Written …

The requirements The developers This is how the

specification was understood it in problem is
defined like this that way solved now

This is how the program is

described by marketing
That is the program after This, in fact, is what the
department
debugging customer wanted … ;-)
Why are requirements important?
 Inconsistent and incomplete requirements are the
most frequent causes of the system problems
Incomplete requirements

Lack of user involvement

Lack of resources

Unrealistic expectations

Lack of executive support

Changing requirements

Lack of planning

System no more needed

10% 20% Causes of the failed projects

Wicked problems
 Most large software systems address
wicked problems
 Problems which are so complex that they
can never be fully understood and where
understanding evolves during the system
development
 Therefore, requirements are normally both
incomplete and inconsistent
Requirements Types
 Needs
 are the capabilities and characteristics
required in the software system to solve the
problem.
 Wishes
 are the capabilities and characteristics of the
software system desired by the users.
 Expectations
 are the capabilities and characteristics of the
software system expected by the users.
Formats of SRS
 Production of System Specification
 Written document
 Graphical model
 Formal mathematical model
 Usage scenarios
 Prototype
 Any combination of above
Role of Software Requirements
 Software Requirements serve two major roles
in a developmental effort.
 They describe what to develop and
 Describe when the development is completed.
 Requirement Document
 Contains all the Software Requirements of the
system that is to be developed
 It communicates the customers needs,
wishes, and expectations to the developers of
the system
Role of Software Requirements

A requirement document may include

descriptions of:
 The required computational functionality
 A description of the system behavior
 Guidelines for the user interface
 Technical aspects of the Hardware / Software Interface
 Operational characteristics
Role of Software Requirements

 Second role is to form the basis for determining

 When the software product is finished.
 The verification of the software functionality against the
requirements document serves to demonstrate that the
contractual agreement between the customer and developers
has been met and generally implies the end of the
development phase.
Requirements Types

 Functional Requirements
 The functional requirements define the fundamental actions
that the software must perform.
 The actions describes accepting inputs, processing, and
generating the outputs.
 Behavioral or Non Functional Requirements
 The behavioral requirements define the actions taken when
the software responds to internal and external stimulus. This
includes describing what event causes an activity to start up
and the event that causes it to stop.
Requirements Types

 Performance Requirements
 The performance requirements specify the numeric
requirements that are placed of the software as well as on
the human interaction with the software.
 Examples of performance requirements may include:
 Number of data transactions with in a certain time frame

 Number of simultaneous users

 Number of terminals to be supported

Requirements Types
 Operational Requirements
 Are usability of the software as it communicates with its human users.
This may include information concerning the
 qualifications of the users,
 level of detail for external messages, and
 Graphical User Interface standards.
 The constraint requirements
 Define any restrictions that will impact the software that is being
developed. Constraint requirements deal with:
 Design / Development restrictions. Example: Target hardware and

programming language.
 Environment Restrictions. Example: Software size and resource

utilization.
 Data Restrictions. Example: Maximum number of files and size of

files.
Participants
 Buyer
 The buyers are the individuals that are responsible for
the acceptance of the software.
 A buyer can be an internal department of an
organization, external customer, or the general public.
 Whatever the origins, the buyers are responsible for
contracting or paying for the software system.
 End-User
 The end-users are the individuals who ultimately uses
the system to perform some predefined set of tasks.
 Ultimately, the end-users will be the individuals who
install, operate, and use the software.
 Participants
 Application Experts
 The application experts are the individuals who provide domain
knowledge and supplies a more detailed understanding of the
problem.
 Software Engineers
 The software engineers are the individuals who provide expertise
on software design, prototype development, and technical
feasibility. The software engineers works closely with the end-
users, buyers, and application experts.
 Requirements Engineer
 The Requirements Engineers are the individuals who are
responsible for the identification and documentation of the
requirements. These individuals are also the mediate between
the buyers, end-users, application experts, and the software
engineers.
 Participants Activities
 Context Analysis
 Determines the underlying need of why the software is to be
created.
 The technical, operational, and economic boundaries are
determined and the scope of the software system is documented.
 Requirements Elicitation
 The requirements elicitation activity creates the required
knowledge structure by gathering requirement related information.
 Techniques for requirement Elicitations are :
 Joint Application Development
 Questionnaires
 Interviews
 Observation of operational environments
Participants Activities
 Requirements Assessment
 The requirements assessment activity performs a risk
assessment on the documented software requirements.
 The goal of this activity is to achieve an acceptable level of
risk concerning the potential problems of:
 Inconsistencies with the software requirements
 Ambiguities


Incompleteness
 Exploration of design Feasibility
 The exploration of design feasibility activity is concerned with
assessing technical feasibility and
 Making requirements tradeoffs may require a demonstration
that a feasible software design does exist.
Participants Activities
 All requirements that are identified during the
Requirement Engineering activities are
documented in the Software Requirements
Specification (SRS). The goal of the SRS is to
describe all externally observed behaviors
and characteristics expected of the software
system.
Software Requirements Document

 SRS (Software Requirement specification)

 The official statement of what is required by the
system developers
 The goal of the SRS is to describe all externally
observed behaviors and characteristics expected of
the software system
 Includes user requirements and system requirements
 Standards for SRS
 RUP
 IEEE
 Ian Summerville
Characteristics of SRS
 Correct
 Every requirement stated in the SRS is one that the
software shall meet
 Unambiguous
 Every requirements stated in the SRS only has 1
logical interpretation
 Complete
 The SRS includes all significant requirements
 The SRS includes all realizable classes of input data
 The SRS includes full labels and references to all
figures, tables and diagrams.
Characteristics of SRS
 Consistent
 No subset of individual requirements stated in the SRS
conflict with other individual requirements
 Verifiable
 For every requirement stated in the SRS, there exists
some finite cost-effective process with which a person
or machine can check that the software meets the
requirements
 Modifiable
 The entire SRS has a style and structure such that any
changes to the requirements can be made easily,
completely, and consistently which retaining the
structure and style.
Characteristics of SRS
 Traceable
 For every requirement stated in the SRS, it is clear of
the requirements origin and it is possible to reference
each requirement in future developments.
 Advantages
 The SRS can establish the bases for contractual
agreement between the customer and developers.
 The SRS can establish the bases for performing cost,
schedule, and resource estimates for the
developmental effort.
 The SRS can provide a baseline for verification and
validation of the software.
IEEE Standard
 Introduction

 Purpose of the requirement document

 Scope of the product

 Definitions, acronyms, and abbreviations

 References
IEEE Standard
 General description

 Product Perspective
 Product functions
 User characteristics

 General constraints

 Assumption and dependencies

 Specific Requirements
 Appendices
 Index
The Requirements Engineering Process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 Requirement Engineering Process

 In reality these processes cannot be performed sequentially

 All process are intertwined and performed repeatedly
 Elicitation is not universally accepted
 Identifying
 Gathering
 Determining
 Formulating
 Extracting
 Exposing