Presented by Ona Wilkins January 16, 2013 Use Cases

Who has a general idea of what a use case is? Who has attended training in Use Cases? Who has written Use Cases? Who likes them? Who does not like them?

What is a Use Case? A Requirements Gathering / Definition Tool Provides a method to organize a large number of requirements Provides a method to work with users to define their needs, and map them out. It works for small projects as well, including maintenance A different way of thinking – forces the definition of business process before defining the technical solution It focuses on the business’ point of view Works for transaction-type requirements

Actor Table / Use Case Definitions Two New Documents being utilized in the Requirements Gathering Process: 1. Actor Table 2. Use Cases

Actor Table / Use Case Definitions What is an Actor Table? An actor table identifies and classifies system users in terms of their roles and responsibilities. (not their job title) What are Use Cases? Use cases are descriptions in abstract terms of how actors use the system to accomplish goals. Each use case is a logical piece of user functionality that can be initiated by an actor and described from the actor’s point of view in a technology-neutral manner.

Actor Table Description What is an Actor Table? An actor table identifies and classifies system users in terms of their roles and responsibilities. (It is not a job title) Why use an Actor Table? To detect missing system users, to identify functional requirements as user goals (use cases), and to help the business clarify job responsibilities.

Actor Table

Use Case Description What are Use Cases? Use cases are descriptions in abstract terms (or not – can be detailed) of how actors use the system to accomplish goals. Each use case is a logical piece of user functionality that can be initiated by an actor and described from the actor’s point of view in a technology-neutral manner. Why use Use Cases? To reveal functional requirements by clarifying what users need to accomplish when interacting with the system. Use cases are a natural way to organize functional requirements and can be easier for users to understand and verify than textual functional requirements statements.

Use Case Description What do Use Cases do ? – Specify user Requirements as actor goals that are described as sequences of interactions between the actor and the system – Document detailed steps for normal system usage as well as for handling errors and variations – Help discover business rules and necessary data – Provide easy-to-read requirements documentation for users who cannot participate in face-to-face requirements elicitation – Provide a shorthand way to discuss sets of related scenarios – Group user requirements in a manner that facilitates requirements prioritization and determining incremental software releases – Provide a basis for developing test cases

Use Case Contents What does a Use Case include? 1.Header, containing high-level identification information about the use case 2.Brief description, summarizing what the use case accomplishes 3.Detailed steps, that the actor and system go through to accomplish the use case goal 4.Exceptions, describing the steps for handling errors and exceptions 5.Variations, describing the steps for handling alternative courses through each use case. Note: Every use case does not have to have the same level of detail; sometimes the header and brief description are sufficient.

What Use Cases Don’t Do: Document performance requirements Describe technical architecture requirements (e.g. storage, platform, network, memory, DBMS, etc.) Describe design protocols (e.g. events, messages, states) Describe GUIs (e.g. windows, icons, dialog boxes, etc.) Show concurrency

An Example of a Use Case: DO Use a Table – Do NOT use all text

The following questions can help you identify the steps of the Use Case: How does the actor interact with the system? What does the system do at this step (for example, present options, display data, execute a process)? What does the system do next? What does the actor do next? Is there part of the Use Case that is another Use Case? Note: Most steps will fit on one line. Variations (Alternate): If something in the step doesn’t or can’t happen, what should happen instead? What other possible actions can the user take at each step? Exceptions: What might go wrong when the system executes the step? What possible error conditions exist at each step of the main course? What are the interrupts that can happen at any time? If the user cancels out at any step, what should happen? How do I write a Use Case?

Where does it fit in the process? Write Descriptions Identify Use Cases Capture organization benefits Capture Frequencies Prioritize Use Cases Complete Header Information Write Normal Course (happy path) Write alternate courses and exceptions User Stories Process Flow High Level Requirements Anytime one or more users interact with a system, a Use Case can be helpful to describe those system interactions from the user’s perspective. Helps to answer the ‘How?’ in the requirements.

Personal History with ‘Use Cases’ Fall, 2006 – Attended the Business Analyst World conference in Chicago, and I opted to attend 2 day-long sessions on Use Cases. Created some for RFP for new system; stakeholders loved it – they ‘got it’. Used in Agile web re-design project; Developers used them as functional spec (in addition to Business Rules); BA used them as basis for test cases

My First Attempt Struggled with defining roles – tried to follow some rules Something learned at the conference: – There are not many rules – Some controversy among the experts My Decision – trying to utilize Use Cases, even if not perfect, is better than not using them at all – They really give the big picture, from start to finish – Event-Response format is an easy way to start – They define the details – input, output, business rules (still like to document business rules separately as well) – Easy to go from Current-State to Future-State – Gets it all defined up-front – reduces risk of missed requirements, incorrect requirements, scope change, etc. – Really!!! – Re-usable – Traceable – Foundation for Test Cases Paradigm Shift in some areas – spend time up-front – can’t just jump to technical solution – isn’t that great?

My Personal Experience – RFP – Business Decision – gather requirements – get internal estimate, do an RFI – Conducted brain-storming sessions on requirements (ya know…the old EDS and Arthur Anderson method) – ranked Must Have, Should Have, Nice to Have – Tried to Categorize – Letter Maintenance, Reports, Security, etc. – Stuck…Overwhelmed…wasn’t making sense to me, figured it wouldn’t make sense to the users, IT, or anyone else – it just wasn’t coming together – Attended Use Case Seminars - Thought – YES – this is it! – Played around with requirements that I had, organized some into Use Cases – Presented Use Case ppt, and my Use Cases. Received very positive feedback from business managers – it was all making sense…coming together – yahoo!

Remember what Bob Prentiss told us last fall, in his Simplexification of Process Modeling: QUIT when it is GOOD ENUF!

Recommended Reading The Software Requirements Memory Jogger by Ellen Gottesdiener Visual Models for Software Requirements by Joy Beatty and Anthony Chen (SEILEVEL) Writing Effective Use Cases by Alistair Cockburn