1. Requirements Validation
SJTU

2. Requirements Engineering Activity Model
Requirements Management
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation
Validated Requirements Specification
Existing System Information
Stakeholder Needs
Organizational Standards
Technical Standards
Regulations
Domain Information
Goals

3. Requirements Validation
Concerned with validating and approving requirements specification
Checking requirements specification for consistency, completeness, accuracy and other attributes of a well-written requirements specification
Certifying that requirements represent acceptable description of system to be implemented
Ensuring requirements specification meets prescribed quality standards

4. Relationship Between Analysis and Validation
Requirements analysis
Concerned with raw requirements
Focus on stakeholder needs
Requirements validation
Concerned with DRAFT requirements specification
Focus on document quality

5. Requirements Problems Discovered During Validation
Examples
Lack of conformance to quality standards
Ambiguous requirements
Errors in analysis models
Requirements conflicts not detected during analysis
May need to revisit earlier requirements engineering process activities to fix requirements elicitation and analysis flaws

6. Requirements Validation Inputs and Outputs
Requirements specification
List of problems
Requirements
Validation
Organizational knowledge
Organization standards
Agreed actions

7. Subtopics Requirements reviews Prototyping Model validation
Planning for acceptance tests

8. Requirements Reviews
Formal review of requirements specification by group of stakeholders
Goal is to validate contents of specification
Identify errors
Identify invalid assumptions
Ensure clarity of requirements
Ensure requirements follow quality standards
May be conducted on any requirements specification
System requirements specification
Software requirements specification
May be conducted multiple times
Goal is to identify and fix requirements errors early in life-cycle

9. Participants Users Domain experts Customers Requirements engineers
System developers
Other stakeholders
Facilitator (chair)
Preferably someone who has not been involved in producing requirements which are being validated

10. Potential Problems with Requirements Specification
Conflicting requirements
Incomplete requirements
Inconsistent requirements
Design dependent requirements
Non-singularized requirements
Unnecessary requirements
Ambiguous requirements
Infeasible requirements (Technical, Operational, Economic)
Non-testable requirements
Requirements requiring non-standard hardware or software

11. Requirements Review Process Model
Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

12. Sample Review Checklist
Understandability
Redundancy
Completeness
Ambiguity
Consistency
Organization
Conformance to standards
Traceability

13. Sample Checklist Questions
Is each requirement uniquely identified?
Are terms defined in the glossary?
Does each requirement stand on its own?
Do individual requirements use terms consistently?
Is the same service requested in different requirements?
Are there contradictions between requirements?
Are requirements cross-referenced when needed?
Are related requirements grouped together?

14. Sample Follow-Up Actions
Clarify badly expressed requirements
Add missing requirements
Negotiate to resolve conflicting requirements
Defer, delete, or modify unrealistic requirements

15. Subtopics Requirements reviews Prototyping Model validation
Planning for acceptance tests

16. Prototyping for Requirements Validation
Prototype is a partial physical representation of a proposed system
Commonly used to validate requirements engineer’s understanding of requirements
Range of techniques available (same as in elicitation)
Static prototypes (throwaway)
Visual representation or paper mock-up of user interface
Static screens in graphics tool (e.g., PowerPoint)
Quick and inexpensive, but lacks interactivity
Dynamic prototypes (throwaway or evolutionary)
Executable screens in CASE tool (e.g., Power Builder)
Supports navigation between screens, but has limited functionality
Validation prototypes must be more complete than elicitation prototypes

17. Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998
Process Model
Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

18. Advantages
Easier to interpret than textual description or graphic model
Easy for customers and users to understand and react to
Provides quick feedback from customers and users
Produces answers to questions and generates new questions
Especially good for validation of user interface requirements
Provides context
Bridges communication gap between developer and user
Displays unanticipated aspects of system behavior
May shorten development time and cost
Increases user satisfaction
Improves productivity
Allows users to experiment with initial system
Establishes feasibility and usefulness before development

19. Limitations May unexpectedly evolve into final system
May be difficult to manage user expectations
Prototypes are imperfect (incomplete functionality)
Users may focus on cosmetic issues, lack of robustness, or quality problems rather requirements
Need to explain what a prototype is and is not
Can be costly

20. Subtopics Requirements reviews Prototyping Model validation
Planning for acceptance tests

21. Model Validation
Concerned with validating quality and correctness of analysis models included in requirements specification
Objectives of model validation
To demonstrate that each model is self-consistent
To demonstrate that models are internally and externally consistent
To demonstrate that models accurately reflect real requirements of system stakeholders
Can be somewhat automated if models are expressed in notations supported by CASE tools

22. Subtopics Requirements reviews Prototyping Model validation
Planning for Acceptance tests

23. Planning Acceptance Tests
Perform early planning for system acceptance testing as part of requirements validation
Concerned with ensuring that requirements are verifiable
Identifying how to verify each requirement
Developing acceptance tests is effective validation technique
Missing or ambiguous information in requirements description may make it difficult to formulate tests
Each functional requirement should have an associated test
Use cases or scenarios may form basis for acceptance tests
Actual tests are carried out after implementation

24. Key Points
Requirements validation is concerned with checking quality of requirements specification
Requirements reviews are most widely used requirements validation method
Prototyping is effective for requirements validation if prototype has been developed to support elicitation
Development of acceptance tests can reveal requirements problems
Requirements errors are more expensive to correct later in the life cycle
Design and implementation rework can be reduced by discovering requirements problems during requirements validation