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.

Welcome to another of our webinars in which we delve into some of the techniques we teach in the course in more detail or discuss some of the issues that affect business analysts. In this session we will go more deeply into the most common technique used by any business analyst, that of the stakeholder interview.

This can be one of the most difficult techniques to use, and there is always something new to learn about how to conduct an interview.

Let’s get straight into it and explore in more detail the intricacies of conducting an interview with our users.

Why Should a Business Analyst Hold an Interview? 

The first purpose for an interview would have course be to explore the existing system. This is usually the first thing we have to do when beginning a new project, that is to understand the existing system which will be replaced by a new one or enhanced in some way.

Other contexts may be to define the business goals and objectives of the project, or to drill down and understand the project contexts and the conditions under which it will operate in more detail.

A business analyst will always want to understand processes, procedures and structures that are in place in an existing system. Alternatively, the analyst will seek requirements for the new system within the constraints under which it will operate.

Experienced business analysts will also look for the informal information flows and collaborations that occur between the users, because these can be the most crucial requirements of all. Not everything will be automated by the existing application, or the new solution once it is implemented.

Outside of this automation boundary there will be interactions that occur between people, often ones which are not documented. The analyst needs to understand how the people work as a team, not just how they interact with the system.

What Can an Interview Do For a Business Analyst? 

The interview is not just to elicit facts and figures or to develop process models, they can also be to establish the opinions and beliefs of the people who will use the system. These can often be more important in revealing than the facts about the system itself.

Never underestimate the importance of people’s feelings about the existing system or their wishes for requirements in the new system. These can have emotional value to the people. We need to understand the morale and culture of the users. We need to capture their emotions and attitudes. In this way we will begin to understand the type of solution which would be successful for them, in their environment and within the context of their team culture.

The interview will also define the goals of the stakeholders and what they need from the new system. It will define their desires for the future and the direction they want their team, department or the organisation to follow.

A crucial element of the interview is to also build up a relationship with stakeholders, and establish their trust. It is possibly the most important thing to do. Unless the users believe that you are interested and committed to finding the best solution for them they will not trust you with their future. The credibility of the business analyst is a most important factor to the success of the business analyst.

Communicating with the Interviewee

The most important factor in the success of the interview is of course the interviewee. The business analyst needs access to their knowledge and skills. They are the ones who know what the true requirements are to ensure the success of any solution.

Business analysts are there to provide communication between the users and IT. They should understand that users can be intimidated by IT, and the business analyst should behave sympathetically to their feelings. Any change can be fearful to the users, and the business analyst should behave in a way that is sensitive to their potential fears.

The interviewee can be motivated by their fears and needs on one side, but also by their hopes and ambitions on the other, and above all by the need to be understood. They want to know how any changes will impact upon their job, responsibilities, influence and even power. Senior managers will be concerned about their power base. Professionals and more junior staff will be worried about job satisfaction, and ultimately job security.

Maslow’s Hierarchy of Needs in Interviews

Business analysts need to have an understanding of the way in which people’s beliefs and needs operate within their minds. One model for understanding this is called Maslow’s hierarchy of needs. This is illustrated by the pyramid in the diagram.

The pyramid illustrates begins with basic survival at the bottom, through to our highest aspirational needs at the top. At the bottom we can see the need for sustenance. This is the basic need for good health and a basic salary which will enable us to live comfortably. This is the minimum in a modern society.

Above this, we would like stability. No one likes change unless we are initiating the change and can control it. We desire security and confidence in the future. We dislike the unknown. We would like to know that we have the future planned out. This can work out in practice as, for example, having a superannuation plan.

Once we have the basics met, then we want to know that we are valuable and are making a contribution. Friendship and belonging are measures of that self-worth. These can work out as being part of a working team or group of friends.

Our esteem can be fully met when we believe we are respected and have status within our situation, either at work or among our friends. A practical example would be a senior job title which demands respect.

