StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Use case analysis is deceptively simple, but this question betrays some of the inherent complexity.</p> <p>Each use case must be meaningful to the actors involved, in the sense that it must represent a well-defined interaction with the system. Each actor and use case must also make sense when you talk about the system, even using everyday language. If you find yourself in difficulty defining either actors or use cases, then probably the system context is unclear and so a domain model might help.</p> <p>A use case must represent a well-defined interaction, but not necessarily a <em>complete</em> one. The <code><<include>></code> relationship can be used in situations where it makes sense to see both full- and partial-interaction use cases at the same level. You might consider having a use case <code>buy stuff</code> include <code>browse products</code>, <code>add product to cart</code> and <code>check out <<xor>> cancel</code>, for instance, each of which makes sense to the customer.</p> <p>(I am a little bit confused about whether your system is intended for physical or on-line transactions; having a till and printed receipts seems to imply the former, a shopping cart as part of the concepts used in the analysis the latter. The above assumes an on-line system.)</p> <p>In your case, however, you are talking about actors which may be considered part of the system itself. This usually means that you are trying to define the system and its subsystems at the same time, which is common in situations where you have a good idea of the (eventual) system design before you start the analysis.</p> <p>What you want to do then is to split the analysis into two levels. At the upper (system) level, be very strict about treating the system as a whole. In your case, you'd probably need the actors <code>customer</code>, <code>payment partner</code>, <code>clerk</code> (for a physical-transaction system), <code>accountant</code> (and maybe <code>administrator</code>), and use cases as listed above plus <code>update product catalogue</code>, <code>audit sales log</code>, etc.</p> <p>Then you break the system down into subsystems and do a separate analysis for each of them. Here the subsystems can be actors in each others' use cases. <code>Print receipt</code>, for instance, is not a meaningful use case on the system level because it is not in itself an interaction between the system as a whole and a system-level actor, but it is meaningful as a use case for the printer subsystem, with the till as the actor.</p> <p>You do not need to complete the system-level analysis before you start the subsystem breakdown, in fact I think it's better to have them both active at the same time - although this places higher requirements on you the analyst / designer to be able to switch contexts quickly and be disciplined about which context you're working in at any given time.</p> <p>So, after all that (phew!) I think the answer to your questions are:</p> <ol> <li>Both, provided each use case makes sense to its actors as a well-defined (but not necessarily complete) interaction with the system.</li> <li>Yes, but not at the same level; with one model for the system and separate models for each subsystem you can use the subsystems as actors in each others' use cases.</li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload