From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 16 Apr 93 03:23:57 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!portal!cup.portal
.com!R_Tim_Coslet@ucbvax.Berkeley.EDU
Subject: Re: more re: If Ada isn't the problem, what is?
Message-ID: <79596@cup.portal.com>
List-Id: <comp.lang.ada>

>>   No, I'm not.  And that's obviously NOT Ada's fault.  A related 
>>	problem not in>   the list (or I missed it) is:
>>
>>   "Specs written by semi-FORTRAN-educated engineers who don't 
>>	know the difference  between requirements and implementation."
>>
>>   Which means that programmers have to try to persuade management 
>>	Ethat "searching  a monstrous array of characters for a particular
>>	substring and using that substrings location in a computed GOTO" 
>>	is not really a requirement.
>
>
>
>I have actually had a requirements document stating that a variable must
>be at a specific memory location.  It did not matter if the variable 
>was even used or not; it had to be at that location.

I like writing software problem reports to systems saying things like:
"remove implementation details from requirement 1.3.34.5"  :-)

Generally they seem to come back with something like "what implementation
detail" and I end up rewriting it FOR them to show them how to not
specify implementation.

Example:

	Was something like:

		Test memory in with incrementing address pattern.

	Becomes something like:

		Test memory with an address pattern calculated to
		exercise all bank select lines and address lines
		on every memory device in all memory banks.

This usually gets a response something along the lines of "oh, that was
what I intended to say in that requirement anyway. I didn't realize
the incrementing pattern was implementation detail" and they go off
an use my example as their requirement change.

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena