RE: Use case: tiger map/census data: have it your way

Dan:
> But I agree with Patrick: a good way to get a sense of it is to tell
> each other stories about it and see if those stories line up.

Expressability in technical terms shouldn't be a gating criteria for a use
case.  If "expressed in terms of" is not restrictive, then fine.  But if it
is restrictive, if use cases are not considered, or not considered as
significant, if they aren't expressed in technical terms then I think we
loose out.

	Andy

----Original Message----
From: Dan Connolly [mailto:connolly@w3.org]
Sent: 18 March 2004 15:13
To: Seaborne, Andy
Cc: Patrick Stickler; RDF Data Access Working Group
Subject: RE: Use case: tiger map/census data: have it your way

> On Thu, 2004-03-18 at 09:03, Seaborne, Andy wrote:
> [...]
> > Patrick:
> > > I think it's useful if our use cases are expressed in terms of
> > > the anticipated DAWG recommendation,
> > 
> > While I have sympathy with having use cases be framed in terms of the
> > future rec (i.e. diving into tehtechnical), I am also aware that, as
> > a group, we do not have a sense of what that recommendation is.
> 
> But I agree with Patrick: a good way to get a sense of it is to tell
> each other stories about it and see if those stories line up.
> 
> I think what he's suggesting echoes another one of the qualities
> of the ideal use case that I gave earlier:
> 
> "
> The ideal use cases will
> 
>   -- clarify one or more requitements
> "
> 
> My hasty use case description fell short of ideal on that count.
> 
> >   I like the qualities Dan
> > provided as they are outwardedly focused, not technology focused. 
> > Getting engagement with the wider audience means talking about the
> > value provided and less about the "how".
> 
> Yes, the outward focus is critical. But the "how" needs to be in
> there somewhere, eventually.
> 
> > 
> > So I see use cases serving as input to a refinement step.  Let's not
> > jump too early and only make use cases a technical description.  The
> > need for a technical feature needs to be backed with an illustrative
> > use otherwise it is a requirement with unclear value.
> > 
> > If we find that many use cases are covered by one technical aspect,
> > then that's good.  We will come out of the first phase with concise
> > requirments that cover a range application/user needs.
> > 
> > 	Andy

Received on Thursday, 18 March 2004 10:33:53 UTC