Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Usecase Presentation


Published on

Published in: Education, Technology, Business
  • I made $2,600 with this. I already have 7 days with this... ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here

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)