EECS 481 - 1/18/07
prof
amazed that open-source works
is customer for our project
has kids
will check random sampling of requirements
team organization
agile
pair programming
works with 2, not 3
avoid loosing goto person
learn from more experienced
open source
most communication by email
unpaid
little documentation
why work on it?
sheer enjoyment of worthwhile task
learning experience
members must feel like they are making a contribution
team lead needs to be a good motivator?
succeeds because
nature of target product
personality of instigator
talents of members of core group
organization essentially irrelevant
examples
volunteers
killing enthusiasm
not using work
see work that you did in action
always feel like you are making a contribution
requirements
what the system does
not how the system works
functionality
performance
- tions
inception
elicitation
elict requirements from all stakeholders
ask customer
determine scope
clarify
elaboration
user scenarios
storyboard
user authentication? naw
list of schools that have already been entered
negotiation
squeeze as much work for money
if you always say yes to customer, you will loose morale of workforce
specification
contract
requirements document
what system has to do
validation
how do you know when requirements are met?
- noicemaker
buttons
when button is pressed, unique noice is produced
sounds must be annoying
lights flash when button is pressed
noices must be short (3 seconds?)
bright colors to attract child
non-functional
small device
small enough to fit into a child's hand
volume, below certain level
lifespan
hours of use on certain battery
can't open it up
safe for child
can't eat it
can't open battery compartment
- traceability
how do you go back and make sure all your requirements are met?
requirements vs code modules
functional requirements
acceptable states
behaviour given stimuli
- doll
teach curing
child safe
looks like a baby
curing action causes simulation of curing
picking up baby causes baby to laugh
healthy state to sick state
- form
written in customer's natural language
sometimes need more rigorous
- documentation
number
title
description
source
priority
notes
description of what
contract between developer and customer
not very well
some process models
teams
incremental model
we're doing it
well
requirements
agile
open source
|
| |