Requirements Validation SJTU

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

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 specification List of problems Requirements Validation Organizational knowledge Organization standards Agreed actions

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 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

Source: Kotonya and Sommerville, Requirements Engineering, Wiley, 1998 Process Model 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