Page History

{scrollbar:icons=false}
h1. {page-info:title}

h2. Introduction

An important part of the requirements gathering process is to engage end users and stakeholders.  In an infrastructure project of this nature, a good way to relay the types of functionality that will be supported is through user stories. This list is not meant to be exhaustive.  These stories are representative of the types of functionality that will be directly supported by the infrastructure, as well as the types of tooling that will be enabled by the infrastructure.

h2. Stories

|| Number \\ || Story \\ || Priority \\ || Status \\ ||
| 1 \\ | [An ad-hoc ability to search  for data that would support a query such as search for all "pre-cancerous" biospecimens that are available for sharing at Washington University, Thomas Jefferson University, and Fox Chase Cancer Center|Semantic Infrastructure Domain User Story 1] | Must \\ | Draft \\ |
| 2 \\ | [The ability to correlate data across different data services that would support a querty to identify samples obtained for glioblastoma multiforme (GBM) from one service with the corresponding CT image information|Semantic Infrastructure Domain User Story 2] | Must \\ | Draft |
| 3 \\ | [Support for workflows that would allow users to automatically discover analytical steps for Illumina bead array analysis using inference based on the semantic metadata of the parameters|Semantic Infrastructure Domain User Story 3] | Must \\ | Draft |
| 4 \\ | [Support for workflows that would allow user to discover and orchestrate services to achieve LS research goals; e.g. start with a hypothesis, identify relevant services that provides the necessary analysis and data, create the workflow/pipeline, report findings|Semantic Infrastructure Domain User Story 6] | Must \\ | Draft |
| 5 \\ | [Support the development of new applications that allows the addition of data elements to an existing information model and automatically capture and publish the information about the extensions [such as when defining new datasets for caIntegrator's data-warehouse, automatically record these new datatypes in a standard, well-defined and federated manner so that data can be shared|Semantic Infrastructure Domain User Story 5] | Must \\ | Draft |
| 6 \\ | [Support the ability to capture and apply rules to data objects such as the ability to match patient to trial through the use of computable eligibility criteria|Semantic Infrastructure Domain User Story 4] | Must \\ | Draft |
| 7 \\ | [Support the ability create, import and reuse forms that have detailed programmatically interpretable metadata about the form, its components (modules) and questions (data elements)|Semantic Infrastructure Forms User Story 1]\\ | Must \\ | Draft |
| 8 \\ | [Support of form annotations to enable form behavior|Semantic Infrastructure Forms User Story 2] | Must \\ | Draft |
| 9 \\ | [Support the ability to harmonize data elements and manage semantic relationships in order to link and share data such as making assertions like "same as" or "equivalent"|Semantic Infrastructure Metadata Specialist User Story 2] | Must \\ | Draft |
| 10 \\ | [Support the ability to create and manage extensions to allowable answers to a question with additional permitted values|Semantic Infrastructure Forms User Story 3] | Must \\ | Draft |
| 11 \\ | [Support the creation and sharing of metadata and management of information models through modeling and web tools|Semantic Infrastructure Metadata Specialist User Story 1] | Must \\ | Draft |
| 12 \\ | [Support interoperability standards (e.g. Healthcare Datatypes)|Semantic Infrastructure Metadata Specialist User Story 3] | Must \\ | Draft |
| 13 \\ | [Capturing data in a standard way using data element metadata and reuse|Semantic Infrastructure Metadata Specialist User Story 4] | Must \\ | Draft |
| 14 \\ | [Finding touch points with other systems when building a population science application|Semantic Infrastructure Metadata Specialist User Story 5] | Must \\ | Draft |
| 15 \\ | [Support automated data transformations where semantic equivalence has been established in order to allow different flow cytrometry tools to work together|Semantic Infrastructure Metadata Specialist User Story 6] | Must \\ | Draft |
| 16 \\ | [Support iterative development and management of information models|Semantic Infrastructure Developer User Story 1] | Must \\ | Draft |
| 17 \\ | [Support standardized processes for software development and assessing compliance and conformance|Semantic Infrastructure Developer User Story 2] | Must \\ | Draft |

h2. Terminology

h3. Priority
* Must: this story must absolutely be supported by the semantic infrastructure in order to meet the core needs of the community
* Should: this story should be supported by the semantic infrastructure because it represents important functionality without which many user needs will not be met
* Could: this story is not critical to the needs of the community but is "nice to have"

h3. Status
* Draft: the story is still under development by the semantic infrastructure analysts
* Review: the story has completed the analysis process and is under a period of community review and comment
* Confirmed: the story has been reviewed and confirmed by the community

h3. Requirements categories

h4. Summary Level
* Cloud level \--> Very high level, can involve multiple user goals  - "Operate a Specimen Bank"
* Kite level \--> High level, a business process that takes place  over several hours, days or weeks involving many steps - "Handle a  Specimen Order"

h4. User Goals
* Sea Level \--> something the actor is trying to get done - "one  person, one sitting"

h4. Subfunctions
* Underwater \--> needed to accomplish user goals, typically can be  used and reused - "Save as a File"
* Clam \--> not usually expanded into a use case - "insert record  into database"

{scrollbar:icons=false}