2006-03-14 Software

I’ve been writing specs during the day for over a year, now. We do specs in a way I don’t like. Here’s how we do our GUI specifications:

1. We use a big Word file with screenshots of the original dialogs, folders, and long lists of fields and columns, with comments. This is hard to read for newcomers, but easy to use as a checklist for programmers and testers on a GUI level, easy to verify for compliance.

2. We make meetings with the client, talk about the prototype, and take note of requirements.

3. One of us adds new stuff from notes to the spec.

4. One of us updates the prototype.

5. We meet again.

It’s not bad. I have no experience with alternatives. Our current approach is already much better than previous approaches we’ve tried: UseCases – the rigid form didn’t work too well, more technical details – worse, interface specs added – worse, no prototypes – much worse.

What we haven’t tried:

• *Narrative based specification**: We talk about stories, much like use-cases, but with much less formalism. “Project manager Studer creates a new project. First, he needs to know the address of the building...” The test of whether the product satisfies the specification and thus whether the customer got what he paid for, is to reenact the stories. This ok for programmers, bad for GUI level tests, but great for process level tests, but not easy to verify for compliance. “This is not what we were thinking of when we ordered it!”

• *Constraint based specification**: One way to verify the outcome of the narrative based specification is to add constraints: Long lists of simple statements about the software. “We only classify customers by region.” Such statements are easier to collect and verify. It’s harder to put them in a big picture, but perhaps the narrative provides the big picture?

Using these two approaches, we could produce a secification that was easier to read for the client, still clear enough for programmers, giving them enough freedom to solve problems elegantly, allowing goal-oriented development. The only drawback seems to be that it is harder to test for compliance. Customers can wriggle their way out, asking for more features. The reason I am discarding this argument is simple: This kind of certitude doesn’t exist for our existing specs, either.

Customers will not and cannot know everything they need to know for the specs. There will always be moments when the customer realizes that some important part is missing. And we need to be flexible enough to handle it.

So why not try AgileProgramming? I don’t know. I’m not sure our customers want this kind of approach. Right now we often sell projects on fixed-price basis. Thus we need to limit the scope of the project early enough. And determining what we need as early as possible, writing it down, and agreeing upon it, still seems to be the best way to do this. Agile programming doesn’t work for all kinds of business models, I think. For fixed price projects, specs will not go away.

Related:

• Getting Real, Step 1: No Functional Spec, by SignalVsNoise
• Painless Functional Specifications - Part 1: Why Bother? by JoelSpolsky

Getting Real, Step 1: No Functional Spec

SignalVsNoise

Painless Functional Specifications - Part 1: Why Bother?

JoelSpolsky

​#Software