NIH | National Cancer Institute | NCI Wiki  

Contents of this Page

Use Case - Iterative registration of information models

Use Case Number
The author-assigned number to refer to each specific use case. The format of this number is <SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc.

Initdbw8.U1
U - User Goal from Initdbw8 in which 4 usage scenarios were described.

Brief Description

An information modeler needs to be able to begin recording semantics the of the information model automatically from the moment he begins his design. He needs to be able to find existing content or register new content, deriving the semantics needed for registration from his model throughout the development of the information modeling process capturing changes and recording then automatically as he edits the model.  

Use Case Level: (Business Summary, User Goals, Subfunctions)

Business Summary level

Actor(s) for this particular use case

Information Modeler

Pre-condition
The state of the system before the user interacts with it

- Information modeler has a documented end user scenario for which he needs to develop a information model.
- He has access to an information modeling tool such as Enterprise Architect and intends to create a UML Model for use with his application.
- He has access to existing content in the semantic infrastructure. 

Post condition
The state of the system after the user interacts with it

The information model has been recorded in the semantic infrastructure and appropriate registries for others to discover and use.

Steps to take
The step-by-step description of how users will interact with the system to achieve a specific business goal or function

1. Modeler opens his modeling tool to begin designing his information model

2. Modeler creates and names new classes in his diagram

3. Modeler creates and names the associations between classes in the diagram

4. Modeler compares his design to the requirements

5. Modeler saves the design in the repository.
6. Modeler retrieves the model to conducts a review with stakeholders and makes changes to the model.
7. Changes are saved in the repository.
8. Modeler marks the model as final and passes the model to the application developer to begin implementation. 

Alternate Flow
Things which would prevent the normal flow of the use case

1. All or parts of the model already exist in the repository by a different name

2. All or parts of the model have been found in the repository with the same name but different characteristics

Priority
The priority of implementing the use case: High, Medium or Low

High

Associated Links
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case.

Interview details

Fit criterion/Acceptance Criterion 
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement?


1. A new model can be developed and the system finds a prior version, allows the modeler to reuse it.
2. A model is retrieved, edited and saved, the system keeps track of the differences between each version.
3. A different information modeler is able to find the specific information model that is associated with a specific use case.

  • No labels