Producing Software is the Art of Requirements Refinement

Well, that’s certainly a provocative title. Let’s see if I can back it up 🙂 First, read Keith Ray’s Engineering post, where he says

“software development is a cooperative “game” in creating and deploying “knowledge” and various people-oriented practices help make that work”

Some of my recent posts about requirements show the problems when software people don’t refine their requirements with customers. See GUI Requirements and Text Documents and Describing Requirements.

I’ve also been reading Phillip Armour’s The Laws of Software Process: A New Model for the Production and Management of Software. Phillip says software isn’t a product or service; it’s knowledge. The more knowledge the developers don’t know and have to encapsulate in the software, the less you can define the requirements (I’m paraphrasing, I don’t think Phillip actually says that anywhere).

So, if I’m right — or even close to right, which is good enough (because I’m constantly refining my ideas) — then we can forget about defining requirements once and for all. Once and for all is never going to happen. Sure, we can start defining requirements. And we should spend as little time as possible, and make that definition as low fidelity as possible as long as the fidelity is appropriate for your project’s context. So if you’re developing a product that doesn’t have human life implication, timeboxing requirements, paper prototypes, storyboards, informal use cases and other fast and low fidelity techniques are suitable. If you’ll be auditing your product or product development process, and/or people’s lives depend on your software, you may want more requirements cycles which include more cycles of requirements refinements, including higher fidelity techniques, especially including use cases with non-happy paths (the paths where things go wrong).

I’ve seen many software products where people spent way too much time defining the requirements as perfectly as possible, and it wasn’t until they saw part of the product in use that they realized their definition was wrong and/or incomplete. I’ve also seen lots of projects waste time attempting to define requirements in depth when a breadth approach plus a promise to refine the requirements with the developers would have been a much more effective use of time. I can’t tell you where on the continuum of definition and conversation your needs fall, but I’m sure that time-consuming up-front definition without more conversation is wrong.

Leave a Reply