Thanks to the increasing popularity of industry membership, certification schemes and the development of recognised competency frameworks by organisations like the IIBA, the BA industry has certainly become more mature in recent years. However, we’re a long way behind traditional professions and I still get the feeling that sections of the BA community let us down as practitioners by overstating their capabilities.
By way of example, to become a specialist in the medical industry, you generally need to complete five or more years of tertiary study and a one year internship prior to registration by the Medical Board. Junior Doctors then spend a year or two in internship followed by up to eight years of study in their chosen specialisation. You’ll never meet a General Practitioner who says they can “do anaesthesia”, nor will you ever meet a Family Lawyer who says they can “do tax law”.
A common thread in the BA profession is analysts who claim to be able to “do UML” when they’ve only ever done a course; or, written some Use Cases. In my opinion if you can’t put together a complete and meaningful model containing Use Case Diagrams, Class Diagrams, State Charts and potentially Activity Diagrams, and communicate that model to both business and technical stakeholders, then you can’t “do UML”.
Use Cases are not UML
First things first, Use Cases are not UML. The Unified Modelling Language is a set of modelling techniques used to represent a system. Use Cases are only part of the model, forming what is known as the “semantic backplane”. Use Cases in their own right are not a true UML model, but they can form a UML model when combined with other techniques.
A UML Model is broken into three core components:
- The Functional Model, represented by Use Case Diagrams and supplemented by Use Cases, which describes the functionality of the system from the User’s point of view.
- The Object Model, represented by Class Diagrams, which is a logical representation of the data entities and relationships with which the system interacts.
- The Dynamic Model, represented by Activity, State Machines and Sequence Diagrams, which describes the internal behaviour of the system.
All three components provide key insights to requirements elicitation and analysis and should converge as the requirements model matures to completion.
What do you need to know to say that you “do UML”?
As a BA, you should be solely accountable for the Functional Model, which begins with the creation of Use Case Diagrams and ends with the creation of fully elaborated Use Cases. It is bad practice to start writing Use Cases until you have defined the Use Case Model, especially in large teams or projects with a number of requirements packages / functional areas.
As a BA, you should be responsible for the Logical Representation of the Object Model and should work with technical architects and/or data architects to ensure that the physical Object Model and Data Model holds true to the Logical Model. Hence, you’ll need to be able to model Class Diagrams and also comprehend component models and database development artefacts.
Keep in mind that the Logical Object Model should describe the end state view of how data entities interrelate so that to reduce the likelihood of major architectural change – it doesn’t necessarily need to align perfectly with the Functional Model.
The BA should actively participate in the development of the Dynamic Model, as decisions made in activity, state and sequence diagrams have requirements and workflow implications. Hence, you need to be able to both model and more importantly comprehend these diagrams.
So, how do I learn this stuff?
If you’re looking to learn how to model UML properly, you can start with books like “UML Distilled” by Martin Fowler and “Use Case Modelling” by Kurt Bittner and Ian Spence, or attend one of the many courses that are available. This will give you basic skills but you’ll need to find someone who can actively coach you to really learn, as UML is as much an art as it is a science.
The best piece of advice I can give regarding coaching is to try to get your student to think about who the consumers of their requirements model will be (business stakeholders, developers, testers) and how it will help them in their role. “Stakeholder Centric Design”, if you will. You’ll also need to coach them in the best ways to develop artefacts so that they integrate with requirements management tools and survive change.
In conclusion, if you don’t know how to do UML, then don’t sell yourself as someone who does. You’ll earn more respect individually and BAs will gain greater respect as a profession. Conversely, if you do know how to do UML, make sure you take the time to coach your peers so that they learn to do it properly – the reputation of our profession depends on it.
