project management – User stories for functional requirements

project management – User stories for functional requirements

Im 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 theyre one of the best ways of actually communicating requirements in a way end users will really take in. Ive 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 theyre better covered in a way that crosses all stories.

In terms of whether its suitable for large companies this is where I disagree. In my experience (and Ive done projects for Shell, American Express, a couple of multi-national banks and others) theyre often no more formal than smaller companies so theyll 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 its the size of the project, not the size of the company that matters when youre determining how you document requirements.

For me the best requirements documentation is documentation thats suited to its audience, and for me user stories hit the nail on the head most of the time – theyre short enough and clear enough that when they sign them off they mean something because theyve read and understood them (as opposed to the sign off of a 100 page spec which invariably means they havent really read it), but good enough for the developers to work from too.

Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.

Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.

I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.

project management – User stories for functional requirements

What youre describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.

An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.

We also work in small teams (sometimes one or two developers) and believe the above is all thats required in this instance.

Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.

Leave a Reply

Your email address will not be published.