NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Scrollbar
iconsfalse

...

Page info
title
title

Pre Interview:

Item

Information/Response

Date

12/18/2009

Requirement # unique id <SemCon Ops Initiative>.<analysts initials><requirement number>
e.g. Init1dbw1
(eventually linked to Use Cases)

Init1SD2

Originator/Customer's Name:

Todd Parnell/NCI forum                                                                           

Originator/Customer's Company:

NCI

Summary of requirement pre-interview, by Reviewer:

Related to the Federated Query Processor

1.1- When a query without any cross-service join is submitted to run on multiple services, caller should be able to view the status of individual query submitted to each service anytime after the submission. In case the service, returns results, user should be able to get the data even though query is still running on other services.

1.2 When a query without any cross-service join is submitted to run on multiple services, caller should be able to should be able to stop the query at a particular service if it is taking too long for it to come back with results

1.3- A user should be able to ping registered services for how much data they have (like number of objects).

1.4- When a query without any cross-service join is submitted to run on multiple services the user should get the results as they become available. (this is same as requirement 1.1)

1.5- Ability for a user to specify whether or not they want to do a cross institute join.

1.6- Ability to configure in FQP the amount of data a query can return.

Actor:  Cancer researcher
Business goal: make Querying more effiecient
Their is a need to make the querying of services more efficient so that the actor has real time knowledge on the status of query running at each service and the querying process is more intelligent. This will address the usability issue to greater degree. The underlying motivation is to strike a balance between a generic query interface that CQL provides and the ability for a service to specify and enforce restriction on the type of queries it is willing to answer. The key is that these restrictions should ideally be expressible in a standard way and not simply out-of-band. A client should be able to know, for a given query,whether the service will support executing that query.

Recommended Next Step Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room

Interview

...


Scrollbar
iconsfalse