In this video, we’re going to dig into the different ways to analyze software requirements.

Software Requirements: Defined

Software requirements describe capabilities a solution must have and information the solution will manage. Software requirements are where business meets technology. They need to be described in ways that business users understand and technical stakeholders can use to build what the business actually wants.

Well done software requirements work is not just well-written requirements. It’s about ensuring the requirements are are implementable by the technology team – but also that they realize what delivers actual value to the business. Collaboration, validation, and buy-in, using language that everyone can understand, are just as important as syntax and formats.

Historically, in traditional waterfall methodologies, software requirements were specified in a Functional Requirements Specification (FRS) or Software Requirements Specification (SRS) in long categorized lists. They are also often a significant component of a Business Requirements Document (BRD).

Different Templates You Can Use

Today, software requirements are more often captured in user stories, organized in product backlogs. Sometimes they are analyzed in use cases. Although it’s not uncommon for a team to embed a backlog in a BRD, which gets completed upfront, and then manage that backlog in an agile way throughout the implementation.

FRSs, SRSs, BRDs, backlogs, user stories, and use cases are all different containers for the software requirements. The choice you make about the container will often be driven by the practices in place within your organization or team. The systems-thinking and collaboration skills you cultivate to discover, analyze, and validate the software requirements transcend any specific template or container, and are the primary focus of what we teach at Bridging the Gap.

Examples of Software Requirements

Let’s take a look at a few different examples of software requirements.

Typically in an FRS, SRS, or BRD, the software requirements will be captured as lists in system-shall statements. For example:

“The system shall stream a live audio session.”

A user story in a product backlog adds more context:

“As a course participant, I want to stream a live audio session so I can listen to a course lesson on-the-go.”

Learn more about user stories in this tutorial:

A use case, on the other hand, would present this requirement as a series of user actions and system steps. For example:

1. The course participant selects to listen to the audio presentation.
2. The course delivery system presents an audio file to the participant’s web session.

Learn more about use cases in this tutorial:

A user interface model is a visual representation of how the software could look, when built and presented to an end user.

Learn more about wireframes in this tutorial:

Pros and Cons of Different Requirements Documents

Each of these software requirements approaches has pros and cons, and each can work successfully.

• System shall statements provide a clear, easy-to-read and sort list of functional requirements, which can be very useful for evaluations and traceability. But they tend to lack context and specificity.
• User stories embed the business objectives into the software requirements, ensuring the team pays attention to not just what the system needs to do, but why that feature is importa They are also a great planning tool, allowing teams to prioritize work at a low level of granularity and respond to change more efficiently. However, in a large backlog it’s easy to lose track of the big picture and, on their own, they do not support your analytical thinking.
• A use case is a robust analytical tool that encourages strong systems-thinking and supports collaboration between business and technology stakeholders. However, use cases can easily get bloated with complexity and extra scope and, the path from use case to implementation can be difficult to manage successfully.
• A user interface model is easy-to-understand, generates insightful feedback, and can help teams get clear on the software requirements quickly. They are a great complement to any of the above. However, on their own, they can lack specificity and can lead to false assumptions.

If you’d like to see what a use case looks like, I offer a free template as part of the BA Deliverables Collection. 

Learning to think in use cases helps you explain what the software needs to do using language that business users can understand. They also tend to miss fewer requirements. Meanwhile, your stakeholders see the full potential of the solution and provide clarifying feedback in more efficient ways.

No matter what container or analytical tools you choose, functional requirements are not technical design. You do not have to know how to write requirements for software. In fact, those with a technical background must learn how to craft requirements in clear language that a business user can understand, and resist any temptation to include pseudocode or technical details.

Want to learn more? Watch this video next:

Learn how to analyze software requirements in The Business Analyst Blueprint training program

If you’d like to go deeper with me, I teach these concepts in depth inside The Business Analyst Blueprint training program.

We have conversations about what problem we’re solving, how to flex our skills on different types of team, and how to leverage AI as part of the proces. And I’d love to work with you or your organization to help you and your business analysis practice get better.

What results are you trying to create? What problem are you trying to solve? And what is the potential ROI (return on investment) in this change versus anything else that we might put our attention into?

