The Requirements Process Workshop Presentation

617
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
617
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Requirements Process Workshop Presentation

  1. 1. The Requirements Process PMI Tools & Techniques Forum Ivars K. Lenss, PMP
  2. 2. Agenda  Introductions  Definition of Requirements  Requirements Planning  Requirements Elicitation  Process Modeling  Q&A Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  3. 3. What Is a Requirement? (1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2) Source: IEEE Std 610.12-1990 Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  4. 4. How Requirements Work Requirements are not solutions Design translates requirements into solutions Many stakeholders mix requirements with their proposed solutions Requirements gathering is discovering the essence of the system Essence is the business reason of the work - what the work would be if there was no project Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  5. 5. Benefits of Good Requirements  Common understanding  Collaborative relationships  Commitment of team members  Products support stakeholder needs Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  6. 6. Correcting Requirement Defects Stage of Discovery Relative Cost to Correct Requirements development 1X Design 2-3X Construction 5-10X System or acceptance test 8-20X Operation 68-110X Source: Wiegers More About software requirements Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  7. 7. Cost of Requirements Defects  Requirements defects contribute to one third of total delivered defects  Fixing requirements errors consumes 70-80% of project rework costs  Requirements defects consume 28-42% of total software development costs Source: Wiegers Software Requirements Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  8. 8. Requirement Sources  Business  Implementation  Stakeholder  Maintainability  User  Regulatory  Quality of Service  Legal  Performance  Safety  Security  Request for Proposal  External Systems  Derived Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  9. 9. Raw Requirements A raw requirement is an environmental or customer requirement that has not been analyzed and formulated as a well-formed requirement. (IEEE Std 1233, 1998 Edition) Higher-level statements of the business goals, objectives, and success factors Often expressed in initiating documents Often vague and subjectively interpreted Can be intermingled with ideas and suggestions for potential designs Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  10. 10. Example  Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”  What are the status messages?  How are they provided to the user?  If displayed, how long are they displayed?  What is the acceptable timing interval? Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  11. 11. Business Events  A system responds to things that happen externally – these are business events  Each event has a preplanned response – This response is a business use case  A requirement associates a business event with a business use case Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  12. 12. Well-Formed Requirements A well-formed requirement is a statement of system functionality (a capability) that can be validated, and that must be possessed by a system to solve a customer objective, and is qualified by measurable conditions and bounded by constraints. (IEEE Std 1233, 1998 Edition)  Abstract: Independent of its implementation  Unambiguous: Interpreted in only one way  Traceable: Associated with source  Validateable: Fit criteria Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  13. 13. Example Raw Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”  The traffic monitor shall display status messages in a designated area of the user interface  The messages shall be updated every 60 seconds, plus or minus five seconds  Messages shall remain visible continuously Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  14. 14. Requirements Classification  Functional Requirements - Things the product must do - Action verbs – calculate, produce, inspect, publish  Nonfunctional Requirements - Qualities the product must have - Look and feel, performance, security, regulatory  Constraints - Boundaries and limits on the solution. - Glossary and naming conventions - Training, knowledge transfer Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  15. 15. Examples  Functional  The rail system shall move people from San Francisco to Los Angeles  Nonfunctional  The rail system shall operate at an optimal cruise speed of 100 miles per hour  Constraint  The rail system shall operate at a maximum speed of 130 miles per hour Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  16. 16. Requirement Attributes• Assigned to each well-formed requirement For example: <identification> = 4.3.2 <priority> = high <criticality> = low <feasibility> = high <risk> = medium <source> = customer <class> = nonfunctional <type> = performance
  17. 17. Requirements Planning PMI Tools & Techniques Forum January 14, 2009
  18. 18. Requirements Planning  Identify stakeholders and key project team members  Identify and communicate key roles/responsibilities to people involved in requirements gathering  [R]esponsible (does the work)  [A]ccountable (the decision maker-only one person)  [C]onsulted (consulted prior to the work, provides input)  [I]nformed (on a need to know basis)  Identify project assumptions  Determine tools and techniques to gather and communicate requirements Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  19. 19. Planning Considerations  Number of stakeholders  Locations of stakeholders  Sources of domain knowledge  Organizational culture  Documentation requirements Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  20. 20. Obstacles  Multiple, conflicting needs from stakeholders  Stakeholder availability  Stakeholder knowledge  Lack of involvement of the right people  Delivery dates mandated without prioritized requirements  Scope creep  Analysis paralysis Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  21. 21. Requirements Life Cycle Target Stakeholder Environment Goals, Needs, PR O and Objectives D U C T REQUIREMENTS RELEASE Process MODELS Requirements FEEDBACK Product Modeling Definition Release TI TS A N N IC E O IF EM FE B DB MO U A EC UIR E IL C DE D K SP EQ LS R B N K G C ED SI A T FE E C D U D O PR Product Product Build Design DESIGN SPECIFICATION Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP Source: Robertson & Robertson, Mastering the Requirements Process
  22. 22. Requirements Elicitation PMI Tools & Techniques Forum January 14, 2009
  23. 23. Requirements Elicitation  Used to build analytical models  Exposes missing, incomplete, or incorrect requirements  Determines if additional iterations required Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  24. 24. REQUIREMENTS WORKSHOPS INTERVIEWS BRAINSTORMING/ FOCUS GROUPS SURVEY/ QUESTIONNAIRE REQUIREMENTS PROTOTYPING OBSERVATION/ SHADOWING DOCUMENT ANALYSIS REVERSE INTERFACE ENGINEERING ANALYSIS Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  25. 25. Interviews  Solicit stakeholder involvement, authority, impact  Most common elicitation technique  Structured interview, pre-defined questions  Unstructured interview, no pre-defined questions  Encourages participation and establishes rapport with the stakeholder  Results subject to interviewer’s interpretation  Not a means of reaching consensus Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  26. 26. Requirements Workshops  Structured way to capture requirements (scope, define, discover, prioritize, and reach closure)  Also referred to as JAD, Joint Application Design  Effective way to elicit requirements quickly  Feedback is immediate  Stakeholders availability affects scheduling  Too many participants can slow down the process  Too few participants can overlook requirements Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  27. 27. Brainstorming/Focus Group  Focuses on a topic or problem area  Share new ideas without criticism or evaluation  Create a condensed list of ideas  Homogeneous—individuals with similar characteristics  Differing perspectives might not be shared  Heterogeneous—individuals with diverse backgrounds  Individuals may self-censor if not comfortable with others’ background Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  28. 28. Survey / Questionnaire  Quick and relatively inexpensive  Does not usually require significant time  Efficient when stakeholders are not co-located  Closed-ended questions:  Used when issues are known, responses are not  Effective in obtaining quantitative data  Open-ended questions:  Effective in obtaining insights and opinions  Difficult to quantify and summarize Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  29. 29. Prototyping  Creates “mock ups” of screen or report layouts  Lets stakeholders “see” the system’s interface  Horizontal prototype  Models a shallow and wide view of the system (breadth)  Vertical prototype  Models a deep and narrow view of the system (depth)  Can take considerable time  Can get bogged down by the “hows” rather than “whats”  May lead to unrealistic expectations of performance, reliability, usability Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  30. 30. Document Analysis  Used to gather details of the “As Is” environment  Leverage existing materials to discover and/or confirm requirements  Applied in situations where  the subject matter experts for the existing systems are no longer with the organization  or are not going to be available throughout the duration of the requirements elicitation process  Documentation may not be up-to-date  Can be tedious and time-consuming Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  31. 31. Interface Analysis  Used to identify shared interface requirements  Interfaces types include:  User interfaces  System-to-system interfaces  Interfaces to and from external hardware devices  Reveals inputs, outputs, functionality  Important to look across all interfaces  Promotes successful interoperability  Does not reveal business processes Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  32. 32. Observation / Shadowing  Study people performing their jobs  Assess an SME’s work environment  Sometimes called "job shadowing” or “following people around”  Documents details about a current process  Could be time-consuming  May be disruptive Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  33. 33. Reverse Engineering  Existing system has little or outdated documentation  Helps in understanding what a system actually does  Black Box:  Studied without examining its internal structure  White Box:  Inner workings of the system/product are studied  Expensive and time-consuming  Can be restricted by copyright laws  Existing tools have limited capabilities and require training to use Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  34. 34. Requirements Modeling PMI Tools & Techniques Forum January 14, 2009
  35. 35. Analytical Models  Express different views of requirements  Provide perspectives and focus  Achieve specific levels of detail  Facilitate communication  Models can be text, diagrams, or both  Behavior models (processes, tasks, sequences)  Structural models (parts and relationships)  Dynamic models (how things change over time)  Control models (decisions and policies) Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  36. 36. Model Views  Control Models (guidelines, standards)  Business Policies  Business Rules  Structural Models (parts and relationships)  Domain Models  Glossary  Dynamic Models (changes over time)  Event Table Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  37. 37. Model Views  Behavioral Models (processes, tasks, sequences)  Relationship Map  Context Diagram  Stakeholder Classes  Actor Map  Actor Table  Prototype  Process Map  Use Cases  Scenarios Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  38. 38. Writing Requirements  Written for stakeholders  Written for designers  Written using business language  Associated with a fit criterion  Designers can build what the client wants Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  39. 39. Establishing Metrics  Project Metrics – measurements associated with the project  Cost, effort, schedule, risk, resources, etc.  Product Metrics – measurements associated with the product  Defects, performance, size, etc. Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  40. 40. Further Reading 1. Wiegers, Karl E., Software Requirements , 2nd ed., Microsoft Press, 2003 2. Wiegers Karl, E., More about Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, 2006 3. Robertson & Robertson, Mastering the Requirements Process, 2nd ed., Addison-Wesley, 2006 4. Sward, Measuring the Business Value of Information Technology, Intel Press, 2006 5. Bridgeland, Zahavi, Business Modeling, A Practical Guide to Realizing Business Value, Morgan Kaufman, 2009 6. IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications Tools & Techniques Forum January 14, 2009 Ivars@Lenss.usIvars K. Lenss, PMP
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×