Project requirements management

Dr Ian [email protected]

MSc Project Management

Key source: Alexander, I.F. & Stevens R. (2002) “Writing better requirements”, Addison-Wesley

• Requirements are the heart & soul of the project

Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

The purpose of requirements

• To show what results the stakeholders want.

• To give stakeholders a chance to say what they want

• To represent different viewpoints

• To check the design

• To measure progress

• To accept products against precise criteria

Remember:

• Gulf between customers, marketing dept. & developers

• It takes time (up to 25% calendar time)

• Iterative process

• They will change so keep checking they are valid

• Users may feel threatened

Draft statement of requirements

RequirementsproblemsRequirements

document

Requirementsanalysis

Requirementselicitation

Requirementsnegotiation

Looking for Viewpoints• No typical user - not heterogeneous

• Viewpoints come from stakeholders– end-users, managers, information systems, external

bodies or regulators, customers

• Viewpoints come from environment which constrains the project– physical, organisation, human, laws, regulations or

standards

Viewpoints on a problemproblem

system

VP1req 1areq 1breq 1c

VP3req 3areq 3breq 3creq 3d

VP2req 2areq 2b

NB: The overlaps help us to discover requirements conflict

Space Telescope

Ngc2818 taken by Hubble Telescopehttp://commons.wikimedia.org/wiki/File:NGC_2818_by_the_Hubble_Space_Telescope.jpg

http://hubblesite.org/the_telescope/hubble_essentials/graphics/telescope_essentials_introduction1_lg.jpg

Viewpoints

socio-political environment

organisation

supervisors / line managers

operators

equipment

Viewpoints

Stakeholder Based Approach:· What does the stakeholder have to achieve? How is success

measured?· Motivation: what are the stakeholders sources of job satisfaction

/ stress?· What are the stakeholders knowledge and skills?· Group dynamics: are there any significant workgroup

characteristics · In the stakeholders roles, what are the critical tasks: frequency,

fragmentation, stress, discretion?· Are there any special working conditions which might effect

the use: lonely, sociable, hot, cold, dusty, wet?

Scenario Based Approaches

http://scenarios2strategy.com/assets/process.gif

Using scenarios to understand requirements

Objectives

Goal: “To …”

Goal

Goal

Step

Step

Exception Step

Step

Using scenarios to understand requirements

Ensure company’s services arepaid for

Record servicesprovided

Calculate the cost

Receive payment

Prepare the bill

Send the bill

To find the unit cost of the individual services

To find the net cost for the number of services provided

To find the billing amount inc. prepayment & interest

To find the gross cost (inc. tax & delivery)

Vending Machine Requirements

Out of C

lass Activ

ity : I

ndividual or P

airs

Four different stakeholders

Four requirements for eachstakeholder

Four different scenarios

Four requirements from each scenario

How to gain requirements data

• Mapping interactions between ‘system’ (who is going to touch it)

• Snowball interviewing (users, admin, consultants, mgrs)• Workshops• Documentation (esp. problem reports) • Observation• Prototypes• Benchmark versus previous versions / rival products

Prioritisation• Need to avoid a ‘shopping list’ approach

• “MUST HAVE” – the project will fail without this

• “WANT TO HAVE” – considerable value but could be delivered after initial ‘go-live’ date

• “LUXURY”

Structuring the requirements document

• 1. General description– 1.1 Product perspective– 1.2 General capabilities– 1.3 General constraints– 1.4 User characteristics– 1.5 Operational environment– 1.6 Assumptions and dependencies

• 2. Specific requirements– 2.1 Capabilities (using the scenarios)– 2.2 Constraints

Prioritisation: ScoringStakeholder A

Stakeholder B

Stakeholder C

Stakeholder D

Stakeholder E

Requirement 1

Requirement 2

Requirement 3

Requirement 4

Requirement 5

Total 100 100 100

50

10

40

40

40

20 20

20

20

20

20

Writing requirements: DO• Simple direct sentences

– The pilot shall be able to view the airspeed• Simple English

– The airline shall be able to change the aircraft’s seating from business to holiday charter use in less than 12 hrs

– [note avoided ‘reconfigured’ & other big words. Avoided abbreviations / jargon]

• Identify the type of user who wants it– The pilot / the user

• State results • Define verifiable criteria

Writing requirements: DO NOT• Ambiguity

– “The same subsystem shall generate a visible or audible …”

• Avoid joining two requirements together– Avoid ‘and’, ‘or’, ‘with’, ‘also’

• Avoid let-out clauses– “The forward passenger doors shall open automatically

when the aircraft has halted, except when the rear ramp is deployed”

– Avoid ‘if’, ‘when’, ‘but’, ‘except’, ‘unless’, ‘although’ • Do not design the solution

– Avoid names of components or materials• Do not speculate

– Avoid ‘usually’, ‘generally’, ‘often’, ‘normally’, ‘typically’

Writing requirements:• Avoid vague terms

– “The user handbook shall be user friendly”– Avoid ‘user-friendly’, ‘flexible’, ‘approximately’, ‘improved’, ‘efficient’

• Don’t express possibilities– “The system ought to be sensitive enough to …”– Avoid ‘may’, ‘might’, ‘should’, ‘ought’, ‘could’, ‘probably’

• Avoid wishful thinking– “The gearbox shall be 100% safe in normal operation” – Avoid ‘100% safe / reliable’, ‘never fail’, ‘upgradable to all future situations’

Requirements Capture

• Unique ID• Description• Stakeholders Interested• Importance (Must Want Luxury)• Associated Products• Status (proposed, work in progress, delivered, accepted,

rejected, to be modified)• Acceptance criteria• Verification method

An example: Identify what is wrong with these

• The sailboat shall be able to carry a crew of up to two adults and two 15-year old children.

• A crew of two adults or children shall be able to lift the sailboat on to its trailer.

• The sailboat shall be controllable by a crew consisting of two persons aged between 7 and 70 in any wind between Force 1 & Force 6.

Handy Hints

• Constraint: governs the (or part of the) system. It narrows down the range of possible alternatives. Could be related the safety, to performance, to integration (with other systems / operations), quality standards, national / international regulations etc.

• Be curious: ask ‘Why?’ to understand the real requirement.

• Do not confuse the solution with the requirement (e.g. “I need a MacBook Air!”)

• Additional resources:– National Audit Office “Common Causes of Project Failure”– http://www.dfpni.gov.uk/cpd-coe-ogcnaolessons-common-causes-of-project-failure.pdf

– Dorsey, P. (2005) Top 10 Reasons Why Systems Projects Fail”– http://www.hks.harvard.edu/m-rcbg/ethiopia/Publications/Top%2010%20Reasons%20Why%20Sys

tems%20Projects%20Fail.pdf