Category Archive ECBA Resources

User Stories Basics

User Stories Basics

User Story is a popular requirements modelling tool. In this post, we will learn about user stories basics, structure of user stories, INVEST theory for user stories. We will also look at an example user story model.

What are user Stories?

User Story is a popular format of representing a feature or user requirements of a software system from an external user perspective. The format comprises of three key elements as shown below:

As a <User role>

I want <to do something>

So that I can <achieve some goal>

The user role represents a type of user (and not an individual user). The requirements are presented from this user role perspective – <to do something>. The third part of the user stories is the purpose of the action.

The user stories, not only, represent the system feature/requirements, it also explains – why it is being done?

User Story Example

Let’s a simple example to understand the user stories basics better. A customer is looking to get a travel portal for flight tickets booking. One of the requirements for this portal is the search of flight tickets for a business traveler.

The user story for this case can be presented as shown below:

As a <User>

I want <to search for flight tickets as per my schedule>

So that I can <so that I can attend a business conference>

The good thing about user stories is that every stakeholder (customer as well as developers) gets a complete idea about the requirements.

Writing good user stories

What are the characteristics of a good user story? Well-written user stories are critical to the success of a project. INVEST represents the characteristics of a good user story as explained below:

  • Independent – User Stories should be as independent as possible.
  • Negotiable – User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
  • Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
  • Estimatable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
  • Small – User Stories should be small. Not too small. But not too big.
  • Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

INVEST guidelines can also be used to review the developed user stories.

More on User Stories

I am going to post more articles/Videos on this subject. These user stories posts are going to be:

User Stories 3C model (Article)

User Stories Modelling in Agile Projects (Video)

About Techcanvass

Techcanvass is an IT certifications training academy offering courses in Data Science, Business Analysis and Automation testing.

We are an IIBA Endorsed education provider (EEP) and iSQI authorized training partner. Our business analyst courses are for all the levels as shown below:

ECBA Certification Training

 

 

 

 

 

 

Agile Business Analyst Training

 

 

 

 

CBAP Certification Training

Selecting the right business analyst training provider

Selecting the right business analyst training provider

If you are searching for a business analyst training program, I am sure you will get a lot of options to choose from. Selecting the right business analyst training provider can be a daunting task. More so because the courses don’t come cheap so you can’t use trial and error technique.

Disclaimer: I represent an IT certification training provider, TECHCANVASS and we are into business analyst training courses. However, I have tried to write this article considering myself as someone who is looking to find the right training provider.

So, how do you go about selecting the appropriate business analyst training provider? I have shortlisted the top 7 parameters to select the right training provider for business analyst training.

Think like an Employer

Even before you start searching for training providers, you must put yourself in an employer shoes and consider the skills you will be expecting for this role. As an entry level business analyst, what is going to be your role and which skills will enable you to perform the role efficiently?

So understanding the requisite skills for an entry level business analyst will be first step. Let me help you with the top 6 skills for an entry level business analyst:

a) Ability to engage customers for requirements elicitation/gathering

b) Capability to manage requirements (traditional and Agile)

c) Ability to conduct requirements analysis and modelling (UML modelling, prototyping etc)

d) Basic SQL knowledge (Querying)

e) Ability to develop and manage SRS/FS or Product Backlogs

f) Capability to verify and validate requirements

You can use these skills as a benchmark to compare the courses offered by a training provider and shortlisting initial few.

Training Provider credibility

Once you have factored in the course content and shortlisted the training providers, the next step is to evaluate them on their credibility. So, How do you evaluate  the credibility of a training provider?

  • Will you decide based on brand?
  • or can you decide based on friend’s recommendations?
  • or would you decide based on Internet feedbacks?
  • or should you decide based on “Authorized Training provider” status

In my view, no single factor is dominant in this case. All these factors should be considered in shortlisting a training provider.

Let me help you with some scenarios:

A company is known because lot of people like it or is it known because it is visible everywhere? Many brands are well known because they spend a lot of money on advertising and are visible everywhere?

