I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant.  - unknown

Why should you bother developing requirements for your project? After all this is the new world of Agile software development. In their book Getting Real, web software company 37signals argues that functional specs are a complete waste of time¹. While I agree that the web world is different than the embedded systems world, I would argue that writing down some level of specification is always the right thing to do no matter what the platform. At least this is true in the context of business where bottom line results are essential.

My top motivations for why I believe project requirements are important:

1. Framework to build on. While many details can be left for later, an outline of requirements serves as the central structure to build the software on.
   
   
2. The act of writing helps to think through the problem. We often do not think through all the possibilities until we first write down what it is we want to do.
   
   
3. Big ideas are great, but it is the details that will define a product’s greatness. We are often tempted to leave the details to the programmer. After all, we do not have time to care about such details. However, the programmer may not be an expert in all aspects of a product field they are developing for. Steve Jobs is known for getting involved in every detail of Apple’s new product development. James Cameron does the same with his films. Who can argue with their results?
   
   
4. Unclear requirements are cited consistently as one of the top reasons that project fail.
   
   
5. Being able to accurately estimate a project’s time and budget. We must first know the scope of the project before we can accurately estimate the time and effort to implement it.
   
   
6. Makes it easier to work on team based projects. Tasks may be subdivided and assigned to individual team members based on the requirements breakdown. While this is merely helpful for small co-located teams, it becomes absolutely essential for large distributed teams.


7. Reference for testing. How do we know if the software is working correctly if we don’t have a reference that defines what correct behavior is?


8. Customer buyoff on what is being developed. It is much easier and cheaper to make requirements changes at the beginning rather than later once the product has already been developed. It will be much easier to get a customer to pay for changes later on if there were an agreed set of requirements to begin with.

Read Part 1 of this series How Requirements Can Make Developing Software Cheaper

¹ http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php