Business Analysis Techniques

Business Analysis Techniques


Business analysis techniques are powerful tools used to analyse a business to obtain actionable insights in solving business problems. In this article, we shall discuss business analysis techniques including: MOST Analysis, PESTLE Analysis, SWOT Analysis, MOSCOW Technique, CATWOE Analysis, Cause and Effect Analysis, Non-functional Requirement Analysis,Brainstorming, Business process modelling notation (BPMN), UML (Unified Modeling Language), Flowchart technique, Data flow diagram, Role Activity Diagrams (RAD), Gantt Charts, IDEF (Integrated Definition for Function Modeling), Gap Analysis, User Stories – INVEST Technique, Business process modelling (BPM), Six Thinking Hats technique,5 Whys Analysis


Business Analysis Techniques-MOST Analysis

Business analysis techniques-Most analysis

The term MOST stands for its four elements:

  • M-Mission
  • O-Objective
  • S-Strategy
  • T-Tactics

MOST analysis is a powerful business analysis framework and among the best business analysis techniques using which the business analysts analyze what an organization does and plans to achieve the goal and what it should do to maintain strategic alignment. Hence, MOST analysis is a clear way to understand an organization on its ability and purpose.

Now, let’s explain each of the factors with their purposes.

Mission: This is the most critical factor for an organization which defines its purpose and the goals it wants to achieve in the future. If the mission is specific, then it is easier to analyze and measure the remaining factors.

Objectives: We can consider objectives as a collection of goals which as an accumulated result in the mission of the organization. Moreover, Objectives must be S.M.A.R.T –

  • S- Specific
  • M-Measurable
  • A-Achievable
  • R-Realistic
  • T-Timely

Strategy: This is the steps or actions that an organization takes to achieve the objectives and finally to accomplish the mission. A strategy is a group of tactics.

Tactics: These are the discrete and straightforward methods which an organization follows to carry out the strategies.


MOST analysis is a structured business analysis technique followed by every working level in an organization from the top to down. The process ensures that an organization retains focus on the mission which is the critical factor for the success of an organization.

Business Analysis Techniques-PESTLE Analysis

There are always environmental factors which influence business in its strategic planning. These key factors are commonly known as PESTLE which stands for –

  • P- Political
  • E – Economic
  • S – Social
  • T – Technological
  • L- Legal
  • E – Environmental

Each of the factors mentioned above has influences in making a business decision final. Hence, analyzing such key drivers is an important task of a business analyst.



In the above picture, we have highlighted some of the key factors which drive the PESTLE parameters. Hence, the task of a business analyst is to apply PESTLE analysis technique to understand and identify the factors within the environment of the organization operates and analyze how those PESTLE factors will influence the future performance of the organization.


PESTLE is a simple and easy framework for business analysis which involves cross-functional skills of a business analyst along with his expertise. With an effective PESTLE analysis, we can reduce the potential threats of an organization. Moreover, it opens up the scopes to exploit the opportunities for entering into new markets globally.

Business Analysis Techniques-SWOT Analysis

The term SWOT stands for its four elements–

  • S- Strength
  • W- Weakness
  • O- Opportunities
  • T- Threats

It is a thorough analysis conducted by a business analysis considering

  • The internal factors as Strength and Weakness
  • The external factors as Threats and Opportunities

SWOT analysis is a four-quadrant analysis for a business analyst where he places the data as the answers for each quadrant. A business analyst answers the questions under each of the quadrants.


SWOT analysis is one of the most popular business analysis techniques followed in the industry. Furthermore, it is easy. It is an enterprise level analysis technique and not only limited to business analysis. It could be used at any stage of the project if the unit needs it and most of the people know it. Hence, it is widely used in the industry.

Business Analysis Techniques-Moscow Technique

Moscow prioritization, also known as the Moscow method or Moscow analysis, is a popular prioritization technique for managing requirements. The method is commonly used to help key stakeholders understand the significance of initiatives in a specific release.

The acronym, Moscow, stands for 4 different categories of initiatives: must-haves, should-haves, could-haves, and will not have at this time. Sometimes, the “W” in Moscow is used to stand for “wish” instead of “will not have right now.”

How Does MoSCoW Prioritization Work?

Before running a MoSCoW analysis, a few things need to happen. First, key stakeholders and the product team need to get aligned on objectives and prioritization factors. Then, all participants must agree on which initiatives to prioritize.

At this point, your team should also discuss how they will settle any disagreements in prioritization. If you can establish how to settle disputes before they come up, you can help prevent those disagreements from holding up progress.

Finally, you’ll also want to reach a consensus on what percentage of resources you’d like to allocate to each category.

With the groundwork complete, you may begin determining which category is most appropriate for each initiative. Let’s break down each category in the MoSCoW method further.


Moscow Prioritization Categories

Must-have initiatives

As the name suggests, this category consists of initiatives that are “musts” for your team. They represent non-negotiable needs for the project, product, or release in question. For example, if you’re releasing a healthcare application, a must-have initiative may be security functionalities that help maintain compliance.

Anything in the “must-have” category is considered mandatory for the team to complete. If you’re unsure about whether something belongs in this category, ask yourself the following.

  • What happens if we release without this?
  • Is there a workaround or more simple way to accomplish this?
  • Will the release/project/product work without this initiative?

If the product won’t work without an initiative, or the release becomes useless without it, the initiative is most likely a “must-have.”

Should-have initiatives

Should-have initiatives are just a step below must-haves. They are important to the product, project, or release, but they are not vital. If left out, the product or project still functions. However, if they are included, they add significant value.

“Should-have” initiatives are different from “must-have” initiatives in that they can be slated for a future release without impacting the current one. For example performance improvements, minor bug fixes, or new functionality, may be “should-have” initiatives. Without them, the product still works.

Could-have initiatives

Another way of describing “could-have” initiatives is nice-to-haves. “Could-have” initiatives are not necessary to the core function of the product. Compared with “should-have” initiatives, they have much smaller impact on the outcome if they are left out.

So, initiatives that are placed in the “could-have” category are often the first to be deprioritized if a project in the “should-have” or “must-have” category ends up larger than expected.

Will not have (this time)

One benefit of the MoSCoW method is that it places several initiatives in the “will-not-have” category. This helps manage expectations about what will not be included in a specific release (or other time frame you’re prioritizing for).

Placing initiatives in the “will-not-have” category is one way to help prevent scope creep. If initiatives are in this category, the team knows they are not to be a priority for this specific time frame. Some initiatives in the “will-not-have” group will get prioritized in the future, while others are not likely to happen at all. Some teams decide to differentiate between those by creating a subcategory within this group.

When Do You Use the MoSCoW Method for Prioritization?

MoSCoW prioritization is an effective prioritization method for teams who would like to include representatives from the whole organization in their process. Capture a broader perspective by including participants from various functional departments.

Another reason you may want to use MoSCoW prioritization is it allows your team to determine how much effort goes into each category. Therefore, you can ensure that you’re delivering a good variety of initiatives each release.

While in its initial iteration, the MoSCoW method was intended for time-boxed projects only, it can be modified and made effective beyond the scope of simple release planning.

Business Analysis Techniques-CATWOE

CATWOE is a generic thinking way for business analysis to understand what a business is trying to achieve. It identifies what the problem areas are and how the solution will impact the business and its associated people.

CATWOE is an acronym for

  • Clients
  • Actors
  • Transformation
  • Weltanschauung or World View
  • Owner
  • Environmental Constraints




The CATWOE analysis brings up the different stakeholders’ perceptions on a common platform. Hence, it provides a holistic understanding regarding assumption, the integrity of the data, ethical angle. It helps a business analyst to prioritize different perspectives depending on its merits.


Business Analysis Techniques-5 Whys Technique

Sakichi Toyoda, the Japanese industrialist, inventor, and founder of Toyota Industries, developed the 5 Whys technique in the 1930s. It became popular in the 1970s, and Toyota still uses it to solve problems today.

Toyota has a “go and see” philosophy. This means that its decision making is based on an in-depth understanding of what’s actually happening on the shop floor, rather than on what someone in a boardroom thinks might be happening.

