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

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

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?

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

Needs Features Requirements Problem Domain Solution Domain

Problem Statement Function Form Economy Time

Examples:  499/Examples/ A Good Process

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

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

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

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

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

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

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

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

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?

Peer Reviews

In person is best  When that’s not possible, telephone  Last resort, Follow up all meetings with minutes If you have to , 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

“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 (Steve Jobs) Use pictures, charts, visuals Use static prototypes  Make sure it’s obvious it’s a prototype Vague Requirements

Questions?