From: Andrew Gabb (agabb@tpgi.com.au)
Date: Mon Oct 13 2003 - 12:50:17 EST
David Lightstone wrote:
> I think my choice of the word - unique - was a bit poor. Each
> method of analysis will yield a different collection of derived
> requirements. Any two such collections (derived by different
> methods) will or will not be equivalent. (by analogy - the
> distinctly different formulations of quantum mechanics by Dirac,
> Heisenberg and Schrodinger are equivalent. Hence, to me it is
> meaningful to ask if one collection of requirements is equivalent
> to another). If they are not equivalent something is wrong.
>
> I believe this is equivalent to your concern about inadequate
> engineering
Perhaps, at least in part. But this is a very good point, David, and definitely worth chewing over. I'm definitely in agreement with your concerns here.
Working on one level, as we refine requirements through RE/RA, we may be replacing set A with set B (talking about sets of requirements), even where B is an extension of A. We would like to believe that set B is actually an improvement on set A (ie reduces project risk). If it wasn't, we shouldn't have embarked on the 'refinement' task. But this also means that sets A and B *cannot* be equivalent.
Instead, we might think of requirements (as I do) as being a step between goals and implementation, and that A and B both reflect the same goals. The same situation might arise, for example, where two teams independently capture and define sets A and B, but working to the same goals.
In reality, it won't be that simple, unless the goals are very simple themselves. This is because sets A and B are likely to be a superset of the requirements implied by the goals, and they are likely to be *different* supersets. In other words, implementations based on A and B are likely to be different, and achieve performance (hopefully positive) beyond that circumscribed by the goals.
This will annoy those purists who are screaming 'gold-plating', but it's a fact of life (yet another quiver in my Impurity Principle arrow :=). For example, we all have a goal to develop documents and MS Word will normally be the solution. The fact that we only *use* 10% of Word's features doesn't bother us at all - well, hardly ever. If we had to write requirements for our wordprocessor, we may or may not include some of these functions (but someone else in our team will).
This is also why I look at reqs capture etc. as almost identical (conceptually) to design, and why an activity which superficially appears simple is actually extraordinarily complex (and in my case is almost as difficult/cerebral). Like design, the reqs 'step' further limits the space of all possible solutions. Like design, our work products (specifications, say) need to be validated and verified. Like design, we may spend a great deal of our effort finding viewpoints, models and representations which improve the understanding and assimilation of our products by both ourselves and others.
Extending the discussion above to include the various levels of design (using a SyE viewpoint) involves RA and design at the different levels, with each design of a system, subsystem, component, resulting in 'new' requirements for each element. This is what I refer to as the reqs/design flick-flack.
In this situation, different designs will result in different derived requirements (for the next level components), which are likely to be far from equivalent, and which again may provide supersets of performance in relation to both the goals and the predecessor requirements. I think the real trick is working out which is the 'best' solution in terms of cost, schedule, performance. Unfortunately, it's a little too easy to lose sight of the original goals in doing this.
And this is why we need to both verify and *validate* all work products, even though many system engineers hate me for saying it, and it is rare for SyE standards or models to include work product validation activities. (Instead they tend to restrict validation to requirements and end-products.)
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Wed Oct 15 2003 - 14:23:04 EST