IIBA Multimodels

BA Core Skills - Overview & Intro

© Ability Engineering 2007 Page 1 of 26





Imagine a typical business project which a BA may get called into.

The departments involved have a process, but only sort-of, and nobody really sticks to it.

Also, each different group within the department has their own set of tools & techniques for getting the job done, and their own private stores of knowledge.

Mostly, they are using MS Word and Excel, with a bit of MS Project thrown in occasionally. Mapping the interactions between the teams is a challenge: it’s mostly done via emails and meetings, with some information kept on a shared drive, but with no clear organisation.

Those who, like me, are contract BAs are now looking forward to many months of lucrative work, organising the business processes, understanding who produces what, and organising the knowledge of the team.

Confident that we can significantly improve their business performance.

Except this isn’t a business project: this is an IT department. And the groups are all part of IT. There are BAs, 6-sigma process modellers, UI and Ux designers and testers.

Sure, we have a process - sort-of. The BAs probably use one tool for requirements management and another for use cases. The 6-sigma people another for processes.

And the UI designers use something else to create their wireframes. But they take input from the User experience team, who use PowerPoint for their User Stories. And the testers use another toolset, but it’s OK, because they get a 1-off email with a spreadsheet of the requirements, and keep their test cases somewhere else….

And the poor Project Manager tries to make sense of it all with occasional snap-shots from everyone, but keeps their own list of risks & issues. And the plan lives in MS Project.

And stranger still: this situation hasn’t changed that much in the 20 years that this author has been involved in large-scale IT projects.

Has anything interesting happened in IT in the last 20 years…..



BAs are typically charged with creating a single, coherent set of information about a project. We’ll call that coherent set of data a ‘model’. Examples of models are Process, Use case, conceptual, Requirements or User story/Journey.

These models have defined types of information within them, and many books get written about how they can be created.

This presentation will suggest that just having one model type as the focus of a project means the project will be limited in what is formally ‘known’ about the project, and that having multiple, linked models can be hugely beneficial, both to the quality of the focal model, and to the project in general.

Some model types have evolved to capture particular kinds of knowledge. For example, the Business Process Modelling Notation allows an accurate picture to be created for the processes within an organisation. It records who does what activities, in what order, and what deliverables are produced and consumed by each activity.

A great many specialist tools exist, which focus on the capture of individual knowledge types....



Even if a project is focussed on one model type – for example, a BPMN Process Model – then there’s much more knowledge which the project encounters as that model is created. So in a process model, the BA will discover that some processes use functions of particular software systems, where those functions might be captured in another form – the use case model for those systems. They may also capture information about the organisation: not just who does which processes, but how those people fit into the organisation, and who has what roles within the project.



Having a number of different models in a project means we need to start to apply some of our BA skills to ourselves. If this was a business, we might create a domain/conceptual/data model of what things are known by the business. For a BP Model, it might look like this.



A simple meta-model for Use Cases



And another for the domain model of the business.



..and there are lots more.

These are particularly important. They are part of the life of most BAs, but rarely make it into a structured analysis tool. But they are vital to keeping a project moving forward in an organised way. Knowing who’s doing what, who owns what, what the risks & issues are is just as important knowing what the requirements & user journeys are.



This is the one you’ll have learned on most UML courses: take the nouns from the text of the Use Cases, and form them into a domain model.



A more obscure example, but one which spans two areas which are normally spread across time and organisation. Those who design a Data Warehouse or MI system to monitor a process, and those who design the process in the first place may work in very different ways, but the ‘Business Event’ is a shared idea.

So, link the Business Event from the Process world with the ‘fact’ in a fact/dimension model which the data people use.



A more down-to-earth example.

Most projects have loads of lists & spreadsheets of risks and issues, notes of meetings and actions, so why not hook them up to the requirements/analysis/design artefacts which they refer to? This makes reporting on them more informative: Risks know what ‘thing’ (requirement/use case/component ) is causing the risk, and those elements know that there is a risk associated with them.

Simple stuff, but powerfull.



But these models are all part of a larger picture. Together, then represent a rich picture of what we can know about a project, from many points of view.

BUT, only if we choose to link the meta-models together.

So we might say that, for example, we may link

• RISK to a DOMAIN MODEL CLASS, to indicate that there’s a problem

• STAKEHOLDER to an ACTIVITY to indicate that the person OWNS the activity

• ACTION to a USE CASE, to remember that there’s an action arising from a review meeting which we need to do concerning that use case.

• ACTIVITY to USE CASES, so show that the process activity needs to use that use case



This is a fragment of a metamodel from a recent telecoms project.

The key item here is the Product Feature. This was the way that the product manager spoke about what the solution did, and what the scope should be – always in terms of this- or that- feature.

So we made Feature the focus of the analysis.

Each product feature had a number of Use Cases: usually in two kinds: some where the user was USING the feature, and some more where they were setting-up or administering the feature (this detail not shown).

We tried to express as much as possible of the function of each feature into Use Cases, but there were still some aspects which needed declarative requirements. A special type of requirement was the non-functionals, attached to each Use Case, which specified the performance, frequency and volume requirements for each use case – really useful for the designers downstream.

Unusually for this project, we also reverse-engineered some existing parts of the administration users interface, to discover the Feature Settings. We made sure each setting got used in a use case somewhere, and each action on the UI was a step in a use case.

Finally, we captured the Risk & Issues in the model, and linked those to any of the other items (links not shown for clarity).

Also, we captured which product release each use case, requirement and feature setting was implemented (links also not shown).



This represents WAY too much information to manage manually – this is what computers are for.

So, get yourself some kind of tool, to which everyone can contribute knowledge, and from which everyone can pull information, and whatever format they want: reports, spreadsheets, documents, diagrams.

And find/write some standards about what knowledge belongs where (your own meta-model) and stick to it.





Documents

IIBA Multimodels