The 5 Whys technique is true to this tradition, and it is most effective when the answers come from people who have hands-on experience of the process or problem in question.

The method is remarkably simple: when a problem occurs, you drill down to its root cause by asking “Why?” five times. Then, when a counter-measure becomes apparent, you follow it through to prevent the issue from recurring.


The 5 Whys uses “counter-measures,” rather than “solutions.” A counter-measure is an action or set of actions that seeks to prevent the problem from arising again, while a solution may just seek to deal with the symptom. As such, counter-measures are more robust, and will more likely prevent the problem from recurring.

When to Use a 5 Whys Analysis

You can use 5 Whys for troubleshooting, quality improvement, and problem solving, but it is most effective when used to resolve simple or moderately difficult problems.

It may not be suitable if you need to tackle a complex or critical problem. This is because 5 Whys can lead you to pursue a single track, or a limited number of tracks, of inquiry when, in fact, there could be multiple causes. In cases like these, a wider-ranging method such as Cause and Effect Analysis or Failure Mode and Effects Analysis may be more effective.

This simple technique, however, can often direct you quickly to the root cause of a problem. So, whenever a system or process isn’t working properly, give it a try before you embark on a more in-depth approach – and certainly before you attempt to develop a solution.

The tool’s simplicity gives it great flexibility, too, and 5 Whys combines well with other methods and techniques, such as Root Cause Analysis. It is often associated with Lean Manufacturing, where it is used to identify and eliminate wasteful practices. It is also used in the analysis phase of the Six Sigma quality improvement methodology.

How to Use the 5 Whys

The model follows a very simple seven-step process:

1. Assemble a Team

Gather together people who are familiar with the specifics of the problem, and with the process that you’re trying to fix. Include someone to act as a facilitator who can keep the team focused on identifying effective counter-measures.

2. Define the Problem

If you can, observe the problem in action. Discuss it with your team and write a brief, clear problem statement that you all agree on. For example, “Team A isn’t meeting its response time targets” or “Software release B resulted in too many rollback failures.”

Then, write your statement on a whiteboard or sticky note, leaving enough space around it to add your answers to the repeated question, “Why?”

3. Ask the First “Why?”

Ask your team why the problem is occurring. (For example, “Why isn’t Team A meeting its response time targets?”)

Asking “Why?” sounds simple, but answering it requires serious thought. Search for answers that are grounded in fact: they must be accounts of things that have actually happened, not guesses at what might have happened.

This prevents 5 Whys from becoming just a process of deductive reasoning, which can generate a large number of possible causes and, sometimes, create more confusion as you chase down hypothetical problems.

Your team members may come up with one obvious reason why, or several plausible ones. Record their answers as succinct phrases, rather than as single words or lengthy statements, and write them below (or beside) your problem statement. For example, saying “volume of calls is too high” is better than a vague “overloaded.”

4. Ask “Why?” Four More Times

For each of the answers that you generated in Step 3, ask four further “whys” in succession. Each time, frame the question in response to the answer you’ve just recorded.


Try to move quickly from one question to the next, so that you have the full picture before you jump to any conclusions.

The diagram, below, shows an example of 5 Whys in action, following a single lane of inquiry

Figure 1: 5 Whys Example (Single Lane)


The 5 Whys method also allows you to follow multiple lanes of inquiry. An example of this is shown in Figure 2, below.

In our example, asking “Why was the delivery late?” produces a second answer (Reason 2). Asking “Why?” for that answer reveals a single reason (Reason 1), which you can address with a counter-measure.

Similarly, asking “Why did the job take longer than expected?” has a second answer (Reason 2), and asking “Why?” at this point reveals a single reason (Reason 1). Another “Why?” here identifies two possibilities (Reasons 1 and 2) before a possible counter-measure becomes evident.

There is also a second reason for “Why we ran out of printer ink” (Reason 2), and a single answer for the next “Why?” (Reason 1), which can then be addressed with a counter-measure.


Figure 2: 5 Whys Example (Multiple Lanes)


Step 5. Know When to Stop

You’ll know that you’ve revealed the root cause of the problem when asking “why” produces no more useful responses, and you can go no further. An appropriate counter-measure or process change should then become evident. (As we said earlier, if you’re not sure that you’ve uncovered the real root cause, consider using a more in-depth problem-solving technique like Cause and Effect Analysis, Root Cause Analysis, or FMEA.)

If you identified more than one reason in Step 3, repeat this process for each of the different branches of your analysis until you reach a root cause for each one.

Tip 1:

The “5” in 5 Whys is really just a “rule of thumb.” In some cases, you may need to ask “Why?” a few more times before you get to the root of the problem.

In other cases, you may reach this point before you ask your fifth “Why?” If you do, make sure that you haven’t stopped too soon, and that you’re not simply accepting “knee-jerk” responses.

The important point is to stop asking “Why?” when you stop producing useful responses.

Tip 2:

As you work through your chain of questions, you may find that someone has failed to take a necessary action. The great thing about 5 Whys is that it prompts you to go further than just assigning blame, and to ask why that happened. This often points to organizational issues or areas where processes need to be improved.

6. Address the Root Cause(s)

Now that you’ve identified at least one root cause, you need to discuss and agree on the counter-measures that will prevent the problem from recurring.

7. Monitor Your Measures

Keep a close watch on how effectively your counter-measures eliminate or minimize the initial problem. You may need to amend them, or replace them entirely. If this happens, it’s a good idea to repeat the 5 Whys process to ensure that you’ve identified the correct root cause.

Key Points

The 5 Whys strategy is a simple, effective tool for uncovering the root of a problem. You can use it in troubleshooting, problem-solving, and quality-improvement initiatives.

Start with a problem and ask why it is occurring. Make sure that your answer is grounded in fact, and then ask the question again. Continue the process until you reach the root cause of the problem, and you can identify a counter-measure that will prevent it from recurring.

Bear in mind that this questioning process is best suited to simple or moderately difficult problems. Complex problems may benefit from a more detailed approach, although using 5 Whys will still give you useful insights.

Business Analysis Techniques-Six Thinking Hats technique

In 1985, a man named Edward de Bono wrote a book called Six Thinking Hats. A physician, author, and consultant, de Bono is a proponent of teaching thinking as a subject in schools to help people be more successful in business and in life. He developed the Six Thinking Hats method as a way to run better meetings and make better decisions more quickly.

In the Six Hats methodology, de Bono identifies six different ways of thinking, each represented by six colored “thinking hats.” As you wear each hat, you learn how to think in different ways to brainstorm and approach problems from various angles.

The thinking hats are defined in the following ways.


White thinking hat

The white hat is like a detective who gathers, organizes, analyzes, and presents current information. As detectives gather clues and facts, they remain neutral and unbiased to avoid jumping to conclusions based on single bits of information. Instead, all clues, facts, and evidence must be analyzed and weighed to see what they have and what is missing.

In the same fashion, while “wearing” a white thinking hat, you should collect known information and analyze it to reach fact-based solutions. Analysis of the gathered data will help you find gaps so you can look for ways to fill them or at least take note of them so you have a better idea of how to direct your conversations.

Start gathering facts and data based on these problem-solving questions:

  • What do we know about this issue?
  • What don’t we know about this issue?
  • What can we learn from this situation?
  • What information do we need to solve this problem?
  • Are there potential existing solutions that we can use to solve this problem?

Work through these questions as a team to gather more information as each person shares their unique knowledge of a particular issue or problem.

Yellow thinking hat

This hat represents enthusiasm and optimism. Like a bright, sunny day, the yellow hat is used to bring positive energy and life to every idea.

With the yellow thinking hat, you seek to find the benefits and value of ideas. You should not be hampered by limitations or boundaries, but rather believe that when there’s a will, there’s a way.

Yellow hat questions could include:

  • What is the best way to approach the problem?
  • What can we do to make this work?
  • What are the long-term benefits of this action?

These questions are only a starting point. As you work through your Six Thinking Hats exercises, you may want to come up with more questions that take into account the optimistic role of the yellow hat.

Black thinking hat

