Skip to main content

Tag: Requirements


Best of BATimes: What Problem Are You Trying To Solve?

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.


Often, business partners come with all sorts of preconceptions, which they present as the actual problem. Sometimes they try to be helpful. It’s the BAs job to ask more questions to determine if that’s the real problem.

For example, I had a business partner who told me that the data in an email we were sending to one of our customers was “encrypted”. It would have been easy to waste hours trying to chase that down. I started down that road, until I caught myself and asked “What’s the problem I’m trying to solve?” I asked the business partner to see a copy of the email. It was then that I realized that what she was referring to as being encrypted was actually just raw XML being presented straight to the page. The problem wasn’t that the email was encrypted, it was that it wasn’t easily readable by a human. One parameter change later, and the problem was fixed.

Donald Gause and Gerald Weinberg wrote a seminal work on discovering the real problem called “Are Your Lights On?” I reread it at least once a year, to remind myself how to ask the questions needed to determine the real problem, because sometimes what appears to be the problem at first glance isn’t the real cause.


A recent real-life example was encountered by the Dutch bike manufacturer Van Moof, who found that over 25% of their bicycles were being damaged en route to the customer, especially when being shipped to the US. The company could have invested money in improving their packaging or looking for a new shipping company. Instead, they spent time identifying what the real problem was: the people doing the shipping weren’t being careful with the product, perhaps because they perceived a bicycle as being sturdy enough to withstand rough handling. Or perhaps they didn’t perceive bicycles as being as valuable, so they didn’t feel the need to take extra care when handling them. What was the solution?

In the end, the bicycle company put a picture of a large screen TV behind the picture of the bike. They didn’t indicate that there was a TV in the box. The shippers, who apparently don’t have time to read carefully, treated the updated boxes like there was an actual big screen TV inside them. As a result, damages in transit dropped by 80%.




1. Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.


2. Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.


3. Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.


In the end, finding the real problem that needs to be solved, can be simple, complicated or somewhere in between. Taking the time to do the right level of investigation is an important part of the BA’s value in the development process.


Published: 2020/06/04

Best of BATimes: Business Analyst vs. Business Analytics Professional: What’s the Difference?

A business analyst and a business analytics professional are not the same. Very often, people get confused about these 2 terms.


Many times, they are used interchangeably. Few start-ups and organizations also seek out a business analyst when they are actually in search of a business analytics professional. Among the analytics enthusiasts who are searching for a job in business analytics, this causes huge confusion. So, it would be better if the difference between a business analyst and a business analytics professional is well-known.


Who is a business analyst?

As defined by IIBA(International Institute of Business Analysis), the business analysis is a discipline of determining the business needs and identifying the solutions to business problems.

A business analyst coordinates between a client and the technical team. A client can be either the internal team that is required to work with the technical team or external, with the requirements to solve a particular problem. The technical team has the ability to either deliver a service or build a product.

The business analyst makes sure that the service or product provided by the technical team meets the client’s present requirements. He/she collaborates with the external and internal stakeholders in the implementation as well as design of the service or product.


Who is a business analytics professional?

A business analyst doesn’t work with data and is mostly concerned about processes and functions. On the contrary, reporting and data are the key components of a business analytics professional’s job.

Let us consider 3 major elements that help us in understanding the difference between a business analyst and a business analytics professional.


Analytical problem solving skills

The business analysts utilize different techniques to analyze the problem and determine the solution. They conduct thorough analysis and deconstruct the solution or problem by making use of various methods. Few examples of this include decision models, business process models and use cases.

On the other hand, business analytics executives use logical thinking, predictive analytics and statistics to solve the business problems.

Let us consider 2 examples that state the way in which the business analytics executives solve the business problems.

  • If a continuous stream of loan applications are being received by a particular bank, the business analytics professional will develop and implement a model to give a recommendation on which loan applications that bank must lend to.
  • From a catalogue launch, if a manufacturer of home-goods wants to predict the expected profits, a framework will be applied by the business analytics executive to work on the problem and develop a predictive model to provide recommendation and results.




The capability to tell story with data

The business analytics professionals must be in a position to share the insights they derive from raw data. They must share the insights in a way that is clearly understandable to the end stake holder as most of the times, the end stakeholder will be a non-technical and/or business-centric person. They shouldn’t use technical jargons while communicating and must present the insights in the simplest possible way. The stakeholder can be an internal or external client. Most of the times, they are business professionals with zero technical background and the authority to take decisions rests with them. The business analytics professionals are very good story tellers and they make use of advanced tools like Ds.js, R and Tableau to share their findings or story to the end stakeholders.

On the other hand, the business analysts are good communicators and they make use of excel, word and PowerPoint to create visual models like wireframe prototypes or work-flow diagrams. They are also good at creating technical documentations. But, they don’t develop custom dashboards making use of modern data visualization tools like business analytics executives do.


