Requirements Management

1. Dr Ian Cammack
i.j.Cammack@soton.ac.uk
MSc Project Management
Key source: Alexander, I.F. & Stevens R. (2002) “Writing better
requirements”, Addison-Wesley

3. • Requirements are the heart & soul of the project
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

4. 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

5. 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

6. Draft statement
of requirements
Requirements
problemsRequirements
document
Requirements
analysis
Requirements
elicitation
Requirements
negotiation

7. 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

8. Viewpoints on a problem
problem
system
VP1
req 1a
req 1b
req 1c
VP3
req 3a
req 3b
req 3c
req 3d
VP2
req 2a
req 2b
NB: The overlaps help us to
discover requirements
conflict

9. Space Telescope
Ngc2818 taken by Hubble Telescope
http://commons.wikimedia.org/wiki/File:NGC_2818_by_the_Hubble_Space_Telesc
http://hubblesite.org/the_telescope/hubble_essentials/graphics/telescope_essentials_introduction1_lg.jpg

10. Viewpoints
socio-political environment
organisation
supervisors / line managers
operators
equipment
Viewpoints

11. 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?

12. Scenario Based Approaches
http://scenarios2strategy.com/assets/process.gif

13. Using scenarios to understand requirements
Objectives
Goal: “To …”
Goal
Goal
Step
Step
Exception Step
Step

14. Using scenarios to understand requirements
Ensure company’s
services are
paid for
Record services
provided
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)

15. Vending Machine Requirements
Four different stakeholders
Four requirements for each
stakeholder
Four different scenarios
Four requirements from
each scenario

16. 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

17. 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”

18. 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

19. Prioritisation: Scoring
StakeholderA
StakeholderB
StakeholderC
StakeholderD
StakeholderE
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

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

21. 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’

22. 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’

23. 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

24. 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.

25. 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!”)

26. • 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%20Systems%20Projects%20Fail.pdf