🚀 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++.    *

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.

In article <1991May30.171315.4195@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
>>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.
> 
Consider also a specification quality attribute I call maintainability.  This
attribute refers to the maintainability of the specification itself.  There are
a variety of factors which have an impact on the maintainability of a particular
spec including:

modifiability
traceability
annotation
organization
understandability
cross referencing
electronic storage scheme

Definitions for these quality factors can be found in IEEE/ANSI Standard
830-1984 and other related documents.  A possible metric of maintainability
would be the traditional concept of MTTR or better still, MTTC (mean-time-to-
change).  In addition, one might be able to apply the SE concepts of coupling
and cohesion in some sense between specification statements or sections and
derive some interesting metrics.

I hope this is useful.

***********************************************************************
Scott P. Overmyer
Center of Excellence in C3I
Information Systems and Systems Engineering
George Mason University                      Phone: 703.764.6523
Fairfax, Virginia 22030-4444 USA             Fax:   703.764.6526
email: overmyer@gmuvax2.gmu.edu
***********************************************************************