As we are a small company, I work as both a project manager and developer. The specifications I create for clients contain a number of elements used to describe and define the project, including user stories alongside any other elements I feel need to be included to define the project (e.g. wireframes, userflows, sitemaps etc.) to the client.
If a functional specification “describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features.“. Then does anyone see any problem with using User Stories to define a functional specification for a website? Does anyone actually do functional specifications in this way?
Really I am trying to up my game a little, and wondering if this would approach would work for larger clients who perhaps have more stringent ideas on what a functional specification should contain, whereby a formal approach may be required. Definitely at the moment our clients respond well to our method of producing documentation.
I am interested in hearing what people who do project management professionally think about this.
I’m at odds with what a couple of other people have said.
First up the bit I agree with – stories are a great way of stating functional requirements. For my money they’re one of the best ways of actually communicating requirements in a way end users will really take in. I’ve seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements – covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they’re better covered in a way that crosses all stories.
In terms of whether it’s suitable for large companies this is where I disagree. In my experience (and I’ve done projects for Shell, American Express, a couple of multi-national banks and others) they’re often no more formal than smaller companies so they’ll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it’s the size of the project, not the size of the company that matters when you’re determining how you document requirements.
For me the best requirements documentation is documentation that’s suited to it’s audience, and for me user stories hit the nail on the head most of the time – they’re short enough and clear enough that when they sign them off they mean something because they’ve read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven’t really read it), but good enough for the developers to work from too.