In this Slide:
___________________________________________________________________
SRE –
Requirements Validation
BSEF15
(V)
Abdul
Razaq Ali
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 document
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
Requirements Validation
1)
Reviews
2)
Prototyping
3)
User Manual
4)
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 members
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.
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 standards
Does the 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) 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 requirement.
Related
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 impossible.
Comments
and recommendations
These are advice on how to solve
requirements problems which have been discovered.
Test Record form – II
Questions ?
No comments :
Post a Comment