You are here

Home

Business Analysis

Business analysis techniques

Often there are several different methods a business analyst could use to complete a task. Each method for completing a task is called a technique.

Techniques also provide information about the different forms that a task's output might take. For example, some techniques might produce outputs in a form that the business analyst will use to deliver information to stakeholders, such as a status report or a process checklist.

Techniques affect the performance of tasks. For a method to be a technique, it has to be related to at least one task. Some tasks have several related techniques, from which the business analyst chooses the technique that best suits the situation.

Tasks may have no related techniques, one, or several related techniques.

There are no techniques that business analysts are required to use.

There are so many different techniques that the BABOK® Guide documents only the ones that have already been tried and tested, and have demonstrated value. These are the techniques that the business analysis community uses most often.

Some of the techniques that are widely used include

  • acceptance and evaluation criteria definition
     
  • brainstorming
     
  • business rules analysis
     
  • data dictionary and glossary
     
  • data flow diagrams
     
  • data modeling
     
  • decision analysis
     
  • document analysis, and
     
  • interviews
     

Other widely used techniques include

  • metrics and key performance indicators
     
  • nonfunctional requirements analysis
     
  • organization modeling
     
  • problem tracking
     
  • process modeling
     
  • requirements workshops, and
     
  • scenarios and use cases

 

Question

What do business analysts use techniques for?

Options:

  1. To complete tasks
  2. To demonstrate value
  3. To determine methods

Answer

Option 1: Correct. Tasks have none, one, or several related techniques that business analysts can choose from to complete the task. They also provide information about the form that a task's output might take.

Option 2: Incorrect. Techniques are used to complete tasks. Some techniques are more relevant and more valuable than others.

Option 3: Incorrect. Methods that are related to at least one task are called techniques. Techniques are used to complete tasks and determine the form that a task's output might take.

 

Sometimes similar techniques that share a purpose are grouped under a single heading. The data modeling technique, for example, covers the use of class models, entity relationship diagrams, concept maps, term and fact models, object role models, and other similar techniques.

Although there are many less well-known techniques that competent business analysts might not be familiar with, business analysts should have a working knowledge of the more widely used techniques. This will enable them to perform tasks effectively in most of the situations they are likely to encounter.

A widely used technique might not always be the best possible technique to use in a given scenario. There might, for example, be a quicker or more effective solution. However, it's unrealistic to expect business analysts to be able to recall and demonstrate the expertise necessary to use every kind of technique.

In the BABOK® Guide, all techniques include

a purpose
The purpose describes what the technique is used for and the situations in which it is most applicable.
 
a description
The description covers exactly what the technique is and how it is used.
 
elements, and
The elements are key concepts that the business analyst needs to understand to use the technique. Each technique has a unique format and structure.
 
usage considerations
The usage considerations are the conditions under which the technique will remain effective
 
 

Question

For which purposes are techniques used in business analysis?

Options:

  1. To describe ways of completing tasks
  2. To provide information on forms that an output might take
  3. To provide value to the sponsoring organization
  4. To describe the best possible way to complete a task
  5. To determine a task's usage conditions

Answer

Option 1: Correct. A technique is a way that a business analyst can complete a task. Tasks might have no related techniques or one or more related techniques.

Option 2: Correct. Techniques provide additional information about the different forms that task outputs might take. Some techniques, for example, are designed to produce certain types of outputs.

Option 3: Correct. A technique is a method for completing a task. A task's output provides value to the sponsoring organization.

Option 4: Incorrect. Some tasks have more than one related technique. Depending on circumstance, certain techniques might be more valuable than others.

Option 5: Incorrect. Techniques have usage conditions, which describe the conditions under which they will remain effective. Usage conditions don't apply to tasks.

What are The Business analysis tasks

Each of the six business analysis knowledge areas has a purpose. The purpose of the Requirements Analysis knowledge area, for example, is to determine a solution to meet stakeholder needs.

A knowledge area is made up of tasks, each of which also has a purpose. Business analysts perform these tasks to accomplish the overall purpose of the knowledge area.

Although each business analysis task is unique, there are several characteristics that all tasks share:

  • they must be completed in order for the purposes of the associated knowledge areas to be achieved
     
  • they produce positive results that are valuable to the sponsoring organization, and
     
  • the results of tasks can be used as inputs for succeeding tasks, which may be performed by other people
     

