As part of a series of articles discussing what makes a great corporate website, here we look at the importance of writing a strong functional specification.
Traditionally, the process for writing the functional specification begins with capturing project requirements, from the initial requirements, through to the activities undertaken in a ‘Discover’ phase where the key aspects of the solution are discussed.
A good specification under this approach should detail the purpose, content and functionality of page templates and modules. As well as global functionality like languages.
Why does this approach not work?
But we’ve found that traditional functional specifications tend to be overly wordy and too detailed for their purpose. The result is an excessive burn of budget in the early stages of the project.
Given the evolving nature of digital, the agile principles we adhere to at RY and our commitment to collaborative working with our clients on website builds, time is better spent on quickly getting to develop the actual solution.
Perhaps counterintuitively, we've found the more detailed the specification gets the more ambiguous the instruction gets.
What's the best approach to documenting functional specifications?
We tend to view the reality of web development as similar to house renovations. For example, when a person walks into a newly built room, they can get a feel of the space, and actually change their initial thoughts on what they wanted for the space.
Having a formal document outlined at the beginning of the project which isn’t able to be flexible to evolving needs, means that decisions are confined to previously unknown assumptions. In this way, traditional functional specifications become out of date and redundant within months of their original creation.
So, we embrace this reality in our scoping methodology and prefer lean, concise documentation which allows further collaborative discussion during the build.
Collaboration is key
Our process involves running collaborative workshops with our clients where we story-board high-level requirements using storiesonboard.com. This tool allows both you and us to visually represent features and user stories like post-it notes on a wall. Subsequent workshops then help to refine these virtual post-it notes.
At the end of the workshops, the virtual post-it notes are the functional specification. We’re more than happy to provide supplementary lean documentation to address specific concerns about some functionality, however the source of truth will always be the virtual post-it notes.
We’re pleased to say this more innovative approach to functional specification has been really efficient for our clients, giving them better visibility of progress and promoting a positive working relationship with frequent communication.
By Anthony Dang, technical director at Radley Yeldar