Your friend has recommended a training provider on heresay or he/she has done a course from that particular training provider.

Last few feedbacks for a training provider is negative or positive. That does not make a company good or bad. Look at the percentage of feedbacks over a period of time (at least a year or 2 years).

 

Dig deeper – Ask for demo or review their content

The next step is to evaluate the depth and skills of their trainers. You can ask for a demo or ask for class recordings. The class recordings are the best representation of trainers teaching style and depth of knowledge.

Most of the training providers should have class recordings available on their Youtube channel or website itself. If you feel comfortable listening to these, it’s a big YES.

However, be careful, don’t just decide on the basis of one video as that could be the best one and only one.

Right Training mode for you

Which is the most appropriate training mode for you? Would you prefer classroom training or live online training or self-paced training?

It’s purely dependent on your availability, work schedule and style of learning. Does the training provider provides training in that particular mode? Please be aware that, there are advantages and disadvantages of each of the approaches.

An important consideration is the availability of recorded sessions in case you miss a class. This is quite common because of work schedule, family commitments etc. If you get access to recorded sessions, that will help you in maintaining continuity.

Training support

Does the training provider offers support of any kind? Can you ask questions after the classes? Sometimes you may not feel comfortable asking a question in the class for whatever reasons? Is there any provision for getting answers later? Or is there is any channel for submitting your questions and doubts?

The training provider can provide support in one of the following formats:

  • A lively discussion forum
  • Email support

I know a couple of training providers, who have lively discussion forums where students ask questions and these questions are answered by trainers.

 Project Work

Another important criteria is the project or projects? Does the course include projects which will help you in applying all the concepts and processes learnt?

For example, does the course provide you with software projects where you can learn to develop and model requirements in a system requirements specification (SRS) document? Can you do a project to create user story cards or learn to manage product backlogs?

Working on these projects enables you to be confident during the interview (as you have done it yourself). At the same time, it also allows you to showcase in your resume making it more credit worthy.

 

The Training cost

The training cost is the last but certainly not the least parameter for selecting the training provider and the course. As the course fees is not a small amount, it is certainly a factor in decision making.

Which training provider offers the course at the best price, provided the course meets other criteria? Even though this cost may not be the lowest but a 10-15% premium for the best provider is not a bad deal. Always consider the best value rather than just the cost.

Hope these parameters will be useful in selecting the right training provider for the business analyst training course.

Wish you all the best

Cheers

 

 

 

Prioritization of Requirements

Prioritization of Requirements

One of the most important aspects of software planning and release management is prioritization of requirements. In this post, we are going to look at the the importance of prioritization, approaches of prioritization and challenges of prioritization.

As per IIBA BABOK Guide:

Prioritization provides a framework for business analysts to facilitate stakeholder
decisions and to understand the relative importance of business analysis
information.

Prioritization of requirements refers to development of an ordered list of requirements in order of their release order. This exercise is conducted in the presence of stakeholders, who are in a position to take a call on the priority of requirements.

Why do we need to prioritize requirements?

Prioritization of requirements is important for multiple reasons:

  • It helps in providing maximum business value withing given constraints like cost, timelines and resources. Most of the times, customer expectations are high, timelines are short, and resources are limited. In these cases, the best option is to deliver the product in the order of business importance.
  • Prioritization of requirements can also be done to minimize risk associated with the product development. Product components or modules with highest risk can be put in the high priority list. This helps in eliminating the risks and carrying on with the remaining project without any unknowns.

Approaches for prioritizing requirements

Version 3 of IIBA BABOK guide provides the following approaches to prioritize requirements:

  • Grouping
  • Ranking
  • Time boxing/Budgeting
  • Negotiation

Grouping/Ranking based approach: In these methods, the focus is on to assign a ranking or priority indicator to each requirement based on the discussion with the stakeholders. So, we can assign high/medium/low or numerical values to the requirements. Examples of these methods are Ranking, Voting, MoSCoW etc. We are going to discuss a couple of them.