The black hat is the opposite of the yellow hat and represents judgment. Wearers of this hat look for ways that the situation can go wrong.

The black hat is used to expose flaws, weaknesses, and possible dangers of proposed ideas. On the surface, the ideas you got from the yellow hat session may seem perfect. The black hat dives below the surface to find any potential problems. The black hat is essential to keep you from jumping headfirst into a potentially disastrous situation.

However, the black hat’s role is not just to sit around and be all judgy. In addition, this role looks for and identifies resources that may be needed to accomplish your goals.

Questions to help you think from the black hat perspective can include:

  • How will this idea likely fail?
  • What is this idea’s fatal flaw?
  • What are the potential risks and consequences?
  • Do we have the resources, skills, and ability to make this work?

Red thinking hat

While you have the red thinking hat, your primary goal is to intuitively suggest proposals and plans of action based on feelings and hunches. This hat is open-minded and non-judgmental. Using the information gathered from feelings and emotions, you should be able to intuitively relate these feelings to the problem you are trying to solve.

A red hat thinker’s objectives include:

  • Make intuitive insights known.
  • Seek out your team’s hunches and feelings.
  • Reveal an idea’s hidden strengths.
  • Use instinct to identify potential weaknesses.
  • Find internal conflicts.

For example, some ideas and plans may seem weak or impractical. But if someone wearing the red hat can identify a new idea or plan that “feels” right, this idea should open up discussion and exploration of additional opportunities you may never have considered.

Red thinking hat questions may include:

  • What is my gut feeling about this solution?
  • Based on feelings, is there another way to fix this problem?
  • What are our feelings about the choice we are making?
  • Does our intuition tell us this is the right solution?

Green thinking hats

Green hats are used for creative thinking. Wearing this hat lets you think outside the box to explore more possibilities and bend the rules of problem-solving. This creative thinking should be free from judgment and criticism.

Because the green hat is now bound by rules or limitations, this is where you can think beyond the norms of reality. The green hat lets you conduct a brainstorming session where no idea is too wild or crazy to be noted or immediately shot down. The green hat must refrain from criticizing or judging any ideas or suggestions that come up. The idea is to expand your thinking as you explore possible solutions.

The green hat may ask questions such as:

  • Do alternative possibilities exist?
  • Can we do this another way?
  • How can we look at this problem from other perspectives?
  • How do we think outside the box?

Keep in mind that as you work with the green thinking hat, you are free to express any idea that comes to mind. Even ideas that may sound crazy can have a kernel of feasibility that can put you on the right path to solving your problem.

Blue thinking hat

This hat provides a management role and will help you analyze the situation. When wearing the blue hat, your job is to manage the thinking of the other hats to ensure that the team stays focused and works more efficiently toward a workable solution. The role makes sure the other hats are being used correctly.

Specifically, the blue hat seeks to:

  • Efficiently and effectively improve the thinking process.
  • Ask the right questions that help you direct and focus your thinking.
  • Maintain and manage agendas, rules, goals, and tasks.
  • Organize ideas and proposals, and draw up action plans.

Questions that will help you in the blue hat role may include:

  • What is the problem?
  • How do we define the problem?
  • What is our goal and desired outcome?
  • What will we achieve by solving the problem?
  • What is the best method for going forward?

Try Lucidchart for your Six Thinking Hats activities

Though you can use the Six Hats technique individually to find all possible solutions and aspects of a problem, this method becomes even more effective when you work with a team. Use Lucidchart as your online whiteboard—it can help you record your team’s ideas whether you meet in person or want input from team members in dispersed offices.

Get started with our Six Thinking Hats template. Our example uses Six Thinking Hats to explore the question of whether a company should move from its current location to a larger office space. Members of the decision-making team include executives, directors, and senior members. The team will use the 6 hats methodology to think about all aspects of moving to a new location, such as feasibility, logistics, costs, and so on.

Business Analysis Techniques-Business process modeling (BPM)

business analysis techniques,business analysis training,business analysis certification

business process management

Managing business processes is a huge challenge in most organizations. Businesses aren’t investing enough efforts in streamlining their business processes due to the lack of awareness about its repercussions. Here’s a definitive guide to managing your business processes with the help of automation.

What is Business Process Management (BPM)?

Business Process Management (BPM) is how a company creates, edits, and analyzes the predictable processes that make up the core of its business.

Each department in a company is responsible for taking some raw material or data and transforming it into something else. There may be a dozen or more core processes that each department handles.

With Business Process Management, a company takes a step back and looks at all of these processes in total and individually. It analyzes the current state and identifies areas of improvement to create a more efficient and effective organization.

How does Kissflow differ from other BPM tools?

Unlike other BPM tools that help you manage only standardized processes, Kissflow offers its users a unique platform that combines structured but ongoing workflows (process), manual workflows (case), and structured, one-off workflows (project). All these are tied together with a channel-based collaborative tool. You can bring all forms of work under one roof and ensure that everything is streamlined and smooth

Business process management is neither task management (which focuses on individual tasks) or project management (which handles one-time or unpredictable flows).

Task management is about handling or organizing a set of activities that arise out of a project. These projects are often one-time and non-repeatable. When these projects are well-organized like in construction work, a project management software like ‘Microsoft Project’ is used. Trello and Asana are good tools for managing tasks in ad-hoc projects.

Business Process Management is focused more on repetitive and ongoing processes that follow a predictable pattern, or process management.

Why  business process management matter

When left unorganized and unsystematized, poor business processes can lead to mayhem. At the individual level, people only see one part of a process, and very few can scan out and see the full effects of a process, where it starts and ends, the key data needed, and where potential bottlenecks and inefficiencies lie.

Unmanaged, chaotic processes hurt business and lead to one or more of these scenarios:

  • Time wasted
  • More errors
  • Increased blame
  • Lack of data
  • Demoralized employees

Applying business process management organizations can improve their processes and keep all aspects of operations running optimally

Business Analysis Techniques-Business Process Management Life Cycle:

Here are the steps in business process management:

Step 1: Design

Most processes include a form to collect data and a workflow to process it. Build your form and identify who will own each task in the workflow.

Step 2: Model

Represent the process in a visual layout. Fix details like deadlines and conditions to give a clear idea of the sequence of events, and the flow of data through the process.

Step 3: Execute

Execute the process by testing it live with a small group first and then open it up to all users. Make sure you restrict access to sensitive information.

Step 4: Monitor

Keep an eye on the process as it runs through the workflow. Use the right metrics to identify progress, measure efficiency, and locate bottlenecks. Here is a more detailed article about this step.

Step 5: Optimize

As you analyze, notice any changes that need to be done to your form or workflow to make them more efficient. Consider business process improvement steps.

Kissflow, our process tracking software, can help your business stay constantly aware of every last business process.

What are the various types of business process management?

BPM systems can be categorized based on the purpose that they serve. Here are the three types of business process management:

Integration-Centric BPM:

This type of business process management system handles processes that primarily jump between your existing systems (e.g. HRMS, CRM, ERP) without much human involvement. Integration-centric business process management systems have extensive connectors and API access to be able to create processes that move fast.

Human-Centric BPM:

Human-centric BPM is for those processes that are primarily executed by humans. These often have a lot of approvals and tasks performed by individuals. These platforms excel at a friendly user interface, easy notifications, and quick tracking.

Document-Centric BPM:

These business process management solutions are required when a document (e.g. a contract or agreement) is at the heart of the process. They enable routing, formatting, verifying, and getting the document signed as the tasks pass along the workflow.

Most business process management systems will be able to incorporate elements of each of these, but each one will usually have one specialty.

What are the benefits of incorporating business process management?

Here are some of the primary benefits of using BPM in your business:

  • Gain control of chaotic and unwieldy processes
  • Create, map, analyze, and improve business processes
  • Run everyday operations more efficiently
  • Realize bigger organizational goals
  • Move toward digital transformation
  • Improve and optimize tangled operations
  • Closely track individual items as they move through a workflow

Business process management examples:


Have you ever felt your organization’s onboarding process is too complex and chaotic? Is your HR department asking the candidates to fill out paper forms that make them exhausted? This is because your HR department lacks the principle of Business Process Management (BPM). Applying business process management, helps you automate your HR processes end-to-end, thereby cutting down on cost, time, and paper forms. Given below are a couple of examples as to how business process management helps your HR department to improve their processes:


In most organizations, the sales team spends a significant amount of time in coordinating with the Accounts Receivable (AR) team, to get sales invoices approved. Even a small typo in invoices, ruins the lives of the salespeople. This is where business process management comes into the picture, since it automates the invoice approval process, thereby eliminating the chances of manual errors and the back and forth clarifications between the salespeople and the AR team. Given below are a couple of scenarios in the sales department, where business process management can help them streamline their processes:


Finance team is the one that is bombarded with paper forms and emails every day, since anything that involves money has to go through them. For instance, if the asset management team wants to purchase 50 laptops, they send the quotation that they received from the vendor to the finance team, for them to approve it. This is just one case. Imagine, how many such emails or paper forms they would be receiving on a daily basis from various teams. Without a system in place, it’ll be cumbersome for them to manage all of these. The one that helps them manage these processes is essentially the business process management (BPM) system. Given below are a couple of scenarios in the finance department, where business process management comes as a saving grace:

Usually, BPM is represented in a diagrammatic way where process, decisions, and information are represented as a sequential workflow. There are two types notations used for BPM diagrams

  • BPMN – Business Process Modeling Notation
  • UML – Unified Modelling Language Activity Diagram

Business Analysis Techniques-User Stories

User stories is a fairly modern Business Analysis Technique which is a way to describe what a user wants in terms of how they will be using a system for their own purposes coming from a specific perspective. User stories are often supported by specific personas, which are created to encourage the development of the full spectrum of user stories from all identified user types. In this technique, requirements are collected from end users point of views to build the best solution.

Why User Stories?

Requirements always change as teams and customers learn more about the system as the project progresses. It’s not exactly realistic to expect project teams to work off a static requirements list and then deliver functional software months later.

With user story approach, we replace big upfront design with a “just enough” approach. User stories reduce the time spent on writing exhaustive documentation by emphasizing customer-centric conversations. Consequently, user stories allow teams to deliver quality software more quickly, which is what customers prefer. There are quite a few benefits for adopting user story approach in agile development such as:

  • The simple and consistent format saves time when capturing and prioritizing requirements while remaining versatile enough to be used on large and small features alike.
  • Keep yourself expressing business value by delivering a product that the client really needs
  • Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution.
  • Avoid the appearance of false completeness and clarity
  • Get to small enough chunks that invite negotiation and movement in the backlog
  • Leave the technical functions to the architect, developers, testers, and so on

Basic Concepts of User Story

A user story is a lightweight method for quickly capturing the “who”, “what” and “why” of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are “to-do” lists that help you determine the steps along the project’s path. They help ensure that your process, as well as the resulting product, will meet your requirements.

A user story is defined incrementally, in three stages:

  • The brief description of the need
  • The conversations that happen during backlog grooming and iteration planning to solidify the details
  • The tests that confirm the story’s satisfactory completion

And these, although, are known as the 3C’s – Card, Conversation and Confirmation. We will talk more about this later on in this user story guide.

Business Analysis Techniques-User Stories – INVEST

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

A good user story should be – INVEST:

  • Independent: Should be self-contained in a way that allows to be released without depending on one another.
  • Negotiable: Only capture the essence of user’s need, leaving room for conversation. User story should not be written like contract.
  • Valuable: Delivers value to end user.
  • Estimable: User stories have to able to be estimated so it can be properly prioritized and fit into sprints.
  • Small: A user story is a small chunk of work that allows it to be completed in about 3 to 4 days.
  • Testable: A user story has to be confirmed via pre-written acceptance criteria.

How to Write User Stories?

When getting started with writing user stories, a template can help ensure that you don’t inadvertently start writing technical tasks:

User Story Template

User stories only capture the essential elements of a requirement:

  • Who it is for?
  • What it expects from the system?
  • Why it is important (optional?)?

Here is a simple format of user story used by 70% of practitioners:

Role – The user should be an actual human who interacts with the system.

  • Be as specific as possible
  • The development team is NOT a user

Action – The behavior of the system should be written as an action.

  • Usually unique for each User Story
  • The “system” is implied and does not get written in the story
  • Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

  • Many stories may share the same benefit statement.
  • The benefit may be for other users or customers, not just for the user in the story.


User stories are written in everyday language and describe a specific goal (what) from the perspective of an individual (who) along with the reason (why) he/she wants it.

In software development, the goal is often a new product feature, the individual is some type of end-user and the reason is the benefit that the user sees in the targeted product feature.

User Story Examples:

  • As a [customer], I want [shopping cart feature] so that [I can easily purchase items online].
  • As an [manager], I want to [generate a report] so that [I can understand which departments need more resources].
  • As a [customer], I want to [receive an SMS when the item is arrived] so that [I can go pick it up right away]

In the examples above:

  • Role represents the person, system, subsystem or any entity else who will interact with the system to be implemented to achieve a goal. He or she will gain values by interacting with the system.
  • Action represents a user’s expectation that can be accomplished through interacting with the system.
  • Benefits represents the value behind the interaction with the system.

It is not a rule but a guideline that helps you think about a user story by considering the followings:

  • The user story will bring value to someone or certain party (e.g. customers).
  • The user story is fulfilling a user’s need (e.g. receive an SMS when the item is arrived)
  • There is a reason to support implementing this user story (e.g. customer can go pick up the item she purchased)

How to Identify User Story?

User stories should be identified together with the stakeholders, preferably through a face-to-face meeting. User story is a requirement discovery process instead of an upfront requirement analysis process.

In the traditional requirements capturing approaches, system analyst tries to understand customers’ needs and then prepare a requirement specification for the system in detail. This is not how the user story approach works. Instead of a documentation process, the identification of user story is more like a note taking process. We list the major steps for identifying user stories as following:

  1. Through the discussions with users, we listen to and understand their problems and needs
  2. And then, write down their needs as user stories at the same time.
  3. These user stories will become the source of requirements.
  4. The details could be subsequently filled just-in-time, providing the team with a “just-enough” requirement references throughout the project development process.

Lifecycle of a User Story

In a broad sense, there are six main states for each user story throughout a software project:


Through the communication between user and project team, user stories are found. At this state, the user stories have nothing more than a short description of user’s need. There is no detailed discussion of requirements, no system logic and no screen design yet. In fact, the only purpose of user story, for now, is just for reminding all parties for a future discussion of user’s request written in this user story (card). It is possible that the user story will be discarded in the future.


Through a discussion between different stakeholders, the user stories to be addressed in the next few weeks are decided, and are put into a time-box called a sprint. Such user stories are said to be in the to-do state. No detailed discussion has yet been carried out in this state.


When a user story is in the Discussing state, the end user will communicate to the development team in confirming the requirements as well as to define the acceptance criteria. Development team will write down the requirements or any decisions as conversation notes. UX specialist may create wireframes or storyboards to let user preview the proposed features in visual mock-ups, and to feel it. This process is known as user experience design (UX design).


After the requirements are clarified, the development team will design and implement the features to fulfill user’s requests.


Upon the development team has implemented a user story, the user story will be confirmed by the end user. He/she will be given access to the testing environment or a semi-complete software product (sometimes known as an alpha version) for confirming the feature. Confirmation will be performed based on the confirmation items written when detailing the user story. Until the confirmation is done, the user story is said to be in the Confirming state.

Finally, the feature is confirmed to be done, the user story is considered in the Finished state. Typically, this is the end of the user story. If user has a new requirement, either it is about a new feature, or it is an enhancement of the finished user story, the team would create a new user story for the next iteration.

Organizing User Stories with Story Map

User stories is a useful way to build a better product backlog, one that is user-centric and describes software requirements in a practical, actionable way. But user stories on their own do not reveal the whole picture that can clue you in on the larger journey the user goes through from the moment that load an app until they reach their final goal.

