1. Object-Oriented Analysis and Design Evolutionary Requirements

2. UP Requirements Artifacts Use Case Model – typical scenarios of functional requirements Supplementary Specifications – primarily non- functional requirements Glossary – noteworthy terms including a Data Dictionary (a recording of data requirements) Vision – high-level requirements and business case summary Business Rules – (aka Domain Rules) requirements or policies which apply to many projects required by business or domain (e.g. tax laws)

4. Object-Oriented Analysis and Design Use Cases Read chapter 6

5. Define the Problem The most critical question: Is this the right system to make?

6. Use Case Relationships Domain Model Use Case Model Interaction Diagrams Design Requirements Business Model Objects, attributes, associations VISION GLOSSARY SUPPLEMENTARY SPECIFICATION

7. Use Cases are not Diagrams Use Cases have a diagram associated with them easy way for analyst to discuss a process with a domain expert Use cases are primarily text text = important; diagram = optional

8. Why Use Cases? Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals. They keep it simple They emphasize goals and the user perspective Focus on the essence/intent of requirements Avoid bias of reproducing the existing system

9. Identify Use Cases Capture specific ways of using the system as dialogue between an actor and the system. Use cases are used to: Capture functional system requirements Communicate with end users and Domain Experts Test the system

10. Specifying Use Cases Create a written document for each Use Case Clearly define intent of the Use Case Define Main Success Scenario (Happy Path) Define any alternate action paths Use format of Stimulus: Response Each specification must be testable Write from actors perspective, in actors vocabulary

11. Use Case Template Items Use Case Name Scope (the system under design) Level ("user-goal" or "subfunction") Primary Actor (calls on system to deliver its function) Stakeholders and Interests (Who cares? What do they want?) Preconditions (what must be true at use case start) Success Guarantee (aka Posconditions; what must be true on successful use case completion) Main Success Scenario (happy path/sunny day) Extensions (alternative scenarios) Special Requirements (non-functional requirements)

12. Suggested Other Use Case Items Technology and Data Variations (I/O methods and data formats) Frequency of Occurrence (of use case) Miscellaneous (e.g. open issues) See Use Case UC1: Process Sale p. 68

13. Naming Use Cases A complete process from end user viewpoint Usually in verb-object form, (e.g. Register for Classes) Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the system

14. Use Case Name Examples Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure, not process)

15. Singular or Plural? Usually determined by context. Preference for the simplest form, but most common form can be better. In the example of concert tickets, most people buy more than one, but a significant number buy only one. At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item.

16. Identify Actors Part of understanding a system is knowing who uses it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system

17. Specifying Actors External to the system Non-deterministic May be different roles for one individual user May be other external systems

18. Identifying Actors Primary Actor Emphasis is on the primary actor for the use case – has goals to be fulfilled Stakeholders and Interests Other actors are listed as stakeholders. The interests of each key actor should be described.

19. Working with Use Cases Determine the actors that will interact with the system Examine the actors and document their needs For each separate need, create a use case During Analysis, extend use cases with interaction diagrams

20. Preconditions Anything that must always be true before beginning a scenario is a precondition. Assumed to be true, not tested within the Use Case Ignore obvious preconditions (e.g. power is on)

21. Success Guarantees (Postconditions) States what must be true if the Use Case is completed successfully May include the main success scenario and some alternative paths Stakeholders should agree on the guarantee.

22. Scenarios Main Success Scenario, or happy path is expected primary use of the system, without problems or exceptions. Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.

23. Happy Path / Sunny Day Scenario Success Scenario (or basic course) gives the best understanding of the use case Each step contains the activities and inputs of the actor and the system response Two column template works well for this If three or more items, create a list Label steps for configuration management and requirements traceability Use present tense and active voice

24. Extensions (Alternative Flows) Extensions or Alternative Flow Use Cases allow the specification of Different ways of handling transactions Error processes Sections are convenient way to handle alternative courses of action Sections are a segment of a use case executed out of sequence

25. Essential versus Real Use Cases Essential (black box) use case leaves out technology and focuses only on functionality Real (white box) use case includes technology is fundamental. E.g., essential Withdraw Cash from ATM use case can mention identification or validation Only real Withdraw Cash from ATM use case can mention a key pad or card reader

26. Extension Use Cases Users appreciate simplicity, so most use cases leave out alternate courses Do this by extending the use case (see Use Case Diagramming section below) while leaving the original use case alone

27. Use-case driven development Requirements are primarily recorded in the Use Case model. Iterations are planned around implementing particular Use Cases. Use Case Realizations drive design. Use Case often influence the way user manuals are organized.

28. Diagramming Use Cases read Chapter 30 Object-Oriented Analysis and Design

29. Actor An actor is an idealized user of a system Actors can be users, processes, and other systems Many users can be one actor, in a common role One user can be different actors, if in different roles An actor is labeled in singular with the name of the role

30. Non-human Actor Actors can be users, processes, and other systems. Non human actors typically shown as rectangle rather than stick figure Usually not primary users, and thus are usually shown on the right Inventory System

31. Use Case Is a coherent unit of externally visible functionality provided by a system and expressed by a sequence of messages Additional behavior can be shown with generalize, extend, and include use case relationships Labeled with the use case name

32. System A system is shown as a rectangle, labeled with the system name Actors are outside the system Use cases are inside the system The rectangle shows the scope or boundary of the system Dont forget the boundary and the system name, unless you are using Rational Rose!

33. Association Relationship An association is the communication path between an actor and the use case that it participates in It is shown as a solid line It does not have an arrow, and is normally read from left to right Here, the association is between a Modeler and the Create Model use case

34. Include Relationship Include relationships insert additional behavior into a base use case They are shown as a dotted line with an open arrow and the key word > Shown is a process that I observed in an earlier career

35. Extend Relationship Extend puts additional, optional behavior in a use case that does not know about it. It is shown as a dotted line with an arrow point and labeled > In this case, a customer can request a catalog when placing an order

36. Generalize Relationship Is a relationship between a general use case and a more specific use case that inherits and extends its features It is shown as a solid line with a closed arrow point Here, the payment process is modified for cash and charge cards

37. Use Case Example: Alarm Clock This is a contrived example, to show many relations. Your diagrams should be simpler.