Time Boxing/Budgeting approach: This approach is taken based on availability of resources. In a way, this is a constraint based approach. Based on availability of resources like team size, time frame and budget, the prioritization of requirements is decided.

Negotiation based approach: This is a consensus based approach, where stakeholders are engaged in a discussion. They brainstorm and agree on an ordered list of requirements.

Techniques for prioritizing requirements

Numerous techniques are used for prioritization of requirements and they have been used in different conditions. Some of these are as follows:

  • MoSCoW Technique
  • Hundred Dollar method
  • Voting
  • Ranking
  • Kano Analysis
  • 100-point method
  • Requirements triage
  • Binary Search Tree
  • Bubble sort technique
  • Analytic Hierarchy Process (AHP)
  • Minimal Spanning Tree (MST) & More…

This can be a long list, you can find more methods if you search. In this post, we can’t discuss all of them. I have selected couple of techniques based on their applicability in most of the scenarios.

MoSCoW Technique

This is one of the simplest techniques used for prioritization of requirements. In this technique, we simply group requirements with the following prioritization groupings:

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have

That’s how the acronym MoSCoW originated. It’s a simple to understand technique and simple to implement. All the stakeholders discuss and arrive at the prioritization of requirements.

Ranking Technique

In this technique, a numeric rank is assigned to each requirement. The numeric values could be 1 to 10. Requirements with highest numeric value are then arranged and become the prioritized list of requirements.

There are other techniques which are based on prioritization by categorizing the requirements as high, medium, low essentially. There could be many variations of these technique but essentially the approach remains the same.

Challenges of these techniques

Even though voting, ranking and MoSCoW techniques are simple techniques, there are some practical pitfalls. These can really create difficult situations for every business analyst.

I would like to highlight one of the challenges, which is critical and can spoil the prioritization effort. While discussing the relative importance, you can run into the following issues

  • Customer stakeholders saying that all the requirements are high in priority, that’s why we have hired you
  • Customer stakeholders not able to decide priority
  • Ego clashes and internal politics leading to a conflict and you can’t decide on the prioritization
  • Customer team is large enough and prioritization meeting is not going to work

Handling these challenges

These are real challenges and as a business analyst or a project manager, you will definitely end up in these situations. So how do we handle them?

One of the important aspects is to add a constraint to our prioritization techniques so that customer stakeholders have a better way to decide on the priority.

What could be this constraint? These constraints can be time related, cost related or penalty related. So if we can ask the following questions, the task of prioritization of requirements become easier:

  • What is the benefit of developing this features? What is the business loss or penalty, if we don’t do it?
  • The budget is defined and within this budget as indicated against each requirements, let’s decide the priority
  • Similar constraint can be timeline as well

Let me briefly mention two important techniques to use a constraint based approach to prioritization.

Kano Analysis

Kano analysis was designed by Prof. Noriaki Kano in 1980. It was not designed for software industry but is being used quite effectively in all iterative methodologies like SCRUM. In this methodology, a question based approach is used. All the participants are asked questions to answer questions based on importance:

  • Rate your satisfaction if you have this feature
  • Rate your dissatisfaction if you don’t have this feature

You can ask these questions for every requirement and then categorize the importance based on the following matrix:

Prioritization of requirements - Kano Analysis

As you can see, the left side of the image actually shows the prioritization category. This technique is quite relevant if number of stakeholders is high or they can’t agree on the prioritization

Prioritization Based on Value, Cost, and Risk

This technique is mentioned in this article on process impact website. This article is written by Karl E. Wiegers. He talks about this quantitative approach. He has used a cost and penalty based approach. In this technique, each of the requirements is assigned numeric values to penalty, cost and risk. The final chart is shown in this article, which has a quantitative prioritization value for every requirement.

Conclusion

