Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

20 683 vues

Publié le

Get projects right with detailed requirements gathering.

  • Soyez le premier à commenter

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