In 16 years I’ve written an a lot of functional specs.
- I’ve written them in small teams and in big teams and every size in between.
- These specs covered many areas: email protocols, server components, user experiences, networking, graphics, telephony, image processing, printing, scanning, real-time communication, security, formats and encodings, APIs, object models, and many more,
- They range from specs with low-level code details (sometimes actual code) to high-level architecture, vision, and strategy.
- My specs have been featured as part of Microsoft’s training on how to write good specs.
And I always get the same feedback from those who read my spec:
“It was easy to understand your spec.”
They also usually ask me why I don’t follow the team’s spec template. 🙂 But we’ll cover that topic eventually.
These days I don’t write specs often – though I do still do a lot of writing – but wanted to share what I learned over those 16 years. I think it applies to anyone who needs to communicate with a technical audience.
So, today I’m starting a series of small blog posts called “The Art of Writing Functional Specs”. I’m not sure how many posts it will take. Let’s say 10 for now. I plan on writing a small post every day for the next 10 days. I hope you’ll enjoy this journey.
We’ll start in earnest tomorrow with Step 1: “What is a Functional Specification?”
FYI: I’ll just be calling them “specs” for most of this series instead of “Functional Specifications”