Requirement Engineering,

Architecture and Design

Chapter One
Introduction to Software Requirements
Engineering & Processes in Requirements
Engineering

Sem. I – 2023
1
 Introduction

Information systems are increasingly becoming an integral part of our everyday,

for correct and efficient functioning.
Requirements specification plays a central role in the process of correct
understanding of the needs of the system’s customers or users.
The process of developing a requirements specification has been called
Requirements Engineering
Definition of Requirements
A condition or capacity needed by a user to solve a problem or achieve an
objective.
A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed documents.
A documented representation of a condition or capability as in (1)or (2).
In General, requirements fall into two broad categories:
Market-driven
Customer-specific
 Introduction
Comparisons
ComparisonsBetween
BetweenMarket-Driven
Market-Drivenand
andCustomer-Specific
Customer-SpecificProjects:
Projects:

3
 Requirements - An Organizational Perspective

The
The contribution
contribution of
of information
information systems
systems toto organisations
organisations can
can be
be examined
examined inin
terms
termsof:
of:
Automating
Automatingproduction
productionby byreducing
reducingthe thecost
costof
ofthe
theprocesses
processesthat
thatmake
makeup up
production.
production.
Informing
Informing decision
decision makers
makers through
through the the exploitation
exploitation ofof automated
automated
processes.
processes.
Transforming
Transforming thethe organization
organization inin aa way
way that
that management
management and and business
business
processes
processesmake
makethethebest
bestuse
useof
ofinformation
informationtechnology
technology
The
Thedevelopment
developmentof ofISIS
Not
Notonly
onlydesigning
designingdatabase
databasestructures
structuresandandalgorithms.
algorithms.
Understanding
Understandingthe theneeds
needsof
ofindividuals
individualsandandother
otherstakeholders
stakeholderswithin
withinthe
the
enterprise.
enterprise.
Ensuring
Ensuringthat
thatthe
thesystem
systemmeets
meetsuser
userrequirements
requirementsandandbusiness
businessstrategy.
strategy.
 Requirements - An Organizational Perspective

Relationship
Relationship between
between the
the ‘enterprise’,
‘enterprise’, ‘system’
‘system’and
and
‘system
‘system user’
user’domains
domains

5
 Requirements - An Organizational Perspective

Requirements
RequirementsSpecification
Specificationfrom
froman
anEnterprise
EnterprisePerspective
Perspective

6
 Requirements - An Organizational Perspective
Requirements
Requirements Engineering
Engineering
Requirements
Requirements engineering
engineering isis about
about establishing
establishing thethe ‘connection’
‘connection’between
between the
the
need
needfor
forsome
somechange
changewithin
withinan anorganisational
organisationalframework
frameworkand andthe
thetechnology
technology
that
thatcould
couldbring
bringabout
aboutsuch
suchaachange.
change.
Or
Or
Requirements
Requirementsengineering
engineeringcan canbebeconsidered
consideredas asaaway
wayofofmanaging
managingchange.
change.
Requirements
Requirementsengineering
engineeringinvolves:
involves:
An
Anunderstanding
understandingatataaconceptual
conceptuallevel
levelof
ofthe
thecurrent
currentstatus
status
AA definition
definition ofof the
the change
change inin terms
terms ofof the
the transition
transition from
from the
the ‘old’
‘old’
conceptual
conceptualsituation
situationtotoaa‘new’
‘new’target
targetconceptual
conceptualsituation
situation
The
Theimplementation
implementationof ofthe
thechange
changeininterms
termsof ofthe
thenewnewcomponents
componentsof ofthe
the
system
system
The
The integration
integration of
of this
this new
new implementation
implementation inin the the environment
environment which
which
contained
containedsome
somelegacy
legacysystem.
system.

7
 Requirements - A Software Perspective