When we have clear business objectives, we do the upfront work that circumvents significant downstream issues that honestly can bring a project to a screeching halt. Some of those issues tend to be detailed requirements churn while stakeholders start to advocate for solutions to completely different problems, or the implementation of a solution that the business rejects or simply can’t even use because it doesn’t meet their actual need.

And while this might sound counter-intuitive, clarifying business objectives can often take the scope and reduce the scope of an initiative, allowing that organization to invest less to generate more value. Even a small change or a seemingly minor enhancement request, when you take the time to clarify a business objective, it’s going to make the best use of resources by ensuring that the right requirements get discovered and implemented.

Business Objectives: Examples

Here we have two examples of quantifiable business objectives for a home insurance claim application where homeowner and contractor could use to submit their claim data to an insurance company.

• Reducing the average time a claim agent spends preparing and submitting a claim from 8 business hours to 6 or less.
• Reducing follow-up calls to check on claim status by homeowners by 50%.

Business objectives can also be qualitative and less specific. Here are two versions of those same objectives without the specific numbers:

• Reduce the time a claim agent spends on a claim.
• Reduce follow-up calls by homeowners.

Business objectives are not scope

Scope describes the solution. Examples include:

• Implement a new Customer Relationship Management (CRM) system.
• Retool the lead management process.
• Automate the contract management process using newly available technology.

Those are all descriptions of solutions. They are outcomes in that they are generated outcomes of the project, but they’re not really the business objectives or why we would be putting those initiatives into place.

Business objectives articulate outcomes

A CRM might increase visibility into the sales lifecycle. Retooling the lead management process might reduce the days to close a new lead from 90 to 60. Automating the contract management process could reduce the effort to produce a new contract from 20 hours to 5 hours.

It’s really important to get that difference. I see way too many BAs thinking they’ve got this whole business objectives thing figured out, but they’re really just talking about the output, not the high-level outcome.

Business objectives can come by many different labels

The other thing I want to draw your attention to is that your organization might not call these “business objectives.” You want to look for where they are using terms like:

• Business requirements.
• Business needs.
• Business value.
• Desired outcomes.
• ROI (Return on investment).
• KPIs (Key performance indicators).

All of these are often business objective-related information, where your organization might be calling it something different.

We want to meet people where they’re at. It would be easier if everyone is calling them “business requirements” or “desired outcomes” to use that language internally. Ensure that those desired outcomes or KPIs are actually business objectives and are clearly understood and aligned by everyone, versus trying to also change the terminology and insist, “We need to call these business objectives now.”

Look at what terminology your organization might be using and opt into that wherever you can.

You’ll find outcomes in many different documents

Scope statements. Business cases. Project charters. Epics. Etc.

At Bridging the Gap, we teach a scope statement because it’s a simplified way of really capturing the scope of a project, the business objectives, the constraints, the capabilities of the solution, and the risks and the out-of-scope items. It’s just a really simple document to communicate that core information.

But your organization might do this in a business case, or a project charter, or an epic. Look at what documents have some information related to why we’re investing in this.

And again, put yourself into the position of being part of that document or part of that review, or validating those business objectives, or asking questions around those business objectives in the document it’s already in, versus trying to create like a standalone document that just has this piece of information. Or, if nothing has it but there’s a document that’s often reviewed upfront, typically by higher-level business stakeholders, advocate for adding a section to that existing document versus creating something from scratch.

Leveraging AI to help draft business objectives

A lot of BAs get stuck because stakeholders don’t really know what their business objectives are. It can be helpful to suggest ideas that people can react to. We might, though, not really know what those ideas are. And so we can use AI to help us come up with some of those ideas. And this AI prompt is a great template to use:

The business sponsor in the role of {role name} wants to implement {solution} for a {type of company}.

{Summarize any context you have around the goals}

I’m struggling to get them to define their objectives. What are the primary benefits that our organization can realize from implementing a solution like this?

You can use this even without a company-sanctioned, licensed AI, as long as you’re not sharing anything proprietary in there. You could use it just to get some ideas and make it a little more general, even outside of your company.

Of course, you always want to abide by those policies, but there’s nothing in this prompt specifically that mandates you share proprietary information.

Prompt AI with additional questions to gain more insight

Now once you have that thread going, you can ask all kinds of additional questions.

