🚀 go-pugleaf

>What are the factors contribute to the complexity in making 
>changes to the requirements specification?

There are a number of factors (I discussed requirements complexity
in a recent post to this group, so please see that for details),
but I think by far the most significant factor is the degree to
which the requirements specify IMPLEMENTATION decisions as opposed
to just the requirements.

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. It has been my experience that the more implementation
decisions are made in the requirements, the more impact a change
to the requirements has on the project, since conceivably quite
significant portions of the implementation can be affected.

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),
but often I think this is done without much justification. I'm
unclear as to what motivates this: some may be mistrust of the
contractor on the part of the person writing the checks, some
may be reluctance to deviate from what has worked in the past,
some may just be a misplaced desire to be a designer on the
part of the requirements writer. In any event, gratuitous inclusion
of implementation specifics in requirements specs should be 
avoided.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *