SRE

R
- equirements
Validation
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

Analysis: Focuses on the relevance of the

requirements.
Validation: Focuses on the accuracy of the details.
Validation Input and Output
Validation Inputs

●
Requirements
document
●
Should be a complete version of the document, not an unfinished
draft.
● Formatted and organized according to organizational standards
Organizational
● knowledge
Knowledge, often implicit, of the organization which may be used to
judge the realism of the requirements
● Organizational standards
●
Local standards e.g. for the organization of the requirements
document
Validation Outputs

●
Problem list
●
List of discovered problems in the requirements
●
Agreed document
actions
●
List of agreed actions in response to requirements problems. Some
problems may have several corrective actions; some problems may have
no associated actions
Requirements Verification
and Validation
Requirements Validation
Check that the right product is being built
Ensures that the software being developed (or changed) will satisfy its
stakeholders’ real needs
Checks the software requirements specification against stakeholders goals and
requirements
Requirements Verification
Check that product is being built right
Ensures that each step followed in the process of building the software yields the
right products
Checks consistency of the software requirements specification artefacts and other
software development products (design, implementation, ...) against the
specification
Both need to be performed at every stage during the (requirements) process
Requirements
Validation
1) Reviews
2) Prototyping
3) User Manual
4) Model Validation
5) Requirements Testing (VnV)
1)
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
Review
Activities
●
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
●
Prepare formembers
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.
● 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
Problem
Actions
●
Requirements Clarification
●
REQ: There shall be a barrier at the entrance of the car park.
●
Define “barrier”, e.g.: porter’s kiosk, bar type, floor spikes. What is the
barrier structure, dimensions, placement, etc. ? What is its action behavior?
●
Missing Information
●
No mention of the hours of operation of the barrier. Do not assume
●
24/7/365. No mention of safety issues

●
Requirements Conflict
●
For emergency purposes, the South entrance to the car park shall always
be open.
●
Conflict: Drivers can sneek into, or exit from, the car park through the South
entrance/exit
●
Unrealistic requirements
●
100% reliability of the barrier operation is required at all times.
●
Hidden camera shall detect private vehicles exiting through the
emergency exit and report to the administration.
 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
Reviews Checklist
●
Understandability
●
Can readers of the document understand what the requirements
● mean?
Redundancy
●
Is information unnecessarily repeated in the requirements
● document?
Completeness
●
Does the checker know of any missing requirements or is there
any information missing from individual requirement descriptions?
●
Ambiguity
●
Are the requirements expressed using terms which are clearly defined?
Could readers from different backgrounds make different interpretations
of the requirements?
●
Consistency
●
Do the descriptions of different requirements include contradictions? Are
there contradictions between individual requirements and overall system
requirements?
Reviews Checklist -
II
●
Organization
●
Is the document structured in a sensible way? Are the descriptions
of
● requirements organized so that related requirements are grouped?
Conformance
● to the
Does standards
requirements document and individual requirements conform
to defined standards? Are departures from the standards, justified?
●
Traceability
●
Are requirements unambiguously identified, include links to related
requirements and to the reasons why these requirements have
been included?
Pre-review
Checking
●
Reviews are expensive because they involve a number of people spending
time reading and checking the requirements document
●
Less expensive but Risky [misses multiple
perspectives]
●
This expense can be reduced by using pre-review checking where a couple of
people 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
Pre-review Checking -
II
2) Prototyping
Prototypes for requirements validation demonstrate the requirements and
help stakeholders discover problems
Validation prototypes should be complete, reasonably efficient and robust.
Prototyping
Activities
●
Choose prototype
testers
●
The best testers are users who are fairly experienced and who are
open- minded about the use of new systems. End-users who do
different jobs should be involved so that different areas of system
functionality will be covered.
●
Develop test scenarios
●
Careful planning is required to draw up a set of test scenarios which
provide broad coverage of the requirements. End-users shouldn’t just play
around with the system as this may never exercise critical system
● features.
Execute
● scenarios
The users of the system work, usually on their own, to try the system
by
● executing the planned scenarios.
Document
● problems
Its usually best to define some kind of electronic or paper problem
report
form which users fill in when they encounter a problem.
3) User
Manual
●
Writing a user manual from the requirements forces a detailed requirements
analysis and thus can reveal problems with the document

●
Information in the user
manual
●
Description of the functionality and how it is
●
implemented Which parts of the system have not been
●
implemented How to install and get started with the
system
4) Model
Validation
● Validation of system models is an essential part of the validation
●
process
Objectives of model validation
●
To demonstrate that each model is self-consistent
●
If there are several models of the system, to demonstrate that these
are internally and externally consistent
● To demonstrate that the models accurately reflect the real requirements
of
system stakeholders
●
Paraphrasing the model is an effective checking
technique
Example
5) Requirements
Testing
●
Each requirement should be testable i.e. it should be possible to define tests to
check whether or not that requirement has been met.

●
Inventing requirements tests is an effective validation technique as missing or
ambiguous information in the requirements description may make it difficult to
formulate tests

●
Each functional requirement should have an associated
test
Requirements Testing – global perspective
Test Case definition
●
What usage scenario might be used to check the requirement?
●
Does the requirement, on its own, include enough information to allow a test to
be defined?
●
Is it possible to test the requirement using a single test or are multiple test
cases required?
●
Could the requirement be re-stated to make the test cases more obvious?
Test Record form
●
The requirement’s
identifier
●
There should be at least one for each
●
Related requirement.
requirements
●
These should be referenced as the test may also be relevant to
these requirements.
●
Test description
●
A brief description of the test and why this is an objective requirements
test. This should include system inputs and corresponding outputs.
●
Requirements problems
●
A description of problems which made test definition difficult or
●
Commentsimpossible.
and
recommendations
●
These are advice on how to solve requirements problems which have
been discovered.
Test Record form – II