Prioritization of requirements is an important aspect of software development in the modern world. It helps in helping customer realize the business value quickly. It’s an important arsenal in the armor of every business analyst or project manager.

 

About Techcanvass

Techcanvass is an IT training academy for professionals offering courses in Business Analysis, automation testing and analytics. We are an IIBA Endorsed education provider (EEP) for providing IIBA certification programs.

Our business analysis courses are:

Business Analyst Training - ECBA Certification

Business Analyst Training – ECBA Certification

Business Analyst Training - CBAP Certification

Business Analyst Training – CBAP Certification

 

 

 

 

 

 

 

Use Case basics

Use Case basics

In our tutorials series on business analysis fundamentals, we are starting with use case basics. Use case diagrams are central to use case modelling. Use cases are one of the easiest ways to capture the requirements.

This series is going to cover basics of many business analysis skills like user stories, sequence diagrams, activity diagrams and many more. The purpose of publishing this business analysis fundamentals tutorials series to provide basic understanding on business analysis skills for everyone, who are new to these concepts.

What is a use case?

Use case is a pictorial notation to represent high level requirements from a user perspective. Use case diagrams comprise of 3 elements – the actor, use case and association link. A typical use case is represented as shown below:

use-case-diagrams

use-case-diagrams

Use case diagrams, however, can represent very limited information. So, we create use case specifications document to add more detailed information. Later in this tutorial, we are going to look at the format of the use case specification document as well.

Who is an actor in use case diagrams

An actor is an external entity who is likely to interact with the proposed software system. The actor is always outside entity like a user, another system, administrator, finance manager etc. Any entity in the system like a database, can not be an actor. An actor is represented as shown below:

Actor in a use case

Use case in use case diagrams

An oval shape represents a use case in use case diagrams. A use case represents an interaction or a functionality of the system. The notation for a use case is as shown below:

Use case

use cases Example

Let’s look at a section of a requirements document and identify the use cases:

A user has to login into the system to book the flight tickets. Logged in users will also have the facility to use discount coupon codes to avail discounts. The users can search for the flights on any domestic route and for any day. However, they can’t do it for the same day.

How to identify use cases?

In the above case, we can look for sections representing interaction points. Easiest way to look for them is to look for action verbs. I have marked these use cases with underlines as shown below:

A user has to login into the system to book the flight tickets. Logged in users will also have the facility to use discount coupon codes to avail discounts. The users can search for the flights on any domestic route and for any day.

The use cases are:

  • Login into the system
  • Book flight tickets
  • Use discount codes
  • Avail discounts
  • Search for the flights

The use case diagram for the above example is as shown below:

use-case-diagram-example

 

 

 

 

 

 

 

 

Use case diagram is central to the use case modelling. All the other diagrams like activity diagrams, sequence diagrams, state model diagrams are created using the use case diagram.

You can also notice that, I have not created the use case for “Avail discounts”. Avail discounts is a actually a result of “enter discount coupons”. The discounts is applied to the total bill amount and in that case, it is just a calculated field, which needs to be tested. It’s possible to have these cases which represent an action but may not be an interaction. In these cases, these are not candidates for being use cases.

 Use case specifications

Use case specifications are an integral part of every use case diagrams. The specifications add important details to the use case diagrams. These details are:

use-case-specifications

The scenarios describe the positive and negative workflows related to each use case. We are going to discuss the same in later posts.

I am also posting a small video recorded in the ECBA business analyst training sessions.

What is requirements analysis and modelling?

What is requirements analysis and modelling?

Requirements analysis and modelling is probably the most important skill for a business analyst. The success of any software project depends on the this task. Requirements analysis and modelling involves multiple tasks:

  • Understanding business requirements
  • Decomposition and analysis of requirements
  • Categorization of requirements
  • Modelling of requirements

The basic objective is to make sure that you understand the requirements from the customer perspective, translate it into requirements, which software development team can understand. Requirements understanding has been one of the key factors for software projects’ poor record. Read the post below:

Why do we go wrong in Requirements gathering?

