I asked AI a simple question about requirements and got back a page of prose instead of an answer. That moment made me test a hope a lot of us are quietly holding: that AI can write our requirements for us. Here is what I found, and why the thinking part still has to be yours.

When you are new to business analysis, stakeholder management can feel like an exercise in trying to keep everyone happy. You map them, you categorize them, you build your Power/Interest Matrix, and then you still end up wondering: out of all these people, who do I actually need to focus on right now?

Most business analysts have filled in a SWOT matrix at some point. Strengths in the top left. Weaknesses beside them. Opportunities and threats below. You end up with a tidy grid, a room full of sticky notes, and a slide that summarizes where things stand. And then the meeting ends, the matrix gets filed, and the insights are quietly forgotten.

You have just finished a stakeholder meeting and three department heads all want process improvements, preferably yesterday. Finance is pushing for a procurement redesign. Operations wants the reporting workflow fixed. HR is asking for an onboarding process review. The requests are legitimate, but the organizational bandwidth is limited. Where do you start?

EARS stands for Easy Approach to Requirements Syntax. It was developed by Alistair Mavin and colleagues at Rolls-Royce as a lightweight approach to writing clear, consistent, and testable textual requirements. The approach uses a small set of keywords that signal the structure of each requirement: what kind of situation it applies to, what triggers it, and what the system must do in response.

The techniques in this post draw on concepts from Neuro-Linguistic Programming (NLP), developed by Richard Bandler and John Grinder in the 1970s. While NLP as a discipline is debated, several of its communication techniques, like mirroring, pacing, and sensory awareness, are widely used in coaching, negotiation, and stakeholder engagement.

In our previous post, we explored Mendelow’s Matrix, a fundamental tool for mapping stakeholders along two dimensions: power and interest. By now, you know which stakeholders to manage closely, which to keep informed, which to keep satisfied, and which require minimal effort. That is already a significant step forward in your stakeholder engagement planning.

In the first post in this series, we watched Anna, a business analyst, meet Marcus, a skeptical IT Director, in three different versions of the same corridor conversation: same setup, same 10 minutes, three very different outcomes. In one, she built a strong connection. In another, she lost him entirely. In the third, she stumbled but recovered.

Rapport is one of those business analysis skills everyone agrees is important, yet it is often described so vaguely that it becomes useless. We hear that good analysts should “build trust,” “connect with stakeholders,” or “develop strong relationships.” All true. But what does that actually look like in the moment?

Business analysts often face a common challenge when gathering requirements. Stakeholders tend to focus on solutions instead of their actual needs. As a result, important requirements can stay hidden. At a recent workshop, someone brought up this exact problem. His stakeholders kept talking about solutions instead of the problem they wanted to solve.

There is a well-documented pattern in requirements engineering that most experienced practitioners will recognize the moment they hear it and quietly wince. Research (2014) from the Universidad Politécnica de Madrid found that when an analyst faces an elicitation challenge, they tend to reach for the technique they know best, regardless of whether it is the most appropriate one for the situation.

In this post, I’ll compare the International Institute of Business Analysis (IIBA), British Computer Society (BCS), and International Requirements Engineering Board (IREB) through a career lens: consulting vs. corporate, geographic reach, industry fit, and the professional community you’ll be joining.

Change is no longer something organizations deal with occasionally. It is constant, rapid, and increasingly technology-driven. Over the years, I’ve worked with many organizations that delivered exactly what they planned and still failed to create value. The issue was rarely execution. It was that the problem they solved was not the problem customers actually had.

If I already hold a certification, can I move to another scheme without starting from scratch? The short answer: yes, but with conditions. The longer answer depends on how the International Institute of Business Analysis (IIBA), British Computer Society (BCS), and International Requirements Engineering Board (IREB) certification frameworks overlap and where they don’t.

Most organizations invest heavily in employee development, but much of that investment is lost when newly acquired skills quickly fade. Why does this happen? What can companies do to ensure their training actually sticks? As the corporate training landscape evolves with new technologies and learning methods, one thing remains clear: without effective reinforcement, even the best training programs are unlikely to deliver lasting results.

AI is rapidly becoming part of everyday business analysis, whether we planned for it or not. Many professionals use Large Language Models (LLMs) like ChatGPT, Claude, Perplexity, Gemini, or Copilot as if they were advanced search engines: we ask a question and expect a clear, reliable answer. Sometimes that works—other times the output feels shallow, inconsistent, or simply wrong.

When I work with organizations on change initiatives, one pattern repeats itself. Teams often jump straight into solution mode. They rush into selecting tools, writing user stories, or planning training, without first understanding what is changing and why. Over time, I learned that the best results come from following a clear, structured approach: the Business Change Lifecycle.

In today’s VUCA (Volatile, Uncertain, Complex, Ambiguous) world, business analysts play an important role as sense-makers. Rather than providing straightforward answers, analysts are increasingly called upon to interpret ambiguity, surface patterns, and guide organizations through uncertain situations.