The ultimate need is to know that we have achieved our dreams, or have a challenging job, or completed a task which was very difficult. These confirm our highest aspirations.

Communicating with Different Kinds of Interviewees

Now let’s consider what happens during the interview with the interviewee. The business analyst should be aware of the body language, the dress code, behaviour and verbal language of the interviewee. These are ways to understand their desires, their needs and even their agendas.

Be careful not to stereotype people by these parameters. Some anxiety during an interview is common and should not be thought of as a permanent feature of their personality.

The business analyst should adjust the approach to the interview according to what is detected. Impatience and anger should be dealt with tactfully, but firmly because we still have a job to do. Anxiety and fearfulness should be counteracted with friendliness and reassurance. If the interviewee appears to be dishonest, misleading or to have a hidden agenda, then the business analyst should be asking questions more closely and confirm any answers from another source where possible.

Combating Interviewer Bias 

The interviewer should be aware of their own biases and preconceptions of the situation and not allow them to interfere with a neutral attitude to investigating what the true requirements are. To be biased will prevent the business analyst from gathering the true requirements, instead of the requirements they believe the user wants. These will inevitably be incorrect.

Sources of bias would be the business analyst’s education, upbringing, intellectual attitudes and emotions. Being professional at all times will ensure that a good attitude will deduce the real requirements that are needed to provide the correct solution to the users.

How to Act in a Business Analyst Interview

The interviewer should understand and adjust to the interviewees personality and motivation. They should endeavour to win their confidence, respect and ultimately their cooperation. As we’ve said already it is imperative that the users have confidence in the business analyst and the job they will do in documenting their requirements, needs and aspirations. They are trusting the business analyst with their future.

The business analyst must actively listen to the user and know what they are actually saying. They must not impose their own judgements or beliefs on top of what the interviewer is actually saying. It’s imperative that the truth about what the user is saying comes through in the requirements. Otherwise the business analyst will fail and the requirements will be rejected by the users and not signed off.

Preparing a Business Analyst Interview

What to do Before the Interview? 

So let’s have a look at a few steps that should be followed by the business analyst before going into the interview.

The first step is always to examine existing documentation where it exists. Look for the language and terminology used by managers and stakeholders. Try to build a common understanding of the current system, processes and environment in which users operate. It will help to build relationships and establish the confidence of the users, if we show that we already have some knowledge of their situation and can accurately use their jargon.

Be careful not to use their jargon unless you truly understand what it means. It can be very embarrassing when you are picked up for use in a term incorrectly. Users often believe everyone understands their terminology.

Second step is to define the objectives of the interview. There is no point setting up a meeting unless it has an objective and success can be measured, so that we know when we have achieved what we set out to do.

Establish in advance who are the correct people to interview. The business analyst at this point should halve developed an understanding of who the key users of the system are, and who has the most complete knowledge of the requirements.

Consideration should be given to those who seek to impede the project, and a strategy should be developed as to how to deal with them. They should not be ignored, because they can justifiably complain that their requirements were not taken into account. Equally their opposition should be taken into account when interviewing or interacting with them in any way. They must be included in the analysis process.

Preparing to Interview Stakeholders 

The next step is to prepare the interviewee for the interview. The best way to allay their fears or their opposition is to inform them of the objectives and expectations placed upon them in advance. Once they understand the interview will take place and why it must take place, give them time to think about how they will approach the interview so that they can define any issues they have in advance. That way they can have confidence that they can make a contribution to the interview.

The final step is to decide what type of structure to give the interview. For example, do we need to ask open questions which will elicit opinions, ideas and potential issues. Alternatively, are we just after facts and figures and should be asking closed questions which have short definite answers. Should the interview be highly structured because it’s a formal meeting, or can it be conducted in an unstructured manner even over a coffee.

Open vs Closed Questions for a Business Analyst Interview

Pros & Cons of Open Questions

This brings us to the question of open and closed questions and which to use.

