Tag: Methodologies


The 6 Most Important Requirements Practices

Authors sometimes make things longer and more complicated than necessary. Some readers might feel that I’ve been guilty of this myself. The third edition of my book Software Requirements, co-authored with Joy Beatty, is about 245,000 words long, nearly 640 pages in a rather small font. Maybe that seems like overkill, but to be fair, the requirements domain is large and complex.

Books like Software Requirements, Mastering the Requirements Process by Suzanne and James Robertson, and the IIBA’s Business Analysis Body of Knowledge describe dozens of valuable techniques for requirements elicitation, analysis, specification, validation, and management. They’re all useful when thoughtfully applied in appropriate situations. But if you don’t have time to wade through these large volumes, you might like this TL;DR version of the six most important requirements practices that every project team should perform. This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson.


Practice #1: Define Business Objectives

Organizations undertake a project to solve a problem, exploit a business opportunity, or create a new market. Defining the project’s business objectives communicates to all participants and other stakeholders why they are working on the project. The organization could hope to achieve both financial and non-financial business objectives with the new product. Try to quantify the business objectives, and make them measurable, with statements like these:

  • Capture a market share of X percent within Y months.
  • Reach a sales volume of X units or revenue of $Y within Z months.
  • Save X dollars per year currently spent on a high-maintenance legacy system.

Using business objectives aligns all of the team’s work and key decisions. Without defined business objectives, you can’t craft a clear product vision statement or establish the scope of either the entire project or any development increment. The team can’t make good decisions about scope changes or proposed functionality unless they know how those changes match up with the business objectives.

Keeping the scope in focus helps the team avoid scope creep while still adapting to changing business realities. And how can you know if the project was a success unless someone defined its business objectives and success criteria up front?


Practice #2: Understand What Users Need to Do with the Product

I strongly advocate taking a usage-centric approach to requirements development and solution design, rather than a feature- or product-centric approach. Understanding the tasks that users need to perform and the goals they want to achieve lets the business analyst (BA) derive the functionality that developers must implement.

When you focus on exploring features rather than user goals, it’s easy to overlook some necessary functionality. It’s also easy to include functionality that seems cool but doesn’t help users get their jobs done. Use cases are an effective technique for maintaining this usage-centric mindset.

Seeking to understand what users need to do with the product implies several other important BA activities, including these:

  • Identifying a wide range of project stakeholders
  • Characterizing distinct user classes that have largely different requirements
  • Identifying individuals to serve as the voice of the customer for each user class (product champions)
  • Selecting appropriate requirements elicitation techniques to engage with users
  • Establishing decision-making processes to resolve conflicts and priorities across user classes
  • Building and evaluating prototypes or early releases to stimulate user feedback




Practice #3: Prioritize the Requirements

I doubt that any project has ever implemented every bit of requested functionality. Even if you could implement it all, you can’t do it all at once. Your goal is to deliver the maximum business value to your customers at the lowest cost and in the shortest time. Achieving this goal demands that you prioritize requirements so the team can work on them in the most appropriate sequence.

Prioritization involves considering how much each proposed requirement contributes to achieving the project’s business objectives. Prioritizing requirements lets the team decide which of the work items remaining in the backlog to defer or omit because of time and resource constraints. There are numerous requirements prioritization techniques available, including these:

  • In or out
  • Pairwise comparison and rank ordering
  • Three-level scale
  • MoSCoW
  • Relative weighting
  • $100 test

Some of these methods take more effort than others, but those methods also help the project manager or product owner make finer-grained choices. Choose any technique that lets the right stakeholders make good business decisions throughout the project to avoid a frantic “rapid descoping phase” late in the game.


Practice #4: Explore Nonfunctional Requirements

People naturally focus on a product’s functionality when discussing requirements, but those are only part of the solution. Nonfunctional requirements contribute heavily to user satisfaction and suitability for use. When speaking of “nonfunctional requirements,” people most commonly think of quality attributes, sometimes called the “-ilities.” These product characteristics include usability, maintainability, security, reliability, and many others. To help designers devise the most appropriate solution, BAs need to discuss nonfunctional requirements as part of requirements elicitation.

