Neumont Presentation to Roles Class - 050108

1,786 views

Published on

This is a presentation I gave to the Roles class at Neumont University on May 1, 2008

Published in: Business, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,786
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Neumont Presentation to Roles Class - 050108

    1. 1. iRise Presentation for Neumont University May 1, 2008
    2. 2. A rigorous 237½ step process for the systemic discovery and definition of non-functional requirements for safety-intensive systems based on statistical methods and empirical observation Neumont University
    3. 3. A rigorous 237½ step process for the systemic discovery and definition of non-functional requirements for safety-intensive systems based on statistical methods and empirical observation Neumont University
    4. 4. Why being a BA is Fun *and* Important… Business Analysis for Fun and Profit Neumont University
    5. 5. Developers are being off-shored, be a BA… Business Analysis for Fun and Profit Neumont University
    6. 6. Business Analysis, Requirements and Simulation Business Analysis for Fun and Profit Neumont University
    7. 7. The skills you need to displace stodgy old BAs already in the workforce… Business Analysis for Fun and Profit Neumont University
    8. 8. Be a BA Business Analysis for Fun and Profit Neumont University
    9. 9. Tom Humbarger Senior Strategic Projects Manager [ thumbarger @irise.com ]
    10. 10. Introduction <ul><li>Why do we need Business Analysts? </li></ul><ul><li>What do they do? </li></ul><ul><li>Frameworks, processes and taxonomies </li></ul><ul><li>Simulation </li></ul>
    11. 11. Objectives <ul><li>Provide you a glimpse into the world of a BA </li></ul><ul><li>Introduce ideas that might lead you down some relevant personal research paths </li></ul><ul><li>Introduce the concept of simulation as an enabler for application definition </li></ul><ul><li>Whet your appetite… </li></ul>
    12. 12. <ul><li>How well you communicate is determined not by how well you say things but by how well you are understood. </li></ul><ul><li>Andrew S. Grove </li></ul><ul><li>Chairman, Intel (’97 – ‘05) </li></ul>
    13. 13. Different interpretations Marketing Sales IT Finance Manufacturing Engineering
    14. 14. What the customer needs
    15. 15. Defects cause challenges Requirements 56% Code 7% Other 10% Design 27% - This data from James Martin Over 50% of software defects are attributed to requirement errors
    16. 16. Defects cause rework Code 1% Other 4% Design 13% Requirements 82% - This data from Dean Leffingwell Over 80% of rework effort is spent on requirements related defects
    17. 17. Requirements Management Impact - This data from I. Hooks 0 5 10 15 20 25 200 180 160 140 120 100 80 60 40 20 0 Percentage of Cost Overrun Requirements Process Costs as Percentage of Total Project Cost 0- 5% on Requirements Process Results in 80-200% Overrun 8-14% on Requirements Process Results in 0- 60% Overrun Value of Investment in Requirements Process Development Project
    18. 18. What did Archimedes say? - This data from Boehm: Software Engineering Economics Requirements Analysis & Design Coding Development Testing Acceptance Testing Product Quality Production
    19. 19. The Quality Lever - This data from Boehm: Software Engineering Economics Requirements Analysis & Design Coding Development Testing Acceptance Testing Product Quality Production 40-100x 30-70x 15-40x 10x 3-6x 1x
    20. 20. <ul><li>Who is responsible for those requirements? </li></ul>
    21. 21. The Business Analysts
    22. 22. The User Experience Professionals
    23. 23. The Product Managers
    24. 24. The “Business Designers?”
    25. 25. What is a Business Analyst or BA? <ul><li>It’s hard to say… </li></ul><ul><li>BA = Business Analysis </li></ul><ul><li>UX = Usability Experience </li></ul><ul><li>IA = Information Architecture </li></ul><ul><li>ID = Interaction Design </li></ul><ul><li>SA = Systems Analysis </li></ul><ul><li>WA = Workflow Architecture </li></ul><ul><li>PM = Product Management or Project Manager </li></ul><ul><li>DA = Data Analysis </li></ul><ul><li>PA = Process Analysis </li></ul><ul><li>QA = Quality Analysis </li></ul>Note – These are disciplines, not roles
    26. 26. What does a business analyst do? <ul><li>Analyze & solve problems </li></ul><ul><li>Understand the business </li></ul><ul><li>Communicate effectively (write & speak) </li></ul><ul><li>Manage client relationships </li></ul><ul><li>Facilitate discussions </li></ul><ul><li>Negotiate & build consensus </li></ul><ul><li>Model data & processes </li></ul><ul><li>Plan & manage activities </li></ul><ul><li>Facilitate & develop business strategy </li></ul><ul><li>Understand & manage organizational change </li></ul>
    27. 27. What Roles Does A BA Play? <ul><li>Analyst / Problem Solver </li></ul><ul><li>Facilitator </li></ul><ul><li>Negotiator </li></ul><ul><li>Artist / Architect </li></ul><ul><li>Planner </li></ul><ul><li>Communicator </li></ul><ul><li>Diplomat </li></ul><ul><li>Expert / Consultant </li></ul><ul><li>Strategist </li></ul><ul><li>Revolutionary </li></ul>
    28. 28. WYSIWYG
    29. 29. WYSIWIS
    30. 30. DWIM
    31. 31. Business
    32. 32. IT
    33. 33. Business IT
    34. 34. IT
    35. 35. Business IT
    36. 36. Grokking
    37. 37. Can you grok it? <ul><li>grok /, /grohk/ 1. To understand, usually in a global sense. Connotes intimate and exhaustive knowledge. </li></ul>(From the novel &quot;Stranger in a Strange Land&quot;, by Robert A. Heinlein, where it is a Martian word meaning literally &quot;to drink&quot; and metaphorically &quot;to be one with&quot;)
    38. 38. Grokking Not a whole lot of grokking going on…
    39. 39. What causes this lack of grokking? Ambiguity Uncertainty Rap music Creationism (aka BUFD) Timelines Tooling/Support Culture Creeping elegance Banana problem Misunderstanding Unclear Expectations “ That’s how it’s always been”
    40. 40. Requirements
    41. 41. <ul><li>What are requirements made of? </li></ul>
    42. 42. <ul><li>Words… </li></ul>
    43. 43. Words are little bombs… <ul><li>“ Words are little bombs, and they have a lot of energy inside them.&quot; </li></ul><ul><li>&quot;I have this theory about words. There's a thousand ways to say `Pass the salt.’ It could mean, you know, `Can I have some salt?'; or it could mean, `I love you.'; It could mean `I'm very annoyed with you'; really, the list could go on and on.” </li></ul><ul><li>Christopher Walken </li></ul>
    44. 44. <ul><li>Where do words or requirements come from? </li></ul>
    45. 45. <ul><li>“ Gathering” sounds easy, doesn’t it? </li></ul>
    46. 46. Here’s a pretty orange requirement. I’ll take it back to The office. Tim Lister - Keynote Agile Development Conference 2004
    47. 47. I think I may have a requirements management problem…
    48. 49. <ul><li>In reality, it means asking, digging, wrenching, pulling, cajoling, extracting, wringing, bargaining, negotiating, begging, pleading… </li></ul>
    49. 50. <ul><li>… beseeching, demanding, imploring, entreating, bartering, dealing, probing, querying, mining, sweet-talking, requesting, inquiring… </li></ul>
    50. 51. <ul><li>… searching, questioning, coaxing, appealing, enticing, arm-twisting, trading, haggling, petitioning, wheedling… </li></ul>
    51. 52. <ul><li>… (whew!)... </li></ul>
    52. 53. Or the alternative…budgeting for goons
    53. 54. <ul><li>… from people who, in the end, don’t really know what they need… </li></ul>
    54. 55. <ul><li>… until they see it. </li></ul>
    55. 56. … until they see it… That’s not *exactly* what I had in mind…
    56. 57. IKIWISI
    57. 58. Or maybe…it’s not until they try it…
    58. 59. IKIWITI
    59. 60. <ul><li>The sooner the users try it the better… </li></ul>
    60. 61. <ul><li>The better the “try,” the more useful the feedback… </li></ul>
    61. 62. Requirements Processes
    62. 63. Wiegers’ Requirements Taxonomy ( www.processimpact.com )
    63. 64. Volere Requirements Process ( www.volere.co.uk )
    64. 65. BA BOK Knowledge Areas ( www.theiiba.org ) Requirements Planning & Management Requirements Gathering Requirements Implementation Requirements Analysis & Documentation Requirements Communications Enterprise Analysis Fundamentals
    65. 66. iRise G-A-V Framework ( www.irise.com )
    66. 67. iRise G-A-V Framework - Gathering
    67. 68. Requirements Documentation
    68. 69. IEEE Standard-based sample structure <ul><li>1. Introduction </li></ul><ul><li>1.1 Purpose </li></ul><ul><li>1.2 Document Conventions </li></ul><ul><li>1.3 Intended Audience and Reading Suggestions </li></ul><ul><li>1.4 Product Scope </li></ul><ul><li>1.5 References </li></ul><ul><li>2. Overall Description </li></ul><ul><li>2.1 Product Perspective </li></ul><ul><li>2.2 Product Functions </li></ul><ul><li>2.3 User Classes and Characteristics </li></ul><ul><li>2.4 Operating Environment </li></ul><ul><li>2.5 Design & Implementation Constraints </li></ul><ul><li>2.6 User Documentation </li></ul><ul><li>2.7 Assumptions and Dependencies </li></ul><ul><li>3. External Interface Requirements </li></ul><ul><li>3.1 User Interfaces </li></ul><ul><li>3.2 Hardware Interfaces </li></ul><ul><li>3.3 Software Interfaces </li></ul><ul><li>3.4 Communications Interfaces </li></ul>4. System Features 4.1 System Feature 1 4.1.1 Description and Priority 4.1.2 Stimulus/Response Sequences 4.1.3 Functional Requirements 4.x System Feature x 5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 6. Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List Copyright  Process Impact. Karl Wiegers. 2001. All rights reserved. In Search of Excellent Requirements0 02/2001 1- Software Requirements Specification
    69. 70. Volere-based sample structure <ul><li>PROJECT DRIVERS </li></ul><ul><li>1. The Purpose of the Project </li></ul><ul><li>2. Client, Customer and other Stakeholders </li></ul><ul><li>3. Users of the Product </li></ul><ul><li>PROJECT CONSTRAINTS </li></ul><ul><li>4. Mandated Constraints </li></ul><ul><li>5. Naming Conventions and Definitions </li></ul><ul><li>6. Relevant Facts and Assumptions </li></ul><ul><li>FUNCTIONAL REQUIREMENTS </li></ul><ul><li>7. The Scope of the Work </li></ul><ul><li>8. The Scope of the Product </li></ul><ul><li>9. Functional and Data Requirements </li></ul><ul><li>NON-FUNCTIONAL REQUIREMENTS </li></ul><ul><li>10. Look and Feel Requirements </li></ul><ul><li>11. Usability and Humanity Requirements </li></ul><ul><li>12. Performance Requirements </li></ul><ul><li>13. Operational Requirements </li></ul><ul><li>14. Maintainability and Support Requirements </li></ul><ul><li>15. Security Requirements </li></ul><ul><li>16. Cultural and Political Requirements </li></ul><ul><li>17. Legal Requirements </li></ul><ul><li>PROJECT ISSUES </li></ul><ul><li>18. Open Issues </li></ul><ul><li>19. Off-the-Shelf Solutions </li></ul><ul><li>20. New Problems </li></ul><ul><li>21. Tasks </li></ul><ul><li>22. Cutover </li></ul><ul><li>23. Risks </li></ul><ul><li>24. Costs </li></ul><ul><li>25. User Documentation and Training </li></ul><ul><li>26. Waiting Room </li></ul><ul><li>27. Ideas for Solutions </li></ul>- Suzanne and James Robertson
    70. 71. Process Impact - sample structure <ul><li>Table of Contents </li></ul><ul><li>Revision History </li></ul><ul><li>1. Introduction </li></ul><ul><li>1.1 Purpose </li></ul><ul><li>1.2 Project Scope and Product Features </li></ul><ul><li>1.3 References </li></ul><ul><li>2. Overall Description </li></ul><ul><li>2.1 Product Perspective </li></ul><ul><li>2.2 User Classes and Characteristics </li></ul><ul><li>2.3 Operating Environment </li></ul><ul><li>2.4 Design and Implementation Constraints </li></ul><ul><li>2.5 User Documentation </li></ul><ul><li>2.6 Assumptions and Dependencies </li></ul><ul><li>3. System Features </li></ul><ul><li>3.1 Order Meals </li></ul><ul><li>3.2 Create, View, Modify, and Delete Meal Subscriptions </li></ul><ul><li>3.3 Register for Meal Payment Options </li></ul><ul><li>3.4 Request Meal Delivery </li></ul><ul><li>3.5 Create, View, Modify, and Delete Cafeteria Menus </li></ul><ul><li>4. External Interface Requirements </li></ul><ul><li>4.1 User Interfaces </li></ul><ul><li>4.2 Hardware Interfaces </li></ul><ul><li>4.3 Software Interfaces </li></ul><ul><li>4.4 Communications Interfaces </li></ul><ul><li>5. Other Nonfunctional Requirements </li></ul><ul><li>5.1 Performance Requirements </li></ul><ul><li>5.2 Safety Requirements </li></ul><ul><li>5.3 Security Requirements </li></ul><ul><li>5.4 Software Quality Attributes </li></ul><ul><li>Appendix A: Data Dictionary and Data Model </li></ul><ul><li>Appendix B: Analysis Models </li></ul>- Karl Wiegers
    71. 73. Words… <ul><li>Are a cumbersome way to communicate </li></ul><ul><li>Lack precision </li></ul><ul><li>Require mental translation </li></ul>
    72. 74. Density doesn’t equal fidelity.
    73. 75. Comprehension can’t be calculated in words per square inch.
    74. 76. Understanding isn’t measured in lbs. per feature.
    75. 77. <ul><li>Because it’s hard to “try” a document… </li></ul>
    76. 78. Have we automated the right things? <ul><li>Specification generation </li></ul><ul><li>Analytics and drill-down reporting </li></ul><ul><li>Traceability and impact analysis </li></ul><ul><li>Requirement meta-data and auditing </li></ul><ul><li>Use Cases, UML… </li></ul><ul><li>State Transition Diagrams </li></ul><ul><li>Specification languages (LOTOS, Z, Planguage…) </li></ul><ul><li>Etc… </li></ul>
    77. 79. Are we thinking outside the box?
    78. 80. Visualize
    79. 81. Sharing a mental model isn’t easy… unless you make it easy for people to see the what they mean.
    80. 82. What industries use visualization?
    81. 83. Architects visualize success
    82. 84. Boeing visualizes success
    83. 85. GM visualizes success
    84. 86. What is visualization?
    85. 87. Visualizations are just models of reality
    86. 88. <ul><li>What if… </li></ul>
    87. 89. <ul><li>… non-developers could create interactive simulations of the software product before coding? Every time. </li></ul>
    88. 90. <ul><li>And they could create prototypes with both the speed and agility (roughly) of paper prototyping… </li></ul>
    89. 91. <ul><li>… and imbue them with the richness possible in a coded prototype? </li></ul>
    90. 92. So, why not visualize software?
    91. 93. Viola - CAD for software!
    92. 94. <ul><li>How could we use visualization to facilitate the evaluation and feedback loops necessary for a good design process? </li></ul>
    93. 95. <ul><li>Could we use visualization to generate excitement with both the users and the executive sponsors of a project? </li></ul>
    94. 96. <ul><li>Could we use visualization to ensure we’re building the right software? </li></ul>
    95. 97. Are we outside the box yet?
    96. 98. <ul><li>“ Visualization is now a proven strategy across many industries that enables business and IT stakeholders to more effectively communicate their needs and give everyone involved the ability to &quot;test drive&quot; and fully experience applications prior to development. “ </li></ul>iRise definition of visualization
    97. 99. iRise Vision “ By 2020 all business software will be visualized prior to development, the same way that visualization is a common practice in the design of every car, airplane and semiconductor today “
    98. 100. Kinesthetic
    99. 101. Variable Fidelity
    100. 102. Immersive
    101. 103. Compelling
    102. 104. Very low fidelity…
    103. 105. Low fidelity
    104. 106. Medium fidelity Drug Dose Drug ABC Drug DEF 100 mg 200 mg Route Freq Indication Last Dose Comment Current Medication List ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ Add Delete Modify Save No Change Cancel Consistent function with other EMR design, e.g. allergy documentation User will be able to make all changes then Save Last Updated: Date/time Updated By: Name/Title Show Brand (Generic) name When possible.
    105. 107. High fidelity
    106. 108. Or the alternative…
    107. 109. Ultra-high fidelity
    108. 111. &quot;Few things are harder to put up with than the annoyance of a good example.” - Mark Twain
    109. 112. Finally…another mission statement
    110. 113. <ul><li>Gather </li></ul><ul><li>Ask “Why” 5 times to get out of the weeds </li></ul><ul><li>Use a variety of approaches to engage different kinds of stakeholders </li></ul><ul><li>Begin with open-ended questions - use close-ended questions to drill down to specifics </li></ul><ul><li>Use whatever methods are at your disposal to help stakeholders visualize the solution </li></ul><ul><li>Analyze </li></ul><ul><li>Checklists for requirements quality </li></ul><ul><li>Capture Priority and some measure of cost/complexity to rank requirements </li></ul><ul><li>Rank requirements! </li></ul><ul><li>Use pivot tables to rank / group / drill down on requirements </li></ul><ul><li>Validate </li></ul><ul><li>Checklists for ambiguity reviews </li></ul><ul><li>When someone gives you a requirement - ask how they’d test it, right up front </li></ul><ul><li>Help stakeholders visualize the solution to make sure you’re on the right track </li></ul><ul><li>Manage / Process </li></ul><ul><li>Implement RM in a staged approach - 80/20 rule first </li></ul><ul><li>Fine tune templates based on freely available templates (Use Google!) </li></ul><ul><li>Provide visibility to get the most possible eyes on requirements </li></ul>Some pretty good BA practices
    111. 114. Careerbuilder.com job openings stats <ul><li>“ business analyst” – 3,962 job openings </li></ul><ul><ul><li>CA – 400 </li></ul></ul><ul><ul><li>TX – 338 </li></ul></ul><ul><ul><li>NY – 280 </li></ul></ul><ul><ul><li>IL – 230 </li></ul></ul><ul><ul><li>UT – 20 </li></ul></ul><ul><li>“ software engineer” – 5,134 job openings </li></ul><ul><ul><li>CA – 740 </li></ul></ul><ul><ul><li>IL – 311 </li></ul></ul><ul><ul><li>TX – 298 </li></ul></ul><ul><ul><li>NY – 286 </li></ul></ul><ul><ul><li>UT - 36 </li></ul></ul><ul><ul><li>As of 4/30/08 </li></ul></ul>
    112. 115. Business Analyst from Salary.com Business Systems Analyst I Reviews, analyzes, and evaluates business systems and user needs. Formulates systems to parallel overall business strategies. May require an associate's degree in a related area and 0-2 years of experience in the field or in a related area. Has knowledge of commonly-used concepts, practices, and procedures within a particular field. Relies on instructions and pre-established guidelines to perform the functions of the job. Works under immediate supervision. Primary job functions do not typically require exercising independent judgment. Typically reports to a manager.
    113. 116. SW Engineer from Salary.com Entry Level Software Engineer Designs, modifies, develops, writes and implements software programming applications. Supports and/or installs software applications/operating systems. Participates in the testing process through test review and analysis, test witnessing and certification of software. Requires a bachelor's degree in a related area and 0-2 years of experience in the field or in a related area. Has knowledge of commonly-used concepts, practices, and procedures within a particular field. Relies on instructions and pre-established guidelines to perform the functions of the job. Works under immediate supervision. Primary job functions do not typically require exercising independent judgment. Typically reports to a manager.
    114. 117. Business Analyst Resources <ul><li>International Association of Business Analysts (IIBA) </li></ul><ul><ul><li>www.theiiba.org </li></ul></ul><ul><li>Usability Professionals Association (UPA) </li></ul><ul><ul><li>www.upassoc.org </li></ul></ul><ul><li>Project Reference </li></ul><ul><ul><li>http://www.projectreference.com/ </li></ul></ul><ul><li>Volere Requirements Resources </li></ul><ul><ul><li>http://www.volere.co.uk/ </li></ul></ul>
    115. 118. www.mycatalyze.org
    116. 119. http://www.facebook.com/group.php?gid=18509427840
    117. 120. Other Links <ul><li>Catalyze – www.catalyze.org </li></ul><ul><li>IIBA – www.theiiba.org </li></ul><ul><li>UPA – www.upassoc.org </li></ul>
    118. 121. Other iRise Links <ul><li>iRise Website – www.irise.com </li></ul><ul><li>iRise Blog – www.irise.com /blog </li></ul><ul><li>Product Tour - www.irise.com/products/2007_tours/index.php </li></ul><ul><li>iRise Video Contest – www.irisevideo.com </li></ul>
    119. 122. In closing…always remember… <ul><li>Quidquid latine dictum sit, altum sonatur. </li></ul>
    120. 123. In closing…always remember… Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
    121. 124. Business IT
    122. 125. Business IT
    123. 126. Questions? Tom Humbarger [email_address] [email_address]
    124. 127. Thank you!

    ×