This document provides guidance on completing an Application Use Case (AUC) template. It describes the typical sections of an AUC document, including the introduction, use case details, performance requirements, supplementary requirements, and interface requirements. It explains how to identify basic flows, alternative flows, and extension points within a use case. The document demonstrates how to apply styles, insert diagrams, and use cross-referencing to link related requirements and flows. Completing the template correctly involves identifying actors, preconditions, steps, and constraints for a use case and representing these following the guidelines in the presentation.

1. 2009 copyright Leslie Munday University
Guide To An AUC Document Template
Requirements Discipline
23 February 2010

2. 10/28/2019 2
Precursor
 In order to understand the material in this
course, you should have knowledge of use case
modeling and the material in the following:
 Working With Styles and Properties,
 An introduction to RequisitePro.
 Terms used in this presentation:
 System – the hardware under which an application
executes. Includes the user interface (monitor,
keyboard, etc) and communication ports to other
systems (network, USB, printer, etc)
 Application – the software within the system that
satisfies the requirements for the system.

3. 10/28/2019 3
Overview
 In this presentation you will learn:
 the purpose of the different sections of the
AUC document,
 the information that goes into each
section,
 How to fill out an AUC document template.
 This lesson will end with a Q & A
session.

4. 10/28/2019 4
The sections of the AUC Document
 The AUC document captures a single application use
case for a single application.
 It’s sections are:
1 Introduction
2 Use Case Details
3 Use Case Performance Requirements
4 Use Case Supplementary Requirements
5 Interface Requirements
 The guidelines in this presentation can be adjusted for
whatever requirements management tool you use.
 [The template that comes with this presentation is designed
to be imported into RequisitePro.]

5. 10/28/2019 5
Introduction
 This section contains introductory text for the
AUC:
 Purpose – The purpose of the AUC document (this is
standard text where only the name of the document
changes),
 Audience – Who this document is written for (may
change from project to project),
 Scope – What are the limitations of the use case,
 Definitions, Acronyms, and Abbreviations – Any terms
specific to this AUC,
 Goals – A high level description of what this use case is
trying to achieve.

6. 10/28/2019 6
Use Case Detail
 This section contains the use case details:
 Description – a description of the details of the use case,
 Usage – the maximum frequency that the use case is expected to
execute,
 Primary Actor - the initiator of the use case,
 Secondary Actors - any roles or systems used by the use case,
 Precondition(s) - what state the system must be in before the use case
executes,
 Successful PostCondition –is the state the system is in after the use case
has ended,
 Alternative Postconditions – other possible states that could cause the
use case to end,
 Basic Flow – the expected externally visible steps of the use case,
 Alternate Flows - externally visible steps that deviate from and return to
the basic flow,
 Extension Points - externally visible steps that describe a path that
extends from the basic flow, never to return,
 Activity Diagram - a pictorial view of the use case steps.

7. 10/28/2019 7
Supplementary Requirements
 A location for requirements that impact this
use case. Supplementary requirements are
generally located in their own repository and
referenced from this section. The
supplementary requirement references the
steps that it impacts.
 Supplementary requirements may be of type:
Usability, Reliability, Performance, Supportability, Design Constraint,
Accessibility, Globalization, Availability, Installability, Serviceability
(Maintainability), Security, (Vulnerability), User Documentation,
Consumeability (Migration), Integration, Software
Reuse/Componentization, Purchased Components, Interfaces,
Licensing Requirements, Legal/Copyright/Other Notices, Applicable
Standards, To be determined.

8. Performance Requirements
 These are a special type of supplementary
requirement.
 They are put into their own section to
emphasize that a use case has a need to
perform within a certain time.
 Every time the system performs an action
it has a maximum amount of time to
complete that action.
 Every system action step in the use case
should be referenced, (by implication or
explicitly) in this section.
10/28/2019 8

9. Interface Requirements
 Where the use case interfaces with
another application a reference is made
to the appropriate standards for using
that interface.
 The interface is specified in a separate
document, because it is applicable to 2
or more applications and we do not
want to duplicate information.
10/28/2019 9

10. 10/28/2019 10
A Use Case Is Black Box
 An ‘externally visible step’ is an action that can be observed
from a ‘black box’ perspective.
 A black box observation is an event that can be detected
without opening up the system.
 All black box events are witnessed by the actors of the use
case.
 All black box events are tested at the interfaces to the
application.
 Example: ‘The system verifies that the password is correct’
would not be a black box event, because we cannot test this
when the password is correct, without opening the application.
 Example: ‘The password is invalid and the system returns a
password in error message’, is a black box event because we
entered an invalid password through the user interface and got
the error message back through the user interface.
 When writing a step, ask yourself the question: ‘How would I
test this?’

11. Creating the Use Case Document
 Add the AUC document template to the
templates that are recognized by MS Word.
 Working in MS Word create a new AUC
document.
 Complete the properties for the AUC document.
 Complete the introductory sections.
 Once the scope and overview have been agreed
upon, start to detail the steps of the basic flow.
 Once the basic flow has been agreed upon,
search for alternative and extension paths.
 Parse the use case steps to add supplementary
requirements.
10/28/2019 11

12. Example Introductory Section
10/28/2019 12

13. Create The Use Case
 Complete section 2.
 Add a use case diagram, showing the actors.
10/28/2019 13

14. Use Case Information
10/28/2019 14

