NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Use Case Number

INIT1SD2.pm7.1

Brief Description

When a long-running query is submitted to a number of different federated services, it is desirable to be able to provide users with a status update on the progress of the query, including which services have completed, how much data has been returned, and (if possible) how much work is left.

Actor(s) for this particular use case

Cancer Researcher

Pre-condition
The state of the system before the user interacts with it

A number of services are available upon which a federated query can be performed.

Post condition
The state of the system after the user interacts with it

The user is updated with the status of the query.

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. The user constructs a federated query and submits it to multiple services
  2. The user periodically requests status updates on the progress of the query from the federated query processor
  3. The user receives information on which services have completed processing the query, how much data has been processed, and/or how much work/time is required to complete the query

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

Medium.

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?

Minimally, the user should be informed on which services have completed execution of the query, which are still working on the query, and how much time has passed for each service.

...

Use Case Number

INIT1SD2.pm7.2

Brief Description

After receiving a status update that a federated query has completed on some services, the user may want to fetch and view the results from the completed sub-queries.

Actor(s) for this particular use case

Cancer Researcher

Pre-condition
The state of the system before the user interacts with it

A federated query has been submitted to multiple services and a subset of them have completed.

Post condition
The state of the system after the user interacts with it

The user receives intermediate data from the completed sub-queries.

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. The Cancer Researcher finds from a status update that a subset of queries have completed from his federated query
  2. The Cancer Researcher selects the services that he'd like to fetch the intermediate results from
  3. The Cancer Researcher fetches those results and views them while the other sub-queries are being completed by the other systems

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

Medium.

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 Cancer Researcher can view intermediate results in order to determine whether to continue the processing of the federated query.

...

Use Case Number

INIT1SD2.pm7.5

Brief Description

Some queries can be intractable or impractical to complete.  When the level of complexity of these types of queries is well understood, it is important that the Software Engineer is able to configure the query processor to handle them appropriately.  This includes the amount of data that can be returned, the length of time that can be spent processing a query, and the number of joins that are allowed.

Actor(s) for this particular use case

Software Engineer

Pre-condition
The state of the system before the user interacts with it

A service has been developed that supports queries.

Post condition
The state of the system after the user interacts with it

The service is configured to handle complex queries appropriately.

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. The Software Engineer configures the handling of different aspects of query complexity, including the amount of data that can be returned, the length of time that can be spent processing a query, and the number of joins that are allowed
  2. The Software Engineer deploys the service

Alternate Flow
Things which would prevent the normal flow of the use case

The Software Engineer changes the configuration of a deployed service.

Priority
The priority of implementing the use case: High, Medium or Low

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?

Minimally, the number of joins and amount of data returned should be supported.

...