• “They’ve shared that they want to [blank], but I don’t think that’s the real or only reason. What do you think?”.
• “Our organizational objectives are [list]… How could this solution help us achieve those outcomes?”. (Take your organizational strategy—this you wouldn’t want to load into a non-protected system—and ask how the solution helps achieve it).
• “What objectives related to sustainability and social justice might we want to propose for consideration?”. (If there’s a value that you find really important and you’d like to at least encourage people to talk about that, you could bring that into the discussion).
• “What additional questions should I be asking about their motivations?”.
• “What is the potential financial return on these objectives, and how can those be measured?”.
• “What baseline data should we be looking at to quantify this opportunity?”.

Looking for more support with AI prompt engineering? Here’s a video tutorial specifically for business analysts:

Go even deeper with an organizational AI knowledge base

One other piece I want to mention is that when you have access to an organizational AI knowledge base, you could even go deeper:

You could ask:

• “How can this initiative support our overall organizational goals?”.
• “What other projects under consideration are also tackling these objectives?”. (So that you can find opportunities for synergy and overlap and shared resources and maybe combine a project together).
• “What changes have we implemented so far to impact these objectives and what can I learn from those projects to consider here?”.

Now these assume you have robust amounts of information and history loaded into your AI system. Not all BAs have this, but if you do you can start to ask these next-order questions and get even better results from what you get from AI.

Business objectives cultivate alignment and clarity

I hope this tutorial helps you think through how you can bring more attention to business objectives in your work. And, critically, ensuring everyone is truly in agreement on what problem we’re trying to solve, where we’re going, before we start the other work of the project. This will save you loads of time down the road and make everything not easy, but a bit easier as you go.

If you’d like to go deeper with me, I teach these sorts of concepts inside The Business Analyst Blueprint training program.

We have conversations about what problem we’re solving, how can we make the scope work within that problem, how can we handle challenging stakeholders who may be resistant to these kinds of questions. And I’d love to work with you or your organization to help you and your business analysis practice get better.

In this post, we’ll walk through a practical, step-by-step business analysis approach to a system migration project, including the specific techniques that will serve you best. Watch the video below for a full walkthrough, then use the written guide and free templates to put it into practice.

What Is a System Migration Project?

A system migration project is when an organization moves from one enterprise system to another. This could mean:

• Moving from one vendor’s software to a competitor’s platform (for example, migrating a CRM from one tool to another)
• Consolidating multiple tools into a single all-in-one system
• Replacing a homegrown or legacy system with a modern enterprise tool
• Transitioning from manual processes and spreadsheets to a supported, automated system

In each case, the core challenge is the same: making sure the new system supports the business processes, requirements, and data that the old one did while capturing any improvements along the way.

Why Do Companies Migrate From One System to Another?

System migrations don’t happen in a vacuum. There’s usually a clear business driver behind the decision. The most common ones include:

1. Mergers and acquisitions — When one company acquires another, system consolidation is often a key cost-savings objective. Redundant platforms get rationalized.
2. Outgrowing the current tool — A company scales up and needs more features, customization options, or integration capabilities than their current system provides.
3. Simplification and consolidation — Organizations streamline their technology stack to improve interoperability and reduce the overhead of managing multiple systems.
4. Executive direction — Sometimes a leader hears about a new platform at a conference and decides it will solve a problem in their department. (It happens!)

Understanding the real driver behind the migration matters. It shapes what “success” looks like and helps the BA prioritize what to focus on.

A Business Analyst’s 8-Step Approach to a System Migration Project

Here’s the 8-step business analysis process framework we teach at Bridging the Gap.

Let’s look at how to apply this within the context of a system migration project.

Understand the Business Objectives for the System Migration

Start with the “why.” What outcomes is the organization trying to achieve with this migration? Ideally, you’re involved early, even in the tool evaluation and selection process. But even if the new system has already been chosen, you need to understand the expected business outcomes so you can shape the migration to meet them.

Define Scope of the Migration

Identify what’s in and out of scope at a high level. This includes:

• Which business processes will be covered
• What functional capabilities will be set up and configured in the new system
• Which systems the new platform will integrate with
• Whether any data will be migrated, and if so, what

Keep it high-level at this stage. You’ll get into the details later.

Pro Tip: A system context diagram is one of the most useful visual models you can create alongside a scope statement. It maps the new system’s relationships to surrounding systems, people, and data flows at a glance — making it easy to communicate scope and flag integration risks early.

Plan Your Work for the System Migration Project

