Question

Does the functional spec help or hinder your expectations? Do programmers who practice the waterfall methodology, are they open to functional specs? I’m a web designer/developer working with a team of 5 programmers and would like to write a functional spec to explain what we need, so that when I begin my work – I know we are working towards the same goal.

Answer 1

I won’t start any freelance project until I’ve got a design spec and functional spec written up and signed off. There’s too much room for rogue clients to nickel and dime you to death if you don’t have it. The functional spec allows you to stay on target/focused and gives you a natural check list to work to.

If there’s no functional spec then you get all the ‘what ifs’ starting to creep in and developers thinking – you know, this would be useful, and it’ll only take me an hour. Sure an hour to code the prototype and get it basically working – plus the day to design all the tests and make sure all test cases are covered, then another couple of days to iron out all the bugs, then time to write the documentation. There’s far too much room for what seems like a trivial addition to be inserted when there’s no spec. You’ve no doubt heard of the infamous ‘scope creep’. There’s also far too much room for clients to say ‘that’s not what I wanted…’ when you deliver it and try and wriggle out of paying you.

If you’ve got the design spec and the functional spec written up ahead of the development and both you and the client have signed off that your understanding of not only the basic details but all the nuances of the language used is one and the same – only then can the real work begin.

There are a couple of anecdotes out there the first is quite true, while the other is a common misconception:

• Software development is only 15% about the code, the rest is resource/people management.
• It takes 20% of the time to complete the first 80% of the project and the remaining 80% of the time to complete the last 20%.

The misconception is that a working prototype is 80% of the way there – don’t be fooled, it is not. So it’s easy for a client to say ‘what’s taking so long, I thought you were almost done!’ and then quibble that they’re paying too much for something that should’ve been finished months ago. Some of the design methodologies out there really lend themselves well to this popular misconception. The waterfall design methodology is one of them if it’s not used correctly.

My view is make sure your understanding is the same, both sign off. Set milestones and make the client very aware at the outset that prototypes are a long way from the completion of the project and set expectations right from the outset as to what those milestones are and when the client can expect to see them delivered.

For project managers of development teams documentation and expectations are everything. You can’t live without it, it’s the only form of recourse you have against ‘That’s not what I said’ or ‘That’s not what I meant’ and ergo ‘I’m not paying you’.

I learned from a lot of mistakes made by far more qualified developers than me and saw what it did to them. The two most important documents for your project are the design spec and the functional spec. Don’t leave home without them or it can [or most likely will] come back and bite you in the ass.

Addendum re: User Stories:

An additional note about user stories is that they’re great for what they are. They should be included in your functional specification but shouldn’t be your functional specification.

A user story only describes a single task. It is very lightweight and doesn’t contain excessive detail. As the common recommendations go, it should fit on a 3×5 card…if you as a project manager handed me a 3×5 card and told me to write a piece of software based on what I read, no doubt it would be handed to the user at the end and they’d tell the project manager that’s not what they wanted.

You need a far greater level of detail in a functional spec. It shouldn’t be limited to basic workflows. A functional spec is a whole bunch of user stories along with notes on interpretation of those user stories, improvements that can be made to them, common tasks that can be combined to improve efficiency. The list goes on.

So user stories are a good beginning, but they’re not a replacement for a functional spec, they’re bullet points in a functional spec.