From: Andrew Gabb (agabb@tpgi.com.au)
Date: Thu Sep 11 2003 - 10:58:56 EST
From: Donald Firesmith
> I have nothing against architecture, design, implementation,
> or testing
> constraints as long as they are 1) necessary (for whatever
> reason including
> the customer saying "because I said so") and 2) they are
> clearly labeled as
> such. The problem is people intending to write a pure requirement and
> accidentally specifying a constraint instead (e.g., because
> that is the only
> way they know how to do something, so they think they are
> specifying a what
> rather than a how). This is all to common (e.g., someone
> specifying user id
> and password when specifying identification and
> authentication requirements
> and not realizing that this is an architectural decision
> because there are
> many ways of identifying and authenticating someone including
> biometrics and
> tokens such as smart cards).
All quite true. However, as someone who has spent more hours than not working for the customer in the customer domain, I understand where some of this comes from, and it's not always as obvious or as wrong as it may seem to a downstream developer who has a more straightforward task (although it sometimes is wrong - perhaps often - it depends on the sophistication of your customer *and* supplier).
Some reasons are given below. Some are excuses, others are justifications, some both.
# Users, like engineers and managers, tend to naturally think in terms of solutions rather than requirements. Hence they often 'specify' half-baked solutions rather than requirements. I have no problem with this. I would *far* rather have the users present me with a weak or incorrect solution (and then use it as a basis for further elicitation), than to avoid the subject (and lose the requirement). I've seen relationships between 'REs' and users where the users were afraid to open their solution-sodden mouths. You can guess the results.
# Often a partial solution, or example, is much easier to describe than a requirement. If the customer states that she is happy with password security only, it gives a good indication of the level of sophistication that needs to be put into privacy, confidentiality and integrity.
# Suppliers are renowned the world over for screwing up the solution to the benefit of their margin and the detriment of the customer, or just through plain incompetence. A technically capable customer will try to avoid what are perceived as poor solutions by tying down some aspects of the solution. It's much easier to do this by constraining the solution space than by getting the requirements to a state where the supplier can't screw up the solution. (In fact, in complex projects I believe it's impossible to tie down the requirements sufficiently anyway - that's the essence of my Impurity Principle).
# In some cases the customer is more technically capable than the supplier in some aspects of the problem (this is relatively common in defence systems).
There are of course counter-examples to all of these, and the last thing I'm trying to do is defend solution-oriented 'requirements' (I've been fighting them all my life). However, I think we need to get used to statements of requirement which include some solution information, ie face the world, rather than wallow in purity, idealism and academic bliss (not you, Donald).
Andrew
This archive was generated by hypermail 2.1.6 : Wed Oct 15 2003 - 14:23:02 EST