sys466 casual use case specifications. systems use case diagrams and specifications based on the...

SYS466

Casual Use Case Specifications

Systems Use Case Diagrams Systems Use Case Diagrams and Specificationsand Specifications

Based on the dialog metaphorBased on the dialog metaphor The process of designing the overall The process of designing the overall

sequences that users follow to interact sequences that users follow to interact with an information system with an information system

The sequence in which information is The sequence in which information is displayed to and obtained from the userdisplayed to and obtained from the user

SequenceSequence

understanding how the user will understanding how the user will interact with the systeminteract with the system clear understanding of user, task, clear understanding of user, task,

technological and environmental technological and environmental characteristicscharacteristics

Systems Use Case Systems Use Case DiagramDiagram

Place holder for the Systems Use Place holder for the Systems Use Case SpecificationCase Specification

A visual index, providing a context A visual index, providing a context for the Specificationsfor the Specifications

**Systems Use Cases Modeling Systems Use Cases Modeling by Bittner & Spence, Pages 153 - 154 by Bittner & Spence, Pages 153 - 154

Systems Use Case Systems Use Case SpecificationsSpecifications

The (systems) use case specifications The (systems) use case specifications provide the substance of the provide the substance of the (systems) use case model and they (systems) use case model and they are the basis for most of the …are the basis for most of the …modeling work…More than 90% of modeling work…More than 90% of the (systems) use-case model lies the (systems) use-case model lies beneath the surface, in the textual beneath the surface, in the textual use-case specifications themselves. *use-case specifications themselves. *

*Use Case Modeling*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, , Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 30p. 30


““(Systems) use cases are more than just a named (Systems) use cases are more than just a named ellipse and a brief Specification. For each ellipse and a brief Specification. For each (systems) use case there will also be a (systems) (systems) use case there will also be a (systems) use-case specification where the full story of the use-case specification where the full story of the use case is told.”*use case is told.”*

**Use Case ModelingUse Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, , Kurt Bittner & Ian Spence, Addison-Wesley, 2003, 2003,

p. 30p. 30


““The use case specification tells a The use case specification tells a story of how a system and its actors story of how a system and its actors collaborate to achieve a specific goalcollaborate to achieve a specific goal

This collaboration takes the form of a This collaboration takes the form of a dialog between the system and its dialog between the system and its actorsactors

It is a step-by-step description of a It is a step-by-step description of a particular way of using a system”*particular way of using a system”*

**Use Case ModelingUse Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, , Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 242003, p. 24

Systems Use Case Systems Use Case SpecificationSpecification

Not a complete specification of all Not a complete specification of all possible ways that some task is possible ways that some task is performedperformed

Does not say how the system is Does not say how the system is designed or implementeddesigned or implemented

Describes typical ways (or Describes typical ways (or scenarios) of using the system*scenarios) of using the system*

*Use Case Modeling*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, , Kurt Bittner & Ian Spence, Addison-Wesley, 2003, pp. 24-252003, pp. 24-25

WIKPEDIA EXPLANATION OF USE WIKPEDIA EXPLANATION OF USE CASES AND USE CASE CASES AND USE CASE

SPECIFICATIONSSPECIFICATIONS An excellent An excellent explanation of use of use

cases and use case specificationscases and use case specifications


““Use cases are a good way to help keep it simple, and Use cases are a good way to help keep it simple, and make it possible for domain experts or requirement make it possible for domain experts or requirement donors to themselves write (or participate in writing) donors to themselves write (or participate in writing) use cases.”use cases.”

““Another value of use cases is that they emphasize the Another value of use cases is that they emphasize the user goals and perspective; we ask the question "Who user goals and perspective; we ask the question "Who is using the system, what are their typical scenarios of is using the system, what are their typical scenarios of use, and what are their goals?" This is a more user-use, and what are their goals?" This is a more user-centric emphasis compared to simply asking for a list of centric emphasis compared to simply asking for a list of system features.”system features.”

Larman, Chapter 6, 6.4Larman, Chapter 6, 6.4


The systems use case specification The systems use case specification must include:must include:

Who the actors are and how many of Who the actors are and how many of them are interacting with the system them are interacting with the system at any point in timeat any point in time

What data is used and howWhat data is used and how All normal logicAll normal logic

Essential UI-free styleEssential UI-free style

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


Essential UI-free styleEssential UI-free style

““Write use cases in an essential Write use cases in an essential style; keep the user interface out style; keep the user interface out and focus on actor intent.”and focus on actor intent.”


Black-Box Use CasesBlack-Box Use Cases

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

Black-Box Use CasesBlack-Box Use Cases ““By defining system responsibilities with By defining system responsibilities with

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

Larman, Chapter 6, 6.13

Black-Box StyleBlack-Box Style

Black-Box StyleBlack-Box Style NOTNOT

The system records The system records the sale.the sale.

The system writes The system writes the sale to the the sale to the database.database.

Even worseEven worse::

The system The system generates a SQL generates a SQL INSERT statement INSERT statement for the sale… for the sale…

Larman, Chapter 6, 6.13

The Use Case The Use Case SpecificationSpecification

One of the best checks of whether a use case One of the best checks of whether a use case specification is finished is to ask if you could specification is finished is to ask if you could use the use case to derive system tests.use the use case to derive system tests.

The best way to tell if the use cases fit the The best way to tell if the use cases fit the purpose is to pass them along to the…test purpose is to pass them along to the…test team for test design.team for test design.

If the team is satisfied that they can use the If the team is satisfied that they can use the use cases to support this activity, then the use use cases to support this activity, then the use case specifications contain sufficient levels of case specifications contain sufficient levels of detail.detail.

sys466 casual use case specifications. systems use case diagrams and specifications based on the...

Documents