A 2016 survey of Australian business analysts across 30 organisations (government, big business, SMEs) found that while 14% used one or more of the popular languages (DFD, UML, BPMN) regularly, the vast majority 76% did not or only very occasionally.

This shows that a small number of business analysts have found benefit in the use of modelling language but the majority still use plain English to try to describe business processes and systems. This may be because the modelling languages can seem intimidating – or more likely the analyst just hasn’t been shown how beneficial modelling languages can be.

The BABOK Guide® specifies that:

“One of the key objectives of business analysis is to ensure that requirements are visible to and understood by all stakeholders.”

While all business analysts want to deliver their projects to the best of their ability, many projects are still over-time and over-budget. Most often this is a result of poorly communicated or mis-interpreted business needs. How often have two people read the same piece of text and come to different conclusions? If you’re not making the requirements as visible as possible to stakeholders then you’re not doing your job.

Using a modelling language is nearly always the clearest way to communicate your understanding of an as-is system and demonstrate your recommendations for the to-be one. The language will also allow you to use layers – high level views to summarise the overall system and detailed views to clearly describe functionality.

Pictures in the form of modelling languages help get all stakeholders on the same page easily – and demonstrate concepts clearly without room for misinterpretation.

If you’re in an organisation that’s already using modelling languages we’d love to know which one you favour – leave us a comment below. If not, come along to our 4-day Business Analysis training and learn how to start making use of this powerful business analysis technique. You’ll also learn that each modelling language has different strengths and the skilled analyst knows what to use and when.

Already down with modelling? We have 6 other business analyst courses.

The post BPMN vs UML vs DFD – which one is best? appeared first on IRM Training.

While user stories do a great job of expressing functional (and often non-functional) requirements in words that business users can understand, that’s not the case for developers. Remember that a business analyst is the communicator between the business AND the developer. There just isn’t enough information in a user story for a developer to do their job.

So how do you get round this? For a really interesting discussion on this topic have a look at the following article Why I still use Use Cases by Alistair Cockburn. Alistair was one of the original signatories of the Agile Manifesto and his article includes observations on some of the key issues faced by organisations using agile methods.

WHY I STILL USE USE CASES

XP pretty much banned use cases, replacing them with the similar sounding “user stories” and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems:

1)   User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?

2)   User stories and backlog items don’t give the project team any sense of “completeness” – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?

3)   Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don’t) – I keep hearing this complaint, “We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role.” No, they don’t have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment – the extension conditions are usually detected mid-sprint, when it is too late.

Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. As not-Einstein said: “Make things as simple as possible, but no simpler.” (The attribution to Einstein has been debunked, it seems.)

In particular, use cases fix those three problems.

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” … and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

In other words, naïve use of user stories and backlog items is causing very real, very expensive damage to companies. Expensive is bad.

The most recent was an executive who was telling about having “delivered” a Scrum project, but it was discovered at acceptance time that there were a whole series of recipients of the system whose needs hadn’t been identified at all. This company is now faced with writing what may amount to a fixed-price contract because the recipients aren’t sure they trust the company to deliver complete and useful software.

Very expensive, very bad. The time spent writing the use cases and doing a more thorough requirements investigation would have paid off handsomely, in this case.

Here 5 reasons why I still write use cases:

1)   The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.

2)   The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.

3)   The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4)   The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: “What are we supposed to do in this case?” (which is normally answered by, “I don’t know, I’ve never thought about that case.”) In other words, it is a thinking / documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.

5)   The full use case set shows that the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

The are several sticky parts for people using use cases as I describe:

*   It is really easy to think all the use cases have to be written up front, when in fact the writing should be staged over the life of the project. The “thinking’ part here is working out how much should be written up front to get the project estimate into a safe place, and which parts can be deferred to just-in-time investigation.

*   These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them. That means additional work is needed, to create user stories or backlog items for each use case, track that each one get developed, and ensure that the complete set of user stories or backlog items do indeed deliver the subset of the use cases needed for the particular release.

*   Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

If you don’t want to think, find a new profession. Software development requires thinking, at all levels.

