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.

...

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- Ability to ping the status of FQP threads so that for multi-threaded queries, we can return status reports to the users so that they know what services have returned results and what services we're still waiting on.
1.2 Ability to kill a particular thread, so that if the user doesn't care that much about the particular service that isn't returning quickly, they can kill that thread and keep all of the other threads going.
1.3- Ability 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- Ability to return results incrementally if there is not a When a query without any cross-service join . FQP aggregates all results before returning anything, because they want to be able to join results across different servicesis submitted to run on multiple services the user should get the results as they become available.
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. Example: Limit the number of joins a service will support, so that if you try to create a 5 table join in caArray and caArray only supports four joins, FQP would kick back the query.

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

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

...