A user story map can help us to arrange user stories into a manageable model for plan, understand and organize the functionality of the system systematically. By manipulating the structure of the map, we can identify holes and omissions in your backlog and interrelating the user stories in a meaning structure; helping plan holistic releases effectively that deliver value to users and business with each release. User story map allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:

  • It allows you to see the big picture in your backlog.
  • It gives you a better tool for making decisions about grooming and prioritizing your backlog.
  • It promotes silent brainstorming and a collaborative approach to generating your user stories.
  • It encourages an iterative development approach where your early deliveries validate your architecture and solution.
  • It is a great visual alternative to traditional project plans.
  • It is a useful model for discussing and managing scope.
  • Allows you to visualize dimensional planning and real options for your project/product.

User Story Map Template

Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from user activities. A user activity should achieved a particular goals. And to complete an activity, users needs to perform the associated tasks. And these tasks can be transformed into epics and user stories for software development. Typically, user story map consists of 3 levels: User Activities / User Tasks / User Stories. For enterprise scale projects, perhaps a 4 levels structure may be more appropriate by introduce Epics in the third level.

User Activities – They are laid out in the second column. This are major objectives that the system must support, with tangible business outcome. The entire row forms the backbone.

User Tasks – Each of the user activities is broke down into a set of related user tasks called narrative flow. The entire row forms the walking skeleton)

Epics / user stories – Each of the user tasks is broken down into Epics / User Stories underneath directly the user task that the feature realizes. Depending on the complexity of your projects, your team may choose the 3 or 4 level of story map which is more appropriate to you as mentioned above.

Visual Paradigm Story Map supports both 3 and 4 levels of complexity for you to cope wide variety type of projects.

Planning for Releases

Use a separator to identify slices of tasks that users might use your software for to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release as shown in the Figure below:

How to Use User Story Effectively

Just like many other software development methodologies, if you apply user story properly in your software project you will be able to produce a quality software system plus to win the trust and satisfaction from customers. Here are some points that you need to keep in mind when using user story:

  • Keep the description of user story short.
  • Think from end user’s point of view when writing a user story.
  • Confirmation items must be defined before you start the development
  • Estimate the user story before implementation to ensure the workload of your team is under control.
  • Requirements are found with the end users, not by the end user or just by the development team. Keeping a good relationship with the end users will be a win-win situation for both parties.
  • Communication is always important in understanding what the end user wants.

Business Analysis Techniques-What is the Requirements Analysis?

Requirements Analysis is the process of defining the expectations of the users for an application that is to be built or modified. Requirements analysis involves all the tasks that are conducted to identify the needs of different stakeholders. Therefore requirements analysis means to analyze, document, validate and manage software or system requirements. High-quality requirements are documented, actionable, measurable, testable, traceable, helps to identify business opportunities, and are defined to a facilitate system design.

Requirements analysis process

The requirements analysis process involves the following steps:

Eliciting requirements

The process of gathering requirements by communicating with the customers is known as eliciting requirements.

Analyzing requirements

This step helps to determine the quality of the requirements. It involves identifying whether the requirements are unclear, incomplete, ambiguous, and contradictory. These issues resolved before moving to the next step.

Requirements modeling

In Requirements modeling, the requirements are usually documented in different formats such as use cases, user stories, natural-language documents, or process specification.

Review and retrospective

This step is conducted to reflect on the previous iterations of requirements gathering in a bid to make improvements in the process going forward.


Requirements Analysis Techniques

There are different techniques used for Requirements Analysis. Below is a list of different Requirements Analysis Techniques:

Business process modeling notation (BPMN)

This technique is similar to creating process flowcharts, although BPMN has its own symbols and elements. Business process modeling and notation is used to create graphs for the business process. These graphs simplify understanding the business process. BPMN is widely popular as a process improvement methodology.

UML (Unified Modeling Language)

UML consists of an integrated set of diagrams that are created to specify, visualize, construct and document the artefacts of a software system. UML is a useful technique while creating object-oriented software and working with the software development process.  In UML, graphical notations are used to represent the design of a software project.  UML also help in validating the architectural design of the software.

Flowchart technique

A flowchart depicts the sequential flow and control logic of a set of activities that are related. Flowcharts are in different formats such as linear, cross-functional, and top-down.  The flowchart can represent system interactions, data flows, etc. Flow charts are easy to understand and can be used by both the technical and non-technical team members. Flowchart technique helps in showcasing the critical attributes of a process.

Data flow diagram

This technique is used to visually represent systems and processes that are complex and difficult to describe in text. Data flow diagrams represent the flow of information through a process or a system. It also includes the data inputs and outputs, data stores, and the various subprocess through which the data moves. DFD describes various entities and their relationships with the help of standardized notations and symbols.  By visualizing all the elements of the system it is easier to identify any shortcomings. These shortcomings are then eliminated in a bid to create a robust solution.

Role Activity Diagrams (RAD)

Role-activity diagram (RAD) is a role-oriented process model that represents role-activity diagrams. Role activity diagrams are a high-level view that captures the dynamics and role structure of an organization. Roles are used to grouping together activities into units of responsibilities. Activities are the basic parts of a role. An activity may be either carried out in isolation or it may require coordination with other activities within the role.

Gantt Charts

Gantt charts used in project planning as they provide a visual representation of tasks that are scheduled along with the timelines. The Gantt charts help to know what is scheduled to be completed by which date. The start and end dates of all the tasks in the project can be seen in a single view.

IDEF (Integrated Definition for Function Modeling)

Integrated definition for function modeling (IDEFM) technique represents the functions of a process and their relationships to child and parent systems with the help of a box. It provides a blueprint to gain an understanding of an organization’s system.

Gap Analysis

Gap analysis is a technique which helps to analyze the gaps in performance of a software application to determine whether the business requirements are met or not. It also involves the steps that are to be taken to ensure that all the business requirements are met successfully. Gap denotes the difference between the present state and the target state. Gap analysis is also known as need analysis, need assessment or need-gap analysis.


For the success of a project, it is utmost important to analyze project requirements when they are gathered as well as throughout the lifecycle of the project. Requirements analysis helps to keep the requirements in line with the need of the business. A good requirements analysis process will render a software application that caters to the objectives of the business set forth.


Business Analysis Techniques-Brainstorming

For decades, people have used brainstorming to generate ideas, and to come up with creative solutions to problems. However, you need to use brainstorming correctly for it to be fully effective. In this article, we’ll look at what it is, why it’s useful, and how to get the best from it.

What Is Brainstorming?

Brainstorming combines a relaxed, informal approach to problem solving with lateral thinking. It encourages people to come up with thoughts and ideas that can, at first, seem a bit crazy. Some of these ideas can be crafted into original, creative solutions to a problem, while others can spark even more ideas. This helps to get people unstuck by “jolting” them out of their normal ways of thinking.

Therefore, during brainstorming sessions, people should avoid criticizing or rewarding ideas. You’re trying to open up possibilities and break down incorrect assumptions about the problem’s limits. Judgment and analysis at this stage stunts idea generation and limit creativity.

Evaluate ideas at the end of the session – this is the time to explore solutions further, using conventional approaches.

Why Use Brainstorming?

Conventional group problem solving can often be undermined by unhelpful group behavior. And while it’s important to start with a structured, analytical process when solving problems, this can lead a group to develop limited and unimaginative ideas.

By contrast, brainstorming provides a free and open environment that encourages everyone to participate. Quirky ideas are welcomed and built upon, and all participants are encouraged to contribute fully, helping them develop a rich array of creative solutions.

When used during problem solving, brainstorming brings team members’ diverse experience into play. It increases the richness of ideas explored, which means that you can often find better solutions to the problems that you face.

It can also help you get buy-in from team members for the solution chosen – after all, they’re likely to be more committed to an approach if they were involved in developing it. What’s more, because brainstorming is fun, it helps team members bond, as they solve problems in a positive, rewarding environment.

While brainstorming can be effective, it’s important to approach it with an open mind and a spirit of non-judgment. If you don’t do this, people “clam up,” the number and quality of ideas plummets, and morale can suffer.

Individual Brainstorming

