1. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections

2. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To explain product design finalization  To present SRS quality criteria and assign responsibility for them  To define several types of reviews  To examine inspections in detail

3. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  Product design finalization  SRS quality characteristics  Reviews  Inspections Roles Process Activities Checklists

4. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 Software Product Design Process

5. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 Design Finalization  Final product design step  Ensures that requirements are properly documented Designer review  Ensures that requirements are valid (that is, the product design is good) Stakeholder review

6. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 SRS Quality Characteristics 1  Well-formedness—An SRS is well formed if it conforms to all rules about stating requirements.  Clarity—An SRS is clear if it is easy to understand.  Consistency—A set of requirements is consistent if a single product can satisfy them all.  Completeness—An SRS is complete if it includes every relevant requirement.

7. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 SRS Quality Characteristics 2  Verifiability—Every requirements in an SRS must be verifiable.  Uniformity—A description has uniformity when it treats similar items similarly.  Feasibility—An SRS contains feasible requirements when designers are confident that they can be satisfied.  Developers should check all these characteristics.

8. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 SRS Quality Characteristics 3  Correctness—An SRS is correct if it specifies a product that satisfies stakeholder needs and desires, subject to constraints.  Proper requirements prioritization—All requirements are prioritized in accord with stakeholder needs and desires.  Stakeholders should check these requirements validation characteristics.

9. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 9 Reviews A review is an examination and evaluation of a work product or process by qualified individual or teams.

10. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Types of Reviews  Desk check—An examination of a work product by an individual. Often the author (proofreading) Checklists  Walkthrough—An informal examination of a work product by a team of reviewers. No assigned roles, no set process Usually preparation (desk check) by reviewers  Inspection—Formal work product review by trained team of inspectors with assigned roles using a checklist to find defects. Mandatory preparation Formal review process

11. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Requirements Inspections  Find as many defects as possible  Not intended to evaluate the author  Not intended to correct defects  Expensive and time consuming  Efficient and cost effective  Can be used for any work product

12. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Inspection Roles  Moderator—Manages and facilitates the process  Inspector—Searches for defects  Author—Originates the work product  Reader—Reads the work product during the inspection meeting  Recorder—Notes defects found, issues, inspection characteristics, etc.

13. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Inspection Process

14. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Preparation Activities  Readiness check Usually done by the moderator Ensures that the work product has no obvious defects  Overview meeting Short (~20 minutes) Tasks  Schedule review meeting  Distribute work product, checklist, etc.  Answer questions May be done electronically  Each inspector carefully reviews the work product using a checklist Takes several hours

15. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Inspection Meeting  Moderator insures that inspectors are ready; if not, the meeting is rescheduled  Reader reads through the work product  Inspectors note defects or raise issues  Recorder notes all defects, issues, comments, collects data, etc.  The meeting should not last more than two hours  There should not be more than one inspection meeting per day

16. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 16 Inspection Checklist  Must be specific to work products and projects  Should be modified continuously Checklist items should be removed if they rarely turn up defects Checklist items should be added to find defects that are often missed

17. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 17 Requirements Inspection Checklist Example  Every requirement is atomic.  Every requirement statement uses “must” or “shall.”  Every requirement statement is in the active voice.  Terms are used with the same meaning throughout.  No synonyms are used.  Every requirement statement is clear.  No requirement is inconsistent with any other requirement.  No needed feature, function, or capability is unspecified.  No needed characteristic or property is unspecified.  All design elements are specified to the physical level of abstraction.  Every requirement is verifiable.  Similar design elements are treated similarly.  Every requirement can be realized in software.  Every requirement plays a part in satisfying some stakeholder’s needs or desires.  Every requirement correctly reflects some stakeholder’s needs or desires.  Every requirement statement is prioritized.  Every requirement priority is correct.

18. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 18 Inspection Conclusion  The author corrects defects found by inspectors.  The moderator ensures that all defects are dealt with.  If the work product is much changed or still appears to have defects, another inspection may be scheduled.

19. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 19 Summary  Design finalization ensures that the SRS is of high quality.  Designers and stakeholders review the SRS for various quality characteristics.  Reviews include desk checks, walkthroughs, and inspections.  Inspections are reviews with explicit goals, assigned roles, and a formal process, that relies on checklists to find defects.