NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Unified Harmonization Process

Use Case Number

Init1bes9.pm11.1

Brief Description

Common data elements can be entered into the metadata repository through a variety of different tools, including a UML loader, manual curation through the web interface, and forms development.  There must be a common harmonization mechanism enforced by the metadata repository such that all mechanisms by which CDEs are entered can be reused by all types of users.

Actor(s) for this particular use case

Metadata Specialist

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

None.

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

CDEs are harmonized in the 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. A Metadata Specialist enters a common data element
    1. via automated UML loading
    2. via manual curation
    3. via form creation
  2. The Metadata Specialist is able (forced?) to harmonize the CDE(s) regardless of the mechanism by which it was registered

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

None.

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.

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

The Metadata Specialist should be notified or forced in some manner to harmonize the CDEs.

Unified CDE Reuse

Use Case Number

Init1bes9.pm11.2

Brief Description

Regardless of the mechanism by which a CDE was registered (automated UML, forms creation, or manual curation), CDEs should be available for reuse by any type of tooling.

Actor(s) for this particular use case

Metadata Specialist

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

CDEs have been registered and harmonized via a variety of mechanisms.

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

CDEs are reused.

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. A Metadata Specialist discovers CDEs for reuse
    1. in forms
    2. in a UML model
    3. in an application
  2. The CDEs are available and fully functional within the desired modality

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

None.

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.

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

Regardless of the mechanism by which a CDE has been registered, it must be reusable by any application.

Association of Form Details to CDEs

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.

Init1bes9.pm11.3

Brief Description

When CDEs are registered for reuse specifically in forms, there should be a way to associate form structure, form behavior, etc.

Actor(s) for this particular use case

Forms Author

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

None.

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

CDEs are registered with forms details associated.

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 Forms Author registers CDEs
  2. The Forms Author defines forms details, such as structure, behavior, etc.
  3. The Forms Author registers the forms details in the metadata repository
  4. The CDEs are available for reuse within forms

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

None.

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.

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

None.

Common Form Development Tool

Use Case Number

Init1bes9.pm11.4

Brief Description

A common form development tool would allow users a unified way to select metadata from the repository, add forms information, build a persistence backend, and a simple front-end.

Actor(s) for this particular use case

Forms Author

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

CDEs exist in the metadata repository

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

A data collection tool is created

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 Forms Author selects CDEs for data collection
  2. The Forms Author adds additional forms details, such as form structure, behavior, etc.
  3. The Forms Author constructs a persistence model
  4. The Forms Author constructs a web front-end for data collection
  5. The Forms Author exports a deployable system

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

None.

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

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?

The tooling should be common and reusable.

  • No labels