Use cases friend or foe a panel presentation
1 / 18

Use Cases; Friend or Foe - PowerPoint PPT Presentation

  • Updated On :

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Use Cases; Friend or Foe ' - Solomon

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Use cases friend or foe a panel presentation l.jpg


Twin Cities Business Analyst Community

Use Cases; Friend or Foe? – A panel presentation

June 22nd, 2006


Hosted by:

Consulting Matters and Solutia Consulting Inc.

Please do not distribute this information.

Panel agenda l.jpg


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

Panel bio s l.jpg


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.

Slide4 l.jpg


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.

Slide5 l.jpg


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

Allianz life use case success story l.jpg


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.

Slide7 l.jpg


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


Twin Cities Business Analyst Community

Allianz Life - Pros/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

Allianz life tips lessons learned l.jpg


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…


Twin Cities Business Analyst Community

Allianz Life - Tips/Lessons Learned


  • 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

Slide9 l.jpg


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.

Lifetime fitness use case success story l.jpg


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.

Lifetime fitness pros cons l.jpg


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.

Slide12 l.jpg


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.

Slfc use case experience l.jpg


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

Slfc use case success story l.jpg


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

Slfc pros cons l.jpg


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


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


Twin Cities Business Analyst Community

SLFC - Pros/Cons

Slfc tips lessons learned l.jpg


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

Additional resources l.jpg

“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


Twin Cities Business Analyst Community

Additional Resources

Slide18 l.jpg

TCBAC Addison-Wesley, 2001

Twin Cities Business Analyst Community

QUESTIONS?For TCBAC information or feedback please contact [email protected] TCBAC Meetings:(same time and location, look for an Evite)Thursday October 5th