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.

Use Case Diagram

Use Case Diagrams can be used to help visualise the story described in a Use Case. A Use Case Diagram consists of 3 components:

1. Actor – represented by a stick figure
2. Use Case Name – represented by an ellipse
3. Association – represented by a straight line that links an Actor with a Use Case Name

Example:

Conventions followed when creating a Use Case Diagram:

• The Use Case Name starts with a verb and (optionally) followed by a noun.
• The main / primary actor is usually drawn on the left and the supporting / secondary actor (if there is one) on the right.

Exercise

Course Registration

Task

Analyse the ‘Course Registration’ requirements above and represent them as a Use Case Diagram.

Example answer

Textual Use Case

A textual Use Case typically include:

• Use Case ID
• Use Case Name
• Actors (or Users)
• Description
• Pre-conditions
• Post-conditions
• Trigger
• Primary Flow
• Alternative Flows
• Exception Flows

The Primary Flow is usually quite simple and shows what normally occur in the most common scenario and when nothing out of the ordinary happens. Any possible variations to the normal story are then presented as Alternative Flows, while the Exception Flows describe what can go wrong and how the Use Case will handle it.

Example textual Use Case for ‘Register for Courses’:

Further Learning

In Use Case Diagrams, apart from the simple association there can also be other relationships between an Actor and a Use Case that you can show, such as Extend, Include and Generalisation.

In textual Use Cases, there can also be more complex requirements, possible alternatives and exceptions.

Learn further about Use Cases and more, by attending one of the following IRM Training’s hands-on courses:

• Business Analysis
• Writing Better Requirements

The post How to Create Use Cases 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.

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.

Data Flow Diagram – a process modelling tool

• Data flow diagrams (DFD) show how the functions, or processes, of a system relate to each other via the data that flows between them. They are most valuable in showing ‘what’, (the logical view) but can also be used to show the ‘how’ (the physical view).
• Data flow diagrams can be used to model the processes in a current system and, separately, a proposed new system. In addition they can show either physical or logical views.
• Data flow diagrams are not concerned with control or sequence. As a tool they are of limited use to designers, but are of greater use to analysts in communicating to the client and to the designers.
• DFDs are levelled so as to reduce the complexity at any one level.

Rules for Drawing a Data Flow Diagram

The four elements used in data flow diagrams are:

Data Flow

• Show the movement of data between processes, into and out of data stores and to and from terminators
• An arrow head indicates the direction of the data flow
• The data must have a meaningful name
• They do not show control

Process

• Indicates a function, this should be a transformation of data
• A functional primitive is the lowest process level

Data Store

• Shows data at rest
• May be manual or automatic accumulation of data

Terminator

• Shows the originator and/or receiver of the overall system data
• Represents people, organisations and systems just beyond the scope of the system under study
• Marks the boundary of the model
• Only appear in the highest level DFD – usually the context diagram

Download the PDF version of this guide to DFDs: How To Draw Data Flow Diagrams

If you enjoyed this article, you may also like:

There’s More to Modelling than Runways and Catwalks

Event-Based Analysis & Modelling

Process Modelling 101

The post How to a Draw Data Flow Diagram appeared first on IRM Training.

As an employee, adding value can translate into improving processes, providing better customer service, reducing time to market, delivering better products/services. However to a shareholder or company owner there’s only one value metric – increased profits. This is achieved by selling more or spending less. It’s not for nothing that most CEOs have a sales or accounting background.

That’s not to say that business analysts need sales and accounting skills. What they do need is to see the connection between what they do and how this fits with the objective of the shareholders. If the organisation is a government department or a not-for-profit, then year on year objectives are to do things better, faster and cheaper than last year.

In our Business Analysis course we show how the projects that a business analyst works on can be assigned to one of five categories:

1.    Compliance – legal, regulatory, safety
2.    Reducing costs
3.    Increasing revenue and/or market share
4.    Decreasing cycle time
5.    Improving quality of products/services

Have you worked on a project that doesn’t fit one of these? Tell us what you think in the comments box below!

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

Six Skills Every BA Needs

What Are Good Business Analysis Questions?

Your Project Pitch

The post How Can I Add Business Value? appeared first on IRM Training.

Kipling knew a thing or two about the written language. Tucked away in one of the Just So Stories were a group of words which have become the basis for information gathering, criminal investigation, scientific research and news reporting around the world – Who, What, Where, When, Why. These have become known as the 5 Ws.

The 5 Ws can also give user stories a greater depth of meaning by expanding on the business functionality required by the user.

“As a who when where, I want what because why.”

Here’s an example:

Now you might consider that some of the information in the above example is obvious and needn’t be stated – of course an operator will be in the call centre when they’re answering calls. But what if the operator is in another office in the building and logs in? Do you still want them to be able to access potentially confidential information outside the secure environment of the call centre? Suddenly this 5 Ws user story can also be a trigger to review access and viewing permissions when separate information threads are combined on one screen.

For specifying complex functional requirements, user stories won’t be replacing use cases any time soon but the 5 Ws approach will result in a more specific statement of business need. This in turn will help developers understand more about the context of the functionality that needs to be provided.

P.S. If you have the time to read Kipling’s poem (The Elephant’s Child) you’ll notice that it’s actually 5 Ws and a How. But we all know that business analysis is about the what rather than the how… don’t we?

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

What Happens After User Stories?

How Clear is your Writing?

Use Case Fragments

The post User Stories & The Jungle Book 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.

The reality is, the more sophisticated the software you’re using, the greater the chance it will hinder, rather than help, the business analysis process.

Almost 10 years ago, an article by Scott Ambler, Software Modeling on Whiteboards, argued that the modelling tool with the greatest installed base in the world was the whiteboard. Scott is the agile practice leader at IBM and author of several books on agile and UML.

Similarly, Alistair Cockburn (of Agile Manifesto fame) put forward in his 2001 book Agile Software Development that face to face is the most effective form of communication – particularly when enhanced with whiteboards, flip charts, paper or index cards. See Scott Ambler’s article on Communication on Software Projects which uses data from Alistair’s book.

Ok you might argue, but the world has moved on, smart phones, tablets, cloud computing are not only part of our everyday life but essential to it. We now have a huge range of modelling and requirements management tools at our disposal.

So why have recent business analysis articles trumpeted the benefits of such leading edge business analysis tools as Etch a Sketch and drawing paper? And we all know that agile was really invented by 3M as a means of boosting post-it note sales!

In the words of Brian Cooney, author of Separating Analysis from Design, would Shakespeare have been a better writer if he had a word processor? If you think so, grab your favourite word processor and write a sonnet which people will be delighted to quote 400 years from now.

What’s clear from all this is that the best business analyst tool in the world is the one you’re born with – your brain. Mastering it and applying its enormous capabilities to your business analysis problems is a far better ROI than learning the latest software toolset.

Download our free Requirements Specification Template.

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

Business Analysis Basics

Most Popular BA Techniques

Stakeholder Communications – Pictures not Words

The post Is Business Analysis Low Tech? 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.