What kind of UML diagrams can describe how a new feature will impact/affect an existing system?

For example; my usecase is we have an existing web application (system) that uses framework specific user login & authentication. We need to change the system to use OpenID to login and authenticate users.

We also want to document how this new feature will impact ancillary functionality of the system and thus estimate the work involved in implementing this feature.

For example;

  • How will OpenID affect our profile update feature - it will make it redundant.
  • How will OpenID affect our view previous sales orders - upon AJAX requests we will need to authenticate the user in a different way, we will need to associate a users openid id with a sales order from now on, etc.

Is there such a UML Diagram or Software Engineering document that is applicable to describe this?

4 Answers 4


The Software Engineering Document that describes the modifications needed to implement the new feature the technical concept. You can find different templates on the net. One of them is the arc42 template. If that's to big for you, it also contains a(sub) template just for concepts.

There is no special UML Diagram. You can use any of the existing Diagrams and use different representations of the elements like using different colours for old new, modified, new components and / or behaviour. If that's not enough you can work with different stereotypes or even define you own meta model which is a advanced topic and maybe overkill.

  • The link redirects me to a german version of the website. Please edit the link to use .org instead of .com for the English version.
    – Christophe
    Commented May 28, 2017 at 19:40
  • @Christophe I've changed the link.
    – andih
    Commented May 29, 2017 at 2:44

There is no UML diagrams that focuses on changes: all the different diagrams are meant to show the desired (or actual) situation.

Nevertheless, even if you don't have up-to date models, you can start using UML to show highlights of the change. For example:

  • a use case diagram: you'll show a secondary actor involved in login use-case (i.e. the openId identity provider). You could also show the redundant use-cases and make an anotation to clarify that they're going to be discared.
  • a sequence diagram: this will help you to represent the interactions with the identity provider for the interactions it is involved in.
  • a class diagram: you may limit this diagram to identity relevant classes (domain model) and the classes involved in the login process (design model).
  • another less used option, but potentially very useful here, is a package diagram. THe advantage of this is to give you an overview of the dependencies between packages and hence help you to analyze how the openId change could propagate through the system.

This limited reverse engineering is of course an effort, but it may help at the beginning of the project to analyse what is involved, and hence better identify and understand the work that will have to be done. But as such, UML won't provide you any estimate.


Like it was mentioned in the previous answers, UMLs are not specially good at describing changes. We could project the new model over the actual one and foresee the impact on the code base, but I presume the result would be a collection of diagrams hard to read by people unfamiliar with the language.

Nevertheless, It may interest you another type of documentation. For instance, The traceability Matrix.

We could cross the actual requirements (or the use cases) with the new features and determine the impact of the new features over the existing ones and the weigth of every change.

In large projects with countless use cases and requirements could be hard to draw the matrix, but we can narrow It down only to those "bounded contexts" of the system that we presume are directly involved with the changes and expand the matrix as the analysis moves forward.

Lately, when the matrix is done, we could choose those changes that caused major impact on the system and describe textually the nature of the changes.

Finally, if we consider UMLs to be necessary, we can translate the previous literature to diagrams.


You could use the notions of diff (colors) inside UML-as-a-sketch diagrams (perhaps some tools support this?). I've done it with Use Case diagrams (the diagram is in French, but green is new a new feature, blue is changed, yellow is existing):

enter image description here

In my example (which is from a GitHub project) there were no removed (redundant) features, but you could do it with strikethrough in the diagram and/or with red-color Use Cases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.