1. Developing Use Cases in a Group Carolyn L. Cukierman Face-to-Face Technology Conference March 27, 2000

2. Overview Background Use Cases Methodology –GroupSystems –Collaboration Benefits Lessons Learned

3. Background Software Engineering Projects –Federal Agency –Military –Health Automation of program functions Establishment of databases Integration with legacy systems, other agency systems

4. Use Cases Ivar Jacobson –1992 book: Object-Oriented Software Engineering: A Use-Case Driven Approach –Satisfying the need for developing requirements. Use cases as the central notion of the development process. –Describes the HOW of the process.

5. Software engineering process Waterfall method –requirements –design –implementation –testing –release All steps completed before starting the next. Incremental/iterative –core subset designed, implemented and tested early –end-user feedback –object-oriented technology Saves development time and avoids errors.

6. What Is a Use Case? “A behaviorally related sequence of transactions in a dialogue with the system.”(Jacobson) A method of identifying information system requirements. A structured description of the interaction of a user and the system -- a description of the process.

7. Why Use Cases? The Use Case depicts the entire flow of a user’s interaction with a system to perform a function. Use cases are an effective tool in communicating to users and developers. Both from a user’s and developer’s perspective use cases are simple to model and understand.

8. More about Use Cases Hold ONLY functional requirements Require no standard form Work best in an easy-to-read, easy- to-track, text format Collect how a goal succeeds and fails Keep the context visible, the value to the user clear

9. A Simple Use Case Recipe Step 1. Identify the who is going to be using the system directly - e.g. hitting keys on the keyboard. These are the Actors. Step 2. Pick one of those Actors. Step 3. Define what that Actor wants to do with the system. Each of these things that the actor wants to do with the system become a Use Case. Step 4. For each of those Use Cases decide on the most usual course when that Actor is using the system. What normally happens.

10. Okay - now how? Pretend you are building an ATM. The bank might say: “I would like for the ATM to allow customers to withdraw cash from their accounts.” In this example, Withdraw Cash is a Use Case.

11. Purpose Describes the reason for the Use Case, i.e. the function the Use Case performs. In our ATM example, Use Case 1.1 - WITHDRAW CASH: Purpose: ATM User requests and receives cash from ATM machine.

12. Actors Actors are any entities that interact with the system. These entities can be people, organizations, or other systems that either provide, or receive information from the system. Primary actor is the one from whose viewpoint all the action occurs. Secondary actors are any other actors involved in the action.

13. Pre-conditions Anything that needs to have taken place or be true, before a Use Case can start. It can be another use case. For Example: –Use Case to put cash in ATM has been executed. –ATM is on and it is ready to accept your card.

14. Flow of Events The Flow of Events is what will normally happen when an Actor uses a part of the system. Events can be various activities: –verbal –written –electronic

15. What else we need to know about an Event Information Items: Data that is entered, viewed, and/or updated by an event. –Examples: name, SSN, date, time, address, etc. Rules: “Operational norms that organizations follow in performing their activities.” – “If / Else” statements, decision tables, etc. –Example: “If a customer has a zero balance in their account, the ATM will not provide cash in this transaction.”

16. Variations As a guideline, if at any point in the Use Case the Main Flow could branch out into two or more directions, then these would be considered variations. –Success or failure of the action. –Different outcomes.

17. Methodology GroupSystems for Windows (Version 1.1E) Use Case Workshops –Education –Collaboration –Group Learning

18. Getting Ready

19. Collaboration Notes Form is less important than the shared understanding between the subject matter experts and the developers. Capturing the “rules” and the “information items” is extremely important to the developers. The context of “how” the action proceeds is an essential piece to keep intact.

20. More.. Duration: 3-4 days per subject Group size: 3-15 participants Subject Matter Experts: –staff –customers Parked tangential issues Provided paper copies of use cases

21. Benefits Repeatable process Documentation Group Memory Team Cohesiveness Time savings Emerging Improvements

22. Lessons Learned Provide simple, easy-to-understand guidance. Avoid participant “weariness.” Focus on validating: do as much up front as possible. Allow an open forum for discussion.

23. Questions? And…..