Requirements Analysis and Modelling Techniques

Several requirements analysis and modelling (RAM) techniques are practiced to conduct this activity. Some of these techniques are as follows:

  • Structured RAM with DFD and ER diagrams
  • RAM with UML diagrams
  • Using BPMN and other similar techniques
  • Custom Technique

As a business analyst, you should learn at least couple of techniques and when to use them? It will help you in having a better perspective and use of correct technique in a given context.

In this video, I have explained some really basic concepts and a completely custom technique for requirements analysis and modelling. You don’t need to have any prior knowledge to understand it.

What’s in the video

In this video, I have explained the basics of Requirements analysis & modeling. Some of the important topics covered in this webinar are as follows:

a) What are C & D Requirements?

b) What & Why of Modeling

c) What is process modeling?

d) Techniques of Process modeling

What’s next?

If you wish to also learn about requirements analysis and modelling with UML diagrams, you can go through the following article:

Object Oriented Analysis with UML

If you would like to be notified of the future webinar recordings and new videos, please subscribe to our channel on Techcanvass by clicking on the following link:

Techcanvass on Youtube

IIBA BABOK guide version 3 – what’s inside?

IIBA BABOK guide version 3 – what’s inside?

In this short article, I am going to provide you a glimpse of what’s inside IIBA BABOK guide version 3. Version 3 of the guide has been released recently. It’s possible that you might not have laid your hands on to it so far.

If you are planning to appear for ECBA, CCBA or CBAP certification exams, this article will help you to know whats’s inside the BABOK guide version 3. The IIBA certification exams are based on this guide, so it’s important to know it well.

What’s inside BABOK guide version 3

Let’s accept it, the BABOK guide version 3 is a big book. It has a total of 514 pages (aggregate). Setting aside the TOC and indexes, the guide still has 491 pages. It’s around 50% more than the previous version.

So, what’s inside the BABOK guide? First of all, let’s look at the BABOK guide architecture and how chapters are arranged:

whats-inside-babok-guide

There are a total of 11 chapters and 4 appendix. The diagram above shows the content of each of the chapters.

Read Also: Business Analysis Core Concepts Model

Business Analysis Core concepts Model (BACCM)

Quick Stats about BABOK guide

Having looked at the structure of the guide, let’s look at the stats:

babok-guide-stats

As you can see, every knowledge area is described in individual chapters. Each knowledge area is further sub-divided into tasks. Total number of knowledge areas is 6 and total tasks are 30 (spread across all the 6 knowledge areas).

Each task has a defined structure as shown below:

babok-guide-tasks-structure

There are 6 categories of competencies and each category has specific competencies. Total number of competencies are 29. There are a total of 50 techniques discussed in chapter 10. Each task has a list of techniques also recommended in the individual knowledge area chapters.

BABOK guide, however does not provide any insights on the techniques mentioned. You need to learn these techniques separately as certification exams have questions on them.

IIBA Certification levels and Scope of BABOK Guide

The BABOK guide is applicable for all the levels of IIBA certifications. Does it mean that you need to master the entire guide for all the levels of certifications? Not really. IIBA has defined the scope of BABOK guide for each levels.

IIBA website has specified the scope of study for each certification level. This detail is available at IIBA certification blueprint page.

I have also written an article on Introduction to IIBA BABOK guide, you can read it below:

Introduction to Business Analysis Body of Knowledge (BABOK) Guide

Even though the BABOK guide is a big book and may look overwhelming, a strategic approach to mastering BABOK guide will make your task easier.

Coming Up

I am going to write guides on “How to crack ECBA, CCBA and CBAP certifications exams?” soon. Watch out the space.

Cheers

Business Analysis Core concepts Model (BACCM)

Business Analysis Core concepts Model

Business Analysis Core concepts Model (BACCM) is the core framework integral to BABOK Guide v3. Core concepts are fundamental to the practice of business analysis as defined in BABOK guide. IIBA BABOK v3 is the new version of BABOK guide for latest version of business analyst certifications. In this article, I am going to discuss the basics of business analysis core concepts model (BACCM).

