Re: Charters for review

On Wed, 2006-11-22 at 13:38 -0600, Dan Connolly wrote:
> [...] people naturally clump
> into groups of 3 and 10 and 100 and 1000 and so on;
> see http://www.w3.org/DesignIssues/Fractal for details.
[...]
> > The development of the test suite is another matter, but I would  
> > expect that the majority of it arrives after CR.
> 
> There lies madness.
> 
> Start with test cases and story telling* and let the spec(s) fall out
> naturally between them.
> 
> *story telling, whether it be conference presentations and tutorials,
> use cases, requirements, blog articles, whatever.

Reading over what I wrote, I realize I should distinguish requirements
documents as a reasonably useful mechanism for dealing with the
boundaries between groups of people.

The pattern lives in the ESW wiki.
  http://esw.w3.org/topic/RequirementsDocument

I think it's worth excerpting pretty much the whole thing here:

[[
Design discussions can get disconnected when some of the parties aren't
interested in this part of the design because they don't see the purpose
of it. Therefore, tell each other stories and write them down in a
RequirementsDocument. 

     1. tell stories that engage your audience/community 
        
     2. derive requirements 
        
     3. evaluate design options against requirements 
        
     4. when they conflict, take it seriously: consider chaning
        requirements (i.e. demoting some to "goals") 
        
     5. document non-requirements too; i.e. stuff that would be nice but
        isn't part of the "minimum required to declare victory" 
        

Requirements should be objective and testable. This is not to say that
things that are not testable have no place; the design goals of XML 1.0
were an important part of the consensus process. But design goals,
objectives and the like should be clearly distinguished from testable,
objective requirements. 

The OWL requirements document, like many others, served as an effective
interface between the producers and the consumers of a spec. This works
well when peers and customers make their requirements clear, a la "I
require XYZ". Their experience is also constructive: "we have had good
luck meeting requirement XYZ with solution ABC". But if they start
saying "you have to meet requirement XYZ with solution ABC", that gets
awkward; parties that want to be involved in choosing the solution
should join the WG. 

Several times during development, and again at last call, the WG should
double check the design against the requirements requirements. 

Since W3C working groups often include people who weren't directly
involved in writing the charter, a requirements document can help
develop group ownership of the goals and direction. The charter should
say "The AC asks us to do this and not that." The requirements document
recapitulates the charter, more connected to user community. 

See also: wikipedia on Requirement, QA.
]]


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 22 November 2006 19:50:02 UTC