While writing a Functional Specifications Document (FSD) may not be part of every Producers role, it is a skill worth spending some time developing.
It's the blueprint of the plan of the guide to what you are building
In short; the FSD is a blueprint of how to build your project. It is most commonly used within the Waterfall method to site development with good FSDs, or the lack of, linked to the success or failure of a project.
At a minimum, most FSDs will cover off all functional elements of the site, plus include a range of ancillary information to help the development team pull disparate site elements together. This can range from navigational elements to the visual treatment of links, buttons and lists. Detailed information on pull-down menu content and form elements through to site maps, wire frames and prototypes detailing user flow or look and feel. There really is a lot of information that can go into a FSD.
While there are many elements of a FSD which are constant, no two FSDs are the same. Depending on your project scope and how close you work with your development team will partially determine what detail you include. A good FSDs will often cover:
- Details of site features
- Outline of functional elements
- Interaction Points
- User flows
- Dynamic elements and content including dependencies
Gonna get me some learning
One of the best tutorials for writing a FSD can be found online at Mojofat.com. This is a highly detailed tutorial running through requirements gathering through to writing the actual document. I highly recommend making the time to read this as it is a great introduction to writing a FSD.
In a nut shell
Writing a FSD can be both time consuming, and at times boring, yet a well thought out and detailed FSD can help ensure your project will be delivered on time and to budget.
So how do you feel about writing FSD, is is a large part of your role or something to be avoided like the plague? Feel free to share your thoughts below.
0 comments:
Post a Comment