Software requirements analysis, and why it doesn't work

Tom DeMarco, The Atlantic Systems Guild: "Ill-specified systems are as common today as they were when we first began to talk about Requirements Engineering twenty or more years ago. ... we may have lost sight of some endemic problems that plague not the process but the people who do the process. Is it possible that an engineering approach to requirements is as badly suited to our real need as would be an engineering approach to raising teenagers? I’m beginning to think so ..." 2nd International Conference on Requirements Engineering (ICRE '96)

Numerous studies have shown that over half of software development projects don't work. And the major reason cited is that they don't do what the users actually want: there's a breakdown in the "requirements elicitation" process.

We do not think that this is actually the case.

Requirements elicitation means getting the requirements out of the users (actually, out of that part of the customer organisation that is charged with specifying the system). There are some powerful techniques out there for doing this, including use case analysis, JAD, etc, etc. Analysts and developers are very good at getting this kind of information out of people and writing it down - they should be, it's been standard practice for 30 years. And yet the software when delivered doesn't do what the user needs.

We think that software developers are missing a vital truth: most organisations don't know what they do. They think they know, but they don't know.

That's why, no matter how good your requirement elicitation process, the delivered system doesn't meet the needs of the client: the client knew exactly what they wanted, but didn't know what they needed.

How do we know this? Our job (when we write procedures) is requirements analysis: we find out what the client's business processes are, and write them down. The difference is that we don't then automate it. The feedback that we get from our users is immediate and vocal: since we're not trying to change their processes, they will tell us right away if we've got it wrong.

So over the years we've developed a method (flowcharting sessions) for capturing this information in an efficient and effective way. In a nutshell, we get a number of users in a room, and we flowchart the process with them. There are a number of advantages to this: we find out a lot about the process, painlessly (for the client!). We achieve buy-in from the people in the room for the process that we finally document. And ... we find out what the disagreements are about the existing process.

Some years ago we were called in to redocument the software development process for a major US merchant bank's Sydney office. They already had a written procedure for project initiation (written in the US) and the six project managers at the flowcharting session were all trained in it, using it and happy with it. But guess what: when we started to flowchart the process, they all disagreed on almost every step. A one-page flowchart took two days to agree on.

This is typical. Imagine an accounts receivable area with one manager and three staff. The staff have all been there for a while, and they all do slightly different parts of the process, or if they do the same process, they do it slightly differently. When they have a problem, they call in the manager, who adjudicates, or provides advice. We know that if we ran a flowcharting session we would get four different versions of their processes - one from each person.

Now imagine a software company being asked to develop software for this area. They will get the manager, and perhaps one of the staff, in a JAD session and ask them "what do you want this software to do?". The manager will describe what the manager imagines is the process used by all three staff (and the staff member who's present will keep their mouth shut). The software company people nod, and go away and write this up as a set of use cases, scenarios, and what have you. This will be presented back to the client for sign-off, and then it will be built.

When the system is rolled out, the fun begins. Users complain that the software doesn't "work the way they work". The manager finds out that the reports that he's imagined aren't actually the ones he imagined he needed. The developers run around trying to fit the system to the needs of the organisation - but it appears to them that these needs have changed in the interim. Eventually, the system may become one of the 75% that don't make it - it's canned, or "put on ice", or "delayed".

Things get worse where the developers are starting with an existing system to modify, like an ERP, CRM or off the shelf system. The client will have been convinced by their auditors that they need to adopt "World's best practice", and that putting in a standard off the shelf system is going to help them achieve that. But of course you can't put the system in without modification, because organisations are different. So the developers go through the same design process, only this time they have a preconceived idea of how the system will operate when they go into the design session. Most of the time, it's a disaster.

Of course, vendors (or implementation partners) will sometimes do a certain amount of analysis before all this - they will generate 'high level process maps' which describe what they think (or what they've been told by the client) the overall business flow looks like. Unfortunately, unless you go down to the lowest "lines and boxes" level it's not obvious that no-one in the client organisation actually knows how their processes work in detail.

Is there an answer? We think there is.

When we write procedures, we tease out every detail of a client's business processes. And we do it in such a way that they become visible to every person involved. Because we're not about to change the way they work (we're not writing software) there's no confusion about whether this is 'the way we work now' or 'the way we will work with the new system'. We drag out all of the disagreements, and resolve them.

By the time we've finished, not only is the actual business process written down, everyone's actually following it. The addition of an internal audit process can make sure that they keep following it. So when a software developer (or even a CRM vendor) wants to automate what they do, there's no confusion about what the client needs. And if the process needs to be changed or improved, you can actually see what it's being changed from.

A side-effect of this approach is: you may find that once you've done it, you don't need to automate your systems. Managers buy software development projects for many different reasons, one of which is to get everyone to use the same process: if they're using different processes now, not only will the implementation of a software system not get them all into line, the process of software development will be expensive and highly risky. By simply writing procedures you can make the process changes you need at low cost and with low risk.

This article may be reproduced only with the permission of HCi (email HCi ). Copyright HCi, 2001-2.