Inappropriate Constraints
In many software practices, ‘business requirements’ end up not being actual business requirements. A requirement is something essential to the existence of the system. Because it is natural for people to think a couple steps ahead about how to solve issues, too often they communicate imagined solutions and design decisions as business requirements rather than focusing on the core business need. The resulting inappropriate constraints negatively impact downstream solutions like software architecture, user experience design, implementation details, and so on.
If your stakeholders or requirement engineers incorrectly assume that there is one and only one way to implement a requirement, they have confused the implementation (the solution) with the requirement. This error produces inappropriate constraints on how the system is built rather that what it should do or how well it should do it.
The problem occurs because requirement engineers are not business domain experts and not qualified to be the source of the business requirements. Requirement engineers are also not usually qualified to architect, design, and implement the system because each of these are specialties in themselves. People in the software industry are becoming more specialized as the field matures, and it is rare to find someone who knows it all.
This also occurs because the sources of the business requirements (your stakeholders) are often so caught up in the current system they can not envision significant improvements that you could achieve by leveraging new technologies or business process engineering. Not everyone can ‘think outside the box’ and find innovative approaches that can revolutionize the value a system can provide. More often than not, your stakeholders look for micro-optimizations of their existing processes, which have quickly diminishing returns along with escalating costs to implement.
Your risks
If your business requirements and domain specifications have unnecessary constraints, you lose the opportunity for your specialists to find the best solutions available. It is easy to over-constrain your CX (Customer Experience) engineers, architects, designers and implementers which impact the products and features you ship. This common problem prevents you from being able to deliver innovations that would significantly improve the system and business processes. You are also likely to lose opportunities to differentiate your solution from your competitors.
It is not uncommon to see implementation details leak into business requirements. Things like visual aspects (interactions, buttons, etc) that are not real user interface constraints, or implementation details (“text field”, SHA256 security key, a numeric identifier, etc) that are not real implementation constraints cause a great deal of damage. If your requirement engineer is not be a security expert, they can inadvertently make a requirement rendering your system insecure. Likewise, if your requirement engineer is not a customer experience engineer, they can inadvertently mandate a sub-optimal user experience which can hurt your ability to compete or limit the value you provide to customers.
How to protect yourself
The best way to protect your project from these types of issues is to be on the lookout for it. Know that it can happen. Anyone who takes part in requirement engineering, including stakeholders, should look for improper constraints. Constraints should always describe what or how well something behaves. Immediately address any constraint that describes how something behaves because it is a solution masquerading as a requirement. Often, you can get to the underlying actual requirement by asking “why?”.
Business requirements and domain specifications should not describe any visual aspects of the system. Ask yourself if the business requirement would equally apply to both a voice recognition interface and a visual one.
As an ultimate check, all your designers, architects, and engineers should take part in the requirements evaluation process and question every requirement that potentially specifies a decision they would make as part of producing an optimal solution.
Conclusion
Vetrify builds tools to help you ensure your projects are on track. I started Vetrify to help you ‘vet’ various aspects of your software projects and processes and give you access to all the tools and knowledge I have gathered over the years to stay on-track and maximize your chances of success.
I hope this helps you succeed in your next project or improve your current one.
Best of luck,
Matt Cochran - CTO and Founder, Vetrify