Requirements Validation

Fundamentals Validation Techniques Assistance Techniques for Validation Summary

Requirements Validation

Antonio Villegas [email protected]

Requirements EngineeringFacultat d’Informatica de Barcelona

April 4, 2011

Antonio Villegas Requirements Validation April 4, 2011 1 / 29

CC© BY:© $\© C©

@avillegasn


Outline

1 Fundamentals

2 Validation Techniques

3 Assistance Techniques for Validation



The context of Requirements Validation



The context of Requirements Validation



Motivation and Goals

Requirements Validation

Validation (in requirements engineering)

Validation denotes checking whether inputs, performed activities,and created outputs (requirements artifacts) of the requirementsengineering core activities fulfil defined quality criteria.

Validation is performed by involving relevant stakeholders, otherrequirement sources (standards, laws, etc.) as well as externalreviewers, if necessary.




Quality Gateway




Quality Criteria

Completeness- The requirement must contain all relevant information

(template).

Consistency- The requirements must be compatible with each other.

Adequacy- The requirements must address the actual needs of the system.

Unambiguity- Every requirement must be described in a way that precludes

different interpretations.

Comprehensibility- The requirements must be understandable by the stakeholders.




Quality Criteria

Importance- Each requirement must indicate how essential it is for the

success of the project.

Measurability- The requirement must be formulated at a level of precision

that enables to evaluate its satisfaction.

Necessity- The requirements must all contribute to the satisfaction of the

project goals.

Viability- All requirements can be implemented with the available

technology, human resources and budget.

Traceability- The context in which a requirement was created should be

easy to retrieve.




Examples

Train doors shall be openedas soon as the train is stopped at a platform




Examples

Ambiguity

Train doors shall be openedas soon as the train is stopped at a platform

Possible interpretations:The front of the train is (stopped) at a platform?orThe whole train is (stopped) at a platform?




Examples

Contradiction

Train doors must always be kept closed between stations.

and elsewhere...

Train doors must be opened once a train is stopped after anemergency signal.




Risk of insufficient validation

Quality Assurance









The earlier an error is discovered,the cheaper it is to correct.



Principles of Validation

The 6 Principles of Validation

First Principle: Involving the Right Stakeholders

Ensure that relevant company-internal as well as relevant externalstakeholders participate in validation.

Pay attention to the reviewers’ independence and appoint external,independent stakeholders, if necessary.

Second Principle: Defect Detection vs. Defect Correction

Separate defect detection from the correction of the detecteddefects.





First Principle: Involving the Right Stakeholders

Ensure that relevant company-internal as well as relevant externalstakeholders participate in validation.

Pay attention to the reviewers’ independence and appoint external,independent stakeholders, if necessary.

Second Principle: Defect Detection vs. Defect Correction

Separate defect detection from the correction of the detecteddefects.





Third Principle: Leveraging Multiple Independent Views

Whenever possible, try to obtain independent views that can beintegrated during requirements validation in order to detect defectsmore reliably.

Fourth Principle: Use of Appropriate Documentation Formats

Consider changing the documentation format of the requirementsinto a format that matches the validation goal and the preferencesof the stakeholders who actually perform the validation.





Third Principle: Leveraging Multiple Independent Views

Whenever possible, try to obtain independent views that can beintegrated during requirements validation in order to detect defectsmore reliably.

Fourth Principle: Use of Appropriate Documentation Formats

Consider changing the documentation format of the requirementsinto a format that matches the validation goal and the preferencesof the stakeholders who actually perform the validation.





Fifth Principle: Creation of Development Artefacts duringValidation

If your validation approach generates poor results, try to supportdefect detection by creating development artefacts such asarchitectural artefacts, test artefacts, user manuals, or goals andscenarios during validation.

Sixth Principle: Repeated Validation

Establish guidelines that clearly determine when or under whatconditions an already released requirements artefact has to bevalidated again.





Fifth Principle: Creation of Development Artefacts duringValidation

If your validation approach generates poor results, try to supportdefect detection by creating development artefacts such asarchitectural artefacts, test artefacts, user manuals, or goals andscenarios during validation.

Sixth Principle: Repeated Validation

Establish guidelines that clearly determine when or under whatconditions an already released requirements artefact has to bevalidated again.



Validation Techniques

Inspections

Desk-Checks

Walkthroughs

Prototypes



Inspections

Inspections

Inspection: an organized examination process of the requirements.

Involved roles:

Organizer

Moderator

Author

Inspectors

Minute-taker

Benefit: Detailedchecking of the artefacts

Critical Success Factors:

Commitment of the organization

Size and complexity of theinspected artefacts

