Page 135 - Software and Systems Requirements Engineering in Practice
P. 135
103
i
u
e
r
q
e
t
r
m
o
d
M
e
n
e
s
t
p
n
:
4
g
C h a p t e r 4 : R e q u i r e m e n t s M o d e l i n g 103
e
R
i
l
C
h
a
Symbol Hyperlink To Rationale
Abstract use case Use case An abstract use case is a
representing a set diagram placeholder for a product feature
of functions or concept and does not have
logic. It is the included use cases
that would have concrete logic.
Abstract use case Use case Abstract use cases and product
representing a diagram features may need to be
product feature decomposed several levels before
concrete, testable features or
use cases are reached. In order
to keep the diagrams simple, it is
necessary to be able to hyperlink
use case diagrams that continue
the hierarchy.
Concrete use case Use case Use cases with many ancillary
diagram processes may need to be
decomposed several levels.
The ability to put only one level
of decomposition on a diagram
reduces clutter and makes the
model more manageable.
Concrete use case Activity When a use case is concrete
diagram (e.g., testable), there may be
many possible paths. While
scenario diagrams are good for
showing one path, the best way
to see all the possible outcomes
or variations is to use an activity
diagram as an overview, showing,
in simplified fashion, all possible
paths that the process may take.
Concrete use case Sequence A use case is a process. One
diagram specific thread (e.g., a success
mode or a failure mode) is best
shown on one diagram for clarity.
Concrete use case Activity When a process is primarily
diagram sequential logic (e.g., an algorithm
or computation) activity diagrams
do a much better job of presenting
the logic than sequence diagrams,
showing activities, inputs, and
outputs.
TABLE 4.1 Example Hyperlinks