IT: Software doesn’t change, requirements do

I was reminded some time back, both by a professional engagement, and by an extremely well versed friend and colleague in agile, how to focus on managing change. So often in the history of IT development, by the time coding has commenced, if anything needs to change, the focus is on what code needs to change. In traditional waterfall developments, this brings about a whole host of issues. With the focus on the software, so many other key assets that must be changed also, are forgotten. Changes to the test scripts, designs, architectural concepts, training needs to name but a few. But most important is the requirements.

In a waterfall development, we can hope that this is held within a proper relational database control system, with version control on the objects, however, this is typically held within a large document, more often using an Office product. This in itself leads to excessive problems. In amending the requirements, how can we ensure all references to a particular requirement change are correctly amended, throughout what can be a very large document? How do we ensure the history and reason for the change are captured? How can we be sure that the owner of the requirement is aware and approves? And possibly what causes the greatest issues, how can we be certain of the true impact of a change?

I have been there when the change justified is with, “It’s only one line of code. It will take 15 minutes to develop and recompile and then another 15 minutes to test”. This ignores that fact that often the software fails later because of the impact to an integrated system or service that makes use of that line of code. The fact that the detail of the change, the impact on the design and how it was tested is not cascaded for future development and testing. The only way to be certain of the full impact of any change is to go back to the root source, the requirement, and see all of the resulting assets that may be impacted. Again, this is where an office product will fail. From your document can you see the UML diagrams, source code, test scripts, etc that will all potentially change of the requirement changes? Highly unlikely.

This is why there must be a change in cultural focus that you do not change software, you change requirements. Only then can the full impact be understood.

But changes to impacts in a waterfall development can have their own issues. As a result of the serial nature in which the associated assets are changed, any change will inherently bring about lengthy delays – 3 days to change the requirements documents, 5 days to change the design, 2 days to update test scripts, and only then can then development changes be made, followed by all of the testing. The result is often lengthy periods to implement even the smallest of changes. In a corporate world that relies so heavily on IT these days, and where the business needs are required to change so quickly on this ever on demand, instant fulfilment world, this is simply not conducive. What you define now, may not be what you require in 3 months’ time. This is where agile can provide the greatest of benefits.

1. Scale requirements – User Stories enable requirements to be held as objects, with attributes. A clear, simple and testable statement with ownership and history, sized to the smallest functional granularity
2. Prioritise requirements – The product backlog should be maintained with a complete list of requirements with the absolute musts floating to the top to be creamed into the release/sprint backlog
3. Impact requirements – ensure that the User Stories are related to all associated assets, e.g. Other User Stories, test scripts, source code, designs, etc.
4. Add requirements – Any change could be to add new functionality and so add a new User Story to the Product Backlog and prioritise. If it rises to the top, it gets released sooner.
5. Revise requirements – User Stories may not just change in the statements, but also in the prioritisation, either up or down the product backlog. Only release what you actually need now.
6. Delete requirements – If the User Story is definitely not required, get rid of it out of the backlog. Stop the gold plating or doing more work than is required.

By following the above 6 simple methods, you can ensure that the only requirements that get released are the ones you actually need, and then only the ones that are the most important. In addition, you are much more easily able to control the fluidity of the requirements into your development and ensure that your related assets are also changed in parallel and in sync. With the short sprints and constant reviews of the backlog, those who define the requirements will see the benefits realised quickly, and future development and changes can be implemented in a rapid, simple and quality manner.

But it must be stressed what it is that is changing here – It is the User Stories/requirements, and not the software. The software delivers a service to the user, and that service is defined in the requirements, so use your requirements effectively. This way the user gets what they actually need, when they need it, and in a quality delivery.