1. Validating the Requirements Chapter 15

2. Prepared by : AHMED ABU SA'DA AHMED ABU SA'DA Moataz Wassim - May – 2010 18 2009/2010

3. Introduction : Most software developers have experienced the frustration of being asked to implement requirements that were ambiguous or incomplete. If they can't get the information they need, the developers have to make their own interpretations, which aren't always correct. Substantial effort is needed to fix requirement errors after work based on those requirements has already been completed.

4. Requirements validation is the fourth component — with elicitation, analysis, and specification of requirements development

5. Requirements validation activities attempt to ensure that The SRS correctly describes the intended system capabilities and characteristics that will satisfy the various stakeholders' needs. The SRS correctly describes the intended system capabilities and characteristics that will satisfy the various stakeholders' needs. The software requirements were correctly derived from the system requirements, business rules, or other sources. The software requirements were correctly derived from the system requirements, business rules, or other sources. The requirements are complete and of high quality. The requirements are complete and of high quality. All requirements representations are consistent with each other. All requirements representations are consistent with each other. The requirements provide an adequate basis to proceed with design and construction. The requirements provide an adequate basis to proceed with design and construction.

6.  Validation ensures that the requirements exhibit the desirable characteristics of excellent requirement statements (complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable) and of excellent requirements specifications (complete, consistent, modifiable, and traceable). Of course, you can validate only requirements that have been documented, not implicit requirements that exist only in someone's mind.

7.  Validation isn't a single discrete phase that you perform after gathering and documenting all the requirements. Some validation activities, such as incremental reviews of the growing SRS, are threaded throughout the iterative elicitation, analysis, and specification processes. Other activities, such as formal SRS inspection, provide a final quality gate prior to baselining the SRS. Include requirements validation activities as discrete tasks in your project plan.

8. Reviewing Requirements  Informal reviews are useful for educating other people about the product and collecting unstructured feedback. However, they are not systematic, thorough, or performed in a consistent way.

9. Informal review approaches include:  A peer deskcheck, in which you ask one colleague to look over your work product  A passaround, in which you invite several colleagues to examine a deliverable concurrently  A walkthrough, during which the author describes a deliverable and solicits comments on it

10. The Inspection Process Inspection is a well-defined multistage process. It involves a small team of trained participants who carefully examine a work product for defects and improvement opportunities. Inspections provide a quality gate through which documents must pass before they are baselined. Inspection is a well-defined multistage process. It involves a small team of trained participants who carefully examine a work product for defects and improvement opportunities. Inspections provide a quality gate through which documents must pass before they are baselined.

11. Inspection Roles All participants in an inspection, including the author, look for defects and improvement opportunities. Some of the inspection team members perform the following specific roles during the inspection. All participants in an inspection, including the author, look for defects and improvement opportunities. Some of the inspection team members perform the following specific roles during the inspection.

12. Inspection Roles cont.. Author Author Moderator Moderator Reader Reader Recorder Recorder

13. Entry Criteria You're ready to inspect a requirements document when it satisfies specific prerequisites. These entry criteria set some clear expectations for authors to follow while preparing for an inspection. They also keep the inspection team from spending time on issues that should be resolved prior to the inspection. The moderator uses the entry criteria as a checklist before deciding to proceed with the inspection. You're ready to inspect a requirements document when it satisfies specific prerequisites. These entry criteria set some clear expectations for authors to follow while preparing for an inspection. They also keep the inspection team from spending time on issues that should be resolved prior to the inspection. The moderator uses the entry criteria as a checklist before deciding to proceed with the inspection.

14. Inspection Stages An inspection is a multistep process, as illustrated in Figure 15-2. The purpose of each inspection process stage is summarized briefly in the rest of this section. An inspection is a multistep process, as illustrated in Figure 15-2. The purpose of each inspection process stage is summarized briefly in the rest of this section.Figure 15-2Figure 15-2

15. Planning The author and moderator plan the inspection together. They determine who should participate, what materials the inspectors should receive prior to the inspection meeting, and how many inspection meetings will be needed to cover the material. The inspection rate has a large impact on how many defects are found The author and moderator plan the inspection together. They determine who should participate, what materials the inspectors should receive prior to the inspection meeting, and how many inspection meetings will be needed to cover the material. The inspection rate has a large impact on how many defects are found

