Requirements

Requirements are one of the most important parts of a project. They form the foundation that the rest of the project is built upon; they define the features that will be included in the system being developed; and they lay out the criteria that determine the success or failure of the project.

Before requirements are gathered, you must identify a Need. In the corporate world, that need is usually dictated by "the business". The Business Need dictates the objective and the purpose for the project. The requirements should all support the Need and should include all features to address the need. A particular Need or project could spawn multiple sets of requirements, but a set of requirements should be related to only one Need. 

The more traditional form of the requirements document contains all requirements in one document. Requirements range from declarations of behaviors, features and the supporting work flows to declarations of the technology that will provide and support those behaviors, features and work flows. All requirements should be clear and concise, and should be easily readable and understandable.

Other teams elect to have two sets of requirements. One set is business requirements. Business requirements are high level and generally phrased as behaviors. The requirements will define a desired feature or work flow items that will contribute to a desired feature. Business requirements should avoid being technical at all. There should be no items that someone who is not technical might not understand. The second set of requirements would be the technical requirements. This document supports and expands upon the business requirements, providing the technical detail that is required to complete the features and work flows defined in the business requirements. Technical requirements do not need to be easily understood by non-technical readers, but should still be clear, concise and easy for someone with technical knowledge to understand. For these teams, all development will result from both documents together, one to define the desired behaviors and features, the other to define the technology needed to provide the behaviors and features.

No matter which method your team chooses, the rules for the requirements remain the same:

1. Define requirements in a declarative fashion.
2. The requirements should be concise and stand without explanation. If explanation is needed, it should be done in supplemental, supporting documentation. 
3. Requirements are not about implementation. Implementation plans and details should be saved for the design document.
4. Each requirement should be prioritized. If the project gets to the point that some features cannot be implemented, it helps to know what gets trimmed out first.
5. Each requirement should be:

• Correct – it must accurately describe the functionality to be delivered
• Feasible – it must be possible to implement each requirement within the scope of the project.
• Necessary – it must fulfill a true need.
• Unambiguous – it must have only one interpretation.
• Verifiable – there must be a way to test it and tell if it has been implemented correctly.
• Understandable – it must be written in a way that does not require specialized knowledge to understand.

Requirements are nothing to be afraid of. They do not have to be hard, nor complicated, but they will often set the tone for the project to come.