how to write functionality specs
So I am about to hire a backend developer, and I've basically made a bunch of notes as to functionality, and broken them out page by page. Is there an 'industry standard' way of writing specs, like a particular format, that makes a developers life easier? I want to be able to give them the specs and have it be clear enough that we can avoid 99% of the mistakes.. Any insight?
-
In addition to the specs, make sure you have a way to make changers during or after development. It won't be free to change specs mid-term, but if you have a system for change orders it can prevent a lot of problems. – Xpda 13 years ago
2 Answers
Your current task of developing the functionality specs is absolutely critical. Congratulations for taking the time to focus on their development. You are correct that investing time now will save problems later.
There are no universal standards. Some developers love their viseo flow charts. Others like simple sentences. Others like spreadsheet where items are categorized for sorting.
What is important is that your developer knows what you mean -- and you know that the developer knows what you mean. Developing that clear communications so that there are no assumptions, no wiggle room, and "I thought you meants"
-
+1 for Joseph. I would only add that you generally want someone very precise to write the spec. For the uninitiated it is easy to consider "must be able to delete contacts" as a requirement. However, there are so many unanswered questions left here. What happens when you delete a contact? Do you delete their notes? Are you really making them inactive but searchable? Is anyone notified? Must there be a confirmation step? You get the idea. You might consider, if you don't have a strong background in it, hiring someone to write the spec. As Joseph wrote, getting them right is very important. – John 13 years ago
-
Big thanks to both John & Joseph. John you touched on something that I think is very important, and probably overlooked a lot. Fortunately, in my case I am a bit OCD, so I think if there is any problem, it will be that I have OVER spec'd it! Thanks guys – Jdh 13 years ago
Jeff, when I look at a project the following items are required:
- Wireframes. These are paper/pen sketches of what you want each page of your application to do. You can make them on paper and scan them or use something like balsamiq or powerpoint to mock them up. THESE are critical, and you don't have to be a user experience guru or a developer to make them. Think of how you want people to use your system and mock up screens for ever possible thing you can think of. Think about each button action and what will happen when that button is clicked, then mock up that page. Outline as much as you can foresee; this process should take awhile.
- Functional Specs / Requirements. You should then do a write up to accompany your wireframes. Write in plain English (or your preferred language) what you expect to occur on each area of the application.
- Review all this with your developer. They should have feedback for you, and suggest improvements or be able to have a conversation about these features and you should have a good sense that they 'get it.' It's imperative that your developer really get what you are trying to accomplish so they can make their own informed decisions during the development process.
- Creative / User Experience. You should then have a professional do the actual design and layout of your system to ensure it's easy and fun to use. You can have the coolest system ever but if it's ugly or hard to use people will not like it.
- Once that is done your developer can get rolling.
I would suggest using a variation of the above process that best fits your needs and budget.
