It would be nice if all software customers had to do to specify software was to make stories. Some people believe that stories are the requirements for an agile project. I have not found this to work very well in practice. I have discovered that user stories are only good for helping developers estimate software projects. Stories turn out to be a very ineffective way to specify real software.
Stories are just short comments that represent a very general view of the features of the software. As the old saying goes, “The devil is in the details.” This is especially true for software development. You might be wondering: “How could you estimate with something that you can’t actually use to build the software?” Stories are general descriptions and so are the estimates that they produce. Software is very specific. We can’t really build a system without knowing the details. Since, typing isn’t the work of software development; it must be the discovery of detail and the invention of a solution that is the real work.
Customers of software products usually struggle with detail. Developers tend to be ultra-detail oriented. This can put us at odds with each other. Just as estimating requires developers to learn to be a little less detailed, making software specifications require customers to be a little more detailed than they are usually comfortable with. The more that each side stretches in these areas, the more value we can install into our software.
The problem is that software customers really do have preferences between different detailed options, but they tend to put those decisions off until they actually see them with their eyes. Developers on the other hand, are used to “seeing “almost everything in an abstract way. Since we practice this every day, we don’t have much trouble imagining what it would be like to have a set of details. We set this up in our heads and think about what it would be like to use the software. This doesn’t help our customers, however.
The problem is that the specification is the responsibility of the software customer, but it requires a high level of detail. A high level of detail requires a lot of mental work, the very thing we are supposed to be removing with the software! Fortunately, customers can employ the help of analysts and software engineers to help them develop the specifications. I would like to discuss what a software specification is and how to “get into” making them. For all you agile developers, yes, you do make specifications all the time on your agile projects... so don’t worry, I’m not departing from the agile way.
So software specification is all about “seeing” the software before it made. The reason for specifications is that they will keep the developer from having to “re-make” software over and over again as the customers change their minds. This problem is called “Churn” in Lean Software Development
and can reduce the value of the software by:
In the days to come, I hope to discuss how to make specifications using: