Follow us...

On Lock Down:  Requirements Change Management

Hans Eckman, VP and Enterprise Business Analyst, Sun Trust Banks Inc.

The High Cost of Change

Change is good, right? In software development, errors increase in relative cost the later they are discovered: three to five times in coding/unit testing, seven to ten times in integration testing, fifteen to fifty times in acceptance testing, and thirty to one hundred times in production. (Tassey1, Boehm2,3). Szalvay found that, “Current software projects spend about 40 to 50 percent of their effort on avoidable rework.” (Szalvay4)

By employing the principles of change and release management to requirements, we can significantly reduce downstream impacts. 

What are some of the types of changes, and when should you look for them?

Table 1

Three Keys to a Successful Requirements Change Management Approach:
  • Classify changes by THREAT LEVEL
  • Execute based on a well-communicated TRIAGE process for each THREAT LEVEL
  • You must maintain constant DILIGENCE managing all changes
The following table provides an easy, three tier approach to managing requirements changes.

Table 2

Triage Process

Any requirements change control process begins after the first formal communication of requirements, and needs to update the system of record for requirements.
  • Validate and qualify the change.
  • Update the impacted requirements.
  • Log all changes (revision log or history) with the effective date, author and source.
  • Package and communicate the changes and new requirements.
If the change is a material change to the solution, the triage process also includes approval steps before any changes are implemented.
  • Define impact and cost if change is implemented.
  • Complete Governance Change Control form for governance impacts.
  • Collect stakeholders approvals.
Tips and Best Practices
  • Communicate the change process and templates as part of your requirements approach. No surprises!
  • Maintain consistent control and communication. 
  • Impact assessments are critical for risk management.
  • Leverage tools and templates when available, such as requirements management systems, defect/change log, or track changes (Microsoft Word).
  • Cross-reference every change: Source; Reason; Date; Supporting documentation: defect, change request, impact analysis, change control, etc.
Applying Requirements Change Control to Baseline Documentation

Once you have a requirements change management approach you are comfortable with in place, you can use those same processes to manage requirements as an asset.
  • Starting from baseline documentation dramatically reduces cost and risk.
  • Treat all scope as changes to the baseline requirements.
  • The sum of changes is the release scope.
  • The sum of changes plus the original baseline becomes the new baseline.
  • It may take additional time and effort to maintain an accurate baseline.
  • Principles of release management and change control can be applied to requirements management.
  • Level of control must match risk and timing.
  • Consistency and diligence are required for success.

1. “The Economic Impacts of Inadequate Infrastructure for Software Testing” , Gregory Tassey, Ph.D., National Institute of Standards and Technology, Prepared by RTI: Health, Social, and Economics Research, RTI Project Number 7007.011  
2. “Requirements-Based Testing: Encourage Collaboration Through Traceability”,  MKS, 2009  
3. “Software Defect Reduction Top 10 List” Barry Boehm and Victor R. Basili, January 2001   
4. “An Introduction to Agile Software Development”,  Victor Szalvay, Danube Technologies, Inc., November 2004
5. “Cost of Change – Modernized”, Paul Oldfield, Mentors, 2003, Appropriate Process Group 

Hans Eckman provides transitional management and consulting for growing companies. He currently serves as VP and Enterprise Business Analyst at SunTrust Banks, Inc., and as the webmaster for the Greater Atlanta Chapter of IIBA.