Specification Packages
I love writing specification packages. What are those, you may ask? Well, they consist of a few things that I have been using to create clear, vision-centric requirements; also known as “specifications” or “specs”.
As I mentioned in a previous post, I like working on the details based on vision and positioning. It helps me create the entire look from 50,000 before diving into the small elements that round out an entire feature or product component. This falls in line with writing specifications.
A while back, I created a template, which I lovingly refer to as a Feature Requirements Document (FRD). I think I’ve heard this used in other places as well. My thought is a feature is simply a container for requirements. Those requirements are what make the feature usable, whether they are functional or non-functional.
So, how does this start? Typically, with an overview or vision document. Within this, I like to include the objective of the thing, a quick overview of the solution and then I get into themes. I love themes. I can look at my notes on what I’m writing about and group all of the requirements into high-level themes, which I find to help everyone involved getter an idea about the vision before getting into the code or UI.
The remainder of this “vision” doc is geared around building out each identified theme. At the end of it all, you have a deliverable that can be used by anyone in the organization to get a quick, 2-page explanation about what it is you are going to be building. Of course, usual disclaimers should be taken into account. It’s message is just, “yes, this is in the pipeline, and here’s the ideas behind it”.
From this overview, I move right into the FRD, while keeping my trusty (i.e., really messy) notepad to jot down ideas on how this bad boy can be positioned. The FRD is long, and very detailed almost to the point of craziness. I don’t refer to wire frames (see below), or mock-ups — I keep it purely about the requirements.
If you find you have a lot of, “field A should be filled in with XYZ by default”, it may be time for a non-functional spec.
One this piece of the puzzle is complete, I move on to wire frames.
Is it weird to be a PM and doing wire frames? Ehh, not really. I did web design for 5 years, so creating pseudo mock-ups is natural. Would it be nice to work with a UI designer that matches your ideas for the feature up to the style guide and creates something that’s brilliant? Oh, yah. My design skills are marginal (”too boxy!”) at best, which is why I am no longer a web designer. But, I digress.
Wire frames can take a while if you don’t have a base to work from. I’d recommend making sure you have a good template and just crank ‘em out. Of course, it helps to take a step back throughout the process to make sure everything is staying in check.
At the end of it all, I want reviews — the good, the bad, the ugly. I’m an iterative guy, and will never go for a slam-dunk. I feed off the energy people have when they read about what I am proposing in these three documents. I take in that feedback and work with it. Incorporating the thoughts of others is key, especially if you want the product to be a success.
That was a long one, but something I’m glad I took the time to write. As always, I’m interested to hear how others are doing this as well — it always helps!
May 15th, 2006 at 11:58 am
Hi. I am interested in learning about your FRD template. I have created some myself, but they never seem to hit the mark perfectly. I am preparing to embark on a major software project and am trying to gather the best tools for managing the information gathering, starting at the 50K foot view.
Ed
February 6th, 2007 at 4:29 am
this is good !very much!