Software
Software Requirements
Requirements Engineering
Engineering
Software
Software Engineering
Engineering isis aa systematic
systematic approach
approach toto thethe development,
development,
operation,
operation,maintenance,
maintenance,and andretirement
retirementof ofsoftware
software
Each
Eachofofthese
thesephases
phasescancanbebeseen
seenfrom
fromaadynamic
dynamicviewpoint
viewpointas asaaprocess
process
Process
Process isis aa unique,
unique, finite
finite course
course ofof events
events defined
defined by
by its
its purpose
purpose oror by
by its
its
effect,
effect,achieved
achievedunderundergiven
givenconditions
conditions
InIn Software
Software Engineering,
Engineering, Errors
Errors inin the
the requirements
requirements definition
definition stage
stage resulted
resulted
inincostly
costlymaintenance
maintenanceof ofsoftware
softwaresystems
systemsatatbest
bestand
andtotal
totalrejection
rejectionatatworst
worst
AsAsaaconsequence,
consequence,Requirements
RequirementsEngineering
Engineeringwas wasestablished
establishedas asaasub
subfield
fieldof
of
Software
SoftwareEngineering
Engineering
Defining
Defining the the software
software architecture
architecture (structure),
(structure), components,
components, modules,
modules,
interfaces,
interfaces, test
test approach,
approach, and
and data
data for
for aa software
software system
system toto satisfy
satisfy specified
specified
requirements
requirements

8
 Requirements - A Software Perspective

Software
Software Requirements
Requirements Engineering
Engineering
Different
Differentmodels
modelsof ofsoftware
software
Method
Method isis aa prescription
prescription of
of steps
steps that
that need
need toto be
be employed
employed inin order
order toto
achieve
achieveaaspecified
specifiedresult
result
Procedure
Procedureisisaasequence
sequenceofofactions
actionsthat
thatmust
mustbebeperformed.
performed.
Tool
Tool isisthe
themachinery
machineryused
usedtotoperform
performsome
someaction
actionas aspart
partof
ofaaprocedure.
procedure.

Three
Threekey
keyelements
elementsdevelopment
developmentof ofaaquality
qualityproduct.
product.
Requirements
Requirements Specification
Specification concerns
concerns of of customers
customers and and users,
users,
Functionality
Functionality of
of the
the system
system and
and the
the constraints
constraints that
that must
must bebe satisfied.
satisfied.
(both
(bothsystem
systemand
andorganisational
organisationalconstraints).
constraints).
System
System Specification
Specification isis concerned
concerned withwith the
the definition
definition of
of the
the system
system
boundary
boundaryand
andthe
theinformation
informationused
usedininthe
theinteraction
interactionofofthe
thesystem
systemand
anditsits
environment.
environment. This
This specification
specification represents
represents aa ‘black
‘black box’
box’ view
view isis aa
sequence
sequenceofofactions
actionsthat
thatmust
mustbe beperformed.
performed.
9
 Requirements - A Software Perspective

Software
Software Project
Project Management
Management
Architectural
ArchitecturalDesign
Designrepresents
representsaahigh-level
high-levelview
viewofofthe
thesystem’s
system’sinternal
internal
design.
design. isis the
the machinery
machinery used
used toto perform
perform some
some action
action as
as part
part of
of aa
procedure.
procedure.
Detailed
Detailed Design
Design represents
represents aa decomposition
decomposition of of the
the system
system andand
concentrates
concentrateson onthe
thedetails
detailsof
ofindividual
individualcomponents.
components.
Implementation
Implementation isis concerned
concerned with
with the
the software
software components
components that
that finally
finally
realise
realisethe
theoriginal
originaluser
userrequirements.
requirements.

10
 Requirements - A Software Perspective

Software
Software Development
Development Process
Process
Software
Softwaredevelopment
developmentprocess
processconsists
consistsof ofaanumber
numberof ofdistinct
distinctactivities
activities
Developing
Developingaasystem
systemconstitutes
constitutesaadesign
designactivity.
activity.
Properties
Propertiesof
ofthe
thedesign
designprocess:
process:
(a)
(a)aaset
setof
ofrequirements
requirementstotobe bemet
metbybysome
someartefact,
artefact,
(b)
(b)the
theoutput
outputof
ofthe
theprocess
processisissome
somedesign,
design,
(c)
(c) the
the goal
goal of
of the
the designer
designer isis toto produce
produce aa design
design such
such that
that ifif an
an
implementation
implementationof ofthis
thisdesign
designwere
weretotomaterialise
materialisethen
thenthe
theartefact
artefactwould
would
satisfy
satisfythe
therequirements
requirements
(d)
(d) the
the designer
designer hashas nono knowledge
knowledge of of any
any design
design that
that satisfies
satisfies thethe
requirements.
requirements.

