1. Requirements sprint

2. Deliverables Web site Meetings Contacts Team rules Project concept
Team roles
Project concept
Project tweet
Personas
User stories
Use cases
Requirements
Prototype
Platform selection
Dev environment

3. Web Site Working Site Primary documentation
(structure may change with new process)
Needs to be EASY for me to find things
Due at first team meeting

4. Team Rules Two classes Why? Meeting and behavioral rules
Coding standards (after you select platform)
Use existing
Why?
Easier BEFORE there’s a problem
Establish expectation

5. Working with a client

6. The Goals Common understanding Communications Expectations Concept
Capabilities
Users
Communications
Expectations

7. First Steps
To build something, we first must understand what it is we’re building
Establish expectations
Understandable by both the client and the developer
Need to understand
Concept
Users
Use cases
Requirements

8. Start with a Concept MUST BE CRISP AND SIMPLE
How do you tell people about your project
Why are you doing it
What makes it unique or different
brochure elevator speech tweet

9. Clients vs. Users The client is the person “paying the bill”
The users are the ones that will
Use your system
Maintain your system
Administer your system
Know
How they perform their tasks now
Their skill level
Their time constraints, tolerances, expectations

10. Requirements

11. Why Written Requirements?
Unambiguous
Defines goals
Cost of finding a requirements bug later can be 100 times more expensive

12. Mars Climate Orbiter (Dec 98)
Intended to orbit Mars
Supposed to provide output in newton seconds
Instead crashed into it
Instead provided in pound-force seconds
Minimum distance:
80 km

13. Sources of requirements
People
Stakeholders
Who are the stakeholders?
Issues:
Conflicting requirements
Wants vs. needs
Helping the customer articulate the requirements
Use cases
Hardware constraints
Laws of physics and nature
Social responsibility

14. Social responsibility
Privacy
Security
How it will (can) be used
Does it have the potential for misuse?
Can it be used to harm people?

15. Sources of Requirements: People vs. Other
decision support system for military tactics
unconstrained
video game
Type of application
corporate accounting system
manufacturing control system
enhancement to corporate accounting system
flight control system for airliner
highly constrained
missile guidance system
relatively low
% of requirements gathered from people
relatively high
(Brackett, CMU)

16. Types of Requirements Functional : services needed
Usability : how easy it is to do it
Performance: speed, capacity, memory
Reliability and availability: failure rates
Error handling: how to handle
Interface: user and program
Constraints: systems and tolerances
(Inverse: what it won’t do)

17. A requirement must be … Documented Expressed precisely
Expressed as what, not how
Prioritized
essential, desirable, optional
primary, secondary, tertiary
Testable

18. The set of requirements must be…
Consistent
Three requirements:
Only basic food staples will be carried
Everyone will carry water
Basic food staples are flour, butter, salt, and milk
Complete
The function tells whether 3 numbers produce an equilateral, isosceles, or scalene triangle.

19. Requirement Level Two phases
Requirements written at customer level
Developer will convert in order to do design
Once agreement exists with customer, developer “translates” them into his language
Example
Customer: User must never lose more than 10 minutes of work
Developer: Autosaving is required

20. Requirements