- From: <skall@nist.gov>
- Date: Sun, 8 Sep 2002 22:14:17 -0400
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: Mark Skall <mark.skall@nist.gov>, www-qa@w3.org
Quoting Alex Rousskov <rousskov@measurement-factory.com>: > > On Sat, 7 Sep 2002, Mark Skall wrote: > > > 3) which a person or software can check that the requirement has been > met > > > > Software (perhaps combined with human judgement) does "check" that > > the requirement has been met. It may not "prove" that the > > requirement has been met, but it certainly checks. In fact, if done > > correctly, it "checks" with a high degree of probability that the > > checking is correct. > > Nice trick! Can you come up with any example (real or imaginable) of a > spec that will not be testable according to your interpretation of the > phrase "check the requirement"? No, this is not a trick. Just like in testing, one can only test exactly what the spec says. Likewise, we are only allowed to analyze what our spec says - ceratinly not what you think it says. Again, what it says is "check". Of course, thee are many specs that are not testable with the "check" phrase. The whole point is that requirements can't be "checked" if they are not precisely defined and what we are encouraging with this wording is the exact wording of requirements. If a requirement is ambiguous, contradictory, or just plain vague it can't be checked. > I can "check" anything if the "process of checking" implies nothing. I > can say that I "checked" a requirement if I simply read it! What is > the point of introducing a definition if practically all specs satisfy > it? Again, read the above response. A requirement can't be "checked" unless it is precisely defined.
Received on Sunday, 8 September 2002 22:14:25 UTC