Developers generally don’t directly implement requirements that describe safety, reliability, portability, security, or other characteristics. Instead, these attributes serve as the origin of many functional requirements and drive design decisions. Table 1 indicates the likely categories of technical information that different types of quality attributes will generate.


Table 1. Translating quality attributes into technical specifications (from Software Requirements, 3rd Edition)

Another challenge is that it’s not possible to optimize all of the desired quality factors at once. Designers must make trade-off decisions among the various attributes. Therefore, the team needs to determine which ones are most important to customer success and optimize those. Carefully specifying quality attributes lets you build a product that delights its users, beyond merely doing what it’s supposed to.


Practice #5: Review the Requirements

How do you know if your requirements are accurate? How can you tell if they’re clear enough so all the team members know what to do with them and other stakeholders know what to expect in the solution? No matter how you choose to represent requirements knowledge, it is sometimes ambiguous, incomplete, or simply incorrect.

One of the most powerful quality practices available is peer review of requirements. Convene some colleagues to review both textual requirements and diagrams. Different project participants—BAs, designers, developers, testers, users—will find different kinds of problems during these reviews. Requirements reviews pose some particular challenges. Rather than simply inviting people to look over the requirements, provide some training so reviewers know how to participate effectively and can find as many issues as possible.

A related requirements validation practice is to write conceptual tests based on requirements. Testing requirements is something you can do early in each development cycle to reveal many errors before they are cast into code. Requirements and tests are complementary views of the same knowledge. Requirements describe how the product should behave under certain conditions; tests describe how to tell if it’s exhibiting the correct behaviors.


Practice #6: Plan for Requirements Change

No matter how well you understand the problem and how carefully you prepare the requirements, they won’t be perfect, complete, or static. The world changes around us as we work. New users and new ideas appear. Business rules surface and evolve. Projects inevitably grow beyond their originally envisioned scope. Every team must anticipate requirements changes and establish mechanisms for dealing with them without derailing the team’s commitments.

When you know the project outcome is incompletely defined and likely to change a lot, an incremental, agile approach is a good way to cope with it. You plan to build the requirements—and the solution—in a series of small chunks, expecting the direction to change and accepting the uncertainty of what you’ll have at the end and when you’ll have it.


When the likely degree of change is less extreme, plan to accommodate some growth (along with risks, imprecise estimates, and unexpected events) by building contingency buffers into development schedules. Establish a requirements change process so the right people can get the right information to make good business decisions about which proposed changes to incorporate to add value with minimal disruption.

Don’t use the expectation of change as a justification for skimping on requirements thinking, though. Excessive requirements churn often indicates that objectives were unclear or the elicitation approach wasn’t effective.


Neglect These Practices at Your Peril

Of course, there are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.


Business Analysis Amalgamation with Product Management

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

 Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

  • Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

  • Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.




  • More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

  • Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

  • Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.


Prioritizing Requirements: An Analogy

I work with “business sponsors” in my company.  Some of them are old hands at going through the process of requesting a new application, or a rewrite, or enhancing an existing application.  Others, though, may never have been involved in requesting software, whether it’s a custom-built application, or something offered by a third party vendor.  In any case, it can be daunting to make decisions about what to ask for, especially when they have to submit a request to get the money to proceed.

Most people I know enjoy engaging in “blue sky” conversations – if you had all the resources in the world at your fingertips, what would you like this new application to do, to support what you and your clients need?  And to be honest, I enjoy those conversations as well.  It’s fun, and liberating, to just let your imagination take flight and ask for the world!  At the end of those blue sky sessions though, it’s time to bring ourselves back to reality, look at the lineup of desired requirements, and put a priority on each of them.  And one of the prioritization methods I’ve had the most success with is the MoSCoW method.


MoSCoW Prioritization Categories:

M = Must Have.  Non-negotiable needs that are mandatory for the business.

S = Should Have.   Important features that are not critical but have much value.

C = Could Have.  Nice to have features that will not impact the usability of the application in a detrimental way if they are not included.

