Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!abvax!iccgcc!kambic
From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.)
Newsgroups: comp.software-eng
Subject: Re: Metric for Requirements Complexity?
Message-ID: <4784.284bc24d@iccgcc.decnet.ab.com>
Date: 4 Jun 91 21:39:40 GMT
References: <gary.675044073@suite.sw.oz.au>
Lines: 57

In article <gary.675044073@suite.sw.oz.au>, gary@suite.sw.oz.au (Gary Corby) writes:
> Given two Software Requirements Specifications, is there a metric which
> will describe the relative complexity of the systems they describe? 
> Please note I am referring to the complexity of the system, rather than any
> sort of stylistic measure of the document per se.
> 
> We are looking for this sort of measure because we wish to determine whether
> we are getting better or worse at writing SRS documents as time goes on.
> This seems to require measuring the number of faults discovered in each SRS
> document and plotting the values as a function of the date of writing.
> The only problem is that not all SRSs describe equally complex systems,
> and more convoluted systems can expect to contain a greater number of errors.
> 
> Does anyone know a solution or have a suggestion?

Solutions - never.....suggestions - always.

I have read a few of the replies to your post, and they started drifting back
into the metrics discussion again, which is relevant, but IMHO not complete.  A
number of the replies mentioned some very interesting metrics (rutabagas,
coffee comsumed, etc.) that could at least be theoretically correlated to
success.  I don't recall seeing the old nostrum: correlation does not imply
causation.  The correlations will be especially difficult to determine because
of the Hawthorne effect also, but you gotta start somewhere.  

I am in fundamental agreement with those who propose some measures, collecting
some data relative to those measures, computing some metrics, and then trying
to determine some correlations.  But then you must perturb the process to find
out if your correlation holds true.  If your perturbed measure does not change
the success rate, then maybe what you are measuring is of no value.   And you
do not know a priori what measures you should use.  Start somewhere. 

Another issue: you discuss complexity of the system.  I think what you really
want to know; is the content of the SRS describe a successful product?  Could
you not apply McCabe's measure to any executable specification language?  Could
you in some manner construct complexity diagrams of the SRS?  Heck, try
diagramming the sentences, treat it as a graph, make the ends connect, and
compute complexity.  You'll have a number.  It may tell you something about how
you write the English language.  See if reducing this number reduces the number
of errors detected in design, etc.

Last issue:  What do better and worse mean?  If your English is better, is your
content necessarily any better?  Vice versa?  As I said earlier, I think what
you want is a measure of how closely your original SRS content accurately
described the resultant product multiplied by customer satisfaction with that
product.  If customer satisfaction is zero for a perfect SRS, you are out of
business.

George X. Kambic
[...]
Section 1.2.5.a.x of net functional specification
	The user shall disclaim all information on the net.

[...]
Execution: I disclaim all information I place on the net.

Wow!  I met the spec.