11
 Requirements - A Software Perspective

Software
Software Development
Development Process
Process
Characteristics
Characteristicsrecognized
recognizedininthethesoftware
softwaredevelopment
developmentprocess:
process:
The
Thesoftware
softwaredevelopment
developmentprocess
processinvolves
involvesthethegeneration
generationof ofaanumber
numberofof
different
differentmodels
models
The
Thesoftware
softwaredevelopment
developmentprocess
processcan
canbebeviewed
viewedasasaaseries
seriesofofsteps
steps
These
These steps
steps are
are goal
goal driven
driven and
and can
can be
be regarded
regarded as
as transitions
transitions between
between
representations,
representations, preserving
preserving the
the semantic
semantic content,
content, as
as refinements
refinements on on these
these
representations
representationsare
areapplied.
applied.
Reasons
Reasonsfor
forSoftware
Softwaredoes
doesnot
notsatisfy
satisfyall
allrequirements:
requirements:
Software
Softwareisisnot
notmade
madeofofany
anyphysical
physicalsubstance
substanceititcannot
cannotbebedescribed
describedinin
standard
standardphysical
physicaldescriptions
descriptionssuch
suchasasmaterial,
material,colour,
colour,dimensions
dimensionsetc.
etc.
Described
Describedininterms
termsof
ofintangible
intangiblecharacteristics
characteristicsof ofthe
thesituations,
situations,tasks
tasksand
and
environments
environmentsininwhich
whichpeople
peopleuse
useit.
it.
Software
Softwareusers
usersbest
bestunderstand
understandandanddescribe
describetheir
theirown
ownwork;
work;
Software
Softwareexperts
expertsare
aremore
morefamiliar
familiarwith
withtheir
theirdomain-software
domain-software
12
 Requirements Specification

What
What isis Requirement
Requirement Specification
Specification ??
Documenting
Documentingrequirements
requirementsforforsoftware
softwareconstruction
constructionisisan
anactivity
activitytermed
termed
requirements
requirementsspecification.
specification.
aarequirements
requirementsspecification
specificationrepresents
representsboth
bothaamodel
modelof
ofwhat
whatisisneeded
neededand
andaa
statement
statementofofthe
theproblem
problemunder
underconsideration.
consideration.
AArequirements
requirementsspecification,
specification,ranging
rangingfrom
frominformal
informalnatural
naturallanguage
languagetext
texttoto
more
moreformal
formalgraphical
graphicaland
andmathematical
mathematicalnotations.
notations.
The
Thestructure
structureof
ofthe
thespecification
specificationitself
itselfvaries
variesaccording
accordingtotodifferent
differentstandards
standards
and
andpractices
practices

13
 Requirements Specification

Purpose
Purpose of
of Requirement
Requirement Specification
Specification
First,
First, To
To correctly
correctly understand
understand the the needs
needs of
of the
the customer
customer andand user
user of
of the
the
intended
intendedsystem.
system.
Second,
Second, Used
Used for
for clarifying
clarifying aa situation
situation about
about the
the intended
intended system
system oror its
its
environment
environmenti.e. i.e.the
theorganizational
organizationalcontext.
context.
Third,
Third, the
the specification
specification maymay be be part
part of
of contractual
contractual arrangements,
arrangements, aa
situation
situation that
that may
may become
become especially
especially relevant
relevant when
when an an organization
organization
wishes
wishes toto procure
procure aa system
system fromfrom some
some vendor
vendor rather
rather than
than develop
develop itit ‘in
‘in
house’
house’
Fourth,
Fourth, For
For evaluating
evaluating thethe final
final product
product and
and could
could play
play aa leading
leading role
role inin
any
anyacceptance
acceptancetests
testsagreed
agreedbetween
betweensystem
systemconsumer
consumerand andsupplier.
supplier.

14
 Requirements Specification