Open questions are used when we do not know what the answer is likely to be. When we want to obtain rich detailed explanations of how the system works, to reveal the needs interests and opinions of the users in detail. When we want to pick up vocabulary beliefs and values of the interviewee. They also help to put the interviewee at ease allowing them to express themselves in their own way.

The disadvantage of course is that we will get some details that are irrelevant, we lose some control over the interview and they are more time-consuming. However, it is often necessary to accept these disadvantages.

Pros & Cons of Closed Questions

Closed questions are used when we know there are only a few valid answers and we need to know what the definitive correct answer is. For example, where the answer is a definitive yes or no, or where the answer is a single number.

The advantages of closed questions are that they are quick, they allow us to control the interview, all the detail is relevant and it is easy to compare answers with other interviewees. The disadvantage here is that they do not provide the rich data we might need, highlight key issues we might not be aware of, they do not help to build rapport with the user and can be quite boring.

Questioning Techniques for a Business Analyst Interview

There are some rules that must be obeyed when we ask questions. Always use probing questions to elicit the answer that is needed.

Always avoid leading questions that suggest to the user that we want a certain answer, or that a certain type of answer is the correct one.

Always go prepared with a list of questions to be asked. This enables subjects to be tackled in logical order. It also avoids long silences when we reach the end of a topic while the business analyst is thinking of what the next topic should be.

A useful technique to ensure that you have all the detail and have understood it, is reflection. To do a reflection you repeat the answer back to the user to make sure that you have understood it correctly. For example, we can say, “Let me make sure I have this straight. You send an email to the client, then…”.

Structured vs Unstructured Interviews

Let’s have a look at structured and unstructured interviews.

Structured interviews are very formal with all questions planned in advance. The same wording and word order is followed, very formally and all interviewees are asked the same questions.

Unstructured interviews cover general topics of discussion. They may be planned to some extent but not as rigidly as a structured interview. The order and wording of questions is not rigidly planned. There is more scope for allowing the user to express themselves in their own words.

Structured interviews tend to be used with senior managers who expect certain behaviours and processes to be followed. Unstructured interviews are more common with junior users who actually use the system and have detailed knowledge we seek.

What Not To Do When Conducting An Interview

This slide might seem obvious to anyone who has worked as a business analyst before, but it must be said. There are certain things we never do as business analysts conducting an interview. We do not argue with the user, lose our temper, appear to be superior to them in any way, criticise their answers or enter conjecture into their answer. These are simple things to avoid which can expose the business analyst as being unprofessional, and can disrupt the relationship with the stakeholders.

Do not use inappropriate jargon, such as complex IT terminology. This can intimidate the user.

An essential practice is not to move on to another topic until you have fully understood the current subject. It can be difficult to return to the topic later with the same user.

Finally, it is essential never to assume that we are getting the whole truth from a single user. Answers should always be corroborated from more than one source wherever possible.

Wrapping Up Interviews 

To complete our webinar today let’s just recap some of the golden rules that we’ve discussed in our travels.

Don’t believe everything you told, but corroborate everything that you are told against another source if possible.

Reflect back the main points to the user if there is any doubt about understanding exactly what was said.

Finally, at the end of all interviews, the business analyst should send an email or some kind of communication to the interviewee with notes about the main points that were discussed. This has two purposes. One is to give you the confidence that what you have gathered as requirements is sound. The second is that even if the requirements do not have to be signed off, the interviewee cannot change their mind later and claim that that is not what they said. The email acts as a confirmation of what was said even if no signoff his required. It gives some protection to the business analyst that the requirements are accurate, and cannot be denied by the interviewee later.

The post Business Analyst Interviews appeared first on IRM Training.

When done well, an interview can be used to clarify any ambiguity as well as verifying facts of business background research. It gives a great opportunity to extract rich and detailed information from key stakeholders.

