From: Andrew Gabb (agabb@tpgi.com.au)
Date: Thu Oct 09 2003 - 20:31:07 EST
David Lightstone wrote:
> As a rule I am very uncomfortable with derived requirements. The uncomfort
> stems from a belief (most likely irrational) that they will not be unique
> coupled with a desire to identify when uniqueness is absent. There may be
> multiple mechanisims for analyzing the input, each mechanism resulting in a
> different collection of derived requirements. Implicit here is a need to
> make a decision as to which collection will be used. That decision will
> appear to be objective, but I speculate it will be either a very subjective
> decision or a design decision. The appearance of objectivity will stems from
> an unawareness or deliberate exclusion of the alternative analysis
> mechanisms.
I'm not really concerned about uniqueness, and in fact they often will not be unique. For example, if we follow the traditional approach of flowing down requirements, it is quite likely that some requirements in the system spec (SS) will flow down to one or more SRSs virtually unchanged.
My nervousness with derived requirements is more about completeness of flowdown and derivation in the reqs/design/reqs/design flick-flack. For example, how to you ensure (or verify - see below) that a set of derived requirements completely encompasses the requirements they are intended to reflect (as shown in the reqs traceability links). Like your concerns, this is probably somewhat irrational and more a concern about incompetent engineering - which can screw up any project from any otherwise sound position - or perhaps just a light going on in my head showing an area of potential risk.
> Earlier this year there was an ongoing discussion of verification and
> validation. At the time I suspected that multiple contexts/perspectives (I
> think the formal word is ontologies) were present. I suspect the problem of
> soft requirements provides an example which will serve to clarify those
> perspectives. One can verify against those derived requirements, but the
> requirements themselves must be validated.
At the risk of opening the V&V can of worms again, here is my take on the V&V aspects of this issue.
#1 User requirements (and operational concepts, use cases, etc.) need to be validated against the current user needs.
#2 The end-product (and in my and others' view almost all work products) need to be validated against the current user needs. (Validation differs from verification mainly in that it provides assurance that the end-product will be suitable for intended use.)
#3 All work products also need to be verified against the specific requirements for those products.
#4 Derived requirements stem from higher level requirements and eventually from some form of user requirements. There is some debate on this issue, but ensuring that derived requirements conform to (or encompass) and trace to user requirements can be regarded as a form of verification. However, as noted in #2 above, there should also be a validation component.
Note that here (as is usual) I'm using the term 'derived' to denote those requirements derived from a higher level (eg SS -> SRS). I tend to use the word 'refine' where a user requirement (for example) is replaced by other, often more detailed requirements as part of the RE process.
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