1. SYS466 Casual Use Case Specifications

2. Systems Use Case Diagrams and Specifications Based on the dialog metaphor Based on the dialog metaphor The process of designing the overall sequences that users follow to interact with an information system The process of designing the overall sequences that users follow to interact with an information system The sequence in which information is displayed to and obtained from the user The sequence in which information is displayed to and obtained from the user

3. Sequence understanding how the user will interact with the system understanding how the user will interact with the system clear understanding of user, task, technological and environmental characteristics clear understanding of user, task, technological and environmental characteristics

4. Systems Use Case Diagram Place holder for the Systems Use Case Specification Place holder for the Systems Use Case Specification A visual index, providing a context for the Specifications A visual index, providing a context for the Specifications * Systems Use Cases Modeling by Bittner & Spence, Pages 153 - 154

5. Systems Use Case Specifications The (systems) use case specifications provide the substance of the (systems) use case model and they are the basis for most of the …modeling work…More than 90% of the (systems) use-case model lies beneath the surface, in the textual use-case specifications themselves. * The (systems) use case specifications provide the substance of the (systems) use case model and they are the basis for most of the …modeling work…More than 90% of the (systems) use-case model lies beneath the surface, in the textual use-case specifications themselves. * *Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 30

6. Systems Use Case Specifications “(Systems) use cases are more than just a named ellipse and a brief Specification. For each (systems) use case there will also be a (systems) use-case specification where the full story of the use case is told.”* “(Systems) use cases are more than just a named ellipse and a brief Specification. For each (systems) use case there will also be a (systems) use-case specification where the full story of the use case is told.”* * Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 30

7. Systems Use Case Specifications “The use case specification tells a story of how a system and its actors collaborate to achieve a specific goal “The use case specification tells a story of how a system and its actors collaborate to achieve a specific goal This collaboration takes the form of a dialog between the system and its actors This collaboration takes the form of a dialog between the system and its actors It is a step-by-step description of a particular way of using a system”* It is a step-by-step description of a particular way of using a system”* * Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 24

8. Systems Use Case Specification Not a complete specification of all possible ways that some task is performed Not a complete specification of all possible ways that some task is performed Does not say how the system is designed or implemented Does not say how the system is designed or implemented Describes typical ways (or scenarios) of using the system* Describes typical ways (or scenarios) of using the system* *Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, pp. 24-25

9. WIKPEDIA EXPLANATION OF USE CASES AND USE CASE SPECIFICATIONS An excellent explanation of use cases and use case specifications An excellent explanation of use cases and use case specificationsexplanation

10. Systems Use Case Specifications “Use cases are a good way to help keep it simple, and make it possible for domain experts or requirement donors to themselves write (or participate in writing) use cases.” “Use cases are a good way to help keep it simple, and make it possible for domain experts or requirement donors to themselves write (or participate in writing) use cases.” “Another value of use cases is that they emphasize the user goals and perspective; we ask the question "Who is using the system, what are their typical scenarios of use, and what are their goals?" This is a more user-centric emphasis compared to simply asking for a list of system features.” “Another value of use cases is that they emphasize the user goals and perspective; we ask the question "Who is using the system, what are their typical scenarios of use, and what are their goals?" This is a more user-centric emphasis compared to simply asking for a list of system features.” Larman, Chapter 6, 6.4

11. Systems Use Case Specifications The systems use case specification must include: The systems use case specification must include: Who the actors are and how many of them are interacting with the system at any point in time Who the actors are and how many of them are interacting with the system at any point in time What data is used and how What data is used and how All normal logic All normal logic

12. Essential UI-free style “In an essential writing style, the narrative is expressed at the level of the user's intentions and system's responsibilities rather than their concrete actions. They remain free of technology and mechanism details, especially those related to the UI. “ “In an essential writing style, the narrative is expressed at the level of the user's intentions and system's responsibilities rather than their concrete actions. They remain free of technology and mechanism details, especially those related to the UI. “ Larman, Chapter 6, 6.11

13. Essential UI-free style “Write use cases in an essential style; keep the user interface out and focus on actor intent.” “Write use cases in an essential style; keep the user interface out and focus on actor intent.” Larman, Chapter 6, 6.11

14. Black-Box Use Cases “Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities, which is a common unifying metaphorical theme in object-oriented thinking— software elements have responsibilities and collaborate with other elements that have responsibilities.” “Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities, which is a common unifying metaphorical theme in object-oriented thinking— software elements have responsibilities and collaborate with other elements that have responsibilities.” Larman, Chapter 6, 6.13

15. Black-Box Use Cases “By defining system responsibilities with black-box use cases, one can specify what the system must do (the behavior or functional requirements) without deciding how it will do it (the design). Indeed, the definition of "analysis" versus "design" is sometimes summarized as "what" versus "how." This is an important theme in good software development: During requirements analysis avoid making "how" decisions, and specify the external behavior for the system, as a black box. Later, during design, create a solution that meets the specification.” “By defining system responsibilities with black-box use cases, one can specify what the system must do (the behavior or functional requirements) without deciding how it will do it (the design). Indeed, the definition of "analysis" versus "design" is sometimes summarized as "what" versus "how." This is an important theme in good software development: During requirements analysis avoid making "how" decisions, and specify the external behavior for the system, as a black box. Later, during design, create a solution that meets the specification.” Larman, Chapter 6, 6.13

16. Black-Box Style NOT The system records the sale. The system writes the sale to the database. Even worse: The system generates a SQL INSERT statement for the sale… Larman, Chapter 6, 6.13

17. The Use Case Specification One of the best checks of whether a use case specification is finished is to ask if you could use the use case to derive system tests. One of the best checks of whether a use case specification is finished is to ask if you could use the use case to derive system tests. The best way to tell if the use cases fit the purpose is to pass them along to the…test team for test design. The best way to tell if the use cases fit the purpose is to pass them along to the…test team for test design. If the team is satisfied that they can use the use cases to support this activity, then the use case specifications contain sufficient levels of detail. If the team is satisfied that they can use the use cases to support this activity, then the use case specifications contain sufficient levels of detail.