Essential UML diagrams in software specification

UML notation allows you to use a lot of diagrams that help you to prepare a complete software specification. After several years and projects working as a business analyst I want to point out those diagrams that I think are necessary and sufficent. I will not describe how to create individual diagrams (there is a lot of theory, examples, templates in the web) , but what are their goals and advantages.

1. Activity diagram – most important one.

Activity diagram is most important because it is the only one which can be relatively easily understood by a customer or stakeholder. Of course, that diagram should be discussed in the presence of the author (Business Analyst). Although this is a standard UML diagram, I personally substitute it with a BPMN notation that is more understandable to non-technical people and allows for a more detailed description of the relationship between process steps.

2. Class diagram

Class diagram allows you to determine the complexity of the forms (number of fields, types, basic operations). I always create two types of Class diagrams:

  • Domain class diagram (conceptual diagram) that allows yout to get the overall relationship between classes (without specifying atributes, operations; just class names). This type of diagram can be discussed with interested non-technicals.
  • Logical class diagram (design diagram) which is an extended version of conceptual diagram. This type can be discussed with more technical staff.

3. Use case diagram (with actors)

Specifying Use cases are very useful to determine overall system complexity (not only forms) and system roles/permissions. In addition, describing use cases is a good place to map requirements.

4. Requirements diagram

Specifying all requirements is a good practice, because you can cover system functionality with requirements described by stakeholder/customer. The best way to do this is connect Use cases with Requirements.

5. Sequence diagram

Sequence diagram lets you to describe interactions between objects (classes, actors, etc.). The value of this diagram for the client is not significant, but it is very helpful to programmers in determining the target system structure.

There are also two additional diagrams which helps in more complex specifications/projects:

A1. Data types

If the system is created by different teams / developers, it is useful to create a common list of data types used in the system. For one “text box” or “string” means 50 characters, for the other 250 characters, and yet another set the maximum size allowed by the database.

A2. Component diagram

Component diagram helps to determine the dependencies and limitations of communication with other systems (eg. SSO or user data from Active Directory, financial data from the financial and accounting system).


The above diagrams were sufficient for the IT system specification in most cases. Remember that every project is different and sometimes it may be necessary to have an extra diagram or those that I have listed are too complicated and not necessary.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s