Shows the reader how to complete a MS Word document that captures a use case. It also shows how to import requirements into the document from ReqPro.

1. Working With AUC Documents
Requirements Discipline
11 February 2010

2. 2/11/2010
Precursor
●In order to understand the material in this
course, you should have knowledge of use
case modeling and the material in the
following:
oWorking With Styles and Properties,
oAn introduction to RequisitePro.

3. 2/11/2010
Overview
●In this presentation you will learn:
othe purpose of the different sections of the AUC
document,
othe information that goes into each section,
owhen to use an AUC document template,
oworking with AUCs and RequisitePro,
ohow to review an AUC.
●This lesson ends with a Q & A session.

4. 2/11/2010
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 template that comes with this presentation is
designed to be imported into RequisitePro.
●The guidelines in this presentation can be adjusted for
whatever requirements management tool you use.

5. 2/11/2010
Introduction
●This section contains introductory text for the
AUC:
oPurpose – The purpose of the AUC document (this is
standard text where only the name of the document
changes),
oAudience – Who this document is written for (may
change from project to project),
oScope – What is in this document,
oDefinitions, Acronyms, and Abbreviations – Any terms
specific to this AUC,
oOverview – A high level description of what this use
case is trying to achieve.

6. 2/11/2010
Use Case Detail
●This section contains the use case details:
oDescription – an overview of the details of the use case,
oUsage – the maximum frequency that the use case is expected to execute,
oPrimary Actor - the initiator of the use case,
oSecondary Actors - any roles or systems used by the use case,
oPrecondition - what state the application must be in before the use case executes,
oPostCondition - the state the system is expected to be in after the use case has
ended successfully,
oAlternative Postconditions – other possible states that could end the use case,
oBasic Flow - the externally visible steps of the use case that are expected to occur
and terminate at the expected postcondition ,
oAlternate Flows - externally visible steps that deviate from and return to the basic
flow,
oExtension Points - externally visible steps that describe a path that extends from
the basic flow and terminate at an alternative postcondition,
oInteraction Diagram - a pictorial view of the use case.

7. Performance Requirements
●These are a special type of supplementary
requirement.
●They are put into their own section because
every use case has implied performance
requirements.
●Everytime 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 in this section.
2/11/2010

8. 2/11/2010
Supplementary Requirements
●A location for requirements that impact this use
case, used to maintain traceability between the
use case steps and the supplementary
requirements.
oSupplementary 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.

9. Interface Requirements
●Where the use case interfaces with another actor,
reference the appropriate standards for developing that
interface and optional add a hyperlink to that document.
●The reference may be to an industry standard, company
standard or a 'to be developed' interface document.
●The interface is specified in a separate document,
because it is applicable to 2 or more use cases and we
do not want to duplicate information.
●Interface requirements are not captured within ReqPro.
2/11/2010

10. 2/11/2010
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 application.
●All black box events are witnessed by the actors of the application.
●All black box events are tested at the interfaces to the application.
●Example: ‘The system verifies that the password is correct’ is NOT
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.
●Create a new AUC document in MS Word.
●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.
2/11/2010

12. Example Introductory Section
2/11/2010

13. Create The Use Case
●Complete section 2.
●Add a use case diagram,
showing the actors.
●Set the style of the text
in the description field to
be ‘Use Case’.
●The description will
become the parent use
case.
2/11/2010

14. 2/11/2010
Numbering The Steps
●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, as they appear when selected as requirements in
ReqPro.

15. 2/11/2010
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:
oEnter alternate flow headings and apply the 'Alternate Flow‘ style to
them.
oEnter extension flow headings and apply the Extension Flow‘ style to
them.
oEnter each alternate and extension flow step and apply the ‘Use Case
Step‘ style.
oFor 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.
oSimilarly when an alternate flow returns to the basic flow, use Word’s
‘Cross-Reference’ feature to enter the step that is returned to.

16. 2/11/2010
Enter Alternate/Extension Flow Steps
●Alternate and extension flows without
references to the basic flow.

17. 2/11/2010
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.
●Once all references to use case
steps have been inserted, you
may navigate between flow
references using the
‘Control/Click’ function of Word.

18. 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.)
2/11/2010

19. The Updated Cross-References
2/11/2010

20. 2/11/2010
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.

21. 2/11/2010
Use Case Supplementary Requirements
●Sections 3 and 4 contain supplementary requirements that
impact this use case.
●These requirements are captured here, but may ultimately
reside in the supplementary requirements folder of
ReqPro.
●All supplementary requirements are captured here during
the development of the use case.
●Supplementary requirements reference the use case
step(s) to which they apply; note that capturing and
identifying the supplementary requirements in the use
case document as it's being developed helps to ensure
that they are traced to the use case steps.

22. 2/11/2010
Capturing Supplementary Requirements
●As you detail a step of the use case recognize
impacting supplementary requirements.
●Document these in the AUC document, under
Performance and Supplementary
Requirements, and reference the step(s) that
they impact, using cross-references.
●Set the style for each supplementary
requirement to be ‘Supplementary
Requirement’.

23. Example Supplementary Reqmts
●Each performance requirement references a ‘Step #’ where
# is a cross-reference to the impacted step in the AUC.
●Other supplementary requirements do not reference a step
#, and therefore apply to all steps in the use case.

24. 2/11/2010
Importing An AUC Document
●The reason for the ‘use case’, ‘use case step’ and
‘supplementary requirement’ styles are that they
allow us to automatically create requirements in
ReqPro.
●When the AUC Document is imported, (see also
Working With Requirements In ReqPro), we tell
ReqPro to make every line of style ‘use case’, ‘use
case step’ or ‘supplementary requirement’ into a
requirement.