W – Will Not Have/Wish.  Features that should be placed in the product backlog for future consideration.


I often use analogies to drive home various concepts to my stakeholders, especially if it is something they aren’t familiar with.  Analogies help them grasp these concepts more quickly, rather than using a lot of “wordy” explanations.  I use this analogy about prioritization when appropriate.


How to Research buying a Refrigerator

Recently my husband and I purchased a new refrigerator.  Our old one was on its last legs, and we wanted to purchase a new one before the old one gave out at a most inconvenient time, as we had experienced several times in the past!  (If you’ve ever had a fridge give out on you when you had a great load of food in it, you know the stress I’m talking about!)

Since it had been quite a few years since our last purchase, we started looking around and were astonished at all of the new configurations and features that were available in new fridges.  The price tags too, had changed – wow, were they expensive!!  So, I said to my husband, “Why don’t we write down all of the features we think we would like in a new fridge, and then go shopping with that list?”




So we sat down at the kitchen table with our son, who lives at home (gathered all the stakeholders), and I started the list of “requirements” for our new fridge.  Did we want an ice/water dispenser, which our old fridge had?  What about extra room for vegetables, now that we had committed to eating more healthy?  How many cubic feet of space did we want?  How about a deli drawer?  Or a computer on the outside of the fridge?


Feature Prioritization
Ice maker/dispenser M
Maximum room to store vegetables M
Minimum cubic feet 26 cu ft M
French door style S
Deli drawer C
Energy efficiency M
Computer built in the front of the fridge W


Once we had our list written down, we used the MoSCoW technique of prioritization, and each requirement was given a must-have, should-have, could-have and won’t have/wish.  We also had to figure out what our budget was–not many people have infinite resources, and we are certainly not in that league, financially!

So, armed with our requirements and our budget number, we started shopping.  On-line, and in person, we spent many hours researching the available options.  Some of those could-haves and wishes dropped off the list pretty quickly, because although we had what we felt was a moderate budget, it certainly weeded out the more extravagant models.

We were able to find a refrigerator that had all of our M, S, and most of our C items in our list that was within our budget.  And because of all this work we did in advance, we actually felt good about our purchase—we were very satisfied we’d made the best choice for us.  That didn’t mean we got everything we wanted, but we didn’t feel disappointed.  We’re still loving this fridge three years later.



And that’s exactly the feeling I want my business sponsors and stakeholders to feel – very satisfied that they’ve made the best decisions for the application/enhancement or whatever the initiative is.  Do your research, prioritize your requirements and move forward with confidence.



3 Effective Techniques for Root Cause Analysis

Root Cause Analysis is a method of identifying the underlying cause of a problem or fault. It is a systematic process that involves gathering information, analyzing data and identifying the root cause of the problem. The goal of Root Cause Analysis is to solve the problem and prevent it from happening again in the future.

The process of Root Cause Analysis begins with identifying and defining the problem. This includes gathering information such as symptoms, causes and effects of the problem. This information is then analyzed to determine the root cause of the problem. The analysis may involve using tools such as cause and effect diagrams, flowcharts, and statistical analysis.

In the past I have performed Root Cause Analysis in a number of occasions, and I found the following 3 techniques both effective and easy to use.


Technique 1: “5-Whys” Analysis

The “5-Whys” Analysis is a simple yet effective problem-solving technique that helps users quickly identify the root cause of a problem. This technique was made popular in the 1970s by the Toyota Production System, which aimed to improve the efficiency and effectiveness of their production processes.

The strategy behind the “5-Whys” Analysis is to keep asking “why” and “what caused this problem” until the root cause of the problem is identified. By asking “why” repeatedly, you are able to dig deeper into the problem and uncover underlying issues. This is the basis for the “5-why” analysis.


The “5-Whys” Analysis is a straightforward process that can be used by individuals or teams. First, clearly define the problem and then ask “why” it is happening. The answer to this question will then lead to a second “why” and so on, until the root cause is identified. It is important to note that it is not always necessary to go through all five “whys” and it can take less or more “why” to get to the root cause depending on the complexity of the problem.

