Your SlideShare is downloading. ×
0
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
The Requirements Process Workshop Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Requirements Process Workshop Presentation

494

Published on

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

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Requirements Process PMI Tools & Techniques Forum Ivars K. Lenss, PMP
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Requirements Planning PMI Tools & Techniques Forum January 14, 2009
  • 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. 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. 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. 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. Requirements Elicitation PMI Tools & Techniques Forum January 14, 2009
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Requirements Modeling PMI Tools & Techniques Forum January 14, 2009
  • 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. 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. 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. 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. 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. 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

×