Every business analyst has seen it happen: a new system is launched to streamline processes, yet productivity drops, morale falls, and support calls skyrocket.  The problem isn’t the technology. It’s the thinking.
Too often, organizations approach change as a linear upgrade, assuming that fixing one component will automatically improve performance.

Eliciting requirements sounds simple, until you realise that everyone has a different view of what’s “needed.” Many new business analysts find themselves in meetings full of opinions, conflicting priorities, and vague statements like “We just need it to be faster.”

Two perspectives “functional” and “process”. Each represents a different perspective of how value is created and how work is managed. Harmon argues that while both are legitimate and necessary, modern performance improvement depends on an organization’s ability to move beyond purely functional thinking and adopt a process-oriented perspective.

In our continuing series on stakeholder management, we’ve explored why identifying stakeholders is crucial and examined techniques like nomination, checklists, and the onion model. Now that we have identified our stakeholders, the next step is to analyze them using Mendelow’s Matrix, a fundamental tool for stakeholder mapping.

Thorough stakeholder identification is essential for project success, and the Onion Model is the third technique in our post series that provides a unique, visual way to ensure no critical stakeholders are overlooked. Ian Alexander, together with Suzanne and James Robertson, popularized this technique in their books in the early 2000s.

Exhaustive requirements elicitation is critical for successful project outcomes, and it starts with thorough stakeholder identification. A stakeholder checklist is one of the simplest and most effective ways to ensure comprehensive stakeholder identification. This technique offers a structured and quick way to ensure no essential group is overlooked.

The stakeholder nomination technique is not a new concept; it has been used for decades as a practical way to identify relevant stakeholders in projects and decision-making processes. Its origins are rooted in basic principles of stakeholder theory and collaborative identification methods that have been widely recognized in management and organizational literature.

The role of stakeholders in business analysis is vital and can be compared to a compass guiding an explorer. Just as a compass ensures alignment with the destination, stakeholders provide direction, purpose, and clarity for projects.

This final article in our series on Agile Business Analysis principles explores the principle Avoid Waste. Over the course of this series, we’ve examined principles that help business analysts (BAs) align Agile mindset and practices with delivering value, fostering collaboration, and driving continuous improvement.

This article is part of our ongoing series exploring Agile Business Analysis principles as defined in the IIBA Agile Extension. In this post, we delve into the principle of Stimulate Collaboration and Continuous Improvement, which emphasizes fostering teamwork and a culture of learning to drive better outcomes in Agile initiatives.

This article is part of our ongoing series on Agile Business Analysis principles. In this post, we’ll explore the fifth principle, Understand What is Doable, which emphasizes the importance of setting realistic goals within Agile initiatives by balancing ambition with constraints and team capabilitites.

In this post, we explore the fourth Agile Business Analysis principle, “Get Real Using Examples.” from the Agile Extension to the BABOK Guide. Building on the previous principles, this principle emphasizes the power of real-world examples to foster a shared understanding of needs and solutions.

According to the IIBA Agile Extension to the BABOK Guide, the third Agile Business Analysis principle, “Analyze to Determine What is Valuable,” emphasizes the continuous process of identifying, assessing, and prioritizing what delivers the most value to both customers and the organization.

This is an article I wrote for the EXIN blog, where I try to explain the importance of strong business […]

In the world of Agile Business Analysis, this principle emphasizes the importance of a customer-centric approach. Rather than focusing solely on the needs of a business, this principle encourages business analysts (BAs) to incorporate the voice of the customer and adopt their perspective ensuring that every feature developed meets customer expectations and adds value.

In Agile Business Analysis, the “See the Whole” principle encourages professionals to analyze the business change in the context of the bigger picture, focusing on the business environment and why the change is necessary. This principle encourages business analysts to take a holistic view. Understanding the context, solution, and stakeholders is crucial to value delivery.

Categorization of requirements means that you group them into meaningful clusters. The question is, why should you consider doing this?

The International Institute of Business Analysis™ announced changes to the Entry Certificate in Business Analysis™ exam.

Writing requirements is not an easy task. It requires discipline and preparation, especially if you define requirements in a natural language. Many professionals dislike this activity and perceive it as dull and tedious. Ivy Hooks discussed this phenomenon and listed improvements that an organization can pursue to change this situation. 

The last knowledge area in the BABOK® framework is called Solution Evaluation. Its main focus is on assessing the (completely or partially) delivered solution’s value and performance. If there are any obstacles or unnecessary constraints, a Business Analyst should identify them and try to remove them to increase the solution value.

The Requirements Analysis and Design Definition knowledge area focuses on processing business analysis information obtained from the Elicitation and Collaboration knowledge area. Business Analysts can perform these information processing tasks as a one-time activity or incrementally and iteratively depending on the selected business analysis approach.

