1. 1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters 18-23 of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman Institute of Technology September 27, 2005 Thanks to Mark Ardis and Steve Chenoweth for some of the slides included.

2. 2 Outline Scope  Establishing Project Scope  Managing Your Customer Refining the System Definition  A More Rigorous Look at Requirements  Refining Use Cases  Supplementary Specifications  Ambiguity and Specificity

3. 3 Establishing Project Scope

4. 4 The Shape of Project Scope Resources Time Deadline Time Resources

5. 5 Brooks' Law Adding labor to a late project makes it later Why?

6. 6 Requirements Baseline Itemized list of features intended for a given release Must be acceptable to customer Must have reasonable probability of success

7. 7 Setting Priorities Customers should decide priorities. Why?

8. 8 Example Priorities #FeaturePriority 1External RDB supportCritical 4Portability to a new OSCritical 3Ability to clone new projectImportant 5New project wizardImportant 2Implementation of tool tipsUseful

9. 9 Assessing Effort Developers should estimate effort  Why?

10. 10 Example Effort #FeaturePriorityEffort 1External RDB supportCriticalMedium 4Portability to a new OSCriticalHigh 3Ability to clone new projectImportantLow 5New project wizardImportantLow 2Implementation of tool tipsUsefulLow

11. 11 Setting the Baseline Include all "Critical" items Can you deliver those items on time? Add some "Important" items as budget allows

12. 12 Example Baseline #FeaturePriorityEffort 1External RDB supportCriticalMedium 4Portability to a new OSCriticalHigh 3Ability to clone new projectImportantLow Baseline 5New project wizardImportantLow 2Implementation of tool tipsUsefulLow

13. 13 Managing Your Customer

14. 14 Suggestions for Dealing with the Client During Development Include customer in decisions about scope reduction Negotiate changes to requirements Give yourself some slack Avoid "feature creep"

15. 15 A More Rigorous Look at Requirements

16. 16 Describing System Behavior Through Requirements Include: Inputs Outputs Functions System Attributes Environmental Attributes

17. 17 Expressing Requirements for System Development The two important components that we will use are  Use Case Model  Supplementary Specifications More on these later

18. 18 What Not to Put in Requirements Project Planning Information  May be part of the contract, though Design Information (“what vs. how”)

19. 19 Refining Use Cases

20. 20 Use Case Model Components Use Case Diagram Use Cases

21. 21 Use Case Diagram Example

22. 22 Use Cases Each feature that will be in the next version of the software (according to the Vision Document) should be involved in at least one use case The set of use cases cannot be exhaustive, but should include all system uses involving those features as described by stakeholders Pre-conditions, post-conditions and special requirements are important for development

23. 23 Extending Use Cases Extend an existing use case instead of redefining it

24. 24 Microwave Extension User Cook FoodCook and Rotate Food >

25. 25 Including Use Cases Frequent sequences of events may be defined as use cases Including a use case is like calling a subroutine

26. 26 Microwave Inclusion User Cook FoodSet Timer >

27. 27 Cook Food Inclusion D. Basic flow: 1. User opens door and places food in unit 2. User performs Set Timer use case 3. User pushes start button 4. Unit cooks food 5. Unit beeps

28. 28 Supplementary Specifications

29. 29 Types of Requirements Functional Requirements Nonfunctional Requirements Design Constraints “Other” Requirements

30. 30 Typical Nonfunctional Requirements Usability Reliability Performance Supportability That is, nonfunctional requirements generally focus on quality attributes

31. 31 Design Constraints Restriction of Design Options (e.g. what database to use) Process (e.g. must use ISO or IEEE software engineering standards) Regulations (e.g. FDA) Why are these in the requirements, if they involve design? Because it is part of what the customer wants or needs in the system to be developed.

32. 32 “Other” Requirements Deliverables (e.g. user documentation, other artifacts to be supplied by the developer – may in part depend on who’s doing the maintenance Technical Support Training Requirements Some organizations will include these in the “nonfunctional requirements”

33. 33 Supplementary Specifications Document Includes  Nonfunctional Requirements,  Design Constraints, and  Other Requirements That are not confined to just one use case

34. 34 Ambiguity and Specificity

35. 35 Basic Problem  The requirements must be both understandable and unambiguous  Balancing the two is sometimes difficult!  Client – needs it to be understandable  Software Team – needs it to be unambiguous