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.

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.

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.

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

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.

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.

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.