Purpose
Purpose of
of Requirements
Requirements Specification
Specification
The
The traditional
traditional view
view of of aa requirements
requirements specification
specification isis that
that ofof aa functional
functional
specification
specificationi.e.i.e.aadefinition
definitionof ofthe
thedesired
desiredservice
serviceofofthe
theintended
intendedsystem.
system.
AAfunctional
functional requirements
requirements specification
specification isis the
the description
description of of the
the fundamental
fundamental
functions
functionsof ofthe
thesoftware
softwarecomponents
componentsthat thatmake
makeup upthe
thesystem.
system.
Functions
Functionsarearetherefore,
therefore,specified
specifiedininterms
termsof ofinputs,
inputs,processing
processingand andoutputs.
outputs.
AA dynamic
dynamic viewview of of aa system’s
system’s functionality
functionality would
would needneed toto consider
consider aspects
aspects
such
such asas control
control (e.g.
(e.g. sequencing
sequencing and and parallelism),
parallelism), timing
timing of of functions
functions (e.g.
(e.g.
starting
starting and
and finishing),
finishing), as as well
well asas the
the behaviour
behaviour of of the
the system
system inin terms
terms ofof
exceptional
exceptionalsituations.
situations.
The
The specification
specification of of ‘real-world’
‘real-world’entities
entities and
and their
their relationships,
relationships, particularly
particularly
for
for data-centred
data-centred systems,
systems, needneed toto be be defined
defined atat appropriate
appropriate levels
levels ofof
abstraction
abstractionandandrelated
relatedtotodescriptions
descriptionsof ofsystem
systemfunctions.
functions.

15
 Requirements Specification

Requirements
Requirements Specification
Specification &
& System
SystemArchitecture
Architecture
Requirements
Requirementsspecification
specificationshould
shoulddefine
definethethe
‘what’
‘what’--aadescription
descriptionof
ofthe
theproblem
problemininhand
hand
and
andnot
notthe
the
‘how’
‘how’--the
theway
waythat
thatthe
theproblem
problemisistotobe
besolved.
solved.
There
Thereareareaanumber
numberof offactors,
factors,that
thatmake
makeaadistinction
distinctionbetween
betweenthethe‘what’
‘what’and
and
the
the‘how’
‘how’. .
The
The requirements
requirements specification
specification isis one
one that
that goes
goes beyond
beyond the
the description
description of of
system
system functionalities.
functionalities. AA functional
functional specification
specification should
should be
be oneone view
view
supplemented,
supplemented,or oreven
evenmotivated
motivatedby bytwo
twoother
otherperspectives.
perspectives.
First,
First, an
an understanding
understanding should
should bebe gained
gained ofof the
the domain
domain within
within which
which thethe
intended
intendedsystem
systemwill
willbe
befirmly
firmlyembedded.
embedded.
Second,
Second, the
the constraints
constraints that
that can
can be
be placed
placed onon the
the system
system environment
environment or or its
its
development,
development, known
known as as nonfunctional
nonfunctional requirements
requirements (NFRs)
(NFRs) (e.g.
(e.g. security,
security,
availability,
availability,portability,
portability,usability,
usability,performance,
performance,etc.).
etc.).
16
 Requirements
Software Project Specification
Management Fundamentals

Conceptual
ConceptualFramework
Frameworkfor
forRequirements
RequirementsSpecifications
Specifications
Requirements
Requirements specification
specification isis shown
shown toto constitute
constitute an
an interrelated
interrelated set
set of
of
descriptions
descriptions inin three
three domains
domains namely,
namely, the
the enterprise,
enterprise, functional
functional and
and non-
non-
functional
functionaldomains.
domains.

17
 Requirements Engineering

