Analyse this User Story:

“As a Data Analyst, I want an anonymised copy of our 2025 sales data, so that I can use it for customer research without risking exposure of individual identities.”

While this may look like a well-written User Story that follows the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) criteria, there is some ambiguity that carries potential legal, ethical and reputational implications.

Whether we use AI simply to assist with some of the tasks or we have a sophisticated AI tool that can process and output the anonymised data, any ambiguity that is not clarified may lead to unintended results.

Analysis

Anonymise – Wouldn’t simply obscuring or removing the customer names from the data make it anonymous? Well, technically, and by the definition that AI understands, yes. But what if the data includes addresses or phone numbers? Wouldn’t that potentially still reveal someone’s identity?

So to be safe, why don’t we just remove all personal information? Yes, that’s possible, but what if our research needs to identify statistics based on customers’ postcodes / cities / countries?

These are all questions that good a Business Analyst needs to ask when eliciting requirements from the stakeholders. The good news is, such elicitation techniques can be learned, and as with many things, the more you practice the better you become.

Ambiguity in Requirements Documentations

And don’t forget, in the requirements lifecycle, requirements elicitation is only one link in the chain. After eliciting the requirements, you still need to document them so that the requirements can be implemented, tested, deployed, used and supported.

As we know, and as we can see from the example User Story above, the English language is prone to ambiguity. That’s why good requirements documents often include visual artefacts, such as BPMN diagrams, data models, Use Cases, Decision Trees, etc. The structured nature of these artefacts allows you to efficiently describe processes, data flows and rules with minimised risks of misinterpretation, by both humans and AI tools.

Become an AI-Ready Requirements Expert

• Business Requirements Elicitation
• Business Analysis Accelerated
• Business Process Modelling
• Writing Better Requirements

– Browse all Business Analyst Courses. –

The post The Risks of Ambiguous Requirements in AI appeared first on IRM Training.

And not a technical solution but a business solution. As a business analyst you definitely need to understand how technology can be exploited. Just leave the technical (i.e. physical) design to others who specialise in this field.

As mentioned, the BA can add the most value by designing a business solution. So why isn’t the word “designer” in the job title?

There’s a great article on this topic by Tony Heap, an agile coach and trainer in the UK. Tony now calls himself a Business Analyst Designer rather than a Business Analyst. Taking this a step further why not Business Solution Designer?

What about you? Do you just gather requirements or do you also help your customers design business solutions? Read Tony’s article here.

If you enjoyed this article, you may also like:

The Creative Business Analyst

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

From Mission Statement to Business Process

The post Business Analyst or Business Solution Designer? appeared first on IRM Training.

Whoever you’re writing for, they’ll only read it if there’s something they want or need to know. So as writers we need to put ourselves in the reader’s shoes if we want our written communications to be effective. Fortunately, writing skills are like any other job skills, you can improve them through effort and practise.

To start, creating a profile of your reader will help you focus on what information is most relevant to them, and from this an appropriate writing style.

Your writing style will depend on the nature of your audience (for example their job role, their knowledge of the subject matter, their familiarity with diagramming techniques), and the type and complexity of the material itself.

Here’s a short exercise on profiling your readers and how to write about the same topic to different audiences. And don’t worry about the topic, it’s one you’re already an expert on – yourself !

Tell 3 different types of readers something about yourself

Write a short note describing yourself to:

• A social or sports club you’ve just joined.
• Readers of a review (movie, food ,book etc. )you’ve posted online. An “About the author” summary.
• A promotions board for a new role or position
• An old friend you’ve made contact with after some years

Consider the different audiences, the words that you would use and what you can and cannot assume in each case. Each audience is going to require a very different style. Think about the detail that you want to supply and what tone you will adopt. Ask yourself:

• What do you want to say?
• What does your reader need to know?

To get started, a good idea is to use a table like this to make a list of key words:

[ws_table id=”11″]

As you flesh out your keywords you’ll also start asking yourself what’s more relevant – what I want to say or what does my reader need to know?

If you’re writing up meeting notes then you want the notes to be an accurate reflection of what was said – i.e. what you want to say.

However if it’s a recommendation or executive summary, then the focus moves from what do I want my reader to know to what does my reader need to know.

In the words of one famous author – it’s not about you, it’s about them.

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

Writing Better Requirements

How Clear is your Writing?

An Introduction to Technical Writing

The post Who Reads Your Stuff Anyway? appeared first on IRM Training.

