Truth be told, end solutions rarely meet all
of the requirements. Think instead of meeting the high-priority, approved requirements. It's critical to help the business stakeholders focus from the start on the requirements with the greatest business value.
Assuming you're all on the same page about requirement priorities and you've gathered a slew of truly necessary requirements to implement, what's next?
It's now time to turn your attention to requirements traceability
in order to ensure all those necessary requirements will be met by the solution that gets designed and eventually deployed.
Traceability demonstrates the relationships between goals, requirements, and the eventual implementation of those requirements. In every project, every requirement should trace back to a high-level (business- or charter-level) requirement. That includes the details of the business rules and the functional or nonfunctional requirements. "Orphaned requirements"—standalone requirements that don't tie back to a vision-level requirement—should be removed from the scope, to allow the team to remain undistracted and focus on the right solution. Conversely, to ensure that high-level requirements are fully implemented, you'll need to account for all of the solution components and details resulting from that requirement.
Traceability becomes especially useful when the requirements change. In every project you'll ever undertake, you can expect that the requirements will change somewhere along the line. For projects longer than one or two months, trying to track the changes in your head is a sure path to the loony bin. Instead, begin tracing requirements by establishing the relationships between the detailed user-level and system-level requirements and the corresponding high-level or business-level requirements. Then, when a high-level requirement changes, you'll be able to validate that you've made the appropriate changes to the corresponding detailed requirements. Similarly, if a detailed requirement changes, you'll be able to verify that the change won't negatively affect the higher-level requirement it's linked to. Your best bet is to prepare for requirements change early by defining your requirements change management process, and ensuring that traceability is an integral element.
Traceability is also very useful for testing that the requirements have been met. Every requirement must be testable. It's an important part of a business analyst's job to make sure that the requirements are testable, that they're tested, and that they pass the tests. A good tool for managing these details is a requirements traceability matrix. Make sure the matrix includes a way to document when a requirement will be tested, even if it's just a time period—the phase, iteration, or date when the solution will be tested to make sure it meets the requirement. The matrix should also eventually indicate how each requirement will be tested—the test plan and test case that will check that requirement. By methodically ensuring each requirement is tested, the team will validate that the solution meets all its associated requirements.
If desired, the matrix can also include a space to indicate that an element has passed its test. Wherever the passing or failing of tests is recorded, the validation process must use that information to take steps to correct items that failed, retest them, and finally validate that all requirements have been met.