Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Bus03: Zen and the art of
requirements gathering
Why getting to
“In time, On budget and In scope”
is easier if you start o...
• Business Consultant
• Silverside
• @FemkeGoedhart
• http://femkegoedhart.com
Tim Clark Femke Goedhart
2#engageug
• Direc...
• And now for something completely different…
3#engageug
4#engageug
Roleplay #1
5#engageug
6#engageug
10 Cosmic truths about
requirements gathering
From
‘More about software requirements’ by Karl E. Wiegers
More a...
7#engageug
#1: If you don’t get the requirements right,
it doesn’t matter how well you execute the
rest of the project
Mor...
Development Work
Development
60%
Rework
40%
Shull et al. 2002, GAO 2004
Influence Of Requirements On Rework
Rework
40%
Other
25%
Leffingwell 1997
Requirement
Errors
75%
#2 Requirement development is a discovery
and invention process, not just a collection
process
10#engageug More about Soft...
Expectation Gap
Time —>
Expectation gap
Software Requirements third edition, Karl Wiegers & Joy Beatty
Time —>
Expectation gap
touch pointtouch point
Software Requirements third edition, Karl Wiegers & Joy Beatty
Cone of uncertainty
13#engageug Boehm 1981
#3 Change happens
(so does sh*t)
14#engageug More about Software Requirements 2006, Karl Wiegers
• Get sign off, before you move on
• Manage the refinement of requirements
• Change management process for RFCs
15#engageug
Start With The Why
Vision & Scope document
User requirements document
Software requirements specification
WHY
HOW
WHAT
Increasing Levels Of Details:
Vision & Scope document
User requirements document
Software requirements specification
Busin...
1x
Cost Of Rework
1x
Cost Of Rework
5-10x
1x
5-10x
100x
Boehm 1981; Grady 1999; Haskins 2004
Cost Of Rework
• So do you really need an RFC process ???
21#engageug
Roleplay #2
22#engageug
#4 The interests of all stakeholders intersect in
the requirements process
23#engageug More about Software Requirements 20...
Analyst
Other
Stakeholders
Customer
User
Developer
Tester
Project
Manager
24#engageug More about Software Requirements 200...
Office politics – org chart
Influencers
Decision
Makers
Sponsor Fred Jones
Tamsin
Smith
Rajesh
Patel
Alma
Simmons
Nigel
Fa...
• Direct users
• Indirect users
• Stakeholders
• Sponsors
• Acquirer
• Management
• Compliance auditor
• Suppliers
• Regul...
#5 Customer involvement is the most critical
contributor to software quality
27#engageug More about Software Requirements ...
• Identify user classes
• Select product champions
• Build prototypes
• Agree on customer rights & responsibilities
28#eng...
29#engageug
#6 The customer is not always right, but the
customer always has a point
30#engageug More about Software Requirements 2006...
• Be critical, play devils advocate
• Be open
• Be realistic
…..and get the customer to see reason
31#engageug
Roleplay #3
32#engageug
33#engageug
34#engageug
?
35#engageug
?
36#engageug
!
37#engageug https://www.youtube.com/watch?v=OmCxtWrRQJ8
#7 The first question an analyst should ask
about a proposed new requirement is,
“is this requirement in scope?”
38#engage...
Context diagram
Cafeteria
Ordering
System
Menu
Manager
Patron
Order
Process
Meal
Deliverer
Payroll
System
39#engageug DeMa...
MOSCOW
Requirement M S C W
Insert multiple order lines x
Create an export of closed orders x
Allow to copy order details t...
MOSCOW
Requirement Costs M S C W
Insert multiple order lines $ 100 x
Create an export of closed
orders
$ 1500 x x
Allow to...
EISENHOWER DECISION MATRIX
Urgent Not Urgent
Important
Crises
Deadlines
Problems
Relationships
Planning
Recreation
Not Imp...
PRIORITISE
Urgent Not Urgent
Important Must! Should
Not Important Could
Won’t
(Nice to have)
#8 Even the best requirements document
cannot – and should not – replace human
dialogue
44#engageug More about Software Re...
Time —>
Expectation gap
touch pointtouch point
Software Requirements third edition, Karl Wiegers & Joy Beatty
#9 The requirements might be vague, but the
product will be specific
46#engageug More about Software Requirements 2006, Ka...
Make it “SMART”
• Specific
• What? Why? Who? Where? Which?
• Measurable
• How much? How many? Is it quantifiable?
• Attain...
A picture is worth more than a 1000 words
Requirement
The current solution that Xxxxx have created in the Xxxxxxxx, XX dep...
#10 You’re never going to have perfect
requirements
49#engageug More about Software Requirements 2006, Karl Wiegers
Cone of uncertainty
50#engageug Boehm 1981
51#engageug
Questions ?
Bibliography
• Software Requirements (Third Edition)
Karl Wiegers & Joy Beatty
ISBN: 978-0-7356-7966-5 (Microsoft Press)
•...
• Business Consultant
• Silverside
• @FemkeGoedhart
• http://femkegoedhart.com
Tim Clark Femke Goedhart
53#engageug
• Dire...
Upcoming SlideShare
Loading in …5
×

