Steps To Improve Requirements
In the quest for good requirements, first, make sure you have appropriately skilled and trained business analysts who can guide the requirements development and management activities on each project.
As your teams get up to speed and requirements become more sophisticated, having the right tools can be a big help. Lots of requirements management tools are available, including IBM Rational RequisitePro, Micro Focus CaliberRM, Microsoft Visual Studio Team System 2010, MKS Integrity, and Ravenflow Raven.
With new projects, I begin at the top by clearly establishing the business objectives. Defining the product vision and project scope help ensure that all the work done aligns with achieving those objectives. This includes assessing your current practices and identifying areas that aren't delivering desired results. Improvement might require writing new processes, modifying current processes, and selecting new templates for key requirements deliverables.
Next, identify distinct communities or classes of users and determine who will serve as the voice of the customer for each such user class. To engage appropriate customer representatives, I recommend designating "product champions" who are key customer representatives engaged on the project on an ongoing basis. This is much like the Agile development concept of the on-site customer.
The "use case" technique, which focuses on expected usage rather than on product features, is an excellent way to explore user product requirements. It should be clear how the use cases will align with business objectives. If they don't align, there's a problem. But use cases aren't sufficient in every situation. Your analysts also need to derive the functional requirements that developers will implement to let users perform the use cases.
In addition, explore and document nonfunctional, quality-related requirements such as usability, security, reliability, and robustness. These attributes are vital to customer satisfaction. Ongoing prioritization of the requirements also is crucial. Think of the backlog of pending requirements as a dynamic list, not a static snapshot frozen in time.
Don't just assume the requirements are correct: validate and verify them. You can begin "testing" your software as soon as you've written the first requirement. On one project I was involved in, I wrote a dozen or so functional requirements, then another dozen or so test cases based on my vision of how the code would operate. In writing the test cases, I discovered an error in one of my requirements. I generally find these sorts of errors, omissions, and ambiguities in my requirements at this point.
A well-structured and rigorous peer review or inspection of requirements documentation is also a good investment. And finally, an effective change management process will help ensure that your project delivers the product that customers need.
Of course, the greatest investment you can make is the time you spend eliciting, analyzing, specifying, validating, and managing requirements. Time spent on these efforts is likely to accelerate a project and make it run more smoothly.
These practices aren't free, but they're cheaper than waiting until the end of a project or iteration, and then fixing all the problems. The case for solid requirements practices is an economic one. With requirements, it's not "You can pay me now, or you can pay me later." Instead, it's "You can pay me now, or you can pay me a whole lot more later."