You can directly go to the end of this blog post to watch a video on BACCM model, if you would prefer to watch video rather than reading the text.

What is Business Analysis Core concepts Model (BACCM)?

The business analysis core concept model is a set of 6 concepts which define the business analysis practice as per IIBA BABOK v3. The six core concepts are as shown below:

Business Analysis core concepts model (BACCM)

Let’s try and understand each one of them with the help of an example.

If are not familiar with BABOK guide, you can refer to the following blog post:

Introduction to Business Analysis Body of Knowledge (BABOK) Guide

 

Core concept – Need

Need core concept is defined by BABOK as:

A problem, opportunity or constraint with potential value to a stakeholder (s)

Need can be thought of as the reason which starts a project. In this case, we are talking about a software project. An organization needs a software (or a solution) to address a business problem.

Example: The need to automate the sales, marketing & customer service processes.

Core concept – Solution

The BABOK guide refers to this core concept as:

A specific way of satisfying one or more needs in a context.

Organizational needs can only be satisfied or addressed through a solution. A solution to address the need can be specific to an organization as different organizations or situations may need different solutions.

Example: Implementing a Software as a service (SaaS) CRM system, rather than a COTS (commercial off the shelf) CRM product.

Core Concept – Change

IIBA BABOK refers to the this core concept as

The act of transformation in response to a need.

Once the organization recognizes it’s need, a change has to take place in the organization to address the need. The need is addressed through a specific solution, as discussed in the solution core concept.

Example – This change refers to the fact that a solution implementation may need mindset change of employees as they will shift from manual system to an automated system.

Core Concept – Context

Context refers to specific background, budget, timelines, organizational structure, that may influence the solution implementation.  Context may decide the specific solution to be appropriate for an organization.

Example: Extending the CRM example in the solution section. If Software as a service (SaaS) CRM system is suitable for Organization A, it is possible that a customized software is more suitable for Organization B. Thereason can be very specialized business processes for organization B as compared to the almost standard business processes in organization A.

Core Concept – Value

IIBA BABOK refers to “Value” as:

The worth, importance, or usefulness of something to a stakeholder within a context.

An organization has a need as it foresees business value by addressing the need. The business value is an anticipated outcome of implementing a solution.

Example – By implementing a CRM solution, a business can look forward to increase its revenue or to improve customer service standards. This is what is meant by “Value”.

Please note that value can be tangible or intangible. This means that value can be qualitative or quantitative.

Core Concept – Stakeholder

Who is a stakeholder?

A group or individual with a relationship to the change, the need, or the solution.

A stakeholder is an individual or group who can influence the project or can get influenced by the project as a user. The stakeholders can be from the customer organization, the solution provider or an external organization.

BABOK guide has proposed specific categories of stakeholders but does not limit them to only these categories. The stakeholder’s categories as per BABOK are:

  • business analyst,
  • customer,
  • domain subject matter expert,
  • end user,
  • implementation subject matter expert,
  • operational support,
  • project manager,
  • regulator,
  • sponsor,
  • supplier, and
  • tester.

Example – In our example of CRM solution, the stakeholders can be marketing manager, Marketing head, you as a business analyst, the project manager and so on.

These concepts are important part of BABOK guide and therefore also important for the IIBA Certifications preparation. We cover all these topics in details in our IIBA certification courses:

ECBA Certification – Business Analyst training for beginners

CCBA Certification – for Business Analysts with 3 years of experience

CBAP Certification – for Business Analysts with 5 years of experience

Youtube video on BACCM

I have uploaded a video on youtube, which is a clipping taken from my Live online training. The video is a clipping of the class recording of business analyst certification training program on BACCM.

 

Introduction to Business Analysis Body of Knowledge (BABOK) Guide

Introduction to Business Analysis Body of Knowledge (BABOK) Guide