Zen and the art of requirements gathering, why getting to "In time, On budget and In scope" is easier if you start out right

2,132 views

Published on

Often forgotten or trivialized, good requirements gathering can make or brake your project. This session will give you techniques and tips on how to effectively get to the core of the requirements, identify ways of prioritizing them and explains some core concepts of Functional and Technical design elements. Based on years of experience gathering requirements (and working with them!) Femke & Tim will take you through some of the real life examples they've come across and a lot of do's & don'ts they have run into. Tying them into practice and theory that can help you get your projects off to a better start.

This session was presented on March 30th 2015 in Gent Belgium during the http://Engage.ug usergroup event by Tim Clark & Femke Goedhart

Published in: Data & Analytics

Zen and the art of requirements gathering, why getting to "In time, On budget and In scope" is easier if you start out right

  1. 1. Bus03: Zen and the art of requirements gathering Why getting to “In time, On budget and In scope” is easier if you start out right 1#engageug
  2. 2. • Business Consultant • Silverside • @FemkeGoedhart • http://femkegoedhart.com Tim Clark Femke Goedhart 2#engageug • Director of Prof. Services • Teamstudio • @TimsterC • http://tc-soft.com
  3. 3. • And now for something completely different… 3#engageug
  4. 4. 4#engageug Roleplay #1
  5. 5. 5#engageug
  6. 6. 6#engageug 10 Cosmic truths about requirements gathering From ‘More about software requirements’ by Karl E. Wiegers More about Software Requirements 2006, Karl Wiegers
  7. 7. 7#engageug #1: If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project More about Software Requirements 2006, Karl Wiegers
  8. 8. Development Work Development 60% Rework 40% Shull et al. 2002, GAO 2004
  9. 9. Influence Of Requirements On Rework Rework 40% Other 25% Leffingwell 1997 Requirement Errors 75%
  10. 10. #2 Requirement development is a discovery and invention process, not just a collection process 10#engageug More about Software Requirements 2006, Karl Wiegers
  11. 11. Expectation Gap Time —> Expectation gap Software Requirements third edition, Karl Wiegers & Joy Beatty
  12. 12. Time —> Expectation gap touch pointtouch point Software Requirements third edition, Karl Wiegers & Joy Beatty
  13. 13. Cone of uncertainty 13#engageug Boehm 1981
  14. 14. #3 Change happens (so does sh*t) 14#engageug More about Software Requirements 2006, Karl Wiegers
  15. 15. • Get sign off, before you move on • Manage the refinement of requirements • Change management process for RFCs 15#engageug
  16. 16. Start With The Why Vision & Scope document User requirements document Software requirements specification WHY HOW WHAT
  17. 17. Increasing Levels Of Details: Vision & Scope document User requirements document Software requirements specification Business requirement Business rules User requirement Quality Attribute External interfaces Functional requirement System requirement Constraints Non-Functional requirement Software Requirements third edition, Karl Wiegers & Joy Beatty
  18. 18. 1x Cost Of Rework
  19. 19. 1x Cost Of Rework 5-10x
  20. 20. 1x 5-10x 100x Boehm 1981; Grady 1999; Haskins 2004 Cost Of Rework
  21. 21. • So do you really need an RFC process ??? 21#engageug
  22. 22. Roleplay #2 22#engageug
  23. 23. #4 The interests of all stakeholders intersect in the requirements process 23#engageug More about Software Requirements 2006, Karl Wiegers
  24. 24. Analyst Other Stakeholders Customer User Developer Tester Project Manager 24#engageug More about Software Requirements 2006, Karl Wiegers
  25. 25. Office politics – org chart Influencers Decision Makers Sponsor Fred Jones Tamsin Smith Rajesh Patel Alma Simmons Nigel Falstaff Finlay McDonagh 25#engageug
  26. 26. • Direct users • Indirect users • Stakeholders • Sponsors • Acquirer • Management • Compliance auditor • Suppliers • Regulatory body • Quality assurance • Etc, etc……. Who will use it? Who will depend on it? Who has a stake in it? Who will own it?
  27. 27. #5 Customer involvement is the most critical contributor to software quality 27#engageug More about Software Requirements 2006, Karl Wiegers
  28. 28. • Identify user classes • Select product champions • Build prototypes • Agree on customer rights & responsibilities 28#engageug
  29. 29. 29#engageug
  30. 30. #6 The customer is not always right, but the customer always has a point 30#engageug More about Software Requirements 2006, Karl Wiegers
  31. 31. • Be critical, play devils advocate • Be open • Be realistic …..and get the customer to see reason 31#engageug
  32. 32. Roleplay #3 32#engageug
  33. 33. 33#engageug
  34. 34. 34#engageug ?
  35. 35. 35#engageug ?
  36. 36. 36#engageug !
  37. 37. 37#engageug https://www.youtube.com/watch?v=OmCxtWrRQJ8
  38. 38. #7 The first question an analyst should ask about a proposed new requirement is, “is this requirement in scope?” 38#engageug More about Software Requirements 2006, Karl Wiegers
  39. 39. Context diagram Cafeteria Ordering System Menu Manager Patron Order Process Meal Deliverer Payroll System 39#engageug DeMarco 1979, Karl Wiegers 2003
  40. 40. MOSCOW Requirement M S C W Insert multiple order lines x Create an export of closed orders x Allow to copy order details to allow quick registration x Allow for inserting personal notes on orders x
  41. 41. MOSCOW Requirement Costs M S C W Insert multiple order lines $ 100 x Create an export of closed orders $ 1500 x x Allow to copy order details to allow quick registration $ 250 x Allow for inserting personal notes on orders $ 100 x x
  42. 42. EISENHOWER DECISION MATRIX Urgent Not Urgent Important Crises Deadlines Problems Relationships Planning Recreation Not Important Interruptions Meetings Activities Time Wasters Pleasant Activities Trivia
  43. 43. PRIORITISE Urgent Not Urgent Important Must! Should Not Important Could Won’t (Nice to have)
  44. 44. #8 Even the best requirements document cannot – and should not – replace human dialogue 44#engageug More about Software Requirements 2006, Karl Wiegers
  45. 45. Time —> Expectation gap touch pointtouch point Software Requirements third edition, Karl Wiegers & Joy Beatty
  46. 46. #9 The requirements might be vague, but the product will be specific 46#engageug More about Software Requirements 2006, Karl Wiegers
  47. 47. Make it “SMART” • Specific • What? Why? Who? Where? Which? • Measurable • How much? How many? Is it quantifiable? • Attainable • Can it be achieved with the resources & facilities available? • Relevant • Does it relate to the project vision & scope? • Timely • Can I set a date to it?
  48. 48. A picture is worth more than a 1000 words Requirement The current solution that Xxxxx have created in the Xxxxxxxx, XX depot is that they complete a spreadsheet that is shared across all members of the depot. This is effective but is a lot of work to enter all data for each delivery or collection. It’s also dependent on each driver having a smartphone with a data connection to access the Google spreadsheet while out at each delivery/collection site. The photos that are currently brought back are then uploaded at the office and there is a final task to match the photo with the delivery record. The requirement is to have a system for the depot dispatcher to be able to assign jobs to each truck for the day and also be able to assign ad-hoc deliveries or collections while the driver is out on their route. The drivers needs to be able to select which truck they are assigned to and then see the jobs that are assigned to that truck. Once they have arrived at the delivery site, they need to be able to take photographs of the site as they arrive, the materials delivered to site and then the site as they leave. Also the ability to capture a signature and receiver’s name or to record that there was no one on site to receive the delivery. Solution The proposed solution is that there will be two streams of development but a single Notes/Domino .nsf for each depot. One stream will be for the dispatcher side of the application and based on a desktop browser and one for the driver’s version of the application that will be capable of running in Teamstudio Unplugged on iPhone or Android mobile devices. The dispatcher’s screen would be able to take a delivery schedule item and place it onto a truck’s route. The system would know the gross weight of each delivery and the max laden capacity of each vehicle and therefore not allow any one truck to be over loaded. Each driver will be able to readjust the delivery schedule based on his/her local knowledge of the route and be able to drag and drop each item on their route schedule. Once the driver has delivered their goods they can update the dispatcher by running a sync of the system so that the central database is updated with the collected information. The driver starts the process by selecting which vehicle they are assigned to and then gets to view the deliver schedule. Once they have organized it to their liking the driver can set off to the first delivery. At the delivery the driver clicks on the job card and is asked to take a photo of the scene to record the original state of the delivery environment. Once the goods have been delivered to site then the driver can take another photo to record the good on-site. He/She can then gather a delivery signature from the person receiving the goods or just click ‘No Signature’ if there is no one there. Just before leaving the driver takes a last photo and to show the delivery environment after the delivery has been made to prove that no damage has been caused during the time of delivery. This is all sent back to the controller so that they have an understanding of the delivery status and the site status before, during and after delivery. The Dispatcher also knows how far along he schedule his driver is at any given point. They also have all the information required should a customer call to question a delivery status or goods left by the driver. The sketches that follow are Teamstudio’s concept images for this application and will be subject to change when discussed with the customer during the initial phase of the development project. 48#engageug
  49. 49. #10 You’re never going to have perfect requirements 49#engageug More about Software Requirements 2006, Karl Wiegers
  50. 50. Cone of uncertainty 50#engageug Boehm 1981
  51. 51. 51#engageug Questions ?
  52. 52. Bibliography • Software Requirements (Third Edition) Karl Wiegers & Joy Beatty ISBN: 978-0-7356-7966-5 (Microsoft Press) • More About Software Requirements (Best Practices) Karl Wiegers ISBN: 978-0-7356-2267-8 (Microsoft Press) • Mockup tool: http://balsamiq.com/ 52#engageug
  53. 53. • Business Consultant • Silverside • @FemkeGoedhart • http://femkegoedhart.com Tim Clark Femke Goedhart 53#engageug • Director of Prof. Services • Teamstudio • @TimsterC • http://tc-soft.com

×