dyip@axion.bt.co.uk (David Yip) (05/30/91)
What are the factors contribute to the complexity in making changes to the requirements specification? David .
jls@netcom.COM (Jim Showalter) (05/31/91)
>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++. *
brendan@cs.uq.oz.au (Brendan Mahony) (05/31/91)
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.
overmyer@gmuvax.gmu.edu (05/31/91)
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 ***********************************************************************