User Stories for Semantic Requirements

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.

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	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	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	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	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	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	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)	Must	Draft
8	Support of form annotations to enable form behavior	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"	Must	Draft
10	Support the ability to create and manage extensions to allowable answers to a question with additional permitted values	Must	Draft
11	Support the creation and sharing of metadata and management of information models through modeling and web tools	Must	Draft
12	Support interoperability standards (e.g. Healthcare Datatypes)	Must	Draft
13	Capturing data in a standard way using data element metadata and reuse	Must	Draft
14	Finding touch points with other systems when building a population science application	Must	Draft
15	Support automated data transformations where semantic equivalence has been established in order to allow different flow cytrometry tools to work together	Must	Draft
16	Support iterative development and management of information models	Must	Draft
17	Support standardized processes for software development and assessing compliance and conformance	Must	Draft

Terminology

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"

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

Requirements categories

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"

User Goals

Sea Level --> something the actor is trying to get done - "one person, one sitting"

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"

Content

Space Tools