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 23 Next »

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


  • No labels