This started out as a comment on this post at Better Projects, and eventually it got long enough that I decided to just post it here.

I thought I should call your attention to International standard IEEE 830-1998. It’s a standard for software requirements specifications.

IEEE have created standards on a range of engineering disciplines from networking to nuclear power.

A summary of it’s contents is here where you can also buy a copy. Anyone read it? How close is it to the IIBA’s BABOK approach?

IEEE 830-1998 is primarily aimed at defining a standard set of contents for a software requirements document. It doesn’t tell you who should write it or how to go about developing it. The BABOK doesn’t require any particular format for that document, so if you want to use this one there’s no conflict. We actually made a lot of use of it in the early development of the BABOK; in fact, this is the original source of the BABOK’s definition of a requirement, although we’ve modified it slightly.

FWIW, I have used it and found it to be not optimal for my needs, as it predates most of the methods I tend to use in requirements development (for the last few years, mostly use cases and process models with some UI specifications). I generally end up tweaking some of the RUP templates for software requirements, although Volere (by Suzanne and James Robertson) is also worth looking at. Volere has a very comprehensive listing of possible sources or drivers of requirements that you might want to consider on a project.

The important thing about any template is that you have to pick one that’s going to be useful to the other project stakeholders. When I worked at Blue Sands, my boss (who was also the system architect) and the developers liked “system shall” style requirements, and since they were the people who had to work with the requirements, that’s what I produced.

No, it’s not an approach I would generally recommend (among other things, that style of requirements writing makes the requirements very hard to validate, because there’s no way to check for completeness) but at the time it made sense for a couple of reasons. First of all, the speed at which we could develop the software was largely constrained by development pace, not requirements, so anything that made it easier on the developers was probably worthwhile. Second, the document was only used by the development team, so it didn’t have to be useful to other audiences.

Certainly, other solutions might have worked under other circumstances. My real point is that there is no one true way of documenting requirements. You produce requirements in the form that they’re needed by the people who will use them.

Kevin Brennan, CBAP
VP, Body of Knowledge