XBC use cases

Hi,

I tried to explain the approach taken in the XBC Use Cases (http://www.w3.org/TR/xbc-use-cases/ 
) but my phone connection was dreadful so apparently it was largely  
lost. So I thought I'd just drop it here.

The problem we were faced with was that there were too many  
requirements for one technology (in this case binary XML): everyone  
wanted to solve their pet problem in a single. There was no way anyone  
could produce a useful technology that would address all of those  
needs, at least not without resulting in a device or apparatus that  
would single-handedly drive Lakeland[0] out of business while proving  
the four-colour theorem for an encore.

The process we used to whittle it down was largely based on the use  
cases: first each use case would list which properties it would need  
the solution to have in order to be successfully addressed (a property  
is a requirement that can be measured), as you can see in the document  
(it also lists the could-haves and the nice-to-haves for greater  
granularity).

We then looked at which properties were needed most (see http://www.w3.org/TR/xbc-characterization/#N10105 
  which is part of the conclusions document), and more importantly  
which ones were only needed by a limited number of use cases. The idea  
was that we would drop the latter as requirements, even if it meant  
that some use cases would not be addressed.

This approach had the big advantage that it really kept people honest  
about what they really needed, rather than what their pet peeves were.  
It limited the requirements to those that gathered broad consensus,  
and tended to cut short the discussions typical of many committees in  
which a single stake-holder pushes hard for a requirement: there was  
little economic value in spending energy on something that was going  
to be cut off at the end because your needs were too different from  
those of the group.

I'm not sure that it can apply directly to this group as its situation  
is different, but I thought I'd bring it up as one possible approach —  
maybe some bits of it can be adapted somehow.


[0]http://www.timesonline.co.uk/tol/comment/columnists/caitlin_moran/article2748804.ece?openComment=true

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 25 June 2008 15:17:57 UTC