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.

Margaret was right

On The Apprentice last year, Margaret Mountford was heard to say that the University of Edinburgh was not what it used to be. Having just seen them only just beat a team which had a homoeopathy student in its number, I can only think that she must be right.

Powered by ScribeFire.

All songs rated

160GB iPod
roughly half-full
nearly 11000 songs
all rated! woo-hoo!

Agile versus the traditionalists - Part 1

I have called this Part 1 because I suspect know that this won't be the last entry in this blog on the topic. It's just too big.

Let me make my position clear. I am firmly in the "traditionalist" camp. But, having said that, I think that there is a lot of value in agile approaches. I'm certainly not going to dismiss it out of hand. Of course, some practices associated with agile (like pair-programming) have proved to be less effective than the original proponents claim, but there is a lot to be said, in many environments, for ideas such as test-first design, use of backlogs, user stories, etc. But there is also a lot to be said, in many environments, for having documented requirements specifications.

For an excellent description of what I am talking about, see David Parnas's classic paper "A Rational Design Process, How and Why to Fake It" in (D.M. Hoffman and D.M. Weiss, Software Fundamentals: Collected Papers by David L.Parnas, Addison Wesley, 2001). Even though you didn't really develop your product that way, you should make it look as if you had a chronological flow of development artefacts (for example, stakeholder requirements, system requirements, architecture, etc.). Why is this important? Well, firstly, the development team won't be there for ever. So it won't be possible to just walk over and ask Joe. Joe is now working for your competitor. But someone still has to maintain the system, so you need some way of recording the common knowledge. But we have all our user stories, you say. Unfortunately, a list of user stories does not always give a sufficiently clear overall picture. Sometimes, you need to be able to understand the whole system at various levels and user stories just don't do that.

So it may still be necessary to document requirements. Note that "document requirements" does not necessarily mean the same as "requirements document". But a requirements document does allow an overview of all requirements in a form that is familiar to people.

But isn't there an overhead in doing this? Sure, there is. The question, though, is: does the investment pay off? Well, if you are delivering a "small" system, say up to a couple of hundred requirements, it may well not. Such a system probably only has at most a few tens of user stories, and experienced people can hold these in their heads. This sort of development is ideal for agile. But when the numbers of requirements starts to creep up it becomes essential to be able to see the big picture. Another situation when the need for a requirements document occurs, even with a realtively small requirements set, is where the requirement specification forms part of a contract. Software has the great advantage here of being incredibly malleable, and also usable even if not complete. Hardware systems generally have neither of these characteristics. Even something as simple as a garden shed to hold tools would be useless without one of its major components, without walls the weather and theft protection is lacking, without a door you can't put things in or take them out, without a roof you lose weather protection, without a lock you lose theft protection, and so on.

So where is the gain in creating a requirements document? Simply, it presents the requirements in a consistent, navigable and understandable way. So, if something needs to change in the future, it is easy to see where that change needs to be made. This means that it is possible for people who were not involved on the original project to make changes in the full understanding of what these changes mean.

And more: if you don't just create requirements documents, but use a requirements tool, you can also see what information is linked. So when a stakeholder says a requirement needs to change, you can see what effect that has right down to implementation level. Simply having a set of user stories, without the linking, does not allow this. And naïve use of user stories will make it hard to use common components (I have seen this happen in practice, leading to a system that we estimated at being around three times as large as it needed to be because people re-implemented).

So, what do I recommend? Surprisingly, perhaps, I would say "use agile". But use it with your eyes open. Use it where appropriate. And don't be browbeaten into not documenting your requirements just because that is the fashionable thing to do.