Written Use Case & Use Case Diagram
Use Cases
Deborah E. Swain, Ph.D.
EXAMPLE
|
Name: Provision Service Data on Platform |
Owner: <initials> |
Actor: Service Administrator |
Assets Impacted: DataManager, Platform
|
Type: Standalone |
|
DB Identifier: XXX-YY-001
|
Customer: All |
Scope: Network |
Function: Configuration |
Related Use Cases: |
Description:
The DataManager provisions Services. The user will be able to create, update and delete data objects. The data can be provisioned for one or more network elements running on the Platform.
Frequency:
Used whenever a Service object needs to be created or updated. The frequency of operation is dependent upon the Service’s provisioning requirements and the number of DataManager provisioning users. An example frequency might be 2 transactions per hour per administrator.
Precondition(s):
1. DataManager is running
2. Service to be provisioned is installed.
3. Views for the Service are created.
4. Owners of Service have been defined.
5. Provisioner (administrator) has login and permissions in DataManager to perform provisioning tasks.
Postcondition(s):
Service object data is provisioned on the selected network elements for the Service.
Main Scenario:
1. Provisioner/Service administrator logs into DataManager via graphical interface.
1. Provisioner/Service administrator selects the Service Object option.
1. Provisioner/Service administrator defines the Service Object name to be provisioned.
1. Provisioner/Service administrator then selects the network elements for which the data needs to be provisioned from the list of available network elements for the selected category. Alternatively, the Provisioner/Service administrator can also choose to use the distribution rules to distribute the data.
1. Provisioner/Service administrator then is prompted to select the categories for the feature capability to be provisioned. Provisioner/Service administrator then keys in the data that need to be provisioned. Multiple service object categories and capabilities can be provisioned.
1. Provisioner/Service administrator scan also select if they want to send to only particular network element. (This may be used when the Provisioner/Service administrator knows one of the NE is out of service)
1. On completion of creation of one service object request, the Provisioner/Service administrator will be provided option to:
1. select particular NE for the provisioning from the NE group (optional)
1. add more capabilities to the just created service object (optional)
1. make changes to the data entered for different capabilities (optional)
8. On completion of creating the data to be provisioned, the user will be prompted to provide:
1. a work order name, or
1. let DataManager select a work order name
9. The user can also select one of the following types of processing for a work order:
1. Save it for later provisioning
1. Submit it for immediate processing
1. Submit it for later processing
10. A summary of a work order being created is provided.
11. Provisioner/Service administrators are prompted if they wanted to add more service object requests to the work order.
12. When submitted for provisioning, the DataManager performs validation of the data provided in the work order.
13. Upon completion of validation, the DataManager distributes provisioning data to the network elements.
1. Provisioner/Service administrator can use the work order ID to check the status of the work order from the work order summary page.
Extensions:
5a. One of the service data types could be Flexible Service Logic.
12a. Validation error occurs in a work order:
the user may correct the data entered and re-submit the work order
13a. Distribution to the network element fails:
The DataManager marks the status of the work order as failed.
NOTE: Possible types of failures include:
1) Platform-DataManager Link failure,
2) No DataManager communication possible with Platform
3) Invalid login/password between Platform and DataManager
4) Missing target Platform directory,
5) Insufficient disk space on Platform.
The Platform-DataManager corrects the work order and resubmits for provisioning.
*a. User wants to cancel the creation of the service object work order (which can happen at any time during the creation process, i.e., steps 3-8 of the main scenario):
1. User chooses cancel operation
1. Creation of service object work order is abandoned
Variations:
3a. User can choose to update an existing service object
3b. User can choose to delete an existing service object
Issues/Comments:
1. DataManager can accept work orders containing service objects to be provisioned from an upstream system. DataManager accepts the request through its well defined CORBA API. DataManager applies the validation rules before starting to distribute it to the network elements.
Associated Specification Textual Requirements: ZZZ
Graphical Example of Scope
The figure below provides a visual depiction of an Scope combined with the Actors defined for a particular set of Use Cases. Actors are identified for each set of Use Cases and there is the flexibility to add Actors as the need arises.
Process
1. Define Problem to be solved.
2. Determine Scope of system (boundaries, domain, customer/business objectives)
3. Identify Actors (role or roles relative to system, event analysis: when do actor and scope need to interact, any related goals/mission to consider)
4. “Discover” the Use Cases
a. Separate Processes (i.e., any mini-scopes)
b. Form Use Cases (interaction context, scenarios, structure, i.e., any sub-use cases)
5. Specify Use Case
a. Define pre- and post- events
b. Write primary scenario
c. Determine logic structure (i.e., any extensions or variations)
d. Write extensions
e. Write variations
Tips
· Use Action Statement Format
(time factor or sequence -> actor-> action ->constraints)
· Number each action sequentially
· Follow the primary course (separate extensions and variations)
Practical Reference Contacts
· Dennis Mancl or Tom Baumgartner, Use Case Primer authors at Lucent Technologies, Inc., ( [email protected] )
Template
Name:
Owner/Author:
Actor(s):
Primary –
Secondary –
Systems Impacted:
Frequency:
Precondition(s):
1. ____________________________
2. ____________________________
3. ____________________________
Postcondition(s):
Main Scenario:
1. ___________________________________________________________________
2. ___________________________________________________________________
3. ___________________________________________________________________
4. ___________________________________________________________________
5. ___________________________________________________________________
6. ___________________________________________________________________
7. ___________________________________________________________________
8. ___________________________________________________________________
9. ___________________________________________________________________
10. ___________________________________________________________________
Extensions:
1. ____________________________
2. ____________________________
3. ____________________________
Variations:
1. ____________________________
2. ____________________________
3. ____________________________
Issues/Comments:
1. ____________________________
2. ____________________________
3. ____________________________
Service Provider
Customer Technical
Support
New Product
Introduction
Lucent Customer
Technical Support
(Service Provider)
Cross-Service
Administrator
(Service Provider)
Service-Specific
Administrator
Enterprise
Customer
Administrator
(Provisioning)
End User
(Parties A, B, ...)
Bearer
Network
Resources
Upstream
Provisioning
System
Service
Application
VPN
Asset Scope
OSSs
Provision Service Application
Data on AHE from eSM
(eSM, AHE, SA)
Service-Specific
Administrator
1.2: SO / Work Order
created
1: Create Service Object
1.1.1 (optional)
1.1.2.2.1: provision(data)
1.1.2.2.1.1:success/fail
Service-Specific
Administrator
1.1
Create Service
Object [name, NEs,
data, type{I,U,D}]
<<eSM>>
Associate SO with
work order
<<eSM>>
create work order
<<eSM>>
1.1.2
schedule work order
(immediately or later)
<<eSM>>
waiting for
scheduled time
<<eSM>>
execute work order
validate
distribute
<<eSM>>
provision data
<<eAS>>
1.1.2.1: wait
1.1.2.2
1.1.2.1.1: done
1.1.2.2.2:
send
status