🚀 go-pugleaf

In <1991May30.171315.4195@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

>For example, a requirement that a system be able to deal with all
>input in, say, 10msec maximum is a clean requirement: it is not
>tainted by any assumptions about HOW the system will accomplish this
>goal. On the other hand, a requirement that a system use a cyclic
>executive and run-to-completion in order to deal with all input in
>10msec is way too implementation-specific: it specifies HOW, not
>just WHAT.

If you are using a formal top-down development method there is no reason
why you can't the abstract requirements spec and still pass the more
concrete design spec to the engineers. When you make a change in the
design it should be made at the appropriate level of abstraction. Thta
way you don't ahve to think about low level things at the top and you
don't have to think about high levels things when you have you hands
covered in grease.

>I grant that there are sometimes compelling reasons to include
>implementation specifics in the requirements (one may know, for
>instance, that the system HAS to run on a 1750a processor, period),

Even if theis has to be done it should be done in the lower layers of
the development sequence. You should be able to read the the
requirements spec and easily find out just WHAT the system is intended
to do. A choice like using a 1750a processor should be presented as a
design choice even if there was no choice.

>In any event, gratuitous inclusion
>of implementation specifics in requirements specs should be 
>avoided.

Amen.

But the same point should be made about carrying requirements specs down
to the implementation level.

--
Brendan Mahony                   | brendan@batserver.cs.uq.oz       
Department of Computer Science   | heretic: someone who disgrees with you
University of Queensland         | about something neither of you knows
Australia                        | anything about.