Programming skills

A business analytics professional works with structured data and utilizes SQL in order to retrieve data from databases. He/she will write SQL queries to analyze and extract data from the transactions database and develop a set of visualizations if the management requires some advanced metrics about their company.

The analytics professional will also have a good expertise on the data science programming languages like Python, Julia, Hadoop and so on. He/she is good at visualizing, analyzing and manipulating data.

A business analyst, on the other hand, has nothing to do with data. Their focus is more on the functions and processes. The significant business analyst value propositions incorporate the calibration and testing, IT re-engineering, process, model requirements, KPIs(Key Performance Indicators), vital pain points, context and business value maps. A business analyst possesses strong knowledge in development frameworks such as SLDC. He/she makes use of Excel to perform quantitative calculations and analysis. The programming skills are not used by the business analysts to perform calculations.



It is evident from the above that both these functions are extremely important for a successful business model. From the business decisions it automates as well as enables, the value of analytics can be derived. Every time, a business analyst will first begin with the business questions but not with data. They are also the domain experts who manage the project from the beginning till the end.

On the other hand, a business analytics professional begins to solve the business problem making use of data first. He/she cares about the retrieval of data, format of data and source of data. Data is the raw material for a business analytics professional.

A business analytics professional and a business analyst work closely to make sure the final project is delivered successfully. This explains the difference between a business analyst and a business analytics professional.


Posted on: 2017/12/27

The Cost of Missing Stakeholders

Business Case:  Lessons from software implementation which put head office directives before stakeholder needs.



This business lesson was learned at a US non-government organization (NGO) operating refugee camps and support services in East Africa.  A few months prior to my arrival the NGO selected an accounting system to be implemented at all local offices.  Instructions and software were sent out from the US head office, and my predecessor had been gamely trying to implement the new system but falling behind a little each month.  We crossed paths in Nairobi as I was inbound to Mwanza, a dusty town on the shores of Lake Victoria.  He was clearly stressed and anxious to be going home.  What was I heading into?

NGO’s operate on private donor funding and from US government grants.  Money was provided in US dollars and was spent in local shillings.  Financial reports are provided in US dollars to the head office and for donor reporting, and in shillings for local authorities.  Multi-currency accounting was not the cause of their current issue, but added complexity to the implementation.

The software was installed but a backlog of configuration work and data migration had been created and this was consuming the efforts of the finance office.  Production of the donor reports were months behind and the NGO was at risk of losing or disrupting the funding to aid the thousands of refugees in their camps. Payments to local suppliers and workers were also in arrears as time had been consumed by the software change.

The new accounting system was rolled out by the head office to support a strategy for global standardization of accounting and reporting from their international offices.  The implementation strategy could be called “out with the old and in with the new”.   Use of the old system was abruptly ceased while the new software was installed, and production of the monthly donor reports would be resumed from the new system once the install and data migration was complete.   There was no local planning for the initial rollout.

The approach of this paper is to use this business case to illustrate the benefits of applying business analysis tools and techniques to all software projects, regardless of size or location.


Planning– identify stakeholders and business analysis approach. 

Always look for all the stakeholders.   The NGO head office is a stakeholder in the Mwanza project, and they communicated a business need to achieve global accounting standardization.  The funding donors are also stakeholders in the project.  The rollout strategy was based on an assumption that the new accounting system was the number one priority for this local office – but donor funds are the life blood of non-profit organizations and any hint of not being able to account for how the money is being spent can cause delays or withdrawals of support.  The number one business need for this Finance office was the timely and accurate production of donor reports.

Local workers and suppliers are also stakeholders in the accounting system. Timely reimbursement for labor and materials is needed to maintain the supply of both to run the refugee camps.

It is easy to overlook the need for business analysis in small projects, but this case illustrates the risk of implementing software without some basic analysis of scope and flows.  A simple context diagram and stakeholder map would have provided a better perspective for implementation planning.




Requirements – identify all the functional and non-functional requirements.

The requirements given to the local office were:

  1. Install new software
  2. Migrate historical data
  3. Recreate reports


Recognition of additional stakeholders leads to the additional requirements –

  • Maintain accurate and timely reporting to donors.
  • Avoid disruption to the delivery of monthly donor reports
  • Ensure consistency in donor reports
  • Maintain payments to local vendors and workers
  • Avoid delays of vendor and worker payments


Strategy – identify the business need, address that need, and align the change strategy within the enterprise.

The business need which dictated the implementation strategy was to achieve global accounting standardization.  The missing business need was to maintain continuity of operations during the software change.  A new strategy was required that gave equal priority to both needs.

Under the new strategy all work was stopped on the software configuration and data migration until the monthly reports and daily operations were up to date, then these were maintained in parallel during conversion and testing until a clean cutoff was possible.  This was achieved within 3 months and there was no disruption to the NGO’s funding or local operations.


