- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 23 Oct 2001 16:05:33 -0600 (MDT)
- To: Mark Skall <mark.skall@nist.gov>
- cc: www-qa@w3.org
On Tue, 23 Oct 2001, Mark Skall wrote: > Specifications are not designed for human interaction. They are > designed to communicate requirements in the most precise way > possible. The fact that human interaction is required after the > spec is promulgated only goes to prove that the English language > has not worked as a precise way to communicate requirements. Specifications are still written for humans. They should be designed for human-specification or for human-text interaction. Human-human interaction is indeed not necessary (in theory). The "human" part is still there though. > Why not eliminate mistakes for all software development? The > answer is because it costs too much to do it right and to use > sophisticated mathematical languages to define requirements. I doubt that is the answer. The answer, IMO, is because it is impossible -- the problem domain (all software development) implies fuzziness and errors. Like nature, software systems cannot be build to be perfect, no matter how much money you spend on specs or tools. > XML is a compromise. It's not as precise as these languages but > much easier to use and less costly to develop specs using it. Dry, spec-oriented English is a compromise. It's not as precise as these languages but much easier to use and less costly to develop specs using it. In fact, XML per se is almost as informal as constrained English so the benefits of using it instead of English must be minor! But we digress... The question was "should most W3C specs have embedded test cases?" My answer was that embedded test cases are evil because they increase the number of conflicts; one requirement should be documented once. The other question was "should most requirements be written in XML or RDF?" My answer is no, but I am sure I am in a minority here. Alex.
Received on Tuesday, 23 October 2001 18:05:35 UTC