More candidates for requirements and objectives [Was: Re: toward an intial design... any more evaluations?]


> A while back, Yoshio asked, "don't we have to go through the
> document, I mean, check if the issues in the document should be in the
> requirements or design objects?"
>  --

I remember I have a few more candidates for the requirements and objectives.

Sorry to have been lazy, but, all, please give a thought on them.

# I hope it's not far far away too late.

Here we go:

(1) premise


I'm a little bit afraid it may fall into the range of the rule issues, but
we are  do lots of  queries with premises in our daily life.

e.g. Are Mary and Bob friends of a friend if Jane is a friend of Mike?
e.g. What is the lowest price for the product A if shop B does discounts by
20 points from their normal price?

# Hmm, can someone think of more natural examples?

(2) conditional solution(?)

(to the question "How long does it take from Fujisawa to Shinjuku?" (or
whatever cities readers are familiar with))

the system should answer:

"If you take Odakyu line, it'll be 52 minutes, and if you take JR line,
it'll be 68 minutes..."

(3) time limit (protocol issue?)


"Give me all the answer found in N seconds"

(4) volume limit

"Give me the solutions within N bytes"

band-width issue?

# (3) and (4) and 3.10 Result Limits can be generalized?

(5)  data freshness

"Use data (triples) created within 1 year only."

or "Don't use data created before 1 year back from now"

(6)  sorting of the solutions

"sort the solutions in this manner"

already included in "user specifiable serialization" issue?

Has things to do with optional matches?

(7) answering just the number of solutions

"Tell me just the number of the solutions you find for now"

It is useful in an interactive query.
If the number is too big, the user can redesign the query without receiving
tons of  solutions.

Yoshio Fukushige

Received on Wednesday, 16 June 2004 05:46:30 UTC