Requirements sprint

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

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

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

Working with a client

The Goals Common understanding Communications Expectations Concept Capabilities Users Communications Expectations

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

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

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

Requirements

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

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

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

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

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)

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)

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

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.

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

Requirements