Describing Requirements


In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s no such thing as a requirement”, says “A misfit occurs when some aspect of the form clashes with some aspect of the context.”

I like the idea that the form of what we’re trying to design and the context, how we’ll use the design, are in tension. Good design involves describing the tradeoffs and how those tradeoffs affect each other. This is why the agile techniques, where the index cards carrying the stories are more of a promise to discuss the requirements and the tradeoffs are so successful.

I get frustrated when I’m brought in to “save” a project, and I see reams of paper describing the requirements. Too often, the functional requirements (the description of what the system will do) are described in mind-numbing detail, with no attention paid to the non-functional requirements (system attributes, possibly Alexander’s notion of context). I can be sure when I see huge requirements docs that the project team thinks they’ve completed the requirements, but they haven’t had enough of the conversations to finish describing the requirements.

There are people who have successfully used huge requirements docs to make their project successful. In the cases I know of, they have used some sort of fit criteria (a la Robertson) and/or use cases in addition to the big functional requirements document. But if they don’t have some sort of context, or fit criteria, or use cases, I haven’t seen big requirements documents succeed.

I don’t really care how a project team describes the requirements, as long as the team thinks about more than just functional requirements. With requirements, it’s the thinking and discussing tradeoffs that is so important. With informed discussions, the requirements documentation is easy. As always, more to think about…

Leave a Reply