a few weeks from now on downloadable transcript or whether it's live over the Internet today, welcome.
Alan, what would you say requirements management really is, anyway?
ALAN: Requirements management is a term used in the software systems development world to basically capture the idea, to begin to write down what it is you want to build before we actually build it. This is something that is done in every single discipline; for example, before you build a bridge, you decide what the bridge is going to do, and you write down those specifications. In the case of software quality management, you must write down your requirements before you write the software to make sure that everybody has the same understanding of what it is you're building.
CAROL: And, and that sounds pretty commonsense to me that it should be fairly easy, that if you've got something that you want that you can just write it down, but something tells me that there is a little bit more to it than that.
ALAN: Actually, I think you're right, Carol. It should be really, really simple. And I think that we tend to fall to two schools of thought on this. Right now in practice, there are large numbers of people who simply don't believe in writing requirements down at all. Their philosophy is, "We'll build it and we'll change it, and eventually we'll be able to produce the product that customers want." And that is a very, very highly risky proposition if you don't write requirements down first. The other school are the people who have gone overboard thinking that requirements management should be done to a level where you squeeze out every single bit of risk you might have. And these people spend enormous amounts of energy writing and documenting and reviewing their requirements, and they end up doing an overkill.
ALAN: And so I agree with you that it is almost a no-brainer to do it, yet, in practice, we seem to keep missing the point.
CAROL: Now, is that something that's specific to software? Do you think it is because software is amorphous or it's too new - We've heard a lot on this show, and in past shows, about the problem of requirements in that a lot of the problems that we have with maintaining software, with dealing with the software, you know, having the abends and that type of thing, could have been solved if there was more planning put in up front. So, it seems like it an elusive situation in some cases.
ALAN: Yeah. I think that in software it is somewhat unique. One of the reasons is because people still have this belief that software is easy to change, so "If I get it wrong the first time, I can always change it later."
ALAN: That's one issue. The other issue is, if you look at our record in the software industry, we are considerably worse than most industries that are building to build systems that meet customer needs. We have around a 29% success record, according to the Standish Group...meaning that only 29% of the systems we build actually end up getting to a customer and solving a real problem. And if you contrast that with the latest data I have seen, which is from .............., that showed industry, all industries, where we are doing new product development, it is somewhere around 50% success.
ALAN: And so in software, we really are a lot worse than other industries. And I think that if we did