Read part 1 and part 2.

This probably should have been part 1, but oh well.

I should make a disclaimer. Although I know some about requirements, I’m no PMP (Project Management Professional) nor do I play one on TV (although I do know a real one – hopefully I won’t do her a disservice with this). This article isn’t meant to be the be-all, end-all of the requirements gathering process. The process is quite detailed and whole books can and have been written on the subject. More information on requirements can be found at the bottom of this article.

In general, requirements define the what the software project does and doesn’t do. All software projects should have some form of requirements to define what it is that you are building.

In a situation where you have been contracted by someone else to build them software, the user or group of users should be involved in the requirements process. They probably have an idea of what they want built for them and using this idea(s), you’ll help them define the requirements of their project (although it’s really not as easy as that since sometimes they don’t even know what they want).

In my case, the requirements gathering process was simple. With the exception of the public interface (reading posts and making comments), I’m going to be the only user.

If I’m the only user, why couldn’t I just start designing and coding? Well, if I had starting working right away, I would have been making myself susceptible to “feature creep.” Feature creep can be defined as features which tend to be requested for inclusion into a project when it’s already in motion. This can stall and delay the project or worse, it cause the project to fail outright. In a case where someone has contracted you, this can cost them real money.

Even a single developer working on a project can fall prey to feature creep and it can actually deter you from finishing the project.

Requirements can be complicated or they can be simple. Complicated requirements can contain interviews, use cases, prototypes and more. The 37Signals guys write a one page story about what the application can do. I chose to just list, in a summary form what the application can do. Using these simple requirements, I can easily build onto them by defining Use Cases for each action.

By defining a loose set of requirements, I was able to see what I
wanted to do and what I could release in the first iteration and what
could wait for further iterations. I solidified my vision for my application and reduced my susceptibility to feature creep.

Further reading:

• Requirements Gathering Essentials
• Gathering Requirements: The Crux of the Matter
  
• Recommended Requirements Gathering Process
• Software Requirements, Second Edition
  
• Mastering the Requirements Process
• Writing Effective Use Cases
• Managing Software Requirements: A Use Case Approach, Second Edition
• Software Requirements: Styles and Techniques
• The Requirements Engineering Handbook
• Project Management Institute