A successful interview is often the result of the experience of the interviewer and their ability to pick up on requirements which are not initially obvious. This is a skill that can be improved with some coaching and a lot of practice.
When conducting interviews remember:

• Interviewing for requirements can be either a formal or informal occasion but the end goal should be the same.
• Ask:
  • open ended questions to find gaps in your information, and
  • close ended questions to confirm your findings.
• Do background research prior to the interview to contextualise the interviewee’s responses and save time.
• Diligence at this phase of the project can save huge expenses in reworking later on.

If you want to improve on your interviewing techniques… practise is everything. Come along to our workshop or start holding interviews more often in your work environment. There is a reason it is one of the most common forms of elicitation.

We cover interview techniques with practical role playing in our 3-day workshop Business Requirements Elicitation.

If you enjoyed this article, you may also like:

How to Interview Your Boss

What Are Good Business Analysis Questions?

Problem Analysis Techniques

The post What’s the Most Popular Form of Elicitation? appeared first on IRM Training.

This template from our Writing Better Requirements course  serves as a guide for setting out your requirements specification document.

When starting a new project, this template can be used as a map to help you approach your business analysis work.

Remember, up front planning helps you avoid going off-scope and over time. Our Requirements Specification template has been used by a variety of large companies as the reference point for their project requirements.

If you enjoyed this article, you may also like:

Writing Better Requirements

Requirements & Big Data Projects

Just Enough Documentation

The post Download a Requirements Specification Template 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.

• Totally baffled (doesn’t understand what you mean) or
• Totally exasperated (at your lack of preparation)

So we can be sure that good business analyst questions explore and investigate, they don’t just harvest facts. How do we phrase these questions in a non-technical way that stakeholders with different priorities will open up and participate in an insightful discussion? After all, it’s the business analysts job to turn interview answers (among other things) into requirements.

Well, without further ado, here are 10 of our favourite business analyst interview questions.

Good Business Analyst Interview Questions:

1. How much does it hurt?
2. Who does it impact?
3. How does it affect your daily operations?
4. What affect does it have on customers?
5. What does this problem stop you from doing?
6. Who will benefit from fixing this problem?
7. Who might suffer?
8. What could get in the way?
9. What will success look like?
10. How will you measure it?

Interestingly, not one of these questions is technical in nature, they’re all about the person sitting opposite you.

If you’ve got some of your own favourite questions or would like to comment on this list, please give us your thoughts!

If you’d like to practise asking these questions and discover how useful they can be, join our workshop Requirements Gathering & Specification.

If you enjoyed this article, you may also enjoy:

Six Business Skills Every BA Needs

How to Interview Your Boss

Problem Analysis Techniques

The post What Are Good Business Analysis Questions? appeared first on IRM Training.

This recent paper, Forward Thinking for Tomorrow’s Projects – Requirements for Business Analytics, by Joy Beatty and Karl Wiegers of Seilevel Inc. avoids most of the technology jargon and instead focuses on what’s important for the business analyst.

It’s an excellent paper resource, which we recommend you read in order to keep up with the changing landscape of the business analyst career.

If you liked this paper, you may also enjoy:

Data Modelling & Object Oriented Development

There’s More to Modelling than Runways & Catwalks

Learn more on our course:

Data Analytics & Business Intelligence

The post Requirements & Big Data Projects appeared first on IRM Training.

This paper – based on IRM’s Writing Better Requirements workshop – takes a top down view of the requirements life-cycle. The paper looks at where business requirements come from and what analysts can do to turn them into solution requirements that developers can work with. Understanding the end-to-end process is a first step in producing well written, clear and specific requirements documentation.

The source of requirements

As we know, every organisation has (or should have!) a business strategy which describes how it will achieve its objectives, its goals. For business units within the organisation to achieve these objectives, opportunities need to be seized or problems overcome.