16. The number of defects found depends on the inspection rate. As Figure 15-3 shows, proceeding through the SRS slowly reveals the most defects. (An alternative interpretation of this frequently reported relationship is that the inspection slows down if you encounter a lot of defects.) Because no team has infinite time available for requirements inspections, select an appropriate rate based on the risk of overlooking major defects. Two to four pages per hour is a practical guideline, although the optimum inspection rate for maximum defect-detection effectiveness is about half that rate (Gilb and Graham 1993). Adjust this rate based on the following factors: As Figure 15-3 shows, proceeding through the SRS slowly reveals the most defects. (An alternative interpretation of this frequently reported relationship is that the inspection slows down if you encounter a lot of defects.) Because no team has infinite time available for requirements inspections, select an appropriate rate based on the risk of overlooking major defects. Two to four pages per hour is a practical guideline, although the optimum inspection rate for maximum defect-detection effectiveness is about half that rate (Gilb and Graham 1993). Adjust this rate based on the following factors:Figure 15-3Figure 15-3

17. The number of defects found depends on the inspection rate.

18. Overview meeting Overview meeting During the overview meeting, the author describes the background of the material the team will be inspecting, any assumptions he made, and his specific inspection objectives. You can omit this stage if all inspectors are already familiar with the items being inspected. During the overview meeting, the author describes the background of the material the team will be inspecting, any assumptions he made, and his specific inspection objectives. You can omit this stage if all inspectors are already familiar with the items being inspected.

19. Defect checklist for software requirements specifications. Organization and Completeness Organization and Completeness Correctness Correctness Quality Attributes Quality Attributes Traceability Traceability Special Issues Special Issues

20. Requirements Review Challenges Large requirements documents The prospect of thoroughly inspecting a several- hundred-page SRS is daunting. You might be tempted to skip the inspection entirely and just proceed with construction — not a wise choice. Even given an SRS of moderate size, all inspectors might carefully examine the first part and a few stalwarts will study the middle, but it's unlikely that anyone will look at the last part. Large requirements documents The prospect of thoroughly inspecting a several- hundred-page SRS is daunting. You might be tempted to skip the inspection entirely and just proceed with construction — not a wise choice. Even given an SRS of moderate size, all inspectors might carefully examine the first part and a few stalwarts will study the middle, but it's unlikely that anyone will look at the last part.

21. Requirements Review Challenges Large inspection teams Many project participants and customers hold a stake in the requirements, so you might have a long list of potential participants for requirements inspections. However, large inspection teams make it hard to schedule meetings, tend to hold side conversations during inspection meetings, and have difficulty reaching agreement on issues. Large inspection teams Many project participants and customers hold a stake in the requirements, so you might have a long list of potential participants for requirements inspections. However, large inspection teams make it hard to schedule meetings, tend to hold side conversations during inspection meetings, and have difficulty reaching agreement on issues.

22. Testing the Requirements It's hard to visualize how a system will function under specific circumstances just by reading the SRS. 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. It's hard to visualize how a system will function under specific circumstances just by reading the SRS. 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.

23. Testing the Requirements You can begin deriving conceptual test cases from use cases or other user requirements representations very early in the development process. You can begin deriving conceptual test cases from use cases or other user requirements representations very early in the development process.

24. Some conceptual test cases would be the following: User enters order number to view, order exists, user placed the order. Expected result: show order details. User enters order number to view, order exists, user placed the order. Expected result: show order details. User enters order number to view, order doesn't exist. Expected result: Display message "Sorry, I can't find that order." User enters order number to view, order doesn't exist. Expected result: Display message "Sorry, I can't find that order." User enters order number to view, order exists, user didn't place the order. Expected result: Display message "Sorry, that's not your order." User enters order number to view, order exists, user didn't place the order. Expected result: Display message "Sorry, that's not your order."

