Use Case

2 Copyright e-Government Program (Yesser) Use Case - Summary Slide  Use Cases – Definition  The purpose of use cases  Why use use cases?  UML - Use case diagram  UML use cases – Actors  Example of use case diagram  Use case definition + description - the process  Draw use case packages  Grouping of business functionality – Use case packages  Draw use case diagrams  Identify actors  Complete verbal description  Use cases – Verbal description  Identify variants and exceptions  Audit business process and term model

3 Copyright e-Government Program (Yesser) Use Cases – Definition  A Use Case is a way of using a system oA scenario that describes limited interaction between a system and actors in the field  In a Use Case, you describe the use of a system for a given work task oYou consider a complete work task, initiated by an actor oYou utilise ”company language” in describing the work task oThe aggregate Use Cases display the aggregate actor use of the system

4 Copyright e-Government Program (Yesser) The purpose of use cases  The purpose for using use cases is to oUncover and describe all tasks that need doing in a system (of both human and system actors) oTo analyse what functionality that need developing for the system oThe use of use cases must mean that the right functional requirements are made of the IT system (the requirements of the business!)

5 Copyright e-Government Program (Yesser) Why use use cases?  Use case strengths are oThat they work well as an analytical tool oThat the notation is simple and easy to pick up oThat they are easy to understand, both for the business and from the technological aspect oIt is a widely recognised market standard oThat customer and supplier – or operators and technicians – can jointly work out and understand the operational functionality oThey bring structure, and ensure complete analysis  The challenge, then, is to find and describe all use cases!

6 Copyright e-Government Program (Yesser) Use cases are documented in two ways  Use Case diagrams oGive an overview of visible use scenarios in the system oDescribes what actors that interact with the system oDescribes any linkages between use cases  Verbal description oDescribes the content of each use case oTypically uses a pre-defined template

7 Copyright e-Government Program (Yesser) UML - Use case diagram  Definition: odiagram which provides an overview of system functionality oShows which use cases the individual actor uses  Purpose: oTo analyse the functionality the system must include oTo give an overview of the functionality and how it is linked oTo analyse how the actors should use the system  Challenges: oTo simplify the complex Construction elements: Package Use case Communication arrow Extends a use case Includes a use case No. and use case name Package name

8 Copyright e-Government Program (Yesser) UML use cases – Actors  Actor: oPerson (or system), which uses the system (think in terms of roles)  Purpose: oTo analyse which actors will use the system oTo analyse how the use of the actors is linked  Challenges: oIt is NOT an organisational chart (no organisational linkages required) Construction elements: Actor Specialisation / Generalisation

9 Copyright e-Government Program (Yesser) Example of use case diagram Web store Find an item Order an item Check order Customer Registered customer SADAD Order fast delivery Free search Structured search > Actor (person) Actor (system) use case

10 Copyright e-Government Program (Yesser) Use case definition + description - the process Agency Draw use case diagrams Complete verbal descriptions Identify actors Draw use case packages Initial state: - A stakeholder analysis has been performed - Processes have been modeled Final state: - All use cases identified and documented All Use Cases Finished ? yesno Audit business process and term model Link to: -Business ProcessBusiness Process -Term modelingTerm modeling Identify variants, exceptions, and start & end conditions

11 Copyright e-Government Program (Yesser) Prerequisites  Always begin by making a stakeholder analysis! (In case it has not been done during process modelling) oA good way of discovering new use cases oA high degree of confidence that all relevant use cases are included oThe use case actors are often only part of the overall pool of stakeholders

12 Copyright e-Government Program (Yesser) Draw use case packages 1.Draw use case packages - for each business process oBase it on the processes oHas a thorough stakeholder analysis been done? oPut all actors for each business process on the packages

13 Copyright e-Government Program (Yesser) Grouping of business functionality – Use case packages  Use case packages divide use cases into packages that make business sense  Typically, cases that belong to a given process  …But it could also be use cases in a given topic / with particular actors / other  The packages help to provide overview  If a documentation tool is used, use cases may be organised as illustrated

14 Copyright e-Government Program (Yesser) Draw use case diagrams 2.Draw use case diagrams - for each package oWhich of the process diagram activities are relevant to the solution? oAn activity in a process corresponds to a use case (using this method)

15 Copyright e-Government Program (Yesser) Use Case Example Use case diagram: ”Work Permit”

16 Copyright e-Government Program (Yesser) Identify actors 3.Identify actors - for each use case oWho or what initiates the use case? oSplit the actors into roles (not e.g. according to organisational dependence) oAny specialisations of an actor? oSplit the actors into those that initiates (triggers) a use case, and those that are passive actors (e.g. received data)

17 Copyright e-Government Program (Yesser) Complete verbal description 4.Complete verbal description - for each use case oWhat is the purpose of the use case? oWhat needs to be done for the use case to begin? (start conditions) oDescribe the steps in the use case oWhat does the actor do? How does the system react? oWhat is the result of the use case? (end conditions)

18 Copyright e-Government Program (Yesser) Use cases – Verbal description

19 Copyright e-Government Program (Yesser) Use Case - verbal description  There is no standardised notation for how a use case is described, verbally  The description typically includes:  The Use Case name  Purpose  Actors  Start conditions (premises)  Description of the use case steps  Any exceptions  Any variants  End conditions (result)

20 Copyright e-Government Program (Yesser) Use cases – Verbal description  Use case descriptions always include a highway  And may contain both variants and exceptions  The highway describes:  The way the use case is typically run through  Variants describe:  Alternative ways the use case may be run through  The highway and variants can be equally important  Start and end conditions will be common with the highways  Exceptions describe:  Events that cause failure to perform use case as described  I.e. end conditions are not met - Start and end conditions are often under estimated!  Make sure they are precise and well-defined

21 Copyright e-Government Program (Yesser) Identify variants and exceptions 5.Identify all variants and exceptions and firm up the start and end conditions oWhat alternative routes would complete the use case? oAny exceptions that would make the use case stop? oReview the start and end conditions once again -Are they precise and well-defined? -Have all variants been considered?

22 Copyright e-Government Program (Yesser) Audit business process and term model  After completion of use cases (or during) a need will often rise to adjust the process diagrams oYou gain knowledge as you dig deeper into the material oThe activities (and their order) may need adjustment oYou typically discover new actors/roles and new interfaces with other systems / stakeholders  Need to add new terms to the term model oAnd maybe correct the use case descriptions to ensure strict use of the terms in the term model

23 Copyright e-Government Program (Yesser) Use cases – best practice  The grain of use cases – what is the right size for a use case? oA UC must contain a complete task that needs solving – not just a step in a task oWell-defined start and end conditions oFeel your way forward – it takes experience!  The aggregate use cases do not need to reflect a workflow! oIf you do that, the use cases may well be too fine-grained  Naming a UC – use imperative verbs! oE.g. ”Acquire car” – ”Search for car” – ”Get FDM test” – etc. oA good idea to attach numbers to the use cases (not meaningful IDs!)

24 Copyright e-Government Program (Yesser) Definition of use cases - tips  Know your business! oBe business oriented oThe professional experts must participate in the completion of use cases  Keep matters abstract oDescribe functionality – not solution designs oKeep use case descriptions free from ”computer monitor-thinking”  Requirement specification with creativity and visions oIt is important that project participants are visionary and do not ”re-create” existing solutions  You may want a resource able to coordinate business and technical aspects oHas an idea of how a use case can be technically realised oCan discuss issues with the technical staff