Back to Blog

What is Business Analysis?

Image of LN Mishra, CBAP, CBDA, AAC & CCA

Business analysis has become an integral part of the most progressive organizations which would like to improve their performance using information technology. Major reasons why organizations start a business analysis process would be:

  1. To solve some of the problems in their existing business processes.
  2. Trying to exploit an opportunity available in the market.

Business Analysis process offers insights into the development of the initial framework for any project. It has the key to guide stakeholders of a project. In this Business Analysis blog, we will learn:

  • What is Business analysis?
  • Steps involved in Business Analysis Process
  • Common Business Analysis Techniques

Let us look at few definitions available to us for business analysis:

Defining Business Analysis

As per Business Analysis Body of Knowledge® (BABOK® Guide) from IIBA®,

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. It is a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits. Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change.”

As per Wikipedia,


Although there are different definitions, depending upon the organization, there does seem to be an area of common ground on business analysis. The most common business analysis projects involve:

  1. Investigating business systems with a holistic view of the situation. Often includes examining elements of the organisation structures and staff development issues as well as current processes and IT systems.
  2. Evaluating actions to improve the operation of a business system. Again, this may require an examination of organizational structure and staff development needs, to ensure that they are in line with any proposed process redesign and IT system development.
  3. Documenting the business requirements for the IT system support using appropriate documentation standards.

Business analysis professionals are adopting business analysis certifications to enhance their careers. Bring your career one level up with the Business Analysis certifications.

Business Analysis Tasks

The set of tasks and techniques that are used to perform business analysis are defined in the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). We have listed all the tasks in BABoK in a subsequent section. Unfortunately, BABoK does not give a definite business analysis process definition. It is rightly so because the situations are different, organizations are different, needs are different. Trying to propose a business analysis process in such varied conditions can really be a nightmarish approach.

At the same time, applying Pareto’s principle, it will be prudent to say that in about 80% of the situations, we can propose a solid business analysis process. For remaining 20% cases, of course, we need expert guidance and need to design custom process. We are proposing a 10-step approach to business analysis. We propose following 8 steps business analysis process.

The Definitive BA Process

1. Plan, Engagement, and Monitor

There are certain activities which run across the business analysis life cycle. This is numbered as 0 as it is the foundation for the remaining phases. Phase 0 will involve continuous planning, monitoring, engaging stakeholders, managing issues, risks, requirements, traceability. For every phase, we should perform appropriate level of planning and monitoring.

  1. Create a task plan

It is extremely important that you create a task plan for yourself and monitor your progress on your task plan. A task plan works like a compass for you.

  • Identifying the timelines for completing the business analysis deliverables.

Make Yourself Familiar with Domain

As Business analysts or as project team members, we must understand the business domain. Now one would not have experience in a domain unless one works in the domain. So, this seems to be a chicken and egg problem. So how can we learn a new domain quickly? Here are few tips that can help all of us:

  1. Learn vocabulary for the domain

I would consider this as the most crucial journey. Most businesses fundamentally do lots of things which are common. However, they use the terminology which could be very different from another domain. So, once you start appreciating what the terminologies mean, then it becomes much easier for you to understand and communicate with stakeholders. If you are comfortable with the language of business, business becomes comfortable with you.

  1. Refer basics of domains on

This is a website I find I find very useful, where one can learn basic tasks that companies perform in various domains. If you visit the process classification framework provided on, you will see process definitions for at least about 25 domains. You may not get an exact domain, but you will definitely find something close to your domain.

  1. Read a fundamental book on the domain

Most domains have a fundamental book written by a prominent author. Usually these books are called as handbook of the domain. For example, you can look at handbook of Banking, or Handbook of insurance, or Handbook of retail. Such books are a very good primer for what happens in the particular domain so if you are planning to join a particular domain. Please buy the paper copy of the book and go through it thoroughly.

  1. Identify resources on internet

Internet is a great source of information. Find authoritative websites which describe about a particular domain that would be very helpful for you to learn the new domain. Only challenge with internet-based learning is that internet is a vast information source, so you have to be really careful not to get deluged in the vast amount of information on internet. I still prefer books for initial reading.

  1. Identify people with domain knowledge

This is another great way to learn a new domain. Try to be in friendly terms with them. They would know lot of tips and tricks and they also may have information resources which could be invaluable for you. I remember when I was working as a Consultant for Change management, I developed good friendship with a senior colleague of mine in my organisation who had tremendous knowledge in change management consulting. I got books and materials from him which was a great help for me in my project.

  1. Be familiar with any of requirements modeling and management tools

Most clients use some tools for requirements modeling and management tools, the most prominent ones being MS Visio and Jira. Make yourself comfortable with the same.

Must ReadList of 10 Best Business Analysis Tools

2. Understand Project Context, Objectives, and Scope

Often business analysts are expected contribute as soon as possible towards project delivery. Often, the project may have started already, or a phase may be completed. As business analysts, it’s our job to clarify the business and project objectives as quickly as possible. Investing some time, whether that’s a few hours or few days, to get oriented will ensure we are not only moving quickly but also competent, effective and confident contributor for the project.

Our key responsibilities in this step include:

  • Plan for understanding the client, project objectives, context, and scope
  • Understanding the project history so that we do not repeat work that’s already been done.
  • Understanding the existing systems and business processes so we have a reasonably clear picture of the current process or system that needs to change.
  • Understand domain and organization vocabulary
  • Understand project objectives and scope.
  • Meet key stakeholders – Sponsor, Project Manager, Domain Subject Matter Experts, and Implementation Subject Matter Experts.
  • Understand project documentation standard to deliverables that meet stakeholder needs.
  • Understand scope and constraints on the project.
  • Develop clear scope statement to validate stakeholder requirements against project scope.
  • Get to understand the solution approach from the sponsor.
  • Learn tools to be used to in the project for requirements management.

This step gets we the information we need to be successful and effective in the context of this particular project.

3. Elicit Stakeholder Requirements

Your key responsibilities in this step include:

  • Plan to understand the process and expectations in detail from various stakeholders to understand their expectations from the solution.
  • Identify stakeholders who are in best position to provide the requirements.
  • Choose appropriate techniques to conduct elicitation activities.
  • Conduct elicitation sessions.
  • Elicit both functional and non-functional requirements, normal and exception requirements.
  • Confirm elicitation results with stakeholders and other sources of requirements.

4. Get Requirements Approved


Your key responsibilities in this step include:

  • Plan for managing requirements elicitated from various sources.
  • Define a requirements prioritization approach and get it approved by Sponsor / PM.
  • Prioritize requirements.
  • Verify alignment to scope.
  • Get requirements approved from competent authorities.

5. Develop Detailed Requirements Specifications

Detailed requirements provide the implementation team with the information they need to implement the solution. Your key responsibilities in this step include:

  • Plan for developing detailed requirements specifications.
  • Develop requirements models.
  • Develop detailed specifications.
  • Ensure quality of requirements specified.
  • Reviewing and validating detailed specifications with appropriate business and technology stakeholders and filling in any gaps.

Also Read: 10 Most Popular Business Analysis Techniques

6. Support Implementation SMEs


Your key responsibilities in this step include:

  • Engage with implementation team to explain detailed requirements.
  • Ensure the solution design fulfills all of the detailed requirements
  • Review test plans and/or test cases to ensure they cover both functional and non-functional requirements.
  • Develop transition requirements.
  • Be available to resolve issues surfacing during the technical design, technical implementation, or testing phases of the project.
  • Training end users / working with the learning instructors to ensure end users understand all process and system changes
  • Collaborating with organizational process designers to update organizational assets impacted by the business process and technology changes.

7. Evaluate and Improve Solution Performance

A track record of successful projects creates significant positive momentum within an organization. So, if we need to assess the value created by the solution.

Your key responsibilities in this step may include:

  • Evaluating the results achieved against the business objectives for the project to show the extent to which the original objectives have been fulfilled.
  • Communicating the results to the all the stakeholders.
  • Participating in the project closure activities.
  • Recording one’s personal learnings from the project for future reference.
  • Celebrating the success of your hard work, commitment and the success of the project.

Common Business Analysis Techniques


Functional decomposition

Functional decomposition breaks down a large aspect (processes, functional areas, deliverables, scope, or problems) into smaller aspects, as independent as possible, so that work can be assigned to different groups. This reduces complexity of analysis.


Estimation techniques are used for better understanding of possible range of costs and efforts associated with any change.

Interface analysis

An interface is a connection between 2 components or solutions. Identify interfaces and interactions between solutions and/or solution components.

Organizational modelling

Org. modelling describes roles, responsibilities, and reporting structures that exist within an organization, and aligns those structures with organization’s goals. Visual representations of organizational units.

Stakeholder list, map, or personas

Identify stakeholders affected by a proposed initiative or share a common business need, level of decision-making authority, authority within domain and organization, attitude/ interest towards change, and business analysis work.

Scope modelling

Describe scope of analysis or scope of a solution. They serve as a basis for defining and limiting scope of business analysis and project work


One or group of stakeholders deliberate on an idea to produce numerous new ideas in a non-judgmental environment, and to derive themes for further analysis.


Requirements workshop, also known as JAD (Joint application design) session, is a highly productive focused event attended by carefully selected key stakeholders, and Subject Matter Experts for a short, intensive period (typically 1 or a few days).

Aspired to start or advance your career in Business Analysis? Choosing one of these Best Business Analysis Certifications will help you stand out!

Focus groups

Elicit ideas, impressions, preferences, and needs and attitudes from pre-qualified individuals about a specific product, service or opportunity in an interactive group environment. Guided by a moderator. Typically 1 to 2 hours with 6-12 attendees.

Collaborative games

Uses game playing techniques to collaborate in developing common understanding of a problem or a solution. Involves strong visual or tactile (activities) elements such as moving sticky notes, writing on whiteboards, or drawing pictures.


Most common form of elicitation technique where interviewers ask questions to stakeholders. Effective interviewers control discussions understand needs from ALL stakeholders, probe deeper when needed and ensure completeness of answers.


Elicit information by observing activities and their contexts.

Survey or questionnaire

Administers a set of written questions to stakeholders and Subject Matter Experts. Survey can elicit information from many people, sometimes anonymously, in a relatively short period of time. Can collect information about customers, products, work practices and attitudes. Alternatively, respondents are provided with a series of statements and asked for their level of agreement.

Document analysis

Elicit Business Analysis information, by examining materials describing business environment or organizational assets. Document analysis helps in understanding context of a business need or understanding how existing solutions are implemented. Based on Business Analysis information being explored, purpose, scope, and topics to be researched are determined.

Benchmarking and market analysis

Benchmarking compares org. practices against best-in-class practices from competitors, government, industry associations or standards. Market analysis understands customers’ needs, factors influencing purchase decisions, and studies competitors.


Provides an early model of final result, widely used for product design. Details UI requirements and integrates them with other requirements such as use cases, scenarios, data, and business rules. Stakeholders often find prototyping to be a concrete means of identifying, describing, and validating their interface needs. Prototypes can discover desired process flow and business rules.


Comprises of key terms relevant to a business domain to provide a common understanding of terms. Contains definitions and synonyms. Needs to be organized and be accessible to all stakeholders.

Mind Map

Articulates and captures ideas in a non-linear (tree) structure. Ideas are grouped as topics, sub-topics, further sub-sub-topics. Mind maps use words, images, color, and connections to structure thoughts, ideas, and information.

Backlog management

Backlogs record, track and prioritize remaining work items. Backlog management is a planned approach to manage remaining work for project. In managed backlogs, items at top have highest business value and priority. Backlog items can be user stories, use cases, defects, CRs, risks etc.

Business rules analysis

Business policies dictate actions of an enterprise and people in it by broadly controlling, influencing, or regulating them. Business rules serves as a criterion for guiding behavior and making decisions in a specific, testable manner.

Lessons learned

Discusses and documents successes, failures and improvement recommendations for future phases or projects. Can include any format or venue that is acceptable to key stakeholders. Can be formal facilitated meetings or informal.


Provides a framework for stakeholder decisions to understand relative importance of requirements. Importance may be based on value, risk, difficulty of implementation etc.


Communicate, verify, and validate content of work products, formally or informally. Communicate review objectives in advance to participants.

Preparing for CBAP certification exam? Check your current level of preparation with CBAP Practice Tests. Start with CBAP free test now!

Item tracking

Captures and assigns responsibility for issues and stakeholder concerns. Items can refer to actions, assumptions, constraints, dependencies, defects, enhancements, and issues.

Balanced scorecard

A strategic planning and management tool to measure org. performance beyond traditional financial measures aligned to organization's vision and strategy.

Business capability analysis

Capability maps provide a graphical view of capabilities. Capabilities describes ability of an enterprise to act on or transform something that helps achieve a business goal or objective. Capabilities describe outcome of performance or transformation, not how it is performed.

Business cases

Formally or informally, justify investments based on estimated value compared to cost. Spend time and resources on business case proportional to the size and importance of its potential value. Business cases do not provide intricate details.

Business model canvas

Comprises 9 building blocks describing how an organization intends to deliver value. As a diagnostic tool, use elements of the canvas as a lens into current process or system of business, especially wrt relative amounts of energy, time, and resources currently invested in various areas.

Decision analysis

Supports decision-making in complex, difficult, or uncertain situations. Examines and models possible consequences of different decisions.

Decision modeling

Shows how repeatable business decisions are made using data and knowledge.

Financial analysis

Explore financial aspects (benefits and costs) of an investment.

Risk analysis and management

Identify, analyze, and evaluate uncertainties that could negatively affect value, develop and manage way of dealing with risks.

SWOT analysis

SWOT is an acronym for Strengths, Weaknesses, Opportunities, and Threats. A framework for strategic planning, opportunity analysis, competitive analysis, business, and product development.

Concept modelling

Organizes business vocabulary, usually starting with glossary.

Preparing for ECBA certification exam? Check your current level of preparation with CBAP Practice Tests. Start with ECBA free test now!

Data dictionary

Standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with ER diagrams.

Data modelling

Data model describe entities, classes or data objects relevant to a domain, their attributes and relationships among them.

Data flow diagrams

Show transformation of data from (data source such as external sources, activities and destination). Data used in DFDs should be described in a data dictionary. Highest level diagram (Level 0) is context diagram represents the entire system.

Process modelling

Graphical model to describe sequential flow of activities. A system process model defines sequential flow of control among programs or units within a computer system. A program process flow shows sequential execution of program statements within a software program.

Sequence diagrams

Sequence diagrams (also known as event diagrams) model logic of usage scenarios, by showing information (also known as stimuli, or message) passed between objects during execution of a scenario.

State modelling

State models (also sometimes called a process or system transition model) describe and analyze different possible states (formal representation of a status) of an entity within a system, how that entity changes from one process or system to another and what can happen to entity when it is in each state.

User stories

User stories are a brief textual description, typically 1 or 2 sentences, of functionality that users need from a solution to meet a business objective. User story describes actor (who uses story), goal they are trying to accomplish, and any additional information to be critical to understanding scope of story.

Use cases and scenarios

Scenarios, and use cases describe how actors (a person or a system) interacts with a solution to accomplish one or more of that person or systems goals.

Non-functional requirements analysis

Examines requirements for a solution that define how well functional requirements must perform. Also known as quality attributes or quality of service requirements. Expressed in textual formats as declarative statements or in matrices.

Roles and permissions matrix

Ensure coverage of activities by denoting responsibility, to identified roles, and to discover missing roles.

Acceptance and evaluation criteria

Acceptance criteria describe minimal set of requirements to be met for a solution to be worth implementing, also known as Must Have requirements. Typically used when evaluation only one possible solution and is expressed as pass or fail. Must be testable.

Metrics and key performance indicators (KPIs)

Measure performance of solutions, solution components and other matters of interest to stakeholders. A metric is a quantifiable level of an indicator to measure progress. A target metric is objective to be reached within a specified period.

Process analysis

Analyzes processes for their effectiveness, efficiency, and identifies improvement opportunities.

Root cause analysis

Identify and evaluate underlying causes of a problem, looking into causes occurring due to people, physical or organizational effects.

Vendor assessment

Assess ability of a potential vendor to meet commitments wrt delivery and consistent provision of a product or service.

Data mining

Finds useful patterns and insights from large amounts of data, usually resulting in mathematical models. Utilized in either supervised (user poses a question) or unsupervised (pure pattern discovery) investigations.

Preparing for CCBA certification exam? Check your current level of preparation with CBAP Practice Tests. Start with CCBA free test now!


Most is a short form of Mission, Objectives, Strategies. It allows business analysts to perform thorough internal analysis of what is the aim of an organization to achieve and how to tackles such issues.


Pestle stands for (Political, Economic, Sociological, Technological, Legal, and Environmental). This model helps business analysts to evaluate all the external factors which can possibly impact their organization and determine how to address them.


SWOT is a full form of Strengths, Weaknesses, Opportunities, and Threats. This technique helps we to find areas of both strength and weakness. It also allows for the proper allocation of resources.


Must or Should, Could or Would process is a long-form of MosCow. This technique allows prioritization of requirements by presenting a framework in which every individual requirement should be evaluated relative to the others.


CATWOE is an acronym for Customers, Actors, Transformation Process, World View, Owner, and Environmental. This technique helps we to recognize processes that may be affected by any action the business undertakes.

The 5 Whys

This technique is a backbone of both Six Sigma and business analysis techniques. It consists of leading questions that allow business analysts to single out the root cause of an issue by asking why such a situation arises.

Six Thinking Hats

