Downloaded 12 times
![Do the Right Things:
Practical Guidance for Adapting
Your Requirements Practices
Copyright © 2012 EBG Consulting, Inc.
[CAI Webinar | 24 April 2012]
Ellen Gottesdiener
www.ebgconsulting.com
© EBG Consulting, 2012 7](https://image.slidesharecdn.com/webinar-gottesdiener-04242012-121217154931-phpapp02/75/Do-the-Right-Things-7-2048.jpg)
Uploaded byComputer Aid, Inc
Do the Right Things
The document is a presentation by Ellen Gottesdiener on adapting requirements practices. It discusses how requirements practices need to be adapted based on factors like team skills, domain knowledge, project type, and product complexity. It provides examples of practices that could be formal and documentation-heavy for some projects, while informal for others. The presentation emphasizes the importance of customer involvement, balancing completeness with purpose, and adapting practices based on the project context.
Do the Right Things
- 1. Do the RightThings: Practical Guidance for Adapting Your Requirements Practices © EBG Consulting, 2012 24 April 2012 11:00 – 12:30 EST © EBG Consulting, 2012 1
- 2. Ellen Gottesdiener President & Founder EBG Consulting ellen@ebgconsulting.com @ellengott (twitter) Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) Michael_milutis@compaid.com © EBG Consulting, 2012 2
- 3. EBG Consulting helpsyou deliver high-value products your customers want and need. EBG is a leader in enabling productive product partnerships thorough its expertise in requirements, business analysis, collaboration, agile planning and product management. © EBG Consulting, 2012 3
- 4. CAI Achieves ITOperational Excellence © EBG Consulting, 2012 4
- 5. PDU CREDITS FOR THIS WEBINAR The Project Management Institute has accredited this webinar with PDUs © EBG Consulting, 2012 5
- 6. NOW AVAILABLE! ONLINE WEBINAR RECORDINGS ANYTIME ACCESS! WWW. ITMPI.ORG / LIBRARY 7 Day Free Access For All Recordings www.twitter.com/ ITMPI © EBG Consulting, 2012 6
- 7. Do the RightThings: Practical Guidance for Adapting Your Requirements Practices Copyright © 2012 EBG Consulting, Inc. [CAI Webinar | 24 April 2012] Ellen Gottesdiener www.ebgconsulting.com © EBG Consulting, 2012 7
- 8. Ellen Gottesdiener Founder &Principal Consultant, EBG Consulting Facilitator, trainer, mentor, agile coach, conference advisor Years of varied project and product experience Certified Professional Facilitator, Certified Scrum Master Expert Reviewer, contributor to IIBA BABOK® (Business Analysis Body of Knowledge) and contributor to in-progress Agile BABOK® Author: articles, books, blog New book! (summer release) w/ Mary Gorman web: www.ebgconsulting.com blog: www.ebgconsulting.com/blog twitter.com/ellengott eNewsletter: Success with Requirements free - sign up at www.ebgconsulting.com © EBG Consulting, 2012 8
- 9. requirements practices intro & adaptations q & a adaptation factors summary © EBG Consulting, 2011 9
- 10. black white © EBGConsulting, 2012 10
- 11. © EBG Consulting,2012 11
- 12. adapt or ______ ©EBG Consulting, 2011 12
- 13. good practices © EBGConsulting, 2012 13
- 14. good practices © EBGConsulting, 2012 14
- 15. gradient of practices © EBG Consulting, 2012 15
- 16. adaption factors © EBG Consulting, 2011 16
- 17. E n gin e e r in g T e a m J e ll P r a c t ic e s Team D o m a in F a cto rs K n o w le d g e O v e r s ig h t P r o x im it y © EBG Consulting, 2012 17
- 18. S iz e C o m p le x it y P ro je c t U sage Type P ro d u ct F a c to rs Im p o rta n ce o f Q u a lit y E c o n o m ic A t t r ib u t e s © EBG Consulting, 2012 18
- 19. practices © EBG Consulting,2011 19
- 20. requirements engineering © EBG Consulting, 2012 20
- 21. set the stage ©EBG Consulting, 2012 21
- 22.
- 23. risk management © EBGConsulting, 2012 23
- 24. value management © EBGConsulting, 2012 24
- 25. C R AC K customer © EBG Consulting, 2012 25
- 26. vision © EBG Consulting,2012 26
- 27.
- 28. shared understanding © EBGConsulting, 2012 28
- 29. glossary © EBG Consulting,2012 29
- 30. © EBG Consulting,2012 30
- 31. multiple formal techniques ©EBG Consulting, 2012 31
- 32. informal, ad hoc ©EBG Consulting, 2012 32
- 33. direct stakeholder involvement © EBG Consulting, 2012 33
- 34. © EBG Consulting,2012 34
- 35. rich analysis models, verification matrices, formal prioritization © EBG Consulting, 2012 35
- 36. lightweight analysis models, ATs, informal prioritization © EBG Consulting, 2012 36
- 37. front loaded targeted, informal © EBG Consulting, 2012 37
- 38. 7 product dimensions ©EBG Consulting, 2012 38
- 39. options © EBG Consulting,2012 39
- 40. assemble options © EBGConsulting, 2012 40
- 41. 7 Ds structuredconversation © EBG Consulting, 2012 41
- 42. multiple models, scenarios continual prioritization © EBG Consulting, 2012 42
- 43. © EBG Consulting,2012 43
- 44. formal specification document © EBG Consulting, 2012 44
- 45. low-fidelity documentation, tests © EBG Consulting, 2012 45
- 46. © EBG Consulting,2012 46
- 47. inspections, structured walkthrus © EBG Consulting, 2012 47
- 48. reqts– examples- tests Adapted from: Agile Alliance Functional Testing Tools Open Space Workshop 2007 © EBG Consulting, 2012 48
- 49. user acceptance tests, demos © EBG Consulting, 2012 49
- 50. reviews, prototypes © EBG Consulting, 2012 50
- 51. © EBG Consulting,2012 51
- 52. change control, trace matrices © EBG Consulting, 2012 52
- 53. refine the backlog(queue) © EBG Consulting, 2012 53
- 54. physically track requirements © EBG Consulting, 2012 54
- 55. product roadmap © EBGConsulting, 2012 55
- 56. summary: adapting requirements practices © EBG Consulting, 2011 56
- 57. customer involvement © EBG Consulting, 2012 57
- 58. purposeful (in)compleness © EBG Consulting, 2012 58
- 59. timing © EBG Consulting,2012 59
- 60.
- 61. requirements management © EBG Consulting, 2012 61
- 62. © EBG Consulting,2012 62
- 63. adapt green field enhancement package selection / config BI, DW © EBG Consulting, 2012 63
- 64. adapt © EBG Consulting,2012 64
- 65. adapting © EBG Consulting,2012 65
- 66. email ellen@ebgconsulting.com twitter ellengott about EBG www.ebgconsulting.com articles www.ebgconsulting.com/articles.php find: “Adapting Your Requirements Practices, Parts I and II” Stay tuned for Discover to Deliver © EBG Consulting, 2012 66
- 67. © EBG Consulting,2012 67
- 68. © EBG Consulting,2012 68
- 69. Questions? © EBG Consulting,2012 69
- 70. CAI Sponsors The IT Metrics & Productivity Institute: • Clearinghouse Repository of Best Practices: WWW.ITMPI.ORG • Weekly Educational Newsletter: WWW.ITMPI.ORG / SUBSCRIBE • Weekly Webinars Hosted by Industry Leaders: WWW.ITMPI.ORG / WEBINARS • ACCESS WEBINAR RECORDINGS ANYTIME AT WWW.ITMPI.ORG / LIBRARY • Follow Us on TWITTER at WWW.TWITTER.COM / ITMPI • Join Our Network on LINKED IN at WWW.ITMPI.ORG/ LINKEDIN • Follow Us on FACEBOOK at WWW.ITMPI.ORG/ FACEBOOK • Find Out About Our CONFERENCES at WWW.ITMPI.ORG/ EVENTS © EBG Consulting, 2012 70
- 71. Ellen Gottesdiener President & Founder EBG Consulting ellen@ebgconsulting.com @ellengott (twitter) Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) Michael_milutis@compaid.com © EBG Consulting, 2012 71
Editor's Notes
- #2 x
- #3 x
- #13 1-adapt or become irrelevant
- #14 Paul Ramsey – 8 June 2006 – inaugural mtg IIBA BABOK globally recognized standard for practice of business analysis. framework describes business analysis tasks that must be performed in order to understand how a solution will deliver value to the sponsoring organization.” global standard value of standard: save time, improve the quality of work AND easier to communicate with others using same standard
- #16 move along gradient as needed context – org, product
- #17 consider options
- #20 consider options
- #21 Requirements engineering refers to all the activities involved in discovering, detailing, testing, documenting and maintaining software requirements. It includes the activities involved in understanding the business needs and transforming those into requirements that are allocated to software. There two sets of activities: requirements development and requirements management. Requirement engineering involves both development and management of requirements. Development of requirements involves much human interaction, investigation and discovery. Models can be text, visual, or a combination of both. Models communicate the requirements needed. Requirements management establishes and maintains an infrastructure for requirements, which allows for change, and establishes practices that ensure that the right software is being developed (validation) and that it is being built correctly (verification). Managing requirements is more technical and mechanical, although some of the management activities, such as change control and re-prioritizing requirements, require direct and heavy customer interaction. Note : Requirements engineering in the software industry does not address the business requirements that are not allocated to software. Those need to be owned and managed by the business (see the “Business Change Document” template in your Appendix). New or changed software results in changes for people and processes. For example, operational timings, steps, business rules and roles often change as a result of software implementation. How those changes are communicated and documented, how and when users are trained, and how and when business results are measured must be the responsibility of the business customer. This is often ignored (or addressed too late) in software projects. It is an element, however, which will make or break the success of a project.
- #26 Collaborative representative Authorities Committed knowledgeable
- #28 shared understanding – what to deliver
- #29 shared understanding – what to deliver
- #30 key ‘tool’
- #34 communicate directly no surrogates, knowledgeable, decision maker
- #38 front loaded – e&a all upfront targeted – specific, limited scope, just enuf, JIT informal
- #45 BA produce, Dev & Test consume BRD, SRS
- #46 when closely communicate, limited scope tests become documentation caution - Vanguard – take agile reqs, doc in UC after delivery – template zombie
- #48 may be necessary – reg env, outsourcing dev & tsting
- #50 UAT def cond for accpeting prod BEFORE dev starts TESTABLE demo as soon as possible
- #53 formal CCB
- #54 BL cat of unfulfilled rqts discover credible need – add pull & prepare hen ready to del
- #66 practices and context
- #72 x