NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

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"
  • No labels