To produce solutions that bring value to an organization requires that the agile team have a basic understanding of the business architecture. Agile teams, through their deliverables, impact business architecture elements such as business capabilities and business value streams. Let us take a look at what these elements are, and why an agile team should care about them.

The Strategy Analysis knowledge area of BABOK focuses on understanding why a change is needed and defining activities that an organization has to undertake to implement it successfully. Because of this focus, the outputs of Strategy Analysis provide context for all other activities in the framework.

The knowledge area Requirements Life Cycle Management ensures that requirements and designs created by Business Analysts during their work are managed and maintained. The requirements and designs are also traced, prioritized, and approved.

The Elicitation and Collaboration knowledge area (KA) contains tasks that help Business Analysts to obtain information from the stakeholders. Business Analysts must confirm and communicate the obtained information back to the stakeholders.

The knowledge area Business Analysis Planning and Monitoring of the business analysis framework focuses on preparing and monitoring the execution of business analysis work. All outputs that are produced within this knowledge area are used by other knowledge areas.

To fully understand the BABOK V3 business analysis framework, we have to go back to the previous version of the BABOK® Guide – version 2. At that time, IIBA® used a slightly different definition of business analysis:

This post is dedicated to the basic concepts of the business analysis profession. These concepts work as a compass helping business analysts speak the same language as their stakeholders.

Welcome to the first post from a series called “Introduction to BABOK®”. This series aims to introduce you to the business analysis framework defined in the Business Analysis Body of Knowledge (BABOK® for short) and the organization behind it: the International Institute of Business Analysis.

The International Institute of Business Analysis™ offers the Certificate of Capability in Business Analysis™. CCBA® certificate is the certificate for business analysis professionals with 2-3 years of experience, trainers and professionals from other domains, e.g. project management or quality management. Is this certificate for you?

Behavior Driven Development recommends to define the expected system behavior in a domain-specific language called Gherkin. Teams together with stakeholders collect examples of required system behavior, group them into features and document them as scenarios. The main structure of an example/scenario is:

The International Institute of Business Analysis offers the Entry Certificate in Business Analysis. ECBA certificate is the first certificate on the IIBA certification roadmap for business analysis practitioners. Is this certificate appropriate for you?

This is a visual representation of the business analysis activities performed by Agile teams based on the IIBA Business Analysis Body of Knowledge and IIBA Agile Extension.

This short video presents the most popular certifications for business analysts. If you are looking for a certification for yourself, consider downloading the white paper we present at the end of the video. It may offer you a helping hand in the selection of the proper certification for you.

Agile methodologies have introduced a big shift in how teams approach business analysis activities. In this article I share my thoughts on business analysis when working agile.

This year the Design Thinking Conference in Amsterdam was about empathy, an element of the Design Thinking approach that starts it. Don’t you agree that in order to help somebody, we need to understand him first? We need to understand the person, his challenges and context, before we start providing solutions. Empathy can serve as a helping hand in building understanding and trust.

The common perception is that innovation is the same thing as research.  Certainly, inventions resulting from research are an important input for a business to develop commercially relevant products and services. But is it the only way?

Lean thinking can be applied to a business analysis process as well. It may be needed too. Research from the Standish Group states that 60 percent of features implemented in products is never used. This is waste, isn’t it?

It is important to help organisations deliver value to stakeholders and guide them through this process, isn’t it? History shows that organisations that neglect change suffer heavily. Lack of responsiveness to what is happening around them may threaten the companies’ existence. Remember what happened with giants like Kodak or Blackberry? 

Interview with Maritza Guaderrama, managing director of Designit Spain & Latam: a global strategic design firm. Designit applies design thinking techniques to help its clients develop better product-service experiences and guide them through their business transformation efforts. Part 2.

Interview with Maritza Guaderrama, managing director of Designit Spain & Latam: a global strategic design firm. Designit applies design thinking techniques to help its clients develop better product-service experiences and guide them through their business transformation efforts. Part 1.

Looking at the history of software engineering, it is interesting to see its evolution. It all started with a pretty basic ‘writing programs’ that did perform some (hopefully functional and useful) tasks. Quickly, it appeared that happy nerd-driven programming was insufficient for addressing more serious functional problems.

Change is important for any organization. Without change, organizations would likely lose their competitive advantage over time. We have seen companies that have had a very difficult time after neglecting signals from the fast-paced outside world and not adapting.

The  International Institute of Business Analysis defines in its “Business Analysis Body of Knowledge” (BABOK) that business analysis is “the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders”. To fulfil this task to a good standard business analysts require, among others, well-developed analytical and problem solving skills.

Have you ever worked on a great solution and concluded … you were not working on the right problem? Well, it has happened to all of us and probably many times. However, there may be a way to break this vicious cycle. Consider the mesh of design thinking and business analysis. How do these play together? What is so powerful in this combination?