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