Tasks are essential to the success of a business analysis initiative. Every task should be completed at least once during the course of an initiative. However, there is no limit on the number of times a task may be completed.

You might, for example, need to perform a task several times in order to determine an organization's current or future state.

There is no prescribed order for tasks. Business analysts can complete tasks in any order, as long as they possess the data needed to perform the tasks and produce results.

The data you require to perform a task sometimes changes over the course of an initiative. When this happens, the task might need to be completed more than once to produce updated results.

Business analysis initiatives may have iterative or agile life cycles. This dictates whether a business analyst performs several tasks in parallel, or breaks a project into specific phases and perform tasks from several knowledge areas during each phase.

Question

In what order are tasks performed?

Options:

  1. Tasks may be performed in any order
  2. Tasks are performed simultaneously
  3. Tasks are performed at the start of a project and upon its completion

Answer

Option 1: Correct. There is no prescribed order for tasks, but they each need to be performed at least once during an initiative.

Option 2: Incorrect. Tasks can be performed in any order and at any time, as long as you possess the required data to complete the task. During iterative projects, tasks are sometimes performed in parallel.

Option 3: Incorrect. Tasks can be performed in any order, as long as each one is performed at least once during a project.

Correct answer(s):

1. Tasks may be performed in any order

The only prerequisite for performing a task is that the data required to complete it is available. This data is called an input.

Task inputs may be generated by one of two types of sources:

  • by a business analysis task or
     
  • externally, outside the scope of business analysis activities
     

When you use an input to perform a task, generating a result doesn't necessarily mean that you've completed the task or fulfilled its purpose.

Instead, inputs and results might simply provide you with input for your next task, or enable you to begin performing additional work. For example, you might use several inputs to perform a single task several times. The results might enable you to examine several scenarios or move forward to an additional task.

Requirements are an important aspect of business analysis. They are the only inputs that are not produced from a single task. Requirements can be stated and classified in a number of ways when they're used as inputs. Sometimes no state or classification is listed and, in this case, any requirements can be used.

In most cases, a requirement is first listed by its state and then by its classification. For instance, stated requirements indicate that any classification can be used.

Stated requirements.

When there's no state listed, business requirements can be used in any state – prioritized, verified, or stated.

Business requirements.

Sometimes states are combined to describe requirements that have two states or to group all requirements that currently have either state. Requirements might, for example, be prioritized and verified.

Prioritized and verified business requirements.

The elements of a task describe the important concepts that business analysts need to understand in order to perform the task. They include aspects of its format and structure.

Because each business analysis initiative is specific, each task's elements are also unique.

Different sorts of tasks affect and require input from different kinds of stakeholders. For every task, a business analyst should list stakeholders who might be affected by or involved in performing the task.

Given that each business analysis task is unique, it would be impossible to create a list of all the possible stakeholders. In most cases, specific stakeholders' roles are included within broader, generic categories.

  Generic stakeholder categories in project include:

Business analysts

Business analysts are responsible for executing a project's business analysis activities, so they are stakeholders by default.


Sometimes business analysts are also responsible for roles that would normally be classed in different stakeholder categories. For example, business analysts sometimes perform subject matter expert, project manager, or tester roles, as well as performing business analysis activities.
 

Customers

Customers are internal or external stakeholders in a project or initiative. They are the people who use the products and services that a project or initiative provides. For example, if a project was implementing a new database in an organization, the customers would be the user group in the department using the new database.

Domain subject matter experts

Organizations sometimes also have contractual standards that they need to meet to uphold customers' moral rights.
Domain subject matter experts, or SMEs, are people with in-depth knowledge related to a business need.

Sometimes SMEs are also end users, managers, consultants, or legal staff. These are individuals who might use the project solution indirectly.
The term end users is most often used in software development. An end user is someone who interacts directly with a solution. In the software development environment, and end user refers to the individual who will actually use a software application once it is developed.
 

End users

In more general terms, an end user is anybody that participates in a business process.

Implementation subject matter experts

Implementation subject matter experts possess the expert knowledge necessary to design and implement the solutions that business analysts recommend.
 
Although there are too many kinds of implementation SMEs to mention, the more common kinds include software engineers, organizational change management professionals, system architects, trainers, and usability professionals.

Other generic stakeholder categories include

Project managers