This article provides an introduction to Business Analysis Body of Knowledge (BABOK) Guide. BABOK guide is the official guide for all IIBA certification examinations for business analysts. It’s a comprehensive guide for understanding the business analysis practice.

IIBA has announced 4 levels of business analyst certifications from 30th September, 2016. BABOK Guide v3 is the reference guide for all these levels of certifications. If you would like to know about the level 1 certification, you can visit the following post.

Business Analyst Certification for beginners – ECBA Certification

What’s there in BABOK® Guide v3? How is it structured? What is the coverage for ECBA Certification? This article will help you get answers to all the above questions.

BABOK® Guide Architecture

What is the architecture of the BABOK® Guide? The guide comprises of five key elements. These elements are:

  • Core Concepts
  • Knowledge Areas and Tasks
  • Underlying Competencies
  • Techniques
  • Perspectives

BABOK Guide Architecture

Let’s look at each of these elements.

Core Concepts

Core concepts are the pillars of the business analysis body of knowledge (BABOK). The business analysis practice, as described in the BABOK guide is based on these core concepts. These core concepts are part of business analysis core concepts model (BACCM) as shown below.

BACCM

We are going to discuss the business analysis core concepts model in our next blog post. Keep watching for this space.

Knowledge Areas & Tasks

The business analysis practice has been divided into six knowledge areas. These six knowledge areas cover the entire business analysis work areas. Each of these knowledge areas are further divided into tasks, which are doable tasks. BABOK guide describes the tasks for each knowledge areas in a structured and systematic manner. For example:

Knowledge area 4 elicitation and collaboration has following tasks defined in BABOK:

4.1 Prepare for elicitation

4.2 Conduct Elicitation

4.3 Confirm elicitation results

4.4 Communicate business analysis information

4.5 Manage stakeholder Collaboration

Furthermore, each of the tasks has been discussed in details with input, output, guidelines, tools and techniques.

Underlying competencies

As per BABOK Guide:

The Underlying Competencies chapter provides a description of the behaviors,
characteristics, knowledge, and personal qualities that support the practice of
business analysis.

The competencies, defined in the guide are generic competencies and are applicable for other professional areas as well. The competencies have been divided into 6 categories like analytical thinking and problem solving, communication skills, interaction skills etc.

As you can make out, these competencies may apply to other professional areas as well.

Techniques

The guide enlists techniques for each of the tasks under knowledge areas. A business analyst can use these technique to accomplish the tasks.  The guide has picked up the most used and common techniques. Further to that, BABOK guide states that:

Business analysts apply their experience and judgment in determining
which techniques are appropriate to a given situation and how to apply each
technique.

Perspectives

Perspectives is one of the core concepts, which provides focus to the business analysis activity for each project. For example, AGILE is one of the perspectives indicating that the business analysis activities have to be applied and used with AGILE perspective rather than a traditional project perspective.

Brief Video on Introduction to BABOK Guide

This is a brief video, where I explained the BABOK architecture to class recently.

SQL Tutorial for Business Analysts Part 3

SQL tutorial for Business Analysts

This is the third and the concluding part of the SQL tutorial for business analysts. In the first part of this SQL tutorial for Business analysts, you learnt about the basics of a database system and SQL. In the second part of this SQL tutorial for business analysts, you learnt about INSERT, DELETE and CREATE TABLE commands.

In this concluding part, you are going to learn about SELECT command.

Introduction to SELECT Command

SELECT command is probably the most used command in SQL. It’s used primarily to get data from a single table or multiple tables. The usage of SELECT command are as follows:

a) If you are a SQL developer, you may use it for creating reports or display data

b) If you are a Business Analyst or a testing professional, you may use SELECT to validate the data stored in the table(s) (to check if correct data is getting saved).

c) Business Analysts may also use it to get data for analysis

Syntax of SELECT command

The syntax of SELECT command is as shown below:

SELECT <<col_name1>>, <<col_name2>>…..

