Understanding what Business Analysis is, what a Business Analyst does, and the value they provide to companies is the critical foundation knowledge needed before we go any further.

Terms: Business Analysis, Business Analyst

Now that you have a foundational understanding of business analysis, the next area of importance is understanding the high-level tasks a Business Analyst performs.

Terms: Business Analyst

This activity is a quick warm up to get you thinking logically.

This lecture contains the answer and the explanation to the warm-up activity

One of the most crucial steps in any project is understanding the business objective. Without knowing what success looks like, it is very hard to achieve.

Terms: Return on investment (ROI)

In order to get a project idea approved and budgeting set aside, many Business Analysts have the responsibility to create a Business Case. This lecture will give you the basics of what a Business Case is and why it is important.  (Part 1 of 2)

Terms: Business case, return on investment (ROI)

Part 2 of 2 on Business Cases

In order to get a project idea approved and budgeting set aside, many Business Analysts have the responsibility to create a Business Case. This lecture will give you the basics of what a Business Case is and why it is important.

Terms: Business case, return on investment (ROI), risk, cost-benefit

Identifying stakeholders is important to your project because it is not possible to elicit requirements from stakeholders that you don't know exist. When you miss stakeholders, you miss requirements. And missed requirements means failed projects. In this lecture, we will discuss what stakeholders are and how you can identify them.

Terms: Stakeholder

Once stakeholders have been identified, it is a good idea to assign them responsibilities to help prevent confusion about their role throughout the project.

Terms: Stakeholder, RACI

DO NOT SKIP!  Activities are extremely important to cement what you have learned.

For most Business Analyst roles, requirements are the key to their success. This lecture provides you an understanding of what requirements are, why they are important, and how they are categorized.

Terms: Functional requirements, non-functional requirements, constraints, assumptions, scope

Writing SMART requirements are crucial to every project. Come learn about what makes SMART requirements and how they make it easier for stakeholders in any role to understand them.

Terms: SMART, traceability, dependency

This is a short lecture to clarify some possible confusion or misconceptions that could come from the SMART Requirements lecture.

Terms: SMART

In this lecture, I will share with you a long list of requirements best practices I have learned throughout my career as a Business Analyst.

Terms: Requirements

Within projects, requirements go through several phases. This lecture will help to explain those phases and how when put together they make the full Requirement Process.

Terms: Elicitation, analysis, specification

This lecture helps to explain what business rules are, how they compare to business requirements, and some best practices for identifying and using business rules.

Terms: Business rules, business requirements

Brainstorming is a great technique to drive lots of high-level ideas on how you can solve a particular problem. This is crucial when you are hoping to generate ideas on how to proceed with a specific requirement or issue.

Terms: Brainstorm, timekeeper, scribe, facilitator

Requirement Workshops pull together individuals, even those from different departments and units, to define, discuss, and analyze project requirements. By getting everyone together, you are able to get feedback based on everyone's varying perspectives.

Terms: Requirement workshop, end-user, Subject Matter Expert

Interviewing is one of the most common requirement elicitation techniques utilized by Business Analysts. While it can take some time to set up and conduct, the value of getting immediate feedback to your questions and the ability to ask follow up questions often makes it well worth the effort.  (Part 1 of 3)

Terms: Interview, job shadow, task analysis

Interviewing is one of the most common requirement elicitation techniques utilized by Business Analysts. While it can take some time to set up and conduct, the value of getting immediate feedback to your questions and the ability to ask follow up questions often makes it well worth the effort.  (Part 2 of 3)

Terms: Interview

Interviewing is one of the most common requirement elicitation techniques utilized by Business Analysts. While it can take some time to set up and conduct, the value of getting immediate feedback to your questions and the ability to ask follow up questions often makes it well worth the effort.  (Part 3 of 3)

Terms: Interview, open-ended

The survey elicitation technique is great to gain quantifiable data that can be used to help identify pain points and create a baseline for your project.

Terms: Survey. open-ended, closed-ended

While not always defining requirements, documentation review is a great first step in requirement elicitation. Reviewing past documents and user guides can help you get your arms around the current landscape of the business and its processes.

Terms: Documentation review, scope

While not a stand-alone elicitation technique, it is important to cover analyzing interfaces because nearly every system has an expectation of information going in and information coming out. Analyzing interfaces ensures we define those needs because missing those requirements can prove to be critical to your project.

Terms: Interface, input, output

DO NOT SKIP!  Activities are extremely important to cement what you have learned.

Once we've elicited the requirements, it is time to analyze them. In this lecture, introduce the concept of analyzing requirements and explain why it is so important.

Terms: Requirement analysis

Visual modeling is one of the best ways to help others understand requirements. This lecture will go over the foundational concepts and benefits of creating visual models.

Terms: Visual modeling, requirements, as-is, to-be

I like to break up visual models into two categories; Business Models and Technical Models. This lecture introduces the most commonly used Business Models.

Terms: Organizational chart, scoring matrix, stakeholder map, use case, process flow, wireframe

Technical Models are not something most Business Analysts will create, but it is good to have an understanding of how to read the model. This lecture introduces the most commonly used technical models.

Terms: System context diagram, data flow diagram, CRUD matrix, state diagram, ERD

There always seems to be much confusion between BPMN and UML. This lecture gives you an understanding of what BPMN and UML are, their similarities, their differences, and which one I would recommend learning over the other.

Terms: Process flowchart, UML, BPMN, swimlane

It is important to engage your technical team on projects. In this lecture, we discuss when, how, and why you should engage with your technical team in projects.