Requirements Validation and Verification

Requirements Validation and Verification

• Ensures that the requirements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs
• Both validation and verification are complementary processes related to the concepts of quality assurance
• Validation assesses whether a product satisfies customer needs (doing the right thing)
• Verification determines whether the product of some development activity meets its requirements (doing the thing right)

Requirements Validation vs. Verification

• Validation: "Are we building the right product?" - assessing whether you have written the right requirements
• Verification: "Are we building the product right?" - determining whether the product meets its requirements

Requirements Validation and Verification Processes

• Need to be performed at every stage during RE: Elicitation, Analysis, Specification
• Involves checking back with the elicitation sources, checking the correctness and consistency of the requirements, and checking conformity to writing standards, rules, etc.

What are We Validating?

• Requirements accurately describe the intended system capabilities and properties that will satisfy the various stakeholders' needs
• Requirements are correctly derived from business requirements, system requirements, business rules, and other sources
• Requirements are complete, feasible, and verifiable
• All requirements are necessary, and the entire set is sufficient to meet the business objectives
• All requirement representations are consistent with each other

Validation Techniques

• Reviews
• Prototyping
• Testing

Reviews

• Anytime someone other than the author of a work product examines the product for problems, a peer review is taking place
• Reviewing requirements is a powerful technique for identifying requirements problems

Informal Peer Reviews

• Useful for educating other people about the product and collecting unstructured feedback
• Not systematic, thorough, or performed in a consistent way
• Approaches include:
  • Peer deskcheck
  • Passaround
  • Walkthrough

Formal Peer Reviews

• Follow a well-defined process
• Produce a report that identifies the material examined, the reviewers, the review team's judgment as to whether the requirements are acceptable, and a summary of the defects found and the issues raised during the review
• Best-established type of formal peer review is called an inspection

Inspections

• Developed by Michael Fagan at IBM
• A well-defined multistage process that involves a small team of participants who carefully examine a work product for defects and improvement opportunities
• Serve as a quality gate through which project deliverables must pass before they are baselined
• Can be used for inspecting requirements documents and software

Inspection Participants

• Author of the work product
• Tester
• Project Manager
• People responsible for interfacing systems that will be affected by the item being inspected
• People who are the sources of information that into the item being inspected
• People who will do work based on the item being inspected

Inspection Roles

• Author
• Moderator
• Reader
• Recorder

Inspection – Entry Criteria

• Document conforms to the standard template and doesn't have obvious spelling, grammatical, or formatting issues
• Line numbers or other unique identifiers are printed on the document to facilitate referring to specific locations
• All open issues are marked as TBD (to be determined) or accessible in an issue-tracking tool
• Moderator didn't find more than three major defects in a ten-minute examination of a representative sample of the document

Inspection Stages

• Reader leads inspector through document, describing one requirement at a time in their own words
• Inspector brings up possible defects
• Recorder captures them in action item list for the author
• Team decides whether to Accept document as is, Accept w/ minor revisions, or Major revision needed

Inspection – Exit Criteria

• All issues raised during the inspection have been addressed
• Any changes made in the requirements and related work products were made correctly
• All open issues have been resolved, or each open issue's resolution process, target date, and owner have been documented

Learn about the importance of validation and verification in requirements engineering, and how they differ in ensuring customer needs are met.