Categorizing Your Requirements Changes
On typical software projects there are many changes that occur to requirements. These changes are not all equal and knowing how to deal with the different kinds of changes is a key requirements management practice, and can make a huge difference in the overall performance of the project. But what are the different kinds of changes? How should requirements changes be categorized?
Some categorize based on the nature of the change – whether it is a new requirement, a requirement modification, or a requirement removal. Some categorize according to the impact and effort it would take to implement the change. Others categorize based on the reason for the change such as due to market pressures, product strategy or vision, hardware/software environment, , or testability. Some categorize based on domain of the change such as ‘Screen change’, ‘Report change’, or ‘Data Change’ for example. Others categorize based on degrees of volatility, or how often the requirement changes. There are many more categorization schemes and of course combinations of these too.
In a recent paper researchers studied how requirements changes are categorized by software practitioners and found that most change requests had little information about the reason for the change, and not enough information to effectively analyze its importance. These researchers then proceeded to use the Card Sorting Method to study how different practitioners categorized their requirements on a globally distributed software project. Perhaps not surprisingly the team members had different categorization schemes, each biased by their own concerns (e.g. the architect categorized according to effort required, the project manager by schedule impact, and so on). Overall the study the participants found that focusing on a requirements categorization approach helped:
- Control and manage the requirements changes
- Assess the impact of requirements changes in a reliable way
- Promote a common understanding of what the change actually meant
- Identify risks associated with the individual change, and with the group of changes
You can read about there study here in along with several references to more on categorizing requirements changes.