With scope defined, build out your project plan. Identify the stakeholders you need to engage, the techniques you’ll use, and how you’ll sequence your analysis activities, and start defining the detailed requirements.

Key Requirements Techniques for a System Migration Project

The three core technique areas in The Business Analyst Blueprint® are especially well-suited to system migration work:

Business Process Analysis for System Migrations

Understand how people are using the current system today. What are the workflows? What works well? What are the pain points? This current-state analysis is the foundation for designing how processes will work in the new system. Then model the future state to show how workflows will change in the new system.

Software Requirements for System Migrations

Map current system capabilities to the new platform and identify gaps. Document any custom enhancements needed and use prototyping to validate configuration decisions with stakeholders. This is often the lightest-lift area when there’s an existing system to work from. For any custom enhancements needed in the new tool, document those as requirements. Use prototyping to illustrate key configuration options and validate your understanding with stakeholders.

Data Modeling for System Migrations

This is often the most time-intensive part of a migration. You’ll need to:

• Understand any differences in data domain between the two systems
• Complete a data map showing how data fields in the current system translate to the new one
• For any integrations, create data maps showing how data flows between systems

These three technique areas, along with an end-to-end business analysis approach, are what we teach inside The Business Analyst Blueprint® training program.

Free Templates to Get You Started on a System Migration Project

We have several free templates in our BA Deliverables collection that are directly applicable to system migration projects:

• Scope Statement Template — Define what’s in and out of scope, document business objectives, and create a clear foundation for your project.
• Business Process Template — Document current and future-state workflows in a structured, stakeholder-friendly format.

Tutorials to Help You On a System Migration Project

And if you want to go deeper on any of the specific techniques, these video tutorials walk you through them step by step:

Scope Tutorial

A 5-part approach to how to scope a project or initiative to gain clarity and build momentum.

Data Mapping Tutorial

Essential to the data migration aspect of a system migration, a data map will help you showcase how data flows between information systems.

Business Process Tutorial

Understanding current and future state business processes is key to a successful system migration.

Entity Relationship Diagram Tutorial

An entity relationship diagram helps identify key concepts and how they relate to one another, giving you a high-level understanding of the data model of your existing and target system, so you can identify overlaps and inconsistencies before starting to migrate data.

Frequently Asked Questions

What does a business analyst do on a system migration project?
A business analyst on a system migration project is responsible for understanding the business objectives behind the migration, defining scope, analyzing current-state processes and data, documenting requirements for the new system, and ensuring that gaps between the old and new platforms are identified and addressed. The BA bridges the gap between the business stakeholders and the implementation team.

What requirements techniques are most useful for system migrations?
The three most impactful technique areas are business process analysis (to document current and future workflows), software requirements (to map capabilities and identify gaps), and data modeling (to map data between systems and document integrations). All three are covered in The Business Analyst Blueprint® training program.

What is a system context diagram and when should I use it?
A system context diagram is a visual model that shows a system and all of the external systems that interact with it. It’s an excellent tool for communicating scope on a migration project because it makes integration points and system boundaries visible at a glance. It pairs well with a written scope statement.

What’s the difference between a data map and an entity relationship diagram?
A data map shows how specific data fields move from one system to another. It’s about the translation of data during migration or integration. An entity relationship diagram (ERD) shows the structure of data within a system — the entities, their attributes, and how they relate to each other. Both can be relevant on a system migration project depending on the complexity of the data involved.

Do I need to document requirements if the new system is an out-of-the-box tool?
Yes! Even with a packaged solution, you’ll need to document which capabilities will be configured and how, any gaps that require custom development or workarounds, data migration rules, and integration requirements. The format may be lighter than a custom development project, but the analysis is just as important.

Ready to Set Yourself Up for Success on System Migrations?

Whether you’re a solo BA looking to sharpen your skills or you’re developing your entire business analysis team, The Business Analyst Blueprint® training program gives you the techniques, templates, and end-to-end approach you need to lead complex projects like system migrations with confidence.

I also offer private cohorts for business analyst teams looking for training.

My goal was to continue to go for depth, just in shorter increments. I started with a series of tips from my new book – The Value-Driven Business Analyst – and then started answering your questions and addressing challenges I was seeing in our community.

What did you think of the change? Please reach out and let me know.

#10 – Stop Reinventing Your Business Analysis Approach on Every Project

