Why Great Requirements Matter
When properly captured, requirements are the ground-level representation of core business goals. Defining good requirements can lead to fantastic products and delighted clients. But capturing clear and specific requirements that lead to accurate development and a great end product can be tricky. The notion of ‘good’ requirements begs the question: what makes a requirement good?
While the anatomy of a good requirement ensures the integrity of features, it is also essential to consider ALL situational factors, as software problems are often both technical and interpersonal.
'Good' Requirements Avoid Issues... Right?
Picture this…
A Fortune 500 client wanted to implement a mass-scale software to streamline the processing of thousands of daily financial transactions. The project requirements were very complex and highly cross-functional, involving many geographic areas and separate business teams.
On projects of this size and scale, product defects and unplanned setbacks are inevitable. While the number one concern for product managers is delighting stakeholders by meeting all the goals of a project, the second most important focus is how to ensure that any problems that arise during the natural course of project development are manageable. Each team in the project must do their part to prevent potential issues and mitigate risks.
For the product management team, delivering successful outcomes for the client meant writing really good requirements. But, as we soon discovered, even ‘good’ requirements can present problems in development.
Why 'Good' Requirements Aren't Enough
A full year into the project, the requirements team finalized a vital piece of functionality to support the client being able to process the thousands of daily transactions they were looking to support. Once the client signed off on the requirements, the product team handed the completed requirements off to the development team. Throughout the next couple of months, a third-party developer wrote the necessary code and built out the transactional area of the product based on the requirements specifications. Subsequently, testers went to work verifying that the software requirements for that code were implemented correctly.
Initially, testing went smoothly as the testers greenlit dozens of use cases. Eventually, the product management team received a complaint from a related but unexpected stakeholder, the accounting department.
“Why is the application not making line-by-line accounting entries for the multifaceted transactions this transaction module is designed to process?” a disgruntled accounting lead inquired.
Imagine the surprise of the product management team when this question was posed, as the application out-of-box created valid, line-by-line accounting entries without issue, which was one of the many reasons this particular software was chosen. What changed?!
What started as a simple inquiry soon led to an internal dispute, as the developer had decided to change out-of-box functions for details that were NOT supposed to be changed with the finalized and approved requirements. The developer was overloaded with work at the time, and argued that the requirements that were provided did NOT explicitly state that out-of-box functionality should extend to the latest development.
Given the developer was overloaded, they indicated it was faster for them to change out-of-box functions rather than retain them. As a result, the developers changed the functionality of the product.
While the entire business team was shocked, they were quick to course correct and resolved the issue. However, this situation provided some clear lessons on the importance of documenting great requirements, and what makes ‘great’ so much more powerful than ‘good’.
Great Requirements Prevent Misunderstanding
At face value, it’s not a stretch to assume that developers would NOT change out-of-the-box functions of a software product unless the business specifically requested a change. However, this story illustrates that any assumption can become a problem in the software development lifecycle.
Product managers should seek to write requirements with such precision and specificity that misinterpretation at any point of the product development lifecycle is virtually impossible. The clarity of requirements becomes even more vital as projects increase in size and scale, and teams lose the capacity to devote scrutiny at each step of development.
Great Requirements Lead to Great Results
This good vs great requirement debacle was in fact real, and has since led us to communicate very carefully with the developer, as well as analyze any assumptions that were made on features throughout the project. Our analysis proved valuable, as we found similar areas where design assumptions could be made that would prove problematic. Ultimately, we were able to course correct throughout each area to ensure the product launch went smoothly, and that the client was absolutely delighted with the final product.
