 The process of collecting the software requirement from the client then understand,

evaluate and document it is called as requirement engineering.

 Requirement engineering constructs a bridge for design and construction.
 Requirements are descriptions of the services that a software system must provide
and the constraints under which it must operate
 In practice, requirements engineering isn’t sequential process, it’s an iterative process
in which activities are interleaved.
 For example, you iterate first on the user requirements; elicitation, specification, and
validation, and repeat the same steps for the system requirements.
 User requirements
Statements in natural language plus diagrams of the
services that the systems provides and its operational
contraints. Written for customers

 System requirements
A structured document setting out detailed descriptions of
the system services. Written as a contract between client
and contractor

 Software specification
A detailed software description which can serve as a basis
for a design or implementation. Written for developers
 Requirements engineering (RE) refers to the process of defining, documenting and

maintaining requirements in the engineering design process. It is a common role in

systems engineering and software engineering.

 In requirements engineering, engineers look at a set of data pertaining to the goals and

objectives of the software: how it will work and what are the qualities of the properties it must
have to provide the results needed. Engineers then work forward from these data to look at specific
coding solutions that support these results. Elements of requirements engineering include:
 Requirements solicitation, where a software company gets the requirements from a client
 Requirements analysis
 Requirements specification
 Requirements verification, where engineers confirm that the requirements are accurate
 Requirements management, which matches processes to their requirements
functional and non-functional

 The software requirements are classified into functional requirements and non-
functional requirements.

 Functional requirements : Statements of services that the system should

provide, how the system should react to particular inputs and how the system
should behave in particular situations

 Non-functional requirements : Constraints on the services or functions offered by

the system such as timing constraints, constraints on the development process,
standards, The constrains, like how many process the system can handle
(performance), what are the (security) issues the system needs to take care of such
as SQL injections …
 The rate of failure (reliability), what are the languages and tools will be used
(development), what are the rules you need to follow to ensure the system operates
within the law of the organization (legislative).
 Describe functionality or system services
 Depend on the type of software, expected users and the type of system where the
software is used
 Functional user requirements may be high-level statements of what the system should
do; functional system requirements should describe the system services in detail
Examples
 The user shall be able to search either all of the initial set of databases or select a subset
from it
 The system shall provide appropriate viewers for the user to read documents in the
document store
 Every order shall be allocated a unique identifier (ORDER ID) which the user shall be able to
copy to the account’s permanent storage area
 Product requirements
– Requirements which specify that the delivered product must behave in a particular
way, e.g. execution speed, reliability etc.

 Organisational requirements
– Requirements which are a consequence of organisational policies and procedures,
e.g. process standards used, implementation requirements etc.

 External requirements
– Requirements which arise from factors which are external to the system and its
development process, e.g. interoperability requirements, legislative requirements etc.
 A software requirements specification (SRS) is a description of a software system
to be developed. ... The software requirements specification documentenlists
enough and necessary requirements that are required for the project development.

 A software requirements specification (SRS) is a description of a software

system to be developed. It lays out functional and non-functional requirements, and
may include a set of use cases that describe user interactions that the software must
provide. The SRS fully describes what the software will do and how it will be expected
to perform.
 Managing
change
requirement
 Perform in group to presentation the each of requirement
engineering activities .
 It is a set of activities that help the project team to identify, control and track the requirements

and changes can be made to the requirements at any time of the ongoing project.

 These tasks start with the identification and assign a unique identifier to each of the

requirement.

 After finalizing the requirement traceability table is developed.

 The examples of traceability table are the features, sources, dependencies, subsystems and

interface of the requirement.

Feasibility study
 Find out if the current user needs be satisfied given
the available technology and budget?

Requirements analysis
 Find out what system stakeholders require from the
system

Requirements definition
 Define the requirements in a form understandable to
the customer

Requirements specification
 Define the requirements in detail
 A software requirements specification (SRS) is a description of a software
system to be developed. It lays out functional and non-functional requirements,
and may include a set of use cases that describe user interactions that the software
must provide.
 Requirements set out what the system should do and define constraints on its
operation and implementation
 Functional requirements set of services the system should provide
 Non-functional requirements constrain the system being developed or the
