Use Cases; Friend or Foe? – A panel presentation

1. TCBAC Twin Cities Business Analyst Community Use Cases; Friend or Foe? – A panel presentation June 22nd, 2006 5:30pm Hosted by: Consulting Matters and Solutia Consulting Inc. Please do not distribute this information.

2. TCBAC Twin Cities Business Analyst Community Panel Agenda • Introduce Panel Participants • Casey Deckard • Erin Wright • Andrew Thomas • Cheryl Nordby • Panel Participant Experiences • Use Case experience • Success story on the usage of Use Cases • Pro/Con’s of Use Cases • Tips or lessons learned • Questions and Discussion

3. TCBAC Twin Cities Business Analyst Community Panel Bio’s • Casey Deckard Casey is a Principal Business Analyst at Allianz Life. She has worked in the IT industry for 12 years in various capacities including Desktop Support, Systems Analysis, User Interface Design, and Business Analysis. She has utilized the Rational Unified Process (RUP) and Use Cases for the past 5 years. Casey is currently managing one of several Business Analyst groups across Allianz Life and helping to refine requirements development and management processes for the enterprise. • Erin Wright Erin is a Principal Business Analyst at Allianz Life. Erin has worked in the IT industry for 9 years (8 years as a consultant) in many capacities including Business Analyst, Project Manager, User Interface Analyst, Usability Specialist, and Technical Writer and Trainer. Erin has utilized the Rational Unified Process (RUP) for 7 years and use cases for 6 years. Her industry experience includes Financial Services, Retail, Insurance, Travel and Agriculture.

4. TCBAC Twin Cities Business Analyst Community Panel Bio’s • Andrew Thomas Andrew is a Manager for the Business Analysis and User Interface Teams at Lifetime Fitness. He has been in the IT industry for 7 years, 6 years as an Analyst. Andrew was a Behavioral Psychologist and Trainer in his previous life. He worked in a RUP / Use Case centered environment for the first 5 years with Life Time Fitness, participating in at least 30 projects where Use Cases were used, including multiple enterprise applications. Lifetime moved away from the UML / Use Case centered environment at the beginning of 2005. • Cheryl Nordby Cheryl Nordby is President and Principal Consultant, Consulting Matters. She has over 20 years management consulting experience in a wide variety of industries and disciplines. Her primary area of expertise is facilitating work teams for high performance, especially in strategic planning, business process improvement, and business analysis. Most currently she has consulted for Student Loan Finance Corporation in Aberdeen, SD. She was responsible for the requirements definition phase on multiple projects as well as training and mentoring the organization’s business analysts. She worked with the IT organization to implement Use Cases in the Definition Phase of their systems development lifecycle methodology.

5. TCBAC Twin Cities Business Analyst Community Allianz Life - Use Case Experience • Lucky enough to implement Rational suite at the same time we created our use case methodology; we had resources from Rational to help establish our practices • Utilize for all web related projects; just starting to utilize for non-web related projects • COTS: Use case survey developed for RFP; specific use cases may or may not be elaborated • At the time, training was not available; needed to develop the “Allianz” style • Created a “Use Case Architect” role to provide 1/1 feedback and ensure consistency • Business was very open to them overall; best to provide visual representation in the form of an activity diagram and/or wireframe • No “automated” traceability to design or test requirements as of yet (utilizing different tools) • QA exports requirements and associates rule numbers to test cases/steps manually • SA role is new to organization; in process of defining the design documentation process • Goal is for each use case to have a corresponding use case realization and for QA to use both documents to build their test cases • Started with the Use Case Specification from RUP; tailored to provide guidance to help enforce consistent style and ensure requirements for specific components/applications not missed

6. TCBAC Twin Cities Business Analyst Community Allianz Life - Use Case Success Story • Helped in identifying Enterprise requirements and scenarios that can be re-used in the form of enterprise requirements/use cases • Helped create a component based view of requirements allowing for iteration based project delivery • Provides clear scenarios for development teams to design and develop against • Allows for prioritizing scenarios based on architectural significance so that we can see issues earlier in the lifecycle • Analysts can easily pick up another analysts requirements and quickly come up to speed on current requirements, outstanding issues and changes that have been made • Provides a standard framework for business analysts so our customers receive a consistent view of requirements every time, no matter which analyst created them • Our use cases template has been simplified in that we have chosen not to use includes or extends. • Our tool (Rational) has been helpful as it is a slightly more automated way of including traceability and managing change.

7. Pros Provides consistent framework for requirements Provides re-use of requirements and components Tells a story using conversational language and specifies requirements from the user perspective Uses scenarios to detail the various paths throughout the flow. (alternate and exception paths) Easily translated to test cases Use cases can serve as the basis for the estimating, scheduling, and validating the effort of a project Provides context for requirements within a flow of events TCBAC Twin Cities Business Analyst Community Allianz Life - Pros/Cons Cons • Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the analyst. • Use cases have a learning curve involved in interpreting them correctly, for both end users and programmers. • Can be difficult to determine when you are “done” • A use case does imply system flow, which in turn can imply design. Can make it difficult to know when/how to separate the how from the what. • Takes significant effort and time to bring them into an organization

