SE 555 Software Requirements & Specification Requirements Validation

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

SE 555 Software Requirements & Specification Requirements Validation Does the SRS correctly describe the intended system capabilities and characteristics? Does the SRS satisfy the various stakeholder’s needs? 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? 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 Requirements reviews Prototyping to elicit and validate requirements 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 V- Mode l Plan and develop tests throughout the life cycle Perform formal reviews of software models Implement tests when code is available to test Repeat “V” at each iteration Requirements modeling Analysis modeling Design modeling Implementation Unit test Sub-system integration test System integration test Acceptance test Sub-system integration test plan and cases System integration test plan and cases Acceptance test plan and cases Formal Reviews

SE 555 Software Requirements & Specification Review Techniques Personal review Peer review Walkthrough Inspection 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 Reviews can be used for requirements, designs, code, test cases, and other artifacts and deliverables Focus only on finding defects Resolving the defects is a different activity

SE 555 Software Requirements & Specification Personal & Peer Reviews In a personal review Analyst privately reviews his/her product 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 Walkthroughs typically follow a meeting format Developer leads the reviewers through the artifact Reviewers may include peers, managers, or other interested parties Objective is to communicate or obtain approval of content Defects are barriers to understanding or approval Little preparation is required

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

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

SE 555 Software Requirements & Specification Inspection Guidelines Plan and prepare for the inspection Review the inspection process Prepare a task list and schedule Assign inspection roles Assemble inspection materials 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 See the Defect Checklist in Wiegers Figs and 15-5

SE 555 Software Requirements & Specification Testing the Requirements 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 It is hard to describe the expected system response for vague or ambiguous requirements It is straightforward to write test cases for complete, clear, accurate requirements Develop requirements and tests together Define test cases early to identify and resolve defects early 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 Functional Requirements and Analysis Models Test Cases and Scenarios Test Procedures and Scripts Technical Designs User Interface Designs User Requirements TesterAnalyst Compare

SE 555 Software Requirements & Specification System Validation: Customer Acceptance Customer acceptance testing executes the system in its operational context Does it satisfy the documented requirements when running in the real world? Is it fit for use in the intended operating environment? Write acceptance tests focused on normal flows Write acceptance tests for non-functional requirements, too Have customers write acceptance criteria 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 Look for new opportunities