Requirement engineering is the process of understanding a client's needs, documenting software requirements, and ensuring the final product meets the client's expectations. It involves eliciting requirements from stakeholders, analyzing and specifying the requirements, and managing changes. The key outputs are a software requirements specification document that formally defines functional and non-functional requirements, and a common understanding between developers and clients.

1. Software
Requirements
analysis &
specifications

2. Requirements Engineering
• 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.

3. Requirements Engineering
1. Requirement engineering is the discipline concerned with understanding
the externally imposed conditions on a proposed computer system,
determining what capabilities will meet these imposed conditions and
documenting those capabilities as the software requirements for the
computer system.
2. The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed.
3. A requirement mandatesthat somethingbe accomplished,transformed,
producedor provided.
3

4. Importance of Requirements
• Makingdesigndecisionswithoutunderstanding allthe
constraintsonthesystemtobedeveloped resultsina
systemwhichfailstomeetcustomer’s expectations.
• Costsofcorrectingerrorsincreasesasthedesign process
advances.
• Anerrordetectedinthemaintenancephaseis20 timesas
costlytofixasanerrordetectedinthe codingstage.

5. Requirements Perspectives
• User requirements
Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
• System requirements
A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client andcontractor.

6. Types of Requirements
1. User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
• Written for customers.
2. System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
• Defines what should be implemented so may be part of a contract between
client and contractor.
• Whom do you think these are written for?
• These are higher level than functional and non-functional requirements,
which these may subsume.
6

7. Types of Requirements
• Functionalrequirements:
• Statementsof services,how the systemshould react to particular
inputs, what functionalities isto beprovided. Functionalrequirements
arenot concernedwith howthese functionsareto beachieved, just
what isto beachieved.
• Non–functionalrequirements:
• dealswith attributes, or properties, of the software ratherthan
functions.Weinclude hereaspectsof the
• softwaresuchasits performance, its usability,itsreliability, anysafety
aspectsandarangeof otherattributes.
• DomainRequirements:
• Requirementsof the applicationdomainof the system, reflect
characteristicsof thatdomain.

8. Requirements Characteristics
• Unambiguous
• Testable (verifiable)
• Clear(Concise,terse, simple, precise)
• Correct
• Understandable
• Feasible
• Independent
• Atomic
• Necessary
• Implementation –free(abstract)

9. Requirements
Characteristics
Besides the criteria for
individual requirements,
3 criteria should apply to
the set of requirements
as a whole:
• Consistent
• Non redundant
• Complete

10. Requirements
engineering
processes
• The processes used for RE vary widely
depending on the application domain,
the people involved and the organisation
developing the requirements
• However, there are a number of generic
activities common to all processes
1. Requirements elicitation
2. Requirements analysis
3. Requirements validation
4. Requirements management

11. Requirements Elicitation:
It is related to the various ways used to gain knowledge about the
project domain and requirements. The various sources of domain
knowledge include customers, business manuals, the existing
software of same type, standards and other stakeholders of the
project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc.
Elicitation does not produce formal models of the requirements
understood. Instead, it widens the domain knowledge of the analyst
and thus helps in providing input to the next stage.

12. Requirements specification:
This activity is used to produce formal software requirement
models. All the requirements including the functional as well as
the non-functional requirements and the constraints are
specified by these models in totality. During specification, more
knowledge about the problem may be required which can
again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow
diagrams(DFDs), function decomposition diagrams(FDDs), data
dictionaries, etc.

13. Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
• The requirements should be consistent with all the other requirements i.e
no two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.

14. The Output
ASoftwareRequirements Specification(SRS)–A formal Document as
the OUTPUToftheSpecificationstage.
• Itis a completedescription ofthe behaviorofasystem developedthat
includes:
• Functional Requirements
• Non- Functional Requirements Constraints
• DesignStrategy Qualityand Standards Architecture
• DevelopmentMethodology

15. Analysis &Specification
• Requirements analysis:
• Theprocessof studying and analysingthe customer and the
user/stakeholder needstoarrive at adefinition of software
requirements
• RequirementsSpecification:
• Adocument that clearly and precisely describes essential
requirements of softwareand external interfaces (functions,
performance, qualityetc.)
• eachrequirement isspecified suchthat its achievement is
capableof being verified bya prescribed method like
inspection,test.

16. Requirement Engineering is the process
characterized for achieving following goals-
• Understanding customer requirements
and their needs
• Analyzing the feasibility of the
requirement
• Negotiating the reasonable solutions
• Specification of an unambiguous solution
• Managing all the requirement
• Finally transforming the requirements of
the project
Requirement engineering
consists of seven different
tasks as follow:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements
Management
Requirements Engineering Tasks