Use Case Number

Init1pm1.1

Brief Description

Since its inception, caBIG has been founded on (1) developing and defining standards, tooling, and architecture to enable interoperability, and (2) determining whether existing systems meet the basic requirements for interoperability.  While the nature of the "compatibility reviews" may change, there is a clear need to provide the community a way to understand at what level different applications meet interoperability requirements.  It is highly desirable that the review process be as simple and transparent as possible both for the developer/owner of a system and the reviewers.  In this way, review artifacts should be able to be generated in an automated fashion based on the model itself or its registration in the metadata repository.  Furthermore, a reviewer using the compatibility review software should be able to access real-time the artifacts that they need to perform a review.

Actor(s) for this particular use case

• Information Modeler
• Compatibility Reviewer

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

A model has been created with all the necessary semantic information for registration and a "compatibility" review.

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

The artifacts have been generated for the compatibility review and they have been linked in the compatibility review system.

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. The Information Modeler register his metadata in the metadata repository
2. (If needed) the Information Modeler takes the steps in the modeling tool to generate review artifacts
3. The review artifacts are linked into the review tool
4. The Compatibility Reviewer has access to all of the information (artifacts) needed to complete the review

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

It should not be a requirement to use the caBIG-defined tooling to generate compatibility artifacts.  Instead, there should be an alternate flow that involves the creation of the artifacts de novo, registration of the metadata, and providing the artifacts to the review system.

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

Medium

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.

Init1pm1 - ICR IRWG Requirements

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

• It is highly desirable that as many (if not all) of the review artifacts be generated automatically for the Information Modeler by the modeling tool
• It is highly desirable that as many (if not all) of the review artifacts be linked real-time from the metadata repository into the review tool (e.g. the reviewer will be reviewing data elements that are pulled directly from the metadata repository rather than statically copied)

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.

n.n

Brief Description

Actor(s) for this particular use case

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

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

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.
2.

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

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

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.

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

1.
2...

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.

n.n

Brief Description

Actor(s) for this particular use case

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

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

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.
2.

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

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

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.

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

1.
2...

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.

n.n

Brief Description

Actor(s) for this particular use case

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

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

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.
2.

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

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

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.

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

1.
2...

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.

n.n

Brief Description

Actor(s) for this particular use case

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

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

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.
2.

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

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

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.

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

1.
2...