Project managers are responsible for implementing the solutions that business analysts recommend. It's their responsibility to ensure that project objectives are met and to balance project constraints.

Constraints might include scope, budget, risk, resources, or schedule limitations.

Testers

Testers are responsible for ensuring that solutions meet the requirements that business analysts have specified.

They are also responsible for verifying that solutions meet quality standards, for minimizing the risk of failures and defects, and for ensuring this risk is understood.
Regulators are responsible for determining and enforcing standards. These might be standards that a solution must meet or standards that the team developing the solution must meet.

Regulators

Regulators help to enforce legislation, corporate governance standards, and audit standards. They also help to ensure that standards enforced by organizational centers of competency, such as business competency centers, are met.

Sponsors

Sponsors authorize business analysis initiatives. It is their role to instigate efforts to define business needs and find solutions that will meet these needs.
Suppliers are considered external stakeholders because they aren't usually part of the organization that is conducting a business analysis initiative. They are responsible for providing products or services to the organization.

Suppliers

Suppliers might have contractual or moral rights that organizations need to respect.

The results produced on the completion of a task are called outputs. An output is either a deliverable in itself or part of a larger deliverable.

A single output is usually created by a single task. However, it is possible for a task to have multiple outputs – for instance, when a single task is completed several times. Successfully completed tasks result in new outputs, outputs that are transformed, or outputs that have changed state.

The form an output takes depends on these factors:

  • the type of initiative or project being conducted
     
  • the sponsoring organization's standards, and
     
  • the form in which the business analyst will deliver information to stakeholders
     

For instance, in a business analysis project that includes accountants and financial clients as stakeholders, the business analyst would want to present information in a form that the stakeholders can understand. In this case, the accountants and financial stakeholders might be interested in financial data such as expenditure and budget, which you could present to them in a spreadsheet.

Because there is no prescribed order for performing tasks, an output doesn't necessarily mean that subsequent tasks using that output as an input should then be completed. Task outputs are often part of a larger deliverable and might not be in their final state. Outputs need only be in a state that enables subsequent work to begin.

 

Question

Identify the statements that describe the characteristics of business analysis tasks.

Options:

  1. They are used to accomplish the purpose of an associated knowledge area
  2. They produce positive and valuable outputs
  3. Their outputs cannot be used as inputs for subsequent tasks
  4. Requirements they use as inputs each exist only in a single state

Answer

Option 1: Correct. Just as each business analysis knowledge area has a purpose, each business analysis task has a purpose. A task's purpose supports achievement of the overall purpose of the associated knowledge area.

Option 2: Correct. The result or outputs of business analysis tasks are valuable to the sponsoring organization. Outputs are either deliverables or form parts of larger deliverables.

Option 3: Incorrect. Completed business analysis tasks produce outputs, or results, which can be used as inputs for tasks that follow.

Option 4: Incorrect. When used as inputs for tasks, requirements can be classified in different ways and exist in several states.

Correct answer(s):

1. They are used to accomplish the purpose of an associated knowledge area
2. They produce positive and valuable outputs

Types of Requirements

A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as in (1) or (2).

 Business Requirements - Are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.

User Requirements - Are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.

Functional Requirements - Describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.

Quality of Service Requirements  - Capture conditions that do not directly relate to the  behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements.

Assumptions and constraints - Identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.

Implementation requirements - Describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.

Joint Application Development (JAD) Technique

The Joint Application Development (JAD) technique is an extended, facilitated workshop.  It involves collaboration between stakeholders and systems analysts to identify needs or requirements in a concentrated and focused effort.

Advantages 
• This technique allows for the simultaneous gathering and consolidating of large amounts of information. 
• This technique produces relatively large amounts of high-quality information in a short period of time.
• Discrepancies are resolved immediately with the aid of the facilitator.
• This technique provides a forum to explore multiple points of view regarding a topic.

Disadvantages 
• Requires significant planning and scheduling effort.
• Requires significant stakeholder commitment of time and effort.
• Requires trained and experienced personnel for facilitation and recording.

