Siva Ganesan, Vice President and Global Head at TCS Assurance Services Unit, blogs about the well thought out business and engineering requirements needed for successful software delivery.
Setting out on a car journey? What if your GPS navigator device keeps re-calibrating, and provides wrong directions? There’s 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 – 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.
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’s where assurance and testing come in – with the right questions that bring to light the unstated, but important requirements. While it’s important to capture and document both stated and unstated requirements, it’s equally important to validate and verify them. In fact, requirements validation and verification is the first (and often missed) step of the development lifecycle.
Requirements validation and verification
But the simple term – requirements – has varied interpretations, and could mean different things to different people. For the CXO, it could be the high-level business vision, while for the developers it may be interface and database design. For customers, requirements generally take the form of use cases or solution ideas and working models. It’s therefore important for all stakeholders, especially business and IT owners, to work together on business and engineering requirements – because the two are inextricably linked. This is even more critical in this digital age where technology is converging, hardware is shrinking, and there is high probability of multiple failure points in user transactions and tasks. Here are two key attributes to keep in mind during the requirements phase to build the right product the right way:
- Continuity: With releases being pushed frequently, weekly or even daily, it is important to ensure continuity of the requirements gathering phase, in short sprints, across the lifecycle. When supplemented with continuous design testing, we can be assured of building the right product.
- Rigour: Efficient requirements call for a certain level of process rigour and documentation discipline. Fortunately, there are software tools that not just help with requirements capture, data and process modelling, but also facilitate cross checking and traceability. When combined with the right talent and skill-set – business and technical experts to validate and verify requirements – we can create the right product, and build the product right.
Building the product right
Businesses cannot dismiss requirements as an inconvenient checkbox, and IT cannot start development without completing the exercise. When done right, the right requirements hold potential to give defect-free software, and accelerate time to market. Do it without continuity and rigour, and you may end up with hastened releases that need defect fixing, delays in go to market, brand value erosion, and worst, disillusioned customers moving away from the business. Assurance is duty-bound to prevent such software failures and business frustration – by ensuring not just the right product, but by building the product right!
An earlier version of this blog was published at #ThinkAssurance, the quality assurance (QA) and testing blog of Tata Consultancy Services. Edited for web by Cecilia Rehn.