Sometimes our job can just become one problem after another. We’ve got to be careful not to get depressed by all the challenges we face!

So rather than just asking analysts what problems they have, what issues they need to tackle, we’ve also been asking them what problems give them the most satisfaction in solving.

Here are 12 positives to the business analyst job based on some recent surveys run by IRM. The list below is what business analysts said when we asked…

Which sort of problems give you the most satisfaction in solving?

1.    Working out why something is failing then working through it to a solution
2.    Delivering positive business benefit to clients
3.    Finding a simple solution to a complex problem
4.    The more difficult the problem, the more satisfaction in solving it
5.    Those that help people achieve more
6.    Help the organisation grow
7.    Making people’s job’s easier, simplifying their work
8.    Challenging – think outside the square
9.    Analysing to find the root cause
10.    Working as a team to come up with a solution
11.    Problems that initially present themselves as difficult or challenging
12.    Solving problems based on intuition

As you can see, there are lots of positives to the role, even if it can be hard to see past the next problem to solve. This can be part of what makes the job so enthralling.

If you’re considering becoming a business analyst or are looking to upskill or refresh your knowledge, feel free to check out our courses for business analysts.

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

What Are Good Business Analysis Questions?
Six Skills Every BA Needs
The BA’s Journey – From a Current to a Future State

The post 12 Positives To Being a Business Analyst 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.

An easy way to stay focused on this objective is to think of business analysis as a journey – a journey from an as is to a to be system – from a current to a future state. Software development methodologies (SDLC’s) such as agile, iterative, waterfall, etc. are the means of travel but you don’t have to be an expert in methodologies to have a successful journey. The following extract from IRM’s Business Analysis workshop is a simple guide which can be used (whatever the methodology) to help you keep a clear picture of what the successful BA journey entails – reaching your destination.

Read the full paper here: The Business Analyst Journey

If you enjoyed this paper, you may also like these:

What is a Business Analyst?

From Mission Statement to Business Process

Is Business Analysis Low Tech?

The post The BA’s Journey – From a Current to a Future State appeared first on IRM Training.

They either approach a client meeting with pre-conceived ideas on what will fix the problem or jump to conclusions during the investigation phase without understanding all the underlying issues.

We can all be guilty of this and sometimes the more experienced the analyst, the more prone they are to fall into this trap. Why is this so?

Problem Solving

When you work constantly with technology you know that in most cases the answer to a client’s problems is going to have an IT component, usually a significant one. Surely it’s just a question of using the right technology – after all isn’t IT embedded into everything we do? Before you know it you’re looking at what technology your company has and how this “solution” can be utilised by the client. But are you solving their problem?

As is often the case, the richness of the English language is both a blessing and a curse. The same word can mean different things to different people. In the world of IT, a solution is synonymous with how a system is implemented rather than what it does.

What might then make matters worse is that every IT system has its own constraints and limitations. We’re already putting boundaries around potential “solutions” to our client’s business problem.

For a client however, a solution is what solves a business problem. Solving the problem might involve a change in procedures, a change of staff, a modification to the company’s business rules – a change to something that might have nothing to do with technology.

Solution Mode

The IIBA® hit the nail on the head with its definition of a solution:

“a set of changes to the current state of an organization that are made in order to
enable that organization to meet a business need, solve a problem, or take
advantage of an opportunity”  (BABOK® V2)

It just comes down to keeping a clear head when using words.

The “solution” to a business problem can be defined as what the client will do to address their problem or opportunity. This is often achieved, but not always, by implementing technology changes.

If you liked this article on Solution Mode Thinking, you may also enjoy:

Is Business Analysis Low Tech?

What Are Good Business Analysis Questions?

How Clear is your Writing?

Try our course:

Analysing & Solving Problems

The post Solution Mode Thinking appeared first on IRM Training.

How things have changed – we now have an international organisation solely for business analysts (with over 26,000 members) plus a professional, experience-based qualification. We also have a reference guide – The Business Analysis Body of Knowledge (BABOK®) – now into its second edition.

And yet the underlying skills needed by business analyst have remained remarkably constant – analysts still need investigative, analytical and communications skills for dealing with clients and stakeholders. They also need specification and modelling skills when dealing with developers and solution providers.

Read the full paper here: What is a Business Analyst?

If you liked this paper, you may also enjoy:

Six Business Skills Every BA Needs

Is Business Analysis Low Tech?

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

The post What is a Business Analyst? appeared first on IRM Training.