JAD Process Steps 
1. Define Session: Define the purpose, scope, and objectives of the JAD session, selecting the JAD team, invite and obtain commitment to attend sessions from the appropriate stakeholders, and schedule the session.
It is important to obtain management commitment to support the process and identify the appropriate stakeholders. 
2. Research Product: Become more familiar with the product or service, gather preliminary information, obtaining any models.
3. Prepare: Prepare any visual aids, developing a realistic agenda, training the recorder, and preparing the meeting room.
4. Conduct Session: Follow agenda to gather and document the project needs and requirements.  It is important to ensure all participants are given equal treatment during the process.
5. Draft the Documents: Prepare the formal documents.  The information captured in the JAD session is further refined through analysis efforts, open questions or issues discovered through the sessions are resolved, and the final document is returned to stakeholders for review and validation.

Roles 
The JAD team is the very heart of the JAD process and the selection and inclusion of stakeholders are critical to the overall success of a JAD session.  The team should consist of a mixture of skills from a variety of individuals.  The participants may include Business Process Owners, Operations Managers, Client Representatives, Business Analysts, Business Managers, End Users, Data Administrators, Systems Analysts, System Designers, Business Analysts, Advisors Project leaders, Auditors, Security, Standards, Vendors, Quality Assurance, Contingency Planners, Production Planners, IT Specialists, Human Resource Representatives, and Trainers.

Executive Sponsor 
Management commitment is required for any needs or requirements gathering process to succeed.  It is very important for the JAD session team to have a management sponsor.  The executive sponsor may be a manager of the business area whose needs and requirements are being addressed during the JAD session.  The sponsor does not have to actively participate in every JAD session.  It might be advisable to attend the first JAD session to show support and, perhaps, the final JAD session to review the results and make comments.  The sponsor should be available throughout the period of the JAD process to solve any serious problems or issues that may arise.  The JAD facilitator must work closely with the management sponsor and provide full briefings on progress.

Facilitator 
The facilitator is the key person in the group and is responsible for planning, executing and managing the session.  They should be a respected, skillful leader with a good reputation within the organization.  JAD facilitator skills do not happen by chance, and the skills may have to be learned through specialized training and experience.  The choice of facilitator may mean the difference between a good session and a poor one.  It is essential that the facilitator be given authority to work closely with the executive sponsor to achieve the objectives of the JAD session.  The facilitator will know how to direct people, to be able to get the best information from them.  JAD Facilitators should be able to:
1. Focus on the process, not the information content, of the JAD session.
2. Be unbiased and neutral, and remain impartial.  It is important that the reporting structure is such that the facilitator cannot be influenced or biased.
3. Use organizational skills to lead groups and keep the sessions on track.
4. Ensure each subject under discussion is accurately recorded and completed to the stakeholders’ satisfaction before proceeding.
5. Stop sideline conversations.

Recorder 
The recorder is responsible for documenting the JAD sessions.  This must be done in an interactive fashion and the recorder must work closely with the JAD facilitator.  Many ideas and suggestions will be discussed. A large session may need multiple recorders.  The recorder must capture the important discussion and decisions made, who made them and why.  Laptop computers, white boards, flip charts, or overhead devices are particularly useful.
It is the responsibility of the recorder to distribute and file the documentation at the end of each JAD session or as soon as possible after the session or topic has concluded.  It can be a difficult task and should not be underestimated.  The recorder should have the following skills:
1. Knowledge of the stakeholder business area.  In order to record the results properly, the recorder needs to understand the concepts of what was discussed.
2. Excellent analytical skills.  The recorder needs to be able to analyze what was discussed and presented in the JAD session.
3. Experiences with JAD tools if any are used.  The JAD tool may be a word processing software, an electronic whiteboard, or a CASE tool.  Whatever tool is used, the recorder has to have a good knowledge of how to use the tool effectively.
4. Good technical writing skills.

Stakeholder 
The participation of stakeholders in the JAD session is widely accepted as essential to its ultimate success.  Without their involvement, the JAD session will not be productive.  The whole point of a JAD session is to bring stakeholder and performing organization together in a structured environment.  Stakeholders will rapidly gain a sense of involvement and ownership in the product or service development where a JAD session is used.  This is vital to its overall success.  Most important, the stakeholders will get the product they want and not one that has been designed poorly for them.  
 

Related Articles:

1. Interview Technique : http://directutor.com/content/interview-technique-requirements-gathering-techniques
2. Survey Method: http://directutor.com/content/survey-method-requirements-gathering-techniques
3. Joint Application Development (JAD) Technique : http://directutor.com/content/joint-application-development-jad-technique  

Subscribe to Business Analysis