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.

Business, stakeholder, system and technical requirements

Terminology bedevils requirements. So here are my views on some common terms.

Business requirements generally define the problem to be solved. The general term we used in Telelogic's Professional Services was "stakeholder requirements". Some people divide these up into levels and differentiate Business and Stakeholder requirements, but they are really just different levels of problem definition. For example, the CEO's view of the problem is necessarily less detailed than that of the department heads. In terms of (at the risk of re-opening a different debate) "function", these requirements define what the business (or stakeholder) wants to achieve - the capabilities. But they must also define all those other types such as performance, security, usability, etc. - and if you don't like the term non-functional for these, then we used "constraint". It's not perfect, but I think it worked better than non-functional without some of the confusing connotations of "quality requirement".

System requirements define (but not design) the solution to the problem. Again, there can be (generally are in a non-trivial system) several levels, for systems, sub-systems, components, etc. In terms of "function", these requirements define what the system must do to provide the desired capability and we were quite happy to call these functions. Again, there will also be constraints in the system requirements.

Stakeholder and system requirements, especially constraints, can be identical. For example, physical constraints, such as a maximum weight, are often identical.

Oh, it is also important to note that you can't always (probably not in general) separate constraints from capabilities or functions; most (but not all) constraints are tied to a single capability (function) or a related set.

Powered by ScribeFire.