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"