This process helps we to consider alternate perspectives and ideas. The 'six hats' in a technique which his categorized as:

  • Green (creative thinking)
  • Blue talk about big-picture overview.
  • White (logical, data-driven thinking)
  • Yellow (positive thinking, which mainly focused on pros)
  • Red (emotion-based reactions)
  • Black (opposing thinking, which is focused on cons)


This is used to perform an in-depth analysis of early stage businesses/ventures on seven important categories. Market opportunity, Product/solution, Execution plan, Financial engine, Human capital, Potential return and Margin of safety.


Is essentially another take on PESTLE. we will notice it factors in the same elements of PESTLE and shouldn't be considered a tool on its own except an author/user prefers to use this acronym as opposed to PESTLE. STEER puts into consideration – the following Socio-cultural, Technological, Economic, Ecological, and Regulatory Factors.

de Bono's Six Thinking Hats

This is often used in a brainstorming session to generate and analyze ideas and options. It is useful to encourage specific types of thinking and can be a convenient and symbolic way to request someone to "switch gears". It involves restricting the group to only thinking in specific ways – giving ideas & analysis in the "mood" of the time. Also known as the Six Thinking Hats. White: Pure facts, logical. Green: Creative. Yellow: Bright, optimistic, positive. Black: Negative, devil’s advocate. Red: Emotional. Blue: Cold, control.


This technique is used when analyzing the expectations of multiple parties having different views of a system in which they all have an interest in common but have different priorities and different responsibilities.

Values – constitute the objectives, beliefs and concerns of all parties participating. They may be financial, social, tangible, and intangible

Policies – constraints that govern what may be done and the manner in which it may be done

Events – real-world proceedings that stimulate activity

Content – the meaningful portion of the documents, conversations, messages, etc. that are produced and used by all aspects of business activity

Trust – between users of the system and their right to access and change information within it.

SCRS approach

The SCRS approach in business analysis claims that the analysis should flow from the high-level business strategy to the solution, through the current process or system and the requirements. SCRS stands for: Strategy, Current State, Requirements, and Solution.

Final words

Along with the proper business analyst interview questions and answers preparation, an industry-recognized business analysis certification can make your hiring process easier. Because a certification makes your credibility beyond question.

Certifications like ECBACCBA, and CBAP provide the excellent roadmap for business analysts to learn best business analysis practices. However, these are very vast courses which need in-depth, hands-on knowledge of the subject areas.

Adaptive US makes your life easy with its well-researched practice exam simulators to crack above mentioned certification exams which are considered the toughest exams among the professional certifications. Additionally, the practice tests will provide you more exposure to tricky business analyst interview questions.

So, if you are an aspiring business analyst, why not try the certification path?

Join us today and explore the dream career as a business analyst!

Please find below an exhaustive description on IT Business Analysis


1. IT Business Analysis concepts

1.1 Defining business

A business is defined as an organization or enterprising entity engaged in commercial, industrial, or professional activities. The term business refers to the organized efforts and activities of individuals to produce and sell goods and services for profit. Businesses range in scale from a sole proprietorship to an international corporation. Several lines of theory are engaged with understanding business administration including organizational behavior, organization theory, and strategic management. People have conducted business since ancient times; historically, businesses have involved mercantile operations, trade guilds, or shared agricultural production.

1.2 Defining analysis


Analysis helps us to understand complex topics better. Typically, in a business environment, we analyze business problems, opportunities, existing processes, solutions etc. Our focus in this book is business needs (problems or solutions) which can be effectively addressed using the capabilities of information technology (IT).

1.3 Defining IT

Information technology refers to use of computers and networks to benefit business activities. Most IT system will have hardware, software and networking component. Since vast majority of IT Business Analysts work in the application software development projects, hence we will focus on the same.

1.4 Software Development Process




1.5 Defining needs and requirements

Needs are essentially problems or opportunities in front of business. Problems reduce organization’s earning potential whereas opportunities help to increase earning potential. IEEE defines requirements as:


* A condition or capability to be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.

* A requirement may be unstated, implied by or derived from other requirements, or directly stated and managed. One of the key objectives of IT Business Analysis is to ensure requirements are visible to and understood by all stakeholders.

Requirements describe, but not limited to, past, present and future conditions or capabilities in an enterprise, organizational structures, roles, processes, policies, rules and information systems. Requirements should be at the level of depth necessary for clarity and implementation.

1.6 Types of requirements

Functional requirements

Functional requirements (FRs) describe abilities of a system that are important to user community. These are functionalities offered by the system. Sample examples of functional requirements are “Manage customer”, “Manage order”, “Manage employees” etc.

Categories of functional requirements are:

User interface perspective: (UI)

In the UI perspective, interactions between users and application are described.

Data perspective: (Data)

In the data perspective, data aspects are described.

Functional perspective: (Logic)

Functional perspectives describe data flows or logic flows of the system.

Behavioral perspective: (State)

In the behavioral perspective, statuses of data elements are described.

Non-Functional requirements

The umbrella term “non-functional requirement” is often used for quality requirements and constraints. Quality requirements describe qualities of a system that are important to:

* User community, such as usability, learnability, reliability, etc.

* Development community, such as scalability, maintainability, reusability, etc.

Quality requirements often influence the system architecture more than functional requirements do. Quality requirements must be documented explicitly. Quality requirements should be traceable to business needs and other requirements. Include appropriate measures for NFRs to be testable.

Quality requirements are mostly documented using natural language. For example:

90% of users shall be able to use basic functions of the system within 6 hours of training. The system shall provide 90% of responses in less than 5 seconds.


Time taken to perform activities and resource utilization levels.


Ability to ensure appropriate confidentiality and integrity of information, to verify when actions were taken and by whom and to authenticate users.


Measure of application being available when needed. Includes ability of the application to recover from errors, uptime, or failures in interfaces.


The system being usable by target audience with specified duration of training.


Ability to change one component without affecting others and without causing unexpected failures, ability to re-use components and testability.

Portability, also known as Transferability

Ease of installing and uninstalling the application, different environments it can run and ease of migrating it to a new environment.

A useful mnemonic: CRM POST (Compatibility, Reliability, Maintainability, Performance efficiency, Operability, Security and Transferability)


Constraints are aspects which the project team cannot influence or modify. (e.g., “The system shall be implemented using .net”) or the time frame (“The system shall be available by fourth quarter of 2015”). Constraints are not implemented; they are adhered to. Constraints limit the solution options (which is actually a good thing else we will have large number of solution options to deal with). Constraints influence IT Business Analysis planning, execution and techniques. In addition to the above classifications, requirements may be classified based on requirement attributes, such as the levels of detail, priorities, or legal obligations.


1.7 Defining IT Business Analysis

IT Business Analysis is a systematic and disciplined approach to identify, specify and manage requirements with the following goals:

* Understanding and documenting the stakeholders’ desires and needs, specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.

* Knowing relevant requirements, achieving a consensus among the stakeholders about them, documenting them according to given standards and managing them systematically.

Business Analysts analyze and synthesize information provided by customers, staff, IT professionals and executives. They elicit the actual needs of stakeholders, not simply capture their expressed desires. IT Business Analysis activities may be performed in many job titles or organizational roles.

IT Business Analysis practitioners include Business Analysts, business systems analysts, systems analysts, product managers, product owners, enterprise analysts, business architects, management consultants and interaction design professionals.

1.8 Need for good IT Business Analysis

