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.

How to write Great Requirements

1,453 views

Published on

A presentation on writing software requirements that does not prescribe to any established methodology but instead is based on the idea of knowing your audience and common sense.

Published in: Technology

How to write Great Requirements

  1. 1. UNDERSTANDING REQUIREMENTSGreg Thomas
  2. 2. RequirementsThe lifeblood of any software Endeavour.
  3. 3. 1 23 Determine your succesGreat requirements always lead to success while poor requirements ultimately lead to failure and confusion. Requirements that are “meh” can take last place for not having even tried.
  4. 4. Who gets the blame? When a product misses the mark? The people who wrote the requirements!
  5. 5. Why?Because requirements have the ability to; • Define the vision • Enunciate the goals and objectives of the system. • Outline the users and audience of the application. • Account for all dependencies and interactions In essence – they weave the story as to how a user traverses your application.
  6. 6. It must be the fault of the requirementsRight?
  7. 7. WRONG WRONG WRONG
  8. 8. WRONG!Bad requirements are everyone’s fault, not just the person who put pen to paper.
  9. 9. TEsters Whose responsible?
  10. 10. everyoneEveryone has a part to play in delivering the best product possible and that comes down to everyone helping on requirements.
  11. 11. Vision System Idea Innovation PLACEHOLDER Audience Installation Customer Fearless Upgrade Control PLACEHOLDER LEAD• Someone has to take the lead • But it’s always a group effort.
  12. 12. 1 28 46 5 7 3 So where do you start?
  13. 13. #1 - Know your audience Stakeholders don’t care about Product Backlog Items. They care about the story and the translation of their requests into an application. Know who you are writing for! idea
  14. 14. #2 - Tell a Story Don’t get sucked into metholodiges – what worked for one person might not work for you. When you start writing a requirement a certain way “just becase”, you’ve already lost your way.
  15. 15. • What must exist in your world for your requirements to work? • Define the Pre and Post Conditions 2 1 4 3 #3 - Outline Dependencies
  16. 16. #4 - SAndbox What world does your requirement operate in? Keep it there, don’t jump all over the place, stay focused.
  17. 17. #5 - Scenario AnalysisRun through the happy and edge paths, define them, why do they exist, who do they serve, is it for your audience?
  18. 18. #6 - Common Sense If it doesn’t fit, if it seems out of place, don’t put it in there. If you need more information, add it in!
  19. 19. Who benefits from all these? Role Audience Story Dependencies Sandbox Scenarios Common Sense Developer X X X X X X Tester X X X X X X Product Owner X X X X X X Stakehold er X X X X X X Product Manager X X X X X X X X X X X X
  20. 20. BE AWAREDon’t get pulled into writing a requirement in a specific way because the methodology “du jour” says you have to OR ELSE!
  21. 21. Don’t believe me? Then you’ve already forgotten Rule #6!

×