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.
- tell stories that engage your audience/community
- derive requirements
- evaluate design options against requirements
- when they conflict, take it seriously: consider changing requirements (i.e. demoting some to "goals")
- 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.
wondering if this fits Wiki:ThereforeBut