This technique can be applied to a wide range of problems, from simple to complex. It is a valuable tool for organizations to improve the efficiency and effectiveness of their processes, as well as to reduce costs and improve customer satisfaction. It also helps teams to work together to find a solution by encouraging open communication and collaboration.



The “5-Whys” technique is a simple and effective method for identifying the root cause of a problem. However, it is important to avoid asking “why” repeatedly in a literal and consecutive manner, as this can make stakeholders feel interrogated and uncomfortable. Instead, consider using alternative expressions of “why” and adopt a gentle and non-confrontational approach in your communication and body language to create a relaxed atmosphere.


Technique 2: Fishbone Diagrams

The Fish-Bone Diagram, also known as an Ishikawa Diagram, is a tool used to identify the potential causes of a specific problem or effect. It is a graphical representation of the relationship between a problem and its potential causes and is often referred to as a cause-and-effect diagram. The design of the Fish-Bone Diagram is shaped much like the skeleton of a fish, which is how it gets its name.

Derived from the quality management process, it’s an analysis tool that provides a systematic way of looking at the effects and the causes that create or contribute to those effects. It allows teams to identify the key factors that may be affecting the quality of a product or service and to focus on those areas that need improvement. To use the Fish-Bone Diagram, first, clearly define the problem and then brainstorm the potential causes in the various categories.

The Fish-Bone Diagram is a simple yet powerful tool that can be used in a wide range of industries and fields, including manufacturing, healthcare, service, and education. One of the Fish-Bone model that is commonly used in manufacturing is the 5 M’s. The 5 M’s are Manpower, Machine, Material, Method, and Measurement. Manpower refers to the people, Machine includes equipment and technology, Material includes raw material, consumables and information, Method refers to the process and Measurement includes inspection and environment.





The Fish-Bone Diagram is a visual tool that illustrates the relationship between a problem and its potential causes. To effectively use this technique, it is recommended to have a physical whiteboard or butchers paper to draw the diagram on. However, it may not be the most suitable option when working remotely as you cannot draw it as quickly with your mouse as with a marker.


Technique 3: Brainstorming

Brainstorming is a powerful tool for identifying root causes of problems. The brainstorming process involves bringing together a group of people with relevant knowledge and experience to generate a wide range of ideas and potential solutions. The goal is to remove inhibitions and encourage the free flow of ideas. The brainstorming session is typically led by a facilitator who guides the group through the process and ensures that everyone has the opportunity to contribute their ideas.

During the brainstorming session, all ideas are recorded and no idea is criticized or dismissed. This allows for a diverse range of ideas to be generated and evaluated. The facilitator may also use techniques such as mind-mapping, word association, or random word generation to stimulate the brainstorming process. After the brainstorming session, the ideas are evaluated and analyzed to identify the most likely root causes of the problem.

Brainstorming can be an effective way to generate ideas and solutions quickly and efficiently in a group setting. It allows for the collective knowledge and experience of the group to be leveraged and it helps to identify potential root causes that may not have been considered by individuals working alone. It also encourages participation from all members of the group and fosters a sense of teamwork and collaboration.



Brainstorming sessions can be time-consuming, especially if many ideas are generated, and it takes time to evaluate and analyze all of them. Also, strong personalities or highly dominant individuals can dominate the brainstorming session and prevent quieter or less confident individuals from contributing their ideas. An experienced facilitator is a must-have to the success of a brainstorming session.



Once the root cause of the problem is identified, a solution can be developed. It is important to not only solve the immediate problem, but also to address the underlying cause to prevent it from happening again in the future. Implementing a long-term solution is critical in order to improve the overall performance and reliability of the system.


