h1. 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. |
h1. 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 |
h1. 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. |
h1. <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; mso-bidi-font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->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. | <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; mso-bidi-font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->CAI2SD4 |
| *Brief Description* | <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; mso-bidi-font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->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 \\ | |
| *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... |
h1. Use Case - Descriptive Name
| *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... | |