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.

Project Requirements, What Are They And How Do You Know You


Published on

Get projects right with detailed requirements gathering.

  • Be the first to comment

Project Requirements, What Are They And How Do You Know You

  1. 1. Project Requirements What are they? How do you know you got’em all?
  2. 2. Agenda <ul><li>Groundwork </li></ul><ul><li>Why do this thing? </li></ul><ul><li>Nuts & Bolts </li></ul><ul><li>Definition </li></ul><ul><li>Analysis </li></ul><ul><li>Punchline </li></ul><ul><li>I&E </li></ul>
  3. 3. Who said that? “ If you don't know how well you are doing, then you know you are not doing very well” Anonymous “ Good stuff ain’t cheap, and cheap stuff ain’t good” Hubert Green
  4. 4. Where do requirements come from? <ul><li>Requirements come from needs </li></ul><ul><ul><li>Needs emergence </li></ul></ul><ul><ul><li>Needs recognition </li></ul></ul><ul><ul><li>Needs articulation </li></ul></ul>
  5. 5. Challenges with needs <ul><li>Dealing with ambiguity </li></ul><ul><ul><li>Needs change </li></ul></ul><ul><ul><li>Customer don’t know what they want (or they know what they want when they see it) </li></ul></ul><ul><li>Possibilities present themselves as the deliverables become tangible </li></ul>
  6. 6. What are requirements? Requirements are a negotiated set of measurable customer wants and needs.
  7. 7. When do you gather requirements? Initiation Executing Controlling Planning Closing Right here
  8. 8. Major requirement types <ul><li>Functional </li></ul><ul><li>Ordinary language </li></ul><ul><li>Non-technical </li></ul><ul><li>Understandable by customer </li></ul><ul><li>Customer developed </li></ul><ul><li>Technical </li></ul><ul><li>Deliverable features </li></ul><ul><li>Dimensions </li></ul><ul><li>Performance specs </li></ul><ul><li>Provide guidance to technical staff </li></ul>
  9. 9. Why are they important? <ul><li>Tangible embodiment of customer needs </li></ul><ul><ul><li>Serve as basis for project plan </li></ul></ul><ul><ul><li>If requirements are flawed, planning will be inadequate </li></ul></ul><ul><li>Define obligations to the customer </li></ul><ul><ul><li>Output of requirements are articulated in the SOW </li></ul></ul><ul><ul><li>Compliance is determined by fulfilling the requirements </li></ul></ul>
  10. 10. Worth a thousand words ($)… Source of errors Cost to correct in $1,000
  11. 11. Intermission <ul><li>What experience has anyone had with turning functional specs into technical specs? </li></ul>
  12. 12. Requirement definition process Gather Review Document Sign-off
  13. 13. Requirement Definition Participants <ul><li>Project manager </li></ul><ul><li>Customer </li></ul><ul><ul><li>End users </li></ul></ul><ul><ul><li>Sponsor </li></ul></ul><ul><li>Project team members </li></ul><ul><ul><li>Customer and vendor </li></ul></ul>
  14. 14. Good Requirements <ul><li>Complete and accurate </li></ul><ul><li>Unambiguous </li></ul><ul><li>Verifiable </li></ul><ul><li>Testable </li></ul><ul><li>Sufficient for design </li></ul>
  15. 15. Guidelines <ul><li>State explicitly and get sign-off </li></ul><ul><li>Be realistic, If it can be misinterpreted it will be misinterpreted </li></ul><ul><li>There will be changes, bend but don’t break </li></ul><ul><li>Use pictures </li></ul><ul><li>Monitor change </li></ul>
  16. 16. Where do they come from? <ul><li>Interviews </li></ul><ul><ul><li>Customers </li></ul></ul><ul><ul><li>End users </li></ul></ul><ul><ul><li>Use open ended and specific questions </li></ul></ul><ul><ul><li>Tape recorder </li></ul></ul><ul><li>Observation </li></ul><ul><li>Teams of two </li></ul><ul><li>Prototyping </li></ul>
  17. 17. Pitfalls of prototyping <ul><li>Advantages </li></ul><ul><li>Used when requirements are vague </li></ul><ul><li>Early feedback possible </li></ul><ul><li>Can provide go/no-go </li></ul><ul><li>Disadvantages </li></ul><ul><li>Prototype mistaken for production </li></ul><ul><li>Not generally scoped </li></ul>
  18. 18. Requirement analysis process Assess Prioritize Evaluate Tie to biz objective Unclear reqs. Immeasurable Intangible
  19. 19. Trade offs <ul><li>Nothing left to chance </li></ul><ul><li>Restricted creativity </li></ul><ul><li>Focus on minutiae </li></ul><ul><li>Costly rework </li></ul><ul><li>Excessive flexibility </li></ul><ul><li>Sloppy deliverables </li></ul><ul><li>Chaotic planning </li></ul><ul><li>Time/cost overruns </li></ul>
  20. 20. Document, Verify and Validate <ul><li>Document and present findings for review and approval </li></ul><ul><li>Refine based on feedback </li></ul><ul><li>Obtain consensus among customer and vendor </li></ul>
  21. 21. Punchline <ul><li>How do you know you got ‘em all? </li></ul><ul><li>When you have enough to design </li></ul><ul><li>They will change </li></ul><ul><ul><li>Have a change management process to compensate </li></ul></ul><ul><ul><li>That is another story… </li></ul></ul>
  22. 22. Prepare a project requirements document <ul><li>Project summary </li></ul><ul><li>Functional reqs. </li></ul><ul><li>Technical reqs. </li></ul><ul><li>Deliverables </li></ul><ul><li>Milestones </li></ul><ul><li>Risk </li></ul><ul><li>Assumptions </li></ul><ul><li>Constraints </li></ul><ul><li>Resource requirements </li></ul><ul><li>Acceptance criteria </li></ul>
  23. 23. Inquiry and Enlightenment