What
What isis Requirements
Requirements Engineering
Engineering
The
The systematic
systematic process
process of
of developing
developing requirements
requirements through
through anan iterative
iterative co-
co-
operative
operative process
process of of analyzing
analyzing thethe problem,
problem, documenting
documenting the the resulting
resulting
observations
observationsininaavariety
varietyofofrepresentation
representationformats
formatsand
andchecking
checkingthetheaccuracy
accuracy
ofofthe
theunderstanding
understandinggained.
gained.
Requirements
Requirements Engineering
Engineering consists
consists ofof thethe knowledge
knowledge elicitation,
elicitation,
representation
representationand andvalidation
validationcycle.
cycle.
The
The success
success of
of the
the requirements
requirements engineering
engineering process
process often
often depends
depends on on the
the
ability
abilitytotoproceed
proceedfrom
frominformal,
informal,fuzzy
fuzzyindividual
individualstatements
statementsof ofrequirements
requirements
totoaaformal
formalspecification
specificationthat
thatisisunderstood
understoodand
andagreed
agreedbybyall
allstakeholders
stakeholders
The
The transition
transition from
from informal
informal toto formal
formal requirements
requirements constitutes
constitutes aa
conceptualization
conceptualization activity
activity by
by using
using domain
domain knowledge
knowledge partly
partly expressed
expressed inin
descriptions
descriptions of of the
the enterprise,
enterprise, andand partly
partly inin existing
existing requirements
requirements
specifications
specifications. .

18
 Requirements Engineering
Insights
Insights of
of requirements
requirements &
& requirements
requirements analysis
analysis
Analysis
Analysis problems,
problems, atat their their inception,
inception, have
have ill-defined
ill-defined boundaries,
boundaries,
structure,
structure, and
and aa sufficient
sufficient degree
degree of of uncertainty
uncertainty about
about thethe nature
nature and
and
makeup
makeupof ofthe
thesolution.
solution.
Requirements
Requirements are are found
found inin organizational
organizational contexts,
contexts, withwith associated
associated
conflicts
conflictsononexpectations
expectationsand anddemands
demandsabout aboutsome
someintentional
intentionalsystem.
system.
The
Thesolutions
solutionstotoanalysis
analysisproblems
problemsare areartificial.
artificial.That
Thatis,is,they
theyare
aredesigned
designed
and
andhence
hencemany
manypotential
potentialsolutions
solutionsexistexistfor
forany
anyoneoneproblem.
problem.
Analysis
Analysisproblems
problemsare aredynamic.
dynamic.
Solutions
Solutions toto analysis
analysis problems
problems require
require interdisciplinary
interdisciplinary knowledge
knowledge and and
skill.
skill.
The
The knowledge
knowledge base base of
of the
the systems
systems analyst
analyst isis continually
continually evolving
evolving andand
the
theanalyst
analystmust
mustbe beready
readytotoincorporate
incorporatechanges
changesininthe thetechnology
technologyand andtoto
participate
participatewith
withusers
usersinindifferent
differentways.ways.
The
The process
process ofof analysis
analysis itself,
itself, isis primarily
primarily cognitive
cognitive inin nature,
nature, requiring
requiring
the
the analyst
analysttoto structure
structure anan abstract
abstractproblem,
problem,process
processdiverse
diverseinformation,
information,
and
anddevelop
developaalogical
logicaland
andinternally
internallyconsistent
consistentsetsetof
ofspecifications.
specifications. 19
 Processes in Requirements Engineering
A Framework for Requirements Engineering Processes
Contemporary software methods do not prescribe a formal Requirements
Engineering process. .
Requirements engineering is easier described by its products than its processes..
A framework for describing Requirements Engineering processes can be
constructed by considering three fundamental concerns of Requirements
Engineering:
Understanding a problem ('what the problem is')
Formally describing a problem
Attaining an agreement on the nature of the problem
The current literature on software requirements, classifies activities in terms:
Acquisition
Elicitation
Analysis
Specification
Validation
 A Framework for Requirements Engineering Processes

In order to avoid the confusion, processes proposed here are:

Elicitation
Specification
Validation
Each Requirements Engineering process is described in terms of:
The purpose of the process
The input to the process and its origins
The activities which take place during the process and techniques used
The final and intermediate deliverables
The interaction with other Requirements Engineering processes

21
 A Framework for Requirements Engineering Processes
A Schematic Framework for Requirements Engineering Processes
 Requirements Elicitation

Elicitation is the first activity that takes place and continues

through the Requirements Engineering lifecycle.
The purpose of requirements elicitation:
Distributed amongst many people, places and sources.
Knowledge is usually available in a variety of notations
range from sketches, through natural language prose to
formal models (e.g. mathematical models)
Some mental model in people's minds!
To gain of knowledge relevant to the problem.
Relevant knowledge produce a formal specification of the
software needed to solve the problem.

23
 Requirements Elicitation

Input to requirements elicitation: All Possible sources of

