Usecase Presentation


Published on

Published in: Education, Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Usecase Presentation

  1. 1. Use Case
  2. 2. Use Case - Summary Slide <ul><li>Use Cases – Definition </li></ul><ul><ul><li>The purpose of use cases </li></ul></ul><ul><ul><li>Why use use cases? </li></ul></ul><ul><li>UML - Use case diagram </li></ul><ul><li>UML use cases – Actors </li></ul><ul><li>Example of use case diagram </li></ul><ul><li>Use case definition + description - the process </li></ul><ul><ul><li>Draw use case packages </li></ul></ul><ul><ul><li>Grouping of business functionality – Use case packages </li></ul></ul><ul><li>Draw use case diagrams </li></ul><ul><li>Identify actors </li></ul><ul><li>Complete verbal description </li></ul><ul><li>Use cases – Verbal description </li></ul><ul><li>Identify variants and exceptions </li></ul><ul><li>Audit business process and term model </li></ul>Copyright e-Government Program (Yesser)
  3. 3. Use Cases – Definition <ul><li>A Use Case is a way of using a system </li></ul><ul><ul><li>A scenario that describes limited interaction between a system and actors in the field </li></ul></ul><ul><li>In a Use Case, you describe the use of a system for a given work task </li></ul><ul><ul><li>You consider a complete work task, initiated by an actor </li></ul></ul><ul><ul><li>You utilise ”company language” in describing the work task </li></ul></ul><ul><ul><li>The aggregate Use Cases display the aggregate actor use of the system </li></ul></ul>Copyright e-Government Program (Yesser)
  4. 4. The purpose of use cases <ul><li>The purpose for using use cases is to </li></ul><ul><ul><li>Uncover and describe all tasks that need doing in a system (of both human and system actors) </li></ul></ul><ul><ul><li>To analyse what functionality that need developing for the system </li></ul></ul><ul><ul><li>The use of use cases must mean that the right functional requirements are made of the IT system (the requirements of the business!) </li></ul></ul>Copyright e-Government Program (Yesser)
  5. 5. Why use use cases? <ul><li>Use case strengths are </li></ul><ul><ul><li>That they work well as an analytical tool </li></ul></ul><ul><ul><li>That the notation is simple and easy to pick up </li></ul></ul><ul><ul><li>That they are easy to understand, both for the business and from the technological aspect </li></ul></ul><ul><ul><li>It is a widely recognised market standard </li></ul></ul><ul><ul><li>That customer and supplier – or operators and technicians – can jointly work out and understand the operational functionality </li></ul></ul><ul><ul><li>They bring structure, and ensure complete analysis </li></ul></ul><ul><li>The challenge, then, is to find and describe all use cases! </li></ul>Copyright e-Government Program (Yesser)
  6. 6. Use cases are documented in two ways <ul><li>Use Case diagrams </li></ul><ul><ul><li>Give an overview of visible use scenarios in the system </li></ul></ul><ul><ul><li>Describes what actors that interact with the system </li></ul></ul><ul><ul><li>Describes any linkages between use cases </li></ul></ul><ul><li>Verbal description </li></ul><ul><ul><li>Describes the content of each use case </li></ul></ul><ul><ul><li>Typically uses a pre-defined template </li></ul></ul>Copyright e-Government Program (Yesser)
  7. 7. UML - Use case diagram <ul><li>Definition: </li></ul><ul><ul><li>diagram which provides an overview of system functionality </li></ul></ul><ul><ul><li>Shows which use cases the individual actor uses </li></ul></ul><ul><li>Purpose: </li></ul><ul><ul><li>To analyse the functionality the system must include </li></ul></ul><ul><ul><li>To give an overview of the functionality and how it is linked </li></ul></ul><ul><ul><li>To analyse how the actors should use the system </li></ul></ul><ul><li>Challenges: </li></ul><ul><ul><li>To simplify the complex </li></ul></ul><ul><li>Construction elements: </li></ul><ul><ul><li>Package </li></ul></ul><ul><ul><li>Use case </li></ul></ul><ul><ul><li>Communication arrow </li></ul></ul><ul><ul><li>Extends a use case </li></ul></ul><ul><ul><li>Includes a use case </li></ul></ul>Copyright e-Government Program (Yesser) No. and use case name Package name
  8. 8. UML use cases – Actors <ul><li>Actor: </li></ul><ul><ul><li>Person (or system), which uses the system (think in terms of roles) </li></ul></ul><ul><li>Purpose: </li></ul><ul><ul><li>To analyse which actors will use the system </li></ul></ul><ul><ul><li>To analyse how the use of the actors is linked </li></ul></ul><ul><li>Challenges: </li></ul><ul><ul><li>It is NOT an organisational chart (no organisational linkages required) </li></ul></ul><ul><li>Construction elements: </li></ul><ul><ul><li>Actor </li></ul></ul><ul><ul><li>Specialisation / Generalisation </li></ul></ul>Copyright e-Government Program (Yesser)
  9. 9. Example of use case diagram Copyright e-Government Program (Yesser) Web store Find an item Order an item Check order Customer Registered customer SADAD Order fast delivery Free search Structured search <<include>> <<extend>> Actor (person) Actor (system) use case
  10. 10. Use case definition + description - the process Copyright e-Government Program (Yesser) Initial state: - A stakeholder analysis has been performed - Processes have been modeled Final state: - All use cases identified and documented yes no <ul><li>Link to: </li></ul><ul><li>Business Process </li></ul><ul><li>- Term modeling </li></ul>Agency Draw use case diagrams Complete verbal descriptions Identify actors Draw use case package s All Use Cases Finished ? Audit business process and term model Identify variants, exceptions, and start & end conditions
  11. 11. Prerequisites <ul><li>Always begin by making a stakeholder analysis! (In case it has not been done during process modelling) </li></ul><ul><ul><li>A good way of discovering new use cases </li></ul></ul><ul><ul><li>A high degree of confidence that all relevant use cases are included </li></ul></ul><ul><ul><li>The use case actors are often only part of the overall pool of stakeholders </li></ul></ul>Copyright e-Government Program (Yesser)
  12. 12. Draw use case packages <ul><li>Draw use case packages - for each business process </li></ul><ul><ul><li>Base it on the processes </li></ul></ul><ul><ul><li>Has a thorough stakeholder analysis been done? </li></ul></ul><ul><ul><li>Put all actors for each business process on the packages </li></ul></ul>Copyright e-Government Program (Yesser)
  13. 13. Grouping of business functionality – Use case packages <ul><li>Use case packages divide use cases into packages that make business sense </li></ul><ul><ul><li>Typically, cases that belong to a given process </li></ul></ul><ul><ul><li>… But it could also be use cases in a given topic / with particular actors / other </li></ul></ul><ul><li>The packages help to provide overview </li></ul><ul><ul><li>If a documentation tool is used, use cases may be organised as illustrated </li></ul></ul>Copyright e-Government Program (Yesser)
  14. 14. Draw use case diagrams <ul><li>Draw use case diagrams - for each package </li></ul><ul><ul><li>Which of the process diagram activities are relevant to the solution? </li></ul></ul><ul><ul><li>An activity in a process corresponds to a use case (using this method) </li></ul></ul>Copyright e-Government Program (Yesser)
  15. 15. Use Case Example Copyright e-Government Program (Yesser) Use case diagram: ”Work Permit”
  16. 16. Identify actors <ul><li>Identify actors - for each use case </li></ul><ul><ul><li>Who or what initiates the use case? </li></ul></ul><ul><ul><li>Split the actors into roles (not e.g. according to organisational dependence) </li></ul></ul><ul><ul><li>Any specialisations of an actor? </li></ul></ul><ul><ul><li>Split the actors into those that initiates (triggers) a use case, and those that are passive actors (e.g. received data) </li></ul></ul>Copyright e-Government Program (Yesser)
  17. 17. Complete verbal description <ul><li>Complete verbal description - for each use case </li></ul><ul><ul><li>What is the purpose of the use case? </li></ul></ul><ul><ul><li>What needs to be done for the use case to begin? (start conditions) </li></ul></ul><ul><ul><li>Describe the steps in the use case </li></ul></ul><ul><ul><ul><li>What does the actor do? How does the system react? </li></ul></ul></ul><ul><ul><li>What is the result of the use case? (end conditions) </li></ul></ul>Copyright e-Government Program (Yesser)
  18. 18. Use cases – Verbal description Copyright e-Government Program (Yesser)
  19. 19. Use Case - verbal description <ul><li>There is no standardised notation for how a use case is described, verbally </li></ul><ul><li>The description typically includes: </li></ul><ul><ul><li>The Use Case name </li></ul></ul><ul><ul><li>Purpose </li></ul></ul><ul><ul><li>Actors </li></ul></ul><ul><ul><li>Start conditions (premises) </li></ul></ul><ul><ul><li>Description of the use case steps </li></ul></ul><ul><ul><li>Any exceptions </li></ul></ul><ul><ul><li>Any variants </li></ul></ul><ul><ul><li>End conditions (result) </li></ul></ul>Copyright e-Government Program (Yesser)
  20. 20. Use cases – Verbal description <ul><li>Use case descriptions always include a highway </li></ul><ul><ul><li>And may contain both variants and exceptions </li></ul></ul><ul><li>The highway describes: </li></ul><ul><ul><li>The way the use case is typically run through </li></ul></ul><ul><li>Variants describe: </li></ul><ul><ul><li>Alternative ways the use case may be run through </li></ul></ul><ul><ul><li>The highway and variants can be equally important </li></ul></ul><ul><ul><li>Start and end conditions will be common with the highways </li></ul></ul><ul><li>Exceptions describe: </li></ul><ul><ul><li>Events that cause failure to perform use case as described </li></ul></ul><ul><ul><li>I.e. end conditions are not met </li></ul></ul><ul><li>Start and end conditions are often under estimated! </li></ul><ul><ul><li>Make sure they are precise and well-defined </li></ul></ul>Copyright e-Government Program (Yesser)
  21. 21. Identify variants and exceptions <ul><li>Identify all variants and exceptions and firm up the start and end conditions </li></ul><ul><ul><li>What alternative routes would complete the use case? </li></ul></ul><ul><ul><li>Any exceptions that would make the use case stop? </li></ul></ul><ul><ul><li>Review the start and end conditions once again </li></ul></ul><ul><ul><ul><li>Are they precise and well-defined? </li></ul></ul></ul><ul><ul><ul><li>Have all variants been considered? </li></ul></ul></ul>Copyright e-Government Program (Yesser)
  22. 22. Audit business process and term model <ul><li>After completion of use cases (or during) a need will often rise to adjust the process diagrams </li></ul><ul><ul><li>You gain knowledge as you dig deeper into the material </li></ul></ul><ul><ul><ul><li>The activities (and their order) may need adjustment </li></ul></ul></ul><ul><ul><ul><li>You typically discover new actors/roles and new interfaces with other systems / stakeholders </li></ul></ul></ul><ul><li>Need to add new terms to the term model </li></ul><ul><ul><li>And maybe correct the use case descriptions to ensure strict use of the terms in the term model </li></ul></ul>Copyright e-Government Program (Yesser)
  23. 23. Use cases – best practice <ul><li>The grain of use cases – what is the right size for a use case? </li></ul><ul><ul><li>A UC must contain a complete task that needs solving – not just a step in a task </li></ul></ul><ul><ul><li>Well-defined start and end conditions </li></ul></ul><ul><ul><li>Feel your way forward – it takes experience! </li></ul></ul><ul><li>The aggregate use cases do not need to reflect a workflow! </li></ul><ul><ul><li>If you do that, the use cases may well be too fine-grained </li></ul></ul><ul><li>Naming a UC – use imperative verbs! </li></ul><ul><ul><li>E.g. ”Acquire car” – ”Search for car” – ”Get FDM test” – etc. </li></ul></ul><ul><ul><li>A good idea to attach numbers to the use cases (not meaningful IDs!) </li></ul></ul>Copyright e-Government Program (Yesser)
  24. 24. Definition of use cases - tips <ul><li>Know your business! </li></ul><ul><ul><li>Be business oriented </li></ul></ul><ul><ul><li>The professional experts must participate in the completion of use cases </li></ul></ul><ul><li>Keep matters abstract </li></ul><ul><ul><li>Describe functionality – not solution designs </li></ul></ul><ul><ul><li>Keep use case descriptions free from ”computer monitor-thinking” </li></ul></ul><ul><li>Requirement specification with creativity and visions </li></ul><ul><ul><li>It is important that project participants are visionary and do not ”re-create” existing solutions </li></ul></ul><ul><li>You may want a resource able to coordinate business and technical aspects </li></ul><ul><ul><li>Has an idea of how a use case can be technically realised </li></ul></ul><ul><ul><li>Can discuss issues with the technical staff </li></ul></ul>Copyright e-Government Program (Yesser)