While group brainstorming is often more effective at generating ideas than normal group problem solving, several studies have shown that individual brainstorming produces more – and often better – ideas than group brainstorming.

This can occur because groups aren’t always strict in following the rules of brainstorming, and bad behaviors creep in. Mostly, though, this happens because people pay so much attention to other people that they don’t generate ideas of their own – or they forget these ideas while they wait for their turn to speak. This is called “blocking.”

When you brainstorm on your own, you don’t have to worry about other people’s egos or opinions, and you can be freer and more creative. For example, you might find that an idea you’d hesitate to bring up in a group develops into something special when you explore it on your own.

However, you may not develop ideas as fully when you’re on your own, because you don’t have the wider experience of other group members to draw on.


To get the most out of your individual brainstorming session, choose a comfortable place to sit and think. Minimize distractions so that you can focus on the problem at hand, and consider using Mind Maps to arrange and develop ideas.

Individual brainstorming is most effective when you need to solve a simple problem, generate a list of ideas, or focus on a broad issue. Group brainstorming is often more effective for solving complex problems.

Group Brainstorming

Here, you can take advantage of the full experience and creativity of all team members. When one member gets stuck with an idea, another member’s creativity and experience can take the idea to the next stage. You can develop ideas in greater depth with group brainstorming than you can with individual brainstorming.

Another advantage of group brainstorming is that it helps everyone feel that they’ve contributed to the solution, and it reminds people that others have creative ideas to offer. It’s also fun, so it can be great for team building!

Group brainstorming can be risky for individuals. Unusual suggestions may appear to lack value at first sight – this is where you need to chair sessions tightly, so that the group doesn’t crush these ideas and stifle creativity.

Where possible, participants should come from a wide range of disciplines. This cross-section of experience can make the session more creative. However, don’t make the group too big: as with other types of teamwork, groups of five to seven people are usually most effective.


How to Use the Tool

You often get the best results by combining individual and group brainstorming, and by managing the process according to the “rules” below. By doing this, you can get people to focus on the issue without interruption, you maximize the number of ideas that you can generate, and you get that great feeling of team bonding that comes with a well-run brainstorming session!

To run a group brainstorming session effectively, follow these steps.

Step 1: Prepare the Group

First, set up a comfortable meeting environment

for the session. Make sure that the room is well-lit and that you have the tools, resources, and refreshments that you need.

How much information or preparation does your team need in order to brainstorm solutions to your problem? Remember that prep is important, but too much can limit – or even destroy – the freewheeling nature of a brainstorming session.

Consider who will attend the meeting. A room full of like-minded people won’t generate as many creative ideas as a diverse group, so try to include people from a wide range of disciplines, and include people who have a variety of different thinking styles.

When everyone is gathered, appoint one person to record the ideas that come from the session. This person shouldn’t necessarily be the team manager – it’s hard to record and contribute at the same time. Post notes where everyone can see them, such as on flip charts or whiteboards; or use a computer with a data projector.

If people aren’t used to working together, consider using an appropriate warm-up exercise, or an icebreaker

Step 2: Present the Problem

Clearly define the problem that you want to solve, and lay out any criteria that you must meet. Make it clear that that the meeting’s objective is to generate as many ideas as possible.

Give people plenty of quiet time at the start of the session to write down as many of their own ideas as they can. Then, ask them to share their ideas, while giving everyone a fair opportunity to contribute.

Step 3: Guide the Discussion

Once everyone has shared their ideas, start a group discussion to develop other people’s ideas, and use them to create new ideas. Building on others’ ideas is one of the most valuable aspects of group brainstorming.

Encourage everyone to contribute and to develop ideas, including the quietest people, and discourage anyone from criticizing ideas.

As the group facilitator, you should share ideas if you have them, but spend your time and energy supporting your team and guiding the discussion. Stick to one conversation at a time, and refocus the group if people become sidetracked.

Although you’re guiding the discussion, remember to let everyone have fun while brainstorming. Welcome creativity, and encourage your team to come up with as many ideas as possible, regardless of whether they’re practical or impractical. Use thought experiments such as Provocation or Random Input to generate some unexpected ideas.

Don’t follow one train of thought for too long. Make sure that you generate a good number of different ideas, and explore individual ideas in detail. If a team member needs to “tune out” to explore an idea alone, allow them the freedom to do this.

Also, if the brainstorming session is lengthy, take plenty of breaks so that people can continue to concentrate.

Taking Your Brainstorming Further

If you’re not getting enough good quality ideas, try using the approaches below to increase the number of ideas that you generate:

  • The Stepladder Technique– This improves the contribution of quieter group members by introducing one person at a time.
  •  Brainwriting This is a written approach that you can use to encourage all individuals to generate and develop ideas.
  •  Online Brainstorming (also known as Brain-netting) – An electronic method of brainstorming, this uses a document stored on a central server, or on a Cloud-based system.
  • Crawford’s Slip Writing Approach – You can use this approach to get plenty of ideas from all participants, and to get a view of each idea’s popularity.

These techniques help you in specific situations:

  • Reverse Brainstorming   – This is used to improve a product or service.
  • Starbursting – Starbursting helps you develop questions that you need to ask to evaluate a proposal.
  • Charette Procedure – This helps you brainstorm with large groups of people. (Conventional brainstorming becomes increasingly ineffective when more than 10 or 12 people are involved.)
  • Round-Robin Brainstorming  – You can use this approach to get people to contribute ideas without being influenced by others.
  • Rolestorming – This technique encourages group members to take on other people’s identities while brainstorming, thereby reducing their inhibitions.

The Next Step – Taking Action

After your individual or group brainstorming session, you’ll have a lot of ideas. Although it might seem hard to sort through these ideas to find the best ones, analyzing these ideas is an important next step, and you can use several tools to do this.

Use Affinity Diagrams to organize ideas and find common themes.

Decision Matrix Analysis and Paired Comparison Analysis will help you choose between different options. You can also use the Six Thinking Hats technique to look at ideas from different perspectives; and the Modified Borda Count and Multi-Voting can help you choose between options as a team, particularly where the differences between options are quite subjective.

Key Points

When managed well, brainstorming can help you generate radical solutions to problems. It can also encourage people to commit to solutions, because they have provided input and played a role in developing them.

The best approach combines individual and group brainstorming. During the process, there should be no criticism of ideas, and creativity should be encouraged.

Business Analysis Techniques-Non-functional Requirement Analysis

The semantic definition would be “any requirement that is not functional“. However, as (for example) data requirements are clearly not functional requirements, and also are clearly not non-functional requirements, this definition is clearly not sufficient!
The fact is that non-functional requirements are any requirements that cannot be categorised into Functional, Data or Process requirements. We only know

  • They are requirements
  • They are not functional, data or process requirements.

In that sense they are a ‘catch-all’ bucket for all those requirements that cannot be categorised in any other way.

The International Institute of Business Analysis ( IIBA) Business Analysis Body Of Knowledge (BABOK) v1.6 suggests that “Quality of service requirements are most often used to describe some of the attributes of the system or system environment. These requirements are constraints on the solution. They are also known as non-functional requirements.”

This may be a useful approach but the important thing is not to get worried about whether a requirement is a non-functional or not. If you can’t categorise it any other way then categorise it as non-functional. The thing to really worry about is not mis-categorising a requirement, but missing a requirement altogether!

There is an important attribute of non-functional requirements that does differentiates them from other requirements and that is they are optional: Not all solutions will need to specify all categories of non-functional requirement. On the other hand, all solutions will need a specification of their functional, data and process requirements.

So what is a requirement that is not functional, process or data? There are a significant number and this is not an exhaustive list of categories:

  • Accessibility Requirements
  • Accuracy Requirements
  • Auditing and Reporting Requirements
  • Availability Requirements
  • Backup and Recovery Requirements
  • Capacity Requirements
  • Compatibility Requirements
  • Concurrency Requirements
  • Configurability Requirements
  • Error-Handling Requirements
  • Legal and Regulatory Requirements
  • Licensing Requirements
  • Localizability Requirements
  • Maintainability Requirements
  • Performance Requirements
  • Precision Requirements
  • Redundancy Requirements
  • Reliability Requirements
  • Scalability Requirements
  • Security Requirements
  • Stress Requirements
  • Supportability Requirements
  • Throughput Requirements
  • Etc, etc, etc!