This article reproduced with kind permission of Alistair Cockburn. To read this and other articles by Alistair go to http://alistair.cockburn.us/Why+I+still+use+use+cases

If you enjoyed this article, you may be also interested in these:

How to Use Use Cases

How to Write Use Cases

The post What Happens After User Stories? appeared first on IRM Training.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application.

So how do we go from a table containing textual information to a specification which a developer can use?

The first step is to turn each business event into a model – either a use case fragment, a DFD fragment or any modelling language you might be working with.

The following event table describes three typical interactions a customer would have with their bank:

Each of these events can be drawn as a separate use case:

These individual use cases (use case fragments) are only half the picture however. Today developers don’t write individual software programs for each event, particularly when multiple events will have numerous common components e.g. database enquiry, ID validation, etc.

What we do want is to be able to combine use case fragments into a single use case. We do this by identifying and sharing common actors (in this example the customer):

While we still need to write individual descriptions for each use case, we’ve given the developer a concise package of functional requirements, offering them the best opportunity to write efficient and effective code.

For an example of writing formal use cases see the paper How to use Use Cases.

The post Use Case Fragments appeared first on IRM Training.

In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the consumer to imagine how the clothes might look like if we were wearing them.

Models in business analysis perform a similar role, they stimulate our imagination so that we can analyse problems, explore solutions. The case for modelling is neatly summed up in this quote from the book Business Analysis Techniques: 72 Essential Tools for Success:

Models reveal the inconsistencies, loops, delays and bottlenecks involved in a process. A systematic analysis of “as is” process models provides a business analyst with the opportunity to think analytically and creatively about what the organisation really needs to do to achieve a better “to be” solution.

Modelling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline from Accounting to Zoology – in between there’s engineering, design, construction, research, etc. Incidentally, accountants use modelling techniques to analyse financial data, zoologists use modelling techniques to analyse, amongst other things, animal behaviour.

Just as accountants and engineers have specific modelling techniques which are used across their respective professions, so too business analysis. But this article is not about which technique should you use – there’s plenty to choose from – it’s more about what are you trying to achieve.

So what are we trying to achieve? It boils down to two things. First what’s the problem – what’s wrong with the “as is” system? To get to the bottom of this we need some dialogue with the stakeholder. If the problem is well documented and understood then great – but often as not the stakeholder will only see the problem from a particular perspective. It’s up to the analyst to dig below the surface and find out the real cause.

Here you’ve got two choices, write a step by step description of the process under investigation – or draw a process model. Which do you think is easier and more likely to draw out the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by product of doing the latter is you get to work collaboratively with the stakeholder rather than them dictating and you taking notes. And you don’t have to be the artist – take every opportunity to hand the whiteboard marker to the stakeholder and say “can you draw that for me?”

The second of our objectives is to decide what the “to be” system will look like. Modelling again offers a rich choice of options. It might be as easy as modifying an existing “as is” diagram or as liberating as asking draw me a picture of what you’d really like to see happening. Very few people would say they can’t understand the following diagram:

A final world on models – they can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall or a mixture of all of these, they all have the same objective…

…to reach an end point and produce a deliverable.

If you liked this article, you may also enjoy these:

Event-Based Analysis & Modelling

Stakeholder Communications – Pictures not Words

Data Modelling & Object Oriented Development

The post There’s More to Modelling than Runways and Catwalks appeared first on IRM Training.

To produce a data model (a logical view of the data) the technique of choice has been, and still remains, the entity relationship diagram (ERD). However in Object Oriented Development (OOD), classes are used to group together things (including data) that have similar properties. Class diagrams in themselves do not provide a straightforward path to database design because they do not represent a logical view of the data. To get this logical view we need to modify how class diagrams are used so that we can have a single view of the data in our application.

Read the full paper here: Data Modelling and Object Oriented Development

If you liked this paper, you may also enjoy:

Event-Based Analysis & Modelling

How to of Essential Modelling

The post Data Modelling & Object Oriented Development appeared first on IRM Training.