development process
 User requirements are high-level statements of what the system should do
 User requirements should be written in natural language, tables and diagrams
 System requirements are intended to communicate the functions that the system
should provide
 Preface
 Define the expected readers of the document, the version history with a rationale
for version changes and a summary of changes. Author list
 Introduction
 Describes the need for the system and the functions provided as well as how it
interacts with existing systems. Explain how the software fits into the business or
strategic objectives of the organisation.
 Glossary
 Define technical terms used in the document making no assumptions on the
technical expertise of the reader.
 User requirements definition
 Describe the services provided for the user and the non-functional requirements of the
system using natural language, diagrams understandable by customers. Define any product
and process standards.

 System architecture
 High-level overview of the system architecture showing the distribution of functions across
system modules.

 System requirements specification

 Detailed description of the functional and non-functional requirements.
 System models
 Define system models showing relationships between system components, the system and
its environment (object, data-flow models etc.)

 System evolution
 Describe anticipated changes to the system due to hardware evolution and changing user
requirements etc.

 Appendices
 Detailed specific information about the system being developed such as hardware and
database descriptions.

 Index
 Indices of the document including diagrams and functions.
 A limited form of natural language may be used to express requirements
 This removes some of the problems resulting from ambiguity and flexibility and
imposes a degree of uniformity on a specification

Special-purpose forms where designed to

describe the input, output and functions of a
software system

 Often best supported using a forms-based approach

 Ambiguity
 The readers and writers of the requirement
must interpret the same words in the same
way. Natural Language is ambiguous so this
is very difficult

 Over-flexibility
 The same thing may be said in a number of
different ways in the specification which can
lead to confusion

 Lack of modularisation
 Natural language structures are inadequate to
structure system requirements
 The processes used for RE vary widely depending on the application domain, the
people involved and the organization developing the domain, the people involved and
the organization developing the requirements.
 Business Requirements – This comprises the business objectives, how they are currently
executed and what you want the system to accomplish in the future (creating the “As Is”
and “Future” states).

 User Requirements – The functional and technical requirements that employees utilize
when using company systems to complete their job on a daily basis.

 System Requirements – This represents the system integrations, inputs and outputs to
existing systems and what requirements are needed currently, in the future and
integrations between systems. Deeper investigation into this process reveals the
interoperability requirements for systems all system to communicate properly.
 Sometimes called requirements elicitation or requirements discovery.
 • Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system should provide
and the system’s operational constraints.
 • May involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc. These are called stakeholders.
 Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in elicitation.

Problem of scope: The customer give the unnecessary technical detail rather than clarity
of the overall system objective.

Problem of understanding: Poor understanding between the customer and the

developer regarding various aspect of the project like capability, limitation of the
computing environment.

Problem of volatility: In this problem, the requirements change from time to time and it is
difficult while developing the project.
 a. Requirements discovery
 b. Interviewing
 c. Scenarios
 d. Use Cases
 e. Ethnograpy
 Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain requirements are also
discovered at this stage.
 Requirements classification and organization
• Groups related requirements and organizes them into coherent clusters.
 Prioritization and negotiation
• Prioritizing requirements and resolving requirements conflicts.
 Requirements documentation
• Requirements are documented and input into the next round of the spiral.
• The process of gathering information about the proposed and existing systems and
distilling the user and system requirements from this information.
• Sources of information include documentation, system stakeholder, system stakeholders
and the specifications of similar systems.

Example: ATM stakeholders

• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff Counter staff
• Database administrators Database administrators
• Security managers
• Marketing department Marketing department
• Hardware and software maintenance engine
• Banking regulators
 Viewpoints are a way of structuring the requirements to represent the perspectives of
different stakeholders. Stakeholders may be classified under different viewpoints. •
 This multi-perspective analysis is important perspective analysis is important as there is
no single correct to analyze system requirements.
 Interactor viewpoints
 People or other systems that interact directly with the system. In an ATM, the customer customer’s
and the account database are interactor VPs
 Indirect viewpoints
 Stakeholders who do not use the system themselves but who influence the requirements. In an
ATM, management and security staff are indirect viewpoints. viewpoints.
 Domain viewpoints
 Domain characteristics and constraints that influence the requirements. In an ATM, an example
