From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sun Oct 19 2003 - 13:01:07 EST
David Lightstone wrote:
> ----- Original Message -----
> From: "Andrew Gabb" <agabb@tpgi.com.au>
>>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.
>
> I would like to believe that there is a traceability relationship between
> element of your B and elements of your A.
> If this is so then there the traceability probably (not certain yet)
> establishes a partial ordering (in the mathematical sense) upon the sets A,
> B, and other refinements
You certainly can't guarantee the traceability, but I'd like to believe it too. <G>
If set A were correct, complete, consistent, etc., and the 'refinement' activity was also flaw-free, I think I'd accept an assumption of full traceability. In practice I've never seen a set of requirements for a complex system that met these criteria in toto. Impurity strikes again!
It's also important to accept that 'additional' requirements do creep in as part of the refinement or flowdown in many cases. There are a number of reasons for these:
# Correcting (possibly small) errors or omissions in the source reqs. # Simplifications such as making reqs more generic. # Attempts to 'steer' the reqs towards a preferred solution set. # Adding in design constraints including tech. regulatory constraints. # In some cases, it is impossible to define more detailed reqswhich do not extend the reqs to some degree.
None of these are necessarily bad reasons, and they happen all the time, including in shops who pride themselves on their careful reqs management. This also applies to modifications and deletions, of course, not just additions. Many of the texts however assume that this doesn't or shouldn't happen.
I joined a major defence project (acquirer-side) in the UK many years ago, which was well into its (long) development stage. For the first few months I did a full reqs/performance trace from high level reqs through to implementation and test - something that was poorly documented. I found two major requirements in the highest level SOR (~10 pages) which were not addressed elsewhere, ie which had no traceable derived requirements.
It caused quite a stir, *not* because there was an actual omission as such - time had clearly overtaken both requirements - but because the high level SOR was the 'legal' basis for the acquisition, and the necessary correction was a little embarassing for the project. Good RM would have avoided this embarassment, but the RM (such as it was) did not extend that high. The fact that the contract was 'cost-plus' rather than fixed price was also an important factor.
I'm certain that I could find examples of non-equivalence in any complex project, regardless of the experience, skill and sophistication of those involved.
> In the sense of the partial ordering one could define equivalence via A is
> equivalent to B if there exists a consistent collection C that refines both
> A and B.
I think you're stretching the word 'equivalent' here out of all recognition, but I probably agree with your suggestion as a test of 'similarity'.
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 : Mon Oct 27 2003 - 09:00:13 EST