Requirements Validation SE 555 Software Requirements Specification Two

Requirements Validation SE 555 Software Requirements & Specification

Two Views of Quality Assessment n Verification n Ensuring correctness from activity to activity in the software development process n n “Did we build the product right? ” Validation n Evaluating a system to see if it satisfies the customer needs Validate the requirements n Do these requirements correctly capture the stakeholder needs? n n n e. g. , ensure that the code satisfies the design “Are we building the right product? ” Validate that all stakeholders have a common understanding of the requirements Validate the system n Does this deployed system actually satisfy the stakeholder needs? n “Did we build the right product? ” SE 555 Software Requirements & Specification

Requirements Validation n n n Does the SRS correctly describe the intended system capabilities and characteristics? Does the SRS satisfy the various stakeholder’s needs? n For conflicting needs, is there consensus on trade-off choices? Were the functional requirements correctly derived from the business requirements, system requirements, business rules, and sources? Are the requirements complete, unambiguous, testable, consistent, modifiable, etc. ? Do the requirements have the necessary qualities (stability, priority, cost/benefit, etc. ) to proceed with design and implementation? n Remember that this is incremental: Is this subset of requirements ready for design and implementation? If valid, baseline this subset and manage change SE 555 Software Requirements & Specification

Requirements Validation Techniques n Requirements reviews n Prototyping to elicit and validate requirements n n n Requirements analysis modeling to develop deeper understanding and to expose ambiguity and incomplete areas Prove properties of formal analysis models Incremental development and architecture-centric development to expose quality requirements issues early Plan how each requirement will be verified in acceptance tests Observe operational usage of the system to see if it truly meets the stakeholders’ needs SE 555 Software Requirements & Specification

Model n n Plan and develop tests throughout the life cycle Performal reviews of software models Implement tests when code is available to test Repeat “V” at each iteration Acceptance test plan and cases Requirements modeling System integration test plan and cases Analysis modeling Formal Reviews Acceptance test System integration test Sub-system integration test plan and cases Design modeling Implementation Sub-system integration test Unit test SE 555 Software Requirements & Specification

Review Techniques n n Personal review Peer review Walkthrough Inspection 1 10 100 n n Reviews can be used for requirements, designs, code, test cases, and other artifacts and deliverables Focus only on finding defects n Resolving the defects is a different activity Defects found in requirements would cost … · 10 times more to remove if not discovered until implementation · 100 times more to remove if not discovered until deployment SE 555 Software Requirements & Specification

Personal & Peer Reviews n n n In a personal review n Analyst privately reviews his/her product n Objective is to find defects before they propagate into design, implementation, and test cases In a peer review, this is done by exchanging the artifact with a peer/colleague Reviews are most effective when structured and measured SE 555 Software Requirements & Specification

Walkthroughs n Walkthroughs typically follow a meeting format n Developer leads the reviewers through the artifact n Reviewers may include peers, managers, or other interested parties n Objective is to communicate or obtain approval of content n n Defects are barriers to understanding or approval Little preparation is required SE 555 Software Requirements & Specification

Inspections n Inspections follow a structured process n Done by a small group (6 or fewer) of stakeholders n n n Author Customer/end user People who will do work based on these requirements n n n Developer, tester, technical writer, manager, etc. People responsible for work products that interface to the functionality specified Inspections are widely considered to be the “highestleverage software quality technique” available. [Gilb 1993] SE 555 Software Requirements & Specification

Inspection Roles n n n Author n Principal responsibility for the artifact’s development n Able to answer technical questions about the artifact n Responsible for fixing defects agreed upon in the inspection meeting. Moderator n Facilitates the inspection process n Responsible for checking later that the problems found have been fixed Inspectors n Review the artifact (or some assigned portion) before the inspection meeting n Provide their inputs and contribute to discussions during the meeting Reader n Paraphrases the SRS one requirement at a time, followed by other reviewers pointing out potential defects and issues n Paraphrasing helps expose ambiguity Recorder n Ensures that problems found get recorded, n Completes the inspection report (results and data) SE 555 Software Requirements & Specification

Inspection Guidelines n n n n n Plan and prepare for the inspection n Review the inspection process See the Defect Checklist in n Prepare a task list and schedule Wiegers Figs. 15 -4 and 15 -5 n Assign inspection roles n Assemble inspection materials n Prepare inspector checklists Set an agenda for the inspection meeting and stick to it The product should be inspected in small “chunks” Meetings should be at least one hour, but no more than two hours Inspect the work product, not the author Limit debate and rebuttal in the inspection meeting Identify problems, do not attempt to solve them Take written notes of the meeting; collect effort and defect data Limit the number of participants and insist upon advanced preparation SE 555 Software Requirements & Specification

Testing the Requirements n n Test cases that are based on the functional requirements or derived from user requirements help make the expected system behaviors tangible to the project participants Designing test cases will reveal many problems with the requirements even if you don’t execute the tests n It is hard to describe the expected system response for vague or ambiguous requirements n It is straightforward to write test cases for complete, clear, accurate requirements Develop requirements and tests together n Define test cases early to identify and resolve defects early n Complementary, synergistic views of the system Write test cases for normal flow, alternative flows, and exceptions SE 555 Software Requirements & Specification

Requirements and Tests are Synergistic User Requirements Analyst Tester Functional Requirements and Analysis Models Compare Test Cases and Scenarios Technical Designs User Interface Designs Compare Test Procedures and Scripts SE 555 Software Requirements & Specification

System Validation: Customer Acceptance n Customer acceptance testing executes the system in its operational context n Does it satisfy the documented requirements when running in the real world? n Is it for use in the intended operating environment? n Write acceptance tests focused on normal flows n Write acceptance tests for non-functional requirements, too n n Have customers write acceptance criteria n How would you judge whether the system satisfies your needs? The “ultimate” validation: observe the production use of the system and see if it satisfies needs n Look for new opportunities SE 555 Software Requirements & Specification