1. Rose-Hulman Institute of Technology Sriram Mohan 18.September.2008 CSSE 497 Requirements Review

2. Documents this term Use cases What about those requirements you can’t do with a Use Case? Best practices Peer reviews Client Concerns  Non-technical clients  Long distance clients Outline

3. Project plan  Process definition  Schedule  Configuration management plan  Risk assessment Problem statement Requirements document(s) Design spec Test plans What Documents do you need to produce?

4. Groundwork for your project Establishes common ground for your team Living document Project Plan

5. Needs Features Requirements Problem Domain Solution Domain

6. Problem Statement Function Form Economy Time

7. Examples:  http://www.rose-hulman.edu/class/csse/csse497-498- 499/Examples/ A Good Process

8. What is a Functional Requirement? Functional requirements specify particular behaviors of a system. 8

9. What is a Use Case? A sequence of actions a system performs that yield and observable result of value to a particular actor Sequences of actions Performed by system of interest Observable result of value to a particular actor 9

10. Benefits Easy to write and read Think from the perspective of an user Provides a clear idea of the “what” and the “how” User involvement Use cases tell a better requirement story Typically developers are encouraged and required to write use cases. Why ? 10

11. Name Brief description Actors Basic flow Alternate flows Pre-conditions Post-conditions Other stakeholders System/sub-system Special requirements Use Case Template 11

12. Condition: optional User: external or internal, usually singular See RFC 2116 (http://www.ietf.org/rfc/rfc2119.txt)  Shall/Will/Must: Mandatory, “definition is an absolute requirement of the specification.”  Should: Recommended, “there may exist valid reasons in particular circumstances to ignore a particular item”  May: Optional Action: usually singular Requirements that don’t fit use case model

13. The database shall use mySQL The LEDs shall refresh at a rate of 1 Hz The interface shall conform to 802.11b standards The system should support up to 100 users The installation should take under 30 minutes Examples

15. A requirements document should include:  Scope  Product description  Business case or mission (needs, goals, and objectives)  Operational concepts  Interfaces  Reference documents (as needed)  Requirements (subdivided and with rationale)  Verification method (defined with requirements) Best Practices

16. Singular Necessary Attainable Complete Correct Unambiguous Verifiable Traceable A good requirement is

17. Essentially About/approximately A few Quickly Slowly Average (adjective not noun or verb) Realistic Designated amount of time Will make sure Appropriate response If possible When cost-effective What is not testable?

18. Peer Reviews

19. In person is best  When that’s not possible, telephone  Last resort, email Follow up all meetings with minutes If you have to email, have someone else read it first When needing a response, include the following:  “I would appreciate your feedback by 8 AM Monday. If this isn’t convenient for you, please feel free to propose a different time.”  Allows you to call at noon on Monday if you don’t have any feedback. Client Concerns

20. “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” – BusinessWeek, May 25 1998 (Steve Jobs) Use pictures, charts, visuals Use static prototypes  Make sure it’s obvious it’s a prototype Vague Requirements

21. Questions?