Equally, every organisation has a framework in which it operates. The framework ranges across many areas – customer needs, market forces, regulatory, how it’s organised and structured, etc. Of particular relevance to the business analyst is the enterprise architecture, the blueprint of the organisations processes and systems.

The business strategy, together with the enterprise architecture, give business units a framework to achieve their business objectives.

To seize opportunities, to solve problems, we need to make things happen and this is done through projects.

Without wishing to upset anyone who might favour one project methodology over another, it’s fair to say that in some shape or form every project has a business case and a terms of reference. These may be written down or in someone’s head, they may be set in stone or fluid and changing. Either way, the business case should be telling us what we’re trying to achieve and the terms of reference should tell us (or at least give us a framework) of how it will be done.

What we’re trying to achieve – be it removing a supply chain roadblock or launching a new product – is the essence of business requirements.

The terms of reference together with the business case, enterprise architecture and organisational strategy, give us our high level source documents for the project.

One of the golden rules of business analysis is to keep an open mind. As such new information (e.g. extra functionality, performance constraints) is often identified by stakeholders during the investigation and analysis phase. If approved, these additional requirements need to be added to the overall scope of the project.

The high level source documents drive business requirements and these business requirements, together with stakeholder requirements, can collectively be called user based requirements. Each one is documented in a template and forms part of our overall single document along with references to the high level source documents.

Although stakeholder requirements translate into business and/or solution requirements, it’s important not to lose track of their individual needs. The needs of stakeholders should be easily identifiable, after all they hold a stake in the project and can make or break it.

Read the full paper here: Writing Better Requirements

If you enjoyed this paper, you may also like:

How Clear is your Writing?

Mind Mapping Requirements

From Mission Statement to Business Process

The post Writing Better Requirements 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.

1. Keeping up with meetings because you can’t take notes as fast as the speaker talks
2. Making sense of your notes at a later time (many people say they can go back to a mind map months later and understand the flow and intent of the meeting – and its outcomes)

There is no right or wrong way to create a mind map. Some people recommend using many different colours and drawing shapes – that’s OK for your own thoughts but usually too time consuming for note-taking in a meeting or interview. Rich pictures are an important way of enhancing the mind map to aid remembering at a later date. You will develop your own style and technique over time.

If you are using a note book, it is a good idea to use the unlined side of the page (lines can be distracting) and to keep the paper in landscape mode (we tend to draw horizontal oval shapes because it helps to write in the words).

We are after speed not neatness. Its’ beauty is in its simplicity.

The Process

• Start with a central idea or meeting topic in the centre of your mind map. From this central idea all the sub-topics will flow outward.
• As people present ideas and concepts, simply draw a branch off the main idea or sub-topic.
• An arrow from one item to another indicates that one idea flows from one item to another.
• Circle the idea, or draw a picture around it (like a star or square) to emphasize important points. If you feel like using rich pictures or writing a few dot points next to an idea do so. Mind mapping is designed to get you thinking from both your left (logic, fact) and right brain (feeling, artistic). The rich pictures keep the creative mind active while the analytical handles the notes.
• An arrow pointing both ways indicates the subjects are of equal value and relate to one another.
• There may be circles with no attached lines. That’s ok and simply means it’s a thought or topic in its own right and not necessarily related to the central idea. It may be an important idea, although off the main topic, and we don’t want to lose it.

Software

Mind mapping software is also available – there are a few dozen available including:

• iMindmap has a free trial available
• Mindjet also has a free trial available
• FreeMind. The fully featured version is free with no restrictions

Before jumping onto the web and downloading an application, try mind mapping on a piece of paper. This helps your brain get into mind mapping mode without being distracted while you learn how the application works.

Once you’re comfortable using the mind mapping technique, it’s a lot easier to use a software tool and to see if it offers you any real benefits.

If you liked this article, you may also enjoy:

Problem Analysis Techniques

Creative Thinking Techniques

Stakeholder Communications – Pictures not Words

The post Mind Mapping Requirements appeared first on IRM Training.