Requirements Validation – I

Lectures # 16

1
 Today’s Topics
• Requirements validation
• Validation techniques

2
Requirements Engineering Process

Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation

User Needs,
Domain Information, Agreed
Existing System Requirements Requirements
Information, Regulations, Document
Standards, Etc.
3
 Validation Objectives
• Certifies that the requirements document is
an acceptable description of the system to
be implemented
• Checks a requirements document for
– Completeness and consistency
– Conformance to standards
– Requirements conflicts
– Technical errors
– Ambiguous requirements
4
 Analysis and Validation
• Analysis works with raw requirements as
elicited from the system stakeholders
– “Have we got the right requirements” is the
key question to be answered at this stage
• Validation works with a final draft of the
requirements document i.e., with
negotiated and agreed requirements
– “Have we got the requirements right” is the
key question to be answered at this stage
5
 Validation Inputs and Outputs

Requirements
document List of problems

Organizational Requirements
knowledge Validation
Agreed actions
Organizational
standards

6
 Requirements Document
• Should be a complete version of the
document, not an unfinished draft.
Formatted and organized according to
organizational standards

7
 Organizational Knowledge
• Knowledge, often implicit, of the
organization which may be used to
judge the realism of the requirements

8
 Organizational Standards
• Local standards e.g. for the
organization of the requirements
document

9
 List of Problems
• List of discovered problems in the
requirements document

10
 Agreed Actions
• List of agreed actions in response to
requirements problems. Some
problems may have several corrective
actions; some problems may have no
associated actions

11
 Requirements Reviews
• A group of people read and analyze the
requirements, look for problems, meet
and discuss the problems and agree on
actions to address these problems

12
 Requirements Review Process

Plan review Distribute

Prepare for Hold review

Follow-up Revise
actions documents

13
 Review Activities - 1
• Plan review
– The review team is selected and a time and
place for the review meeting is chosen
• Distribute documents
– The requirements document is distributed to
the review team members

14
 Review Activities - 2
• Prepare for review
– Individual reviewers read the requirements to
find conflicts, omissions, inconsistencies,
deviations from standards and other problems
• Hold review meeting
– Individual comments and problems are
discussed and a set of actions to address the
problems is agreed

15
 Review Activities - 3
• Follow-up actions
– The chair of the review checks that the
agreed actions have been carried out
• Revise document
– The requirements document is revised
to reflect the agreed actions. At this
stage, it may be accepted or it may be
re-reviewed
16
 Problem Actions
• Requirements clarification
• Missing information
• Requirements conflict
• Unrealistic requirement

17
 Requirements Clarification
• The requirement may be badly expressed or
may have accidentally omitted information
which has been collected during
requirements elicitation

18
 Missing Information
• Some information is missing from the
requirements document. It is the
responsibility of the requirements
engineers who are revising the
document to discover this information
from system stakeholders

19
 Requirements Conflict
• There is a significant conflict between
requirements. The stakeholders involved
must negotiate to resolve the conflict

20
 Unrealistic Requirement
• The requirement does not appear to be
implement-able with the technology
available or given other constraints on
the system. Stakeholders must be
consulted to decide how to make the
requirement more realistic

21
 Pre-review Checking - 1
• Reviews are expensive because they
involve a number of people spending time
reading and checking the requirements
document

22
 Pre-review Checking - 2
• This expense can be reduced by using pre-
review checking where one person checks
the document and looks for straightforward
problems such as missing requirements,
lack of conformance to standards,
typographical errors, etc.
• Document may be returned for correction or
the list of problems distributed to other
reviewers

23
 Pre-review Checking Stages

Check Check Check document Run

Requirements Problems
document report

24
 Review Team Membership
• Reviews should involve a number of
stakeholders drawn from different
backgrounds
– People from different backgrounds bring
different skills and knowledge to the review
– Stakeholders feel involved in the RE process and
develop an understanding of the needs of other
stakeholders
• Review team should always involve at least a
domain expert and an end-user
25
 Summary - 1
• Requirements validation should focus on
checking the final draft of the requirements
document for conflicts, omissions and
deviations from standards
• Inputs to the validation process are the
requirements document, organizational
standards and implicit organizational
knowledge. The outputs are a list of
requirements problems and agreed actions to
address these problems
26
 Summary - 2
• Reviews involve a group of people making
a detailed analysis of the requirements
• Review costs can be reduced by checking
the requirements before the review for
deviations from organizational standards.
These may result from more serious
requirements problems

27
 References
• ‘Requirements Engineering: Processes
and Techniques’ by G. Kotonya and I.
Sommerville, John Wiley & Sons,
1998

28