While every project is different, reinventing your approach every time only leads to confusion, reactivity, and burnout. Explore how following a flexible framework brings clarity, consistency, and long-term success…even in fast-moving, diverse environments.

FAQs

Question: If every project is unique, why use a structured business analysis process?

Answer: A flexible framework helps you adapt without starting from scratch. It gives you a foundation to build from, so you’re proactive instead of reactive…and focused on what the business truly needs, not just what’s urgent.

Question: Won’t using a process make me rigid or too formal?

Answer: Not at all. The most successful BAs flex their process intuitively. A strong structure gives you freedom because you always know what step to take next, and how to adjust it for your project context.

Question: What process does The Value-Driven Business Analyst teach?

Answer: Laura teaches an eight-step business analysis process refined across industries and methodologies. It includes deep dives into business process analysis, software / functional requirements, and data modeling and it’s designed to scale with your career.

#9 – Overwhelmed at the Start of a Project? Watch This

Explore why overwhelm can be a positive sign and discover one practical, value-focused tip to break through the fog and start leading with confidence.

FAQs

Question: Why is feeling overwhelmed at the start of a project actually a good thing?

Answer: Overwhelm often means you’re absorbing critical context and raw information needed to drive meaningful change. It’s a natural part of early-stage analysis where ambiguity is high.

Question: How do I avoid getting stuck in analysis paralysis?

Answer: Instead of trying to solve everything at once, focus on identifying just the next decision your team needs to make. This creates momentum and keeps your analysis grounded in immediate value.

Question: What if stakeholders resist taking a step back to define business objectives?

Answer: Reframe the conversation by connecting the objective-setting work to a tangible outcome, like choosing the right system. This positions your analysis as enabling faster, smarter decisions, not slowing things down.

#7 – Scoping an AI Project: Don’t Miss This Step

Explore how to strategically evaluate generative AI as a solution option during the scoping phase and the key questions every business analyst should be asking to unlock its real business value.

FAQs

Question: Why should business analysts consider AI during project scoping?

Answer: Generative AI isn’t just a trend, it’s a new category of solution that can enhance communication, summarization, simulation, and decision support. Business analysts are uniquely equipped to evaluate whether it’s the right fit for a business need.

Question: What types of questions should I ask when scoping an AI-driven solution?

Answer: Start with core questions like: What problem are we solving? What data do we have? Where can AI be trusted, and where is human review still needed? These help you align the solution to business goals while managing risk and feasibility.

Question: When is traditional software still the better choice?

Answer: Rule-driven, structured processes are often best served by traditional programming. AI shines in creative, iterative, or variable tasks, like drafting content or generating concepts, not rigid workflows.

#6 – Scope Creep Starts Small – Here’s How to Stop It

Discover how minor changes can quietly derail a project and how value-driven business analysts reframe the conversation to stay focused, deliver results, and avoid unnecessary complexity.

FAQs

Question: Why is scope creep such a big issue if the changes seem small?

Answer: Small additions often create ripple effects—more testing, more complexity, more documentation—adding friction without delivering real value. Over time, these seemingly minor changes can overwhelm the project.

Question: How can business analysts prevent scope creep?

Answer: Shift the conversation from “Can we add this?” to “What will it cost?” and “Is it worth it?” Use strategic questioning to evaluate impact, trade-offs, and alignment with business objectives before saying yes.

Question: What should I ask when assessing a scope change?

Answer: Ask questions like: Does this support our core objectives? How often will it be used? Are there workarounds? What will we de-prioritize to make space? These help surface hidden costs and keep the project focused.

#5 – Agile is NOT a Business Analysis Process

Agile may guide how software is delivered, but it doesn’t replace the structured analysis business analysts bring. Explore why the business analyst role is more critical than ever…and how to move beyond “just writing user stories.”

FAQs

Question: Isn’t agile already a process that includes business analysis?

Answer: Agile is a delivery framework—it tells teams how to deliver software, but it doesn’t provide a process for discovering business needs, analyzing processes, or aligning stakeholders. That’s where agile business analysis comes in.

Question: Why do business analysts often feel reduced to “just writing user stories” on agile teams?

Answer: When analysis activities aren’t clearly defined, BAs default to story writing. But without upfront work like clarifying objectives and evaluating options, agile teams risk delivering software that doesn’t meet real business needs.