domain knowledge
Domain experts
Literature about the domain
Existing software systems in that domain
Similar software applications in other domains
National and international standards, which constrain the
development of software in that domain
Other stakeholders in the larger system (e.g. an
organisation) which will host the software system.

24
 Requirements Elicitation

Activities and techniques of requirements elicitation :

In requirements elicitation, the analyst is presented with the tasks of
Identifying all the sources of requirements knowledge
Acquiring the knowledge
Deciding on the relevance of the knowledge to the problem in hand
Understanding the significance of the elicited knowledge and its impact
on the software requirements.
Some most typically used techniques:
Users interviews, and through the
Creation of mock-up (prototype) software.
Reuse knowledge acquired in similar problem domains

Elicitation is a Labour intensive process, difficult task will take a large share
of time and resources for software development.
 Requirements Elicitation
Deliverables
Deliverablesofofrequirements
requirementselicitation:
elicitation:
The
The formal
formal outcome
outcome of of Requirements
Requirements Engineering
Engineering should
should bebe thethe
requirements
requirementsspecification
specificationmodel.
model.
The
The Model
Model creation
creation starting
starting with
with conceptual
conceptual models
models and
and ending
ending with
with the
the
requirements
requirementsspecification
specificationmodel.
model.
Model
Modelcontains
containsenvironmental
environmentalfactors,
factors,domain
domaingoals,
goals,policies,
policies,constraints
constraintsetc.
etc.

Interactions
Interactionsbetween
betweenelicitation
elicitationand
andother
otherProcesses:
Processes:
Elicitation
Elicitationisisongoing
ongoingprocess
processof ofRequirements
RequirementsEngineering
Engineering
Provides
Providesthe
the'raw
'rawmaterial'
material'totoother
otherprocesses
processestotoproduce
produceformal
formalModel
Model
Elicitation
Elicitationoccurs
occursininparallel
parallelwith
withspecification
specificationand
andvalidation
validationprocesses.
processes. 26
 Requirements Specification

A specification is a contract between users and software developers which

defines the desired functional behaviour of the software artefact (and other
properties of it such as performance, reliability etc.) without showing how
such functionality is going to be achieved.
Specification describes: 1. Application domain (enterprise models)
2. Nonfunctional models.
.
The purpose of requirements Specification:
The specification model is used as an agreement between the software
developers and the users on what constitutes the problem which must be
solved by the software system
The specification model is also a blueprint for the development of the
software system.

27
 Requirements Specification

Input to requirements Specification:

The process of specification requires as input knowledge about the
problem domain.
This knowledge is supplied by the elicitation process.
The input knowledge comes in a 'raw' format which must be converted
to meaningful information in order to produce a formal specification
model.
Other types of knowledge produced by the validation process is also
employed in specification.
Such knowledge states what is valid and what is not in the formal
specification.
It acts as a force for changing the formal requirements model.

28
 Requirements Specification

Activities and techniques of requirements Specification :

The process is analytical because all different kinds of knowledge
that the analyst elicits from the problem domain must be examined
and cross-related.
Specification is also synthetic because the heterogeneous
knowledge must be combined into producing a logical and
coherent requirements specification.
Requirements specification is described by the following major
activities:
Analysis and assimilation of requirements knowledge •
Synthesis and organization of the knowledge into a coherent and
logical requirements.
 Requirements Specification
Deliverables
Deliverablesof ofrequirements
requirementsSpecification:
Specification:
User-oriented
User-orientedmodelsmodelsspecifying
specifyingthe
thebehaviour,
behaviour,non-functional
non-functionalcharacteristics
characteristics
etc.
etc. of
of the
the software
software which
which serve
serve asas aa point
point of
of understanding
understanding between
between the
the
analyst,
analyst,thethecustomer
customerandandthe
theuser
user
Developer-oriented
Developer-oriented models models specifying
specifying functional
functional and
and non-functional
non-functional
properties
propertiesof ofthe
thesoftware
softwaresystem
systemas aswell
wellasasconstraints
constraintsononresources,
resources,design
design
constraints
constraintsetc.etc.which
whichact
actas
asblueprints
blueprintsforforfurther
furtherdevelopment
developmentstages.
stages.