would be standards for inter-bank communications.
 Identify viewpoints using:
 Providers and receivers of system services;
 Systems that interact directly with the system being
specified;
 Regulations and standards;
 Sources of business and non-functional requirements.
 Engineers who have to develop and maintain the system
 Marketing and other business viewpoints.
 In formal or informal interviewing, the RE team puts questions to stakeholders

about the system that they use and the system to be developed.

 There are two types of interview

 Closed interviews where a pre-defined set of questions are answered.

 Open interviews where there is no pre-defined agenda and a range of issues are

explored with stakeholders.

 Normally a mix of closed and open-ended interviewing

 Interviews are good for getting an overall understanding of what stakeholders do

and how they might interact with the system.

 Scenarios are real-life examples of how a system can be used.

 They should include:

 A description of the starting situation;

 A description of the normal flow of events

 A description of what can go wrong

 Information about other concurrent activities;

 A description of the state when the scenario finishes

 Use-cases are a scenario-based
technique in the UML which identify the
actors in an interaction and which
describe the interaction itself.
 • A set of use cases should describe all
possible interactions with the system.
 Sequence diagrams may be used to
add detail to use-cases by showing the
sequence of event processing in the
system
 A social scientists spends a considerable time observing and analyzing how people
actually work.
 People do not have to explain or articulate their work.
 Social and organizational factors of importance may be observed.
 Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models.
 Scope
 Requirements that are derived from the way that people actually work rather than the way which
process definitions suggest that they thought to work.
 Requirements that are derived from cooperation and awareness of other people’s activities.

 Focused ethnography
 Developed in a project studying the air traffic control process
 Combines ethnography with prototyping
 Prototype development results in unanswered questions which focus the ethnographic analysis.
 The problem with ethnography is that it studies existing practices which es which may have some
historical basis which is no longer relevant.
 Concerned with demonstrating that the requirements define the system that the
customer really wants.
 Requirements checking
 Validity. Does the system provide the functions which best support the . Does the system
provide the functions which best support the customer customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer included?
 Realism. Can the requirements be implemented given available budget . Can the
requirements be implemented given available budget and technology
 Verifiability. Can the requirements be checked?
 Requirements reviews
 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.
 Involve in two main topic:
 a. Requirements management planning
 b. Requirements change management

 Requirements management is the process of managing changing process during the

requirements engineering process and system development.
 Requirements are inevitably incomplete and inconsistent
 New requirements emerge during the process as business needs change and better
understanding of the system is developed;
 Different viewpoints have different requirements and these are often contradictory.
 During the requirements engineering process,
you have to plan:
 Requirements identification
 How requirements are individually identified;

 A change management process

 The process followed when analyzing a
requirements change;
 Traceability policies
 The amount of information about requirements
relationships that is maintained;
 CASE tool support CASE tool support
 The tool support required to help manage
requirements change;
 Requirements management is the process of documenting, analysing, tracing,
prioritizing and agreeing on requirements and then controlling change and
communicating to relevant stakeholders. It is a continuous process throughout a
project.
 Should apply to all proposed changes to the requirements
 Principal stages
 Problem analysis. Discuss requirements problem and propose change;
 Change analysis and costing. Assess effects of change on other r Change analysis and
costing. Assess effects of change on other requirements;
 Change implementation. Modify requirements document and other documents to reflect
change.
 What the contents of software requirement documentation????

 Follow IEEE Recommended Practice for Software Requirements Specifications, IEEE

Std 830-1993 (Revision of IEEE Std 830-1984)
The Parts of an SRS
 Table of Contents
 1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, an abbreviations
1.4 References
1.5 Overview
 2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
 3. Specific requirements
 Appendixes
 The requirements engineering process includes a feasibility study, requirements
elicitation and analysis, requirements specification and requirements management.
 Requirements elicitation and analysis is iterative involving domain understanding,
requirements collection, classification, structuring, prioritization and validation.
 Systems have multiple stakeholders with different requirements
 Social and organization factors influence system requirements
 Requirements validation is concerned with checks for validity, consistency,
completeness, realism and verifiability.
 Business changes inevitably lead to changing requirements.
 Requirements management includes planning and change management.