Ministry/Agency Name

[Complete file/properties to populate fields on this page and in the document headers]

Project Name

Project #: 

Essential Use Case Specification 1.0 :

Prepared by:    Author's Name

Prepared for:    

Date Submitted:    [Date]

Project Sponsor:    Project Sponsor's Name

Client Acceptor:    

Project Manager:    

Document Number:    50-20/Project Number /EUC 

Security Classification: Low

Version:    0.1

Last Updated:    May 19, 2005

Creation Date:    May 19, 2005

Table of Contents

Table of Contents    2

Introduction    3

Document Purpose    3

Intended Audience    3

Use case brief description    4

Actors List    5

Flow of events    6

Basic Flow    6

Alternate Flow    7

Non-functional Requirements    8

Pre- and Post-conditions    9

Pre-condition    9

Post-condition    10

Extension Points    11

List of <> use cases    12

List of <> use cases    13

List of " inherited from (parent)" use cases    14

APMS Update    15

Revision Log    16

Appendices    17

Approval    18

Introduction

Document Purpose

The objectives of the Essential Use case Specification Document are 

∙Describe the use case in text form that was modeled earlier in the Use case diagram. 

∙List the actors involved with the use case.

∙Describe use case's functional requirements.

∙Describe the Use case's basic flow and alternate flow of events. 

∙Describe the Use case's Pre- and Post-conditions.

∙Describe how the Use case is reused (extended and included), if applicable.

∙Describe use case's non-functional requirements.

Intended Audience

∙User.

∙ITMB Business Analyst.

∙Development Team.

∙IMG QA Team.

Use case brief description

[Describe briefly the role and purpose of the use case in one paragraph]

Actors List

[List all the actors (generalized as well as specialized actors) who are involved with the use case. Add more rows to the table below if required.]

Flow of events

[The above diagram is provided for illustration purposes only.]

[The Flow of events section of a use case specification contains the most important information derived from use-case modeling work. It should describe the use case's flow of events clearly enough for an outsider to easily understand it. Ensure the flow of events should present what the system does, not how the system is designed to perform the required behaviour.

Do not put any text directly under this section. Break the text into the following two sections.]

Basic Flow 

[The basic flow of events should cover what "normally" happens when the use case is performed. This is a mandatory section.

Begin the description with "how the use case starts and which actor triggers it".  The use case should describe what the actor does and what the system does in response.  It should be phrased in the form of a dialog between the actor and the system.

The use case should describe what happens inside the system, but not how or why.  If information is exchanged, be specific about what is passed back and forth. Use terminology from the Business Glossary defined earlier in the project. 

Do not describe alternate flows in this section.

Number each step of the basic flow.

If this use case "inherits" complete behavior from another use case, describe the first step of the basic flow as "This is an inherited use case". Describe the use case's specialized behavior in subsequent steps.

If a step in the basic flow is performed by another use case unconditionally, then invoke that use case as per the following example syntax :  

include ("Pre-screen the Applicant" Use case).   

If a step in the basic flow is performed by another use case under specific conditions, then invoke that use case just by specifying the name of the extension point as per the following example syntax :  

Extension Point "Parent Financial Profile".

Do not list the included, extended or "inheriting from (parent)" use cases here since this is done in a later section of this document. 

Do not duplicate the included, extended or "inheriting from (parent)" use case's details or flow here. 

Describe how the use case starts and ends. 

Describe what data is exchanged between the actor and the use case.

Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system. 

Avoid using IT terminology.

Describe the flow of events, not only the functionality.

Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system.]

Alternate Flow 

[Follow the same guidelines as mentioned for basic flow.

Always describe alternate flow in this section and do not describe alternate flows within the basic flow section.

Number each step of the alternate flow.

If no alternate flow exists then leave this section blank.]

Non-functional Requirements

[A non-functional requirement is typically a special requirement that is specific to a use case, but is not easily or naturally specified in the text of the use case’s event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirements such as operating systems and environments, compatibility requirements, and design constraints should be captured in this section.

If there are to many special requirements to be documented, then categorize them as subsections such as  " usability", "reliability

Document only those non-functional requirements here that applies to this use case. Non-functional requirements that apply to the whole system should be separately documented as "Supplementary Specifications" in plain text. 

Number each special requirement.]

Pre- and Post-conditions

[The above diagram is provided for illustration purposes only.]

[Use Pre- and Post-condition sections only if adds value to the use case specifications.

Ensure Pre- and Post-conditions described here are applicable to this use case and not for other use cases. It is possible for two or more use cases to have the same Pre- and Post-conditions.]

As a matter of convenience, you can first fill in the pre- and post-condition sections (i.e. define what the use case is supposed to achieve) and then fill in Flow of Events section (i.e. describe how to reach this condition.]

Do not put any text directly under this section. Break the text into the following two sections.]

Pre-condition

[A pre-condition of a use case is the state of the system that must be present prior to a use case being performed.

The states described by pre-condition should be a state that the user can observe. Example: User has successfully logged into the system.

Ensure to list all the important pre-conditions.

Ensure that a pre-condition is a constraint on when a use case can start and it is not the event that starts the use case. 

Ensure that a pre-condition is for the whole use case, not just for specific flow(s) within the use case.]

Post-condition

[A post-condition is the state the system can be in after the use case has ended.

Ensure to list all the important post-conditions.

A post-condition for a use case should be true regardless of which alternative flows were executed; it should not be true only for the main flow.

 If something could fail, mention that in the post-condition by saying, "if something failed, the action is not performed", rather than just "The action is completed". 

While using post-conditions together with <> association, ensure that the extending use case does not introduce a sub-flow that violates the post-condition in the base use case.]

Extension Points

[Using named extension points helps separate the specification of the behavior of the extending use case from the internal details of the base use case. The base use case can be modified as long as the names of the extension points remain the same and it will not affect the extending use case. 

Ensure that the text describing the flow of events of the base use case is not duplicated with details of extended use case.

Describe the condition of the extension in terms of attributes of the base use case. If the extension condition is omitted then the extension will always be executed.

List and describe each Extension point and the extension condition as a pair. Add more rows if needed.

If there is no Extension condition for an Extension point, then specify the Extension condition as "none" rather than leaving it blank.]