Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Rose-Hulman Institute of Technology Sriram Mohan 18.September.2008 CSSE 497 Requirements Review."— Presentation transcript:

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:  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 (  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?

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

Similar presentations

Ads by Google