Business Analysts: Make your point with models

A picture can be worth a 1000 words. This article discusses the use of modelling techniques to facilitate establishment of the requirements.

Diagrams and models can be a valuable support to eliciting, documenting and understanding requirements. If modelling is to have any value, however, the modeller needs to ensure that they are doing more than drawing boxes with lines between them. The analyst needs to analyse; models are useful to the extent that they facilitate this analysis.

Unfortunately modelling is often considered as a technical activity. Even ISEB in its diplomas, includes modelling only as an option, rather than core, in its analysis stream. Technical people design effective and efficient systems and databases (at least, the good ones do) - they do not necessarily create flexible models of the business prior to starting the development of the database.

Although this article is primarily concerned with the analysis view, it is worth pointing out that many advantages can accrue from involving developers (particularly architects and designers) and testers at this stage. Developers and testers may enable to assist with the modelling, as long as the sessions are not steered away from analysis and into premature design. Developers can however, usefully consider the design implications of what the analyst is saying and of course they can ask the analyst for more details or for examples try to get their point across.

Perhaps the first thing to clarify is the distinction between models and diagrams; the terms are often used synonymously, but this is not strictly correct, although a diagram is usually the first step towards creating a fully specified model.

The model concerns the detailed information that we gather and analyse. Diagrams offer a view into the model. As the model tends towards correctness, we do not create and discard elements as and when we think they will be useful; the artifacts of the model tend to become more or less permanent residents in the repository. Diagrams, however, can be created as we need them and discarded as soon as they are no longer useful, although some may join those more permanent residents. The important thing to note is that when a diagram is deleted, the underlying model should, by default, remain intact.

There are many approaches to modelling and there are many modelling techniques. Analysts frequently have a favourite technique and use that exclusively. One secret of success being able to select the most appropriate technique for a given purpose and situation.

The Object Management Group (OMG), in specifying the Unified Modelling Language (UML), defines two broad categories of model, static and dynamic. Static models are concerned with data and rules; dynamic models are concerned with process. It is the latter set that are typically the most popular; static models are often misunderstood and are felt to belong to the domain of technical development rather than business analysis; this attitude not only totally misses the potential of static modelling, but even restricts the potential advantages of dynamic modelling.

To the static/dynamic view, we can also add a formal/informal view. All of these types are complimentary rather than exclusive and to maximise our return from modelling we should employee all four as appropriate. These are covered in the following paragraphs.

In ‘Writing Better Requirements’, Alexander and Steven recommend the use of informal models, at least to start the process and to support interviews and other fact finding techniques. Such diagrams, especially when drawn large on a whiteboard, allow us to see the overall flow and connections between entities and to identify who does what and when. Informal models allow us to keep our requirements sessions relaxed and to encourage the participation of all concerned; some clients may be put off by more formal approaches. One compromise that can work well is to use an informal approach in face to face ‘whiteboard’ sessions with clients, and then to formalise these views behind the scenes. The increased formality can highlight questions that need to be considered at the next client session.

Following the creation of the high level view, we can develop the detailed scenarios, or descriptions, of user tasks. The scenarios themselves can initially be developed in an informal manner, gradually adding formality, such as line numbers. My favourite starting point is via business events; this approach has been well described by the Robertsons in ‘Mastering the Requirements Process’. The typical approach to scenarios is to define the normal sequence of actions, followed by at least some of the variant flows.

The static model should be started in parallel with the initial views of the process. Examples of static model are Entity Relationship Models and Class Models. Drawn properly, these can not only identify the major categories of business data and the associations between them, but can also highlight generalisations that demonstrate the conceptual structures underpinning the business. It is important to realise that the associated diagrams do not represent data base designs, nor are they intended to constrain the technical designs. They are simply describing the business in the clearest possible terms so that flexible, adaptable and efficient designs and implementations can be created.
The expression, ‘in the clearest possible terms’ may surprise some people who find these diagrams to be obscure. I have long been a believer in supplementing such diagrams with notes and examples in plain English; a short narrative summary of a least the main diagram is invaluable, not least for yourself if you have not looked at it for a week or so. This point is taken up in the excellent paper, ‘How to Build Articulate Class Models and get Real Benefits from UML’ by Leon Starr and that can be found at http://www.uml.org/#Articles.
The points Leon Starr makes about documenting the diagrams apply equally to dynamic models. In this way, the dynamic and static views can develop in a mutually supportive manner allow us to fully describe the system at hand.

If class models are often thought to belong to the realm of the technical modeller, state models are viewed as even more so. However, if we take an informal approach at a whiteboard session, I have found them to be readily accepted; I avoid all embellishments and complex diagramming of course.

Taking, by way of example, a business concept such as insurance policy, it is surely the business who are best placed to tell us the names of states, or stages, that a policy can exist in during its life. It was presumably the business and not the IT groups who named those states in the first place. Capturing these states, the ‘legal’ order of going through them, and what functions are allowed or not allowed in each of them, provides an additional level of in depth analysis that can be hard to achieve if we avoid this technique or assume that IT have the necessary knowledge.

Once the whiteboard models have been agreed, an individual licence holder for your CASE (Computer Aided Software Engineering) tool can capture it. I would always stress the value of joint white board sessions over everyone doing their own thing with the CASE tool.
The development of models, particularly if we use a case tool, will support the generation of prototypes that help to demonstrate to the stakeholders that progress is being made. Prototypes also allow the stakeholders to confirm what they are seeing is what they believe they asked for. Alternatively, it will allow them to change their minds before we have gone too far.

Analysis models are all about describing the system and getting underneath it to discover the essence; this is analysis. In some circumstances it may acceptable to consider the models themselves as the statement of the requirements. In other situations, we may use the models to drive out lists of requirements. Whichever approach we go for, the correct use of models facilitates both the analysis process itself, the documentation of the requirements, and the communication between all stakeholders. And thinking of the stakeholders, it is vital that we work at a level that all participants can understand; for successful modelling, remember your audience. Above all, avoid trying to force use of the techniques down peoples’ throats.