 |
Page History
| Wiki Markup |
|---|
{scrollbar:icons=false}
h1. {page-info:title}
{anchor:ContentsofthisPage}{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}
h2. 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 \\ | # A Metadata Specialist enters a common data element
## via automated UML loading
## via manual curation
## via form creation
# 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. \\ | * [Init1bes9 - CDEs from Man. curation, UML models and CRFs|https://wiki.nci.nih.gov/x/JgpyAQ]
* [CDEs from Man. curation, UML models and CRFs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=43&t=122] |
|| *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. \\ |
h2. 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 \\ | # A Metadata Specialist discovers CDEs for reuse
## in forms
## in a UML model
## in an application
# 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. \\ | * [Init1bes9 - CDEs from Man. curation, UML models and CRFs|https://wiki.nci.nih.gov/x/JgpyAQ]
* [CDEs from Man. curation, UML models and CRFs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=43&t=122] |
|| *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. \\ |
h2. 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 \\ | # The Forms Author registers CDEs
# The Forms Author defines forms details, such as structure, behavior, etc.
# The Forms Author registers the forms details in the metadata repository
# 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. \\ | * [Init1bes9 - CDEs from Man. curation, UML models and CRFs|https://wiki.nci.nih.gov/x/JgpyAQ]
* [CDEs from Man. curation, UML models and CRFs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=43&t=122] |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |
h2. 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 \\ | # The Forms Author selects CDEs for data collection
# The Forms Author adds additional forms details, such as form structure, behavior, etc.
# The Forms Author constructs a persistence model
# The Forms Author constructs a web front-end for data collection
# 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. \\ | * [Init1bes9 - CDEs from Man. curation, UML models and CRFs|https://wiki.nci.nih.gov/x/JgpyAQ]
* [CDEs from Man. curation, UML models and CRFs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=43&t=122] |
|| *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. \\ |
h1. Fetching Forms Data
|| *Use Case Number* \\ | Init1bes9.pm11.5 |
|| *Brief Description* | Some tools rely heavily on fetching forms and form data programmatically. In order to make this process efficient, it is desirable to fetch entire object graphs that includes the entire form, data element information, and, where applicable, the data itself. \\ |
|| *Actor(s)* for this particular use case | Metadata Specialist |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | A form exist in the metadata repository \\ |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | The form and (if applicable) data is entirely fetched \\ |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # The Metadata Specialist identifies the form that he wishes to fetch
# The Metadata Specialist fetches the form (and associated data) in its entirety |
|| *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. \\ | * Email Requirements: _In the course of retrieving the metadata for a CRF from the caDSR, the AGNIS Metadata Tool sends a large number of web service requests to the cadsrapi40Service web service. This can take a long time, due to the large number of round trips to the server. One possible way to improve performance would be to implement a caDSR API that, instead of returning only one object at a time, could return a graph of objects in response to a single web service request. This would move processing to the server side, where it can be done more efficiently, and also improve performance by reducing the number of round trips to the server._
* [Init1bes9 - CDEs from Man. curation, UML models and CRFs|https://wiki.nci.nih.gov/x/JgpyAQ]
* [CDEs from Man. curation, UML models and CRFs|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=43&t=122] |
|| *Fit criterion/Acceptance Criterion* \\
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? \\ | None. \\ |
h2. Form Data Mining
|| *Use Case Number* \\ | Otherhm1.pm12.1 |
|| *Brief Description* | A common set of tooling should work out-of-the-box for performing mining and analytics on CDE-based forms data. \\ |
|| *Actor(s)* for this particular use case | Metadata Specialist |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | Data has been collected through a common forms collection mechanism. \\ |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Data mining analytical results are available \\ |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # The Metadata Specialist identifies the forms persistence services to mine
# The Metadata Specialist formulates the data mining queries using a common graphical interface
# The Metadata Specialist issues the queries to the forms persistence services |
|| *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. \\ | * [Otherhm1 - Generation of Forms|https://wiki.nci.nih.gov/x/BglyAQ]
* [Generation of Forms|https://cabig-kc.nci.nih.gov/Vocab/forums/viewtopic.php?f=44&t=141] |
|| *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. \\ |
\\
{scrollbar:icons=false} |
