Requirements CS121 Spring 2010. Administrivia new student: Guillermo artist: Jackie Wijaya.

Requirements

CS121

Spring 2010

Administrivia

• new student: Guillermo

• artist: Jackie Wijaya

Requirements

“What does the customer actually want?”

Types of Requirements: FURPS+

• Functional: features, capabilities

• Usability: human factors, aesthetics, consistency, documentation

• Reliability: frequency of failure, recoverability, predictability

• Performance: response times, throughput, accuracy, availability, resource usage

• Supportability: adaptability, maintainability, configurability

• +: others

Why are requirements so important?

• We need to know what we are supposed to build before we can build it.

• Failures at this stage are costly.

duh

when problem is found

requirements design construction

requirements 1x

design 3x 1x

construction 5-10x 10x 1x

system test 10x 15x 10x

post ship 10-100x 25-100x 10-25x

when problem is introduced

Why are requirements so important?

• We need to know what we are supposed to build before we can build it.

• Failures at this stage are costly.

• Failures at this stage are common.

duh

Most errors found by users in software are the result of

A. coding errors

B. errors in requirements

C. system integration errors

D. errors in the design of the solution

Answer: B“Software’s Chronic Crisis”

Why are requirements so difficult to specify?

• Customer’s can’t tell you what they want

Why are requirements so difficult to specify?

• Customer’s can’t tell you what they want– they don’t know– they don’t clearly articulate their needs

Why are requirements so difficult to specify?

• Customer’s can’t tell you what they need– they don’t know– they don’t clearly articulate their needs

• Customer’s have conflicting needs

You must control at least one parameter!

Cost

Quality Time

Customer: I want the best RPG ever

Customer: I want to pay $500 for its development

Developer: It will be finishedwhen hell freezes over.

Why are requirements so difficult to specify?

• Customer’s can’t tell you what they need– they don’t know– they don’t clearly articulate their needs

• Customer’s have conflicting needs

• Customer’s needs change

Growth in requirements

0

10

20

30

40

50

60

10 100 1000 10000 100000

Project Size in Function Points

Cre

epin

g R

eq's

as

% o

f O

rig

Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems.

% in

cre

as

e in

re

qu

irem

en

ts

du

rin

g p

roje

ct

life

Why are requirements so difficult to specify?

• Customer’s can’t tell you what they need– they don’t know– they don’t clearly articulate their needs

• Customer’s have conflicting needs

• Customer’s needs change

• Technology changes

Developing requirements: Best Practices

Developing Requirements

• Inception: – define initial concept– identify stakeholders

Developing requirements

Software Engineer

Management

Marketing

Users

…

stakeholders

Developing requirements for games

Game Designer

Management

Marketing

Users

…

Software engineers

Developing Requirements

• Inception: – define initial concept– identify stakeholders– gather background information: competitive

analysis, technology review, etc.– identify “perceived requirements“

Developing Requirements

• Inception

• Elicitation: Ask the customer what they want

Requirements Elicitation

I want you to build a game ...

software engineercustomer/stakeholder

I want an RPG better than

anything seen before!

software engineer

Requirements Elicitation

customer/stakeholder

Ok ... off you go!

Call me when its done.

customer/stakeholder software engineer

Requirements Elicitation

Requirements

• Inception

• Elicitation: What do customer say they want?

• Analysis: What does the customer really want?

OK here is my idea for the

game. What do you think?

customer/stakeholder software engineer

Requirements Analysis

Great! Can I have it next week?

customer/stakeholder software engineer

Requirements Analysis

Requirements

• Inception

• Elicitation: What does the customer say they want?

• Analysis: What does the customer really want? What can you realistically provide?

Feasibility: Can we meet the constraints?

Cost

Quality Time

Feasibility

• Understand the proposed system

• Understand the capabilities of your team and tools

• Explore gaps (or risks)

Requirements

• Inception

• Elicitation: What does the customer say they want?

• Analysis: What does the customer really want? What can you realistically provide?

Software Requirements Specification (SRS)

Waterfall Model

Requirements

Design

Implementation

Test

with feedback

SRS

Agile requirementsProject inception: • Identify high level scope• Key requirements• Initial “goal stack”

highest priority, best modeled goals

lowest priority, least modeled goals

Well modeled means we understand what to doand how long it will take.

Agile requirementsAt the start of each iteration: • Incorporate new goals (often produced by last iteration)• Remove items no longer needed• Reprioritize• Clarify requirements for goals at top of stack• Plan iteration

highest priority, best modeled goal

lowest priority, least modeled goal

Who prioritizes?Customer driven Risk driven

Requirement Quality

• Specify what not how• Unambiguous• Testable• Feasible• Consistent• Prioritized• Traceable• Agreed upon by customer

Next time: elicitation demonstration

• Meet the customer

• 1 team will do and in-class elicitations

• other teams will do their elicitation wed. after class (or if need be thursday morning)

Prior to Elicitation

• Prepare short (2-4 slide) concept presentation

• List of “perceived” requirements and questions to clarify them

• Open ended questions to better understand needs

Elicitation format

• Introduce yourselves and provide agenda• Give your (2-4 slide) concept presentation• Start with open-ended information gathering

This is where you’ll discoverissues you haven’t thought of

on your own.

Elicitation format

• Introduce yourselves and provide agenda• Give your (2-4 slide) concept presentation• Start with open-ended information gathering• Follow up on new issues raised• Discuss “perceived” requirements

Based on your background research you should have some reqs in mind

before the meeting starts.

Elicitation format

• Introduce yourselves and provide agenda• Give your (2-4 slide) concept presentation• Start with open-ended information gathering• Follow up on new issues raised• Discuss “perceived” requirements• Discuss priorities• Present a summary of key points and give him

an opportunity to confirm/correct• Thank him

Elicitation roles

• Moderator: Leads the meeting, discussion

• Scribe: Takes notes

• Others– Distill discussion for final summary– Keep track of points that need clarification– Keep track of pre-determined requirements

that need validation– Watch clock, agenda

Elicitation Report

• When, where, and who

• Summarize discussion

• New requirements

• Validation of prior requirements

• Priority of requirements

• Any other interesting information

Sample questions

• Why are requirements so important?• Why are they so difficult to specify?• What are the various types of requirements?• What are the first steps of requirements gathering?• What is a customer elicitation?• What is involved in requirements analysis?• What is an SRS?• What constitutes quality in requirements?• How are requirements managed in agile processes?

Assignment for next time

• Prep for elicitation– concept presentation– open ended questions– perceived reqs and questions to clarify– roles assigned to team members

Scheduling of elicitations

• In-class

• After-class