Scribd
Upload
314 views

XXX Use Case Document XXX: Description Changed by Date

The document provides a template for writing use case documents with sections for description, prerequisites, business trigger, basic flow, alternate flows, sub-flows, business rules, activity diagrams, and prototypes. It includes guidance for what information should be included in each section.

Uploaded by

Banhi
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
314 views

XXX Use Case Document XXX: Description Changed by Date

The document provides a template for writing use case documents with sections for description, prerequisites, business trigger, basic flow, alternate flows, sub-flows, business rules, activity diagrams, and prototypes. It includes guidance for what information should be included in each section.

Uploaded by

Banhi
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

XXX < the system name> Use Case Document

XXX <the name of the use case starting with an active verb and indicating the successful outcome of
value to the actor. Avoid naming use cases with partial outcomes. These use cases tend to be incomplete.
Ask if you would leave the system the way it is and walk away>
<Template instructions: Text in this style should be removed. Text in Normal style should be replaced. After
using the template for some time you might remove some of the sections if they are unused, or adapt it more
closely to suit the general style in use within your company. Copyright in this template remains with CRaG
Systems>

<The change log should be updated for every significant change made to the document. Use the format n.m
for the version number>

Version Description Changed By Date


1.0 First draft Fred Bloggs 1/1/00

1. Brief Description: XXX <2 to 3 sentences describing the use case>


2. Preconditions: XXX <the stable state(s) that the system must be in for the use case to start>
3. Business Trigger: XXX < the business event that causes the first interaction>
4. Basic Flow:
5. xxxx xxx xxxxx <a line in the use case normally describing an interaction across the system boundary
(‘black box’ view), but possibly describing gross internal functionality (‘white box’ view). Keep the level of
abstraction as high as possible while still providing sufficient information to describe what is done. Avoid
referring to the technology of the interface if possible and describe what information or command is
passed. Write complete sentences including source (noun), action (verb), optional parameters (nouns),
possibly with actual values and target (noun). Avoid concatenating sentences with commas and ‘ands’>
6. xxxx xxx xxxxx <further lines as above. Try to keep them in pairs or 1 in to n out. Don’t include things
that happen outside the system but don’t cross the system boundary>
7. xxxx xxx xxxxx <if there is a large time gap between interactions, consider separating the temporally
cohesive sections into separate use cases >
8. xxxx xxx xxxxx <continue until the outcome described by the name of the use case has been fulfilled.
The last step should be one going out, probably back to the primary actor indicating that the use case is
complete>
9. Post Condition: XXX <the state of the system at the end of the basic flow, or things guaranteed
to be true at the end of a successful use case>
10. Alternate Flow: XXXX <name of the alternate flow starting with an active verb>
11. When in XXX <insert the number of the line in which the condition occurs>
12. xxxx xxxx xxxx, then: <define the condition under which the alternate flow is executed e.g. ‘the item
number entered is found to be invalid’>
13. xxx xx xxxxx <write the lines just as you would in the basic course, describing what happens largely as
interactions across the boundary adding further lines as necessary>
14. xxx xx xxxxx <the last line must describe what happens next: the use case terminates; the use case
restarts where it left off; the use case jumps back and restarts at an earlier step; the use case jumps
forward and restarts at later step>
15. Post Conditions: XXXX <you might wish to describe post-conditions for an alternate flow where they
differ from those of the basic flow>
16. Alternate Flow: XXXX <add the names of further alternate flows as you think of them. Add the detail of
the alternate flow after the basic flow has been detailed. It is possible to have extensions on the
extensions. Write them exactly the same way as other extensions>

Author: <the author’s name> Page 1 of 2 Printed:


XXX < the system name> Use Case Document
XXX <the name of the use case starting with an active verb and indicating the successful outcome of
value to the actor. Avoid naming use cases with partial outcomes. These use cases tend to be incomplete.
Ask if you would leave the system the way it is and walk away>
17. Sub-Flow: XXX <where there is procedure that is common to more than one flow in the use case, or
where there are different flows following a case statement or selection statement, create sub-flows and
‘call’ them from the using flow. Name the sub-flows starting with an active verb>
18. xxxx xxxx xxxx <write the lines of the sub-flow just as you would in the basic course, describing what
happens largely as interactions across the boundary. Add further lines as necessary>
19. Sub-Flow: XXX <add further sub-flows as necessary>
20. Business Rules:
21. xxxx <include here a description of detailed internal algorithms or procedures that are not part of the
externally visible behaviour, but are vital to the functional definition of the system >
22. xxxx <or specify data structures or constraints or technology requirements that are specific to the use
case and have no place in the procedural part of the use case >
23. Activity Diagram:
24. <if there is complex iteration and selection, include an activity diagram, or a reference/hyperlink to one
here. Activity diagrams should not duplicate or replace the text of the flows but augment it where prose is
difficult to use to describe complex conditionality >
25. Prototype Screen:
26. <if you have a prototype screen for this use case, include it or a reference/hyperlink to it here. If might be
at proof of concept or detailed level depending on the importance of the screen design to the user. Make
sure the text of the use case is consistent with the prototype >

Author: <the author’s name> Page 2 of 2 Printed:

You might also like