Paper Prototypes

1
Paper Prototypes Requirements Analysis
Today/Friday 1-page project descriptions to
DonnaFor next class Pressman 10.5 Homework 1

• Team Status Reports
• Project Management (continued)
• Bio Break (5 minutes)
• Paper Prototypes
• Requirements Analysis

Homework 1 See web site.
2
Project Management

• People Management roles responsibilities
• W5HH
• Make v. Buy
• Outsourcing
• Plan vs. Reality

3
Typical Project Plan Elements

• Scope
• Schedule
• Team organization
• Technical description of proposed system
• Standards, procedures, tools, techniques
• Quality assurance plan
• Configuration management plan
• Documentation plan
• Data management plan
• Resource management plan
• Test plan
• Training plan
• Security plan
• Risk management plan
• Maintenance plan

Source Pfleeger text.
4
The Right-to-Left Schedule
5
Paper Prototyping
a.k.a. low fidelity prototypes

• Listen to the customer
• Build / revise mock-up
• Customer test drives mockup

http//www.ucc.ie/hfrg/projects/respect/urmethods/
paperproto.htm http//www.infodesign.com.au/protot
yping/default.html http//www.oclc.org/usability/p
rototyping/oclc.htm
6
Requirements Process

• Elicitation
• Analysis Negotiation
• Specification
• Models
• Validation
• Management

7
Requirements Elicitation

• Scope issues
• Communication issues
• Change issues
• Pressmans checklist
• Feasibility, people, technical environment, key
  constraints, elicitation methods, variety of pts.
  of view, identify candidates for prototyping,
  usage scenarios

8
Requirements Analysis / Negotiation

• Map requirements to objectives?
• Right level of detail?
• Essential or gold plating?
• Clear scope / bounds of each requirement?
• Requirement conflicts?
• Technically achievable?
• Testable requirements?

9
System Modeling

• Flow charts
• Input, processing, output
• UI
• (See Donnas methodology for projects)

10
Requirements Validation

• Formal technical review
• Include engineers, customers, users,
  stakeholders
• Does everyone understand the requirements the
  same way?
• Quantified requirements? Bounded requirements?
• Dependencies identified?
• Can we map the requirements to
• Objectives
• System models / other documents
• Traceability tables