Note that non-functional requirements tend to be the ‘ilities” of the system aka availability, accessibility, etc. Why so many and why the “etc, etc, etc!”? Because as business analysts we need to define all the requirements for a solution and while there are some categories of requirements common to all solutions (functional, data and process) there are a set of categories of requirements that are not common to all solutions and will vary by the particular circumstances of the change project being worked on. As no two change projects ever have the same set of particular circumstances it is likely that there will always be exceptions to the general categorisations of requirements that never-the-less need to be analysed and carried into the design. That is not to say there are not a set of “usual suspects” of non-functional requirements that most change projects will probably need to analyse and these are:

  • Availability Requirements
  • Capacity Requirements
  • Performance Requirements
  • Reliability Requirements
  • Security Requirements

For example, a solution that provides the user the functionality to manage sales through – in part – capturing customer data in the ‘create customer’ process may also need to specify some non-functional requirements defining

  • Who is allowed to operate the process?
  • Are there any restrictions on the data that users can see? (Can users see full credit card numbers for example).
  • How many of these transactions per hour must the solution be capable of processing?
  • When can user operate this process?
  • How many users can operate the process at the same time?

This solution may NOT need to specify

  • Licensing requirements (it could be an in-house development).
  • Configurability requirements (all users might have to run the process in the same way).
  • Scalability requirements (the scope may be fixed user group with no predictions of growth).

A final point: there is no one single correct way to document non-functional requirements. The way you choose should support your objectives of making sure that all requirements are designed in to the solution and whatever way that achieves this best is the correct way. We will look at some of the general issues in this area in the section on documenting non-functional requirements, but typically there are different factors to consider for different non-functional requirements and these will be outlined in the articles looking at each of the non-functional requirements we have identified.

How to identify non-functional requirements

Let’s face it: it is unlikely that we will sit down with your users and say “today we are going to analyse non-functional requirements.” So the question is how do you set about uncovering these non-functional requirements. You have to ‘uncover’ them because they already exist whether you and your users know about them, so you just have to find them!

The good news is you have an advantage over your users: You already know that some non-functional requirements do in fact exist (and need discovering) and roughly what categories of non-functional requirements there are. It would be nice if you could just work through a list with your users:
“Ok, please tell me when you need to be able to run this process.” (Availability).
“Now tell me how many times you expect to run this process per hour.” (Throughput).
“Now tell me how long we need to retain the data that this process generates.” (Auditing)

Perhaps that would work! That is for you to judge based on what you know about your users. However, what we must recognise as Business Analysts is that humans are not usually quite so methodological. What they tend to do is tell us Business Analysts a whole bunch of things all in one go: “Hey, this process is terrible: it takes 10 minutes to process an order! What we need is a system that can retrieve the customer details as soon as the operator enters the customer name and address – oh and the operator must validate that data with the customer – and we need to keep the data for 6 years (because of financial regulations)”

As Business Analysts we need to categorize all the information they have just given us into a structure that allows us to analyze their requirements:

  • There is an objective to reduce the time taken to process an order from 10 minutes to…(well, we don’t know and we would need to ask).
  • There is a process requirement to retrieve customer details.
  • There is a non-functional requirement to retrieve customer details as soon as the operator enter the customer name and address.
  • There is a process requirement to validate customer details.
  • There is a non-functional requirement to keep customer details for 6 years (starting when? We don’t know and would have to ask.)
  • There is an objective to maintain compliance with financial regulations (which ones? We don’t know and would have to ask to see what other objectives we might have in order to maintain compliance).

As Business Analysts we also know that for the above processes (retrieve customer details and validate customer details) and data (customer details) there will almost certainly be the following set of “the usual suspects” non-functional requirements as well as any we have already discovered:

  • Availability Requirements – when do they want to be able to operate these processes?
  • Capacity Requirements – how many times do they operate the process per day? How many customers are there (over 6 years)?
  • Performance Requirements – they asked for the data to be returned “as soon as” the operator entered the customer name and address. Does this really mean instantly (which could have a significant impact on costs of the solution) or is there a time period that they would deem acceptable (e.g. 1 second).
  • Reliability Requirements – do the users really need the process and data to be available 100% of the time? Again, cost impacts if they do and if not then what would they be prepared to accept (e.g. is it acceptable if the system goes down for no more than 1 day per year).
  • Security Requirements – who can use these processes? Just ‘operators’ or can ‘system administrators’ (for example) use them as well? Can all operators access any customer details or are there some that they are not allowed to access? E.g. operator teams who manage customer segments – perhaps they should not be allowed to see other operator team customers?

Then we might start thinking about other candidate non-functional requirements: perhaps the operators in different teams need to configure what information gets retrieved for their customers…?

How to document non-functional requirements

It depends on what type of non-functional requirements you are documenting and at what level they apply.

The basic types of non-functional requirements are process, data or both.

The basic levels that non-functional requirements can be applied at are

  • Whole solution
  • All automated (or all manual) components of the solution
  • Functional requirement
  • Whole process
  • Any level within a process hierarchy
  • An individual process step
  • All data
  • An individual data entity
  • An individual attribute on an entity

Regardless of type and level that they are documented at, non-functional requirements all involve a definition of what they are and some values (targets) they must achieve.

We can imagine a matrix:

Process Data Both
Whole solution      
All automated or all manual components      
Functional requirement      
Whole process      
Any level within a process hierarchy      
An individual process step      
All data      
An individual data entity      
An individual attribute on an entity      

At each intersection can be any combination of non-functional requirements. This is – potentially – a lot of non-functional requirements!

We can restrict the number we document by applying 2 rules:

  • only document the non-functional requirements that apply to the solution – not all solutions will need to specify all non-functional requirements.
  • Given that we want to document the minimum number necessary to define the non-functional requirements it follows that we should document the non-functional requirements at the highest row we can based on the principle that a non-functional requirement applies to all the components it logically contains. It also follows by the same rule that if we can put it in to the ‘both’ column we should.


  • “the solution should be available to users during normal working hours” could apply to the whole solution for both processes and data (top right in the matrix).
  • “full history of all changes to the date of birth of a customer must be maintained” applies to one attribute used by process steps within a processes within functional requirements within the automated components within the whole solution.

So, back to the question of how to document functional requirements.

We have seen that non-functional requirements can be documented in text as they all involve a definition of what they are and some values (targets) they must achieve.

That text needs to written against the highest element within the matrix they can be incorporated in to and here is a table showing the analysis deliverables that could be used to document different types of non-functional requirements at different levels:


Process Data Both
Whole solution Terms of reference or
Requirements Spec
Terms of reference or
Requirements Spec
Terms of reference or
Requirements Spec
All automated or all manual components Terms of reference or
Requirements Spec
Terms of reference or
Requirements Spec
Terms of reference or
Requirements Spec
Functional requirement Requirements Spec or Requirements catalogue N/a N/a
Whole process Process spec Process spec Process spec
Any level within a process hierarchy Relevant level process spec Relevant level process spec or
Entity spec or
Attribute spec
Relevant level process spec
An individual process step Process step spec Process step spec or
Entity spec or
Attribute Spec
Process step spec
All data Process spec Data model overview Process spec
Data model overview
An individual data entity Process spec or
Entity spec
Entity spec Process spec or
Entity spec
An individual attribute on an entity Process spec or
Attribute spec
Attribute spec Process spec or
Attribute spec

Suppose you have different names for your analysis deliverables or maybe different analysis deliverables? You should still apply the rules of documenting the non-functional requirements you need to at the highest level you can, regardless of the analysis deliverable they end up in.

Example non-functional requirements

