Eliciting requirements is a surprisingly difficult activity in a major program. This could possibly be attributed to stakeholders not really knowing what they require in the system this early in lifecycle. Add to that, the issues around connecting with the correct set of people, ensuring that all possible asset teams, end users are in sync with the progress, and we already have a mountain to climb.
One of the inconspicuous effects of this complexity is to write requirements that are ambiguous, non-atomic and that can be misinterpreted by the reader. In our effort to meet our milestones, we do tend to overlook these “minor” issues and move on to development and later test planning.
What happens next has been well documented and fretted over.
What can we do?
I believe getting the testing team involved at this point in time, with the following goals, would add good value to the program:
- Improve granularity and reduce ambiguity of project documentation and deliver assets that reduce the total cost of ownership across Application Integration and Maintenance.
- Validate traceability across requirements and design documentation (detailed business requirements, technical detailed designs, interface specifications, data mapping documents).
- Detect defects early in Requirements and Design phase to reduce the effort of testing and defect fixes later in the cycle.
- Reduce the risk of high number of critical defects later in the cycle.
- Reduce overall solution validation costs.Improve effectiveness of risk-based prioritization through better understanding of solution risks and reduction in testing effort/cycle time.
How can we do it?
The program’s leadership team should conduct a focused process change management and communication campaign to ensure successful adoption of such improvements:
- Develop structured operating model upfront for the early lifecycle validation phase between Business, Project Management, Business Analyst, Solution Design, Development and Testing teams.
- Define a clear RACI matrix with responsibilities and expectations from each team.
- Conduct brown bag sessions with stakeholders upfront on
- Validation process and Process Aids
- Utilize industry-accepted tools like HP Quality Center for test planning, execution and defect lifecycle management. This will allow easier collaboration across team hierarchies and provide clear visibility of the review outcomes and defect ownership.
- Conduct periodic progress review with program leadership, presented actual benefits delivered and sought support on resolving resistance issues, if any.
Where do we see the benefits?
The areas where we will see benefits are as below:
- Improved granularity and reduced ambiguity.
- Ensured coverage and traceability of business requirements. This will ensure that for every wish the business has, the solution has provided inputs and these are clearly traceable and visible.
- Early detection and fixing of defects will translate into significant avoidance of cost for the program.
- Through participation in early lifecycle validation, the testing team will be well versed with the business requirements and design before test planning and execution phases. This will translate to improved productivity.
- Improved effectiveness of risk-based prioritization. Risk-Based Testing Assessment can be conducted with business and design teams, by scoring the functional areas, based on clarity and accuracy. Heat maps, thus developed, can be used to identify high-risk areas for focus during test planning and execution.
If managed well, the benefits of early lifecycle validation would be immense. As an industry survey done in 2008 by M Ballou found out, “if 100% of defects were addressed and remediated prior to production, they would experience a 32% cost savings.” Now that’s savings worth working for.
Don’t forget to leave comments below.