Requirements
CS121
Fall 2011
mae
Administrivia
•
•
•
•
Teams chosen, glics assigned, mail lists made
Tracs created
svns created
2nd floor access in place
– 2nd floor needs work....
• elicitation schedule coming...
Panic: Due in next 7 days
• Bunch of Phase 1 stuff
• .
Requirements
“What does the customer actually wants?”
can requirements be created, analyzed,
evaluated, etc
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.
dhu
• Failures at this stage are costly.
Cost
to Fix
is introduced
when problem is requirements
found
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
Case 1:
A friend was on review RED team for a Norwegian air defense
contract. The customer generated an ops (operations)
concept document that was about 100 pages long from which
a flat requirements document containing about 2000
requirements was generated. The problem with this contract
was that the 2000 requirements were not definite enough,
thus the result was a floating set of slightly different
requirements every 6 months or so. The project was a 3 year
project in it's 6th year with 100% overrun on a fixed price
contract (reason for the red team review).
Why are requirements so important?
• We need to know what we are supposed to
build before we can build it.
duh
• Failures at this stage are costly.
• Failures at this stage are common.
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 want
Case2:
There were two ops concept documents, each about 2-4 pages long, one from
developer view and one from a customer view.
This resulted in a 50 page top level system requirements document from
which about 5 or 6 lower level requirements documents were written e.g., spacecraft requirements document, network requirements
document, set-top box requirements document; operations requirements
document, air-link requirements document, etc.
A document was then written showing the linkage/relations between all the
various requirements.
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!
Customer: I want to pay $500 for its development
Cost
Quality
Customer: I want the best RPG ever
Time
Developer: It will be finished
when 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 or there
understanding of their needs
during project life
% increase in requirements
Growth in requirements
Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems.
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, along with price
– Monitors – 10 years ago paid $2k for a 600x800,
today $300 for a much better display + can run 2
displays
Developing requirements: Best
Practices
• Still a developing area
Developing Requirements
• Inception:
– define initial concept
– identify stakeholders
Developing requirements
Management
…
Marketing
Users
stakeholders
all of the above
Software Engineer
Developing requirements for games
Management
Marketing
…
Game Designer
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 ...
customer/stakeholder
software engineer
Requirements Elicitation
I want an RPG
better than
anything seen
before!
customer/stakeholder
software engineer
Requirements Elicitation
Ok ... off you go!
Call me when its
done.
customer/stakeholder
software engineer
Requirements
• Inception
• Elicitation: What do customer say they want?
• Analysis: What does the customer really
want?
Requirements Analysis
OK here is my
idea for the
game. What do
you think?
customer/stakeholder
software engineer
The exchange begins... and must continue
Requirement Solicitation
• Specify what not how – hard to do
Having some sort of sorting game with pictures of chemical reactions and physical
Requirements Analysis
Great! Can I have
it next week?
customer/stakeholder
software engineer
Requirements
• Inception
• Elicitation: What does the customer say they
want?
• Analysis: What does the customer really
want? What can you realistically provide? Do
you really understand.
Feasibility: Can we meet the constraints?
Cost
Quality
Time
Feasibility
• Understand the proposed system
• Understand the capabilities of your team and
tools
• Explore gaps in requirements (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)
Requirement Quality
• Specify what not how – hard to do
Having some sort of sorting game with pictures of chemical reactions and physical
reactions Chemical reactions: Baking soda/vinegar, baking, cooking, toasting, burning ect
Physical reactions: Cutting, ripping, mixing, melting Another idea is a little more
complex Having students sort the chemical elements into correct place on the periodic table
based are their properties. My idea is that an alien periodic table has been found and the
students need to place the alien elements into the correct spot based on the elements and
properties. The elements would be very similar to the earth periodic table. Students would
need to know about the number of protons neutrons electrons I attached an example of the
alien periodic table activity
• Unambiguous – English is designed for
ambuiguity
Waterfall Model
with feedback
Requirements
SRS
Design
Implementation
Test
Agile requirements
Project inception: move from requirements to goals
• Identify high level scope
• Key requirements
• Initial “goal stack”
highest priority, best modeled
goals
Well modeled means we understand what to do
and how long it will take.
lowest priority, least modeled goals
Agile requirements
At 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
Who prioritizes?
Customer driven
Risk driven
lowest priority, least modeled goal
Requirement Quality, cont
•
•
•
•
•
Testable
Feasible
Consistent – analysis critical
Prioritized
Traceable – number of systems to build a table
matching requirements (numbers) to specific
code
• Agreed upon by customer
Next time: elicitation demonstration
• Meet the customer
• At least 1 team will do an in-class elicitation
• other teams will do their elicitation Tuesday
evening 5-8. after class (or if need be Wed
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
• You may be doing this on Skype or just the
phone, so be prepared to ‘present’ your slides
without viewing
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 discover
issues 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 the
teacher an opportunity to confirm/correct
• Thank the teacher
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
Lecture 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?
Summary
• what are requirements
• types
• difficulties in getting ‘good’ equirements
• process of acquiring requirements
• cycle of elicitation - evaluate/analysis - refine
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
• email has been sent, waiting for responses
from teachers.....
The End
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”