rose-hulman institute of technology sriram mohan 18.september.2008 csse 497 requirements review

Rose-Hulman Institute of TechnologySriram 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

SolutionDomain

Problem Statement

• Function• Form• Economy• Time

• Examples: http://www.rose-hulman.edu/class/csse/csse497-498-499/Examples/

Problem statement

Team buy-in

Client buy-in

Feedback

Revise

Requirements document

Vision document

Team buy-in

Client buy-in

Feedback

Revise

A Good Process

What is a Functional What is a Functional Requirement?Requirement?

• Functional requirements specify particular behaviors of a system.

8

What is a Use Case?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

BenefitsBenefits

• 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 TemplateUse Case Template

11

<Condition> <user> <shall || should || may> <action>

• 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

• 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

• 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, 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

“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

Questions?