FROM <<table_1>>, <<table_2>>

WHERE <<conditions>> AND <<Joins>>

We will explain the syntax shortly but first of all, let’s see one example. We have been referring to STUDENTS table in this tutorial and we added rows to it as well. Let’s see, how can we fetch the data from that table. Write the following command in the W3 SQL editor and hit “Run SQL” button:

SELECT * FROM STUDENTS;

The result of this command is as shown below:

SELECT command in SQL

You can see that it returns all the rows (I had only inserted one row). If you have completed the exercise in the previous tutorial, it should return all the rows you had inserted.

Please note “*” in SELECT command is meant for showing all the columns and not for all the rows. 

So what if there are multiple rows and we only want a specific row. Let’s take an example to understand that. There are multiple rows in the CUSTOMERS table in example database. As of now, if I run the following command on CUSTOMERS table:

SELECT * FROM CUSTOMERS;

It returns 91 rows as shown below:

Select command in SQL

What if I want only specific row or rows? What should I do?

Using conditions in SELECT

That’s where the WHERE <<condition>> section comes into picture. So, let’s say we would like to see the customers who belong to “Berlin” (city name). So how will we write this SELECT?

SELECT * FROM CUSTOMERS

WHERE city = “Berlin”;

This SELECT statement will return you only those customers, which belong to “Berlin”. It’s also possible to have multiple conditions in a single SELECT statement.

The table contains multiple Customers from the USA. As of now, there are 13 customers from the USA. But if we only want to know about the customers from the city “Seattle” in the USA, we can write the SELECT statement as shown below:

SELECT * FROM CUSTOMERS
WHERE country=”USA”
AND city = “Seattle”

This will get only those customers, which are from “Seattle” in the USA. You can have as many conditions in the SELECT statement.

Practice Exercises

You can use the tables provided in SQL editor to practice.

Joins in SELECT Command

In the last section of this three part SQL tutorial, we are going to discuss about JOINS. JOINS are used if we would like to get data from more than one table. In that case, we need to create the join on the columns, which are common between the tables.

We have already seen the syntax in this post. Let’s look at our example case. In the sample database given in W3 SQL editor, let’s look at PRODUCTS and CATEGORIES tables. If you see the data in the PRODUCTS table, you can see that products belong to various categories and these categories are stored in the PRODUCTS table as CategoryID.

SQL Tutorial image

This CategoryID is actually a column in the CATEGORIES table. If we try to get the data from CATEGORIES table, we will get the data with CATEGORYID as 1, 2 etc. But that’s not very easy to understand, what if we would like to see the proper Category name along with the product names and unit. Let’s see how to write the SELECT command in this case.

SELECT productname, categoryname, unit FROM PRODUCTS A, CATEGORIES B

WHERE A.categoryID = B.CategoryID

As a result, we will get the following result:

SQL Tutorial image

We have used A & B immediately after the table names for convenience. These are also known as aliases. The join is created using the following line:

A.categoryID = B.CategoryID

Since CategoryID is the common column name, we have equated them to avoid Cartesian product (Remember Set theory?). If there are more than one common columns between the tables, you should equate all of them, else you will get wrong results.

Summing up SQL Tutorial

You have learnt basic commands of SQL in this tutorial, there are many commands as discussed in Part-I of this SQL tutorial. To get a stronger grip on the SQL command, you need to practice a lot more . This is an important skill, expected from a Business Analyst in the job interviews.

We are coming up with a more comprehensive tutorial for learning Business Analysis skills . That tutorial will provide steps to learn the business analyst skills with specific resources including videos and tutorials.

You may also like to look at our other tutorials and videos, specially for professionals, who are looking to become a business analyst.

Business Analyst Tutorials

Finally, SQL is an important skill for Business Analysts specially if you are looking to become a business analyst. Techcanvass provides a Certified Business Analyst (ECBA) training program, to know more about it you can click on the following image.

Certified Business Analyst Training