 |
Page History
| Wiki Markup |
|---|
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.
Automated matching service
Use Case Number | 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 |
|
Post condition | Actor gets a list of recommended results to choose from and the selected option is persisted |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links |
|
Fit criterion/Acceptance Criterion | Actor can do a bulk search and save features for values taken from a CSV |
Ability to bulk write on caDSR
Use Case Number | 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 |
|
Post condition | Actor is able to bulk register metadata on caDSR |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links |
|
Fit criterion/Acceptance Criterion | An actor with the necessary privilege should be able to upload metadata on caDSR. |
Grouping of CDE on caDSR
Use Case Number | 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 |
|
Post condition | A named group of bunch of CDEs is created on caDSR |
Steps to take |
|
Alternate Flow | None |
Priority | High |
Associated Links |
|
Fit criterion/Acceptance Criterion | A created group with a bunch of CDEs are available on caDSR |
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?
...
\\ | 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. 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 |
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. | 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 |
h1. 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* | <!-- /* 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 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 \\ | <!-- /* 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;} --># 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 \\ | <!-- /* 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;} -->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 \\ | <!-- /* 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;} --># 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? \\ | <!-- /* 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;} -->Actor is able to compare from the available search result and select the best fit CDE | |
