From: Andrew Gabb (agabb@tpgi.com.au)
Date: Mon Oct 06 2003 - 20:34:58 EST
Overmyer, Scott wrote:
>> This image of 'hard requirements' is an illusion, pushed on us
>> by academics and mil/aero/space developers.
>
> Hardly. Rather, this image of "soft requirements" is an
> illusion, pushed on us by politically correct engineers that are
> either: 1) unable to make a decision, 2) unable to convince the
> client to make a decision, 3) unable to convince the client of
> the correctness of requirements decisions because they don't have
> the evidence necessary to support the decisions they've made, or
> 4) they are relativists and don't believe that there is a
> "right" way to do anything.
Sigh. Sorry, Scotto, I wasn't trying to get up your nose. I'm often a little too brutal - it saves time, but it annoys people. Sorry again. (Didn't the Kiwis warn you about Australians?) Please let me explain reasonably gently.
I'm *not* pushing soft requirements. I like hard (correct, complete) requirements as much as any developer. And I'm willing, eager in fact, to spend a certain amount of time and effort to harden the requirements until the cost/risk is acceptable. But I *know* that some of the requirements will always be softer than I'd prefer them. And I live with that knowledge and factor it into my ongoing work, both in design and further RE. As do most engineers working at the customer/supplier interface, for large, medium and small projects.
My outburst above was challenging the illusion that it is possible to get our requirements completely hard (except in exceptional circumstances, and they are often debatable). Anyone who believes in this illusion is sending out the wrong message to potential REs. In my mind there is just as much danger in believing that we can and must achieve 'hard' requirements, as in believing that our soft requirements are adequate and that we can't harden them. REs must understand about cost/time/risk tradeoffs, the impossiblity of achieving perfect requirements (my Impurity Principle), and learn techniques for using their time and effort effectively.
Some recent examples:
Ian F Alexander wrote:
> Clearly the attempted reqt 'the system shall be perfectly secure
> against hacking' isn't realistic. 'shall record all logins' is.
I'm sure Ian didn't intend the second requirement to be a total replacement for the first, but some folks I know would. As all of us know, recording all logins may be useful against some hacking attempts, but is a rather pathetic solution to the customer's badly stated requirement. And note, it *is* a solution-oriented requirement, whereas the original one is not. And its implementation may turn out to be of no value at all in detecting hackers - after all we haven't told the supplier *why* we want to record logins, so what will he record? The time?
I've seen clients being forced to accept the second requirement as a replacement by a slick supplier, but also by their own internal advisers, who have been on an RE course (or read a book) that concentrates mainly on 'hard' requirements.
I'm sure we can improve the original requirement, but how hard can we really make it, and at what stage of the development process?
David Lightstone wrote:
> Just as a point of reference, in control system development (i.e.
> auto engine or transmission or suspension control) there is an
> extensive calibration task to be performed.
A few years ago I attended a seminar given by an engineer from one of the major automotive companies. Their market research had shown that many people thought that the gear changes on certain cars 'felt' better than others. They had some subjective evidence of this (and it's also interesting to note that this was not an issue of speed or positive selection but something more subtle - ie it was about what the customer wanted rather than what they may have needed). The engineers were in the process of finding out what 'good feel' meant, and to quantify it to harder requirements.
I'm making two points here. The first was that the 'good feel' requirement (a hateful, spiteful, nasty requirement, but a genuine requirement none the less) was used as input to derive more quantitative requirements. The second is that to validate those derived requirements (or to validate gearbox prototypes) it would be necessary to return to the original soft requirements to some extent, ie to undertake usability testing on the models or prototypes with representative users. Note that such testing is likely to be subjective.
This soft requirement, like the anti-hacker requirement above, won't go away because it still exists at a higher level (unless some misdirected pedant has eliminated it).
P.S. One of the wonderful things about requirements and specifications is that I can look at any of yours, and you can look at any of mine, and we can all find quite valid faults. This should tell us something about our business.
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:03 EST