The How to use Use Cases paper described a relatively simple event – a student registering for a course. Whilst the primary flow had 5 steps, the alternate flow in the formal (fully specified) use case involved 9 steps each comprising 3 or 4 interactions. The line by line description of the alternate flow ran to one full side of A4 paper and quickly became an exercise in concentration! So how else could we write it?

Read the full paper here: How to Write Use Cases

If you liked this paper, you may also enjoy:

Use Case Fragments

User Stories & The Jungle Book

What Happens After User Stories?

The post How to Write Use Cases appeared first on IRM Training.

An event can be any activity, action or business process where the system under investigation needs to respond. In this approach to business analysis, once the scope of the system has been identified, the first deliverable is a table (a list) of events.

Event-based analysis aligns very well with UML and object-oriented development as both are based on how a system responds to an event. For example, use case diagrams model system responses when an actor initiates an interaction with a system.

Events can be of different types (external, time dependant, internal to a system) and requirements analysis begins with the identification and documentation of these events.

As mentioned, each event describes a condition – a piece of functionality. The system under development must have the capability to successfully process the event.

Each event can be thought of as a functional or non-functional requirement and a typical Business Requirements Document could contain dozens or even hundreds of individual events. Once we’ve defined an event we can further analyse and model the process itself using any one of a number of modelling techniques.

Try our course Modelling Requirements with Use Case & UML.

If you liked this article, you may also enjoy:

Data Modelling & Object Oriented Development

Use Case Fragments

Most Popular BA Techniques

The post Event-Based Analysis & Modelling appeared first on IRM Training.

This switch in thinking is not always easy as we have to ignore the very practical matters of procedures, methods, people, technology etc. The more involved we are in the system that we’re looking at, the more difficult it may be to look at things conceptually. We have to look at what business objective we are trying to achieve. The business analyst who can do this – and explain it to clients and management – becomes a most valuable asset to the business.

Read full paper here: How To of Essential Modelling

If you like this paper, you may also enjoy:

The BA’s Journey – From a Current to a Future State

Event-Based Analysis & Modelling

There’s More to Modelling than Runways & Catwalks

The post How To of Essential Modelling appeared first on IRM Training.

Read full paper: UML Business Context

If you liked this paper, you may also enjoy:

Use Case Fragments

How to use Use Cases

How to of Essential Modelling

The post UML – Business Context appeared first on IRM Training.

When producing project documentation, use case diagrams are rarely used on their own. They will generally be accompanied by a textual use case and if they’re complex, may also have a supporting activity diagram to show what’s going on “inside” the use case.

To keep things simple we’ll stick to use case diagrams and textual use cases. Textual use cases can be both formal and informal. Try the following exercises (from IRM’s Modelling Requirements with Use Case & the UML workshop) to test your skills. First we’ll draw a use case diagram from a plain English description, then build on it using textual use cases.

Exercise 1 – Course registration

The following should be textually analysed and a use case diagram created containing several use cases. Identify the actors, use cases and associations.

At the start of each semester a student can request a prospectus containing a course list. Information about a course is provided, such as the tutor, department and pre-requisites.

The new system will allow students to create a schedule, then select four courses. Each student chooses two others in case their first choices become full or are cancelled. No course can have more than 10 students. No course can have less than 3 students or it will be cancelled. This will be the same functionality as available to other internal users of the system.

When registration is complete, the registration system sends a message to the billing system to send out a bill to the student.

Tutors use the system to find which classes they are teaching and who the students are. The registrar will administer the system.

For a period at the beginning of the semester the student can change their schedule. Students must be allowed to access the system during this time to add or delete courses.

Note: If you have some experience with use cases try drawing a suitable diagram. If you’re new to the field, see below for an example answer.

Exercise 1 – Example answer

Actors: Student, Tutor, Billing System, Registrar

Use Cases:

Student

• Register for courses

Tutor

• View teaching roster

Registrar

• Maintain course information
• Maintain student information
• Maintain tutor information
• Maintain curriculum
• Generate prospectus

For the rest of the exercises and PDF, download full paper here: How to use Use Cases

If you liked this paper, you may enjoy:

What Happens After User Stories?

Use Case Fragments

How to Write Use Cases

The post How to use Use Cases (With Examples) appeared first on IRM Training.