Capturing the Requirements as Use Cases (continued)
Workflow
 Of what does a use-case model consist?
 Use-case diagram(s)
 Survey description of the whole model
 Detailed descriptions of individual use cases
4. Activity: Prototype user interface
 The input and result of prototyping the user interface
Use-case
model
Userinterface
designer
UserInterface
Prototype
Supplementary
Requirements
Use case
[described]
Prototype
user
interface
Glossary
 Steps
(1) Logical user-interface design
 For each use case, what input/output data/ information that each
actor needs to interact with the system
(2) Physical user-interface design
 Illustrate how the actors can use the system through its user
interface to perform the use case
(3) Prototyping user interface
 Create a prototype (G)UI according to the physical design
a) Creating a logical user-interface design
 Strategy
 For each actor, identify user-interface elements to which the actor
will access in the system, from all use cases that the actor will use.
 Design how the actor can use and manipulate the user-interface
elements.
 What is a user-interface element
 A (business) entity in the system which or whose attribute(s) will be
accessed by an actor.
 An entity is usually modeled as a class in the system.
 A user-interface element may participate in more than one use case.
 Example: User-interface elements employed in the Pay Invoice use case
b) Creating a physical user-interface design
(1) Sketch the constellation of user interface elements
(2) Sketch the graphical user interface by visually combining or
grouping user-interface elements into containers in a user-friendly
way.
c) Building an executable user interface prototype
 Strategy
Using a rapid prototyping tool to build a prototype user interface for
each actor.
 Review prototypes to validate the user interface
 What to look for
 User navigation
 Consistent look and feel and usability
 Compile with relevant standards
5. Activity: Structure the use-case model
 What to do
 Generalization relationship between use cases
Identify and extract general and common use case descriptions of
functionality that can be used by more specific use case descriptions.
 Extend relationship between use cases
Identify and extract optional use case descriptions of functionality
that can extend more specific use case descriptions.
 Include relationship between use cases
Identify and extract sub-use case descriptions of functionality that
can be used by more specific use case descriptions.
 The input and result of structuring the use-case model
Use-case
model
[outlined]
System
Analyst
Use-case
model
[structured]
Supplementary
Requirements
Use case
[described]
Structure
the usecase model
Glossary
a) Identifying general descriptions of functionality
 A generalization (super) user case describes common functionality of
concrete use cases.
 A generalization use case is an abstract use case without instances.
 A concrete use case inherits the functionality of the generalization
use case.
 Instances of a concrete use case can perform all behavior described in
the generalization use case
 An actor can only interact with a concrete or “real” use case.
 A generalization relationship is a use relationship, i.e. the concrete
use case uses the behavior of the generalization use case.
 Example:
 Generalization between use cases
Buyer
Pay Invoice
Seller
Perform Transaction
 Real use case
Buyer A
Pay Invoice + Perform Transaction
Seller B
b) Identifying additional and optional descriptions of functionality
 An extension use case behaves as if it is added to the original
description of target or extended use case
 An extension use case is subject to
 An extension point described in the flow of events of its target use
case, and
 A condition for extension also described in the flow of events of its
target use case.
 An extension use case is to be performed at the extension point in a
use case instance, if the condition is satisfied at the extension point.
 Example
 Extend relationship between use cases
Pay Invoice
Buyer
Seller
<<extend>>
Perform Transaction
Pay Overdraft Fee
 Real use cases
Buyer A
Pay Invoice + Perform Transaction
+ Pay Overdraft Fee
Seller B
c) Identifying sub-descriptions of functionality
 An included use case provides an explicit and unconditional
extension to a use case at an extension point.
 The behavior of an included use case is part or sub-behavior of the
overall behavior of the including use case, but relatively independent
to other part.
 The behavior of an included use case can be shared by two or more
use cases.
 The behavior sequence and the attributes of the included use case are
encapsulated.
 Example
 Include relationship between use cases
Check Buyer ID
<<include>>
Pay Invoice
Buyer
Seller
<<extend>>
Perform Transaction
Pay Overdraft Fee
 Real use cases
Buyer A
Check Buyer ID + Pay Invoice + Perform Transaction + Pay Overdraft Fee
Seller B
 Guidelines for structuring use cases
 The structure of the use cases and their relationships should reflect
the real use cases.
 Each single use case needs to be treated as a separate artifact
 Avoid decomposing the use cases functionality in the use-case model.