Interactions
Interactionsbetween
betweenRequirements
RequirementsSpecification
Specificationandandother
otherProcesses:
Processes:
Requirements
Requirements specification
specification isis thethe central
central process
process of of Requirements
Requirements
Engineering.
Engineering.
Specification
Specificationcontrols
controlsboth
boththe
theelicitation
elicitationand
andvalidation
validationprocesses
processesas asfollows.
follows.
This
This will
will trigger
trigger the
the process
process of
of elicitation
elicitation which
which will
will inin turn
turn supply
supply the
the
needed
neededinformation.
information.
Some
Somechange
changeininthetheproblem
problemdomain
domain(e.g.
(e.g.change
changeininsome
someassumption,
assumption,mademade
about
aboutthe
thedomain)
domain)cancantrigger
triggeraachange
changeininthe
thespecification
specificationmodel.
model.

30
 Requirements Validation

Requirements validation is a process of Requirements Engineering which

aims to ensure that the right problem is being tackled at any time.
In many Requirements Engineering methods, validation is not a separate
activity, part of requirements specification.
Conceptual as well as practical reasons, to make the distinction between
validation and other processes and activities of Requirements Engineering.
The purpose of requirements Validation:
Requirements validation is defined as the process which certifies that the
requirements model is consistent with customers’ and users’ intents.
Validation is an ongoing process which proceeds in parallel with
elicitation and specification.
Validation encompasses activities such as requirements communication

31
 Requirements Validation

Input to requirements Validation:

Any requirements model (formal or informal) is subject to
validation and thus provides an input to the process.
Knowledge about the problem domain for example must be
validated, i.e. checked for accuracy, consistency, relevance
to the project etc.
In a similar way, some part of the formal requirements
model must be validated in parts and as a whole.

32
 Requirements Validation

Activities and techniques of requirements Validation :

Validation is a process which requires interactions between analysts,
customers of the intended system and users in the problem domain.
This is similar to the scientific process of formulating a new theory
(specification) and subsequently testing it by performing experiments
(validation).
In some occasions, the analyst can test the validity of the requirements
model without resorting to experimentation, e.g. by using common-sense.
In a scientific sense, validation is therefore characterized by two principal
types of activities:
preparing the settings for an experiment
performing the experiment and analyzing its results
 Requirements Validation
Deliverables
Deliverablesof ofrequirements
requirementsValidation:
Validation:
Validation
Validation delivers
delivers aa requirements
requirements model
model which
which isis consistent
consistent and
and inin
accordance
accordancewith
withthe
theusers
usersexpectations.
expectations.
This
Thisdoes
doesnot
notmean
meanthatthatthe
themodel
modelisisininany
anysense
sensecorrect.
correct.
Validation
Validation yields
yields aa compromise
compromise between
between whatwhat was
was desired
desired by
by the
the users
users and
and
what
whatisispossible
possibleand
andfeasible
feasibleunder
underthe
theproject
projectconstraints.
constraints.

Interactions
Interactionsbetween
betweenRequirements
RequirementsValidation
Validationandandother
otherProcesses:
Processes:
Validation
Validationisisever
everpresent
presentininallallstages
stagesof
ofRequirements
RequirementsEngineering.
Engineering.
The
The need
need for
for validation
validation isis triggered
triggered by
by the
the acquisition
acquisition ofof new
new knowledge
knowledge
about
about the
the problem
problem domain
domain (elicitation),
(elicitation), or
or by
by the
the formulation
formulation (even
(even inin part)
part)
of
ofaarequirements
requirementsmodel
model(specification).
(specification).
Validation
Validation isis also
also needed
needed during
during the
the analysis
analysis andand synthesis
synthesis phases
phases of of
requirements
requirements specification,
specification, since
since information
information analysed
analysed must
must bebe checked
checked forfor
correctness
correctness andand synthesised
synthesised requirements
requirements mustmust be be checked
checked for for logical
logical
consistency
consistencyandandcoherence.
coherence.

34
Processes of RE, in the context of the S/W development models

Processes of Requirements Engineering, in the context of the

following software development models
The waterfall model
The spiral model
The prototyping model
The operational model
The transformational model
The knowledge-based model
The Domain Analysis model