Over the last several months I have been working on several Product Features pertaining to KiSSFLOW . One of the many questions that have been intriguing me is “What constitutes a good Feature Specification?”.

Form Follows Function

I had tried several mediums to communicate Feature Specifications, including Presentation Slides, Detailed Written Documents, Key-Point Document with Designs, and Annotated Designs with Various degrees of Success. What I did eventually learn was that the Effectiveness of a Feature Specification Document was not determined by the medium used to communicate it but by the content actually communicated. Form Follows Function.

Qualities of good Specification

An effective Feature Specification Document contains three qualities. It’s:

Comprehensive

A Good Spec is comprehensive. It lists down all that the Feature expects to accomplish. Particularly it will describe:

How a Feature Will Appear

The spec should contain design as well as textual explanations of all the visible elements of the Feature.

The spec should contain design as well as textual explanations of all the visible elements of the Feature. How it will work

The spec should contain explanations of all the interactions that the Feature will accomplish.

The spec should contain explanations of all the interactions that the Feature will accomplish. How it will affect the Product

The spec should also specify all the things that will break or change when the new Feature is built. Its seldom possible to build a Feature that is completely independent of all else.

Unambiguous

Clarity of Goal

One of the primary things the Feature Specification should do is to explain why a Feature is built in the first place. What the goal for the Feature is and more importantly what its Goal will not be. This “Context” is most important for anyone developing the Feature. An engineer who understands the need for a Feature does a much more thorough job than an Engineer who doesn’t.

One of the primary things the Feature Specification should do is to explain why a Feature is built in the first place. What the goal for the Feature is and more importantly what its Goal will not be. This “Context” is most important for anyone developing the Feature. An engineer who understands the need for a Feature does a much more thorough job than an Engineer who doesn’t. Clarity in Approach

One more thing that the spec should do is explain why a particular approach is taken to implement the Feature. This forces both the writer of the spec as well as the developer to appreciate the various possible approaches available as well as the relative merits and demerits of them. Knowing this will help developers as well as other stakeholders appreciate why a particular approach was favored over another.

One more thing that the spec should do is explain why a particular approach is taken to implement the Feature. This forces both the writer of the spec as well as the developer to appreciate the various possible approaches available as well as the relative merits and demerits of them. Knowing this will help developers as well as other stakeholders appreciate why a particular approach was favored over another. Clarity in Language

Linguists define this as pragmatics. In common terms this is the understanding gained by reading what is written in the Feature Spec based on the “context” that is conveyed or implicitly understood. I have noticed many times that the reason for the disconnect between what is implemented vs what was expected lies in the way the Spec was (Mis)understood.

Future proofed

We have a philosophy here at OrangeScape / KiSSFLOW

“Design for the Future, build for today”

This philosophy does not stop at Engineering alone, but penetrates both design and product. The Feature Specification should be adequately future proofed. A good Spec will always address three things.