Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!mephisto!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: "Correct" IS UNDEFINED!
Keywords: proof, correctness, theory, balderdash
Message-ID: <17270@duke.cs.duke.edu>
Date: 2 Feb 90 14:43:27 GMT
References: <17142@duke.cs.duke.edu> <13211@cbnewsc.ATT.COM>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 41

In article <13211@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>In summary, then:
>
>a) Requirements are somewhat relative.  If customers really need
>or want a product, they aren't going to let textbooks stand in
>their way.  Conversely, mere fulfilment of textbook requirements
>is no guarantee that customers will buy your product.
>
>b) Market needs and wants change continually.  A development
>process that attempts to "freeze" requirements may put out
>products that are obsolete the day of their introduction.
>
>
>	Lawrence G. Mayka
>	AT&T Bell Laboratories
>	lgm@ihlpf.att.com
>
>Standard disclaimer.


Sure, sure.  But there's a big difference (which I've noted more than
once) between "meets requirements" and "the requirements really
describe what is needed".  But you have to look at it sort of like a
contract: if you contract with me to build a system that meets a certain
collection of requirements, and I do so, then the system must be
correct.  If it turns out you wanted another system, then I can build
that too; what I can't do is read your mind.

On the other hand, what we really want is satisfied customers; there has
to be some way to pry from the customer or client what they *really*
want, make sure it is feasible, and then delvier it with high certainty
that what you deliver is what was finally agreed upon.

The domain of verification is this second: give a specification and I
can mathematically argue with great certainty that I have built it.

I don't know the solutino to the first; the solution that appears best
is incremental development and prototyping.  It isn't easy.  I don't
think it will ever be easy.  But all verification promises is to
increase the trust in the realization meeting the specification. 
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)