Question: How can business analysts create more value in agile environments?

Answer: Use a value-driven process to guide your work before, during, and between sprints. This ensures you’re not just keeping pace with Agile: you’re enhancing its impact by making sure the right problems are being solved.

#4 – Great Requirements Start with Great Questions

Clear, actionable requirements don’t come from guesswork. They emerge from smart questions and structured analysis. Explore how value-driven business analysts build credibility by asking what others overlook.

FAQs

Question: Why are great questions so important when defining requirements?

Answer: The right question can reveal hidden gaps and spark clarity. It builds trust and credibility, often making the difference between requirements that drive value and those that miss the mark.

Question: Where do those great questions come from?

Answer: They come from analysis. By using tools like requirements questionnaires, business process maps, and data models, you develop insights that help surface the questions no one else is asking.

Question: What techniques help uncover hidden or vague requirements?

Answer: Techniques like use cases, process models, data maps, and structured working meetings give you multiple perspectives on the same requirement…helping you dig deeper and build stakeholder buy-in.

#3 – The #1 Reason Business Analysts Don’t Get Recognition

If your work as a business analyst feels overlooked, the issue may not be your effort. It may be that the value of business analysis isn’t clearly understood. Explore how to shift that narrative and build recognition through structured, value-driven work.

FAQs

Question: Why do so many business analysts feel unrecognized or undervalued?

Answer: Often, the value of business analysis isn’t clearly articulated, even by those doing the work. Without a shared understanding, BAs can be sidelined, underutilized, or buried in task work that hides their true contribution.

Question: How can I better explain the value I bring as a business analyst?

Answer: When you follow a structured, value-driven business analysis process, it becomes easier to communicate the impact you’re making, such as reducing rework, aligning stakeholders, and solving the right problem (not just the stated one).

Question: What’s the first step to earning more recognition as a BA?

Answer: Own your role by adopting a repeatable, trusted process—like the 8-step framework in The Value-Driven Business Analyst—that helps you lead with clarity, gain confidence, and demonstrate consistent value.

#2 – How to Sequence Your Business Analysis Work Strategically

When everything feels like a priority, it’s easy to stall out. Discover four practical strategies to sequence your business analysis work with clarity, reduce risk, and keep your project moving forward with purpose.

FAQs

Question: Why is sequencing business analysis work so important?

Answer: Without a clear strategy, BAs can create bottlenecks or overlook critical insights. Strategic sequencing helps manage complexity, align teams, and ensure you’re solving the right problems at the right time.

Question: What are some effective strategies for sequencing analysis work?

Answer: Key strategies include identifying dependencies, working to the critical path, reducing risk early, and generating quick wins. Each helps you balance momentum, clarity, and delivery value.

Question: How do I know which sequencing strategy to use?

Answer: Most projects benefit from a blend. Start by analyzing where ambiguity or risk is highest, what work unlocks progress for others, and where you can deliver early value. Use these insights to build a smart, flexible business analysis plan.

#1 – A Simple Business Analyst Mindset That Changes Everything

Use case thinking isn’t about documentation. It’s about perspective. Uncover how adopting a simple, scenario-focused mindset helps you uncover missed requirements, align software behavior with real-world use, and add immediate value to any project.

FAQs

Question: What is use case thinking, and how is it different from writing use cases?

Answer: Use case thinking is a mindset that focuses on how users interact with a system. It’s less about documentation and more about uncovering the hidden steps and edge cases that ensure your solution works in the real world.

Question: Can I use use case thinking without formal use case documents?

Answer: Absolutely. This mindset can be applied when writing user stories, creating flowcharts, or simply discussing requirements. It helps you ask smarter questions that reveal gaps stakeholders often overlook.

Question: What kinds of issues does use case thinking help prevent?

Answer: It helps catch edge cases like forgotten passwords, incomplete forms, or simultaneous data edits that can derail functionality or user experience if missed. It ensures the system behavior aligns with user expectations.

That’s a wrap! 10 videos!

What business analysis topics would you like to see us cover next year? Please reach out and let me know.

Ready to go deeper? Join us for The Business Analyst Blueprint training program:

Celebrating My New Book – The Value-Driven Business Analyst

