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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Needs emergence – There is some type of issue or problem that arises, pick your poison. Our work force is not flexible We cannot communicate in real-time Needs recognition A project emerges, maybe supported by market survey Executive support Needs articulation This is where the documentation begins Generally on the customer’s side
  • Challenges from the customer’s side
  • Requirements Define what the deliverable will look like and what it will do.
  • Association of Computing Machinery ’84 ATT bell labs estimates. These are relative numbers, but we can see the relationship between the catching errors early and the cost to correct errors later in a project.
  • Challenges noted, how did the project fare compared to others?
  • Bad choice, sometimes needed. Do we get paid for this effort?
  • Two extremes of project planning
  • 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