Documenting Requirements

While building a requirements document recently, I came across the challenge of building for purpose. I found that in order be as clear as possible for the developer who was the target audience, I was going to have to build the document in such a way that it didn't know anything about future maintenance.

This presented an interesting dilemma, as how could I then use these same requirements for the maintenance work that I know is coming for this work product?

I found there were certain aspects I could boil it down to, and instead of creating a large, formal document, I boiled the whole thing down to an email with three parts.

• Background - I used this to cover the ground with a general layout of where we were.
• Current Issue - I used this section to cover how we got here, from there, and what exactly "there" was.
• Proposed Solution - Lastly, I outlined what I was proposing we do about it.