1

Project Requirements

What are they?

How do you know you got’em all?

2

Agenda

Groundwork Why do this thing? Nuts & Bolts Definition Analysis Punchline I&E

3

“If you don't know how well you are doing,

then you know you are not doing very well”

Anonymous

Who said that?

“Good stuff ain’t cheap, and cheap stuff ain’t good”

Hubert Green

4

Where do requirements come from?

Requirements come from needs1. Needs emergence

2. Needs recognition

3. Needs articulation

5

Challenges with needs

Dealing with ambiguity Needs change Customer don’t know what they want (or

they know what they want when they see it)

Possibilities present themselves as the deliverables become tangible

6

What are requirements?

Requirements are a negotiated set of measurable

customer wants and needs.

7

When do you gather requirements?

InitiationInitiation

ExecutingExecuting ControllingControlling

PlanningPlanning

ClosingClosing

Right here

8

Major requirement types

Functional Ordinary language Non-technical Understandable by

customer Customer

developed

Technical Deliverable

features Dimensions Performance specs Provide guidance

to technical staff

9

Why are they important?

Tangible embodiment of customer needs Serve as basis for project plan If requirements are flawed, planning will be

inadequate Define obligations to the customer

Output of requirements are articulated in the SOW

Compliance is determined by fulfilling the requirements

10

Worth a thousand words ($)…

0.00%5.00%

10.00%15.00%20.00%25.00%30.00%35.00%

40.00%45.00%50.00%

Req def SW Des Code Test Deploy

$0.00$1.00$2.00$3.00$4.00$5.00$6.00$7.00

$8.00$9.00

$10.00

Req def SW Des Code Test Deploy

Source of errors

Cost to correct in $1,000

11

Intermission

What experience has anyone had with turning functional specs into technical specs?

12

Requirement definition process

Gather Review Document Sign-off

13

Requirement Definition Participants

Project manager Customer

End users Sponsor

Project team members Customer and vendor

14

Good Requirements

Complete and accurate Unambiguous Verifiable Testable Sufficient for design

15

Guidelines

State explicitly and get sign-off Be realistic, If it can be misinterpreted

it will be misinterpreted There will be changes, bend but don’t

break Use pictures Monitor change

16

Where do they come from?

Interviews Customers End users Use open ended and specific questions Tape recorder

Observation Teams of two Prototyping

17

Pitfalls of prototyping

Advantages Used when

requirements are vague

Early feedback possible

Can provide go/no-go

Disadvantages Prototype mistaken

for production Not generally

scoped

18

Requirement analysis process

Assess Prioritize EvaluateTie to biz objective

Unclear reqs. Immeasurable Intangible

19

Trade offs

Nothing left to chance Restricted creativity Focus on minutiae Costly rework

Excessive flexibility Sloppy deliverables Chaotic planning Time/cost overruns

20

Document, Verify and Validate

Document and present findings for review and approval

Refine based on feedback Obtain consensus among customer

and vendor

21

Punchline

How do you know you got ‘em all? When you have enough to design They will change

Have a change management process to compensate

That is another story…

22

Prepare a project requirements document

Project summary Functional reqs. Technical reqs. Deliverables Milestones

Risk Assumptions Constraints Resource

requirements Acceptance criteria

23

Inquiry and Enlightenment