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
Top Related