As per a study by TechRepublic (, it is estimated that around 68% of projects fail due to poor IT Business Analysis. Majority of customer expectation mismatches can be attributed to poor requirements. Hence, it is extremely essential that we focus on identifying and documenting complete requirements for all projects.

As per the TechRepublic study mentioned above, two third of system errors in production are due to requirements errors. Developers develop solutions as per their understanding of requirements. Unclear, incomplete, or wrong requirements lead to development of wrong solutions.

Complete and correct requirements are the basis for successful system development. Discovering gaps in requirements early avoids tedious change control processes.

Symptoms of poor IT Business Analysis

Key symptoms for inadequate IT Business Analysis are:

* System not used,

* User dissatisfaction with developed system,

* System not meeting stakeholder needs,

* Features needed by stakeholder not needed getting implemented.

* Work executed though workarounds.

Causes of poor IT Business Analysis

Most common reasons for poor requirements are:

* Assumption that requirements are obvious and hence need not be stated explicitly,

* Improper communication from stakeholders to Business Analysts and then to designers and developers,

* Tendency to begin design and coding to speed-up the project implementation without proper requirements gathering,

* Inadequate time allotted for IT Business Analysis,

* Lack of appropriate skills for requirements elicitation,

* Inadequate templates available for requirements elicitation,

* Inadequate level of detailing needed for solution requirements.

Please watch a very interesting video on problems with requirements


1.9 IT Business Analysis – Major Activities


During planning, Business Analysts understand system objectives, scope, boundary and plan for resources and activities.


Elicitation means to “Understand underlying needs” and “To draw forth – to enquire till all necessary information are obtained”. Key objectives for elicitation are:

* Elicit requirements from stakeholders and other sources using different elicitation techniques.

* Elicit various attributes of requirements.


During analysis, Business Analysts organize, prioritize and model requirements. They also verify and validate requirements.


Requirements management is an ongoing activity which spans across all other requirements activities.

Key objectives for requirements management are:

* Manage requirements from creation till decommissioning of requirements,

* Manage requirements changes, conflicts and issues.


1.10 Responsibilities of Business Analysts

* Understand business domains as well as technology domains,

* Act as the connecting links between business stakeholders and technology implementation stakeholders,

* Plan IT Business Analysis activities in collaboration with stakeholders,

* Speak the language of the stakeholders,

* Be able to communicate requirements (e.g., by means of diagrams and graphs),

* Create requirements documents,

* Maintain respectful relationships with stakeholders,

* Present ideas and alternatives as well as their realizations,

* Make systems user-friendly and simple,

* Ensure systems satisfy functional and non-functional requirements,

* Plan and organize requirements communications,

* Take additional responsibilities towards Domain SME, Project Manager, and Tester if needed.

Business Analyst is a key project role. Usually they are the ONLY ones who are in contact with all the stakeholders, from sponsor, to Domain SMEs and Implementation SMEs. Business Analysts need more than only IT Business Analysis process knowledge. 3 key skill areas for Business Analysts are behavioral, process and technical.

They MUST acquire following skills:



Communication skills

Good communication skills are essential to elicit requirements, and communicate them in a suitable manner. Business Analysts must be able to listen, ask right questions at right time, notice when a statement does not contain desired information and make further inquiries when necessary.

Knowledge of documentation and presentation tools

Business Analysts MUST become familiar with documentation and presentation tools.

Knowledge of modeling tools

Business Analysts MUST become familiar requirements modeling tools and techniques. Requirements modeling techniques help in reducing requirements ambiguity.

Analytical thinking

Analytical thinking allows Business Analysts to group and analyze requirements at the right level.


Empathy for people helps in building personal connects with stakeholders.

Conflict resolution skills

Conflicts are common during IT Business Analysis. They could be due to differing opinions among stakeholders with respect to value, priority of requirements. Business Analysts MUST identify and record conflicts, and use suitable techniques to resolve conflicts.

Moderation / Facilitation skills

Business Analysts must be able to mediate between different opinions and lead discussions during individual and group conversations. They should anticipate problems that might arise in such situations and act accordingly. They MUST be able to represent requirements in different fora. They MUST consolidate differing opinions, facilitate a decision in case of disagreements and create consensus among the stakeholders.


Business Analysts are exposed to criticisms as well. They need high level of self-confidence and should have the ability to defend themselves. They should NEVER take criticism personally.

Ability to convince

Business Analysts should be able to convince stakeholders the need to prioritize requirements as per agreed upon criteria and need for realizing maximum value from requirements in shortest possible time.


2. IT BA Vocabulary


Absolute reference

Unique identifier of a requirement to be maintained even if requirement is moved, changed or deleted.

Acceptance criteria

Minimal set of requirements to be met for a particular solution to be acceptable to stakeholders.

Active/visible observation

Observer observes the current process and takes notes, interacts with the user while work is being performed.


A unit of work performed.

Activity diagram

Diagram showing sequence of activities.


Any person, system, or event that interacts with the system.

Additional potential capabilities

Capabilities offered by solution beyond those specified.


One type of software development life cycle.


See requirements allocation.


Stakeholder responsible for analysis.


High level plan to execute any task.


Manner in which components of system are organized.


Relationship between two elements or objects in a diagram, such as between classes and use cases.

Atomic level

At lowest level


Defines information associated with a concept.

Auditory learners

Stakeholders who learn best through oral communication.



Business analyst / Business analysis


A point-in-time view of requirements which have been reviewed and agreed upon. Serves as the basis for further development.


Comparing a process or application's cost, time, quality, or other metrics to those of best in class process or applications to identify opportunities for improvement.


Business intelligence - Analyzing business data to draw inferences.

Black box tests

Tests conducted using expected inputs and outputs.


Business process re-engineering - To modify business processes from scratch.



Business constraints

Business limitations placed on the solution design such as schedule, budget etc.


Data dictionaries or glossaries

Identify and define critical terms used by the organization or organizational unit.

Data entity

Group of related information to be stored in the system.

Data flow

Describes how data movement between a data process and an external entity, a data store or another data process.

Data flow diagram (DFD)

Diagrams data processes. See data flow.

Data model

Diagram depicting logical structure of data, independent of the data design or storage mechanisms.

Data process

A process that transforms the data in some way, either combining, reordering, converting, filtering etc.

Decision analysis

Decision-making approach modeling possible consequences of different decisions under conditions of uncertainty.

Decision tables

Tables expressing complex business rules or logic concisely in an easy-to-read tabular format, specifying all of the possible conditions and decisions.

Decision tree

A graphical representation illustrating conditions and outcomes.

Deep structure

Actual needs of the stakeholder.


Deficiency in a product or service reducing quality.


Any work product or service that stakeholder has agreed to deliver.


Activities that have to be completed before subsequent tasks can begin.

Design constraints

Constraints placed on solution design.

Detailed logical data models

Describe complete descriptions of all entities, attributes and relationships.


Stakeholders responsible for the construction of software applications.


See Data flow diagram.

Dialog hierarchy

Diagram showing user interface dialogs arranged as hierarchies.

Dialog map

Diagram showing architecture of the system’s UIs.

Discovery session

See requirements workshop.

Dispersed stakeholders

Stakeholders located in different geographic regions or countries.

Document analysis

Analysis of existing documentation and documentation of competing products.



Elicitation involves understanding underlying needs from stated requirements of stakeholders. It also involves eliciting all necessary information for successful development of a system from all identified sources.

Elicitation workshop

See requirements workshop.

End user

A person or system that interacts with the solution.

Entity-relationship diagram

Graphical representation of entities relevant to a chosen problem domain, their attributes and relationships between them.


Something that occurs to which an organizational unit, system, or process must respond.

Event-based elicitation

Techniques that require in person interactions, such as brainstorming, focus group, interview, observation, prototyping, requirements workshop.

Event response table

A table defining events and their responses.

Evolutionary / functional prototype

A prototype that becomes the product.

Exploratory prototype

Prototype developed to explore requirements.

Extend use case

Extends additional behavior into a use case.

External interfaces

Interfaces with other systems (hardware, software and human) that a proposed system will interact with.



Skill of moderating discussions among a group.

Flow chart

A diagrammatic representation of activity or logic.

Focus group

Means to elicit ideas, attitudes and improvements about a specific product, service or opportunity in an interactive group environment.

Force field analysis

A diagram depicting forces supporting and opposing a change.


Function point – A method to compute software size based on the functionality provided by the software.


Functional specifications.

Functional requirements

Product capabilities or features.



A group with diverse participants.

High-level logical data models

Focusing on describing important entities, attributes and relationships.

Horizontal prototype

A prototype that shows a shallow and wide view of the system’s functionality. Does not support any actual interaction.


Impact analysis

Assessing effects of a proposed change on stakeholders, project, or system.

Implementation subject matter expert (SME)

Stakeholders responsible for designing, developing and implementing requirements.

Incremental delivery

Creating working software in multiple releases.


Various categories of businesses in economy, for example, retail, telecom, aviation etc.


Effort undertaken with a defined goal or objective.


Formal peer review utilizing a predefined and documented process, specific participant roles, captures defects and process metrics. Also see Structured walkthrough.


A shared boundary between any two entities (persons and/or systems).


Elicit information from stakeholders by asking relevant questions.


A set period of time in which a solution is progressively built.


One methodology for software development life cycle where working software is created in multiple releases.

JAD (Joint application design)

A session where client and solution team discuss requirements together. See requirements workshops.


JAD (Joint application design)



Key Performance Indicators (KPI)

KPIs measure progress towards a strategic goal or objective.



Lessons learned process

Learn about and improve a process or project. Also called Sprint retrospective in agile process.

Logical order

Order of priority/significance, for example, general questions to specific questions, start to finish, summary to, etc.


Matrix documentation (model)

Captures a set of requirements having a complex but uniform structure in tabular form.


Data about data.


Proven approach.


Quantifiable level of an indicator at a specific point in time.


Represent significant events in the progress of a project.


Synonym for proto-type.


Continuous process of collecting data to determine if the solution is performing in real world scenario. See also metric and indicator.


MoSCoW categorizes requirements into, Must Have, Should Have, Could Have and Wont Have.


See Cardinality.


Natural language

Expressed in spoken language


Converting a long-lasting activity or group of nouns into a single event or noun.

Non-Functional requirements (NFR) aka Quality or Supplementary requirements

Conditions under which the solution must remain effective.


Object oriented modeling

A software engineering approach where software is comprised of objects.


Eliciting requirements by observing stakeholder’s work environment.

On-going requirements

Requirements required to be maintained on an ongoing basis.


Object oriented - An approach to design systems with real-world concepts.


Object oriented analysis and design.

Open-ended question

Respondent is free to answer questions as he/she wishes.

Operational support

Stakeholders who provide support, such as trainers, help desk, network and other technical support personnel.

Operative rules

Rules intended to guide actions of stakeholders.


Defines whether there is a mandatory relationship between entities in a data model.

Oral communication skills

Verbally express ideas, and information.

Organizational change management professionals

Stakeholders responsible for facilitating adoption of new solutions and overcoming resistance to change.

Organizational process assets

Methods, policies and processes and artifacts created by the organization from past experiences and best practices.


Passive/invisible observation

Observer observes users working but does not interact with them.


Plan-Do-Check-Act, four phase approach to complete any activity. Also known as Deming cycle or Shewhart's cycle.

Peer review

Stakeholders evaluate a work product to discover errors in order to improve its quality.

Personal organization

Ability to quickly find information, timeliness, management of outstanding tasks and appropriate handling of priorities.

Physical data models

Description of how data is stored and managed in a system.


Approaches focusing on up-front minimizing uncertainty and fully defining solution before implementation begins.

Plan-driven methodology

Methodologies emphasizing planning and formal documentation.


Proof of concept - Activities carried out to check technical feasibility of an initiative.


Process, Organization, Location (Business architecture), Data, Applications, Technology (Systems Architecture)


Aspect to be true when the use case is complete.


Aspect to be true before the use case begins.

Preventive and corrective action


Primary actor

Actor who initiates the use case.

Primary or basic flow

Simplest way to accomplish the goal of the use case.


Determining relative importance among a set of items.

Process map

Model that shows a process.


A solution or its component.

Product backlog

A set of user stories, features or requirements identified for potential implementation, prioritized and estimated.

Product scope

Features and functions that characterize a product.


A temporary endeavor undertaken to create a unique product or service.

Project charter

A document that formally authorizes the existence of a project.

Project manager

Stakeholder to manage work required to achieve the project objectives.

Project scope

Work to be performed to deliver a project. See also scope.



Quality assurance – Activities carried out to ensure that the designed process will deliver quality products and services.


Quality control - Activities carried out to ensure the defective products are not delivered to customers.


Quality Management System.


Degree to which a set of inherent characteristics fulfils requirements.

Quality assurance

See QA.

Quality attributes

See Non-functional requirements.


See survey.


RACI (Responsibility-Accountability-Consulted-Informed) matrix

Describes stakeholders / roles for a given task or deliverable.


Alias scribe

Regression testing

Checking if the existing functionalities are affected due to introduction of new functionalities.


Stakeholder with legal or governance authority.

Release planning

Deciding requirements to be included in different releases.


A real or virtual facility where information is stored.

Request for information (RFI)

Document issued to obtain supplier input on a proposed process or product.

Request for proposal (RFP)

Requirements document issued when seeking a formal proposal from suppliers.

Request for quote (RFQ)

RFQs are used when the organization understands solution options available and is seeking suppliers to implement an option.

Requirement attributes

Metadata related to requirements used for requirements management.

Requirement defects

Errors in requirements caused by incorrect, incomplete, missing, or conflicting requirements.

Requirements allocation

Apportioning requirements to subsystems and components (i.e., stakeholders, hardware and software).

Requirements coverage

Tracing business objectives to detailed requirements such as business rules, data elements and use cases.

Requirements discovery session

See requirements workshop.

Requirements document

See requirements package.

Business Analyst, aka requirements analyst

A practitioner of IT Business Analysis.

IT Business Analysis

Systematic and disciplined approach to identify, specify and manage requirements.

Business Analysis approach

Overall process to be followed to perform IT Business Analysis work.

IT Business Analysis communication plan

Types of communication that Business Analysts perform.

IT Business Analysis performance assessment

Using prior experiences to determine effort involved in performing IT Business Analysis work.

IT Business Analysis plan

Includes information such as scope, work breakdown structure, activity list and estimates for each activity and task.

Requirements iteration

An iteration defining requirements for a subset of the solution scope.

Requirements management

Activities that control requirements development, including requirements change control, attributes definition and traceability.

Requirements management plan

Describes approach to be taken to structure traceability, definition of requirements attributes, requirements prioritization and change process.

Requirements management tool

Software tool that stores requirements information in a database, captures attributes and associations and facilitates reporting.

Requirements model

Representation of requirements using text and diagrams.

Requirements package

Requirements documents created for sharing with specific audience.

Requirements quality

See requirements verification.

Requirements repository

See repository.

Requirements risk mitigation strategy

Identify, prioritize and mitigate requirements-related risks.

Requirements signoff

Formal approval of a set of requirements.

Requirements trace matrix

A matrix tracking requirements’ relationships to other requirements and other deliverables.

Requirements traceability

Linking requirements to business objectives, other solution components and other requirements.

Requirements validation

Ensuring requirements are aligned to the goals and objectives of the business.

Requirements verification

Ensuring requirements are at an acceptable level of quality.

Requirements workshop

A structured meeting in which selected stakeholders define requirements.


See lessons learned process.

Return on investment

A measure of the profitability of a project or investment.



Series of actions to achieve a goal.


Area covered by a particular activity or topic of interest. See also project scope and solution scope.

Scope model

A model that defines scope boundaries.


Software Development Life Cycle.

Secondary actor

An actor who participates in a use case but does not initiate the same.


Work carried out or on behalf of others.


See requirements signoff.

Software engineers

Stakeholders responsible for construction of software applications.

Software/systems requirements specification

Requirements document describing detailed functional and non-functional requirements.

Solution requirement

Requirements described to develop a solution that meets the business and stakeholder requirements.

Solution scope

Set of capabilities a solution must deliver to meet business need.

Span of control

Number of employees a manger is responsible for.


Stakeholder who pays for the project.


Indicates how mature the requirement is.


A group or person who may be affected by an initiative or has influence over it.

Stakeholder analysis

To identify, prioritize, assess interests and likely participation of stakeholders for an initiative.

Stakeholder list, roles and responsibilities

List of stakeholders affected by a business need or proposed solution and their participation.

Stakeholder maps

Visual diagrams that depict relationship of stakeholders to the solution, their authorities and interests.

Stakeholder requirements

Statements of needs of a particular stakeholder or class of stakeholders.

State machine diagram, State transition diagram

See state diagram.

Stated requirements

Requirement described by stakeholders.

Status attribute

Indicates requirement status.

Structured walkthrough

A session where invited participants review a set of requirements/deliverables.

Subject matter expert (SME)

Stakeholder with specific expertise in any aspect of problem domain or potential solutions.

Surface structure

Requirement stated by the stakeholder


Administering a set of written questions to stakeholders to collect responses.

Swim lane

Horizontal or vertical section of a process model showing activities are performed by a particular role.


Technical constraint

Limitations on design of a solution based on technology used.

Throw-away prototype

A prototype used to quickly uncover and clarify interface requirements using simple tools and which is not used in final product.

Time box

A fixed period of time assigned for a purpose.


Act of linking requirements among them and also to other deliverables.



Use case point – A method to compute software size using use cases.

Unified modeling language (UML)

A non-proprietary modeling language used to specify, visualize and document requirements and designs for object-oriented software systems.

Universal quantifiers

Universal quantifiers group set of objects and generalize behavior or property for the group such as All, None etc..


Indicates how soon the requirement is needed necessary.

Use case diagram

A diagram showing actors and use cases for a system.

Use case (UC) specifications

Describes the tasks that the actors and system will perform for achieving a goal.


See end user.

User acceptance test

Testing carried out users to judge whether the delivered system is acceptable.

User requirement

See stakeholder requirements.

User requirements document

A requirements document prepared for a user audience.

User story

A short description of a solution capability described from a stakeholder perspective.


Validated requirements

Requirements that demonstrate delivery of business value.


Ensuring product or service satisfies its intended use.

Variance analysis

Analysis of differences between planned and actual performance parameters.


Ensuring deliverables produced at a given stage of development satisfies the conditions or specifications of the previous stage.

Verified requirements

Requirements that demonstrate characteristics of requirements quality.

Vertical prototype

A prototype that dives into the details of the interface, functionality, or both.



A review where participants present, discuss and go through a work product to find errors and verify correctness of requirements


Software development methodology where activities move from one phase to another.


Synonym for proto-type.

Work breakdown structure (WBS)

A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish the project objectives.

Work packages

Include at least one and usually many activities, which can be further broken into smaller tasks.

Work product

Document or collection of notes or diagrams created during the IT Business Analysis process.

3. Techniques

3.1 Acceptance and evaluation criteria

Acceptance criteria describe minimum requirements to accept a solution, mostly used when only one possible solution is being evaluated. Acceptance criteria results in pass or fail. Evaluation criteria are set of requirements used to choose between multiple solutions options, solutions or solution components, thus allowing for a range of possible scores.

Scoring determines how well a solution meets acceptance and evaluation criteria. Business Analysts must establish a scale for scoring each criterion and define possible scoring levels. Stakeholders must agree on the criteria and how solutions will be rated against them. Acceptance and evaluation criteria must be testable.

Ranking is the process of determining the relative order of importance for all requirements. MoSCoW is a very popular technique used for ranking requirements.


* Agile methodologies require requirements to be expressed as testable acceptance criteria.

* Necessary when requirements express contractual obligations.


* May express contractual obligations,

* Difficult to change for legal or political reasons.


3.2 Activity diagrams

Activity diagrams model action sequences.

Action nodes

Action nodes execute an action. Start nodes initiate execution of activity diagram. End nodes represent termination of activity diagram.

Control flows, object flows, responsibilities

Alternative control flows in activity diagrams are achieved through use of decision nodes. Synchronization bars depict concurrent execution of control flows.

Swim lanes are informal modeling where activities are placed along the lines of roles / actors responsible.

3.3 Apprenticing

During apprenticing, Business Analysts collect requirements by becoming an apprentice in the stakeholder’s work environment. This is useful for

* Documenting details about current processes.

* When the project’s objective is to enhance or change an existing process.


* Provides realistic and practical insight into business processes.

* Elicits details of informal communication.

* Identify workarounds which may not be documented.


* Possible for existing processes only.

* Time-consuming.

Steps for apprenticing

Prepare for apprentice

  1. Determine activities to apprentice.
  2. Identify a mentor for apprenticeship.


  1. Learn safety aspects
  2. Learn the process.

Be the apprentice

  1. Execute tasks under mentor’s guidance.
  2. Record requirements.

Review requirements

  1. Provide a summary of notes to the stakeholders, as soon as possible, for review and any clarifications.
  2. Review findings with the entire group to validate requirements.

3.4 Benchmarking

Conduct benchmark studies to compare current strategies, operations, processes and practices against the best-in-class practices in own or other industries. Benchmark studies try to determine how others have achieved superior performance levels and design projects to improve operations of the enterprise.

Steps for Benchmarking

  1. Identify area to be studied
  2. Identify leading organizations in the industry
  3. Conduct a survey to understand their practices
  4. Visit best-in-class organizations
  5. Develop a project proposal to implement the best practices.


* New and different ideas, tools and methods to improve organizational performance.


* Time consuming.

* Lack of expertise to analyze benchmarking data.

* Cannot produce innovative solutions.

* Difficult to organize.

3.5 Brainstorming

During brainstorming, one or group of stakeholders, usually in groups of 5 to 10 people, deliberate on an idea with the aim to produce numerous new ideas in a non-judgmental environment and derive themes for further analysis within a stipulated time frame. Participants built on other users' ideas to modify them or develop new ideas. Facilitator documents ideas by a without discussing, judging, or commenting. Participants analyze collected ideas to develop themes for further analysis.

Steps for brainstorming

Prepare for brainstorming

* Develop a clear subject of focus.

* Set a time limit for the group to generate ideas (30 to 60 minutes).

* Identify facilitator and participants.

* Aim for 6 to 8 participants representing range of backgrounds and experiences with the topic.

* Set ground rules with participants and get buy in.

* Establish criteria for evaluating and rating ideas.

Conduct session

* Share new ideas without any discussion, criticism or evaluation.

* Visibly record all ideas.

* Encourage participants to be creative and build on others’ ideas.

* No limit on the number of ideas gathered.


* On reaching time limit, discuss and evaluate ideas using pre-determined evaluation criteria.

* Finalize list of ideas by eliminating duplicates and combining similar ideas.

* Rate the ideas.

* Distribute final list of ideas to appropriate parties.


* Excellent ways to foster creative thinking as ideas are not judged.

* Facilitated properly, it can be fun, engaging and productive.

* Multiple people can expand on these ideas collaboratively

* Ability to elicit large number of ideas in a short time period.

* Useful during a workshop to reduce tension between participants.

* Unbiased collection of ideas allows new solutions to pop up.

* Highly effective when a large number of stakeholders from different groups are involved.


* Depends on participants’ creativity and willingness to participate.

* Organizational and interpersonal politics may hinder participation.

* Participants must agree to avoid debating on the ideas raised.

* Effectiveness depends on group dynamics.

3.6 Business rules analysis

A business policy is an intent statement for the organization. For example, as an organization, we shall be responsive to client needs. A business rule is an actionable and testable directive under control of an organization supporting a business policy. For example, as an organization, we shall respond to a client's request within 1 business day.

Complex rules can be expressed as decision tables or decision trees. They should be independent of any implementation, or enforcement. Business rules should be:

* Stated in appropriate terminology for Domain SMEs to validate.

* Documented independently of enforcement.

* Stated at atomic level and in declarative format.

* Maintained in a manner to monitor and adapt the rules as the business policies change.


* Allows changing policies without altering processes.

* Helps in assessing impact of changes to business rules.


* Can be unwieldy, contradict one another.

* May produce unanticipated results when combined.

* May be irrelevant to current and future operations and structure.

3.7 Conflict resolution techniques

Effective conflicts resolution is key to a project’s successes. Conflict resolution strategies have significant effect on willingness of stakeholders involved to continue working along. Unfair conflict resolutions lead to decreased engagement and collaboration in the project. Vice-versa is also true. Irrespective of conflict resolution strategies, Business Analysts MUST involve all relevant stakeholders during conflict resolutions.


Conflicting parties negotiate a solution to the conflict. They exchange information, argue and try to convince one another to achieve an agreeable solution.


Conflicting parties compromise to a solution where each party is willing sacrifice certain aspects.


Conflict parties vote on solution alternatives and alternative with most votes is accepted as resolution for the conflict.

Definition of variants

System is developed in a way that permits different behaviors by use of variants (or parameters). For example, the system behaves differently for processes executed in country A vs. country B.


Conflict is resolved by means of formal authority. Should be used only if other resolution techniques have failed or are not feasible due to resource limitations (e.g., time).


Investigate all influencing factors of a conflict. Determine relevance by prioritizing influence factors. Based on results of this technique, apply Plus-Minus-Interesting technique.

Decision matrix

Create a decision table that contains solution alternatives in columns and all relevant decision criteria in rows. Identify decision criteria using technique “consider-all-facts”. Assess each combination of criterion and solution alternative, for example by means of a point-scale (0 indicating irrelevant to 10 points indicating Most relevant. Calculate sums of columns in order to find a solution. Accept solution alternative with highest score.

Conflicts resolutions should be documented for future reference. Business Analysts may make use of the following template for the same.

3.8 Data flow diagrams

Data models show data flow, data processes, data stores, sources and sinks in system environment. Data flows can be modelled at different levels of abstraction. Important modeling elements of data flow diagrams in different notations are below:









Data manipulation

A data process consumes input data, processes this data and outputs result of processing in form of output data. Data flow diagrams do not depict data transformation.

Resting data / Data store

Data stores depict persistent data. Data processes access and may update data in a data store.

Sources and sinks in system environment

Sources provide data to system, while sinks receive data from system (like people, departments, organizations, or other systems). These cannot be altered during system development.

Flowing data

Data flows describe data transported between processes, data stores and sources/ sinks.


3.9 Decision tables

A table showing complex business rules or logic specifying all of the possible conditions and actions that need to be accounted for in business rules.


* Easy to understand.

* Effectively shows large number of rules.

* Good to apply as an excel rule book.


* Not very effective to develop program logic.

3.10 Decision tree

A Graphical diagram illustrating conditions and actions in sequence. This is an alternative to decision tables.


* Easy to understand.

* Effectively shows large number of rules.

* Good for implementing as code logic.


* Not effective to apply as an excel rule book.

3.11 Data model

Data models describe concepts relevant to a domain (types of people, places, things etc.), information associated with them and their relationships. Two most widely used data models are - Entity-relationship diagrams (ERD), for relational database management systems (RDBMS) and Class diagrams, for object-oriented (OO) development.

Sample class diagram

* Concepts are aspects of significance about which the organization needs data. Each type of concept has a unique identifier (a type of attribute) that distinguishes actual instances of the concept. Concepts are known as entities in ERDs and as classes in class diagrams.

* Attributes define particular pieces of information associated with a concept.

* High-level logical data models focus on describing entities, key attributes and important relationships.

* Detailed logical data models contain descriptions of all entities, attributes and relationships.

* Physical data models describe how data is managed in the application.

Relationships are significant associations between concepts.

* Relationships define important linkages between entities which may indicate “cardinality” or "multiplicity” of the relationship.

* Metadata is “data about data”. Metadata describes the context, use and validity of information.


* Data models can be built at different levels of description.

* As data models have a strong basis in mathematical concepts, are supported by rules for correctness and completeness. This improves requirements accuracy.


* Complex for people without a background in IT.

* Terms used may vary in use in different organizational units or domains.

3.12 Document analysis

Document analysis elicits requirements from available documentation on existing and comparable solutions (business plans, market studies, contracts, requests for proposals (RFPs), statements of works (SoWs), guidelines, procedures, training material, competing product literatures, published comparative product reviews, problem reports, customer suggestion logs and existing system specifications etc.).


* Not starting from a blank page.

* Leveraging existing materials to discover and/or confirm requirements.

* Cross-check requirements elicited from other techniques such as interviews, surveys or focus groups.

* Helpful when Domain SMEs are not available.


* Limited to “as-is” perspective.

* Existing documentation may not be up-to-date or valid.

* Can be time-consuming

3.13 Entity-relationship diagrams

In structured programming, entity-relationship diagrams are used for modeling data perspective using entity types and relation types. Entity types define a set of entities, i.e. objects with same properties, such as people or items.


* Offer flexibility of descriptions at different levels.

* Many old applications may have associated ER diagrams.


* Complex for people without a background in IT.

* ER diagrams are less expressive compared to Class diagrams as they do not include operations aspects.

* Terms used may vary in different organizational units or domains.

3.14 Flow charts

Flow charts are diagrammatic representations of activities or logic. There are many types of flowcharts, such as

  1. Logic charts
  2. Decision trees
  3. Activity diagrams
  4. Process models


* Easy to understand.

* Reduces miscommunication in requirements.

* Effectively shows large number of rules.

* Good for implementing as code logic.


* Not effective to apply as an excel rule book.

* Needs additional effort.

3.15 Focus groups

Focus groups elicit needs, ideas, impressions, preferences and attitudes from pre-qualified individuals about specific opportunity, product, or service in an interactive group environment, guided by a facilitator. Focus groups typically last between 1 to 2 hours. Focus groups can be used during any life-cycle state: Exploration, during development, ready to be launched, or in production.

During product development, analyze focus group’s ideas with existing requirements. This may need result in updating existing requirements or adding new requirements.

For a product to be launched, focus group may discuss product positioning. For a product in production, focus group may provide inputs on new improvements for the next release of product. Focus groups can also help assessing customer satisfaction with a service or product. Observers can record or monitor the focus group but they should not participate. Being a qualitative research technique, focus group results are analyzed and reported as themes and perspectives, not in numerical findings. Traditional focus groups gathered in the same physical room. Now online focus groups allow members to be located remotely. Focus groups are similar to a brainstorming session. Differences are:

> Focus groups are typically more structured and mandate a facilitator.

> Brainstorming session’s goal is to actively generate large number of ideas without inhibitions.

Steps for focus group

Recruit participants

Focus groups typically have 6-12 attendees. Invite 2 to 3 additional individuals to allow for no-shows. If more people need to participate, plan for more focus groups. Choose focus group participants based on the topic for the focus group. For new products, include existing users (experts and novices). Focus groups can be homogeneous or heterogeneous.

Homogeneous – Participants have similar characteristics.

Caution: May not bring up differing perspectives.

Possible solution: Conduct separate sessions for different homogeneous groups.

Heterogeneous – Participants with differing backgrounds and perspectives.

Caution: Participants may not share opinions freely if they are uncomfortable with other participants' backgrounds or opinions.

Possible solution: Collect inputs from all participants through brain-writing or round robin method before beginning the discussion.

Assign facilitator and recorder

A skilled facilitator should:

* Promote discussion.

* Ask open questions - requiring or promoting an extended response.

* Facilitate interactions between group members.

* Engage all members.

* Keep session focused.

* Remain neutral.

* Be adaptable and flexible.

Create discussion guide - Include session goals, objectives and few questions to discuss.

Reserve site and needed services - Select location for the session and arrange for transcription support, audio/video recording equipment, if needed.

Run focus group session

Follow a pre-planned script of specific issues and ensure the focus group objectives are met. However, the discussion should appear free-flowing and relatively unstructured for participants.

Produce report

Facilitator documents participants’ agreements and disagreements and creates themes for future usage.


* Saves time and cost compared to conducting multiple individual interviews.

* Effective for learning people’s attitudes, experiences and desires.

* Active discussion and ability to ask questions create an environment where participants can consider their personal views wrt others’ perspectives.


* Due to group setting, some participants may not discuss sensitive or personal topics.

* People's opinion and actual behavior may not match.

* Homogeneous groups may omit requirements.

* Needs skilled facilitator.

* Difficult to schedule.

* Not an effective way to evaluate usability.

3.16 Functional decomposition

Functional decomposition breaks down a large aspect (process, functional area, deliverable, scope, or problem) into smaller independent elements. This provides ability to estimate, plan and manage larger aspects. Functional decompositions can be represented by hierarchical diagrams, tree diagrams, or by numbering sub-aspects. Each aspect is wholly comprised of the sub-aspects below it. Work breakdown structure (WBS) decomposes project scope to deliverables and work packages.


* Creates a conceptual model of work to be completed.

* Provides stakeholders with a consistent view of the scope.

* Assists in estimating, planning and monitoring.


* No way to ensure that all components have been captured.

* Decomposing without fully understanding the relationship between pieces creates an inappropriate structure.

3.17 Functional requirements analysis

Functional requirements (FRs) describe abilities of a system that are important to user community, such as functionalities offered by the system. Examples of functional requirements would be to manage customers, manage inventory, manage orders etc.

Categories of functional requirements are:

User interface perspective: (UI)

In the UI perspective, A user interface perspective on the requirements of the system is adopted. For example, the method of data inputs and outputs from the system are documented.

Data perspective: (Data)

In the data perspective, a static-structural perspective of the system is adopted. For example, the structure of data in the system and inter-relationships between them are depicted.

Functional perspective: (Logic)

The functional perspective documents information (data) received from the system context and manipulations done by the system. It also documents which data flows back into the system context.

Behavioral perspective: (State)

In the behavioral perspective, information about the statuses of information documented in a state-oriented manner.


* Strong influence on system’s acceptance by users.


* Many FRs added by users may be used sparingly.

* Un-controlled FRs significantly increase cost of development.

3.18 Implicit requirements analysis

Implicit requirements (IRs) describes requirements that the user community needs but do not mention them explicitly. The reason for not stating the requirements could be due to the assumption that the Business Analyst is knowledgeable about the domain and would take care of them. One very simple example of implicit requirement would be that we expect the restaurant to treat its customers well and deliver the food hot and fresh.

Typical sources of implicit requirements are Functionalities of the existing system and Functionalities offered by similar products.

Implicit requirements can be gathered by developing a comprehensive implicit requirements catalog.


* Strong influence on system’s acceptance by users.


* Users may add implicit requirements when discussed where as they may not really need them in the new system.

3.19 Interface analysis

Interface analysis identifies interfaces and interactions between solutions and/or solution components. 3 common software interface types are:

  1. User interfaces (UIs) - Allowing users to interact with the system and receive reports from the system.
  2. Interfaces to and from external applications.
  3. Interfaces to and from external hardware devices.

Interface analysis can also be useful for non-software solutions, such as when defining requirements for third party deliverables.


* Early identification of interfaces uncovers and confirms how stakeholders will interact with the application.

* Provides a framework for subsequent analysis of detailed interface requirements.

* Provides an early, high-level view of interoperability for planning.

* Enables better project planning by assessing interfaces needed, their anticipated complexities and testing needs.

* Better collaboration with other systems or projects – It is difficult to change existing interfaces. Address ownership, development and testing aspects for new interfaces.

* Negotiate and cooperate between those responsible for both applications while eliciting and analyzing interface requirements.

* Helps in integrating multiple components.


* Does not provide insight to internal components / aspects of the solution.

3.20 Interviews

Interviews are the MOST common form of elicitation technique. During interviews, interviewers ask questions to stakeholders. Effective interviewers control discussions, understand needs from all stakeholders, probe deeper when needed and ensure completeness of answers.

Interviews are broadly categorized as:

Structured interview - Interviewers have pre-defined set of questions.

Unstructured interview - There are no pre-defined questions, interviewers and interviewees discuss in an open-ended manner.

Successful interviewing depends on

* Interviewer and interviewees understanding of the domain.

* Interviewer and interviewees’ rapport.

* Interviewer experience.

* Skill of interviewer in documenting discussions.

* Interviewee readiness to discuss and provide the relevant information.

* Interviewee’s knowledge about requirements of system being developed.

* Ability of the group to reach consumers.

Tips for interviewing

Prepare for interview

* Define interview’s focus or goal.

* Identify interviewees with most authentic, current, higher relative importance information on the subject.

* Design interview questions considering format for the interview - Structured vs. Unstructured. For a structured interview, types of questions can be close ended or open ended.

* Organize questions - Use a logical order. Examples of order can be high priority/ significance low priority, general questions to specific questions, start to finish, summary to detail, etc. Choose questions based on interviewee’s level of knowledge and expertise.

* Participants location - Ensure the interview time and location are convenient to the interviewees. Interviews can be conducted in-person, using telephone, web conference, or other remote communication methods.

Conduct interview

* Open interview.

* Conduct interview.

* Maintain focus on the established goals and pre-defined questions, if structured.

* Record concerns raised by participants and address them during the interview or document for future follow-up.

* Listen actively and paraphrase to confirm what has been understood from the conversations.

Close interview

* Check if any areas / information have been overlooked.

* Summarize findings.

* Thank interviewees for their time.

Follow-up and confirm

Prepare and share interview notes to the interviewees for review.

* Purpose of this review is neither to validate the requirements nor to approve, but only to determine if the interview findings have been properly documented.


* Builds personal rapport.

* Helps in understanding individual concerns and expectations.

* Helps in user data collection.

* Helps in identifying underlying political factors.


* Consumes time and effort.

* Unverified opinions.

* Largely qualitative inputs.

3.21 Lessons learned process

Lessons learned process analyzes successes, failures, opportunities and recommendations for improvements. Ensure format or venue works for the key participants. During lessons learned sessions, participants review

* IT Business Analysis process, activities, deliverables, final product, automation, technology used or not used and managerial issues.

* Contribution of organizational process assets to requirements processes.

* Performance against plan (variances) and possible root causes.

* Corrective and/or preventive actions needed.

Lessons learned sessions can be formal, facilitated meetings with set agendas and meeting roles, or informal working sessions, or get-togethers. It may or may not include a celebration.


* Can identify improvement opportunities.

* Build team morale.


* Participants may make it a blame game session and avoid honest introspection.

* Participants may avoid discuss and document problems.

* May become a “gripe” session.

3.22 Matrix model

Tables are simplest forms of matrices. Matrices are extremely efficient to express set of requirements having uniform structure. Data dictionaries and requirements attributes often expressed in matrices. Matrices can be used for requirements traceability. They also can be used for prioritizing requirements.


* Can identify missing requirements.

* Very compact in form.


* Takes time and effort.

3.23 Mind-mapping

Mind-maps allow to explore requirements from high level to detail. In the following diagram, we are trying to explore different types of requirements.


* Very helpful tool to expand requirements.


* Needs time build.

3.24 MoSCoW Analysis

MoSCoW analysis divides requirements into four categories: Must have, Should have, Could have and Won’t have


Requirement must be satisfied for the solution to be considered a success.


Represents a high-priority item which is critical but can be satisfied through work around.


Requirements which can be included if time and resources permit.


Requirements which will not be implemented in a given release. These may be considered for future releases.

3.25 Non-Functional (Quality, Supplementary) requirements





Quality requirements are mostly documented using natural language. For example:

  1. 80% of users shall be able to use basic functions of the system within 6 hours of training.
  2. 90% of responses will be in less than 5 seconds.


Time taken to perform activities and resource utilization levels.




Measure of application being available when needed. Includes ability to recover from errors, uptime, or failures in interfaces.





Portability, also known as Transferability



3.26 Observation                           

Observation technique is also known as Job shadowing” or “Following people around". During observation, collect requirements by observing actual work environment. This is useful for

* Documenting details about current processes.

* When the project’s objective is to enhance or change a current process.

* Stakeholders are unable to express the requirements well.

Observations are 2 types:

  1. Active observation – Business Analyst asks questions during the process.
  2. Passive observation - Business Analyst asks questions at the end.

Steps for observation

Prepare for observation

  1. Determine activities to observe.
  2. Identify sample users (e.g. experts and novices or just experts) to observe.
  3. Prepare observation questions.


  1. Introduce self.
  2. Assure users that their work is not being questioned and sole purpose is to gather requirements.
  3. Inform users that you are present only to study their processes.
  4. Refrain from discussing future solutions to any problems.
  5. Inform users to stop the observation process at any time if it interferes with their work.
  6. Suggest user to “think aloud” while they are working to share their intentions, challenges and concerns.

Conduct observation

  1. Take detailed notes.
  2. For active observation, understand rationale, issues and challenges of the tasks being performed by questioning stakeholders.


  1. Obtain answers to initial questions, or new questions raised during observation.
  2. Provide observation summary promptly for review and any clarifications.
  3. When observing many users, periodically compile notes to identify similarities and differences.
  4. Review findings with the entire group to ensure findings represent the entire group, not selected individuals.


* Provides practical insights into business processes.

* Identifies workarounds which may not have been documented.


* Possible for existing processes only.

* Time-consuming.

* Can be disruptive.

* Can’t capture unusual exceptions, critical situations and intellectual activities.

3.27 Organization model

Organization models describe roles, responsibilities and reporting structures within organizations. Organizational charts a very common example of an organizational model.

Typical organization structures are:

Functions: Employees grouped based on shared skills or areas of expertise. Helps in work standardization across the organization.

Markets: Employees grouped on serving a particular customer segment. Enables the organization to serve needs of its customers. This may lead to work inconsistencies and duplication.

Matrix: In matrix model, employees are grouped in 2 dimensions: Functional areas as well as market (product, service, or customer group). Functional managers are responsible for the managing and improving performance of specific types of work. Market (product/ service/ project etc.) managers are responsible for managing customers, products, services across multiple functional areas.


* Organizational models exist even for simplest organizations.


* Do not reflect informal authorities which may be quite different from formal authorities.

3.28 Persona

A persona defines a typical group of users of a system. To design effective software, it needs to be designed for a specific person. For example, for a bank, potential personas could be named Mike Miller and Katy Williams. Personas represent fictitious people which are based on knowledge of real users. Unlike actors in use case diagram, personas are not roles that people play. Personas are different as they describe a typical instance of an actor. In a use case model, we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.

Each persona may be described in detail by developing personas with real names, personalities, motivations and often even a photo. The goal is to bring users to life.


* Allows to think and document requirements from different user categories.


* Will increase number of requirements, hence may increase effort and cost.

3.29 Problem tracking

Problem tracking (can include conflicts, clarifications, issues, risks, questions, defects, or other concerns requiring closure) provides an systematic approach to record, track, and resolve problems. This is important to ensure project success. Problem tracking ensures that issues are not neglected or lost. Communicate problem statuses to all relevant stakeholders.

Steps for Problem tracking

Record problem

Problem records typically contain:

* Description: A clear and specific description of the identified problem.

* Raised by: Person who identified the problem.

* Date identified.

* Impact: Possible effects on schedule, cost or scope.

* Priority: Urgency, typically classified into: Critical, High, Medium and Low.

* Need by date.

* Owner: Team member accountable for the problem.

* Current status: Examples statuses can be Open, Assigned, Resolved, Cancelled etc.

* Action needed to resolve the problem.

* Responsible: Person assigned to resolve the problem.

* Date of completion.

* Outcome: Results of resolution.

Manage problems

Track and manage problems till closure or problem is no longer relevant. Problems not resolved in reasonable time should be escalated.


* Provides an organized method for tracking and resolving problems.

* Timely resolution of problems eliminates or minimizes negative impacts.

* Resources can be allocated to resolve problems.

* Assists in identification of root causes of problems.

* Provides mechanism to communicate problems across the team.

* Helps to maintain focus on open problems and ensure resolutions with regular team reviews of the problems.


* Lack of regular prioritization and management of problems makes the list outdated and irrelevant.

* Often problem resolutions are very slow to non-existent.

* With a strict deadline to deliver a solution, problem management may become a lower priority.

3.30 Prototyping

Prototypes detail out user interface requirements and elaborate other requirements such as scenarios, use cases, data and business rules. Prototypes are a concrete means of identifying, describing and validating interface needs.

Different types of prototypes are:

Horizontal prototype

Shallow and wide view of the system’s functionality without any business logic.

Vertical prototype

A deep and narrow slice of system’s functionalities.

Throw-away prototype

Quickly uncover and clarify interface requirements using simple tools, can be just paper and pencil.

Evolutionary or Functional prototype

Extends initial interface requirements into a fully functioning system. Requires specialized prototyping tool, language and produces a working application.

Steps for prototyping


* Determine prototyping approach.

* Identify functionalities to be modeled.


Build prototypes iteratively. Initially outline high-level views. Subsequently, add more details.

For example,

* First prototype of a report may contain a list of requirements such as data attributes, selection criteria and rules for totals. Further one may create a detailed.

* For UI prototyping, initial focus can be on end-to-end understanding of the interface flows. Later details of each UI.

* Storyboards (also known as a Dialog maps, Dialog hierarchies or Navigation flows) portray navigation paths across multiple interfaces. This diagram includes screen abstractions with arrows indicating allowable navigation flows.

* Screen prototypes provide data attributes, filter criteria and control objects.

* A screen layout or mock-up provides a graphical representation of UI elements. Apply organizational standards or style guides.

Evaluate prototype

* For detailed prototypes, trace logical interface elements to user requirements such as processes, data and business rules.

* Validate that the prototype meets user’s needs. Scenarios are useful to test prototypes.


* Very effective in finding stakeholder needs as stakeholders see the future system in the prototype.

* Allows early user interactions and feedbacks.

* Vertical prototype can demonstrate feasibility with chosen technologies.

* An evolutionary / functional prototype can be a vehicle for designers and developers to learn about users’ needs and to evolve system requirements.


* Unless evolutionary prototyping, working prototypes can be expensive to confirm requirements beyond user interface aspects such as processes, data and business rules.

* Assumptions about underlying technology need to be made for evolutionary prototyping.

* Users may develop unrealistic expectations about product and project. A detailed prototype can look similar to a fully functional system.

* Users may focus on design specifications than requirements.

3.31 Release planning

Release planning is an agile development activity to distribute epics and user stories across different releases. Release planning is conducted periodically to ensure releases deliver maximum value to business.


* Allows to agile development team to deliver maximum business value.


* None.

3.32 Requirements prioritization techniques

Requirements prioritization techniques provide various options for prioritizing requirements.

Prioritization Basis

Prioritization Basis and Description:

Urgency - Prioritizes requirements based on time sensitivity. Typically uses MoSCoW technique.

Business value - Prioritize requirements on their relative value to the organization based on cost-benefit analysis. High value requirements are developed early. Commonly used when enhancing an existing solution, or when delivering solution incrementally.

Business or technical risk - Prioritize requirements with highest risk of failure. Implemented first to ensure that, if the project fails, it fails with least expenditure.

Implementation difficulty - Prioritize requirements which are easiest to implement. Common when piloting a new development process, tool or when rolling out a packaged solution. This helps the project team to gain familiarity and develop competence by working on lower-risk requirements.

Likelihood of success - Prioritize requirements which are likely to produce quick and relatively certain successes. Common when a project is controversial and stakeholders need early signs of progress to support the initiative.

Regulatory or policy compliance - Prioritize requirements to meet regulatory or policy demands. This can take precedence over other stakeholder interests.

Relationship to other requirements - Prioritize requirements which support other high-priority requirements.

Stakeholder agreement - Prioritize requirements based on Stakeholders’ agreement most useful or valuable requirements. Often used together with other approaches described above.

3.33 Requirements review checklist

Requirements review checklist is a simple verification / validation technique which is used during requirements review.



* Simple technique to improve requirements quality.


* Can be very lengthy if not designed properly.

3.34 Requirements workshops

Requirements workshops (also known as JAD (Joint application design) sessions) are focused events (typically one or a few days) attended by carefully selected key stakeholders and SMEs. Experienced, neutral facilitators facilitate requirements workshops. Scribes document requirements and outstanding issues. Business Analysts may act as facilitators, or scribes or be participants in case they are SMEs on the topics. Workshops can generate ideas for new products, features, help in reaching consensus on a topic, review requirements, and capture detailed requirements in models.

Prepare for requirements workshop

* Clarify purpose of the workshop.

* Identify critical stakeholders for the workshop.

* Define workshop’s agenda.

* Determine how to document outputs of the workshop.

* Schedule sessions.

* Arrange logistics and equipment, including seating, flipcharts, projectors etc.

* Send materials in advance to so that attendees come prepared. This increases workshop productivity.

* Conduct pre-workshop interviews with attendees to ensure objectives of the workshop is aligned with the needs the attendees.

* Ensure any preparation needed for the session by the attendees is understood. Note that these are not requirements interviews.

Conduct requirements workshop

* Elicit, analyze and document requirements.

* Obtain consensus on conflicting views.

* Maintain focus by frequently validating workshops activities with the stated objectives.

Facilitator’s responsibilities are:

* Establish a professional and objective tone for the workshop.

* Introduce goals and agenda.

* Enforce discipline, structure and ground rules for the workshop.

* Manage the workshop and keep the team on track.

* Facilitate decision-making and building consensus, but avoid participating in the discussion.

* Ensure all stakeholders participate and have their inputs heard.

* Ask right questions including analyzing information being provided and following up with probing questions, if necessary.

Scribe’s responsibilities are:

* Document requirements in the format determined prior to the workshop.

* Keep track of any issues identified.

Post requirements workshop wrap-up

* Follow up on any open action items recorded at the workshop.

* Complete documentation and distribute it to stakeholders.


Helps in getting requirements in a short time.

* Good means for stakeholders to collaborate, work together to reach consensus, make decisions and gain mutual understanding of requirements.

* Costs lower than cost of performing multiple interviews as interviews may yield conflicting requirements and resolving the same can be very costly.

* Stakeholders can immediately validate facilitator’s interpretation of requirements, so feedback is immediate.


* Difficult to schedule due to stakeholder unavailability.

* Success is highly dependent on the expertise of the facilitator and knowledge of the participants.

* Too many participants can slow down the workshop process.

* Not collecting inputs from all participants can lead to overlooking of important requirements.

3.35 Scope models

Scope models describe scope of analysis or scope of a solution. They serve as the basis for defining and limiting scopes of business analysis and project work. Most common scope models are:

* Context diagram is top most level data flow diagram. It shows the external entities that provide data to and receive data from the system.

* Events are external to the system under study. Events can be triggered by stakeholders such as customers placing orders, partners sending messages or by time such as monthly or annual reports. Processes responding to events can be documented and further analyzed, using process modeling techniques.

* Features are services provided by the solution to fulfill one or more stakeholder needs. They allow for early priority and scope management. Features are expanded later into functional and supplemental (quality or non-functional) requirements.

* Use case diagrams depict features (use cases) supported by a system, actors who use those features and relationships between them.

* Business processes can also be used as scope models.


* Helps to determine whether requirements are in and out of scope for a solution.


* Usually at high level, thus leading to conflicts between stakeholders.

3.36 Sprint planning

Sprint planning is an agile development activity to distribute planned user stories for a release across different sprints. Sprint planning is conducted prior to every sprint to ensure sprints deliver maximum value to business.


* Allows to agile development team to deliver maximum business value.


* None.

3.37 Sprint retrospective

Sprint retrospective is an agile development activity to analyze successes, opportunities for improvement, failures and recommendations for improving the performance of future sprints.

Sprint retrospective can review

* Sprint process, activities, deliverables, final product, automation and technology used or not used and managerial concerns or issues.

* Performance against plan, variances (within acceptable limit and beyond limit) and possible root causes

* Corrective and/or preventive action needed


* Can identify improvement opportunities.

* Build team morale.


* Participants must avoid blame game as it does not allow honest introspection.

* Unwillingness of participants to discuss and document problems.

* May become a “gripe” session.

3.38 Sprint review

Sprint review is an agile development activity to demo the outcome of a sprint to different stakeholders, especially product owner. This session is conducted at the end of the sprint to decide whether the sprint outcomes can be potentially shipped to customers.


* Gate keeping measure before releases.


* Absence of product owners and stakeholders makes this ineffective.

3.39 Stakeholder register


Since stakeholders are the MOST important source of requirements, it is a best practice to maintain stakeholder register (also known as Stakeholder List). Business Analysts MUST identify and list all potential stakeholders for a project. A stakeholder list lists potential stakeholders for IT Business Analysis. Usually stakeholder identification begins with suggestions made by Sponsor or by Domain SMEs. For a project, there can be large number of stakeholders. Stakeholder registers should capture Stakeholder name, Type (Internal / External), Function / Role, Designation, Contact details, Area and expertise, Location, Time availability, Criticality, Stakeholder’s objectives, Expected contribution, Current contribution and Interventions needed etc.

3.40 State Diagrams



For depicting system behavior, Unified Modeling Language (UML) offers state chart diagram. State defines a period of time in which a system exhibits a particular behavior and waits for particular event(s) to occur. On particular event(s), a state transitions to a new state. States usually have a Start state (Origin state) and a final state (Final state).

3.41 Structured walkthrough

Structured walkthroughs, also known as business requirements reviews, are working sessions where invited participants review and discuss a set of business requirements. They are performed to communicate, verify and validate business requirements. Record all questions, comments, concerns and suggestions that arise during the walkthrough. Inspection is similar, but follows a more formal process and uses checklists and other tools.

Pre-requisites of Structured walkthrough

* Completed requirements package - Scope of the review can be only one requirement document, or an entire requirements package.

* A list of appropriate reviewers - Appropriate reviewers include stakeholders or representatives who contributed to the requirements, Implementation SMEs, and representatives of sponsor or end users.

* A meeting vehicle - Can be in-person review of review using remote communication tools.

Review scope

* Provide reviewers with a checklist of items for review. Specify out of scope requirements, excluding solution elements etc.

Organize and schedule review

* Send requirements package in advance to allow all stakeholders to do self-review.

* Ensure availability of stakeholders with approval authority at the session.

* Explain reviewers that the ONLY purpose of the review is to remove unclear, inconsistent and incorrect requirements.

Roles in review

Author is a Business Analyst who Provides clarifications. Incorporates accepted changes. It is mandatory.

Scribe is a any team member who documents all suggestions, comments, issues, concerns, outstanding questions. It is not mandatory.

Facilitator is a Another stakeholder and he must be natural. Who Verifies all participants have reviewed the document before the session begins.

and Keeps participants focused on the requirements and ensures participation from all reviewers. It is mandatory.

Reviewer is a Domain SMEs who Review requirements prior. Questions, comments, suggests changes and discusses them with the group. It is mandatory.

Conduct review

Structure of review sessions:

* Introduce participants.

* State purpose of the deliverables for review.

* State review objectives.

* Explain project background, if required.

* Formal walkthrough/review of deliverable.

* Agree on actions/changes required.

* Determine reviewed deliverable status (e.g. signed-off, not signed off, etc.).

Compile notes and results of the review

* Record all participant comments.

* Consider them for revisions to the requirements document.

* At the end of the review, agree:

* On quality improvements to be made to the requirements document.

* Whether requirements document can be accepted in its current form.

* Whether additional reviews are needed to approve the requirements document.

Re-review, if necessary.

Rules to be followed during the review:

Facilitator is responsible for making sure that all participants adhere to the rules.

* Reviewers must review the document before the session.

* Determine appropriate project stakeholders to participate in the review/ structured walkthrough.

* Reviewers must review the content, not the author

* Supervisors or managers (especially of the author) should be careful during the review. Their organizational authority can adversely affect effectiveness of the review.

* List of questions, comments, concerns and suggestions must be compiled.


* Promotes discussion among stakeholders.

* Effective at identifying possible ambiguities and areas of misunderstanding.


* Can lead to repeated revisions.

* May take considerable time for getting approval.

3.42 Surveys and Questionnaires

Surveys, also known as questionnaires, can obtain requirements from large stakeholders in a relatively short period of time. Surveys can be anonymous. Surveys are easy to implement as there are many online survey tools available at no or low cost. Surveys administer a set of written questions to stakeholders. Surveys can gather feedbacks, expectations, work practices and attitudes. Analyze and distribute survey responses to appropriate stakeholders.

Survey questions are of two types:

* Closed – Respondents select from available responses. Useful when the ranges of user’s responses are well understood and we need to determine strengths of each response category. Closed questions are easier to analyze as they can be tied to numerical coefficients.

* Open-ended – Respondents are free to answer the questions. Open ended questions are useful when the issues are known but the ranges of user responses to them are not known. Open-ended questions are more difficult to analyze and quantify as they have descriptive inputs.

Steps for Survey

Prepare for survey to ensure that the needed information is obtained while minimizing respondent’s time to complete it.

  1. Define purpose and objective of survey.
  2. Identify target groups to be surveyed.
  3. Choose appropriate survey types.
  4. Confirm with sponsor.
  5. Select sample group.

Distribute survey

  1. Select distribution and collection methods - For each sample group, determine appropriate execution mode, such as postal mail, or web.
  2. Determine acceptable response rate. If actual response rate is lower than the acceptable threshold, use of the survey results may be limited. One can offer incentives to raise the response rate.
  3. Determine if the survey should be supported with individual interviews. Surveys may not be able to provide in-depth data which can be obtained from individual interviews.
  4. Consider pre-survey interviews with key individuals to design survey questions,
  5. Develop survey questions.
  6. Communicate purpose of the survey. This may improve the response rate.
  7. Be aware of the group’s characteristics.

* Use information about the background of the target group, including their environment and specific terminology to develop questions.

* If the target group is significantly diverse, conduct multiple surveys targeted at specific groups.

  1. Focus on requirements - All questions MUST be directed towards the stated survey objectives.
  2. Make the survey easy and quick to complete, ideally not more than 5 or 10 minutes.
  3. Arrange questions in an order which tells a story.
  4. Ensure question wordings are clear and concise, using terminologies familiar to respondents.
  5. Each question must address a single point.
  6. Avoid the following:

* Double questions in a single question.

* Negative phrasing.

* Complex branching structures.

* Uncomfortable questions

* Information restricted by regulations.

  1. Perform usability test on the survey. Use results to fine-tune the survey.
  2. Select distribution means according to:

* Organizational policies,

* Urgency of obtaining the results,

* Level of security required and

* Geographic distribution of the respondents.

  1. Target specific survey responses or themes to elicit a greater level of detail during post-survey interviews.

Document survey results

  1. Collate responses. For ‘open-ended’ questions, identify emerging themes.
  2. Analyze and summarize results.
  3. Report findings to sponsor.


* Quick and relatively inexpensive.

* Closed-ended surveys are effective at obtaining quantitative data for use in statistical analysis.

* Open-ended surveys can get insights and opinions not easily obtained through other techniques.

* Does not require significant time from stakeholders.

* Effective when stakeholders are not co-located.


* Not suited for collecting information on actual behavior.

* Response rates can be too low for any statistical significance.

* Open-ended surveys require more analysis.

* To achieve unbiased results, one needs specialized skills in statistical sampling methods when survey is conducted only for a subset of potential respondents.

* Ambiguous questions may remain unanswered or answered incorrectly.

* May require follow up surveys or interviews depending on the responses provided.

3.43 Use case diagrams

Use case diagrams are simple diagrams to document functions of a system from users’ perspectives. They also indicate interrelations between system functions and system functions and the system context (People, other systems etc.).

Uses cases are depicted using oval shapes which contain name of use case. For example, here the use cases are, “Set-up project”, “Assign resources” and “Track progress”.


Actors represent people or systems that interact with the system and are outside the system boundary. If actor is a person, a stick figure is used. For system actors, use either a rectangle or a stick like figure.

System boundaries

System boundaries, represented by rectangles, separate aspects within the system (Functions) to aspects out-side the system (people or systems).


* Very simple diagram to understand system context and functionalities.

* Understand interrelationships between use cases.

* Assists in identifying re-usable requirements through include use cases.


* Are high level diagrams.

* Do not provide insights into how the functionalities actually work.

* Need help of other models such as activity diagram to understand detailed process flows.

3.44 Use case specifications

Use case diagrams are high level diagrams and do not provide detailed information, for example information on step by step interaction between the actor and the system. This information is documented using use case specifications. Typical sections of a use case template include:

* Unique designation of the use case

* Name of the use case

* Description of the use case

* Triggering event

* Actors

* Result

* Pre- and post-conditions

* Various kinds of scenarios.


* Detailed and provide insights into how the functionalities actually work.


* Have large amount of texts,

* Process steps possibly can be better described in activity diagrams.

3.4.5 User stories

User Stories are brief textual descriptions, usually 1 or 2 sentences, of functionalities needed by users. Include only details that reduces the risk of misunderstanding by developers while creating the estimate.

A user story includes:

* User (Actor) - Stakeholder who benefits from the story.

* Description - A high-level overview of the functionality.

* Benefit - Business value that the story delivers.

* Defined acceptance and evaluation criteria.

Example: As a Project Manager, I should be able to import schedule from MS Project.


* User stories create an environment of customer ownership of features and prioritizations.

* Minimize the need to provide functional requirements in some environments.

* Ensures value delivered by the story be clearly articulated


* Does not explicitly address non-functional requirements.

* May not be the best technique for environments with regulatory restrictions.

* Not very effective for non-co-located teams.


  1. Plan IT Business Analysis

4.1 Key Concepts

Plan IT Business Analysis knowledge area focuses on having right planning for IT Business Analysis. It describes following tasks:

* Plan for understanding requirements context

* Understand and document requirements context

* Define system boundary and solution scope

* Identify requirement sources

* Identify and prioritize stakeholders

* Determine Business Analysis approach

* Plan for requirements communication

* Identify IT Business Analysis risks and assumptions

* Estimate schedule, effort and cost

* Develop IT BA plan

A good planning ensures that Business Analyst has identified all requirements sources and resources needed for IT Business Analysis. This goes a long way in ensuring quality of requirements gathered.

4.1.1 Understanding context

Dictionary definitions of word “Context”.

Webster-Mariam dictionary

* The words that are used with a certain word or phrase and that help to explain its meaning.

* The situation in which something happens: the group of conditions that exist where and when something happens.

Cambridge dictionary

* The influences and events related to a particular event or situation.

Oxford dictionary


So, we can conclude context is the prevailing situation that affects or helps to understand requirements.

Typical elements of the context are:

* People (stakeholders),

* Systems in operation (interfacing systems),

* Processes,

* Events,

* Documents (e.g., laws, standards, system documentation).

Requirements originate within a certain context. Stakeholders, relevant standards, and legal authorities demand specific functionalities from the system to be developed. Requirements can ONLY be interpreted correctly in regard to the specific context. Better understanding of the context lowers the likelihood of incorrect interpretations. Business Analysts MUST document the context correctly and completely.

Very first thing Business Analysts should do is to plan for understanding the context. As part of the plan, plan for studying existing documentation and meet key stakeholders. Use case diagrams and data flow diagrams are often used to document system context.

System boundary

System boundary demarcates aspects to be developed from its environment. It separates the aspects of the environment that can be modified from aspects of the environment that cannot be modified by the development process. Aspects within the system boundary can be business processes, technical processes, people and roles, organizational structures and components of the IT infrastructure.

Sources and sinks

Sources and sinks can be used to identify system’s interfaces with its environment. Sources provide inputs for the system. Sinks receive outputs from the system. Possible sources and sinks of a system are:

* Stakeholders of existing systems,

* Other systems (applications and hardware).

Sources and sinks interact with the system via system interfaces. Using system interfaces, the system provides functionalities to the environment, monitors the environment, and influences parameters of the environment. Depending on the type of source or sink, system needs different interface types:

  1. Human-machine interface, also known as user interface,
  2. Hardware interface,
  3. Software or application interface.

[Rupp, Klaus Pohl and Chris 2015]

4.1.2 Requirements sources

Significance of requirements sources

Requirements are the foundation of solution development, hence it is essential to identify all requirements sources.

Identifying relevant stakeholders, interfacing systems and relevant documents is a key task for Business Analysts. Gather, document and consolidate goals and requirements from different sources.

Consequences of unconsidered sources

Not identifying or not considering stakeholders, documents and interfacing results in significant re-work, possibly leading to failure of the project. Unconsidered sources will create large number of change requests during system acceptance and operation. As we learnt earlier, not implementing requirements at appropriate time leads to significant re-work and hence high additional costs.

Types of requirements sources

Key requirements sources are:


Stakeholders are those people or organizations who affect requirements. They may provide or implement requirements. Stakeholders are the most important sources of requirements, hence not considering is bound to result in incomplete requirements.

Typical IT Business Analysis stakeholders are: Sponsor, Project managers, Domain SMEs, Implementation SMEs, Testers, End users, Administrators, Management, Application owners, and Legal entities, and institutions etc. There could be undesired stakeholders as well, such as hackers and users with fraudulent intents.


Documents are also another significant source for requirements. Documents may be:

* Provided by statutory and regulatory bodies.

* Standards prescribed by industry bodies and standard setting organizations such as ISO.

* Requirements documents of existing systems.

* Feature documents of competing systems.

* Error reports of existing systems.

* Complaints and feedbacks on existing systems.


Since most applications need to interact with other applications, interface requirements are needed for most applications. Similarly, Business Analysts can get insights into requirements from competing systems available in the market.

* Existing or predecessor systems

* Other interfacing systems.

* Competing solutions.

Important information of the stakeholder documentation

Stakeholders can be classified as internal or external.

Internal stakeholders are within the organization: e.g. employees and management. External stakeholders are outside the organization: e.g. government and trade associations etc.

Stakeholders can also be classified as Primary, Secondary and key stakeholders

Primary stakeholders are directly affected by the system such as end-users, management etc. Secondary stakeholders are indirectly affected, e.g. government and media. Key stakeholders are the ones who are most significantly affected or those with maximum influence.

4.1.3 Stakeholder management

Identifying relevant stakeholders is a key task of Business Analysts. Identify stakeholders and determine the impact of proposed changes on them to determine the needs, wants, and expectations to be satisfied by a solution. Some individuals may play a variety of roles in the same project, and different roles in different projects. Early identification of stakeholders helps in timely delivery of requirements deliverables. Stakeholders are the MOST important source of requirements. Business Analysts gather, document, and consolidate conflicting goals and requirements of different stakeholders.

Not considering stakeholders (could be due to non-identification) will result in significant negative impact for the project progress. Significant change requests can result during system operation as critical requirements may remain undetected. Modifying the system late causes high additional costs. Hence it is critical to identify all stakeholders in the beginning itself. Change-driven approaches better accommodate this risk, but cannot eliminate it.

Another technique for stakeholder identification is maintaining stakeholders’ checklist. This allows planned elicitation from relevant stakeholders. If the stakeholder list is not updated at right time or incomplete, the result may be that some stakeholders are missed from elicitation.

Stakeholder elicitation often begins with suggestions of relevant stakeholders made by management or by domain experts.

Enterprise architecture describes organizational units in the enterprise, their interactions with each other, customers, and suppliers, responsibilities within the organization, and roles, and relationships within each organizational unit.

Project manager, and Business Analyst share the responsibilities of stakeholder identification and management. Project manager is accountable for project team meeting commitments made to stakeholders, assignment of stakeholders to project tasks, their involvement in project execution, ensuring project scope is managed.

Business Analysts assist Project managers in defining which project team members and stakeholders should be involved in developing, reviewing or approving IT Business Analysis deliverables.

Stakeholder management process










* Ensures no stakeholders have been left out.

* Involving stakeholders can build trust.


* May add non-critical stakeholders to the project leading to additional requirements, cost and schedule.

Ensuring agreement with stakeholders

It is essential that all stakeholders agree to a common requirement for the system to be developed. Hence Business Analysts along with stakeholders should define a protocol to work. A stakeholder charter is a great tool to do so. The agreement process can be verbal or written. A sample stakeholder charter can be:

* All stakeholders will deal with all stakeholders in a dignified professional manner, treat each other with civility and respect

* To carry out activities as per project scope

* All stakeholders agree to listen and be open to the diverse points of view expressed by other participants

* Needs beyond project scope can be discussed and agreed by Steering committee

* Respect time of each stakeholder

* All stakeholders agree to provide other stakeholders the level of commitment and support expected in terms of time and effort minimum 2 weeks in advance

* As an effective team, all stakeholders agree that the issues will be judged on the merit of the issues only

* All stakeholders will co-operate and support each other to make the project a success

* All stakeholders shall raise any concerns about the project or the process with an open and timely manner

* All stakeholders agree to attend all review meetings,

* In case they are unable to attend, nominate a representative

* All stakeholders agree to provide approval / objection to the requests within 1 week

* Meeting if need to be re-scheduled, should be done at least 3 days in advance

* To save time on travel, stakeholders can participate calls through tele-conferencing means

Usually many stakeholders are involved in large projects. Due to limited resources, Business Analysts MUST carefully select stakeholders MOST suitable for IT Business Analysis. Principles in dealing with stakeholders are:

Comprehensive identification

Comprehensive identification ensures no stakeholders are left out from the IT Business Analysis process.

Constant prioritization

Since stakeholders are not static, it is essential for Business Analysts to keep the stakeholder register updated and prioritized.

Continuous involvement and constant communication

Continuous involvement and periodic communication with stakeholders help in better collaboration. Address stakeholder grievances.

Collaborative (Win-win) mindset

Business Analysts and project managers need to convince stakeholders regarding project benefits.

Defined protocol for engagement

To avoid misunderstandings and disputes, Business Analysts should develop formal communication and approval mechanism. This should include deliverables, tasks, roles, responsibilities and approval authorities. Also determine communication paths and feedback loops for stakeholders. Organizations differ greatly on formality on approvals, which could be ranging from being verbal to ink signature sign-off.

[Rupp, Klaus Pohl and Chris 2015]

4.1.4 Principles in dealing with stakeholders Stakeholder’s rights & duties

Stakeholders play vital role in IT Business Analysis process. They have deep understanding of the domain and its processes. Stakeholders’ responsibilities include:

* Provide requirements,

* Prioritize and rank requirements,

* Review documented requirements,

* Accept requirements trade-offs,

* Approve requirements,

* Assist Business Analysts in understanding domains and application,

* Communicate requirements promptly,

* Adhere to defined requirements development and change processes.

4.1.5 Business Analysis approaches

In software development, Business Analysis approaches range from Waterfall (plan-driven) to Agile (change-driven) approach, proprietary in- house methodologies, customs, and practices.

Source: BABoK

Business Analysts can combine elements from different approaches. Organizational process assets are typically known as Quality Management System in many organizations. Organizational process needs, and objectives include:

* Compatibility with other organizational processes.

* Constraints on time-to-market.

* Compliance with regulatory, and governance frameworks.

* Desire to evaluate new approaches to solution development.

* Other business objectives.

Organizations usually have formal or informal standards regarding how to conduct IT Business Analysis, and how it fits into project, and other activities. Review existing organizational standards, guidelines, and processes relating to the initiative. These may suggest or mandate Business Analysis approach. Even if a standard approach exists, tailor it to the needs of a specific initiative. Organizational standards govern tailoring of IT Business Analysis processes, specifying permitted approaches, elements that can be tailored, and guidelines for selecting an approach.

If no standards exist, work with appropriate stakeholders to determine the Business Analysis approach. Business Analysis approach often follows project approach but can also be independent. For example, project may follow an iterative approach but Business Analysis approach can be waterfall.

Especially, collect non-functional requirements in water-fall approach as changing non-functional requirements will be very difficult once the product is designed and built.

4.1.6 Plan for requirements communication

Determine how best to receive, distribute, access, update and escalate information from project stakeholders and how best to communicate with them. Requirements can be presented in any format, as long they as are understandable for the reviewer. This task decides formats appropriate for a particular initiative, and its stakeholders. Requirements must be clear, concise, accurate, and at appropriate level of detail.

Typically, IT Business Analysis communication plan is integrated into overall project communications plan. On small projects, it may be very brief, and may not be formally documented. On projects with many stakeholders, it may be a separate document or at least an essential part of the overall project communications plan.

4.2 Activities

4.2.1 Plan for understanding requirements context

Purpose: To plan for understanding requirements context from the sponsor and key stakeholders.

Stakeholders: Sponsor*, Domain SME*, Project Manager*.


  1. Enterprise architecture
  2. Business needs


  1. Plan for understanding requirements context.
  2. Get system and application landscape.
  3. Estimate effort needed for understanding requirements context.


  1. Plan to understand requirements context
  2. System and application landscape

Tools and Techniques: IT Business Analysis plan.

4.2.2 Understand and document requirements context

Purpose: To understand and document requirements context for guiding the IT Business Analysis activities.

Stakeholders: Sponsor*, Domain SME*, End users*, Customers*.


  1. Plan to understand requirements context
  2. System and application landscape


  1. Discuss project vision with sponsor, domain SME and Project manager.
  2. Understand the rationale behind the new / improved system.
  3. Understand current and likely future needs of the organization.
  4. Define requirements context.


  1. Business objectives / opportunities
  2. Current system challenges
  3. Requirements context
  4. Objectives of new / improved system
  5. Interfacing requirements

Tools and Techniques: Interviews, Document analysis, Context diagram

4.2.3 Define system boundary and solution scope

Purpose: To define system boundary and solution scope.



  1. Plan to understand requirements context
  2. System and application landscape
  3. Requirements context
  4. Objectives of new / improved system


  1. Define requirements context
  2. Define system boundary
  3. Define solution scope


  1. System boundary
  2. Solution scope

Tools and Techniques: Interviews, Document analysis, Context diagram, Requirements management plan.

4.2.4 Identify requirements sources & suitable elicitation techniques

Purpose: Identify requirements sources and suitable elicitation techniques for the initiative which may be regulatory, contractual and implicit requirements.

Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator.


  1. Business and system context
  2. Objectives of new / improved system.


  1. Identify sources of government regulations.
  2. Identify pertinent standards published by industry associations.
  3. Identify requirements fulfilled by current systems.
  4. Identify requirements fulfilled by competitors’ products.


  1. Identified requirements sources

Tools and Techniques: Interviews, System context diagram, Organization chart, Process models, Brainstorming.

4.2.5 Identify and prioritize stakeholders

Purpose: Identify stakeholders affected by a proposed initiative, determine their influences, and approval authority for project deliverables.

Stakeholders: Sponsor*, Regulator*, Domain SME*, Project Manager*, and End Users*.


  1. Business need
  2. Enterprise architecture
  3. Requirements context
  4. Stakeholder checklist


  1. Identify stakeholders.
  2. Determine their influences and interests.
  3. Prioritize stakeholders.


  1. Stakeholder list, roles, and responsibilities

[Note: Describes which stakeholder is responsible, accountable, consulted, and informed for IT Business Analysis deliverables ]

Tools and Techniques: Brainstorming, Interviews, Organization model, Process model, Scope models.

4.2.6 Determine Business Analysis approach

Purpose: To select correct Business Analysis approach based on project context and stakeholder needs.

Stakeholders: Sponsor*, Customer*, Domain SME*, Project manager*, End user, Supplier, Implementation SME, Tester, and Regulator.


  1. Business need
  2. Requirements context
  3. Organizational process needs, and objectives
  4. Organizational process assets.


  1. Consult key stakeholders on selecting the Business Analysis approach.
  2. Decide Business Analysis approach based on timing of IT Business Analysis work, formality, and level of detail required for IT Business Analysis deliverables.


  1. Business Analysis approach

Tools and Techniques: Brainstorming, Expert judgment.

4.2.7 Plan for requirements communication

Purpose: To plan for requirements communication based on stakeholder needs

Stakeholders: Sponsor*, Domain SME*, Project Manager*, Customer*, Supplier, End user, Implementation SME, Operational support, Tester, Regulator.


  1. Stakeholder list and expectations
  2. Organizational policies and processes
  3. Business Analysis approach


  1. Understand stakeholder needs.
  2. Consider geographic locations.
  3. Consider cultural diversity.
  4. Consider type of project.
  5. Determine communication frequency.
  6. Consider communication formality.
  7. Plan for requirements communication.



  1. Requirements communication plan

Tools and Techniques: Brainstorming, Requirements management plan, Guidelines for requirements communications.

4.2.8 Identify IT Business Analysis risks, assumptions & mitigation actions

Purpose: Ensure IT Business Analysis risks and assumptions are identified and suitable mitigation actions are designed.

Stakeholders: Sponsor, Customer, Domain SME*, Project manager*.


  1. Business Analysis approach
  2. RE activity plan
  3. Organizational risk database
  4. Past project experiences


  1. Identify sources of business IT Business Analysis risks.
  2. Identify business IT Business Analysis risks.
  3. Prioritize risks.
  4. Identify mitigation measures for critical risks.


  1. IT Business Analysis risks and mitigation plans

Tools and Techniques: Risk management, Requirements management plan.

4.2.9 Define constraints

Purpose: To identify factors other than requirements affecting the viability of solutions.

Stakeholders: All stakeholders, Implementation SME, and Project manager.


  1. Business constraints
  2. Technical constraints



  1. Document business constraints.
  2. Document technical constraints.


  1. Constraints

Tools and Techniques: Requirements templates.


  1. Documenting Requirements

5.3 Requirements documentation

Good requirements are foundations for successful projects. A good document design improves communication between stakeholders and increases quality of requirements. Requirement engineers MUST design appropriate documentation standard and adhere to the same. A requirements specification are collection of requirements, typically for a system or component.

Reasons for documentation

Requirements are basis of system development. Requirements influence all succeeding phases of project: analysis, design, implementation, test, acceptance and maintenance. Quality of requirements documentation has a strong impact on progress of the project and on its success.

Key reasons for requirements documentation are:

Communication vehicle among all stakeholders

Requirements documents serve as the primary communication medium among stakeholders.

Legal relevance

Non-fulfilment of requirements can become a legal issue for the organization. Documenting requirements helps the organization during legal conflicts.


Large systems have large number of requirements with complex interdependencies. Without proper requirements documentation, managing requirements will be near impossible task.


In a large and complex project, many stakeholders participate at different points in project life cycle.

Requirements MUST be accessible to all stakeholders for the project and even after completion of the project.

Sharing of knowledge

Requirements documentation helps in sharing and maintaining organizational knowledge about processes and business rules.

For future re-use

Requirements documentation helps in requirements reuse. Requirements reuse saves significant effort and time for the organization. Requirements documents may also contain relevant information which are helpful for current and future projects.

Use of requirements documents

Over course of the project, requirements documents serve as basis for different tasks:


Requirements documents are used to develop concrete work packages and milestones for implementation of system requirements.

Architectural design

Requirements documents are used to develop detailed requirements (along with constraints) which serve as basis for design of system architecture.


System is implemented by making use of architectural design and detailed requirements.


Test cases can be developed from requirements to be used for system validation.

Traceability management

Requirements documents are also used for managing traceability between requirements and other associated documents.

Change management

When requirements change, requirements document can serve as basis to analyze extent to which other parts of system are impacted, thus helping in estimation of change effort.

System usage and system maintenance

Requirements document can be used to analyze defects and shortcomings those are discovered during system use. For example, one can decide if a defect is a result of incorrect usage, a defective requirement, or an implementation error.

Contract management

Requirements document is prime aspect of a contract between a client and a supplier in most cases. During any dispute, requirements documents serve as the basis for dispute resolution.

5.4 Documentation types

Requirements can be documented in 3 different ways: natural languages, conceptual models and hybrid approach.

Requirements documentation using natural language

Advantages of using natural language

Most requirements originate as natural language text when stakeholders describe their needs. Text is natural to all stakeholders and no one needs to learn a new notation. Text can be used to express any kind of requirement and all 3 perspectives (Data – Logic – Behavior).

Disadvantages of using natural language

Natural language texts are prone to be ambiguous, leading to multiple interpretations. Requirements understandings can vary greatly depending on the stakeholder’s knowledge on the subject, their ability to express and understand. In natural language, it is also difficult to isolate information pertaining to a particular perspective, say data or behavior.

Requirements documentation using conceptual models

Advantages of conceptual models

Conceptual models decrease ambiguity (i.e., fewer ways to interpret requirements) than natural language due to their notation formalities. They depict requirements in a concise manner. It is easier for a trained reader to understand conceptual model than natural language.

Disadvantages of conceptual models

Conceptual models require specific knowledge of modeling symbols and texts appropriate to the perspective (Data – Logic – Behavior).

Hybrid requirements documents

Hybrid requirements documents use both natural language and conceptual models, hence overcome dis-advantages of both text and conceptual models.

Basic rules to enhance readability of requirements

  1. Short sentences: Limiting requirements to 10 words per sentence is a good practice to follow.
  2. Short paragraphs: As human memory is limited, use 7 or less sentences in a paragraph.
  3. Formulate only one requirement per sentence: Avoid long, complicated interlaced sentences.
  4. Use business terminology: Use terminology used in business than using technical terms.
  5. Define and mandate glossary: Stakeholders interpret same terms differently which is a frequent cause for conflicts in IT Business Analysis. To avoid these conflicts, everyone involved in development process MUST share same understanding of terminologies used. Glossary MUST contain all relevant terms.
  6. Use active voice: Active voice is always better than passive voice.
  7. Use models and matrices where ever possible: Using models and matrices improves requirements clarity.

5.4.1 Quality criteria for requirements

Quality criteria defined in IEEE standard can be used for individual requirements and requirements documents. In addition, few more quality criteria for individual requirements can be:


Must be needed by stakeholders and MUST fulfill their needs.


Requirements MUST be feasible given organizational, legal, technical, or financial constraints.


All stakeholders agree to the requirement.

Unambiguous (IEEE Std. 830)

It MUST not be possible to interpret a requirement in different ways. All readers of requirement MUST arrive at same understanding of requirement. One example of ambiguous requirement:

  1. System shall calculate time taken to complete a service request as Date of completion of service request minus Date of arrival of service request. One stakeholder may interpret this as Calendar days (Elapsed days) where as another stakeholder may interpret as Number of working days elapsed between arrival and departure.
  2. The system shall have ability to support multiple browsers. Which all browsers?

Consistent (IEEE Std. 830)

Requirements MUST be consistent with other requirements, i.e., requirements MUST not contradict one another, irrespective of their level of detail or documentation type. Requirements should not contradict themselves.

Verifiable (IEEE Std. 830)

Requirements MUST be testable. Example: System should be extremely user friendly. This cannot be tested as “User-friendliness” is undefined quantitatively.

Traceable (IEEE Std. 830)

Requirements must be traceable to their origin.

Complete (IEEE Std. 830)

Each individual requirement MUST completely describe functionality it specifies. Incomplete requirements MUST be marked, for example by adding "TBD” (“to be determined”) into description or using a corresponding status.

Each requirement MUST be documented completely. Describe all possible inputs, required responses, errors and exception cases and quality requirements for each desired system function.


Requirements MUST be understandable to stakeholders. Type of requirements documentation can vary significantly, depending on development phase (and therefore, depending on involved staff). It is important to strictly define terms and use them.

Correct (IEEE Std. 830)

A requirement is correct if it adequately represents idea of stakeholder. This also means that requirement should not express more than what stakeholder communicates.

Example: For any service request, actual end date of is always greater than actual start date. It may seem to be a correct requirement, but it is not. Correct requirement is, actual end date of a service request is always equal to or greater than actual start date of service request.

Ranked (IEEE Std. 830)

It is important to rank requirements, according to their importance, legal obligation, or priority.

Valid and up-to-date

Documented requirements MUST represent facts and conditions valid for current actualities.

5.5 Assigning attributes to requirements

Important attribute types for requirements

Identifier - Unique identifier of a requirement / artefact.

Name- A short description.

Description - Long description of the requirement.

Rank - Order of the requirement in a set of requirements. Rank should be unique in a chosen set of requirements for implementation.

Version - Current version of requirement.

Author - Specifies author of requirement.

Source - Specifies source of requirement

Stability - Specifies approximate stability of requirement. Possible values can be “Fixed”, “Established” and “Volatile”.

Criticality - Specifies impact of requirement on business. Possible values can be “High”, “Medium” and “Low”.

Priority - Specifies priority of requirement. Priority determines order implementation.

Assigned to - Specifies person, group of stakeholders, organization, or organizational unit that is responsible for the requirement.

Requirement type - Specifies type requirement (e.g., “Functional requirement”, “Quality requirement”, or “Constraint”).

Status regarding content - Specifies current status of requirement content, e.g., “Idea”, “Concept”, “Detailed content”.

Status regarding validation - Specifies current status of validation, e.g., “Un-validated”, “Erroneous”, “In correction”.

Status regarding agreement - Specifies current status of negotiation, e.g., “Not negotiated”, “Negotiated”, “Conflicting”.

Estimated Effort - Estimated effort to implement requirement.

Release - Release in which requirement shall be implemented.

Legal obligation - Specifies degree of legal obligation of requirement.

Cross references - Specifies relations to other requirements, for example, if it is known that implementation of requirement requires prior implementation of another requirement.

Remarks - Any information which is of stakeholders’ interest.

5.6 Prioritizing requirements

To prioritize requirements, follow these steps:

  1. Define goal (i.e., purpose) of prioritization.
  2. Document constraints of prioritization, such as availability of different stakeholders or resources available.
  3. Ensure requirements are at similar level of abstraction.
  4. Choose requirements prioritization criteria. Typical examples of requirements prioritization criteria:
  5. Choosing appropriate stakeholders to ensure required expert knowledge is available during prioritization.
  6. Select of the artifacts to be prioritized.

5.7 Requirements traceability

Requirements traceability is ability to trace requirements to business needs, work products based on requirements and relationships among requirements.

Benefits of requirements traceability

Aid in verification: Allows verifying whether a requirement has been implemented in the system.

Identification of unneeded properties / requirements in solutions: Traceability allows identification of unneeded properties / requirements solutions of developed systems. Tracing properties / requirements back to their origin allows identifying requirements that do not contribute to business need and system goal. Unneeded requirements should not be implemented.

Impact analysis: Allows for analysis of effects during change management. Allows identifying requirements and artefacts that MUST be changed when their underlying requirements change.

Reuse: Allows for reuse of requirements artefacts in other the projects.

Accountability: Traceability assists in determining accountability.

Maintenance: Traceability of requirements allows for simplified system maintenance.

Caution: It takes significant effort to establish and maintain traceabilities. Record information with clear purpose that it will serve.

Three types of traceability relationships

  1. Pre-requirements traceability are traceability links between requirements and those artefacts that are basis for requirements (Prior artefacts).
  2. Post-requirements traceability are traceability links between requirements and artefacts of subsequent development activities, such as components, implementation, or test cases (Posterior artefacts).
  3. Traceability between requirements is about mapping dependencies between requirements. For example, a requirement refines another requirement, generalizes it, or replaces it.

Representing requirements traceability

Traceability can be represented using textual references, hyperlinks, trace matrices and trace graphs.

Text-based references

Mentioning source artefact name / description in the target document.


Establish a hyperlink between initial artefact and target artefact.

Trace matrices, aka Traceability matrix, Coverage matrix

Trace matrices are tables where rows contain source (initial artefacts, requirements) and columns contain target artefacts (development artefacts). If a relationship exists between artefact in row “p” and a artefact in column “f”, cell (p, f) is marked.

Trace matrices are difficult to maintain as number of requirements increases. For example, a trace matrix documenting relation between merely 100 requirements contains over 10000 cells.

5.8 Versioning of requirements

Versioning of requirements aims at providing access to specific contents of requirements over time. Versions are marked by unique version numbers. Versioning can be applied to single text-based requirements, to entire requirements documents, and to models.

Requirements versions

When versioning requirements, one should distinguish between version number and increment number. For example, version number 4.2 references a requirement with version 4 and increment 2. As shown in figure, with smaller changes regarding content, increment is increased by one. If large changes are performed, version number is incremented. “V” is added in front of version number to make it easier to identify.




5.9 Requirements validation

3 quality aspects of requirements

Defined requirements quality criteria (e.g., completeness, understandability, agreement etc.) help to check requirements systematically. Requirements validation is carried out for:

* Content: Relevant requirements elicited and documented with appropriate level of detail.

* Documentation: Requirements documented as per defined guidelines and templates.

* Agreement: All stakeholders agree with documented requirements and known conflicts resolved.

Stakeholders should approve requirements for further development activities only when all three quality aspects are verified.

Using validation criteria for the quality aspects

Quality aspect “Content”

Validate requirements with respect to errors in content. The validation criteria are:

* Completeness of individual requirements

* Correctness and adequacy

* Consistent – Necessary – Testable - Realizable

* No premature design decisions.

* Traceable to business needs

Quality aspect “Agreement”

Validate requirements for agreement between stakeholders. During the project, stakeholders may change already agreed requirements as they gain new knowledge. Requirements are agreed with all relevant stakeholders and all known requirements conflicts are resolved.

5.10 Importance of requirements changes

Requirements change over during life of a system due to errors or incomplete requirements, evolution of context, changes in stakeholders’ needs, legal changes, new technologies, or additional competition in market etc.

Requirements changes per se may not be an issue as it may indicate stakeholders working closely with system and learning more about it. However, frequent requirements changes make it extremely difficult to develop a stable system. A high change frequency may also indicate inadequately performed IT Business Analysis. Frequent changes take up a lot of resources in project development.

Change control board

Change control board (CCB) evaluates and approves changes to requirements. It has following tasks:

> Classification of incoming change requests.

> Estimate effort for performing change.

> Evaluate CRs for desirability (Benefit vs. cost).

> Define new requirements based on CRs.

> Approve or reject CRs.

> Prioritize approved CRs.

> Assign approved CRs to change projects.

[Source: CPRE FL syllabus].

Representatives in change control board

CCB usually consist of following stakeholders: Change manager (Chairperson for CCB), Sponsor, Suppliers, Architect, Configuration manager, Customer representative, Product manager, Project manager, Quality assurance representative and Business Analyst.

Change manager mediates between parties in case of conflicts, negotiate decisions with respective parties, documents and communicates decisions.

Change request (CR)

Change requests document desired change and associated information. In agile methodologies, CRs are called "Product backlog". CRs typically contain following information:

  1. Identifier: Uniquely identify a CR.
  2. Title: Summarizes CR in brief statement.
  3. Description: Describes change, also information on effects of changes as well.
  4. Justification: Reasons as to why change is necessary.
  5. Date created: Date at which change request was filed.
  6. Requestor: Person who raised CR.
  7. Requested priority: Importance of CR as per requestor.
  8. Impact analysis status: Indicates whether impact analysis has been performed on CR.
  9. Acceptance status: Indicates CCB acceptance status.
  10. Accepted priority: CCB priority of CR.
  11. Assigned to: Person responsible for CR.
  12. Release: Release for CR implementation.

Classification of incoming change requests

CRs can be classified as:

  1. Corrective CR: CR raised for fixing a failure of system during its operation attributed to an error in requirements.
  2. Adaptive CR: CR raised for modifying system behavior due to change in stakeholder needs or change in system context.

CRs also can be classified as:

  1. Exceptional CR (hotfix): CR must be done immediately
  2. Normal CR (hotfix): CR which can follow planned release schedule.

Basic method for implementing CRs

* Can be tailored depending on organizational and project-specific needs.

Analyze impacted components

Identify all components (requirements, design, code, test cases, user manuals etc.) affected by change. Traceability matrices are helpful in analyzing impact of a CR. In absence of traceability matrices, Business Analysts should consult domain experts and development team to identify impacted components.

Estimate effort and cost

For each affected component, determine effort for implementing each change. Sum up efforts for finding total effort and then subsequent costs.

Evaluate and approve / reject CR

CCB evaluates CR based on objective criteria such as cost and benefit, availability of resources and approves / rejects the CR.

Prioritize CRs

CCB prioritizes approved CRs and assigns to projects or system releases for implementation.

Implement approved changes

Development team implements approved and prioritized CRs.

Validate requirement changes

CCB or person responsible validates implemented CRs.

  1. Elicit Requirements

6.1 Key concepts

6.1.1 What is elicitation?



6.1.2 Elicitation challenges

Some of the common challenges faced in elicitation are:

* Users omitting to identify requirements.

* Users and analysts taking certain knowledge for granted and failing to ensure a common understanding.

* Lack of clarity in the wordings.

* Ambiguity of written language.

* Conflicts between requirements.

* No way to test.

* Providing a solution rather than stating requirements.

* Lack of consensus among business users.

* Getting into solution domain.

6.1.3 Role of communication in IT Business Analysis

Natural languages are the most important means to communicate requirements. However, stakeholders may understand natural language requirements differently due to their knowledge and background. Effectiveness of natural language communication depends on familiarity of stakeholders on the subject, their past experiences, cultural and educational backgrounds, etc. Hence, it is important to develop common terminology (glossary) and defined requirements constructs, i.e. describe requirements using a standard structure, while communicating in natural language. Expressing requirements using standard constructs helps in not forgetting essential information while using natural languages.

Business Analysts can take help of modeling languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) which reduces ambiguity in communication using natural language.

6.1.4 Impact of communication mediums in IT Business Analysis

Communication mediums (written or spoken) have significant effect in requirements communication (or miscommunication). When communicating in natural languages, all stakeholders MUST consciously focus on direct and simple communication. In verbal communication, success of the communication relies on expressed language, gestures and feedbacks. But in written communication, these are absent. Many often, requirements may be communicated incorrectly due to natural transformations that occur during human perceptions

6.1.5 Language effects

Natural languages are inherently ambiguous and often interpreted in multiple ways. Requirements are described and referred by people with different knowledge, different social backgrounds and different experiences. Due to gaps in communications, developers develop something different from actual needs of stakeholders. Business Analysts MUST try to minimize such transformations and try to make requirements unambiguous.

6.1.6 Transformational effects

As transformational effects adhere to specific rules, Business Analysts can exploit this to elicit deep structures (i.e., what requirement providers really meant) from its surface structures (i.e., stated requirements).

5 most common transformational processes for requirements are:






Nominalization (Compression of activities)

Users tend to convert a long-lasting activity or group of nouns into a single event or noun, this is nominalization. For example, users may say “Manage schedule” when what they actually mean is “Create, Retrieve, Update, Delete, Import and Export schedule”. The way to minimize nominalization is to identify all verbs used in requirements. These verbs MUST be explained clearly in glossary and agreed upon by all stakeholders.

Nouns without reference index

Users tend to omit adverbs or use generic nouns. Common nouns which are incompletely specified are: user, system, message, data, or function. For example, let us study a requirement “Users shall update data using their devices”. The following questions arise: Which user? What data? Which devices? We can write the above requirements as: Privileged users can update schedule data using their laptops or mobile phones.

Universal quantifiers

Universal quantifiers group set of objects and generalize behavior or property for the group. Typical universal quantifiers are: All, always, every, never, no, none, or nothing etc. Most likely the specified behavior or property may not apply to all the objects in the specified group. Business Analysts MUST verify whether specified behavior or property really applies to all objects grouped through quantifiers.

For example, let us consider a requirement “The system shall not allow anyone to delete projects”. In this case, following question must be asked: “Can no employee actually delete the name? What happens if someone created a project by mistake?”

Incompletely specified conditions

Conditions are usually associated with words such as if... then, in case, whether and depending on. Stakeholders sometimes specify behavior that MUST occur when condition is met, but forget to specify what should occur if condition is NOT met.

For example, let’s consider requirement, “Only post graduates are eligible to attend the program”. In this example, at least one aspect remains unspecified: “Which programs shall be offered to graduates or lower”?

Business Analysts should use decision tables and decision trees for complex conditional structures.

Incompletely specified process verbs

Some verbs need more than one noun to be completely specified. For example, verb “Communicate” requires at least three aspects for completeness: “What is being Communicated, who is communicating and to whom it is being Communicated”. Formulating requirements in active voice minimizes incompletely specified process words.

6.1.7 Elicitation using requirements models

If you would have visited any new housing complex or a large building being constructed, you would have observed that a tiny replica is made with defined proportions, such as 100 meters: 10 centimeters. Such physical models allow designers and architects to visualize the entire property before constructing the actual property. They can understand if the open spaces will be adequate, what would be ideal places for provisioning the common amenities such as club-house, swimming pool etc.

Obviously, the model is the real thing but it serves a great purpose: Be a guide for the architects and engineers. Same way, Business Analysts can model requirements which often provides requirements in a condensed manner and aids in completing the missing parts of the requirements.

We can define models as: "Models are abstractions of an existing or desired reality”. Requirements models are usually diagrams, tables or mathematical equations. Requirements models make it easier to document requirements, understand requirements from different perspectives and reduce ambiguity.

Elicitation and documentation of requirements in the form of conceptual models offers following advantages:

* Information presented in pictures is quicker to understand,

* Allow the targeted modeling of one or multiple perspectives on the requirements.

Combining natural language and requirements models provides the advantages of both documentation types.

6.1.8 Aspects to take care during elicitation

While conducting elicitation, Business Analysts should carry out concurrent activities for eliciting, documenting, validating, capturing attributes, modeling, verifying, and confirming requirements. However, it is not possible to complete all the work during elicitation. Still Business Analysts should keep an eye on above mentioned activities to get quality requirements at source.

6.1.9 Elicitation techniques

Various techniques used for requirements development are:

  1. Survey techniques (e.g. interviews, workshops, questionnaires),
  2. Creativity techniques (e.g. brainstorming, brainstorming paradox, change of perspective, analogy technique),
  3. Document-centric techniques (e.g. system archaeology, perspective-based reading, requirements reuse),
  4. Observation techniques (e.g. field observation, apprenticing),

6.1.10 Factors influencing choice of elicitation techniques

Factors influencing the choice of elicitation techniques are:

  1. Type of requirement - Conscious, unconscious and subconscious requirements to be elicited,
  2. Desired level of detail of the requirements, Time and budget constraints,
  3. Availability of stakeholders, Risks of the project, Context, Organizational influences,
  4. Human influences: Experience of Business Analysts and stakeholders with particular elicitation techniques.

Techniques based on level of detail required

Level of requirement

Abstract requirements


Creativity techniques

(Interview, Brainstorming)


Capture subconscious requirements

Provide immediate feedback


Time and effort consuming

Level of requirement



Inquisitive (survey) techniques or observational techniques



Precise and unbiased.

Stakeholders unable to express their opinions can provide their inputs.

Cost effective.


Can be only employed to elicit requirements IT BA already knows.

Do not provide immediate feedback.

Creating right questionnaire is tricky, time-consuming and requires good knowledge of the domain.

Level of requirement

Finely detailed requirements


Document-centric techniques


Captures extensive details.


Takes time.

Can produce lots of requirements.

Techniques based on availability of stakeholders

Stakeholder availability


# of stakeholders



Interviews, Workshops

Stakeholder availability

Distributed, Large

# of stakeholders




Techniques based on risks of project






Interviews, Workshops

Observation and document-centric techniques

Techniques based on complexity of the project




Prototyping, Interviews, Workshops

Observation and document-centric techniques

6.2 Activities

6.2.1 Determine suitable elicitation techniques

Purpose: Determine suitable elicitation techniques to elicit requirements.

Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator, Supplier.


  1. Requirements context
  2. System scope


  1. Understand different types of requirements to be elicited.
  2. Determine suitable requirements techniques to elicit requirements.


  1. Identified elicitation techniques

Tools and Techniques: Brainstorming, Elicitation techniques chart.

6.2.2 Prepare for elicitation

Purpose: To prepare for conducting elicitations.

Stakeholders: Business Analyst.


  1. Identified Stakeholders
  2. RE activity plan


  1. Identify resources needed for conducting elicitations.
  2. Organize needed resources.


  1. Resources organized for elicitation

Tools and Techniques: Audio and video recordings.

6.2.3 Elicit requirements

Purpose: To elicit requirements from stakeholders and other sources.

Stakeholders: Sponsor*, Customer*, Domain SME*, End user*, and Regulator*,

Project manager, Implementation SME, Operational support, Tester, Supplier.


  1. Business need and solution scope
  2. Scheduled resources
  3. Supporting materials


  1. Elicit non-functional, functional and implicit requirements.
  2. Elicit regulatory, statutory, contractual requirements.
  3. Elicit current and future requirements.
  4. Elicit interface requirements.
  5. Ensure requirements expressed are aligned to business need and solution scope.
  6. Capture requirement attributes.


  1. Elicited requirements

Tools and Techniques: Requirements workshop, Interview, Observation, Survey/Questionnaire, Document analysis, Requirements Template.

6.2.4 Document elicitation results

Purpose: To document stakeholder and other inputs elicited during elicitation.

Stakeholders: Any stakeholder who has participated in elicitation tasks.


  1. Requirements (Stated, Unconfirmed).
  2. Stakeholder concerns (Unconfirmed).


  1. Document elicitation results with the stakeholders who provided the requirements.


  1. Documented elicitation results

Tools and Techniques: Backlog, Enumerated list, Minutes of meeting, Audio and video recordings, Issue log.

6.2.5 Confirm elicitation results

Purpose: To validate that stated requirements expressed by stakeholders match stakeholder’s understanding of the problem and their needs.

Stakeholders: Any stakeholder who has participated in elicitation tasks.


  1. Approved scope.
  2. Requirements (Stated, Unconfirmed).
  3. Stakeholder concerns (Unconfirmed).


  1. Verify alignment of elicited elicitation results to approved scope.
  2. Confirm elicitation results with the stakeholders who provided the requirements.
  3. Confirm requirements elicited from document analysis with Domain SME and Sponsor.
  4. Update business requirements document based on stakeholders’ feedbacks.


  1. Confirmed and prioritized requirements.

Tools and Techniques: Interviews, Observation.


  1. Analyze requirements

7.1 Key concepts

7.1.1 Models and their properties

Models are abstract representations of existing realities or desired realities. 3 important properties of models:

Mapping of realities:

Models map certain aspects of realities onto their modeling elements. Models can map existing realities, known as “As is” or “Descriptive models” or can map desired realities, also known as “To be” or “Prescriptive models”.

Reduction of realities:

Models reduce mapped realities through selection (only selecting a particular aspect, say for example only process steps for a system) and compression (providing high level overview than actual activities).

High level requirements for GRCPerfect, an Enterprise Governance Risk and Compliance management system


Detailed process requirement for defect management of GRCPerfect

Mapping exact realities will result in highly complex and large outputs and would need considerably higher efforts. Hence, purposefully, during modeling, we reduce the complexities. One can consider a simple rule, models provide 80% values with 20% investment. For rest 20% value, one needs to invest 80% effort which does not make business sense.

  1. Pragmatic property: Models are always constructed for specific purposes through selection or reduction, containing only information necessary for the respective purposes. The perspective could be data, flow, behavior (state) or user interaction. For example, above model only describes “Activity flow” for defect management. It does not describe data, state, or user interaction perspectives for defect management.

7.1.2 Elements of a conceptual modelling language

Modeling languages are defined by their syntaxes and semantics.

Syntax: Defines modeling elements and their valid combinations.

Semantics: Defines individual modeling elements and helps in interpretation of models.

Conceptual modeling languages are classified as formal (e.g. UML, BPMN) and informal (Flow charts, Swim-lanes) depending on degree of formalization.

Requirements models

Conceptual models that document requirements of a system are called requirements models. UML (Unified Modeling Language) is frequently used to develop requirements models. Extensive examples of modeling using UML can be found at OMG.ORG.

7.2 Activities

7.2.1 Organize requirements

Purpose: To organize requirements into appropriate requirements levels and categories.

Stakeholders: Domain SME, End user, Implementation SME, and Project manager.


  1. Confirmed requirements
  2. Organization process assets


  1. Organize requirements according to type of requirement (Functional, non-functional, constraint), level of requirement (High level vs. detailed).


  1. Organized requirements.

Tools and Techniques: Functional decomposition, Requirements templates.

7.2.2 Prioritize requirements

Purpose: To ensure project efforts focus on the most critical requirements.

Stakeholders: Sponsor*, Domain SME*, Implementation SME*, Regulator, and Project manager*.


  1. Business need
  2. Business case
  3. Organized requirements
  4. Requirement prioritization guidelines
  5. Stakeholder list, roles, and responsibilities


  1. Enhance requirements attributes.
  2. Prioritize requirements.
  3. Manage requirements prioritization challenges.


  1. Prioritized requirements

Tools and Techniques: Ranking, Decision analysis, Risk analysis, MoSCoW analysis, Time-boxing, Budgeting and Voting

7.2.3 Model and elaborate requirements

Purpose: To model and elaborate prioritized requirements using a combination of matrices, diagrams, and mathematical formulas.

Stakeholders: Domain SME.


  1. Prioritized requirements


  1. Elaborate requirements.
  2. Model requirements.


  1. Modeled requirements

Tools and Techniques: Data flow diagram, Functional decomposition, Interface analysis, Non-functional requirements analysis, Organization modelling, Process modelling, Prototyping, Scenarios and use cases, State diagrams, and User stories, Matrix model, Use case specifications, Flow charts, Decision tables, Activity diagram.

Models for schedule management


7.2.4 Prepare requirements package

Purpose: To package set of requirements in an appropriate manner for effective stakeholder communication.

Stakeholders: Primary responsibility of Business Analyst.


  1. Business analysis communication plan.
  2. Organizational process assets.
  3. Requirements.
  4. Requirements structure.


  1. Prepare work products, and deliverables.


  1. Requirements package.

Tools and Techniques: Requirements documentation, Requirements for vendor selection.

7.2.5 Verify requirements

Purpose: To ensure requirements and packages meet necessary standards of quality. To identify defects in the requirements before presenting to other stakeholders.

Stakeholder: Primary responsibility of Business Analyst.


  1. Packaged requirements
  2. Requirements quality criteria.


  1. Review requirements.
  2. Update requirements based on review.


  1. Verified requirements

Tools and Techniques: Requirements review checklist, Commenting, Inspection, Prototyping, Peer review, Structured walkthrough.

7.2.6 Validate requirements

Purpose: To validate verified requirements before sharing the requirements for development or procurement.

Stakeholders: All key stakeholders.


  1. Business need and solution scope.
  2. Verified requirements.


  1. Communicate review schedule.
  2. Present requirements for review.
  3. Gather observations during the review.
  4. Seek information from documentation or stakeholders for the queries or clarifications raised by stakeholders.
  5. Update requirements document with stakeholder feedbacks.
  6. Obtain approval on requirements.


  1. Minutes of review meeting
  2. Approved requirements

Tools and Techniques: Group review, Structured walkthrough, Inspection, Prototyping, Perspective based reading.

  1. Manage requirements

8.1 Key concepts

Requirements management knowledge area describes following tasks:

* Allocate requirements

* Communicate requirements

* Manage requirements changes

* Manage IT Business Analysis activities, risks and performance

* Manage requirements conflicts

* Define transition requirements

* Define interface requirements

* Validate new / improved solution

* Identify workarounds and future improvements



Requirements management manages individual requirements as well as complete requirements documents. It documents information about requirements throughout entire life cycle of a system. This includes, unique identifiers, name, author, person responsible and sources of requirement.

8.1.1 Significance of requirements conflicts

Requirements conflicts occur when stakeholders disagree on requirements. For example, one stakeholder may like to include a feature which another stakeholder may prefer to keep out. Unresolved requirements conflicts have negative impacts on the project including:

  1. Stakeholder dissatisfaction.
  2. Poor return on investment.
  3. Some stakeholders’ requirements not implemented.
  4. Operational system not accepted.
  5. Operational system not sufficiently used.

At the same time, conflicts provide opportunity for Business Analysts to discover potential new ideas and different options for development. Resolving conflicts increases acceptance of the system. Requirements negotiation aims to develop consensus on requirements among relevant stakeholders. Requirements negotiation MUST be performed throughout IT Business Analysis needing additional efforts and costs. However, advantages of requirements negotiation (reduction of overall cost, increase in acceptance, supporting creativity and innovations) is significantly higher than these additional costs.

Conflicts arise during throughout IT Business Analysis activities. Stakeholders provide contradicting requirements during elicitation. Business Analysts should identify potential conflicts early so that they can be analyzed and resolved early.

8.1.2 Workarounds

When a problem is identified with the solution (i.e. a failure to meet a stakeholder need, whether or not the requirement was correctly specified), Business Analysts help the team to determine the most appropriate action.

Some solution components, especially software applications, may require an Implementation SME to investigate the root cause of problems. Identify defects which MUST be rectified, which can be mitigated through workarounds or other approaches, and which can be accepted until resources are available to address them. If a defect cannot be resolved in an acceptable timeframe (due to complexity, or cause not identified, or not of high priority, etc.), and stakeholders cannot accept the defect, investigate options for mitigating the effects. Options can be additional quality control checks, new manual processes, removal of support for certain exception cases, etc.

In spite of project and implementation team’s best efforts, situation could arise that the solution is not able to handle certain requirement(s). In such a situation, Business Analyst should identify possible workarounds. Workarounds are useful that they may not be the most elegant solution but they are highly cost-effective and can be implemented in a short duration.

8.2 Activities

8.2.1 Allocate requirements

Purpose: To allocate solution requirements among releases, and solution components to maximize possible business value.

Stakeholders: Sponsor*, Domain SME*, Project manager*, Implementation SME*, Customers, Suppliers, End user, Operational support, Tester.


  1. Approved and prioritized requirements
  2. Release plan
  3. Solution components


  1. Compute capacity of the releases.
  2. Allocate requirements among releases and solution components.


  1. Allocated Requirements

Tools and Techniques: Release plan.

8.2.2 Communicate requirements to stakeholders

Purpose: To communicate validated requirements to stakeholders.

Stakeholders: Sponsor*, Domain SMEs*, Implementation SMEs* / Procurement team*, Testers*, Support team.


  1. Requirements communication plan.
  2. Validated requirements.


  1. Share validated requirements with stakeholders.
  2. Send meeting invites if needed.
  3. Explain requirements.
  4. Clarify questions.
  5. Explain rationale behind selection / non-selection of requirements.


  1. Minutes of meeting.

Tools and Techniques: Structured walkthrough, Email.

8.2.3 Manage IT Business Analysis activities, risks and performance

Purpose: To manage performance of IT Business Analysis activities to ensure they are executed as effectively as possible. Monitor and report IT Business Analysis progress and take necessary corrective actions.

Stakeholders: Sponsor, Project manager.


  1. Defined IT Business Analysis metrics.
  2. IT Business Analysis performance


  1. Prepare IT Business Analysis performance reports.
  2. Review IT Business Analysis plan, risks and performance with key stakeholders.
  3. Identify corrective actions to meet desired performance level.


  1. Corrective actions.
  2. Updated IT Business Analysis activity plan.

Tools and Techniques: Status Reporting, Variance analysis, Problem tracking

8.2.4 Manage requirements changes

Purpose: To effectively manage requirements changes.

Stakeholders: PM*, Domain SME*, End user, Sponsor, CCB*.


  1. Suggested requirements changes.


  1. Record requirements changes.
  2. Determine if change is acceptable as per project change management policy.
  3. Propose change to change control board.
  4. Update requirements documents once change is accepted.


  1. Accepted requirements changes.

Tools and Techniques: Requirements Change management, Problem / Issue Tracker, Brain storming.

8.2.5 Manage requirements conflicts

Purpose: To effectively manage requirements conflicts.

Stakeholders: PM*, Domain SME, Sponsor, End user*, Implementation SME.


  1. Requirements conflicts


  1. Record requirements conflicts.
  2. Explore options to manage conflicts.
  3. Decide on the action for the conflict.


  1. Resolved conflicts

Tools and Techniques: Conflict management, Problem / Issue Tracker, Brain storming.

8.2.6 Define transition requirements

Purpose: To define requirements for transitioning from an existing solution to a new solution.

Stakeholders: Sponsor*, Implementation SME*, Domain SME*, Project manager*, End user, Operational support.


  1. Existing solution data model
  2. New solution data model
  3. Stakeholder list


  1. Determine data migration requirements.
  2. Map data elements between existing application data model and New / Updated application data model.
  3. Develop transformation rules, if needed.
  4. Determine options to perform ongoing work, and new solution concurrently for defined duration.
  5. Plan for end user trainings, if needed.
  6. Manage organizational change.
  7. Manage on-going work along with new work.


  1. Transition requirements
  2. Training plans (Optional)
  3. Data migration approach

Tools and Techniques: Business rules analysis, Data flow diagrams, Data modeling, and Data mapping template.

8.2.7 Define interfacing requirements

Purpose: To define requirements for interfacing new application with existing applications.



  1. Existing solution data model
  2. New solution data model
  3. Stakeholder list


  1. Determine data interfacing requirements.
  3. Decide interfacing frequency


  1. Interfacing requirements

Tools and Techniques: Data flow diagrams, Data modeling, Data mapping template, Interfacing template.

8.2.8 Identify workarounds and future improvements

Purpose: To validate that a solution meets the business need, and determine the most appropriate response to identified defects.

Stakeholders: Domain SME, Implementation SME, End user, Sponsor, Project manager, Tester, Operational support, and Regulator.


  1. Solution (Constructed)
  2. Requirements (Prioritized, and Validated)


  1. Investigate defective solution outputs.
  2. Assess defects, and issues.
  3. Identify possible workarounds to defects where developing permanent solutions may not be gainful.
  4. Obtain feedback from stakeholders on the workarounds.


  1. Identified defects
  2. Mitigating actions
  3. Solution validation assessment

Tools and Techniques: Acceptance evaluation criteria definition, Problem tracking, and Root cause analysis, Workarounds.

Acknowledgements and Bibliography

  1. A Guide to Business Analysis Body of Knowledge v2.0. International Institute of Business Analysis. Toronto: IIBA, 2009. PDF and eBook.
  2. Syllabus for CPRE Foundation Level examination, IREB, Germany
  3. Rupp, Klaus Pohl and Chris. A Study Guide for the Certified Professional for Requirements Engineering Exam Foundation Level 2nd Edition. Rocky Nook Inc., 2015. Kindle and Paperback.
  4. Business Analysis, Debra and Paul, British Computer Society
  5. Podeswa, Howard. The Business Analyst's Handbook. Boston: Course Technology, 2009. Paperback.
  6. UML for the Business Analyst, Second Edition. Boston: Course Technology, 2010. Paperback.
  7. James Cadle, Debra Paul and Paul Turner. Business Analysis Techniques. Chippenham: British Informatics Society Limited, 2010. Paperback.






Related Posts

Business Analysis Technique - Business Capability Analysis

Image of Ann P
Ann P


Read more

World's Largest Listing of Business Analysis Terms

Image of LN Mishra, CBAP, CBDA, AAC & CCA


Read more