Functional specifications – the classic way
The term Functional Specification sounds as bulky as dusty. Even in English, he is not better. Often there is also a Software requirements specification, the requirements specification – in short Requirements.
On the difference between these documents I will not take up here – because today as a non-programmer you only have rarely to do with functional specifications & Co. For many years they were the standard for large software projects, there is even an ANSI standard for that.
All these documents tried what is believed to be impossible now: at the beginning of a project everything should be set so clear that all functions can be on time implemented in the required quality and with the planned effort. Functional specifications try to fully describe the proposed system.
Use Cases – the user comes into play
As a UX expert you already feel much more comfortable with the use cases or user scenarios.
They describe what the user will actually do with the system what has to be created and how this reacts. A single use case defines what happened between user and system when he tries to do his job with the system.
User Stories – now it is getting human
Working with User Stories (user stories) is the youngest of the methods presented in this paper to describe a system that will be implemented. A user story is also the smallest element: it describes the smallest possible task that can the user do with the system.
It is formulated in everyday language and kept as short as possible.
An example would be a user story:
As a business traveler I would like an overview of my current hotel reservations, so that I can cancel one of them.
A user story usually include not only such a description, also a title as well as the acceptance criteria. Acceptance criteria define when the requirement is met. These criteria are usually the instructions for testing – if the acceptance criteria are checked and the system meets these, the user story is considered to be processed.
There are usually 3 to 4 criteria that must be met. If there are more than 10, the user story itself is probably not well defined – and you should break it down into more than one.
It has proven its worth to write down user stories on index cards (A6). In this way the amount of text is limited. Title and description are placed on the front page, the acceptance criteria on the back.
Fits the user story is not on the map, it is not fragmented enough.
Many stories tell about the product
What the future product is able to do is described by the user story that is defined for it. However:
A user story is not a specification.
And the totality of all user stories should not replace traditional specification.
Because user stories are mainly used in Agile development. This should(more simplistic) further software projects faster and achieve a higher quality than by conventional methods. The core point here is to work in small steps and frequent iterations.
In the Agile development one thing is central: The conversation. Means that nobody here works for weeks quietly at his desk to present something afterwards. You meet regularly and in short intervals to discuss the situation and how to proceed. Testing is part of its everyday life.
User stories are therefore more an invitation to an interview as a stand-alone document. A good user story stimulates discussion and reminds the participants in the conversation about what they have discussed.
Better overview: User Story Mapping
To retain the overview of complex tasks, I like the technique of mapping user story very much.
Jeff Patton, who made known this technique, describes it like this:
In the team I tell the history of the product and write down every major step of the user on a post-it. Afterwards I order these post-its from left to right. Then we go back and talk about the details. Each detail is on another piece of paper and I will arrange one after another under each step. This creates a grid that tells the story from right to left – and each contributes the details from top to bottom.
If you are interested in this technique, I recommend you the book by Jeff Patton warmly: User Story Mapping: Discover the Whole Story, Build the Right Product.There he describes very entertaining and in an easily understandable English on 322 pages, how to work with user story mapping. The target groups are primarily UX experts and Product Manager / Owner, working on large software projects. But also for people, who are working on larger sites or apps, the reading the book will be a profit.
The big picture: From vision to epic
To conclude, a view of the big picture: In the agile development the individual user stories are part of the so-called project backlogs. This is a collection of related stories that represent a part of the project. An example: Booking and managing hotel reservations.
Then the individual user stories come from the project backlog which are implemented in a pass-through (“Sprint”).
Most systems which have to be developed are so complex that they can be divided into several projects – then their respective story tells the so-called epic (which means something like “long history”…).
Finally the vision describes in a few sentences, where the way of the development will go: Who should buy this product, who should use it? What’s the value for users? Which properties must the product have before it can be delivered? What makes the product better than the competition (USP)? What are the time frame and budget?
Problems with acceptance and implementation
A problem with user stories: they are not established yet. This means, that for some customers it seems like you want to skive off the work to make proper planning and documentation.
Many customers still expect detailed mockups – or at least wireframes, which are presented as early as possible in the project. But in agile development they will occur only gradually.
In addition to that, not every costumer values the circumstance to participate in the project. It is not clear to everyone that the more and more he is involved in the development, the more the result corresponds to his ideas.
Often the usual documents are the milestones for the payment – only if for example the detailed concept exists, the customer will pay the next installment.
This means you have to make some educational work.
Use what works for your project, your clients and your team
My pragmatic advice is:
Use the techniques in the way they fit for your clients and your team. Start with:
- Personas (see What would Walter do?), then continue with
- Customer Journey Maps (see customer journey, user experience, Maps) and then test
- User stories.
For projects that are very content heavy, such as pure information sites, also come along well with the classical methods.
The more features your project should offer, the more you should try to work agile.
At the end, a comforting quote from my colleague Rian van der Merwe:
Documents are not a bad thing. Poor documents are bad.