25. 2/11/2010
Importing AUC Document
●Import existing AUC
documents into the
ReqPro project by
selecting the folder to
contain the document
and entering the ‘File-
>Import’ command.

26. Import An AUC Document
●Browse to select the existing document from
your desktop.
●Select the ‘Microsoft Word Document’ option
2/11/2010

27. Import Document And Requirements
●We import the document because we will be
working on the AUC from within ReqPro from now
on.
●The desktop version of the document is obsolete.
2/11/2010

28. Document Properties
●Enter the document
properties:
odocument name,
oA description of the
contents of the
document,
othe folder where it will
reside,
oWhere the document
can be found on your
desktop,
oThe document type.
2/11/2010
Press ok, and when prompted to
retain the document formatting,
select ‘Yes’.

29. 2/11/2010
The ReqPro Import Wizard
●Note that the ‘use case’, ‘use case step’ and supplementary requirement’
styles have been added to the list of styles that signify a requirement.
●Both the use case and use case step styles have been assigned to use
case requirement types.

30. Confirming The Import
●When prompted to make a requirement, select ‘Yes
To All’.
●When prompted to commit the requirements, verify
that they are correct and select ‘Commit’.
2/11/2010

31. Organize The Requirements
●The document and
requirements are imported
to the selected folder.
●The AUC steps are made
children of the parent AUC
by selecting the steps and
executing a ‘Change
Parent’ command.
2/11/2010

32. Find Supplementary Requirements
●When the AUC is imported to RequisitePro, determine if the
supplementary requirement is already captured elsewhere.
●Below we see a view that displays all supplementary requirements
categorized as ‘Performance’.
●Notice that the ‘Opening Door’ and ‘Close Door’ requirements have
already been captured elsewhere.
●If it exists, make sure the original is traced to the use case step(s) that it
impacts and delete the imported supplementary requirement.
●If the requirement does not reference any steps, trace it to the whole use
case.
2/11/2010

33. 2/11/2010
Move Supplementary Requirements
● Once a supplementary requirement traces to 2 different use cases, it is moved to the
ReqPro database.
● Locate the supplementary requirement using the ‘Go To’ command. (If the ‘go To’
command is not available then the requirement is already in the database.)
● When the use case document opens, execute a ‘RequisitePro->Requirement->Cut’
command, and the requirement is removed from the document.
● Open a supplementary requirements view and execute ‘Edit->Paste’ to move the
requirement to the view.
● Remove the reference to the step from the requirement text. (This is no longer a
cross-reference and may become inaccurate.)
● Why move supplementary requirements that trace to more than one use
case, once they are in ReqPro?
o Because they belong in both use case documents and we want to avoid
duplication of requirements. (ReqPro does not allow the same requirement to be
located in 2 places.)
o Originally I suggested moving all supplementary requirements to the database,
whether duplicated or not; for consistency this may still be a good idea.

34. 2/11/2010
Cut A Requirement

35. Paste Supplementary Requirements
●The requirements are pasted into the supplementary
requirements view.
●The requirements are moved from the ‘Application
Use Case’ folder to the ‘Supplementary
Requirements’ folder.
2/11/2010

36. Trace Supplementary Requirements
●The supplementary requirement traces To
the use case step that it impacts.
2/11/2010

37. Demo
●Import an AUC document.
●Set the use case steps to be children of
the parent AUC.
●Move the supplementary requirements
to the supplementary folder in the
requirements explorer.
●Trace the supplementary requirements
to the use case steps they impact.
●Set the status of the AUCs to ‘Detailed’.
2/11/2010

38. Generating The AUC Document
●When you need to review the AUC document,
many of the reviewers will not have access to
ReqPro (many of your reviewers will refuse to
use ReqPro even if you do give them access.
●You will need to take the document offline
(prevents it from being edited while being
reviewed).
●You will need to add the supplementary
requirements to the off line document.

39. Review The AUC Document
●Take the document offline, using ReqPro’s ‘Offline’
command.
●Run the attached SoDA template and enter the
document’s location when prompted.
●An AUC document including supplementary
requirements is generated.

40. Supplementary Requirements
●The SoDA script will automatically add
cross-references to the use case steps.

41. Once The Review Is Complete
●‘Cancel’ the offline document, deleting the
version on your desktop.
●All changes to the AUC document are made
through the ReqPro UI.
●Once the changes are complete, you might
want to set the status of the AUC and all
supplementary requirements, to ‘Approved’.

42. Demo
●Take an AUC document offline.
●Run the SoDA script to generate an AUC
document for review.
●Cancel the offline document.
●Set the requirements status to approved.

43. 2/11/2010
AUC Document Relationships
●A single AUC is documented
in an AUC document.
●An AUC contains AUC steps.
●AUC steps are requirements
in a ReqPro database.
●Supplementary requirements
trace from AUC steps.
●Supplementary requirements
are contained in either the
ReqPro database or in an
AUC document.

44. 2/11/2010
Summary
●In this presentation you learned:
othe purpose of the different sections of the AUC
document.
othe information that goes into each section.
ohow to detail an AUC document.
ohow to import and manage an AUC document in
ReqPro.
ohow to review an AUC document that is managed
by ReqPro.
ohow to manage supplementary requirements with
ReqPro.

45. References
●The Application Use Case Document
template in MS Word is located here.
●The Working With Styles and Properties
presentation is here.
●The Introduction To ReqPro presentation is
here.

46. 2/11/2010
Test Your Knowledge
●How many use cases are there in an application use case
document?
●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.
●Import the AUC document to ReqPro, keeping the original AUC
document on your desktop.
●Change the AUC document inside ReqPro.
●Take the AUC document offline.
●Modify and bring the AUC document back online in ReqPro.
●Set the status of the AUC requirements to ‘Approved’.