> There's no mention of requirements, let alone > "meets all requirements".
It doesn't say anything about specifications either. You proposed that specification was the criteria to judge whether something is correct. I was merely pointing out that there is a common understanding of the relationship between requirements and specification. I merely did this because of your bizarre argument that requirements are not related to correctness. I generally wouldn't need to point out such trivial facts in a sane and rational discussion.
> > The definition of specification that would apply here > > would be: "precise documentation of requirements." I > love > > that you accused me of 'quarreling over definitions'. > > The definition of specification that would apply here > would be a definition of software specification - > not some random jumble of general definitions from other > fields.
So do you believe that in software engineering we use normal English words in ways that are incompatible other fields, including engineering?
What definition do you think 'specification' has in our field, exactly? Or alternately what do you think the definition of 'requirements' is in our field? You don't do 'requirements gathering' or have never seen the results of this (generally called 'the requirements')?
It was you that quoted 'specification' as the criteria for correctness.
> > Do you mean, a software application with no > requirements > > is correct? Or more clearly, a software application > with > > no requirements cannot be incorrect. ... > > I mean your indulging in absurd word games, without any > relevance to what we know or don't know about programming.
You are the one trying to redefine words in order to prove your argument. Trying to make up a new definition for the word 'correct' is an absurd word game.
There is no doubt in my mind that the term requirements is understood to include a formal specification of requirements and a number of assumed requirements such as 'runs without crashing' by anyone who speaks English and has worked for any significant time in the software industry. In any real sense of whether the software is 'correct' would be derived from the required properties and functions of the software (a.k.a 'the requirements') and not based on whether it passes a test.
The concept that passing all tests makes the software correct is patently absurd. If the program crashes are you seriously going to argue that it is 'correct' because it passed all tests? Testing is a way of trying to gauge the correctness. It doesn't define the correctness of software unless you requirements are specified as passing a number of tests which would severely limit the kinds of requirements that could be defined. Testing is equivalent to an experiment, which in scientific terms is a 'test of a hypothesis'. The experiment does not define the hypothesis.
Previous Topic
