Today I read an interesting article on software requirements from http://ericsink.com/articles/Requirements.html. Do read it when you have the time.
Here is an excerpt of the article:
What is a Spec?
A spec is short for “specification”. A spec is something that describes what a piece of software should do.
For the moment I am being deliberately broad and inclusive. If you are experienced in software project management, you probably have something very specific in mind when think of the words “spec” or “requirement”. In fact, it is possible that you are not willing to acknowledge that something is a spec unless it matches up fairly well with your image of same. That’s okay. Just stay with me.
For now, I’m saying that anything that is a “description of what a piece of software should do” can be considered a spec. This may include:
- A document
- A bunch of 3×5 note cards
- A spreadsheet containing a list of features
I am currently involved in a project where my role is “The Walking Spec”. In other words, I am the person who mostly knows everything about how this piece of software should mostly behave. When people need a spec, they ask me a question (footnote 2). I’m not saying that I am a good spec, but I don’t think I’m the worst spec I have ever seen, and I am certainly better that no spec at all. 🙂
Seriously, a spec needs to be in a form which is accessible to more than one person. It needs to be written down, either in a computer or on paper.
But how?
…..
on another note Eric Sink wrote:
Changing Requirements
If a project gets all the way to completion with bad requirements, the likelihood is that the software will be disappointing. When this happens, the resulting assignment-of-blame exercise can be fun to watch. From a safe distance.
More often, during the project somebody notices a problem with the requirements and changes them along the way.
Marketing: By the way, I forgot to mention that the application has to be compatible with Windows 95.
Development: Windows 95? You’re kidding, right? People stopped using Win95 over a decade ago!
Marketing: Oh, and Mac OS 7.6 too.
Development: What? We’re building this app with .NET 3.0 and we’re already 40% done!
Marketing: You’re half done? That’s great! Oh, and I forgot to mention we need compatibility with the Atari ST.
Development: Why didn’t you tell us this before we started?
Marketing: Sorry. I forgot. It’s no problem to change it now, right?
Changing requirements mid-project can be expensive and painful.
However, it is very rare to have a project where all the requirements are known and properly expressed before development begins. So, it behooves us to prepare for changes. If we choose a development process which rigidly requires a perfect spec before construction can begin, we are just setting ourselves up for pain. We need to be a bit more agile.