Non functional requirement category Typically applies to Non-functional Type Example
Accessibility Requirements Process Help text will be provided in English, French and German.
Accuracy Requirements Both Process: All comment fields will be spell checked.
Data: Date of Birth must be in the past.
Auditing and Reporting Requirements Both Process: A record of which users access or try to access process “Update Customer” is required.
Data: A record of which user updates the Date of Birth attribute is required.
Availability Requirements Process Process “Update Customer” is available 08:00 to 18:00 daily excluding Sundays and Public Holidays.
Backup and Recovery Requirements Both Process: All processes can be made available after unplanned system downtime within 1 working day.
Data: All data will be backed-up daily.
Capacity Requirements Both Process: Up to 500 users in total can use “Update Customer”.
Data: Up to 1,000,000 customers can be stored.
Compatibility Requirements Both Process: “Update Customer” can integrate Word 2003 onwards.
Data: Customer data can be exported in XML format.
Concurrency Requirements Process Up to 300 users may be using “Update Customer” at any one time.
Configurability Requirements Process “Update Customer” users may choose whether to display previous name the customer has been known by.
Error-Handling Requirements Process In the event of the user cancelling or quitting the process “Update Customer” any changes made by the user will be reversed.
Legal and Regulatory Requirements Both Process: The user must confirm that they have notified the customer of the updates they have made before saving changes made during “Update Customer”.
Data: All changes to Customer data will be held for 6 years from the date of change.
Licensing Requirements Both Process: The “Update Customer” process will be licensed for 300 concurrent users.
Data: The Postcode Address File will be licensed for 1 year starting each April.
Localizability Requirements Both Process: For American users of “Update Customer” all dates will be displayed in MM/DD/YY format.
Data: For American users all currency will be stored as USD.
Maintainability Requirements Both Process or data: Changes required by law will applied at least 3 months before the law becomes enforceable.
Performance Requirements Process During the process “Update Customer” system responses should be no more than 1 second.
Precision Requirements Data Time of changes to data must be recorded to the nearest second.
Redundancy Requirements Process In the event of an unplanned exist from “Update Customer” the user can choose to restore the update to the customer they were working on at the time of the event.
Reliability Requirements Process “Update Customer” will be available to users 98% of normal working hours.
Scalability Requirements Process Up to 200 new sites per year may start to use “Update Customer”.
Security Requirements Both Process: Only users holding the role “Customer Advisor” or “Supervisor” can access “Update Customer”.
Data: Only users holding the role “Supervisor” can update customer Date of Birth.
Stress Requirements Process Up to 10 users may access the customer details concurrently during “Update Customer”.
Supportability Requirements Process The Customer Advisor Help desk will support users of “Update Customer” from 09:00 to 17:00 daily on weekdays only excluding public holidays.
Throughput Requirements Process “Update Customer” may apply up to 3,000 updates per working day.
Etc, etc, etc! Both! Process: Blah, blah, blah!
Data: Ya-de-ya!

Cause and Effect Analysis

Identifying the Likely Causes of Problems

(Also known as Cause and Effect Diagrams, Fishbone Diagrams, Ishikawa Diagrams, Herringbone Diagrams, and Fishikawa Diagrams.)

When you have a serious problem, it’s important to explore all of the things that could cause it, before you start to think about a solution.

That way you can solve the problem completely, first time round, rather than just addressing part of it and having the problem run on and on.

Cause and Effect Analysis gives you a useful way of doing this. This diagram-based technique, which combines brainstorming with a type of Mind Map, pushes you to consider all possible causes of a problem, rather than just the ones that are most obvious.

About the Tool

Cause and Effect Analysis was devised by professor Kaoru Ishikawa, a pioneer of quality management, in the 1960s. The technique was then published in his 1990 book, “Introduction to Quality Control.”

The diagrams that you create with are known as Ishikawa Diagrams or Fishbone Diagrams (because a completed diagram can look like the skeleton of a fish).

Although it was originally developed as a quality control tool, you can use the technique just as well in other ways. For instance, you can use it to:

  • Discover the root cause of a problem.
  • Uncover bottlenecks
  • in your processes.
  • Identify where and why a process isn’t working.

How to Use the Tool

Follow these steps to solve a problem with Cause and Effect Analysis:

Step 1: Identify the Problem

First, write down the exact problem you face. Where appropriate, identify who is involved, what the problem is, and when and where it occurs.

Then, write the problem in a box on the left-hand side of a large sheet of paper, and draw a line across the paper horizontally from the box. This arrangement, looking like the head and spine of a fish, gives you space to develop ideas.


In this simple example, a manager is having problems with an uncooperative branch office.

Figure 1 – Cause and Effect Analysis Example Step 1

Tip 1:

Some people prefer to write the problem on the right-hand side of the piece of paper, and develop ideas in the space to the left. Use whichever approach you feel most comfortable with.

Tip 2:

It’s important to define your problem correctly. CATWOE can help you do this – this asks you to look at the problem from the perspective of Customers, Actors in the process, the Transformation process, the overall World view, the process Owner, and Environmental constraints.

By considering all of these, you can develop a comprehensive understanding of the problem.

Step 2: Work Out the Major Factors Involved

Next, identify the factors that may be part of the problem. These may be systems, equipment, materials, external forces, people involved with the problem, and so on.

Try to draw out as many of these as possible. As a starting point, you can use models such as the McKinsey 7S Framework (which offers you Strategy, Structure, Systems, Shared values, Skills, Style and Staff as factors that you can consider) or the 4Ps of Marketing (which offers Product, Place, Price, and Promotion as possible factors).

Brainstorm any other factors that may affect the situation.

Then draw a line off the “spine” of the diagram for each factor, and label each line.


The manager identifies the following factors, and adds these to his diagram:

  • Site.
  • Task.
  • People.
  • Equipment.
  • Control.

Figure 2 – Cause and Effect Analysis Example Step 2


Step 3: Identify Possible Causes

Now, for each of the factors you considered in step 2, brainstorm possible causes of the problem that may be related to the factor.

Show these possible causes as shorter lines coming off the “bones” of the diagram. Where a cause is large or complex, then it may be best to break it down into sub-causes. Show these as lines coming off each cause line.


For each of the factors he identified in step 2, the manager brainstorms possible causes of the problem, and adds these to his diagram, as shown in figure 3.

Figure 3 – Cause and Effect Analysis Example Step 3

Step 3: Identify Possible Causes

Now, for each of the factors you considered in step 2, brainstorm possible causes of the problem that may be related to the factor.

Show these possible causes as shorter lines coming off the “bones” of the diagram. Where a cause is large or complex, then it may be best to break it down into sub-causes. Show these as lines coming off each cause line.


For each of the factors he identified in step 2, the manager brainstorms possible causes of the problem, and adds these to his diagram, as shown in figure 3.

Figure 3 – Cause and Effect Analysis Example Step 3

Step 4: Analyze Your Diagram

By this stage you should have a diagram showing all of the possible causes of the problem that you can think of.

Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. This may involve setting up investigations, carrying out surveys, and so on. These will be designed to test which of these possible causes is actually contributing to the problem.


The manager has now finished his analysis. If he hadn’t looked at the problem this way, he might have dealt with it by assuming that people in the branch office were “being difficult.”

Instead he thinks that the best approach is to arrange a meeting with the Branch Manager. This would allow him to brief the manager fully on the new strategy, and talk through any problems that she may be experiencing.


A useful way to use this technique with a team is to write all of the possible causes of the problem down on sticky notes. You can then group similar ones together on the diagram.

This approach is sometimes called CEDAC (Cause and Effect Diagram with Additional Cards) and was developed by Dr. Ryuji Fukuda, a Japanese expert on continuous improvement.

Key Points

Professor Kaoru Ishikawa created Cause and Effect Analysis in the 1960s. The technique uses a diagram-based approach for thinking through all of the possible causes of a problem. This helps you to carry out a thorough analysis of the situation.

There are four steps to using the tool.

  1. Identify the problem.
  2. Work out the major factors involved.
  3. Identify possible causes.
  4. Analyze your diagram.

You’ll find this method is particularly useful when you’re trying to solve complicated problems.

To conclude, all the techniques mentioned above are useful and must be known to a business analyst who wants to practice best business analysis techniques. Moreover, these techniques are emphasized explicitly in any industry recognized business analysis certification like IIBA Certifications like CCBA, ECBA, CBAP, and PMI-PBA.