Number and experience of theinspectors

Effort: Medium-High



Desk-Checks

Desk-Checks

1 The author of a requirement artefact distributes the artefact to aset of stakeholders.

2 The stakeholders check the artefact individually.

3 The stakeholders report the identified defects to the author.

4 The collected issues are discussed in a group session (optional).


Commitment of the participants

Coverage of all the aspects

Not recommended for criticalartefacts

Benefit: Obtain feedbackfrom individual reviewers

Effort: Medium



Walkthroughs

Walkthroughs

A walkthrough does not have formally defined procedure and doesnot require a differentiated role assignment.

Checking early whether an idea is feasible or not.

Obtaining the opinion and suggestions of other people.

Checking the approval of others and reaching agreement.


Involving stakeholders fromdifferent contexts

Comprehensible presentation of theartefact

Benefit: Validation ofideas and sketches

Effort: Medium-Low



Prototypes

Prototypes

A prototype allows the stakeholders to try out the requirements forthe system and experience them thereby.

1 Develop the prototype (tool support).

2 Training of the stakeholders.

3 Observation of prototype usage.

4 Collect issues.


Effort

Level of detail of theprototype

Quality of the review

Benefit:

Highly effective defect detection

Proof of feasibility

Effort: Very High-High



Review

Review of Techniques

Inspection Desk-Check Walkthrough Prototype

Goal extensive search fordefects in amanageable extentof requirementsartefacts

less-detailed checkof a larger extentof artefactsindividually

feedback on earlysketches of anartefact

try out therequirements andexperience them

Group session yes, strict focus ondefect collection

optional yes, for providingfeedback

yes, to evaluate theobservation

Process detailed roles andstrict steps

defined but flexible no predefinedprocedure

defined but flexible

Effort forexecution

Medium-High Medium Medium-Low Very High-High

Benefit forvalidation

High Medium Low Very High



Assistance Techniques for Validation

Checklists

Perspective-basedReading

Creation of Artefacts



Checklists

Checklists

A checklist should comprise few questions so that the reviewer canuse it during validation in an effective way.

Applicable with each validation technique.

Create different checklists for different validation goals

Create checklists based on rules, experience, and defect statistics.


Limiting the size of the checklists

Avoiding generic questions such as”Are the requirements complete?”

Considering the stakeholders’background and experience

Benefit:

Each reviewer knows howto check the artefact

Used for validation and forelicitation

Effort: Low-Very Low



Perspective-based Reading

Perspective-based Reading

Applying perspective-based reading during requirements validationmeans checking the same set of artefacts by reading them fromdifferent perspectives.


Identify the perspectives that are relevant for the project

For each perspective, provide reading instructions and questionsthat support defect detection.


Quality of the instructions andquestions

Experience of the reviewers

Involving stakeholders fromdifferent contexts

Benefit:

Practical support forreviewers

More defects uncoveredthan without perspectives

Effort: High-Medium



Creation of Artifacts

Creation of Artifacts

Creating artefacts during validation means using the requirementsto be checked as a reference for creating other developmentartefacts.


Verbalisation of Models.

Creating Scenarios, Test Cases, a User Manual...


Quality of the created artefacts

Experience of the reviewers

Traceability between requirementsand artefacts

Benefit:

Defects uncovered duringartefacts creation

Reuse of the createdartefacts as initial drafts

Effort: High-Medium



Review

Review of Assistance Techniques

Checklists Perspective-basedReading

Creation ofArtifacts

Goal guide thestakeholders duringthe requirementsvalidation

checking the sameset of artefacts byreading them fromdifferentperspectives

validate therequirements whilecreating drafts ofartefacts

Critical SuccessFactors

size and diversity ofthe checklists

quality of theinstructions andexperience of thereviewers

quality andtraceability of theartefacts

Effort for execution Low-Very Low High-Medium High-Medium

Benefit for validation Medium Medium High-Medium



Summary

The Context of Requirements Validation in RE

The Quality Gateway and Quality Criteria

Risk of Insufficient Validation


Validation Techniques

Assistance Techniques for Validation



“Quality is never an accident.It is always the result of intelligent effort.”

John Ruskin



References

Denger, C. and Olsson, T. Quality Assurance in Requirements Engineering

Pohl, K. Requirements Engineering: Fundamentals, Principles, andTechniques.Part V. Validation pp. 509-585

van Lamsweerde, A. Requirements Engineering: from system goals to UMLmodels to software specifications.Chapter 5. Requirements Quality Assurance pp. 187-217

Robertson, S. and Robertson, J. Mastering the Requirements Process.2nd Edition. Chapter 11.


Education

Requirements Validation