Use Cases Why use ‘em? How do they work? UC diagrams Using them later in the software development cycle

Requirements analysis: Use Case Model Use cases document what a system does/should do, not how it delivers/will deliver those functions UCs document system behavior from the user’s point of view –Work inwards from user requirements –Thinking in terms of what the user wants to do with the system, not how the system will be implemented

…continued A use case is a sequence of actions that an actor performs within a system to achieve a particular goal An actor represents an external entityt that interacts with the system –An actor exchanges information with the system –A role that a user can play with regards to a system –An entity such as another sytsem or a database (outside of the system being modeled)

…continued UC model is developed to help with: –Capturing system requirements –Maintaining traceability across iterations in system design/development –Creating system validation (testing) models UCs evolve; as understanding of users, user needs, system requirements, environment, etc etc change, UCs must reflect that change

An aside: System Development Life Cycle Project proposal Preliminary investigation Requirements analysis and specification System design Detailed design Programming/implementation Testing Installation and changeover Maintenance

Use Cases for requirements capture Result of Use Case modeling: all required system functionality is described in the UCs UCs provide a structured approach to requirements capture –Identify the actors –For each actor find out What they need from the system; that is, what use cases there are which have value for them Any other interactions they expect to have with the system, that is, which UCs they might take part in for someone else’s benefit

Identify Actors Potential human actors tend to be easy to identify –Note distinction between actor and user: User is anyone who uses the system Actor is a role that a user can play A single person (user) can play more than one role (be an instance of more than one Actor) Actors don’t have to be described in great detail; they are identified to help you figure out the UCs that they carry out

…identify actors Non-human actors can be less clear –Wht counts as an external system or device? –Do whatever seems to be most useful—show interactions with external systems: Always When it is the other system that initiates the contact When it is the other system that gets value from the contact

Example: actors in a library system Users: –Librarian –Library member –Non-member of the library Actors (roles): –Librarian –BookBorrower –JournalBorrower –Browser –Homeless

Developing the Use Cases Sit down with the Actors and identify their pertinent Use Cases Ask: –What are the main tasks (in terms of the organization) performed by each actor? –Will the actor read or update any information in the system? –Will the actor have to inform the system about changes outside the system? –Does the actor have to be informed about unexpected changes?

Use Cases in a library system: diagram BookBorrower –Reserve book, Borrow copy of book, Return copy of book, Extend loan JournalBorrower –Borrow journal, Return journal Browser –Browse Librarian –Update catalog, … Homeless –Special case of Browser

Documenting Use Cases Detail of each UC must be written down –Use third person, active voice English –Use terms from the problem domain –Say what the system does (in terms of the business; what it accomplishes for the business), not implementation detail or how The basic course of action is the main start-to- finish path the user will follow under normal circumstances An alternative course of action can represent an infrequently used path, an exception, or an error

…documenting Create a simple UC template: –Actor(s) that initiate the UC –Basic course –Alternate courses Eliciting Use Cases from system stakeholders: –Ask “what happens?” This gets the basic course of action started. –Ask “and then what happens?” Keep asking this question until you have all details fo the basic course on paper –Be relentless. “what else can happen? Are there any other things that can happen?” Keep asking until you have a set of alternative courses written down. –Alternative courses usually hardest to elicit—hard to think of unusual situations, odd occurrences, …

Borrow copy of book UC Actor: BookBorrower Basic course: 1.A BookBorrower presents a book. 2.The system checks that the borrower is a member of the library and that s/he does not already have the maximum permitted number of books on loan. 3.The system records that this library member has this copy of the book on loan. Alternative course(s): 1.If potential borrower is not a member of the library, then the system refuses the loan. 2.If the library member has the maximum permitted number of books (12 for staff members, otherwise 6) then the system refuses the loan.

Scope of a UC Often difficult to decide whether a set of user-system interactions is one UC or several UCs Rule of thumb: –A UC typically represents a major piece of functionality that is complete from beginning to end –A UC must deliver something of value to an actor Focus on things of value that a system provides to an actor –Group sequences of actions together –Review, modify, test action sequences as a unit –Note that a UC represents a complete functionality—don’t represent an individual action that is part of an overall function as a UC (ex: Borrower presenting a book is not a single UC)

Relationships between UCs > relationship: extends a UC by adding new behavior or actions –Example: Borrow ‘Adult Materials’ book; > Borrow a copy of a book –need to follow additional steps for AM books > relationship: one UC references another UC –Means that one UC uses the other UC when executing –Example: would make sense to have a UC ‘Check library fine’ –Then ‘Borrow copy of a book’ would have an > relationship with ‘Check library fine’ UC

Use Case diagrams in the analysis process Client interviews start the process –Use terminology of the client Start talking to users (generally more than the single client person) –Initial interviews reveal actors and functional requirements in general terms (high level UCs) –Helps define boundaries and scope of the proposed system –Later interviews delve into more detail. Produce UC models that show usage scenarios and sequences in detail Diagrams and UCs should be produced iteratively

UCs through the development cycle Planning –Need a list of all UCs for the proposed system, together with: A good idea of what each entails An understanding of who wants each, why, and how much Knowledge of which UCs carry the most risk when implementing An estimate of how long it should take to implement each UC Political aspects –Identify which UCs are most important to which people –Satisfy the most influential people first

…through development Technical aspects –Attempt/deliver UCs associated with highest risk first System validation –Each UC satisfies some functional requirement(s) –Correct design realizes each UC –Derive system tests from UC walkthroughs