Taming Requirements Engineering Headaches With UML

All professions are unique in the particular frustrations that they thrust upon their practitioners, and software development is no exception. The same physically intangible nature of software that makes it more difficult to recognize risks and requirements can also contribute to a general perception that software development is easier than it actually is. The result can often be unrealistic and unclear expectations and misjudgments in planning the cost and time required to get the job done right. 

These incorrect requirement definitions are one of the most common causes of defects and shortcomings in software products. And a poll of GitHub developers identified such unrealistic, vague, or constantly changing requirements as a particular source of stress. But they’re certainly not the only source of frustration for developers. Let’s look at some of these additional frustrations and explore how they can be alleviated through the use of UML in draw.io.

Bugs

It goes without saying that a major source of annoyance for developers is the familiar necessity of pinpointing the source of undesirable or unexpected behavior in the codebase. The most egregious examples being those that are especially difficult to track down, those that refuse to go away, bugs that come unexpectedly out of left field, and, of course, the ones that take significant time and effort to fix.

Shoddy code

Whether you inherited it from a colleague or wrote it yourself when you were more youthful and innocent, poorly written code is another obvious source of developer pain. And unclear or nonexistent comments only make things worse.

Code maintenance

Then there’s the need to understand, build upon, or simply maintain unfamiliar legacy code – especially when it was written by a long-departed colleague – or worse, “built by committee” and passed from developer to developer over a period of time.

But enough about problems. You already know the problems that you face as a developer. Let’s talk about solutions. And one of the most effective solutions for a host of problems in any industry is plain, simple communication.

Talk to me

So, we don’t need to go into all the details of why communication is important. That’s a different blog. But I think we can all agree that, when it comes to software development, accurate and complete communication is vital to achieving consistent positive outcomes. In talking about communication, though, it’s important to remember what George Bernard Shaw said: “The single biggest problem in communication is the illusion that it has taken place.”

Sometimes, despite our best efforts, our attempts at communication fail. Or worse, we end up creating more confusion than clarity. It’s at these times that we need to take a look at different ways of making ourselves clear.

Show me

We’ve talked before about the importance of visualization in successful learning. We’ve even cited studies to prove it. But aside from aiding in the actual learning or retention of information, visual communication is quite simply a more effective means of accurately and efficiently transferring information from one human being to another. As William Albert Allard put it: “Words and pictures can work together to communicate more powerfully than either alone.”

Why is this true? Many reasons – including:

• Time – Research shows that the brain processes images 60,000 times faster than text. That’s fast.
• Language/Culture – Verbal communication is inherently limited to language. And even when a language is shared, differing cultures add another level of difficulty. Images are more universally understood than words.

• Simplicity: OK, I’ll say it: A picture is worth a thousand words. Given the choice, which would you rather create (or take time from your schedule to read)?

Some of the benefits of the UML include:

• Getting every team member on the same footing and swiftly bringing new team members up to speed with an overall view of the system. What’s more, once team members understand what they’re trying to build, they can delegate tasks, identify possible issues before work begins, and work more efficiently toward a common objective.
• Allowing you the flexibility to tailor the modeling interactions and elements in a diagram to suit the technologies or domain you’re using.
• Planning and evaluating new features before any work goes into programming them. Changing a UML diagram is much easier and cheaper than the tedious and time-consuming task of reprogramming an entire section of code.
• The ability to communicate more easily and effectively with both technical and non-technical audiences.

No need to spend weeks learning. You only need to know 20% of UML to achieve 80% of your modeling needs.

But what’s the easiest, most efficient way to harness all of the powerful benefits that UML brings to the table?

draw.io

draw.io is the easiest way for Confluence teams to collaborate using diagrams. It’s intuitive. It’s powerful. It gets out of your way. It helps you build diagrams ranging from flowcharts to org charts to ERDs, mindmaps – and yes, UML.

To use draw.io for your UML diagrams, simply enable the UML shape library. Here’s how:

• In the left panel, click on More Shapes.
• Scroll down to find the UML shape library in the Software section on the left, make sure the check box is selected, then click Apply.

If your team works with UML diagrams in Confluence a lot, you can customize draw.io to show this library by default. If you need your diagram to follow the UML 2.5 spec, we have a library for that as well: drawio.com/blog/uml-2-5.

You’ll find more on UML in draw.io in our archives.