Create a Context Diagram at the start of the business analysis process then share this early and often with your known stakeholders to help identify what might be missing.




Identification of all stakeholders is key to successful requirements. Timely identification of all the stakeholders at the start of the project avoids delays and rework when new requirements are identified while development or delivery is in progress.


Complexity Science Terminology Applied to Business Requirements

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.


We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.


From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.




Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.


Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

  • Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
  • Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
  • Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
  • Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
  • Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
  • Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
  • Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.

User Stories: A Vital Step to Craft Successful Software

Simple and easy-to-understand user stories are the key to designing and developing successful software applications (products). Mastering the art of writing user stories is crucial for product owners and business analysts. Want to explore more about user stories? Here you go!


User Story 101

The foremost step in developing a project is to have a clear view of what needs to be created. Clarity is the most crucial element in software application design and development to end up with the most efficient solution.

User stories are the step-by-step documentation of a process, which describes the actions and results. It is an agile software development tool that mentions the features from the users’ perspective. The well-documented user stories are the foremost step in the agile development process to design and develop a software application that users love to use.

The primary purpose of writing a user story is to define project deliverables and how they will bring value to the user. No matter how complex a product or project can be, user stories are always written in simple terms. It needs to be as simple as possible so that a non-technical person can understand the document. There are some key considerations that make the creation of user stories even easier.


Key elements of a user story

  • Simple, straightforward content
  • Keeps users at the focal point
  • Collaborate with team members to gather details
  • Emphasis value deliverables


Apart from this, Business Analysts should also focus on making the entire teams’ and stakeholders’ participation by adding an INVEST element to the user story.


I – Independent (Self-contained without overlapping actions)

N – Negotiable (Keep the scope for negotiation to design a user-centric product)

V – Valuable (Must deliver values to the end users)

E – Estimable (Estimate, prioritize, and fit into sprints)

S – Small (In the form of small stories to complete in a couple of days)

T – Testable (Confirmation via pre-written acceptance criteria)


These elements are crucial in writing well-documented, to-the-point user stories to initiate the product development process. Once you understand the basics of user stories and how they should approach, it becomes easier to create those accurately.




Now that we have understood what user stories are and their key elements, let’s explore why Business Analysts need to master the skill to write definitive user stories. 


Why a BA needs to master the skill to write user stories

User stories are the foundational documentation that works as a blueprint while working on a project. The simple and easy-to-understand documents help the entire team to adhere to the project requirements and develop user-friendly features and functionality.

Moreover, it offers a contextual overview before the initiation of a project so that the team can understand what they need to work on. Also, they can think creatively and employ their best efforts to craft a user-centric product.


The most important benefits of user stories include.


  • Higher clarity on business values and project deliverables
  • Improved collaboration and visibility across the team
  • Prioritize features and functionality of the product
  • Efficient use of the end-users’ feedback
  • Minimize potential risks like communication gaps, technical flaws


As the user story conveys information about potential users and their actual needs, well-written user stories are essential to developing function-rich software applications. Business Analysts should understand the concept of user stories and focus on crafting user stories that drive value for the businesses via developing user-centric products.


When user stories are created

Generally, user stories are written at all software development stages BEFORE the development is initiated. Especially, while shaping product ideas, prioritizing features, and functionality, and during the development phase.


Who is involved in creating the stories

Business analyst, product owner or project manager, development, and design team, and sometimes stakeholders. Primarily, a business analyst or product owner writes the user stories; however, the entire team’s involvement is essential to create well-versed user stories that contribute to developing a user-centric, feature-rich software application.


How to create user stories

User stories are generalized documentation of why the product (software app) will be created and how it will take action. Here’s a simple way to create user stories that lead to a successful project development process. As mentioned earlier, keep users at the focal point along with what and why.


  • Who is the user story for?
  • What action is required?
  • Why is the action important?


The most commonly used format to create a user story:

As a <user>, I want to <complete this action> so that <I want this function>. Business analysts and the other team members can add other details to make the user stories to-the-point document.



  • As a <user>, I want <to have to sign up feature> so that< I can log into the system>
  • As a <customer>, I want <to receive text notification when the item arrives> so that< I can pick up the item right away>.
  • As a <customer>, I want <to have online payment terminal> so that< I can pay online for purchases>
  • As a <manager>, I want <to generate multiple reports on dashboard> so that< I can monitor team’s progress>


In short, user stories need to be created before product development initiates. The understanding of users and what actions they need to take and why the action is necessary must be reflected in the user story. A well-documented user story will aid in creating a blueprint for project development that will lead to a successful software application. Usually, a product owner is assigned to form user stories; however, a business analyst must know how to create user stories that drive the design and successfully develop a product or software.