The Ideal Number of Diagrams and Diagram Elements

„How many diagrams are necessary to describe a system? How many elements per diagram are appropriate?“ Systems developers are familiar with these kinds of questions. The best way to elicit complete and consistent requirements is to visualize them in UML and SysML diagrams. The UML comprises 13 diagram types, the SysML 9 diagram types, some of which were simply borrowed from the UML, e.g. use case diagrams. Others were expanded (activity diagrams) or renamed (block definition diagrams, known as UML class diagrams). And there are also a number of new diagram types such as the requirements diagrams.1

Each of these diagrams offers a different view of a planned system, helping to create a common understanding and improving the chances of successful systems development. But what is the ideal number of diagrams and elements?

Spoiler Alert: There is no Ideal Number

A formula helping you to define the number of diagrams does not exist. In a project containing 100 requirements we cannot automatically deduce a number of, let’s say, 25 requirements diagrams. Or that we will need 7 goal diagrams for a project featuring 20 stakeholders. But isn’t there a way to approximate the number of diagrams?

Let me ask you this: Why is the number of diagrams important at all? A growing number of diagrams often leads to concerns about not being able to keep track of the system. A large number of diagrams may lead to confusions instead of a better understanding.

Each diagram contains information on the relationships between different diagrams and between individual diagram elements, which again leads to concerns, this time about not being able to process this amount of information. Understandable. Specialized, database-supported tools for requirements elicitation and modeling come in very handy in these cases.

The-ideal-number-of-diagrams

Are these too many diagrams?

Objects Get Around

Requirements engineering tools are a means of gathering requirements, test cases, goals, stakeholders, change requests and more. More precisely, with the help of these tools, information on different objects and their properties and relationships are stored in a database, enabling you to visualize the information as needed. For example, you may choose to pick requirement A from a list of existing requirements and drag and drop it to a requirements diagram. You then might add requirement B by adding it to your diagram. This requirement will also be stored in your database, along with all information on the requirements, such as relationships to other requirements. You may also choose to add this requirement as an element in a goal diagram.

You may also choose to add relationships between elements to the diagram. The great thing is that these realtionships will now also be stored in your database regardsless of whether you display it in this or in other diagrams.

Documenting Information

The number of diagrams in systems development may also be relevant for the generation of documents. Working with an integrated solution makes it easy to decide which elements are needed in which documents. This way, you won’t need to worry about large numbers of diagrams, or large numbers of requirements, for that matter. Problems are far more likely to occur in the realization of these requirements. And document generation is easy: With just a few clicks you generate elements and diagrams in a document type of your choice.

The Middle Way for Diagram Elements

A rule of thumb for the readability of texts puts the ideal number of words in a sentence at 9 words.2 Still, texts consisting of only of short sentences are not automatically good texts. The preceding sentence has 13 words, putting it below the desired 20 words and the maximum of 30 words. What does that tell us about the number of elements in diagrams? Is 9 elements the recommended number of elements?

Requirements-Diagram

Are these too many elements?

In school, some teachers made a habit out of filling every inch of the black board in their effort to save time and to make sure to note down every aspect of a subject matter. The pupils would groan in exasperation. Too much information. The use of transparencies with their limited availability of space offered a slight improvement. So reducing the number of elements might be a solution. But wait.

There also were teachers that would not just present you with information but develop it in collaboration with the students. The black board was still filled but there were just a few groans. Why? Because the problem was not the amount of information but the way in which it was presented. Some implications for the number of elements:

  • Actively creating a diagram makes it easier to comprehend interrelations.
  • Reading a diagram created by someone else is more difficult.
  • Accessing information step by step makes it easier to understand relationships between elements and to navigate between the elements inside the diagram.

Conclusion

Don’t worry about the exact number of diagrams. There simply is no ideal number of diagrams, simply because the number is not important. Instead, be sure to use specialized tools helping you to create visualizations of all relevant aspects of your product development. And create documentation containing all of your 10,418 requirements in 123 diagrams at the push of a button.

Sources:
[1] Tim Weilkiens, Vortrag Systems Modeling Language (SysML), http://www.sigs-datacom.de/
[2] Dr. Katrin Prüfig, Kurze Sätze, große Wirkung, http://www.bmtd.de/kurze-saetze-grosse-wirkung  

Michael Schenkel believes in useful tools, that support users in their work and that provide a common working environment for all types of roles in a project. He became a member of the microTOOL family more than fifteen years ago and took over the position of head of marketing for about half a decade. In October 2017 he moved on to a new adventure and we wish him all the best on this new path.

Tags: ,
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *