Requirements Validation

SJTU

Requirements Engineering Activity Model

Requirements Elicitation

Requirements Analysis

Requirements Specification

Requirements Validation

Validated Requirements Specification

Existing System Information

Stakeholder Needs

Organizational Standards

Technical Standards

Regulations

Domain Information

Goals

Requirements Management

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

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

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

Requirements Validation Inputs and Outputs

Requirements

Validation

Requirements specification

Organizational knowledge

Organization standards Agreed actions

List of problems

Subtopics Requirements reviews Prototyping Model validation Planning for acceptance tests

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

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

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

Requirements Review Process Model

Plan reviewDistributedocuments

Prepare forreview

Hold reviewmeeting

Follow-upactions

Revisedocument

Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

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

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?

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

Subtopics Requirements reviews Prototyping Model validation Planning for acceptance tests

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

Process Model

Chooseprototype

testers

Document and extend prototype system

Developtest

scenarios

Executescenarios

Documentproblems

Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998

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

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

Subtopics Requirements reviews Prototyping Model validation Planning for acceptance tests

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

Subtopics Requirements reviews Prototyping Model validation Planning for Acceptance tests

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

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