Business Analysis Fundamentals - ECBA, CCBA, CBAP endorsed

The lecture gives the thousand foot view of the course as a whole. Having a clear understanding of what the course will teach you, allows you to work at your own pace knowing what information is yet to come.

Business Analyst is not a role that often comes up when researching career paths, so in this lecture, we will provide you with seven of the top reasons you should become a Business Analyst.

In this lecture, we provide you a ZIP file that contains all of the downloadable resources for the course. While those downloads are still available on appropriate lectures throughout the course, we're providing this ZIP file for convenience and to avoid some of the nuances and issues with downloading the files individually. It is our recommendation that you download this file now and then pull up the files as they are referenced within the course. Happy learning!

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

Some organizations have Business Analysts play a very general role within their organization. The Business Analysts may be involved in all aspects (or tasks) of a project and need to be versed to do so. Other organizations are taking a more streamlined approach and breaking the Business Analyst position into various roles that perform specialized actions. This lecture dives into some of the most common roles a Business Analyst can play and what duties they perform within such roles.

Terms: Business Process Analyst, Requirements Analyst, Systems Analyst, Data Analyst, User Experience Analyst

This quiz is utilized to validate your understanding of the basics of Business Analysis.

This is a brief introduction lecture to The BA Guide's Business Analyst Glossary of Terms. I walk you though the glossary and explain how to utilize it.

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

This quiz will validate your understanding of the knowledge taught in this Initiating a Project section of the course.

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.

In this lecture, we continue our teaching of the Requirements Process and turn our focus to the third step, Requirement Specification.

Terms: Specification

One part of the Requirement Specialization step is to categorize requirements. This lecture explains why it is important to categorize requirements, as well as it provides some example categories that could be used.

Terms: Categorize, prioritize, functional, non-functional, constraints

Another aspect of Requirement Specialization is deriving requirements. This helps to add details, remove ambiguity, and increase clarity.

Terms: Derive, ambiguity, parse

All requirements have certain attributes or properties that are important to capture. In this lecture, we will explore those elements and discuss some example attributes you can use with your requirements.

Terms: Requirement

Not all requirements are created equal. Some are significantly more important than others in helping to achieve the goals defined by the project. In this part of Requirement Specialization, we learn about how prioritization can be used to help ensure the most important requirements are completed first.

Terms: Prioritize

It is crucial that your requirements are valid. In this lecture, we remind you about ensuring your requirements are clear, concise, and follow the SMART acronym.

Terms: SMART

Now that you understand how to elicit requirements, it is important to understand where you document them. One common place to document requirements in traditional projects is the Business Requirements Document (BRD). In this lecture, we will break down the BRD, how it is created, and discuss its most common sections.

Terms: BRD

Once you have the requirements detailed and polished, you need to get them approved. This is your opportunity to validate with the business team, technical team, and Project Sponsor that the requirements you defined are accurate and provide a clear picture of the needs of the business and its stakeholders.

Terms: Requirements

The first step in your approval process should almost always be to gain business approval. This is where you validate with the business team what you captured accurately represents their needs and wants.

Terms:  Requirements, SME

Now that you've gained the approval of the business, it is time to check with the technical team to highlight any technical concerns and to validate there are enough details to move forward with a design.

Terms: Requirements, SME, design

And finally, we need to gain the Project Sponsor approval. Since the Project Sponsor is ultimately the one who is providing the budget for the project, it is important they are in agreement with the requirements and the plan for moving forward.

Terms: Project Sponsor, requirement

Once projects are complete, it is important for the team to conduct a project review to elicit feedback from the project team. This feedback can then be used to both celebrate project wins and to highlight changes and enhancements that will positively affect future behaviors and projects.

Terms: Stakeholders, survey

Once a project is thought to be complete, it is important to conduct one final check, the Project Completion Verification. This validates the project has adequately met the goals it set out to achieve.

In the corporate world, most organizations will have various environments including dev, test, and production. This lecture will help to explain the use of each environment and how they work together to help create successful project outcomes.

Meeting agendas are great to both inform your meeting invitees the topics for the discussion and to help keep the meeting conversation on track to meet its goals. In this lecture, we will break down those concepts.

Meeting agendas are great but don't get too rigid. Planning out every minute of your meeting makes it difficult to adjust to new learnings.