 |
Page History
| Wiki Markup |
|---|
{scrollbar:icons=false}
h1. {page-info:title}
{anchor:ContentsofthisPage}{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}
h2. Free style search for best content
|| *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. \\ | CAI2SD1 |
|| *Brief Description* | This use case describes the sequence of events that follow when an actor is looking for CDE of interest from caDSR |
|| *Actor(s)* for this particular use case | Study Manager |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # caIntegrator has the necessary API to connect to caDSR and import the relevant data in caDSR
# Along with results, the API should provide data such as frequency of use, Actor populations, applicability across domains, diseases etc. |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Actor is able to view data that shows up in order of relevance |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor clicks on change assignment hyperlink
# Actor gets to select if he wants to see 'Draft new CDEs as a part of the result
# The system fetches a list of local CDEs and CDEs from caDSR that show up in the following order of prioritization/relevance \\
I. Standards CDE \\
II. CDE displayed according to frequency of \\
use, Actor populations, applicability \\
across domains, diseases.
# The result is displayed as \\
I. via indentation, like Google \\
II. Brother and sister CDEs (within same object class) \\
III.Similar CDEs with differences highlighted \\ |
|| *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 actor must be able to import most relevant CDE into his study with reasonable ease, and these must be represented fully. |
h2. Automated matching service
|| *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. | CAI2SD2 |
|| *Brief Description* | This use case describes the sequence of events that follow when an actor is looking for best CDE matches based on actual values of the spreadsheet |
|| *Actor(s)* for this particular use case | Study manager |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # There is a service that accepts a CSV in specific format and interfaces with caDSR to get matching CDEs
# Service can persist the results from caDSR in the CSV |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Actor gets a list of recommended results to choose from and the selected option is persisted |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor selects the CSV which has the data that he wants to search on caDSR
# Actor invokes a service that is configured to query caDSR on entities from CSV
# Service returns the CSV with matched results
# Actor selects from the list of matches that the service returns with
# The selected entity is persisted |
|| *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? \\ | Actor can do a bulk search and save features for values taken from a CSV |
h2. Ability to bulk write on caDSR
|| *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. | CAI2SD3 |
|| *Brief Description* | This use case describes the sequence of events that follow when an actor is bulk writing data on caDSR |
|| *Actor(s)* for this particular use case | Curator |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # Actor should have the write privilege on caDSR
# Actor should have the necessary authentication in caIntegrator
# caDSR should be able to validate the authentication of the author |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Actor is able to bulk register metadata on caDSR |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor selects a list of CDE in the application
# An API uploads the CDEs on caDSR
# The uploaded CDEs are available on caDSR. |
|| *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? \\ | An actor with the necessary privilege should be able to upload metadata on caDSR. |
h2. Grouping of CDE on caDSR
|| *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. | CAI2SD4 |
|| *Brief Description* | This use case describes the sequence of events that follow when an actor is trying to create a group of CDE like a bookmark |
|| *Actor(s)* for this particular use case | Curator \\ |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # Actor should have the necessary privileges on caDSR
# caDSR should allow grouping of CDEs into a common group |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | A named group of bunch of CDEs is created on caDSR |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor provides necessary authentication on caDSR
# Actor searches caDSR using context/project based search
# Selects pertinent CDEs he wants grouped together
# provides a group name for the selected CDEs
# The said group is created on caDSR with the chosen CDEs as part of the group
# Actor can browse across multiple contexts/ projects and keep on adding to the existing group |
|| *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? \\ | A created group with a bunch of CDEs are available on caDSR |
h2. Free style search for best content
|| *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. | CAI2SD5 |
|| *Brief Description* | This use case describes the sequence of events that follow when a Actor wants to bulk import metadata from caDSR |
|| *Actor(s)* for this particular use case | Study manager |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # caDSR has a group created for a bunch of CDEs
# caIntegrator can query caDSR based on a group name
# Actor knows which group is of interest for his study |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | A named group of bunch of CDEs is created on caDSR |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor provides necessary authentication on caDSR
# Actor searches caDSR using context/project based search
# Selects pertinent CDEs he wants grouped together
# provides a group name for the selected CDEs
# The said group is created on caDSR with the chosen CDEs as part of the group
# Actor can browse across multiple contexts/projects and keep on adding to the existing group |
|| *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? \\ | \\
A created group with a bunch of CDEs are available on caDSR |
h2. Compare search results
|| *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. \\ | CAI2SD6 |
|| *Brief Description* | This use case describes the compare search results feature in caIntegrator |
|| *Actor(s)* for this particular use case | Study Manager |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | # Actor should be able to select CDEs to be compared
# Application should be able to retrieve every single data point about a CDE |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Actor is able to compare and contrast the selected CDEs |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | # Actor is displayed a list of matching CDEs as a result of his search
# Actor selects the CDEs of interest to compare by clicking on the check boxes
# The application gives a details of the selected CDEs with the differences highlighted |
|| *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? \\ | Actor is able to compare from the available search result and select the best fit CDE |
\\
{scrollbar:icons=false} |
