Project Requirements
Requirements are the backbone of any project. They help us understand the needs of our users and help us provide a solution to meet those needs. Documented requirements provide information not only to the design team but also to the testing team and other project stakeholders. For example, Project Managers need to be able to estimate timelines, determine resources required, and manage budgets. Clients and customers need to be aware of changes that impact users, processes, and data. Also, vendors can use requirements to help provide accurate quotes for their products and services.
It doesn’t matter if you are working in a Traditional or Agile world, all stakeholders use the requirements in different ways but they should all get their requirements from a single source. Multiple sources of information can lead to misunderstandings or data being out of sync. Traditionally this single source is the Business Requirements Document (BRD) or in an Agile world, it is the Product Backlog (PD).
Requirements should be traced through the life cycle of a project with a unique identifier. The quality of the information in the requirements document (BRD or PD) is key to the success of any project. Other than the delivered product, it is the single most important deliverable of a project.
Design Requirements
The requirements document is used to create the physical design and user interfaces. It helps develop the functional and non-functional specifications, the business, security, and performance rules. If the rules are undefined or hard to understand then the designers will have to fill in the requirements gaps. This could lead to missed requirements, scope creep, and rework.
Providing quality requirements early in the design phase can help deliver a better product, as a single missing requirement may result in one or more features missing from the product and the cost to add or fix requirements increase dramatically later in the traditional development life cycle.
Testing Requirements
Testing is not just a phase that happens before you deliver the product. Test planning should be a part of the requirements gathering process. The BA should always be thinking “How can I test this requirement?” Every requirement should be tested and there should be a test for every requirement.
The requirements document should be used early in the project to help testers create the test plan and test cases, help set up the test environments, determine staffing and training, determine what test data should be created, and select the automated and manual tests that should be executed.
Quality documentation is important and the requirements document is no exception. Requirements are used by various stakeholders for various reasons but with one goal in mind; to produce the best product at the best value. If something is worth doing then it is worth documenting. Remember why we need to document requirements the next time you are working on a project.