Root Cause Analysis is an important technique for business analysts to perform their job duties because it helps to identify the underlying causes of problems or issues within an organization. By identifying the root cause of a problem, business analysts add real value to the organization by addressing the problem at its source, rather than simply addressing symptoms. This can lead to more sustainable and long-term improvements in the organization. Overall, Root Cause Analysis is a crucial tool for business analysts to use, when permanent solutions rather than temporary fixes are required.



  1. International Association for Six Sigma Certification, “Root Cause Analysis”, https://www.iassc.org/root-cause-analysis/
  2. Toyota Global, “5 Whys”, https://www.toyota-global.com/company/toyota_traditions/quality_management/5s/5_whys.html
  3. ASQ, “Ishikawa Diagram”, https://asq.org/quality-resources/ishikawa-diagram
  4. Mind Tools, “Brainstorming”, https://www.mindtools.com/pages/article/newIDE_86.htm
  5. National Safety Council, “Root Cause Analysis: A Guide for Effective Incident Investigation”, https://www.nsc.org/work-safety/safety-management/incident-investigation/root-cause-analysis

Deep Listening: Avoid Hearing What You Want To Hear

Elicitation is a key business analysis skill. Whether it’s one-on-one interviews, workshops, observation or one of the many other techniques, elicitation is a key source of information. As BAs, it’s easy to think that we are highly attuned listeners, carefully scouring the airwaves for tasty morsels of relevant information. Of course, this is probably true. However, have you ever reflected on how deeply you pay attention and listen? For example, have you ever:

  • Quickly checked your email in a meeting (where something critical could be mentioned, but you weren’t expecting it)
  • Been tired at the end of the day so tried to rush a conversation
  • Skim-read an email and missed a key detail
  • Missed a key piece of information in a document
  • By the time you interview the sixth person, you think you already know the answer so ‘tune out’ for part of the interview

If you haven’t, then you probably deserve a medal. I’m sure most of us have indulged in some—or all—of these behaviors at some point in our careers. While there might be good reasons to do so in some cases, doing so will affect the ability to listen deeply. Notably, by ‘listening’ here, I’m also referring to ‘reading’ of information, as I suspect we all spend a lot of time ‘listening’ to our colleagues through their emails and comments on documents etc.


Miscommunication Is Rife

It’s easy to miss the point when listening or reading.  As an example, I was wandering around a large supermarket here in the UK, and I picked up a bottle of own-brand hand wash. I was looking on the back of it, and noticed the following statement in bold:


[Supermarket name] is against animal testing and funds alternatives

It struck me that this is a deliberate piece of misdirection. If you were scanning it quickly to look for information about whether the product is tested on animals, you might see that statement and think “oh, they’re against animal testing, so it’s fine”. This is similar to a case where a listener hears what they expect to hear, or what they want to hear! However, the statement taken at face value doesn’t confirm (or refute) whether the product was (or wasn’t) tested on animals. It just says the supermarket is against animal testing and funds alternatives.  Yet many readers’ might inadvertently apply their own meaning to it.




Granted, you’re unlikely to be reading a statement on the back of a hand wash bottle at work, and it’s unlikely that folks will be deliberately trying to deceive. But it’s very easy to miss tiny nuances in verbal or written communication.  Take these statements:

  • “I broadly agree with what is proposed” (what does broadly mean? Are there areas of disagreement? If so, what are they?)
  • “I agree with points 1 and 3”. (OK. Do you disagree with point 2?)
  • “This is a real pain point for us.” (What does ‘pain point’ mean? Does our definition of ‘pain point’ agree with theirs?)

These are just three specific examples, but I’m sure you get the point.


Curiosity Is A Prerequisite To Listening Deeply

Deep listening is hard, and a skill that one could probably work on for their entire life. I have heard it said multiple times that people tend to listen to respond; by the end of the speaker’s sentence the listener is tuned out thinking how to respond. As a BA, this might translate into thinking about the next question.

It is almost as if we are scared of silence. Like silence will be interpreted as some awful slight on our stakeholders. Yet in reality a (relatively short) amount of silence can be useful. In my experience, people will often pause, reflect, and add more insight when given a bit of breathing space. Of course, what is considered an appropriate length of silence varies, and certainly it shouldn’t be excessive!

A common thread throughout this is curiosity. If we are genuinely curious about the stakeholder, the subject-matter, their perspectives and so on then it’s easier to focus in and listen. If we lose curiosity or get distracted by the busy-work of organizational life it’s far too easy to tune out.


Here’s to remaining curious, and to listening deeply!