8. Do Do have buy-in to the templates – from both the BAs and their customers (business and development!); provide introductions on “interpreting use cases” Do establish a Use Case Architect role to help define Requirement Management and Development plans to ensure consistency and provide mentorship throughout the suite of use cases Do provide a framework to avoid duplication of requirements (i.e. Supplementary Specification, Software Requirements Specification, Enterprise requirements) Do use a tool that can provide tagging, traceability and change control management. (We use the Rational tools) Do use supporting documents for optimal understanding (activity diagrams and wireframes) Do have a clear scope stated or use cases won’t help at all… TCBAC Twin Cities Business Analyst Community Allianz Life - Tips/Lessons Learned Don’t • Don’t try to use includes/excludes or generalizations initially. There are easier, less formal methods to show use case relationships. Once use cases are well established and understood, you may consider introducing the concepts. • Don’t create use cases by scenario over multiple iterations - causes a lot of re-work

9. TCBAC Twin Cities Business Analyst Community Lifetime Fitness - Use Case Experience • From 1999 through 2004 LTF software development team used use cases and other documents to convey requirements. This practice was introduced from the inception of our MIS department by consultants who developed our first systems. • Regularly found ourselves manually filling the gaps by e-mail or verbal communication. • Over the years, we continually tried to modify our use case centered process to fit the needs of all the teams, but were never fully satisfied. • LTF has abandoned use cases as a published artifact that is used for development. Moved to using the Software Requirements Specification as the primary document that the development team refers to for requirements.

10. TCBAC Twin Cities Business Analyst Community Lifetime Fitness - Use Case Success Story • Most successful when being applied to smaller maintenance projects, where constraints, system requirements and quality attributes are already defined. • We’ve had good success implementing principles of use cases into the Software Requirements Specifications. • Use Cases are still a good tool for helping analysts to reveal functional requirements. • Found that use cases are a handy sidekick in the development process, but there is a lot they don’t know. Use Cases can tell you how to get from point A to point B, but they’ll never tell you about the proverbial speed trap along the way or how much you can expect to pay in tolls. • Usefulness must be gauged in the context of the entire software development process.

11. TCBAC Twin Cities Business Analyst Community Lifetime Fitness - Pros/Cons • Pros: • Very useful for the Analyst for the purpose of revealing requirements. • Helps the business understand the process and determine any changes to the business process that may be needed. • Good for shaping test cases and training manuals. • Cons: • When contained in use cases, requirements are often spread amongst multiple documents. This is cumbersome for other members of the development team as they must reference multiple documents. • Limited in scope. Software development requires understanding of business rules, user requirements, project requirements, quality attributes, constraints, system requirements and functional requirements. Use cases only deliver the first two items.

12. TCBAC Twin Cities Business Analyst Community Lifetime Fitness - Tips/Lessons Learned • Use cases and logical sequencing of events work well when paired with other requirements into one master document that contains all requirements for the software.

13. TCBAC Twin Cities Business Analyst Community SLFC - Use Case Experience • As part of a large systems development and implementation project, a major consulting firm introduced use cases to SLFC in 2001 • These use cases were tied to elementary business processes and were not “fully dressed” • SLFC did not continue with use cases after this project • More recently, SLFC has implemented more structure and discipline in their SDM, especially in the upfront definition phase • System level use cases have been adopted as one element of their requirements documentation: • To ensure all process variations and error conditions are identified and documented • To more effectively support the testing effort • BAs, Project Managers and Test Leads have been trained on all aspects of use cases • Use cases are only one part of their definition phase documentation: • Process maps • Functional requirements statements • Business rules • Interface requirements/descriptions • Reports, screens and letters inventories/descriptions • Use cases are developed/used for most projects (this is determined during the Project Initiation Phase when confirming the Definition Phase approach

14. TCBAC Twin Cities Business Analyst Community SLFC - Use Case Success Story • Used successfully on a web project • Very effective in identifying variations and error conditions • Testing “loved” the use case • Covered all testing scenarios • Made it easy to write test scripts • Was a good communication vehicle for reviewing requirements with external partners • Used to train and orient users on the new process

15. Pros Excellent communication vehicle for design, testing and training Is a very good instrument for identifying error conditions and variations Relatively easy to read Can be adapted to document business and system level processes Cons Requires skill to write effective use cases Does not document all requirements Hard to know when enough is enough May not be applicable to all types of projects TCBAC Twin Cities Business Analyst Community SLFC - Pros/Cons

16. TCBAC Twin Cities Business Analyst Community SLFC - Tips/Lessons Learned • Determine where in the SDM use cases fit • Determine up front what use cases will be used for to determine types/levels of use cases • Business vs system • “Black” box vs “white” box • Establish realistic expectations about what use cases can and cannot do • Implement customized, standard use case templates for your organization • Don’t be afraid to change your use case template if it’s not working for you • Provide training on how to write effective use cases and how to read use cases • Process maps/diagrams can be useful when developing a use case • Start small and build on success • If you are just starting out with use cases, don’t worry too much about re-usability • Do store your use cases so they are easily found/accessible

17. “Writing Effective Use Cases” by Alistair Cockburn, Addison-Wesley, 2001 “Object-Oriented Software Engineering: A Use Case Driven Approach” by Ivar Jacobson, Addison-Wesley, 1994 IBM Website, Introduction to Use Cases http://www-128.ibm.com/developerworks/java/library/co-design5.html TCBAC Twin Cities Business Analyst Community Additional Resources

18. TCBAC Twin Cities Business Analyst Community QUESTIONS?For TCBAC information or feedback please contact TCBAC@solutiaconsulting.comFuture TCBAC Meetings:(same time and location, look for an Evite)Thursday October 5th