Skip to Content

Requirements based change is not a new mode of thinking by any means, but like most thinking the better thoughts take some time to make their way into everyday use. 

In a recent discussion with a senior SAP architect in the UK the subject of managing change by business requirement came up and since this was the second time I had heard the term in a change control context, I decided to look into how change control technologies may add value within a requirements based change management framework.

Requirement based change

A requirement is a capability which a software development (change) is designed to deliver and the purpose of requirements based change management is to assure the organization documents, verifies and meets the requirement.

A requirement may be as granular as a single development or as broad as a significant business project.

Requirement management

During the process of development or project delivery the requirements may evolve, vary or change significantly in which case the requirements themselves require managing.  Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the development which also involves process for managing, tracking and reporting on all proposed changes against requirements. It includes the process of documenting, analyzing, tracing, prioritizing and agreeing on the requirements.

Requirement change control

Requirements change control controls and documents the traceability from business requirements to change requests to code. Good change control reduces or prevents scope creep (uncontrolled changes in a project’s scope), streamlines development, ensures adequate testing and provides real-time visibility between the requirements and development activities – often a key communication gap.

Change control technology and requirement base change management

Managing and controlling changes to requirements and changes made to deliver the requirements involves the documentation of a significant amount of linked information, well considered processes and streamlined workflow.

Linking the information, managing documentation, controlling process and generating workflow using manual methods cannot guarantee the traceability required or guarantee any predetermined process is followed. In addition, the human effort involved in policing and managing the process is substantial resulting in high costs and risk to quality.

Technologies that do not physically link the information (requirements, documentation, change process, approvals, test data, code changes and so on) may well result in a disconnect between the various elements such as requirements and code changes, process and workflow, requirement changes and documentation also increasing the risk to quality.

What is required is a change control technology thatcan link all the elements of a requirement based change process in the one place thus providing assurance that the process is followed, requirements and code changes are linked and traceability for each element exists.

The key benefits being full visibility between requirements and code changes made, process assurance, documentation traceability and streamlined workflow.

When looking, be sure your selected technology is a change request based change control methodology that can provide the framework for capturing requirements documentation, provides automated approval process and workflow and automatedinking of requirement information directly to code changes. In doing so you will achieve full visibility between requirement, change request and any code changes made including test data, impact analysis results and approval process.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Even after blue printing – requirements are completed we have changes.  Lots of changes.  So what do we track?  When do we track them?  At what level?  Overall process?  Programs?  Configuration?

    It’s an interesting concept.  We always try to do this.  I think creating a demo is probably the best way.  A demo without everything required.  Maybe mocked up data…  Etc.

    I wish we could do this….  It’s just very hard.


    1. Rick Porter Post author
      Naturally the theory is always easier that the actual.

      Tracking requirements and requirements changes in software tools is relatively new and not something many of our customers have reported on just yet.

      Hopefully there are others who can add to the conversation Michelle and give you a few practical clues going forward.

      Either way, some method of tracking (to what level too) is an important.


Leave a Reply