25. Ideally, an analyst will write the functional requirements and a tester will write the test cases from a common starting point, the user requirements, as shown in Figure 15-6 Ideally, an analyst will write the functional requirements and a tester will write the test cases from a common starting point, the user requirements, as shown in Figure 15-6Figure 15-6Figure 15-6 Figure 15-6: Development and testing work products are derived from a common source.

26. The notion of testing requirements might seem abstract to you at first. Let's see how the Chemical Tracking System team tied together requirements specification, analysis modeling, and early test-case generation. Following are a business requirement, a use case, some functional requirements, part of a dialog map, and a test case, all of which relate to the task of requesting a chemical. The notion of testing requirements might seem abstract to you at first. Let's see how the Chemical Tracking System team tied together requirements specification, analysis modeling, and early test-case generation. Following are a business requirement, a use case, some functional requirements, part of a dialog map, and a test case, all of which relate to the task of requesting a chemical.

27. Business requirement Business requirement business requirement is from the vision and scope document. business requirement is from the vision and scope document. "Establishing the Product Vision and Project Scope." "Establishing the Product Vision and Project Scope."

28. Use case Use case A use case that supports this business requirement is "Request a Chemical." This use case includes a path that permits the user to request a chemical container that's already available in the chemical stockroom. A use case that supports this business requirement is "Request a Chemical." This use case includes a path that permits the user to request a chemical container that's already available in the chemical stockroom.

29. Functional requirement Functional requirement Here's a bit of functionality associated with this use case: Here's a bit of functionality associated with this use case: 1. If the stockroom has containers of the chemical being requested, the system shall display a list of the available containers. 2. The user shall either select one of the displayed containers or ask to place an order for a new container from a vendor.

30. Test case The use case has several possible execution paths, you can envision several test cases to address the normal course, alternative courses, and exceptions. The use case has several possible execution paths, you can envision several test cases to address the normal course, alternative courses, and exceptions.

31. Use cases and test cases work well together in two ways: If the use cases for a system are complete, accurate, and clear, the process of deriving the test cases is straightforward. And if the use cases are not in good shape, the attempt to derive test cases will help to debug the use cases. Use cases and test cases work well together in two ways: If the use cases for a system are complete, accurate, and clear, the process of deriving the test cases is straightforward. And if the use cases are not in good shape, the attempt to derive test cases will help to debug the use cases.

32. Defining Acceptance Criteria Software developers might believe that they've built the perfect product, but the customer is the final arbiter. Customers perform acceptance testing to determine whether a system satisfies its acceptance criteria Software developers might believe that they've built the perfect product, but the customer is the final arbiter. Customers perform acceptance testing to determine whether a system satisfies its acceptance criteria

33. Acceptance testing Acceptance testing should focus on anticipated usage scenarios. Acceptance testing should focus on anticipated usage scenarios. Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly. Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly.

34. Acceptance Criteria Having customers develop acceptance criteria thus provides another opportunity to validate the most important requirements. It's a shift in perspective from the requirements-elicitation question of "What do you need to do with the system?" to "How would you judge whether the system satisfies your needs?" If the customer can't express how she would evaluate the system's satisfaction of a particular requirement, that requirement is not stated sufficiently clearly. Having customers develop acceptance criteria thus provides another opportunity to validate the most important requirements. It's a shift in perspective from the requirements-elicitation question of "What do you need to do with the system?" to "How would you judge whether the system satisfies your needs?" If the customer can't express how she would evaluate the system's satisfaction of a particular requirement, that requirement is not stated sufficiently clearly.

35. Acceptance Criteria Writing requirements isn't enough. You need to make sure that they're the right requirements and that they're good enough to serve as a foundation for design, construction, testing, and project management. Acceptance test planning, informal reviews, SRS inspections, and requirements testing techniques will help you to build higher- quality systems faster and more inexpensively than you ever have before. Writing requirements isn't enough. You need to make sure that they're the right requirements and that they're good enough to serve as a foundation for design, construction, testing, and project management. Acceptance test planning, informal reviews, SRS inspections, and requirements testing techniques will help you to build higher- quality systems faster and more inexpensively than you ever have before.

36. Thank you for you attention