How to identify the impacts of a new requirement on an existing logical system model often depends on the level of the requirement and the phase of delivery.
When considering the impact of a change on the logical model you typically view the change from one of two perspectives. These are:
- ‘Top-down’ where you consider the use cases and other transaction types for the application to determine which of these are impacted by the requirement. This is typical when you have a high-level or open requirement such as a change in regulations that may impact large areas of the application. You then drill down identifying the impacted logical components of each of the impacted use cases as you go.
- ‘Bottom-up’ where you have very specific requirements to consider around individual components that need to be amended. You then need to work up to determine which of the use cases is impacted by the change and should be tested.
However in the end you will always meet in the middle as if you make a change to an individual component you will still need to know which transactions are impacted so that you know how to test it. If you start at the top then you need to drill down to the components that need to be amended or added to meet the requirement. The key point is that impact assessment requires detailed knowledge of the application and is iterative because as you identify components that are impacted by a change you will also identify where those components are used by other components so you need to also consider how those components are also impacted. Typically you are trying to identify these changes without access to a model of the application that you can interrogate to identify these impacts. Consequently this approach often ends up requiring a large amount of guess work to determine what may need to be changed and what needs to be tested.
Top Down Approach
Possibly the most logical approach. This assumes that you have a good understanding of the functionality of your application but in effect requires that you take the user story that you have been given and consider all of the use cases and select all of them that will need to be changed. When considering these you need to remember that not all of these have a person as the actor. These will include:
- User journeys – Where human actors are interacting with the application
- APIs – Where third party systems are interacting with the application
- Batch jobs – Where the system is performing actions on a selected set of transactions
- Diary events – Where the system is performing an action on a specific transaction at a particular point in time.
Once you have a list of all of these that are impacted (ideally it should be a short list for any given user story) then it is a case of documenting what needs to be changed for each one or to provide a description for the functionality required in a new component of that type. You will then need to drill down into each one to identify either missing child components or those that need to be amended and documenting each change.
When you have completed this process you will have a good understanding of the impact of the requirement on the logical model and the changes that you intend to make. You are then ready to start the bottom up impact assessment.
Bottom Up Approach
This approach is used when you have a very specific requirement such as a change to a low level requirement like an existing email or form. In these circumstances the need is to identify the dynamic components that will require testing for the change that you have applied as they have been impacted. E.G. I add a new field to a form. Which journeys use that form and will need to be tested. Functional test cases are used to simulate the behaviour of system users to exercise the new functionality and prove that it behaves as expected. When completing a bottom up impact assessment then effectively you are taking each of the elements of the application that you have changed and are then identifying each use case for the application that you need to execute to see the change applied is implemented as expected.
Review Point
This is an excellent review checkpoint for the product owner and the accountable stakeholder for the requirement to agree that the impact assessment is correct and nothing has been missed. The next phase of the process will be to specify the detail of the changes required to each of the components on the list in the form of acceptance criteria.