Business, stakeholder, system and technical requirements - More thoughts

On the Requirements Engineering Newsletter, Roger L. Cauvin wrote (responding to something I wrote):

Keith Collyer (keith.collyer@uk.ibm.com) wrote:

> System requirements define (but not design) the solution to the
> problem . . . . [T]hese requirements define what the system must
> do to provide the desired capability.

I agree with much of what you wrote in the rest of your message, Keith, but this particular statement highlights again how oxymoronic requirements terminology has become.

How is it possible for so-called "system requirements" to define but not design the solution to the problem?

Let's say one of my problems is that it takes me too long to do my taxes. I challenge you or anyone else to "define what the system must do" to solve this problem without introducing any design choices. Is there anything that the system truly MUST do to solve this problem, aside from create a condition in which it no longer takes me too long to do my taxes?

Here is my response:

the way I think of this is quite old-fashioned, in terms of function, the business requirements define why a system should do something (what I want to achieve), the system requirements define what the system must do to deliver what I want to achieve, and the design defines how the system does it. Of course, quality / constraint / non-functional requirements need to be taken into account throughout.

So, if your business requirement is "reduce the time taken to do taxes", then I would say that you need to do some analysis to understand what this means, still in the business area. Let's say that it breaks down into three activities (please don't argue with these, they are intended just as examples):

• collect income and expense information
• calculate tax
• complete tax form

These are still stakeholder requirements, as they are decompositions of the original requirement and still reflect what you want to achieve, within the context of the environment in which you work (in some jurisdictions you calculate your tax, in others the tax authority does). So now work out which of these is costing you most time and you know where you can save most time. At this point, you are still defining the problem. Say the place you can save most time is in calculating tax. Now I can say what a system must do, it must calculate tax, faster than I could do it, using the collected information. I'm not saying anything at all about how it calculates tax.

This system requirement happens to be a fairly simple restatement of the decomposed stakeholder requirement, changing the focus from what I want to achieve to what the system must do - and that is common, but not inevitable.

Powered by ScribeFire.