Project requirements management
-
Upload
ian-cammack -
Category
Education
-
view
445 -
download
0
Transcript of Project requirements management
![Page 1: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/1.jpg)
Dr Ian [email protected]
MSc Project Management
Key source: Alexander, I.F. & Stevens R. (2002) “Writing better requirements”, Addison-Wesley
![Page 2: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/2.jpg)
![Page 3: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/3.jpg)
• Requirements are the heart & soul of the project
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf
![Page 4: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/4.jpg)
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
![Page 5: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/5.jpg)
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
![Page 6: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/6.jpg)
Draft statement of requirements
RequirementsproblemsRequirements
document
Requirementsanalysis
Requirementselicitation
Requirementsnegotiation
![Page 7: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/7.jpg)
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
![Page 8: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/8.jpg)
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
![Page 9: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/9.jpg)
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
![Page 10: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/10.jpg)
Viewpoints
socio-political environment
organisation
supervisors / line managers
operators
equipment
Viewpoints
![Page 11: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/11.jpg)
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?
![Page 12: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/12.jpg)
Scenario Based Approaches
http://scenarios2strategy.com/assets/process.gif
![Page 13: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/13.jpg)
Using scenarios to understand requirements
Objectives
Goal: “To …”
Goal
Goal
Step
Step
Exception Step
Step
![Page 14: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/14.jpg)
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)
![Page 15: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/15.jpg)
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
![Page 16: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/16.jpg)
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
![Page 17: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/17.jpg)
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”
![Page 18: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/18.jpg)
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
![Page 19: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/19.jpg)
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
![Page 20: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/20.jpg)
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
![Page 21: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/21.jpg)
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’
![Page 22: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/22.jpg)
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’
![Page 23: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/23.jpg)
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
![Page 24: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/24.jpg)
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.
![Page 25: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/25.jpg)
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!”)
![Page 26: Project requirements management](https://reader035.fdocuments.in/reader035/viewer/2022070519/58f009951a28ab50398b462d/html5/thumbnails/26.jpg)
• 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