Hi, I’m Laura Brandenburg with Bridging the Gap, and today I just want to share a little bit more about my new book, The Value Driven Business Analyst. It’s so new that I still don’t have my actual copy yet, I only have my review copy. But it is very much a real book with tables and diagrams of call outs.

Quite thick and hefty as well. Over, I think, almost 300 pages. And I just wanted to share a bit about why this book, why now we are at such an inflection point in the world, in the profession, in how we do business.

Why This Book for Business Analysts, Why Now

There is never been more change, more acceleration, more needs to pivot. What? No matter what kind of organization you are at and what do we need when there’s change?

We need business hours and we need good business analysts to focus on value. I think this is a time for the BAs to be really elevating the conversation about what business analysis is, and also be 100% committed at every layer of our work to deliver value and to shift how people see us as valuable. And so The Value-Driven Business Analyst is both a collection of practices and techniques.

It’s a how to guide of how to be a value-driven business analyst, what to actually do on a project or a change initiative. But it is also about how to ensure that you’re doing those things in a value creating way, and also shifting the perception of the business analysis role as you go through the business analysis work.

The Foundation of the Book: The 8-Step Business Analysis Process

So I want to share it today a bit about what’s included at the book, and also how you can go ahead and get your copy and claim some exclusive bonuses. So the foundational structure of the book is the business analysis process, this eight step framework that goes from this initial idea that comes in the form of an email or maybe a high level document dropped into our lap that we need to get oriented around what this project is, who to include, what our role is, and all the way through.

Discovering the business objectives are why we’re doing this project. Defining scope or what’s the boundary of what’s in and out. Super important to get clarity on early on our plan. So as a business analyst, what deliverables will we be creating to, elaborate that scope into a set of implementable details for the solution team and then defining those requirements, which involves discovery, analysis, and validation to make sure everyone is on the same page.

That avoids a lot of rework right there. And then we shift to more of a supportive role where we’re supporting the tactical implementation and ensuring they are implementing a value driven solution and the business to embrace that solution and adopt it as part of their day to day practice. And then finally, we look at what value was created, what was the ROI on this project, how can I improve my business and off this practice going forward?

Learn more about the 8-step business analysis process here:

The Book Also Includes Business Analysis Techniques and Tutorials

All throughout the book, I’ve included, call outs and techniques and tutorials, from The Business Analyst Blueprint®, which is a framework of techniques that we teach in detail at Bridging the Gap.

So for example, in step one, I’m getting oriented. There is a technique tutorial on the glossary in step two on discovery the primary business objectives. There is a technique sectorial on a process map.

And then there are entire chapters dedicated to the software level where we cover use cases, wireframes, user stories and product backlogs, as well as the information level where we go into the end of the relationship diagram, data map, data dictionary as well as some others. So there’s a lot of depth in content in this book. It’s really designed to be a how to manual for you and your business analysis work.

Generative AI Guidance for BAs Included in the Book

Now, one thing I wanted to add, because generative AI is such a big deal and it is influencing so much, you really can’t get away from incorporating AI in some way.

Every chapter has these call outs with ways and ideas for you to enhance your productivity with generative AI, and the early readers has said this is a really great balance of not handing over all my work to AI, but how do I lead and and use and leverage AI as a co-creative partner in my work, and have it help facilitate some of the more Indic mundane aspects of that role?

Want to learn more about Generative AI? Check out with my latest video on Prompt Engineering for Business Analysts.

For me? So that’s a big piece that people have really liked so far when they’ve seen it. All right.

How to Get Your Copy of the Book

The book is available at https://www.bridging-the-gap.com/value/

It’s also available on Amazon – in every possible country Amazon allows us to distribute to. You can find country-specific URLs at the link above. Or, if you just search for the “value driven business analyst” or my name, “Laura Brandenburg” it will show up for you.

Register Your Book Purchase for Exclusive Bonuses

And when you get the book, make sure to register your purchase at: https://www.bridging-the-gap.com/value/

There will be some exclusive bonuses for you to receive once you register your purchase. And that will allow us to deliver those bonuses for you.

I’m so super excited to have you be part of the program or a part of the book and part of our reader circle, and part of what we’re doing at Bridging the Gap.

Please continue to do the great work you’re doing as a business analyst. We really, truly built our profession, one business analyst at a time, one person, and we changed the world one project at a time. Thank you for doing what you do as a business analyst, and I hope that you’ll pick up a copy of the book. Thanks so much.