18 Red Flags.
Here are eighteen things you should be on the alert for to help you recognize poor quality business requirements and domain specifications in your software practice. Later on, I’ll discuss the six steps you can take to protect projects from these common mistakes.
- Anemic Requirements
- Ambiguous language
- Low cohesion
- Incomplete
- Contradictory and/or inconsistent
- Incorrect
- Out of date
- Unclear terminology
- Solutions masquerading as requirements
- Incorrect Focus (‘how’ rather than ‘what’)
- Not feasible (to design or build)
- Irrelevant
- Not mandatory
- Lacking in context (priority/status)
- Not traceable or not tracked
- not usable by stakeholders
- Unverifiable
- Unvalidatable
Causes.
Common causes of poor requirements and specifications are:
-
inadequate training
-
inadequate access to stakeholders or domain experts
-
inadequate authority to perform the activities needed to engineer requirements
-
Incorrect beliefs that good requirements are too costly, too difficult, or impossible to produce. Because of lack of training and the resulting poor level of skill in requirement engineering in the industry, this is an especially common misconception for nonfunctional requirements like: availability, interoperability, performance, portability, safety, security, and usability.
-
Mistaken beliefs that writing verifiable requirements containing minimum acceptable thresholds is impossible.
Effects.
Poor requirements lead to poor design. Without quality business requirements and domain specifications with explicit thresholds:
-
It is impossible for designers like customer experience designers and software architects to know when their designs are adequate to meet the business needs.
-
It is impossible for testers to produce proper quality tests and to generate associated test completion criteria.
-
Solution designers can not determine viable trade-offs between different design decisions.
Poor business requirements and domain specification mistakes will multiply the remaining costs in your project because they impact all subsequent activities like experience design, software architecture, implementation, testing, and maintenance. Poor quality requirements are a primary cause of major schedule overruns. Incorrect requirements and specifications massively increase development, maintenance, and modification costs (between 50x-200x [Boehm and Papaccio]). You can trace approximately 50 percent of your defects and 80% of your rework costs back to quality issues in your initial requirements.
Solution.
To solve these all-too-common issues, quality control on business requirements and domain specifications must be a top priority to get the correct trajectory for your project before you start subsequent design and building activities. Quality control of business requirements and domain specifications goes a long way in improving your resulting software systems, minimizing your time to market, and reducing the total cost of ownership of your systems; especially as they mature and go into a maintenance phase.
Here are six steps you can take to be sure you are producing the highest quality business requirements and specifications possible:
1. Training:
Ensure adequate training for everyone involved in the business requirement and domain specification process so they can recognize the difference between high-quality and low-quality business requirements and domain specifications. This includes the technical requirement engineers and all non-technical stakeholders. Training and proficiency is also crucial for anyone who you will have reviewing or inspecting the business requirements and domain specifications.
2. Formal sign-offs:
Establish a formal review and sign-off process. Sign-off should include a designated business stakeholder, at least technical resource, and at least one quality assurance resource. This process should be besides the requirement and specification gathering activities or any informal review work or walkthroughs. During the formal sign-off process, all stakeholders should verify that the specifications and requirements meet all quality criteria to ensure none of the issues described in the beginning of this article are present.
3. Lexicon:
Create a dictionary of vague or potentially misunderstood business terms that appear in the specifications to non-business resources like stakeholders and domain experts. It is critical that you remove any chances of your designers or developers misunderstanding the business requirements and domain specifications.
4. Verification:
Always involve your design resources to verify your requirements and specifications are realistic, feasible, and verifiable. Conduct technical reviews with your experience engineers (UX/CX), software architects, and test teams.
5. Enablement:
Mandate that your requirement engineers must collaborate with stakeholders and business domain experts until the formal sign-off is complete. Also, require the stakeholders and business domain experts are available as needed so there are no roadblocks.
6. Maintain:
Require that your requirement engineers rework or delete all requirements that are no longer relevant or that lack the required characteristics of good requirements.
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 have been doing this long enough to know there are always mis-steps along the way and part of achieving success is having the ability to fail fast and quickly adjust so you can ultimately reach your goals. Business requirements and domain specifications are the foundation of all the other steps in a project. They are always there, underlying all activities, regardless if you proactively engage them or not. This is because an understanding of the business must exist for anyone on a project to make decisions while they carry out their activities, including functional and non-functional requirements gathering and analysis, design, development, and testing. The risk is having different people with different assumptions about the business move in directions you don’t want.
This is the first opportunity in your project to fix any incorrect assumptions head-on and make sure your team stays on the same page, so your product is on-point at much less cost. If you ignore initial alignment work early on, you risk paying to design and build the wrong things, which is a leading cause of project failures.
I hope this helps you succeed in your next project or improve your current one.
Best of luck,
Matt Cochran - CTO and Founder, Vetrify