15. Inserting Use Case Steps
 Add use case steps as normal text.
 Apply the 'Use Case Step‘ style to each line
of the use case flow.
 This will cause the steps to be automatically
numbered and become blue-underlined.
 In order to show 2 or more actions
occurring in parallel, add them as bullet
points to a use case step and set their style
to ‘Use Case Bullet’.
10/28/2019 15

16. 10/28/2019 16
Inserting The Use Case Steps

17. 10/28/2019 17
Alternate And Extension Flows
 Once the Basic Flow is complete we start to look for
alternate and extension flows.
 Entering Steps For Alternate And Extension Flows:
 Enter alternate flow headings and apply the 'Alternate Flow‘ style
to them.
 Enter extension flow headings and apply the Extension Flow‘ style
to them.
 Enter each alternate and extension flow step and apply the ‘Use
Case Step‘ style.
 For each alternate/extension flow make reference to the step(s)
that it comes from in the use case Basic Flow, by using the
'Insert->Reference->Cross Reference' command to reference the
step number.
 Similarly when an alternate flow returns to the basic flow, use
Word’s ‘Cross-Reference’ feature to enter the step that is returned
to.

18. 10/28/2019 18
Enter Alternate/Extension Flow Steps
 Alternate and extension flows without
references to the basic flow.

19. 10/28/2019 19
References Within Use Case Steps
 Using the Word
command, ‘Insert-
>Reference->Cross
Reference’, select the
Numbered Item’
Reference Type, Insert
Reference To
‘Paragraph Number’ an
make sure that ‘Insert
As HyperLink’ is ticked.

20. Alternate Flows With Reference
 Once all references to use case steps have been
inserted, you may navigate between flow references
using the ‘Control/Click’ function of Word.
10/28/2019 20

21. Renumbering the steps
 Suppose (as it will happen) that a new step is inserted or an existing
step is taken out of scope.
 Simply add or remove the step(s), select all text and press F9.
 All steps and cross-references are automatically updated with the
correct numbers.
 (two new lines have been inserted.)
10/28/2019 21

22. The Updated Cross-References
10/28/2019 22
 The cross-references have been replaced
with the updated basic flow step #s.

23. 10/28/2019 23
Demo
 Create a use case document from the AUC
template.
 Select the correct styles for each section of
the document.
 Add cross-references to the use case steps.
 Renumber steps in the use case by adding
and removing steps in the basic flow and the
alternate flows.
 Ctrl-A + F9 to update fields.

24. Importing Diagrams
 There are 2 locations for diagrams in the
document;
 the details description includes a use case
diagram.
 an activity diagram is located after the details of
the steps.
 If feasible add diagrams to the document as
linked objects, otherwise copy and paste, and
set their style to ‘figure’.
 Enter a ‘return’ character after the diagram and
the next line is automatically set to style ‘figure
label text’. Add a diagram name to this line of
text.
10/28/2019 24

25. Example Activity Diagram
10/28/2019 25

26. Example Activity Diagram
10/28/2019 26
 The figure is automatically numbered.

27. 10/28/2019 27
Use Case Supplementary Requirements
 Sections 3 contains supplementary requirements that
impact this use case.
 These requirements are captured here during development
of the use vase, but will ultimately reside in a
supplementary requirements repository.
 Supplementary requirements reference the use case step
#(s) to which they apply.
 For each step in the completed use case, identify any
additional restrictions upon that step. Add each restrictions
as a supplementary requirement and use the cross-
reference feature the reference the steps that the
supplementary requirement impacts.
 Set the style for each supplementary requirement to be
‘Supplementary Requirement’.

28. Performance And Interface
 Determine a common response time for each
interface to the use case. Document this as a
supplementary timing requirement.
 For each step in the use case, identify any
unusual performance requirements for that
step. Document each performance requirement
in section 3.1, referencing the step that it
impacts.
 For each interface to another application,
create an interface requirement in section 3.2
and reference where this interface is
documented.
10/28/2019 28

29. Example Supplementary Reqmts
10/28/2019 29

30. The AUC Template
 This document contains ‘template text’ in blue italics. This
text may be removed at any time during the creation of
the use case document.
 The text contains useful instructions for completing the
template, along with examples of the different sections.
 Prior to publishing the AUC, all template text should be
removed from the document.
 All properties in the document (including the TOC) should
be updated to reflect the current state of the document.
 Finally, make sure that no rogue styles have been
attached to the document. Ensure that all contents are of
a valid style and delete any styles that do not belong,
from the styles pane.
10/28/2019 30

31. Demo A Complete AUC Document
 Include:
 Use case and activity diagrams,
 Supplementary requirements,
 Performance requirements,
 Interface requirements,
 Updated table of contents,
 Styles pane.
10/28/2019 31

32. 10/28/2019 32
Summary
 In this presentation you learned:
 the purpose of the different sections of the
AUC document.
 the information that goes into each
section.
 when to use the AUC document.

33. 10/28/2019 33
Test Your Knowledge
 How many use cases are there in an application use case
document?
 How do we identify the primary actor?
 Can systems be secondary actors?
 What do we call a constraint on the state of the
application before the use case may execute?
 If an actor is entering data into the application and has
to stop (end the use case) because there is missing
information, is this documented under an alternative or
extension flow?
 Open the AUC document style guide and change the
example AUC in the document into a true use case with
the correct styles and references applied.