Requirements are fundamental to project success as the scope definition.  Additionally, there are dependencies that impact the ability to produce suitable requirements.  A few of those things are:

• Well defined scope of the work
• Sponsor and customer involvement
• Capability of the requirements authors
• Prioritized functions or abilities

The needs or objectives of the customers or the organization set a project into motion.  These objectives start the discussion around the requirements for any project.  Since this is so, requirements are a key element to the future project success. Requirements are, or should be, inextricably linked to the project scope. Requirements that are not thus, are not really requirements and can be attempts at “gold plating” or sneaking in other objectives.

Good requirements are not that easy to come by.  Anybody that has ever read a specification and attempted to build a product from it will likely attest to that as fact.  Often the requirements quality will reflect the clarity of the scope of the project. That goes with the acronym GIGO – or Garbage In, Garbage Out. 

If the scope statement is poorly crafted or vague, you can be nearly certain the requirements will follow that lead. If you are smart and lucky and you review the requirements, you may ferret out these failings before you start the development process in earnest (that is making prototypes and writing software.)  We can avoid the costs associated with building the wrong thing (wrong objective) if we review the requirements rather than find out as we produce the product and hand it to the sponsor that the product does not meet the objective.  Continuous interaction with the project sponsor and subsequent customers is often helpful.  This continued discourse helps us clarify the objectives or scope and our proposed way of a achieving those objectives via the requirements documentation.  For a better understanding how this interaction between sponsor and development team should happen, consult agile project management work. This method provides great counsel in that regard (http://www.amazon.com/Scrum-Project-Management-Kim-Pries/dp/1439825157/ref=sr_1_1?ie=UTF8&qid=1364391570&sr=8-1&keywords=pries+quigley). This technique should not be solely the province of an agile approach but constitutes good management.

Requirements are written (or modeled) by people and as such are impacted by the talent of those writing or capturing them.

We add prioritization to the mix of things that matter when writing the requirements for two reasons. Sometimes we can get a conflict between two or more requirements. For example, consider the requirements long battery life, light weight, and cost.  These three may impede or conflict with each of the other objectives requiring us to set priorities or preferences.

Requirements are the next layer after the scope in project success. If this is poorly executed (ambiguous), and delivered late you can expect there to be consequences. You may not notice immediately these consequences (though you likely will if you are paying attention) but you will certainly see the results at the end of the project.