Setting out on a car journey? What if your GPS navigator device keeps re-calibrating, and provides wrong directions? There\u2019s a fair chance of you arriving late and annoyed. That’s if you arrive at all! Likewise, if your business and engineering requirements are unclear or incomplete, your end product will overshoot budget, slip schedule, fall short of user expectations, or worse, may not be delivered at all. The point being \u2013 well thought out business and engineering requirements, at the start of the lifecycle, are extremely important. Leading software needs excellent requirements. Get it right the first time and you significantly reduce defect detection and rework, optimise quality, accelerate test cycles, reduce cost, and delight customers. Do it wrong and you risk project failure, by negatively impacting all downstream activities.<\/p>\n
Most software projects fail not because of a gap in the stated requirements, but because the unstated requirements are not captured. Every project, has a few unstated requirements, which, if not addressed, can haunt users in production. Product owners at best, describe the product, and envisage its working, but may not focus on other important aspects such as speed, performance and security. That\u2019s where assurance and testing come in \u2013 with the right questions that bring to light the unstated, but important requirements. While it\u2019s important to capture and document both stated and unstated requirements, it\u2019s equally important to validate and verify them. In fact, requirements validation and verification is the first (and often missed) step of the development lifecycle.<\/p>\n