Business Analysts Handbook

Use Cases

About UML[]

UML is a modelling standard primarily for software development, but can also be used for other conceptual models such as describing job roles, business processes and organisation functions. UML stands for Unified Modelling Lnaguage.

It was developed in the early to mid-nineties by staff from several large software firms including IBM and Hewlett Packard. The standards are managed by the OMG. UML is an ISO specification.

UML was developed as an industry-wide standard so that there was an agreed language for documenting business requirements that could be understood across companies. Imagine the problems vendors face when dealing with a company that defines its requirements in an unfamiliar language.

For business analysts these days UML usually means being able to represent requirements with Use Cases, Class Diagrams, or State Diagrams, but is more than just a way of drawing a process, function or relationship. It’s also conventions around the whole of a document, from common labels such as font type to standards for embedding one diagram into another.

Reading the standards can be heavy going, but is recommended. In practice the BA doesn’t need to know everything in the standards, but reading them helps you know what you need to know.

For a business analyst, the most important part of understanding the UML is in understanding the diagram tools, and when and how to best use them. The diagrams are listed below (and should eventually become links to information pages.) They are broken into categories.

Behavior Diagrams[]

  • Activity diagram
  • State Machine diagram
  • Use case diagram[[File:Media:Example.jpgInsert non-formatted text here]]

Interaction Diagrams Communication diagram[]

  • Test diagrams
  • Interaction overview diagram
  • Sequence diagram
  • UML Timing Diagram

Structure Diagrams[]

  • Component diagram
  • Composite structure diagram

The important thing to remember when applying your UML skills is that you are writing for multiple audiences, some of which will be familiar with UML and some who aren’t.

Additionally, even though the UML standards are reasonably stable they are still not wholly unambiguous. Any communication relies on a certain level of assumptions and skills, and you are best served by remembering that few of the people you deal with at work are working from the same world view, assumptions and level of understanding of these standards as you.

The best solutions are to not rely only upon written documents and to have regular feedback loops built into any handover of requirements to designers and developers.


OMG maintains a homepage for UML here;