A TOOLBOX of techniques that you can pick and choose from, based on the needs of your project and team.
A FRAMEWORK that guides you step-by-step what to when.

At Bridging the Gap, we provide an organized, streamlined, and practical toolbox and framework in the form of The Business Analyst Blueprint® – it’s both a framework for approaching business analysis skill development and the name of our flagship, online, practical business analyst training program.

And it looks like this (and keep reading below for a break-down of what each part is and what it means):

The Business Analyst Blueprint® Framework is Organized Into Analysis & Communication Techniques

The first thing you’ll notice about The Business Analyst Blueprint® is that the techniques are organized into Analysis Techniques and Communication Techniques. The Analysis Techniques are the models and templates we use as business analysts to analyze and think through the requirements.

Requirements do not get created in a vacuum. We must elicit or discover them from our stakeholders. This is why knowing the right Communication Techniques to use as a business analyst are equally important.

The key Communication Techniques for collaborating with stakeholders are:

• Discovery Session – to discover information related to the process or requirements from business stakeholders, so the requirements represent their needs.
• Requirements Review Session – to validate the requirements that have been captured are clear and correct.

We also consider the glossary and user stories to be communication techniques, because their primary purpose is to capture and communicate requirements-related information to various stakeholder groups.

Here’s a video all about user stories – if you want to explore how to leverage them as a communication tool on an agile team.

The Business Analyst Blueprint® Framework: Multiple Levels of Technique Help You Avoid Missing Requirements.

The second thing you’ll notice about The Business Analyst Blueprint is that there is not just one set of analysis techniques. We miss requirements either when we don’t involve the right stakeholders (i.e., apply the right communication skills) or overlook key areas of requirements because we are only looking at one view.

When you use multiple techniques, particularly powerful analytical and visual models, you will find that you naturally see gaps that others gloss over and identify the downstream impact of a change or new solution.

The Business Analyst Blueprint® framework includes 3 key levels of analysis that are important to fully understanding a problem and solution domain, when software is being implemented as part of the solution. These are the business-level, software-level, and information-level.

Let’s look at each of these separately.

The Business Analyst Blueprint® Framework: Business Process Level

The Business-Level articulates how the business work flows operationally. When you have a clear understanding of the business process, you will be able to clarify the business problem to be solved and ensure the technical solution delivers actual value to the business.

At this level, the analytical techniques include:

• A Business Process Flow diagrams which is a visual model showing the end-to-end flow of the steps a business user (or group of business users) take to accomplished a desired outcome within the organization.
• An accompanying Business Process Document which is a textual model providing additional details like business rules, exceptions, entry and end points.

Analyzing a business process is almost always a great way to start figuring out what problem needs to be solved and getting stakeholders on the same page about the key issues to be addressed by a project. Often you can solve a lot of problems just by clarifying the “as is” or current state process, so this is a really productive set of techniques to have in your toolbox.

Learn more about creating process flow diagrams, or process maps, in this video:

The Business Analyst Blueprint® Framework: Software Level

The Software-Level captures how the software system supports the business workflows. When you analyze your functional (software) requirements in use cases and visually model them in wireframes, you create the perfect combination to get your business stakeholders and technical implementers on the same page about the requirements more quickly.

At this level, the analytical techniques include:

• Use Cases which is a textual model that describes exactly what the software needs to do, and capture the requirements in a way that is clear to both the business and technology stakeholders, so that the software development team can build what the business actually wants.
• Corresponding wireframes show what the screens on the page might look like, and make it easier for stakeholders to visualize the requirements and provide meaningful feedback.

Use cases also help you generate a lot of high quality questions to be asking, because missing pieces and requirements pop out pretty quickly with a good set of use cases. What’s more, you can use them for both new software development as well as configurations or customizations of COTS or SaaS projects.

Learn more about use cases in this video:

The Business Analyst Blueprint® Framework: Information Level

The Information-Level addresses how data and information are stored and maintained by an organization. Data modeling is critical on all kinds of projects, but especially data migration and system integration projects.

And while data modeling can seem quite technical, the way we teach these techniques at Bridging the Gap is from a business-focused approach. And using these modeling techniques can help you earn credibility with your developers, since you’ll be able to talk in their language (even when you don’t know how to code or write SQL).

Key data modeling techniques include:

• Entity Relationship Diagram (ERD), which bridges gaps between business concepts and technical database design using a simple visual format that really engages stakeholders.
• Data Dictionary, which shows you how to organize and drill down into the detailed data requirements. You will also take away the essential concepts you’d glean from an introductory SQL class.
• Data Map, which shows you how to visualize the information flows between systems and clarify boundaries that speeds up the scoping and elicitation process.
• System Context Diagram, which shows you how to visualize the information flows between systems and clarify boundaries that speeds up the scoping and elicitation process.

This video is a great place to start diving into data modeling:

The End-to-End Business Analysis Process in The Business Analyst Blueprint® Framework

The next thing you’ll notice about The Business Analyst Blueprint® Framework is that there is a foundational framework underlying the techniques. This is the business analysis process, or the end-to-end approach you apply to be successful and effective on a typical business process improvement and software project.

Having a structure and trusted approach gives you credibility.

The business analysis process leads you step-by-step through how to approach a software project as a business analyst and covers:

1. Get Oriented – Start actively contributing as quickly as possible.
2. Discover the Primary Business Objectives– Ensure the right business problem is solved.
3. Define Scope– Gain agreement from stakeholders on the scope of the project.
4. Formulate Your Business Analysis Plan– Identify the deliverables, stakeholders, and timelines for a comprehensive solution.
5. Define the Detailed Requirements– Establish an efficient and collaborative rhythm.
6. Support the Technical Implementation– Ensure the technical solution meets the actual business objectives.
7. Help the Business Implement the Solution– Support business stakeholders so that the solution ultimately delivers the intended result.
8. Assess the Value Created by the Solution– Assess the ROI of the solution.

As you leverage this process framework, you’ll gain increased recognition for the value of business analysis, and you’ll start to get pulled into more interesting projects, and be engaged earlier in the process. Here’s a video about the business analysis process framework.

Leverage the Power of The Business Analyst Blueprint® Framework

When you leverage a framework like The Business Analyst Blueprint®, you’ll be able to shift from being reactive to proactive. You’ll have a toolbox of techniques to use in just about any situation you find yourself in as a business analyst, and you’ll know exactly what to do when!

Business analysis can feel so fuzzy and mystifying, but it certainly doesn’t have to be that way.

Join The Business Analyst Blueprint® Training Program

Click the image below – or visit this link – to find out all about The Business Analyst Blueprint® training program – our practical, results-oriented program designed to help you achieve more success in the real-world as a business analyst.

I hope to see you in class!

With data mapping, you can take control of your projects from the very beginning, setting the stage for successful implementation.

In this video, Laura will guide you step-by-step through the process of creating a data map, without needing any type of coding language or SQL knowledge.

Once you understand data mapping, you’ll be empowered to tackle data migration and system integration projects with confidence!

In this video, you’ll discover:

• A data mapping sample
• The key components of a data map
• Resolving potential issues with data modeling
• Finding data mapping issues in the data model

As a business analyst, you need to have the ability to showcase how data seamlessly flows between information systems ensuring smooth operations and avoiding the headaches of data inconsistencies and mapping issues. With data mapping, you can take control of your projects from the very beginning setting the stage for a successful implementation. That’s why in this video, I will guide you step by step through the process of creating a data map, all without needing any type of coding language, or even SQL knowledge. Once you understand data mapping, you will be empowered to tackle data migration and system integration projects with confidence. So don’t click away.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis, tips and techniques.

A Data Mapping Sample

Essentially, a data mapping specification will analyze on either a field-by-field basis how to move data from one system to another. Here is a sample data mapping template and an example that you can use to see how this works in action.

This is a hypothetical example, assuming that we’re sending a data feed from the Bridging the Gap article repository to a search engine.

In this scenario, I would want to map the key attributes of an article, such as the title, the category and content to the attributes specified by the search engine. This analysis exercise would ensure that each piece of information ended up in the most appropriate place in the target repository.

For a little context, by the time that you are at this stage of the project, this is definitely not the first technique that you would be using most often.

By now you have analyzed the business process, you’ve defined the functional software requirements, you have an overall vision of the project scope. You’ve also done some high level data modeling, like creating an ERD or an Entity Relationship Diagram, and a system context diagram. Now you are looking at how data is going to flow specifically from one system to another at a very granular level of detail to achieve those bigger picture business objectives.

The Key Components of a Data Map

To achieve this goal, let’s just talk about the key components of a data map.

• It’s going to contain a list of attributes. For the original source of data, often that additional information comes from a data dictionary.
• Then it’s going to have a corresponding, or mapped, list of attributes for the target data repository, again, with additional information from your data dictionary.
• Then it has translation rules defining any data manipulation that needs to happen as information moves between the two sources, such as setting default values, combining fields, or mapping the values from one example to another.

Data Mapping is About Resolving Potential Issues

In its essence, data mapping is about resolving potential issues. Creating a data mapping specification like this requires discovering and resolving potential issues prior to the mapping being implemented. You don’t want to get to the point where you’re trying to move the actual data between systems and all kinds of errors are popping up or the users are looking at the data and feel like so much data is just missing. We lost the data. You want to prevent those problems by doing this analysis upfront. In a data migration or an integration, there are any number of differences between how the data is stored and where it goes can cause that data to be lost or misrepresented in some way that looks really significant, especially to a business user.

For example, it might be that the source data has a text field and your target data repository uses an enumerated list. Without analyzing the data and providing some logic for how to map those text values to the values in that enumerated list or the list of potential allowable values, or doing some sort of data cleanup before that happens, you’re likely to experience a lot of errors in the system migration.

Even in our simplest data mapping exercise here in this example, there are multiple mapping issues that we had to work through.

• For example, the article title contains HTML in the source data. Not uncommon to have some sort of code that would then in another system show as code versus automatically be filtered out.
• Also the source data can have multiple categories while the search engine has a single text field. You might want to have logic for turning multiple values in the category field into a comma or semicolon separated list in that text field.
• Another example is that the article truncated to 4,000 characters. While there’s no limit in the source data, the same with the URL.

In each of these cases, as the business analyst, you want to use your knowledge of the business process to identify how to handle that mapping issue or collaborate with the business stakeholders to really discover their needs and their desires and what they’re willing to invest in potential data cleanup and manipulation and organization and scrubbing before the migration or the integration happens.

It’s really important. I know I keep stressing this, but it’s important for this to happen before the actual development part of the data migration starts so that these issues can be found and then direction can be provided to the database developers who may not have the same in depth knowledge of the business that you’ve developed as the business analyst.

It’s also not uncommon to need the business to do actual data cleanup before the migration. Often that best happens in the source system because you have all the data there versus trying to get over what you can and doing things in the new system or the target system.

Finding Data Mapping Issues in the Data Model

Data mapping is going to help you get really, really clear on how the data is going to flow from one system to another. However, mapping issues can be even more significant than like how one field maps to another.

Often when you’re moving between systems or relationships. In the data model itself that are different between systems. For example, if our article system happened to have a concept of a newsletter or a group of articles that wasn’t maintained by the target system, we could lose a lot of value in how our content was organized during that migration.

These sorts of data modeling differences show up when you’re creating an ERD or an entity relationship ship diagram. An ERD is an incredibly useful tool to use before you do more detailed data modeling like this so that you can get a sense of the big picture of how key concepts in your business relate before you dive into the details.

If you’re not familiar with what an ERD is or how to construct one, we have a free sample and a tutorial that you can download.

>> Click here for free download <<

Additionally, another critical data modeling technique for system integration and migration projects is called the system context diagram.

If you want to learn more about that, watch the video below and I’ll tell you more about that next. I’ll see you there.

No, you don’t have to be a UX designer to even aspire to be one.

In today’s fast-paced world, getting everyone on the same page about software functionality is crucial. That’s where wireframes come in!

They are the secret weapon that saves time, improves collaboration, and ensures clarity in software requirements.

Wireframing is a technique that any business analyst can master, and in this video, you’ll discover:

• What wireframes represent
• The different levels of wireframe fidelity
• How to create a wireframe
• How to get business stakeholders feedback on wireframes
• Challenges to watch out when wireframing

Say hello to the System Context Diagram, your secret solution to project scope!

In today’s world, projects are only becoming more and more complex, and even the tiniest tweak can send ripples through numerous systems.

A System Context Diagram is an elegant solution and visual powerhouse that will have your business and technical stakeholders nodding in agreements as you confidently navigate the intricacies of scope.

In our new video, Laura will guide you through the creation process and unveil the three primary parts of its syntax. You’ll also discover practical examples and insider tips that’ll get you comfortable with utilizing a System Context Diagram.

As a business analyst, you can provide tremendous value by not only getting sign off on the requirements, but also getting buy in from stakeholders about what the solution needs to do and how it fits into their workflow before development even begins.

So how do you get buy in and meaningful sign off on your requirements to avoid unnecessarily changes and costs? In this video, Laura shares 3 tips for getting meaningful sign offs that you can use on your next project!

Engaging stakeholders is a critical piece to streamlining your sign off process. Our free guide, 10 Tips for Engaging Stakeholders, is a great place to start so you can supercharge your stakeholder management skills.

>> Download Free Guide <<

One of the most frustrating challenges on a project is when the developers build a solution that everyone thought the business had signed off on, only to have significant changes surface during testing or even after deployment. Business analysts can provide tremendous value by getting not just the sign-off on the requirements, but buy-in from the business stakeholders about what the solution needs to do and how it fits into their workflow before the development even begins.

Gaining buy-in saves a tremendous amount of time and effort and reduces the need for expensive rework late in the development cycle. Keep watching, and I’m going to share how to gain buy-in in a meaningful way on your requirements.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos and business analysis tips and techniques.

Requirements Sign-Off Tip #1 – Focus on Sign-Off as a Tool for Obtaining Buy-In

Let’s start off with tip number one, which is to focus on sign-off as a tool for obtaining buy-in.

The BA’s job is to get meaningful feedback on the requirements so that they represent what the business actually wants from the solution. In my very first role, we used to walk through the requirements line by line as part of getting sign-off. These meetings would take hours and would require dozens of people to be there, and then I need to get an email confirmation from each and every person about that same long document.

I know in other organizations, sometimes an actual signature, either physically or electronically, is required and sometimes this can be necessary for regulatory reasons. It’s more important, though, to focus on what that signoff actually represents, and that is buy-in. Buy-in means that the business agrees with what’s documented. It actually wants to move forward with having that solution built based on the specifications.

As I matured as a business analyst, I started to shorten my reviews and really hone my approach to make it more efficient.

Requirements Sign-Off  Tip #2 – Be Clear on What Input You Are Looking For

That leads me to sign-off tip number two, which is to be clear on what input you are even looking for. Most projects have different phases of sign-off. You might sign-off or approve the scope or the business case. You might sign-off on specific requirements, deliverables, such as a business process or a use case, or even a data mapping document. You might have sign-off on the implementation and transition plans.

Gaining sign-off at each stage is significant, and using your business analysis framework to guide that is crucial. It provides a valuable opportunity to engage your stakeholders, to seek their input and ensure their buy-in at each stage of the life cycle so that you don’t get off track doing something that’s irrelevant because you are getting that buy-in incrementally and iteratively throughout the project.

By obtaining sign-off in those major phases, you establish a solid foundation for success, and you also foster a shared sense of ownership from your business team.

Oh, and that business analysis framework I just mentioned, if you don’t have one yet, you certainly need one. You can start by learning about our eight step business analysis process framework that I outlined in another video I did a while ago, which you can watch after finishing this video by clicking below.

The mindset here that you want to bring into your work as a business analyst is, what is the next decision that needs to be made to move my project forward? Always be driving towards that as a business analyst and moving from ambiguity to clarity in the context of that decision. This will keep you moving forward in a proactive and efficient way and not getting bogged out in making decisions about details too early in the project, which often leads to analysis paralysis.

Requirements Sign-Off Tip #3 – Customize Your Approach to Sign-Off Based on Your Stakeholders

Requirements tip number three is to customize your approach to sign-off based on who your stakeholders are.

Let’s really be honest here. Most of our stakeholders are not all that great at reading requirements. As business analysts, we bring a lot of expertise in writing and organizing requirements and analyzing requirements, and there are times when a requirements review or a walkthrough is the best way to get sign-off. But I found that the easiest way to get buy-in is when I customize my approach specifically to a group of stakeholders.

If you have a hard time engaging stakeholders in sign-off or a hard time engaging them in general, we recently created a new free guide that aims to help boost stakeholder engagement. If you want a copy, you can click below to get a download of it.

>> Download Free Guide <<

Let me just share a few examples of how I’ve customized my approach.

• On one contract, I reviewed annotated wire frames with the business stakeholders. I had the use case and the user story right up in hand. I had done that analytical thinking and writing to make sure I had all the questions that I needed to ask and all the information that I needed to verify. I used my use case thinking to identify those questions. But ultimately the details made it into the user stories for the developer to review and implement. But on the screen, it was a visual model of what that screen might look like with some little sticky note annotations that they could review and provide feedback on.
• On another project, I created a clickthrough prototype. That could handle a few different key scenarios and had the business stakeholder actually use that prototype to provide feedback. This was somebody who is just super hands-on and tactile and like needed to see it working in order to be able to really provide great feedback. I was able to do that in a click-through prototype. You might even consider slide decks with abstract visual models and key bullet points for high level and strategic details.

For those who need to buy into the project vision and approach, but not necessarily all of the minute little details, consider who your audience is. Consider what feedback you need from those stakeholders and then look at how to get that specific kind of feedback and buy-in. That is always what you want to be doing as a business analyst to make your process efficient and effective. I really do believe it’s your job to find ways of communicating the requirements and keeping them in sync, and it’s their job to meet you halfway and provide some meaningful feedback.

Is Requirements Sign-Off Still Relevant in Agile?

One question I often get about this is whether requirements sign-off is still relevant in agile.

While agile practices might not require an official “sign-off,” there is definitely an assumption of buy-in built into the user stories that are brought forward for implementation in a sprint. If you want to save unnecessary rework, it’s essential that either a product owner or supporting business analyst gains buy-in from all the necessary business stakeholders on the solution approach and the details before that user story is brought to a sprint for implementation.

To ensure successful signoff and to obtain meaningful buy-in, remember these key steps.

• Focus on securing buy-in from your stakeholders and clearly define the input you need and the decision that needs to be in the main next, and customize your approach for each stakeholder or stakeholder group so that you’re meeting them where they’re at and can get the best possible feedback. Engaging stakeholders is crucial for a streamlined sign-off process.
• Don’t forget to download our free guide, “10 tips for engaging stakeholders,” to supercharge your stakeholder management and your skills in engaging stakeholders.
• Lastly, as part of the sign-off process, incorporating requirements reviews or walkthroughs can be essential.

Join me in the next video below where I’ll share practical best practices for efficient and effective requirements reviews. I’ll see you there.

• What documents should you create to capture those crucial requirements?
• How can you ensure you’re fulfilling your role as a diligent business analyst?

The path to success lies in understanding the power of documentation. In this video, Laura shares examples of the five types of requirements documentation that every business analyst needs to start using, including:

• Scope Statement Specification
• Business Analysis Plan
• Business Process Documentation
• Functional Requirements Documentation
• Information or Data Requirements Documentation

Throughout this video, Laura mentions various free resources we have that will give you a jump start in your requirements documentation, you can download those at the links below:

>> Click here to download Business Process Template <<

>> Click here to download Use Case Template <<

Imagine this. You’re ready to do a deep dive into a new project as a business analyst, but amidst the sea of information and tasks at hand, you find yourself at a crossroads. Which documents should you actually create to capture these crucial requirements? How can you ensure that you’re fulfilling your role as a diligent business analyst?

The path to success really lies in understanding the power of documentation, not just as a create all the documents type of tool, but as an analysis and a thinking tool, and a helping the business make better decisions type of tool. Today I’m going to cover five types of requirements documentation that every business analyst needs to be aware of and start using on most of their projects.

Hi, I’m Laura Brandenburg from Bridging The Gap where we help you start, succeed and excel in your business analyst career.

Scope Statement Specification

We’re talking about five types of requirements documentation today. The very first one I want to talk to you about is the Scope Statement. This is the very first type of document that you want to create on just about any type of project. It defines the scope of the project.

This specification might also be referred to as a business case or a vision document, or a Business Requirements Document, although in practice, BRDs typically include many additional sections that would include functional requirements. I’m going to classify that as a separate deliverable. We’ll talk about that in a little bit.

In this requirement specification, the scope statement, you’re essentially answering the following questions:

• What problem are we solving?
• What’s the business need?
• What is the scope of the solution to that problem?
• How in a high level view are we solving that problem?
• What does the solution look like?

Then you’re really using both of those questions to get to this final question, which is:

Is the investment in solving that problem worth it? Is there going to be a positive ROI, or return on investment, in this project?

Now, in an agile environment, those sorts of questions might be answered in an epic format, but regardless of what format, what document, what type of methodology you’re using, you want to get clear on what problem you are solving and what the solution looks like at a high level so that you’re scoping that project and getting buy-in that you need from senior level stakeholders to move forward.

Business Analysis Plan

Once you have the scope, the next type of requirements documentation is the Business Analysis Plan. A business analyst will typically create a plan that outlines the elicitation, the requirements analysis, and the validation and verification efforts as well as clearly indicate who is responsible for what within the context of the business analysis effort.

The business analysis plan will often be driven by the organization’s business analysis or software development methodology. Again, that might be formal or it might be really informal. If you don’t yet have a methodology, you can start with the eight step business analysis process framework that we teach at Bridging the Gap. I did an entire video outlining this framework step by step. Be sure to watch that after you finish this video.

Business Process Documentation

With the scope defined and your plan in place, you know where you’re headed, it’s time to start digging into the details. Although there is always a temptation to jump right into the software solution or functional requirements, it almost always makes sense to first start with analyzing the business process.

• Part of analyzing the business process is a process flow diagram, which is also sometimes called a workflow diagram or a process map. It shows the big picture of how the overall process flows from a stakeholder or end user perspective. This is a type of visual model that’s a great way to elicit a lot of information and create a shared understanding of both your current state and your future state process relatively quickly.

Here’s an entire video on creating a great process map:

• To accompany your process flow diagram, you want to use this textual business process document. We teach this technique of textually modeling a business process in our online business analysis training courses at Bridging the Gap because it helps you capture more details and analyze the process in more depth. Often, a process flow diagram is a great way to get the big picture, but you’re going to overlook some nuances and some details that a textual template will help you think through. Often those issues or inconsistencies are really easy to glaze over with just a workflow diagram, and you are going to catch them when you do the more in-depth analysis using a business process template like this.

>>Click here to download the full template<<

• To help you in that process, we have a really valuable resource for you available at Bridging the Gap. Our business process template is designed to help you capture and analyze the intricacies of your business process. By using this template, you can uncover all of those hidden issues and gain a deeper understanding for your workflow. Click below to claim your free business process template download.

>> Click here to download Business Process Template <<

What’s really important in this third type of documentation, the business process documentation, is that you are getting a business perspective of both the current state, or as is business process, and your desired future state, or to be business process. This is going to help clarify, in even more detail, the specific problems that you need to solve using technology.

You can learn more about as is and to be business processes in the following videos:

Functional Requirements Documentation

Next up on the list, our fourth type of documentation, is functional requirements documentation.

If the solution is a software solution, not all solutions are, sometimes you can just update the business process to solve the business problem. We don’t always need to use technology, but very often we are leveraging technology as all are part of the solution. In that case, the business analyst is going to specify the functional requirements for the project. These are also known as the solution requirements, the software requirements, sometimes the technical requirements, or the system requirements.

Functional requirements identify what the system does, how it functions, and they are typically written at the level of what a given user, like an actual end user, a person, can get the system to do. It’s what they see in their interaction with the system that is a functional requirement.

There might be a lot of additional things happening behind the scenes. Those would be more technical system design type of requirements. A functional requirement would be something that an end user could experience in interacting with that software system. They can be captured in a wide variety of different requirements deliverables.

• The very first one that we love to teach, it’s one of my very favorite requirements modeling techniques, are called use cases. These are a very common way to capture a functional requirement. We teach use cases at Bridging the Gap, using the template that you see here. We do this because we find that use case analysis helps the BAs, again, identify otherwise missed requirements by getting really clear on that system user interaction. It’s a really key technique.

>> Click here to download Use Case Template <<

• To assist you in this process, we offer another great resource at no cost to you, which is our use case template. You can download the exact template that you see above. This is specifically designed to help you capture and document use cases effectively. By using this template, you can ensure that no requirement is missed and gain a lot of clarity on the interactions between the system and its users. Click below to claim your free use case template download.

>> Click here to download Use Case Template <<

• Other times use cases are captured together in a different type of document called a software requirements specification, or SRS, or a functional requirements document, FRD, those may also include non-functional requirements. They’re more of a list of requirements. The use cases though, because of the way they show the user system interaction, are really powerful analysis tools that help you think about what requirements you might otherwise miss.

• In an agile environment, functional requirements are typically captured in user stories, which are organized into a product backlog. You might still analyze the requirements and use cases to make sure you’re kind of keeping the thread of how all those user stories fit together in your product backlog.

You Don’t Need a Technology Background to Analyze Software Requirements

One thing I just want to mention here, for those of you who don’t have a technology background, this is the level at which you need to learn and understand how to talk intelligently about technology. It’s about what the system can do for the business, not about how the system is built. Even if this level of understanding technology systems is not appealing, you are probably better off focused on more business process focused business analyst roles.

I just want to highlight, you don’t need to understand how to code, how to run SQL queries, how to design the systems in order to get to this level of clarity that really gets business and technology users on the same page. This is more of an analytical thinking capability than a technical ability.

Throughout my experience, I’ve noticed that functional requirements can still be really challenging for many business analysts. There’s a layer of specificity that you need to get to, to really be effective at getting these right. That’s why I created a comprehensive video tutorial specifically on this topic. I highly recommend watching that video as well to gain valuable insights and clarity after finishing this video. You can click below to watch that video. It’s an excellent resource to deepen your understanding of functional requirements.

Information or Data Requirements Documentation

One fifth and final type of requirements documentation, and that is to capture the information or data requirements. In addition to the user facing functionality of the software, the business analyst may identify elements of the information model as well. There are a few common types of data requirements documentation.

• One of the very first is the glossary. This is used to define a common language and terminology. You were going to use this to get really crystal clear on what terminology your business is using, making sure that the way you use a term like “customer” or “account” or “order” in your business process, in your use case, is consistent and that all of your stakeholders have the same understanding of what that term means.

• The next really common data requirements model is an entity relationship diagram. This shows those key concepts that might end up in your glossary and how they relate to one another, what details are captured in the information system about each concept. For example, if you had an order, are you getting the order date? Are you getting links to specific products? That would be a relationship to another entity called a product. You’d have the order time, the shipping address, things like that. And where are those captured? That’s what your entity relationship diagram is showing. These can look really technical, but you can also do them at a very business abstract level view so they really show the business concepts and the business understanding of the information domain.

• The last thing I want to show you is called the data dictionary. It also fits into this category of data requirements documentation. It will go into the details then about the specific fields or attributes, such as how long can that field be? What type of information does it hold? Are there any validation or business rules?

• When you combine, you can elaborate and combine data dictionaries from multiple systems to show how fields from one system will map to another, either for a one-time system integration or a system migration project that would be one time where you’re moving data from one source to another. Or we’re using something like an API to show how the ongoing system integration works and how those fields map to one another. This is called data mapping. I’ve got an entire video on data mapping.

Again, while all of this data modeling stuff can seem really complicated and technical, the way we teach it at Bridging the Gap is very business oriented. In The Business Analyst Blueprint training program, you would learn each of these data modeling techniques as well as how to use system context diagrams to show the overall information or data flow for your project.

To get you started with an overview of data modeling, we also offer a free data modeling training course, which is a portion of our full-fledged data modeling training module.

Key Practice: Choose Your Requirements Documentation Intentionally

We just listed five categories of documentation and multiple different types of specifications you might use within each of those categories. By no means does a business analyst create every one of these specifications for each and every project. Most business analysts will pick and choose the most appropriate specifications given the nature of their project, and they’re going to customize those templates based on the stakeholder needs and project considerations.

You want to look at what is happening in your project and what is really needed to make the next decision. What’s even more important is that you have a clear and focused business analysis approach that enables you to be more strategic and proactive in terms of how you approach the project.

We’ve got a wealth of content dedicated to providing valuable tips and strategies and insights for business analysts like yourself to help you really be strategic and proactive as possible. We have new videos releasing here every week, but you’re going to have to subscribe to the BTG YouTube channel to stay in the loop with all of our new content.

Remember to claim our free use case template by clicking below. And f you don’t have a business analysis methodology nailed down yet, that is really the very next place to start.

Make sure to watch our eight step business analysis process framework video by clicking the video below.

I’ll see you over there.

Download Your Use Case Template Today

If you want to get started with your requirements documentation, I invite you to download our Use Case template (it’s free). You’ll learn the key elements that go into a business process model, and be able to kick-start your requirements documentation process.

>> Click here to download the Use Case Template <<

If you’re not using some type of diagramming tool in your business analysis job, you may be missing out on a powerful tool that can help you gain clarity quickly and effectively communicate your ideas to stakeholders.

As a business analyst, creating visual models like process flow diagrams, wireframes, or entity relationship diagrams can really speed up the requirements process and provide clarity. However, many BAs avoid creating visual models because they feel like they don’t have access to the right tools.

In this video, I’m sharing 5 diagramming tools you can afford, most even have free trials, so you can get started with your visual modeling right away.

To help you get started with visual modeling, we’ve created a FREE entity relationship diagram sample download that will give you an idea of how these diagrams can be used to represent complex relationships within entities.

>> Download the Entity Relationships Diagram Sample <<

Did you know that using visual models can improve communication, reduce misunderstandings, and facilitate collaboration in business analysis projects? If you’re not using some type of diagramming tool in your business analyst job, you may be missing out on a powerful way to help you gain clarity quickly and effectively communicate your ideas to stakeholders.

Stick around for this video where I’ll cover some of my favorite diagramming tools and visual models that are not only affordable, but also user friendly. You don’t have to be a designer or tech savvy to use them.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis, tips and techniques.

As a business analyst creating visual models like business process flow diagrams, wire frames and entity relationship diagrams can really speed up the requirements process and provide a lot of clarity. However, many BAs just avoid creating these models because they feel like they don’t have access to the right tools. These tools even have free trials, so you can get started with your visual modeling right away.

Diagramming Tool #1 – Visio (If You Have It)

The first diagramming tool is Visio. This is the one that’s used most predominantly by business analysts. Many organizations have licenses to Visio, which is why I wanted to bring it up first. It makes it a logical first choice for many of you.

While an individual license is not cheap, if your organization already has a license, it’s often easier to get access to it than to make the case for a separate investment in one of the other tools. It is relatively easy to use and there are a lot of online tutorials. It has out-of-the-box shape sets from many common modeling notations like UML and BPMN.

If you don’t already have access to it, it is one of the more pricey options. The last time I checked it was $589 US dollars for a professional license, but there is a 60 day free trial that you can download. If you are job searching and you see Visio coming up in your job descriptions, download that trial and get familiar with the tool. Otherwise, I’m going to share some more affordable tools that will serve your basic diagramming needs.

Diagramming Tool #2 – Gliffy

The second option is Gliffy. Gliffy is an online diagramming tool that allows you to create everything from basic workflow diagrams to BPMN and UML diagrams. It has out-of-the-box shapes from most of the common modeling needs. It costs $8 per month per user, and discounts are available if you pay for an entire year up front. There is a two week free trial. Gliffy was my go-to tool for a long time for everything except for wire frames.

Diagramming Tool #3 – LucidChart

My go-to tool these days is Lucidchart. I pay less than $100 a year for an online subscription. I’ve used it to create swimlane diagrams for our marketing processes and an entity relationship diagram for our ACBA registration information model, which I’m going to show you on the screen now. If you are not familiar with what an ERD is, this is a great example.

We also have a free sample that you can download by clicking below.

>> Download the Entity Relationships Diagram Sample <<

I also did a video tutorial on entity relationship diagrams that you can check out after this video.

Lucidchart has a free trial that allows you to create up to three editable models with up to 60 shapes. This is a great way to experiment with a visual modeling tool and not lose access to your diagrams after the free trial’s over. Either Gliffy or Lucidchart are really great ways to experiment with new modeling techniques, even if you don’t have Vizio.

And here’s the thing, when you are familiar with either of these tools, Vizio is not going to have that steep of a learning curve, as all the tools are relatively similar. It’s more about the conceptual understanding of how to put a diagram together. That is the thinking and the learning. The tool itself, is about finding where the right shapes are and making sure you know how to line up the lines and kind of put things together. But the tools themselves are relatively simple.

Diagramming Tool #4 – Balsamiq

Okay, so the fourth tool I want to talk to you about is Balsamiq. So Balsamiq is a rapid wire framing tool that captures the look of a hand drawn wire frame, but in an electronic format. Here I’m going to show you an example of a sample wire frame from our course materials showing the screen to log into a system. These hand drawn wire frames are effective because they don’t give the false impression that what’s behind the wire frame has already been implemented. One of the worst things that can happen as a business analyst is you show a really pretty user interface wire frame and people are like, great. It’s already built. Go make that happen. And you’re like, no, nothing works. Nothing’s clickable. But it looks so good. They think it’s already built when there’s a lot more structure in code that needs to be put in behind the scenes.

It’s also because it looks hand drawn, it’s easier for your stakeholders to provide feedback because it doesn’t yet seem complete. They’re not going to be like, “Oh, I don’t want to talk about this piece,” or have you move something because it’s very obvious that it’s a tentative or you’re throwing that out as a low fidelity or sort of a working model.

Within Balsamiq, there are several elements that you can drag and drop into your wire frame and like Gliffy, it’s online, so you don’t need to download any software. A single user license to Balsamiq starts at $9 a month and discounts are available for volume packs. They also have an extensive program offering for free versions to classrooms and open source projects and nonprofits. If you qualify for one of those, definitely reach out to them. They also have a 30 day free trial so that you can experiment with the tool and start to see how it works.

Diagramming Tool #5 – Axure

The fifth tool I wanted to share with you is a tool called Axure. So it’s been a long time since I used Axure, and so I’m not up to date on the latest functionality, but I just wanted to share it with you because it’s a totally different type of tool. It’s a prototyping tool that allows you to create wire frames, site maps, prototypes, click through prototypes, mobile prototypes, and flow diagrams. It allows somebody who does not have coding ability, who’s not a technologist, to create prototypes where stakeholders can actually click a button and see something functionally happen as a result.

I’ve had a lot of success using those sorts of click through prototypes to have stakeholders review and validate requirements that were diagramed that way. It does require additional work for you. It’s not as easy as putting together a Balsamiq wire frame. With even more work, you can integrate some data into that prototype as well. Then you’re getting really good end user feedback of how they would actually use the system.

It does come with a higher price tag because it has a lot more functionality. It starts at $25 a month. There’s also a 30 day free trial, so it’s something you can experiment with.

Diagramming Tool – BONUS! – SmartArt in Microsoft Office

And then finally, last but not least, I wanted to share about Smart Art in Microsoft Office.

Smart Art is a built-in feature for Microsoft Word, Excel, and PowerPoint. You can use it to create simple process flows or images that represent the pros and cons of a decision. You can show hierarchies and relationships of information. I have used it to create really clunky looking wire frames of how a screen might look in a PowerPoint slide.

There are ways you can use it to show information and incorporate information into simple diagrams that you might include in your scope document or a slide deck. It is not the most efficient way to create models, but it is an option. We’ve had course participants create workflow diagrams using the out-of-the-box shapes in Microsoft Word. And so it’s a great way to practice modeling, learn that tool set, and put something together electronically to share with your stakeholders even if you don’t have access or want to bother with any of the tools mentioned above.

What Will Your Diagramming Toolset Be?

So my question for you is, what will your tool diagramming tool set look like?

The tools we’ve covered in this video are simple and for the most part, relatively affordable and accessible. With one or two of them, you’re going to be able to create everything you need as a business analyst. But remember, the most important thing is to know how to leverage those visual models to clarify business processes, to get users on the same page about software requirements, to model your data and information appropriately.

To help you get started with visual modeling, we’ve created a free entity relationship diagram sample download that will give you an idea of how these diagrams can be used to represent complex relationships between entities. You can claim your free download by clicking below. However, remember diagramming tools are just one piece of the puzzle. To excel as a business analyst, it’s essential to know how to leverage visual models to clarify business processes and software requirements.

>> Download the Entity Relationships Diagram Sample <<

One of the must know models for the business analyst is the process flow diagram. We have an entire video on how to create a process flow diagram. If you click the video on screen now, I’ll see you over there.

While it’s important that a business analyst has a conceptual technical understanding as it helps you analyze the problem to be solved and communicate with technical stakeholders, you don’t need to be able to write code or run database queries.

In this video, I share the technical skills you do need to know and how they will help you position yourself more strongly in the job market and hold up your side of the conversation with developers.

For those who like to read instead of watch, here’s the full text of the video:

Today we’re here to answer a question from Monica. She asked, “What are the top three to five technical skills a business analyst with a business background needs to have?” Specifically, she asked this around wanting to be able to make sure she could have good conversations with the technical people on her project teams.

Here’s the thing about technical skills in BA jobs – you’ve heard me say it before and you’re going to hear me say it again – you see them as job requirements a lot of times in business analyst roles. And a lot of times those requirements are extremely misleading.

You can, of course, to become more technically minded as a business analyst, learn how to write code. You could go take an introduction to programming and a sequel course and learn a bunch of technical skills that you may never, ever want to use in your career. You could do that. Or you could learn some requirements models that allow you to have those very productive communications and conversations with technical professionals and understand more about how the technology is structured and give you insight into what questions to ask than the technical skills, themselves, actually do.

What I’m going to talk about here, in terms of technical skills, are three requirements models or three types of requirements models that you might want to look at if you feel that you’re not “technical” enough to be a business analyst. I will finish with one closing bonus skill that might catch you by surprise.

Let’s talk about these three models.

Technical Skill 1: Use Cases for Functional Requirements

The first is use cases. Use cases are a textual description of how a business user or a user of a software application interacts with a software system. They force you to get really specific about what function or feature that system needs to have in order to meet the business needs. Underlying that feature is often a piece of code that a developer has created, customized, or integrated to make that function work.

But what you need to be able to specify as a business analyst is what that software needs to do, and the condition under which it needs to do it. A use case is the perfect model to get familiar with that business user system interaction. It’s much more detailed than a typical business process model, and it’s much more specific. You get into those specific technical requirements even though you don’t know how to write the code that underlies it.

Technical Skill 2: Wireframes for Visual Requirements

The second requirements model that can be helpful in expressing technical requirements like this is wireframes. Wireframes are visual descriptions, or visual renderings, of a user interface screen. Essentially, when I go to a software application as a user, what does it look like to me?

Not, specifically, what are the colors, what are the buttons, and how are they; circle or square? That is important at a certain point of a project, but a wireframe can be much less specific than that. It can use general buttons and not be specific on colors. Use grayscale. You’re trying to show this is what the user interface screen might look like to a potential user.

Again, you’re getting to that level of detail of what that software system needs to be able to do and look like, again, without having to write the code behind it. There are a lot of tools today that people, like me, who don’t have coding backgrounds, are able to use that just drag and drop those features into a wireframing tool so you can create them without having to know how to code.

Technical Skill 3: Data Models for Data Requirements

The third set of models are data models, such as entity relationship diagrams, system context diagrams, data flow diagrams, data dictionaries. There are a bunch of different models included in the data modeling area.

Essentially, all those models allow you to understand how the database is structured, how information is stored, what information needs to be stored. So, if you’re looking at a business process and there are different fields on a form coming in through some sort of an input:

• How is that information stored in your software system?
• What are the rules that need to be applied when that information is stored?
• How do the different pieces of information that come in through different business processes, how do those relate together?

Different data models allow you to look at that information model in different ways. This is how you, essentially, learn how to model a relational database or express data requirements without knowing SQL.

A not very well-kept secret is that I’ve never learned how to write SQL. I did learn how to do a little bit of coding in a very proprietary database language that was very specific at the very beginning of my career, but I’ve never learned SQL. I’ve never used that skill to move forward as a business analyst. I’ve done a lot of work with data requirements and data modeling and helped a lot of teams figure out what those data requirements and databases should look like by using some of the core data modeling skills.

And One Bonus Technical Skill…Asking Questions

I promised you one bonus.  Our three models are use cases, wireframes, and data models. What’s that bonus skill? The bonus skill is something that you’re probably already good at if you’re a business analyst, and that’s the ability to ask questions.

When it comes to technical questions, it’s like the ability to ask that question that you really feel like you should know. You should know the answer to this and you don’t. It’s asking questions about how things are organized, what are the capabilities of the technology, what are things that you might not think of. You’re using that so you can understand the possibilities of the technology and how the system is designed without knowing how to do it yourself.

In my experience, you could spend a lot of time learning how to build these systems and write code. That could have a measurable impact on your career. Or, you could spend time learning these core skills that you’re going to use forever in your life-long career as a business analyst.

They’re going to give you a more advanced level of understanding of the potentials of technology than you would get from learning how to line-by-line create the code because they’re going to enable you to work in any sort of situation as opposed to just the coding language that maybe you learned. There are dozens of coding languages out there, dozens of different technical environments. So, you’re never going to become the expert on all of them unless you want to be the expert and the doer of that kind of thing. If you’re a business analyst, I’m assuming you probably don’t.

Again, use cases, wireframes, data models, and having the courage to ask questions and get the answers to those questions so that you really have a good technical understanding in your environment. Those, to me, are the skills that you need to succeed as a business analyst with a business background in today’s technical environment. They will take you far as a business analyst without getting you lost in the weeds of learning specific technical coding skills.

>>How to learn these key technical business analyst skills

When you join The Business Analyst Blueprint® training program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

>> Click here for more information about The Blueprint <<

In this short video, you’ll discover:

• The definition of a To Be Business Process
• How to analyze a To Be Business Process
• Where to start in your analysis
• What type of collaboration to expect

Download Your Free Business Process Template

At Bridging the Gap, we are all about helping you succeed as a business analyst, no matter where you are in your career. That’s why we’ve created a Business Process Template you can download for FREE.

In this template, you will discover how to:

• Help business users from multiple departments clarify their actual step-by-step workflow
• Avoid wasting money on software solutions that don’t solve the right business problems
• Help new business analysts figure out what questions to ask when starting on a new project

> Click here to download <<

Now, Let’s Dive Into Mapping the “To Be” Business Process

Is your organization rolling out a new technology that impacts the business or developing a new product or service that your organization needs to figure out how to deliver? If so, as a business analyst, it’s your role to analyze the To-Be business process and help your stakeholders define exactly how work will flow once that new solution is in place.

Stay with me and I’ll share exactly how to do just that.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis tips and techniques.

Today we’re going to be discussing the To-Be business process and how business analysts can analyze different organizational processes to help improve the business operations and provide more clarity to all members of the organization.

Definition of a “To Be” Business Process

First, let’s start by defining what a To-Be process is. A To-Be business process defines the future state of a business process in an organization.

Typically, the analysis goal in putting together the future state process is to clarify how the business process will work at some point in the future once changes have been made in the organization. And those changes could be business changes or technology changes.

How to Analyze a “To Be” Business Process

So a To-Be business process contains all of the sections in a typical business process model – a description, a list of rules, a list of steps and exceptions, a process map, perhaps even some business rules. To get a rundown of these elements, you can download our business process template. It’s absolutely free.

When it comes to defining the future state, it’s really important for you, as the business analyst, to bring some structure to that business analysis process. Often these discussions can really start to go all over the place without a defined structure. When we’re talking about the To-Be, it’s like anything goes and conversations start to fly all over the map.

Getting ALL the Stakeholders Involved is Key to Success Process Definition

To start defining the To-Be process, you’ll want to start by involving all of the key stakeholders that are involved in the process today, or that you anticipate will be involved in the process in the future. You should have at least one stakeholder representing each functional area or role impacted by the process.

Most often it makes sense to start by analyzing the As-Is business process so that the entire team is aligned around the current state before defining the future state. I did a video recently on the As-Is business process that you can watch below.

If, today, your team is using a spreadsheet and email communication to manage a process and in the future we’re hoping to use a tool or some sort of software system, you want to get clear on how that flows first. How does the spreadsheet and email communication flow and who all is involved as a starting point so that you know exactly what to automate.

To Analyze a To Be Process, Start with Why

Next, you want to be clear on what problem you are trying to solve by updating the process.

• What is the “why” for the project?
• What’s the desired outcome?

For example, your sponsor may want to make the process more efficient, reduce errors, or take advantage of efficiencies created by new technology solutions that could automate all aspects of that process. With the right stakeholders involved, the current state understood, and your desired outcome or where you’re headed defined, it’s actually defined what this future state process is going to be.

Again, this is a collaborative effort between the business analyst and the stakeholders. As a business analyst, you never have all the answers. You can suggest ideas, you can propose solutions, but you really need to involve your stakeholders in the process of defining the process. It’s a little Meta.

If you are having trouble getting stakeholders engaged, here’s a video with a lot of tips on building stakeholder engagement.

To Discover the “To Be”, Use the “As Is” as a Starting Point

As a business analyst, you may want to bring in that As-Is business process documentation as a starting point or maybe even just the high level process map and mark it up with some suggestions and opportunities. This way everybody has something to start from. It helps keep the meeting focused on what the desired outcome is.

For a Truly Brand-New Process, Start with the Goals for the “To Be” Business Process

But if this is a completely new process, you would start by defining the beginning and the ending of the process.

What’s true when this process starts and what needs to be true when it’s done or complete?

That way you’re really clear on scope and then you can just start visually mapping out the steps in between.

Often you need to get to that fully fleshed out business process template. But you would start with a process map so you’re just looking at the high level and starting to map in those pieces in those steps. You can then rework it and move it around.

Often what happens, there’s a lot of rework and splitting apart and breaking things apart into multiple processes or combining them back together as you go through that process.

If you are looking for some tips on process maps, specifically, I also recently recorded a video on that topic, and I invite you to watch it.

Expect a Fair Amount of Collaboration When Analyzing a To Be Process, Including Technical Stakeholders

Now, one thing to note is if your To-Be process is heavily technology dependent, you may need to have a technical stakeholder available to explain how the technical system works and what opportunities there are, what the potential configurations are, and what’s really possible given the technology solutions you have.

This is not always just a business-focused activity. Often we need to have a technology expert as well. And this is why you will often see business analyst roles include some sort of technology requirements, like expertise in a specific software system, because they want you to be able to bring that expertise to the meetings as you meet with your business user.

But if you don’t have that expertise, you just need to bring it into your team by involving a technology stakeholder. Not your whole technology implementation team, but somebody who can speak to the possibilities of technology.

Your To Be Business Process Lays the Groundwork for Software or Functional Requirements

Now, you’ve completed the analysis of the future state, or the To-Be process when you, as the business analyst, have thought through all the implications of that future state, and your stakeholders have approved the updated documentation essentially saying, yes, this is how we want the process to work.

Then you are ready to define any software changes in terms of the functional requirements that are needed to support that To-Be process and start building organizational assets that will support the new process, like templates or training.

Analyzing functional requirements is an entirely separate topic, and here’s a video introducing the key concepts:

If all of this seems like too much, again, don’t worry, you don’t have to start from scratch. We have a free business process template that you can download today to help you get users from multiple departments on the same page about clarifying their desired workflow. This download can even help new business analysts figure out what questions to ask when starting on a new project or a new domain.

For more details on how to use this template to fully analyze a business process, check out this video for a complete tutorial:

In this short video, you’ll learn the definition of an As Is Business Process, as well as how and when to analyze an As Is Business Process.

The best news is that you don’t have to start from scratch. When you download our free Business Process Template, you can:

• Help business users from multiple departments clarify their actual step-by-step workflow
• Avoid wasting money on software solutions that don’t solve the right business problems
• Help new business analysts figure out what questions to ask when starting on a new project

Thousands of business analysts are already using this free template– add this tool to your toolbox today!

>> Click here to download <<

Are customers getting frustrated with your organization’s level of service? Are business users confused about what the right process is or what steps they should take in what situations? If so, as a business analyst, it’s your job to analyze the as-is business process and help everyone get on the same page. So stick with me and I’ll share exactly how to do just that.

Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos on business analysis tips and techniques.

Today I’m discussing the As-Is business process and how business analysts can analyze different organizational processes to help improve business operations and really provide more clarity to all members of the organization.

Definition of an As Is Business Process

An As-Is business process defines the current state of the business process in an organization. Typically, the goal when putting something like this together is to clarify exactly how the business process works today, flaws and all. So mistakes, errors, redundancies, whatever that is.

How to Analyze an As Is Business Process

Now, the As-Is business process contains all of the elements of a typical business process model – the description, the list of roles, a list of steps, exceptions, and a workflow diagram or a process map. To get a rundown of all of these elements, you can download our free business process template.

And here’s a video with all the details on process mapping:

Now, when you’re putting together an As-Is process, access to the business stakeholders who perform the business process is key. Business analysis never happens in a vacuum. You need access to stakeholders so you can actually understand what they are doing.

Secondarily, access to business stakeholders who understand the process, such as a manager or a subject matter expert can be helpful as well even if those individuals don’t routinely perform the business process. Often they can provide another perspective on what the business process should do, and they might be really surprised to learn what is actually happening. So often it’s important to have people who are actually doing the process involved as well as management or people who have the idea of what the outcome of that business process should be, and how they believe it should be performed.

What’s really important, though, is that you’re going to need at least one stakeholder to represent each role in the process.

If you are having trouble getting stakeholders engaged, here’s a video with a lot of tips on building stakeholder engagement.

For example, for a process describing how a new customer gets set up, you might need a representative from sales, from customer service, and from fulfillment, maybe even accounting, if that’s part of the process as well. Once you determine who needs to be involved, you can elicit information about the current state using a variety of different methods. Interviews and observation tend to be the best elicitation techniques for understanding the current state and then you’re able to put a draft together and then review that or do a document review that can confirm your understanding and fill any knowledge gaps.

We’ve done a great video on elicitation, and I invite you to check it out if that’s something you want to learn more about.

When to Analyze the As Is Business Process

One of the most frequently asked questions we receive is whether or not you always have to do the As-Is. We’re actually going to improve this process. Can’t we just start with the future state or the to be or the desired state process?

I find that it almost always makes sense to start with the As-Is because this brings a lot of clarity and it gives your team a solid foundation to build from. There are some scenarios, though, where the As-Is is particularly necessary and I would say really a non-negotiable in your analysis process.

• For example, if there are known issues with the current state process such as order is not getting processed or customers being frustrated with your organization’s level of service. Often the clarity that comes from a good business process document is going to help you identify the gaps that are causing those issues in the first place. The analysis helps you define what your future state, or to be business process, should be.
• Also, if you find that business users are confused about what the current state process is or what steps to take in current situations, it makes sense to start with the As-Is so you can get everybody on the same page about what they should be doing currently. It avoids a lot of disagreements and confusion and back and forth discussions about trying to define a future state when we’re really not already on the same page about what we should be doing right now.
• Finally, if your organization wants to automate or streamline the current processes but, again, that current state is not well understood or documented, you need to start here. By analyzing the current state, you are going to discover redundant steps and opportunities for automation.

Here’s a Starting Point for Your As Is Business Process Mapping

If all of this seems like too much, don’t worry. You don’t have to start from scratch. We have a free business process template that you can download today and that will help you get business users from multiple departments on the same page and clarify their actual step-by-step workflow.

This download can even help new business analysts figure out what questions to ask when starting a new project or working in a new domain.

Click the image below to claim your free business process template.

There’s a lot more to mapping a business process, and I have another video that goes into this technique in more depth.

The cornerstone of a user story is a single statement in the following syntax:

“As a [user], I can [do something] so that [perceived benefit].”

Discover the benefits of user stories and how they fit into the BA workflow by watching the video below.

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about user stories and how to write user stories and be really effective with this technique as an agile business analyst.

User stories are a way of capturing requirements that is commonly used on an agile software development team or a team using the agile methodology of some sort.

Benefits of User Stories

There are some really key benefits to managing requirements with user stories.

First of all, when you’re using user stories to manage your requirements, you’re often organizing all of those stories into the product backlog. That allows you to rank prioritize the requirements, which is a very agile focused technique, as opposed to like a big document where everything is “priority one.” That rank priority makes it incredibly clear which requirements are the most important and most valuable to the business. You, as the business analyst are focusing on the most important requirements and the development team is also focusing on the most important requirements.

And now the other piece that I really love about user stories is the very syntax of how they’re written, which we’re going to go through in just a minute here, links each functional requirement to the anticipated business benefit, and that makes it much more difficult to just sort of add in or sneak in requirements in a big document or even in a use case. I love use cases, and we’re going to talk about how to incorporate those into your user story development process a little bit at the end.

What I have found when I only write use cases is they can get a bit bloated with extra steps and alternate flows and all kinds of exceptions, and all of a sudden something that seemed really simple becomes really complex and that becomes very obvious when you are breaking down the requirements from a use case into user stories because then you have to prioritize each of those independently.

And then the final thing I really love about user stories is that they create this powerful link between your requirements work and your development work which helps us, again, guard against unnecessary scope creep, or projects that really become more intensive without actually creating more value. That’s a great position to be in as a business analyst, making sure you’re paying attention to value.

User Stories Defined

So what is a user story? The cornerstone of a user story is a single statement in the following syntax. As a user, I can do something so that whatever that perceived benefit is of that feature. And then you include whatever accompanying details or supplemental materials you need to make the user story clear and implementable.

Often these are detailed in acceptance criteria or the conditions the software must satisfy to be accepted by a user, a customer or a stakeholder.

An Example User Story

Let’s go ahead and look at an actual example, which I think will make this much clearer.

This is an example that we include with our use cases and wireframes module of The Business Analyst Blueprint training program®.

As you can see up here, the title for this is The Username Doesn’t Exist. This is a component of a bigger use case that would be logging into the system. That use case has multiple different features and exceptions and alternates. This is just one little piece of that. What happens if the user tries to log in and that username does not exist in the system? Up here we have a, as a user. I can be notified that the username I provided does not exist so that I can provide a different username or try to log in again.

Here we have our different acceptance criteria. They’re written in this given when/then format. So given this happens, then this happens. Given this happens, then this happens.

Now what we’ve also included here is a wireframe. And what I have found as a business analyst, it’s often really helpful to have not just the acceptance criteria detailed out in words, but to have some sort of supporting documentation. In this case, the wireframe made the most sense. Other times it might be a workflow diagram. It might be the use case that this user story is a part of. It might be a data model, if it’s data intensive. It could be a data dictionary or a glossary of terms, or an ERD, like a piece of the ERD. Those are all examples of what you could include as supporting documentation. In this case, we have a wireframe.

So that’s an important piece to keep in mind. There’s some specificity to user stories, like guidelines, and how to create them. But I think there’s also a lot of judgment as a business analyst of what actually is going to communicate these requirements in the most effective way to my software development community.

Wireframes are super common. Here’s a video explaining how to create a wireframe if you want more detail on this business analysis technique:

How User Stories Fit into the Business Analysis Workflow

I think another thing that we really need to keep our mind wrapped around is how these user stories fit into our workflow as business analyst.

One area that often gets overlooked in agile circles, even still today, is how the development of the user stories fits into a business analyst process framework.

If you aren’t familiar with what a business analysis process framework can look like, here’s a video tutorial on that:

Agile is a Software Development Process, Not a Business Analysis Process.

Agile is a software development process. It is not a business analysis process.

Most agile methodologies, whether they explicitly do this or not, there’s some sort of assumption built in that the details of what goes into a user story are fairly well known or easy to figure out, and just a matter of the business analyst sitting down with a user and really figuring that out and having one quick conversation with them.

The reality is that often as a business analyst:

• You need to be collaborating with multiple stakeholder groups to rank and prioritize and estimate those user stories.
• You might need to gather information from multiple different stakeholders groups to build out that acceptance criteria or to gain alignment on what the software actually needs to do.
• You might need to dig in and figure out what the business process is before you even start defining what those software requirements are.

There could be a lot of background kind of upfront work that even though we want to be more agile, we also want to be thinking things through.

As a business analyst, when I’m on an agile team, I’ve found it a good practice to work ahead at least by one or two sprints, and that’s if things are relatively simple.

If you’re dealing with something much more complex where there’s a big business process focus, you might need to work even further ahead than that kind of doing some of that business process work before you get into the sprint part of the development process.

What that means is that I’m always prioritizing the product backlog that will be developed in the next month or two. That gives me time to refine those requirements, to get all the necessary stakeholders on the same page about those requirements, and to detail out those acceptance criteria so when we go into sprint planning, I’m ready with the good draft of what the requirements are for this user story, and then we can have dialogue with the technical team. I can go back and clarify things if I need to or add to them or supplement them.

But I’m not doing the heavy lifting of getting all the stakeholders on the same page while the developers are trying to build that feature. I’ve done that before under the pressure of agile. What happened is we built one thing and had to change it and build it again and nobody was happy, especially me, especially the developers as well. .

When Focused on User Stories, It’s Easy to Lose Track of the Big Picture

The other thing I want to say is that when we are focused on these little user stories, especially like that example of “the username doesn’t exist,” it’s a little tiny piece of functionality. It is really easy to lose track of the big picture. And when you lose track of the big picture, it’s common to miss requirements because you’re focused on this one little piece. As a business analyst, you need other techniques to maintain a view of this big picture.

What we teach at business at Bridging the Gap is use cases because we find that use case thinking and the semantics and the logic of a use case helps business analysts uncover otherwise missed requirements. And if you are a great agile business analyst, you’re like, “Laura, I write user stories all the time. I don’t ever write use cases,” that is totally possible. I’ve done that too, but it’s because I had that use case thinking background in my head and I was thinking through the use cases, even though I wasn’t writing the use cases and I was using that use case thinking to hold together and think through how all these user stories fit together.

And so it might be that use cases or use case thinking has become so intuitive to you by now that you don’t actually have to write the use cases if you’re new and struggling with how to make sense of this big glob of user stories that you might have on your plate. You might want to actually put them together into a use case or a business process model, or a process map, or a workflow diagram to help you think through that bigger picture view before you dive into each individual story.

Download our Use Case Template

If you’d like to go further on the use cases specifically, I do have a free template for you that you can use to walk through with some guiding text. It’s absolutely free. You can just use that link below.

And again, that technique is going to help you avoid missed requirements and think through the big picture of how your user stories fit together.

Again, user stories are an incredibly important technique. We need to know them as business analysts, especially if we’re working on agile teams. Mastering use case thinking is going to make you a stronger business analyst who can weave those user stories together in a meaningful way to ensure that the team delivers a solution that’s truly valuable to the business.

Again, my use case template is available through that link below. We’d love to help you take the next step with this skill in your career.

I’m Laura Brandenburg with Bridging the Gap and we build our profession one business analyst at a time. Success starts with you. Thanks for being here.

<<Click here to download free template>>

Use Cases Are One Way to Analyze the Functional Requirements

If you are looking for more guidance on use cases, here’s a video tutorial to go through:

Use Cases and User Stories Can Work Together

You can also learn about how use cases and user stories can work together here:

One of the great things about process mapping is that they are often intuitively understood by our stakeholders. They are also extremely powerful communication tools because they allow us to get great feedback on the process early in the requirements process.

Discover the 7 Steps to Diagram a Workflow or Process Map in the video below.

Process Map Defined

I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to draw a process map in seven steps.

A process map is a visual model that shows how a collection of activities are sequenced together to accomplish work in an organization. Super simple. Other terms for a process map are process flow diagrams, workflow diagrams, swim lane diagrams, or simply a process flow, or simply a process map. Lots of different terminology often referring to the same exact technique that I’m going to show you an example of today.

Benefits of Drawing a Process Map

Now, one of the great things about process maps is they are often really intuitively understood by our stakeholders. They’re relatively easy technique to pick up as a business analyst as well, and they are super powerful communication tools.

They allow us to get feedback, really impactful feedback early in the process and before we start writing software requirements, which makes that process go so much more smoothly and easier.

They are also a really strategic technique that helps us as a business analyst discover their true problem to be solved before we dig into the details of what the software really needs to do to support the business. If you’ve been feeling like you’re kind of cut out of that early phase of the process, or not really understanding why the software or why the requirements are what they are, a great technique to pull out of your toolbox is this process map or a business process model.

7 Steps to Creating a Business Process Map

Let’s talk about the seven steps to create a process map or to draw a process map.

Step 1 – Identify the process you are mapping

Now, the first is to actually identify a process. A process captures any repeatable set of steps. It is different from a project in that a project is a set of work that needs to be completed a single time to achieve a specific result.

A process is repeatable. Look for work or activities that happen again in your organization or are a part of the repeatable work related to the software that you might be identifying requirements for. Identify what that process is.

Step 2 – Name the process map

And then you want to give it a name. This might seem like, “Laura, let’s just get to the visual modeling and start drawing it out.” That is step five. We have a little bit of pre-work to do here because I find that the pre-work really helps you get clear on what that process is and makes the visual modeling part go a lot easier. Naming your process is really important.

We teach, in our online business analysis training at Bridging the Gap, to start with a verb. So it would be, “Collect past due payments,” versus “The past due process.”

When you start with a verb, it’s much more clear and specific. I see a lot of times we see in our program participants really want to just use a broad name like, “The email management process,” or “The collections process.” But, as we’ll see in the next step, that leads to all kinds of problems and is really too vague to give you a crystal clear idea of what that process is.

Step 3 – Identify a clear start point and end point for your process

The next way to get clear on what the process is, is to identify the starting point and the ending point for the process. The most commons mistake we see in participant deliverables is that they don’t have a clear starting or ending point.

(If you’d like YOUR work to get this kind of official review, check out our flagship offering – The Business Analyst Blueprint training program.)

Visually, this leads to models that have boxes off to the side and are not integrated into the process map. So ask yourself:

• What’s the very first thing that needs to happen or the very first activity that needs to happen and what must be true before the process can start?
• And then what’s the last activity that happens? Or what signals that the process is complete?

This creates your container, your scope, what this process is.

Step 4 – Identify your purpose for the process map

And then the final piece of pre-work that you want to do is really consider what your purpose is for creating this process map.

• Are you trying to show a lot of opportunities to a high level stakeholder group?
• Are you trying to get really specific and granular with a specific team of business stakeholders?
• Is this something that will eventually be shown to your software development team as context for why they’re doing the requirements or implementing the requirements, specific requirements?

Once you understand that purpose, it’s going to help you know what level of detail to get into because you can do these process maps at various levels of detail that will give you a different view into either a really big picture process or a more specific, almost procedural level process.

Getting clear on your purpose will help drive better stakeholder engagement, which is critical to getting the details we’re going to go into next. Here’s a video with lots of tips on stakeholder engagement:

Step 5 – List or draw out a series of steps in a process map format

With that context, we are on to step five, which is to actually draw your process map. I’m going to go ahead and share an example with you because pictures speak louder than words here. What we have here is just a simple workflow diagram. This is done using swim lanes, which is a great technique to make it really clear who is doing what.

You’ll see each of these swim lanes here has a role. Contributor, communications manager, reader. That makes it really clear who’s doing what. If you’re not using swim lanes, then you need to include the clarity of who is doing what inside each of these boxes, which is your activity steps. Just using a rectangular box, really simple logic here. Simple, as often best, a lot of times is more complex, different shapes, different colors. They just confuse your model unless you are very clear and have a key for how to do them and what they mean. Here, we’re just very simple steps and no colors. It’s very clear. Each step or each box has an activity step. This would be the actual steps of your process.

Diamond is a decision diamond, so this means that there’s more than one outcome from that step. In this case, a yes answer leads to another decision diamond, a no answer leads to a specific step. That can help when there are alternative paths through your steps.

Then, finally, these little icons here are often used when there’s some sort of a creation of a document or a deliverable or an update to a database. I think the document is what they’re usually called in most tools.

And then, of course, you’ve got these arrows flowing all the way through. That is to show the flow and how the process actually flows and where it flows through.

Then the final thing I want to point out here are these activity boxes that have the little lines on them. That’s just a standard that’s used to actually represent a subprocess. That allows you to look at a high level view and to show that there’s way more detail behind this step that you’re not seeing here. You would have then a separate process flow diagram or a separate process map to show the steps in those sub processes. It just allows you to present certain information in certain ways. That’s, again, why it’s so important to know your purpose. Why are you creating this process map, and who is your audience?

Step 6 – Look for exceptions or rules to the process

You’re still not done. I’m going to go back and show that again because your next step here is to look for exceptions or rules. You might, at first, when you diagram this out, as I often recommend don’t get out a diagramming tool like this is built in, draw it out on paper. Because then you might say, well, does this step always happen the same way? And if not, that’s where you end up with these decision diagrams or decision diamonds. That, in this case, is this question answerable via a blog post? If yes, we send the blog post. If not, we do something else. We might consider it for a future blog post.

You want to look for those exceptions and those rules, and you want to ask your business stakeholders do things always happen this way? What tends to go wrong? And add that information to your model. Often it’s those exceptions and rules and alternative flows where the confusion happens. You can bring a lot of clarity, as a business analyst, by figuring out those rules and eliciting those rules from your stakeholders.

That’s step six.

Now, onto the final step. This is optional, but highly encouraged, is to create an accompanying textual business process model.

Step 7 – Why Process Maps Need Corresponding Textual Process Models

Process maps are great and they can help us get clear really quickly and kind of the overall scope of the process, but they often are not quite enough detail to fully understand a process. In our courses, we teach a corresponding textual model called the Business Process Template. We use that template and we teach that template and you can actually download that template completely for free using the link below. This helps you fully flesh out the business process to understand, to ensure that you are leveraging best practices in terminology, and that you’re actually structuring the language of each step. There’s a section in there for roles and responsibilities, so it’s really clear who was doing what.

You can upload and put your process flow or your process map into that template as part of it. It’s like the visual description of it, but the text just goes into a little bit more detail and covers some additional elements that really help bring a lot of clarity. This is really useful if you find yourself missing steps or overlooking key components of your process. Sometimes going into the textual model will help elicit that additional information and give you more questions to ask your business stakeholders to make sure that you’re really clarifying what their business process is.

Asking lots of questions is a key business analyst skill, whether you are analyzing a business process, functional requirements, or data mapping! But a lot of business analysts get stuck wondering what questions to ask. Here’s a video with a ton of guidance around figuring out what questions to ask.

So that’s it. Those are your seven steps.

And then to help you create process maps that truly improve project communication, that solve real business problems and help you move forward in your business analyst career. This is a technique that’s going to position you as a really strategic thinker and somebody who understands the business perspective, which is super, super important.

Again, feel free to download our business process template today. It’s completely complimentary.

Process maps are great because they help us get clear really quickly, but they’re often not fully detailed enough to truly understand that process. And you want to use a template like ours to get to those details.

Again, I’m Laura Brandenburg from Bridging the Gap. Thank you so much for being here. We build our profession one business analyst at a time, and success starts with you.

Download Your Free Business Process Template

When you want to get analyzing a business process, download our Business Process template (it’s free). We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

You’ll discover the key elements that go into a business process model, and be able to kick-start your analysis of the business process.

>>Click here to download the Business Process Template<<

Learn More About Analyzing a Business Process

To dig deeper than a process map, and explore the full textual business process model, check out this video:

In this video, I am going to walk you through possible solutions, why we use them, and what kinds of requirements techniques are important for you as a business analyst.

Whether you are working with SAP, Microsoft SharePoint, Salesforce.com, Archer, Service Now, or another tool, these requirements will help you leverage these powerful tools to lead a successful project.

I’ll be sharing specific techniques for business process analysis, use cases, and data modeling, as well as success stories from our participants in The Business Analyst Blueprint training program.

COTS Requirements are Critical to Project Success

Hi, I’m Laura Brandenburg from Bridging The Gap, and today we’re going to talk about how to specify requirements for COTS and SaaS projects. COTS being commercial off the shelf, and SaaS being software as a service.

The vast majority of projects these days are delivered using some elements of these prebuilt solutions and it can feel like, well, do we really need requirements? Do we really need business analysts? I see a lot of projects going through our Blueprint program as well as through my work with my husband who implements Salesforce, and I can tell you that the projects that are successful still leverage business analysis capabilities and specific business analysis skills and techniques to make sure the requirements, the COTS requirements, are actually in place. Because many of these options are highly configurable and customizable. We need to do the work of figuring out even if we’re going to use the solution as is, how it fits within our business process and how we get data into it.

In this video, I’m going to walk you through what the solutions are, why we use them, and what kinds of requirements documentation are really important to pay attention to. It’s going to be a little bit of a longer video, most likely, because I want to walk you through these examples, give you some visuals so you can see what they are, as well as share some success stories from our program participants on how they’ve actually used these techniques on their projects, doing COTS and SaaS type requirements work.

Let me go ahead and share my slides.

COTS and SaaS Defined

Now, the first slide I want to bring, just to kind of revisit these actual definitions and make sure we’re clear. COTS is commercial off the shelf or a solution that’s usually deployed internally. It’s where you license a software or install a piece of software on either a centralized server within your organization or maybe on specific computers that employees are using.

SaaS is software as the service. That’s in the cloud. You are not actually hosting it as an organization. The service provider is hosting it. You might still have quite a few customization and configuration options depending on the solution.

Just to be really clear, the kinds of requirements you do from a process and functional requirements basis are very similar regardless of what kind of solution you’re using. You don’t really have to worry too much about that from a functional perspective as a BA.

Examples of COTS and SaaS Systems

What are some examples of these types of systems? We’ve got SAP, Microsoft SharePoint. Salesforce.com is huge. Lately, we’ve seen a ton of people come through the Blueprint program, The Business Analyst Blueprint – our business analyst training program –  and work on Salesforce.com projects and go on to become experts in Salesforce business analysis. I’m going to share a couple of their stories.

And then Archer is another one. We’ve got document management tools. We’ve got ServiceNow. I’m going to share an example of that. All these types of tools are, software as a service or COTS tools, and they all need requirements if you’re going to implement them successfully at your company.

One example I want to give you from my career where this didn’t work, it actually was a project I came into after the fact as a business analyst, was a document management system. They had implemented this document management system, just kind of put it in place, and the whole goal of the project was to reduce the amount of paper used and make the process more efficient.

The users at this other location hadn’t been trained on how to use it. Their workflow hadn’t been well understood, so they were given a solution that they didn’t think worked for them. And instead of printing a document once and then kind of handing it around the office using their old workflow, they were actually printing it and uploading it multiple times at each step of the workflow. It was more labor intensive and used more paper. It was actually a negative return on investment. That’s what happens if you just put a tool in place and don’t actually understand what your business process is or how to use that tool successfully within your organization.

COTS Requirements: Business Process Analysis

Let’s just share the first technique that’s really critically important, and that’s a business process or a business process flow diagram.

You need to understand how the business works today. It might be using spreadsheets; it might be a paper process. It might be using another system that you’re migrating away. You need to understand how that process works so that you can understand how it’s going to work using your new system. There tends to be a lot of flexibility right in how those solutions work, so you really need to understand what that process is so you can figure out what you need to implement.

You also need to understand the constraints of the software so that sometimes it’s actually easier to adjust or tweak the business process versus adjust and tweak the software. It gives you a more maintainable system with more longevity. You might need to understand how the software works so that you can adjust the business process, and your to be process actually changes to work better with the software that you’re implementing. Either way, you just need to understand what that business process is. And a process flow diagram like this one is, is really important as well as a detailed process textual template.

I’ll leave a link below for our free template that you can use to articulate your business process. We also have videos on that technique as well as creating a process map like this one. There are other videos here that you can check out as well.

Now as an example of this, Manuel Ninapaitan was in QA work when he joined our Business Analyst Blueprint program. And he was specifically doing QA work using an application called Service Now. He took it upon himself, as part of understanding the business process, to really look for opportunities to be more efficient. He also updated his email signature to have the job title of Business Analyst. This is why I wanted to share this story with you. It might be intuitive of how it works for you as a business analyst. It also can work if you are not yet in a business analyst role because it will give you opportunities to understand the process, to ask questions about how the process works. Bring that business analysis mindset to whatever role you’re in, because often these solutions do get deployed without business analysis. We see a lot of Salesforce administrators, for this reason, becoming somewhat de facto business analyst because their role is to administrate the system, but in order to do that work, and in order to meet the user needs, they have to start understanding the business process so they can make the little tweaks that they’re able to make.

An admin role is a great way to progress into business analysis. A QA role is a great way to progress into business analysis, and you can do that starting by understanding and analyzing the business process. Again, if you haven’t already downloaded that template, it’ll help you get started with that technique.

> Click here to download the Business Process Template <<

Learn more about business process analysis in this video:

COTS Requirements: Use Cases

Now, another technique that’s really important is use cases, or some way of analyzing the functional software requirements. This is not required for every feature. You wouldn’t analyze the login use case for your COTS tool because most likely you are not going to be customizing that. And if you are, there’s got to be a really specific business case for that. You might want to push back on that one. But there are going to be features where there’s maybe a lot of configuration options, or you do need to customize it to work within your organization’s business model, and that’s where the functional requirements are. Here we have a sample use case as well as a wire frame are incredibly important.

Now, an example of this was Jamie Moore. She had a particularly challenging feature, and there were multiple ways it could be used or implemented using Salesforce. There were different ways that it could happen. And so she wrote a use case to decide to show how different areas of functionality could actually be leveraged in Salesforce to accomplish the end user objectives. She got this great feedback from a senior level stakeholder. I’ve never seen it done this way before. And it’s absolutely fantastic.

Wouldn’t you like to receive that kind of feedback? Often we can feel like we’re presenting tools that are new to our community and that maybe that can be a little scary. Like, oh, I don’t know. Nobody’s asking me to write a use case for this. But you can see the indecision and the uncertainty and the lack of clarity about what that feature’s actually supposed to do. There are tools in your toolbox that you can pull out to use in those scenarios. And a use case can be a great one if you’re trying to figure out how a feature could work or what you need to configure or customize and how that can work because it gets really specific about how the user interacts with the system and what the system needs to do to support that business user.

Again, if you do want to go back, I’ll just show you that use case again, and that’s probably a little bit hard to read. But we also have an absolutely free download for the use case template where you can go ahead and have this template fully at your disposal to start using right away in your work as a business analyst. And again, that’s another free download and we’ll leave a link for that below.

> Click here to download the use case template <<

You can learn more about use cases in this video:

COTS Requirements: Data Modeling

Okay, so third element of COTS requirements is data modeling. I would say data modeling is always important. Data is everywhere these days. It’s kind of a buzzword in a way, but as part of a COTS project, it might be one of the areas that you need to pay the most attention to. Maybe the second to only the business process.

What happens is often you are either migrating data from one system to another, maybe a legacy system to your COTS system, or maybe even spreadsheets to your COTS system and you need to migrate that data. That’s considered a one-time move.

And then the other example would be if that COTS system is actually integrating with another system. It could be your legacy system. It could be two COTS systems integrating together using an API. It could be any multiple number of things. But in that case, data is moving back and forth. In both of these scenarios, understanding the data dictionaries of both the source system and the target system, where the data is now and where it’s going to, as well as how those data fields map together is really important because often there’s logic. If your target system only allows 20 characters for company name and your source system allows 25 and people are often filling that in, it’s going to get truncated and you want to figure that out before you move data over and then people are saying the system is broken. You analyze these requirements with a data map.

It could be that there are fields that are broken apart in different ways or combined in different ways, or that are labeled the same thing, but actually used differently by the business. That’s where the business process layer comes in. You really want to understand what that data is and how it has an impact or how it’s going to flow.

One of our participants, Stephanie Belhomme, she is now an independent contractor as a Salesforce business analyst. She really learned to see how critical data modeling was as a tool that she could bring to her clients.

She says as a contractor, my clients are paying me to bring my best, to bring tools. It’s really important that I can do that. The Bridging the Gap program really helped her elevate her skillset.

But particular to data modeling, she realized that past projects she hadn’t really gone into that level of detail. There are always project pressures. Just like get it out there. Often, this was a great way to have a bigger impact for her clients and to make those projects go more smoothly as well.

To learn more about data mapping, check out this video:

Your Business Analysis Skills Can Make You a More Valued Contributor on COTS Projects

One other final thing I want to leave you with is about, just in general, how business analysis skills can make you a more valued contributor on COTS projects.

The example here is Tammy Schlador. Tammy was and is an expert in SAP. It’s another system. We’ve talked about multiple different systems here. She found that she was getting job offers that were very like SAP, developer or administrator focused because she was emphasizing her SAP skillset on her LinkedIn profile and her resume. And then when she would interview for a business analyst job, a new job she would find that she would do great at those SAP questions and she would fall short or felt like she was falling short at those business analyst questions about how she would actually work with users and end users, and how she would actually make sure the requirements reflected the process that was needed.

When you’re thinking about moving from one industry to another, which you may be just wanting to, think about, well, where is my career going to go? Am I always going to be in this one industry with this one domain and have a lot of expertise, both in the technology and in the business?

Probably not. Probably you’ll switch that multiple times over your career, and that’s going to give you a lot of opportunity to explore new opportunities. And in Tammy’s case, she moved from the steel foundry industry to the pharmaceutical industry and earned a 20% salary increase as a result of being able to shift industries like that. And it was because she had learned the business analysis skillset. Even though she had, I think it was like 20 years of experience doing business analysis on SAP, it was the. understanding and the grounding and the skills that we’ve just talked about that enabled her to move into a new job in a new industry. She actually had a recruiter contact her based on the updates she made to her LinkedIn profile, both to emphasize her business analysis skill set and add her training.

Just another example of how having a breadth of business analysis skills is super important and it’s really seen as valuable by your stakeholders as well, and by your hiring managers.

There we have it. A really good, detailed rundown of COTS requirements, the kinds of requirements that you need for these types of projects. Be thinking about your business process, your use cases and wire frames, your functional requirements. Definitely don’t forget those data requirements. A lot of people overlook them.

Also, this might seem like a lot to focus on, but realizing what’s in it for you is a much more longevity in your career and much more transportability of your skill set.

You’re not cut down or constrained by one area of expertise in either an area of software or an area of business domain expertise. You start to build a skill set that you can take with you anywhere, and that’s what we want for you.

Again, lots of resources that will further cover these concepts in other videos as well as the free business process template and the free use case template. Go ahead and download those if you want to get started right away.

Again, I’m Laura Brandenburg from Bridging the Gap. We build our profession one business analyst at a time, and success starts with you.

Thanks for being here.

>>Improve Your Requirements Analysis Skills<<

When you join The Business Analyst Blueprint® training program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

>> Click here for more information about The Blueprint <<

Simple enough.

Boring enough.

But valuable enough that it just simply has to be done.

All too often I’ve seen this important step in the requirements process skipped, often to the detriment of the project as a whole and especially to the detriment of getting all the stakeholders on the same page about the scope or details of a project.

Common Objections to Doing a Requirements Review

But I email the document out for review, that way everyone can do this when it works for them and I get better input. Let’s get honest here for a minute. In today’s workplace, people have competing priorities and are constantly multi-tasking.  Opening up and reviewing that document is not the most exciting or probably the most pressing the most pressing task on their list. Few stakeholders will provide their best input in this manner.  Those that will are probably conscientious enough to read the document before your meeting and come prepared.

I want an email sign-off because it’s traceable. Nothing about the requirements walk-through precludes an email sign-off.  But if your reason for using email is to get a passive sign-off and cover your you-know-what, not to actually create the alignment that the sign-off actually entails, then you are doing your technology team a disservice.

My stakeholders don’t have time. Then one of two things is wrong–either you’ve identified the wrong stakeholders or you’re working on the wrong project.  Either of these issues might not be your fault.  But if the people benefiting from and contributing to the project can’t spend 2 hours in a room finalizing what exactly that project is supposed to do, there are larger issues at play.

When you sit down to review a requirements specification in a meeting, you know that people are actually reading it. You also will find that one comment leads to another and that can help discover new requirements before it’s too late. Besides, a review meeting cultivates a certain accountability – if you ask your stakeholders to look you in the eye and confirm they are ready to take the next step with the project.

We’re agile. Then reviewing the requirements with your business stakeholders prior to sprint planning is even more important! Instead of reviewing bigger documents for the full project, you’ll often focus on reviewing lists like the list of ranked product backlog items for the next few months, or the details of the user stories for the upcoming sprint.

How to Facilitate a Requirements Review Session

1. Set the stage.  Send out an email/calendar requirements with the document and a description of how the meeting will go.  Let everyone know that their role is to provide any feedback on the requirements and ultimately sign-off on the document.  Re-iterate this message at the beginning of the meeting.
2. Be prepared.  Have a few extra hard copies.  If possible, project the document onto the wall using an LCD unit.
3. Lead the walk-through section by section. Give everyone an appropriate amount of time to read and consider the requirements in that section.  Ask for comments, clarifications, and questions.  Ensure the discussion focuses on the requirements, not how to build them or what tasks need to be done or the marketing plan.  As the review group agrees to updates, note these on your hard-copy or make them electronically where everyone can see them.
4. Ask for sign-off.  Say “I’ll make these edits and distribute an updated copy.  Provided I get all these notes incorporated, is everyone prepared to sign-off?  Are there any lingering issues or concerns?”  Look at everyone in the room for a visual cue.

Some of the More Common Requirements Review Issues

Doing the requirements walk-through too early. As BA, do your homework first or you will be wasting everyone’s time. Vet out the big issues in small teams. Meet individually with the stakeholders to make sure you understand their needs.  Recognize and elevate conflicts in requirements so these are resolved.  By the time you do the walk-though, requirements should be almost ready to sign-off and the purpose is really to make sure everyone is aligned and to trigger any last gotchas.

Reading every requirement aloud. I’ve done this and it worked, but it was inefficient and I wouldn’t suggest it. Instead, review the requirements in meaningful sections that people can read through in the meeting.

Not including the right people. Ideally, your review should include one person from every area of the business impacted by the requirements, good examples include marketing, operations, product management, customer service, and IT.  Often times you’ll need more than one person from a group because of the decision matrix within that group.

No one says a word.  Be prepared with some questions to get discussion going. (And if you need help coming up with questions, download our the Free Requirements Checklist example to get the idea. Often people don’t have something to say but don’t want to appear to be critical of your work. Even throw a few mistakes in to make sure people are paying attention. Then you can point out your own mistakes, a practice that can often trigger similar responses from others.

The business uncovers a fundamental flaw in the project.  No matter how diligent you are in ensuring your stakeholders are ready for this meeting, someone can have a middle-of-the-night insight the day before your meeting and blow it to pieces.  Take a deep breath.  Ask the group if they feel this issue has to be dealt with in order to finalize the requirements for this project.  If they say yes, you have two choices: you can refocus the meeting to deal with the new issue or disband the meeting and work out a plan to deal with it ASAP.

Download a Free Requirements Checklist

Part of preparing for a requirements review is knowing what questions to ask. Learn exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to download a free sample checklist

(By the way, if you are looking to learn more about Entity Relationship Diagrams, be sure to check out our FREE ERD Sample + Bonus Tutorial)

Essentially, a conceptual or logical ERD will visually show how the terms in your glossary relate to one another. They are especially helpful in clarifying information models for relational databases and helping business users understand database structures at a high level and without details. 

(This might surprise you as typically ERDs look almost ridiculously complicated. That’s because most ERDs are automated output from physical database designs, not carefully crafted abstractions of business concepts.) 

In this tutorial, you’ll learn what goes into an ERD and how to create one from a more business-focused perspective. 

For those who like to read instead of watch, here’s the full text of the video:

What is an ERD (Entity Relationship Diagram)?

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about ERDs, or entity relationship diagrams, and specifically how to do them from a business perspective, and why they’re really valuable for business users and business analysts. What is an ERD? An ERD is a data model that describes how entities or concepts relate to one another. So, those are two concepts with a line to create.

We’re going to show you a model, an actual example, before I close the video so that you’ll have more than my fists with a line between them. But that is essentially it. We over-complicate them because what often happens is the first ERD we ever see is a messy spider web of boxes and arrows and lines and details and stars and all kinds of things. We’re like, “This is crazy complicated. It makes no sense.”

The reality is that most of those, if not all of those, are automatically generated output showing the physical details of a database, as opposed to carefully designed abstractions of concepts that help us conceptualize, talk about, and realize how business concepts relate to one another. It’s the same exact syntax and semantics and modeling technique, the same modeling technique, but it’s done in a very different way. We’re going to talk about how to do it from a business focused way that looks at the very high level business concepts and the relationships between those.  

Really what you’re doing in an ERD is you’re showing logically how concepts relate to one another and what the key data elements are that you need to know about a concept as a business user. It’s a tool to help really communicate how information is stored and how the business thinks about relationships.

What would a business concept be, just as an example? It could be customer order. Customer order is a good one. Can a customer have multiple orders, and can an order have more than one customer? Usually not. Usually a customer can order multiple times.

That’s awesome, but usually an order has to have one, and only one, customer. That’s what we mean by relationship.

It could be could job seeker, another example we use pretty often. A job seeker and their résumé that they can use to apply to a job. Then a hiring manager looks at that application and decides to contact them. Some of that got into flow, but how does a hiring manager and a job seeker and a job posting and a résumé, how do those concepts relate to one another? Can one job seeker have more than one résumé? In some systems, yes. In some systems, no.

It’s a question. Maybe there’s a one-to-one relationship between a résumé and a job seeker. Maybe there’s a one-to-many relationship, and then when they go to apply for a job, they have to decide which résumé they’re choosing to submit for that application.

Those are the ways that we’re talking about. What are those core business concepts, and how do they relate together? This is what an ERD will show from a business perspective. 

Now from a data perspective—let’s just talk about that for a tiny little bit—this is not the way that we teach them at Bridging the Gap, and it’s not the way that most business analysts need to create them, but it’s going to show, at a very detailed level: what are all the tables in the database, what are the relationships between those tables? Again, it’s the same exact idea of what we just talked about: one-to-many, one-to-one, many-to-many. What are the relationships between those tables, and what are all the fields that are included in all of those tables?

It’s the physical—it’s actually how the database is built, the physical structure of the database, which is important. We need that, but we don’t always—there’s a lot that goes into the physical structure of a database that is implied or not relevant from a business perspective, and when we show all of those details to our business users, we get, “That’s a messy spider web I know nothing to do with,” versus if we can winnow it down and show a very intelligent, thoughtful abstraction of that information, we can get some really important business input and clarity on business concepts that will help us build the database that will actually serve them better.  

Key Elements of an ERD (Entity Relationship Diagram)

So what’s included in an ERD? We’re going to show the visual model here, and I’m going to talk you through some of the key examples. First are the entities. The entity is the thing, the concept. It’s the box on this model that you’re looking at. In business domain terms, it’s a concept. In relational database terms, it’s going to be the table. 

Then, there are the relationships. They’re the relationships that connect those boxes. This is where the real insight from this diagram comes because we see how those entities relate to one another. How does the job posting relate to the résumé? How does the job seeker relate to the résumé? Relationships are really those verbs or the numerical relationship that links those nouns together. 

Finally, we have attributes. Attributes are the details within each entity, and there can be more than one attribute. They provide detailed information about the concept. If we’re having a job seeker, we need to know their name. We need to know the date they joined, maybe. We need to know their current employment status. Some key attributes or information that we would store in this concept of job seeker. 

By the way, you have this sample here. I’ve also included the sample and the Visio swipe file of this along with twenty-one other actual visual models in our Visual Model Sample Pack.  It has twenty-two visual samples, one of which is the swipe file that you’re looking at here. There are other swipe files in Excel and PowerPoint and Visio. Then we also, along with that, have a guide for how to create each model. It’s not just a swipe file. It’s: why did I create it? How did I create it? How do you create it? When would you use it? Why is it important as a business analyst? Lots. A “how-to” practical crash course type information in these things. 

How to Create an ERD (Entity Relationship Diagram)

But I want to talk a little bit more about that here, specifically on the ERD, or the entity relationship diagram. How do you actually create this thing as a business analyst? What do you do?

Usually, I will start with the glossary that I have, if I have a glossary. If I don’t, I’ll start pulling the nouns out of my use cases, pulling the nouns out of my business process documents, or pulling the nouns out of any requirements document that I have, and pulling those together and putting them in boxes on the page.

I don’t often do it right in Visio. I, more often, will start on a blank sheet of paper and draw because it’s really messy, or I’ll do it on the whiteboard and start to piece these things together because you’re going to do it, and you’re going to redo it. Then you’re going to look at it, and you’re going to have lines crossing, and you’re going to need to move things around. If you’re trying to do it in Visio, there’s so much to figure out in Visio that it takes away from the headspace you need to figure out, “What are the concepts that I need to cover, and what are the relationships that I need to cover between those concepts?” 

So, I just start with those nouns, piecing them together, and then start looking at, “Does this one have a relationship to this one? If so, what is that numerical relationship? Is it one-to-many? Is it many-to-one?” I talk myself through that relationship, then I put the line in with the appropriate notation to cover that relationship. There are two notations. I didn’t mention this before. There’s the crow’s foot notation, and there’s the multiplicity syntax, which has a numeric value. Crow’s foot represents that visually with crow’s feet at the end or one line, where multiplicity shows it in numbers. You can use either one. We include examples of both because it’s really a personal preference. Whatever your organization uses, be consistent.  

Then, I would piece it together. I would get a draft together, and one of the more powerful experiences I had reviewing an ERD and using it, not just to be like, “Hey, look at me! I have this ERD,” but to actually say, “We have a fundamental challenge on this project of how we’re going to realize what the business wants in our physical database model.” We had this disconnect, and everybody was like, “It’s impossible to do what they want in the physical database.”

We were just going back and forth, and the use cases weren’t getting to enough detail, or they weren’t getting these relationships. We were looking at one slice here and one slice here, so I took a holistic view of all the concepts and all the relationships that we were trying to model and realize in the system.

Then, I sat down with my primary business subject expert and our primary development expert, and I gave them a printout of what I’d been working on, but I was like, “This is just an idea. It’s just a draft.” I asked the developer to withhold, step back from what the database does and step in to a space of understanding what the business wanted. I said, “I realize this might be tough. It might be infeasible. We might not ever be able to build this, but just for the purposes of this next hour or two (it was probably a two-hour meeting) please just suspend that attitude and show up to just understand what they want. Then, we’ll worry about the solution later. I promise I’m not painting you into a corner here, but let’s just get aligned on what we actually want.”  

Then we proceeded to redraw this on the whiteboard, and it was beautiful. The model I created was complete crap at the end of this, but it was a talking point that helped me prepare because I was the least knowledgeable person in the room about this domain.

So, it helped me prepare to create that model, and it helped me make sure we covered everything. By having that draft put together, it helped them see where I was going as we were drawing things on the whiteboard. Ultimately, the whiteboard represented a completely different set of concepts. Not completely different a very different view, and it was a complete view where everybody could look at that and be like, “Yes. This is what we want the system to do.”

The magic of that is that within hours, or maybe even days, or maybe even in that meeting, the developer was like, “This is how we can do this, and this is how we can model this. We just need this little tweak here and to adjust this relationship here. It’s really not a big deal.”

It went from being this huge problem on the project to being, “It’s really actually not a big deal.” That model helped us get over that intellectual hurdle in that project, and it was an ERD, and it was a business-focused ERD.

This is why we use them as business analysts. This is a tool, and it’s really useful, even to just help us think through these concepts so when we’re writing a use case, we’re thinking about the steps. Does that align with our ERD? Does the data model, the information model we’re asking for actually support what we want the system to be able to do? Are there variations in the business process? These all go together, in terms of different views to look at the requirements. 

Again, I invite you if you’re interested, download our swipe file. It’s part of our Visual Model Sample Pack. You’ll get the ERD plus twenty-one others.

Thank you for watching. Thank you for taking the initiative to create one of these ERDs yourself. They are not scary. I promise. Again, I’m Laura Brandenburg at Bridging the Gap, and we help you start your business analyst career. 

>>Learn More About Entity Relationship Diagrams

If you are looking to learn more about Entity Relationship Diagrams, be sure to check out our FREE ERD Sample + Bonus Tutorial

• If you have a business background, a use case will help you define what the software needs to do, even if you don’t have much (or any) technology/coding knowledge.
• As a technical professional, a use case will help you communicate about what the software does using less “tech speak”.

In this use case tutorial, you’ll learn exactly how to apply use cases in your analytical work. I’ll also share favorite use case template, with detailed annotations and descriptions so you know exactly what goes into each section.

>> Click here to download the use case template <<

For those who like to read instead of watch, here’s the full text of the video:

Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to write a use case. I’m super excited because these cases are my absolute favorite analytical technique. Hopefully, as I share this tutorial of how to actually put one together, you start to see why and are encouraged to start experimenting with them, as well, or maybe have a takeaway if you’ve done them before about you can make them a little bit better. 

Why Write a Use Case

First of all, why would you write a use case? What is this for? Why do you need to do it? As a businessperson, you might be concerned about how to actually communicate the technical requirements or the software requirements to a—I don’t even know what those are, first of all. How do I communicate with my software developers to make sure I get what I want out of the software system?

That’s one of the great tools or reasons to use a use case is that they are really a connection point. Both business and technical users should be able to really understand them and provide feedback on them. As business analysts, we use them as a communication tool, really, to literally bridge that gap or really connect people together, in terms of a common technique, common language about what the software will do. 

As a technical person, you might be looking for a way to communicate with your business stakeholders, build stakeholder engagement, and get rid of that “text” speak, less about how the system does it and more about what the system does. That really is going to help speed up the communication and clarify and make sure you’re building what the business actually needs and wants when you sit down and work on the code. 

What is a Use Case? 

What is a use case? How does it solve these problems for us as analysts, as technical people, as business users?

• A use case is a textual description that captures the interaction between a user and a system to achieve a specific goal.

This is really important. It’s the interaction between the user and a software system.

It’s different than a business process, which might capture all the things that that user would do to achieve a bigger picture goal or outcome in the organization. Use case is very specific and dialed in, in terms of how that user actually interacts with that software system to achieve a goal. This is a more granular goal.

Use Case Examples

Some example use cases include:

• Purchase Course
• Watch Video
• Subscribe to Free Training
• Download Template

Use cases represent specific and concrete things that a user can do with the software system, and it captures all the ways that that user and system can interact.

The details of the use case include all the exceptions and variations and what happens if you go to purchase a course, and your email address is invalid or your credit card’s not valid or something like that. All those variations of what can go wrong in variant paths in the scope of the system only. This is what allows us to get at the software requirements.

Use Case Template + Step-by-Step Tutorial

What is included in a use case? I’m going to go through the common sections that are in a very traditional use case template.

You can take notes if you want, but you can also download our template.

It’s one of the thirteen templates we include with our Business Analyst Template Toolkit.

How to Name a Use Case

You want to start with a name, and just like with a business process, you want that name to be verb-noun. So, “Purchase Course,” “Subscribe to Free Training,” not just “The Free Training Use Case.”

You want to know: what is the action that user is taking that’s going to be described in the use case?  

Writing a Brief Description for a Use Case

Next is a brief description, and one of the things I really like to include in my brief description is a sentence that really gets clear about the scope. “This use case starts when…” and “This use case ends when…” because what happens when you start to write all those steps is you find all these variations.

Then, all of a sudden, your use case is all over the place, and you’re like, “Laura, this isn’t a sequence of steps. It’s a web.” It’s usually because you’re going off track, or exploring alternates in too much detail, or really are just not staying within the scope of the steps that need to happen for the specific goal of that use case.

Get clear on your: Starts when / Ends when.

Big tip. 

Define Use Case Actors

The actors: who are the users, or the roles, or the types of actors that might use the system? It’s not job title; it’s actor.

Multiple people can fill that role with the system. It’s what the system can identify about you.

Are you a purchaser?

Are you an administrator?

Are you a reporter?

Something like that. 

Define Preconditions

Preconditions: what must be true before the use case starts?

This, again, is a very system-level. What can the system know to be true before the use case starts?

Write the Basic Flow of the Use Case

Then, you get into the Basic Flow, and I like to think of the basic flow like ping pong. The user does one thing, the system does another thing. The user does one thing, the system does another thing. “Ping pong, ping pong.” It’s not always that clear-cut. Sometimes it’s like, “Ping, ping, pong, pong, pong. Ping pong.” It doesn’t have to be just one back-and-forth like that, but thinking about it as ping pong really helps make sure that you’re getting that user-system interaction.

What we see very commonly among our business analysis course participants is that those with more of a business background are like, “Ping, ping, ping. User, user, user, user, user, user.” System does one thing. Really, the system is doing things all along, they’re just not seeing it because they’re not used to looking for what the system does to support them, and because they’re the business user, they’re thinking about all the things that are happening in the business. So, they’re not seeing.

That’s part of the way that the use case is such a powerful tool. It really dials you into, as a businessperson, what the system is doing to support you and what those requirements actually are of the system that you might not see otherwise. It becomes very important when you’re just like the, “Ping, ping, ping, ping. User, user, user, user.” 

On the flip side, a more technical person will often say, “The user does one thing in a ‘Boom, boom, boom, boom.’” It’s like, “Pong, pong, pong, pong, pong.” It’s all the technical details of what the system is doing, which is way more depth than what the business actually cares about because you just lose them with “text” speak of, “Oh, the system executes this sort of procedure, and updates this data, and sends this to this API, and updates the web form,” and all this technical detail. That’s not what goes into the use case.

Instead, explore data modeling techniques such as a data dictionary, system context diagram, and data map to be sure you have a full understanding of the data requirements.

The use case is not a technical specification. It’s not a system specification.

You want to the requirements, or what would go into a functional specification. This involves what’s the observable piece that the system, that the user can see the system doing and experience the system doing? Not how the system is doing all that. I realize there’s a lot of magic and juicy stuff that happens there; it doesn’t go in your use case. Ping pong. Sometimes, “Ping, ping, pong,” but not all one or all the other. Otherwise, you really have a different kind of document, not a use case.

Break out Alternate and Exception Flows in a Use Case

Then, alternate flows and exception flows. These are the variant paths. Sometimes—Let’s just see an example. For “Watch Video,” you might have “Pause.” You can pause the video. You can end the video (please don’t do that!). You can do different things. You can “Like” the video. You might have—Sometimes it might not fit within the scope of that use case but all the different things you can do. These are the alternate flows.

An exception flow might be: what happens if your Internet connection cuts out and the stream ends? How does that get presented to the user? Things that go wrong and keep people from, stopping reaching the end goal or the end of the use case. 

Finally, decide on Post Conditions

Post-conditions are what are true after the use case is over. If there’s any information that needs to be stored or outputs that need to be generated, those all need to have steps in your use case, and you can capture them as post-conditions, as well. Again, you don’t have to remember all of these details. Be sure to download our use case template, which will give you an annotated template, all these sections, a quick synopsis of what’s included. Again, that’s just one of the thirteen templates that we include in our Business Analyst Template Toolkit. 

Use Cases Do Not Require Technical Knowledge 

One thing I want to cover—and I’ve alluded to this as I described a use case, but we still get a lot of questions about it—is: doesn’t that use case require technical knowledge? “What do I do if I don’t know the tech? How do I communicate with developers, and how do I do things like requirements? It seems like I’ve got to know all this technology, and I have to know the business analysis.”

Really, you’ve got to think of the use case as a tool that allows you to communicate about what the technology needs to do without actually knowing how it’s built because you’re not doing all those “Pong, pong, pong, pongs.” You’re not seeing all of the different pieces of the tech that happen behind the scenes.

You’re saying, “As a user, what is my observable functionality? What do I see the system doing for me?” We should be able to be very clear about that as a business analyst. That’s part of the clarity we bring to the table.  

Use Cases Help You Ask Smart Questions

That’s why use cases are such a great tool; they help us ask really, really smart questions that uncover gaps in thinking and understanding and requirements.  

As an example, say we’re talking about “Purchase Course.” We have a step for the user choosing a course, a step for the system presenting the order form. Then, the user fills in the order form; the user submits the order form, the shopping cart checks credit card details. I’m probably missing a few things here, but you’re going to have this back-and-forth between the user and the system.

If you watched my business process video, you know that there’s a course participant registration that happens automatically. How does that actually happen? What’s the output that enables that to happen? Behind the scenes, there’s a—I don’t know the technical term—but there’s a data ping, likely specified by a data map, that’s sending that credit card information. That would be really important, the user information from one system to the other, so we can automate that setup and get people their course registration details as quickly as possible.  

Interested in learning more about a business process? Here’s the full video:

As you detail out the use case to fulfill this business process, you would see the gap. Like, “Well, wait. We see this thing happening here. We have this thing happening here. We don’t actually know what the steps are to get from point A to point B. It’s not clear to me.” We’ve had people ask that question that are new to our business. “How does that actually happen?”

They’re using their use case thinking to think it through and to find the gap.

It’s way easier when you’re actually writing the use case and getting all to the steps to where the last step is that the user receives their course registration email. You’re like, “Wait a minute. That’s not coming from the shopping cart. Where does it come from, and how does it get there?” That’s the kind of step-by-step thinking that you want to be doing in your use cases and that you want to bring to the table. It really helps you understand the technology without having to build the technology. 

I hope that is both a tutorial on how to create a use case and a lesson in why they’re so fun and important, and why I love them so much, and how they are such a powerful analytical tool for you to be using to really get clear on the requirements to bridge the gap between your business and technology stakeholders, bring everyone truly on the same page about what the software needs to do using a communication tool and an analytical tool that helps you uncover gaps and communicate with people who are both technical and non-technical. 

Download Your Use Case Template Today

Thank you for watching.

Again, download that use case template here.

This will give you a great starting point to writing your first or next use case, and save you so much time gettings tarted. It even has instructional text to guide you ever step of the way.

As always, we build our profession one business analyst at a time. Success starts with you.  

Thank you for being here. Thank you for watching. I’m Laura Brandenburg from Bridging the Gap, and we’ll help you start your business analyst career. Happy modeling! 

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

A Business Process Model is a commonly used business analysis technique that captures how a business process works and how individuals from different groups work together to achieve a business goal.

Let’s look at what a business process model is, how you’d go about creating one, and why it’s important to model your process, both visually and textually.

>> Click here to download the Business Process Template <<

For those who like to read instead of watch, here’s the full text of the video:

Hi, I’m Laura Brandenburg from Bridging the Gap, and we help business analysts start their careers.

Today, I want to share a really important technique with you on our business process modeling and how to analyze a business process because when you’re trying to figure out what problem you’re actually solving as a business analyst, it’s really important to know what the business process is. It helps you look at what the need is, what the scope is, and what problem we should even be solving with this process. You want to do this in both a visual way and a textual way, and we’re going to talk about how those work together.

Now, you might not be a business analyst yet. We help a lot of people get started.

• If you’re in a software development role, this is a great technique to use to understand the business perspective of the technical or the software that you build. How does the business actually use this software in the bigger picture? What are all the steps that they might do before they use your software, and what are the steps they might do after? It helps you see how your software fits into their day-to-day workflow.
• If you’re a subject matter expert or somebody who’s hoping for technology improvements to the work you do every day, using this sort of analysis can really help you fully articulate what you do day-to-day and how that work flows, so that when you’re talking to a developer or business analyst about the enhancements you want to a system, you can be very clear about how that process flows today. You might find opportunities to improve it, even just by analyzing, as well, which is always a win-win.

In this video, we’re going to talk about what a business process is, as well as what the key sections in a template that we teach at Bridging the Gap in terms of how to document and analyze a business process in a very clear, very complete way.

What is a Business Process Model?

Just to lay the groundwork, a business process is just a step-by-step sequence of events that is performed by a business user to achieve a specific goal. You want to know: what’s the desired outcome? What’s the goal? What’s the thing that happens at the end of this process?

Then, you back engineer. What are the things that have to happen to achieve that goal? All of those steps go into your business process.

Some of those steps could be manual. They could be in a spreadsheet. They might be on a sticky note on the user’s computer, the business person’s computer.

They might be using software. Those steps are not limited to what the software sees on a use case, which is very limited to the software. It’s very all-encompassing. What are all the things they need to do? Even if that’s getting up and walking over and talking to somebody at the desk next to them, that’s the kind of information that you want to capture in your business process.

One more important thing is that they can have variations and exceptions. We’re not always doing the same sequence of steps. One way that comes up for us at Bridging the Gap is when you register for one of our courses online, when you go through our online shopping cart, the system automatically will create a course registration for you and send you an email with that course registration information and your login details so you get access right away.

That process works beautifully for a majority of the registrations we have, which are one person paying for one course at a time. Every once in a while, we have teams invest in our business analyst training courses, or a manager who wants two or three people on their team, or a business analyst who gets the person next to them to join with them, which is awesome, and they’ll pay for multiple course seats at once. Then, the system doesn’t work so well. We actually have a manual process that’ll work around so that you send us the names and emails of those people, and then we will, within a day or two, set up access to all of those course participants.

So, an example of when you have a main process and then variations. It’s the same goal with the same outcome. Each individual course participant is getting their registration information, but there’s a variation to it when something triggers that variation. We’re going to talk a little bit more about that when we go through the sections.

You don’t have to take notes. You can if you want, but you can actually download the template we have for free, and that will walk you step-by-step through each of these sections we’re going to talk about so you can get started right away plugging your own information in about your business process. If you want to get that, that’s at bridging-the-gap.com/bptemplate, and don’t forget those hyphens in Bridging-the-Gap. There should also be a link below this video, as well, for you to grab that.

The Key Elements of a Business Process Model

Scope

The first section of our template is our statement of scope, or our purpose. This is: what is this process? You want to name your process, and you want to start your process name with a verb. It’s not “Our Course Purchasing Process” or “Our Course Participant Process.” It’s “Purchase Course Process” or “Give Access to Course Process.” It’s very specific on the outcome. You want to identify the scope of the process really clearly. You want to identify when that process starts and when it ends.

Desired Outcome

Then, you want to talk about the desired outcome of the process. It’s a little different than the purpose because there are a lot of reasons that we can execute a process. We can get really engrained in how we do it here. “That’s just how we do it.” Why are we doing this process? For Bridging the Gap, we have a course registration process because we want to help people improve their skills and because we are a company.

We’re a revenue-generating company, and those two things go hand in hand. That’s our “why” behind the course registration. If we did not have course registration online, we would have it through the phone, or we’d have it through fax way back in the day. It’s an essential business process to delivering the value we’re here to deliver, as well as receiving the revenue that allows us to be a profitable company that expands and grows and helps more people.

So, what’s the desired outcome of the process that you’re considering?

Activity Descriptions

Then, you’re going to go step by step through the process or activity descriptions. Step by step, what are the things that a business user does? Sometimes you’ll have multiple business users, so then you want to be clear about what the handoff is and who is doing what by using different actor or role names.

Exceptions

After that, you have the exceptions. As I mentioned, we have a primary path for when a course participant just purchases one, and then we have an alternate path, or an exception path, if multiple registrations come through at once. You want to be able to handle those sorts of variations and specify exactly what happens differently when you have a variation.

Business Rules

Another thing you might have is business rules. For us, a business rule is when somebody purchases more than one course registration at once, we will have them set up with access within two business days. Often, our team is amazing, and often, it happens within hours, but our business rule is two business days. You can have a business rule that a business user has to support. A lot of times we have business rules that are built into our systems that our system actually enforces for us. In a business process, you could talk about either of those kinds of rules.

Entry Criteria and Inputs

The other thing you have in a business process is your entry criteria and your inputs. Entry criteria are what must be true before the process starts. In the course of our course registration, you must have access to an online system. You must have a valid credit card. All of those things must be true.

The inputs are a little different. The inputs are what you have in place. What are you tangibly bringing to the business process? So, actually, valid credit card would be more of an input. You’d have an input of a credit card or maybe if you were buying a course and getting approval on your company, you might have an input of an approval document of some sort that allowed you to use that credit card. Something like that. It’s a tangible input. Our sales material and our marketing material for our courses could be considered an input for that process.

Exit Criteria and Outputs

On the reverse, you have the exit criteria and the outputs. What is true, or what has to be true when that process is complete? The process is complete when the course participant is set up and has access. Then, what’s the output? In our case, the main output is that email that gets sent to the course participant with their login information. That’s an output of the business process.

Process Flow Diagram

Finally, you might have a process flow, or a workflow, diagram. This is that visual model, and often you will have the visual model that accompanies your textual process.

All of this information that we’ve just been talking about can be modeled both visually and textually. It’s really important to look at it both ways, and you want to have those two types of information, essentially, side by side so you can see the visual. Often that visual is going to be a little bit higher level of information. Then, see the text, which has more detail.

Again, you don’t have to remember all of these details. We have, for free for you, the business process template. It’s below so you can start using this right away, getting started without a lot of roadblocks.

It’s one of the thirteen templates that we include in our Business Analyst Template Toolkit, and we’re just happy to give it away for free. The toolkit also has corresponding work samples and a guidebook. So, there is a lot more in that, as well, but the template we can give, for free, to you today.

Why Text + Visual Is Needed To Get a Complete View of the Business Process

I just want to talk a little bit more about this difference between the textual model and the visual model because one thing we see with our course participants is that they’ll just send us in the visual model and be like, “This is it, right? This is all I usually do.” A lot of business analysts really only do process flow diagrams or workflow diagrams, and they consider those complete business process models.

What happens, though, when you start going through the text is that—and especially start applying some specific guidelines about how to phrase those activity descriptions, what goes in the entry criteria versus the inputs. It really forces you to think through the process at a more granular level and dig deep. This is how you don’t miss steps. This is how you uncover, “The stakeholder jumped from here to here.”

When you’re winding that up on a process flow diagram, a lot of times, it’s easy to just skim over the fact that that connection actually doesn’t make sense. When you’re writing it out using the template, often you’ll say, “Oh, wait a minute. There’s a gap here that I didn’t see,” or, “I don’t know who the actor is,” or, “I don’t know this piece of information.”

The template helps. The textual view really helps you dig a little deeper as a business analyst and uncover gaps and ask really smart questions, which is what we all want to do: look smart. Even though we don’t actually know the process ourselves, it helps us ask really smart questions.

That’s why I’d encourage you, if you haven’t before, to check out how to actually document the business process textually, in addition to that visual model that goes along with the textual model.

Download Your Business Process Template Today

When you want to get started with that, go ahead and download our template totally free. We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>> Click here to download the Business Process Template <<

Again, I’m Laura Brandenburg from Bridging the Gap. Happy process modeling!

(By the way, real-world samples of each of these visual models are included in our Visual Model Sample Pack.)

While it will be unnecessary to use every model for every project (the samples are drawn from experience across 10 years of BA work in 6 difference companies), the more models you know, the more likely you’ll be able to apply the best model to keep the requirements process moving faster in the situation you find yourself in.

#1 – Activity Diagram

What They Do: Activity Diagrams break the process down in detail and are great for being sure you don’t miss any steps. They are good complements to use cases since they provide a visual picture of the text describing the basic, alternate, and exception flows.

What They Look Like: An Activity Diagram illustrates the steps a system undertakes to deliver an outcome and the procedural logic required to proceed through those steps. Activity Diagrams can be completed as a workflow diagram or in a more formalized version in UML notation.

#2 – Business Domain Model

What They Do: Business Domain Models clarify the information created and managed by an organization without diving deep into the database structures. Creating and walking through a model like this can often clear up misunderstandings and get everyone speaking the same language.

What They Look Like: In a Business Domain Model, each key concept gets a box. Important attributes for each concept are listed within each box. Lines connecting the boxes show the relationships between concepts.

#3 – Competitive Comparison Matrix

What They Do: Competitive Comparison Matrices compare the current state or a potential future state of a product or system to that of an organization’s competitors. This kind of understanding can help significantly with prioritization as it clears up what requirements are important to gain a competitive advantage or simply catch up in the marketplace.

What They Look Like: Competitive Comparison Matrices can be presented in many different forms. They often include a list of competitors on one axis and a list of features on the other. Then each box in the matrix is filled in to identify the competitor’s offering for each feature. In the real-world sample provided in the Pack, we developed a matrix/roadmap combination that fits easily on one PowerPoint slide.

#4 – Data Flow Diagram

What They Do: A Data Flow Diagram illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.

What They Look Like: Data Flow Diagrams show the data sources, data processes, and data stores. The BABOK® Guide identifies two formal notations for representing data flow diagrams: Yourdon and Gane-Sarson. It’s possible to create an informal data flow diagram as well, which typically takes the form of a workflow diagram.

#5 – Data Model

What They Do: While the Business Domain Model illustrates a high-level representation of the information managed by an organization, a Data Model goes deep into the database structure. Mapping data and creating new tables or attributes often has a direct impact on reporting and other system functionality. Even while this is a more technical model, your business stakeholders often have many relevant concerns.

What They Look Like: Most Data Models contain a matrix of attributes that helps your development team know exactly what data fields to create, along with their associated data types and allowable values. In other situations, a Data Model includes a mapping from one information source to another.

#6 – Evaluation Criteria and Recommendation Summary

What They Do: Evaluation Criteria and Recommendation Summaries are useful when evaluating off-the-shelf software, comparing potential vendors to engage, or even in preparing to interview job candidates. They will help you gain clarity on what your options are and make decisions from the information instead of untested opinions.

What They Look Like: Evaluation Criteria list specific ways that a potential solution will be evaluated to determine if it’s desirable or acceptable to stakeholders. A Recommendation Summary provides supporting detail to back up a recommendation, ideally made based on previously agreed to Evaluation Criteria. Both Evaluation Criteria and a Recommendation Summary are often organized visually for ease of scanning, review, and comparison.

#7 – Feature Brainstorming Mind Map

What They Do: You know that early stage of the project when everything is fuzzy but you absolutely need to get something down on paper? You need a way to keep ideas organized while keeping it easy to add new ideas and other relevant information. That’s a perfect scenario in which to create a Feature Brainstorming Mind Map – this visual model captures ideas from your stakeholders when it’s not yet time to invest in a detailed scope statement.

What They Look Like: A Feature Brainstorming Mind Map contains a central node for the project or product under discussion and a branch for each high-level area of exploration. Ideas, concerns, and feature requests can be captured and linked back to each branch.

#8 – Feature Matrix

What They Do: Have a complex set of features to track against? Looking for a simple requirements tracking tool to manage your BA work? A Feature Matrix can be used to analyze, rank, and assess the architectural impact of multiple features, or track other attributes that are important to your project.

What They Look Like: A Feature Matrix lists each high-level feature in a row of a spreadsheet. Then, columns are added to capture critical pieces of information, such as a feature description, priority, state, and risk. Each box is filled in with appropriate information for each feature.

#9 – Feature Prioritization and Stakeholder Matrix

What They Do: Oftentimes different stakeholders are needed for different parts of the project. They may also have competing priorities that need to be reconciled. A Feature Prioritization and Stakeholder Matrix is a specific type of Feature Matrix that addresses both concerns.

What They Look Like: For this type of Matrix, each feature is listed as a row in the spreadsheet with columns for each corresponding stakeholder and individual priority assessment. An additional column can be used to roll up priorities and with a simple calculation you’ll have useful information for establishing an organization-wide priority assessment.

#10 – Feature Roadmap

What They Do: A Feature Roadmap can be used to show how your project investments have and will yield demonstrable value to the business. They are useful for high-level summaries given to top executives and boards of directors.

What They Look Like: A Feature Roadmap contains 4 boxes – one for your past state, one for your current state, one for your target future state, and one listing the benefits of attaining the future state. Each box contains 2-3 short bullet points. Graphics can be added to emphasize key elements.

#11 – Navigation Map

What They Do: A Navigation Map helps you keep the big picture perspective on how the user interface flows. I often review a Navigation Map before starting a wireframe for a new screen. With stakeholders, a Navigation Map is a useful tool to set the stage for user interface or use case reviews.

What They Look Like: Essentially, each screen in the system is represented by a box. Lines with arrows connect the boxes together and show how the user can navigate through the screens.

#12 – Organizational Chart

What They Do: An Organizational Chart represents the organizational hierarchy in place for an organization or a part of an organization. Organizational charts can be used as part of stakeholder analysis or to model new work groups to be created as part of responding to organizational change.

What They Look Like: Organizational Charts typically contain a box for each employee. Lines are used to connect managers to direct reports and show the functional hierarchy in place within the organization. Organizational Charts can be created at multiple levels of granularity and may show departments, teams, functions, or individuals filling specific roles.

#13 – Performance Report

What They Do: A Performance Report shows the results from a project, project phase or business activity. Looking at past data can help stakeholders make faster and more informed decisions about next steps, ensuring that the organization is learning from its own activities and results.

What They Look Like: Most typically, a Performance Report is captured as a matrix. Each line represents an important element of the project, phase, or activity. Columns are used to identify appropriate metrics. Boxes are filled in with measures for each element.

#14 – Process Flow Diagram

What They Do: Process Flow Diagrams are an intuitive way for stakeholders to understand the organization’s fundamental processes, get clarity on how work gets done, and appreciate how value is delivered. They also put other requirements activities in context. For example, a business process diagram can help facilitate more effective use case reviews by providing context for how the system functionality will support the business process.

What They Look Like: Like Activity Diagrams, Process Flow Diagrams exist in multiple forms. Most BAs create simple workflow diagrams that show the end-to-end business process.  A smaller subset of BAs use BPMN (Business Process Modeling Notation) to create more formalized diagrams. (We’ve included examples of both in the Visual Model Sample Pack.)

#15 – Process Improvement Progress Report

What They Do: When we improve a business process, we expect to see results. But how do you communicate the changes and results to executives? Commonly, a list of bullet points is created to identify changes and improvements. Taking a more visual approach, a Process Improvement Progress Report visually shows improvements made to a business or technical process as the result of a project.

What They Look Like: A Process Improvement Progress Reports contains models of the past, present, and target future states of the process and uses visual cues, such as color codes, to show the changes.

#16 – Scope Model

What They Do: The fundamental question to answer in many projects is what is in vs. out of scope. A Scope Model is a visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.

What They Look Like: Scope models can take many forms and how you decide to put one together is typically driven by what project factors are driving scope. Technical integration requirements are typically represented by a System Context Diagram (more on that below).  Business needs are typically represented by a high-level business process. Feature-driven projects, such as a product for an end user, are often accompanied by a visual representation of functionality.

#17 – Stakeholder Map

What They Do: A Stakeholder Map is a visual diagram that depicts the relationship of stakeholders to the solution and to one another. Stakeholder Maps visualize the temporary structures put in place for a project to show who is responsible for what and how different artifacts get reviewed, approved, and ready for implementation.

What They Look Like: A Stakeholder Map is a lot like an Organizational Chart, except that it lays out the temporary team structure put in place to run a project instead of a permanent structure to run an organization. It can be very useful in clarifying stakeholder roles and responsibilities and identifying gaps in your business analysis plan.

#18 – SWOT Analysis

What They Do: When stakeholders are stuck figuring out how to solve an issue, whether that’s a minor issue in the project or a strategic issue facing the organization, a SWOT (Strengths, Weaknesses, Opportunities, and Threats) Analysis can clear the air and pave the way toward improved decisions.

What They Look Like: A SWOT Analysis contains 4-boxes, one for each of the four elements (Strengths, Weaknesses, Opportunities, and Threats). Within each box, bullet points are used to list appropriate information.

#19 – System Architecture Diagram

What They Do: A System Architecture Diagram identifies the system components and how they interact as part of the solution. This can help you figure out how to best organize the detailed requirements. It can also help you communicate the constraints of the solution to business stakeholders or help them see why particular requirements need to be addressed.

What They Look Like: A System Architecture Diagram contains an element for each key piece of technology. Lines are used to connect interconnecting or integrated components. Visual hierarchies can be used to link technical components to user-facing features.

#20 – System Context Diagram

What They Do: In today’s world of integrated components, it’s difficult to work on one system without impacting others. A System Context Diagram is a useful tool for confirming scope with business and technical stakeholders and ensuring you address all necessary integration requirements in your analysis.

What They Look Like: A System Context Diagram contains a central box for the primary system and additional boxes or circles for each potentially impacted system. Lines are drawn to identify integration points and specify what type of information is passed from one system to another.

#21 – Use Case Diagram

What They Do: A Use Case Diagram is useful on a project with many use cases to get the big picture of who is using the system and what functionality they can execute. The diagram can be used to establish context before an individual use case review meeting or to confirm the functional scope of a system.

What They Look Like: A Use Case Diagram is a UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them. Actors are represented by stick figures, use cases by ovals, and relationships by connecting lines.

#22 – User Interface Wireframe

 What They Do: A User Interface (UI) Wireframe is a visual rendering of how a specific screen to be implemented as part of a software solution will be laid out. They are useful in generating “yes, but” conversations and eliciting information stakeholders don’t think of until they see what an application might look like.

What They Look Like:  UI Wireframes, also often called Prototypes or Mock-Ups, can vary in fidelity, or the degree to which the presentation of the UI is intended to be realized in the final application.

• A low-fidelity UI prototype may show the general layout of the screen but not the specific UI elements.
• A medium-fidelity UI prototype will show the UI elements on the screen but may not represent the actual look.
• A high-fidelity UI prototype, often called a rendering, will represent exactly how the UI should look and feel once implemented.

Which of These 22 Visual Models Can You Use Right Now?

While you wouldn’t use all of these visual models on any given project, hopefully, you’ve noticed a few that look like they can give you immediate, practical value on the project you’re currently working on.  Bookmark or print this page for easy reference at the beginning of each new project you start, and you’ll set yourself up for a faster requirements process.

These visual models are invaluable tools for establishing context, addressing communication challenges, and creating clarity – so the next time you feel your requirements process screeching to a halt, consider what visual you might use to speed the process back up again.

Download Samples of All 22 Models

The Visual Model Sample Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.

Click here to learn more about the Visual Model Sample Pack

In this video, I demo 3 different diagrams that can easily be added to your BRD. And while a full-text transcript is available, you’ll want to check the video for an insider peek into our 3 examples from the Visual Model Sample Pack.

For those who like to read instead of watch, here’s the full text of the video:

Today, we’re here to talk about three diagrams that you can add to your business requirements document because BRDs can be long and difficult to understand.

Business Requirements Documents Can Be Text Heavy

While I personally no longer create BRDs, and our template toolkit does not include a BRD template, instead, we have a three-page statement, and then models for business process documents and use cases that are separate.

I know many of you do and you had a question about how your organization, or if your organization requires you to use a BRD template, how can you make it more user-friendly by adding some visual models to it?

Today, we’re going to demo a couple of diagrams. These are from our Visual Model Sample Pack. You can easily add to a BRD to make it more clear.

Add a System Context Diagram to a Business Requirements Document

The first one of these diagrams is called a system context diagram. This shows the central system under design and the primary ways information flows into and out of the system.

You see, here, we have a portal, and then we have the accounting system, internal system, email server, document management system. These are all showing how information goes back and forth between the central portal, which was the system under design, and then the other related systems. This is useful in the BRD because it can help you to show the big picture of the system and how it fits together with everything else in your organization.

It’s included in our three-page scope statement template that we offer at Bridging the Gap, and it’s included in a lot of different diagrams. It’s common diagram for business analysts to use because it brings a lot of clarity very quickly.

Add a Business Process Diagram to a Business Requirements Document

The second model you might look to create, and this one you might be familiar with is called a workflow diagram, or a business process flow diagram, or business process model. While you can create them at a low level of detail, this one is relatively detailed and dialed into a specific business process. You can also create them at a very high level to show the big picture of how the process related to the requirements in your BRD.

You can have a big picture high-level map in your BRD, and then, maybe, some supporting ones. If your BRD is comprehensive and includes all the requirements, you might include a workflow diagram for each key section of requirements that, essentially, is showing how those requirements fit together.

If you’re a higher level, then you could just have one that shows the big picture, and you can drill into those more detailed requirements than a business process model.

Add a Scope Model to a Business Requirements Document

The third thing that I would include is called a scope diagram, or any sort of diagram that shows, functionally, how you decompose or organize, the requirements.

The technique from A Guide to the Business Analysis Body of Knowledge^® (BABOK^® Guide)  is called functional decomposition. You might have more of a hierarchy than we have here, so, you could also show this as more of an organizational chart view where, maybe, job seekers have key functionality. You want to show the hierarchy between job seekers and applications, and resumes, and search. Things like that; employers, and reviewing applications, and what all the key functions employers do.

You could break this down in a hierarchy. Here, we were just showing the really big picture of what are the key features in the product platform. What are the key areas that we’re looking at and how do they…we weren’t even showing how they, really, together, we could, but we just chose to be abstract to get the big picture.

What’s inside the product platform, and what’s outside? There was a system context diagram field to this as well, even though it’s not modeled as system context diagram.

This, I would use to organize each area of my requirements. If I had a section on requirements for employers, and then a section on requirements for partners, this would be that visual model that shows the big picture, how is this document organized? How are the requirements in this document organized?

You want to look for a way to functionally organize your document and show how the business requirements or functional requirements fit within that and decompose the overall structure of your documentation.

Check Out the Visual Model Sample Pack for 22 Visual Models

These are swipe files. What you’re seeing here is the PDF. In our Visual Model Sample Pack, we have swipe files in the native format of each of the models. We have 22 different models covered. I’ve just been focusing on the visual here because it tends to be the most interesting. But inside that pack, you also get an overview of the model, a link to the BABOK^® Guide, and why I created the model. All of these were created in my real-world work as a business analyst.

A description of the different elements of that model, different terminology that can be used, and how this fits in with business analysis techniques and terminology, when you would use it, and the step-by-step guide on how to create a similar model, and finally, what to watch out for.

These are common mistakes people make with this model and how that trips them up in their business analysis work.

Again, you can download the Visual Model Sample Pack from our website. It is a paid product. It’s $97. You get 22 of these PDF documents along with the actual source files that you can use right away to start creating these in your own business analysis work.

To recap, if you’re looking to add to your BRD, the three models I would suggest paying attention to make it more user-friendly are:

• The system context diagram.
• The process flow diagram to show either that high level or maybe several of them to show a lower level detail for each area of your business requirements document.
• Then the scope model, or something that shows, in general, how this document is organized and how are the requirements in this document organized.

Those are going to take you a long way to making a clearer document that’s easier for your stakeholders to understand, easier for you to review with your stakeholders, and get lots of buy-in on that as well.

Again, Laura Brandenburg from Bridging the Gap. Happy modeling.

Click here to learn more about the Visual Model Sample Pack.

(By the way, to learn more about use cases, be sure to download our free use case template.)

What’s your take? Leave a comment below.

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

At Bridging the Gap, we teach use cases as a technique to analyze and document functional or software requirements. We get a lot of questions like, “What about user stories?” User stories are important if you’re on an agile software development team, you probably know what I mean, and you’ve probably created user stories before. You’re wondering what’s all the noise about use cases. Why are people still using use cases?

Use Cases Versus User Stories – Thinking Versus Communicating

Use cases have been around for, literally, decades. If you gave me one tool, stranded me on a desert island and made me choose one business analyst technique, I would choose use cases. They are the very first tool I learned, the first technique I learned, the first way I learned how to analyze and document functional requirements. I really think I’m a stronger business analyst because of the focus I had and how many use cases I wrote early in my career.

That doesn’t mean in an agile environment I don’t also write user stories, and sometimes even write lighter use cases. Let me talk more about how they work together and why I think use cases are so important.

When you work through a use case and think through a use case, you’re thinking through how the user and the system interact together. You’re also thinking through exactly where variations can occur, where exceptions can occur, what has to be true before the user can even start the requirements in the path, has to be true after.

In the process of mapping that out and using the right language, it’s important to avoid passive voice, avoiding before and after; getting the steps and the sequencing clear and using very clear language, consistent terminology in your use case. In the process of going through that, often you discover questions that you don’t think about when you’re writing a requirement here, and a requirement here, and a requirement here, or when you’re writing a huge, long list of requirements.

It’s the thinking process that’s critical, especially as a newer business analyst. Trying to figure out what should I put in my user stories? Are these complete? Does this have enough? How do they thread together? It can be overwhelming when you sit down and try to look at this big, long list of product backlog items and figure out what requirements and what acceptance tests, and what acceptance criteria should go in each of those.

That’s the value of the use case and why I think it’s so important, even as we move towards more agile software development environments, especially as new business analysts, to learn the skill.

Side Note on Use Cases:

If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:

Side Note on User Stories:

If you aren’t familiar with user stories, here’s how to start using them:

Use Cases Versus User Stories – Do I Really Need to Write Both?

It’s interesting. As a senior business analyst, a lot of times they’ll be like, “Well, Laura, you don’t actually suggest that I write my use cases and then break them all apart into user stories.” Yeah, as a senior business analyst, if you’ve written hundreds of use cases, like me, you probably don’t always need to actually write the use case. You’ve done it so many times you can think through it, almost, unconsciously.

As you’re writing your individual user stories from that thread of functionality, you’re thinking in use cases and you’ve got it all covered because it’s all in your head. That works once you’ve done this for a while and once you’re confident in your techniques and have other ways of managing that kind of information.

It’s hard as a new business analyst to sit down and drop yourself into that state. That’s why we still teach use cases skills at Bridging the Gap, why I think it’s so critically important, and why we see people have the a-ha’s of like, oh, this is how I need to specify software requirements. This is how I come up with the questions that I didn’t even know I needed to ask. This is how I can be confident that I haven’t missed or overlooked requirements. Those are important areas of confidence and skills to have as a new business analyst. That’s our focus on use case thinking.

It doesn’t mean that user stories aren’t important. I do think that in a lot of environments today, if you’re working with an agile software development team, you’re going to break that use case apart into user stories. Just recently, we’ve re-released our Use Cases and Wireframes course (which is now part of The Business Analyst Blueprint training program), and we’ve added a lesson on user stories to talk about that process.

Whether you’re an experienced business analyst who writes the use cases and the user stories, or whether you think in use cases and write the user stories. Or rather, you’re still just in a more traditional iterative environment that’s not quite yet agile. You’re just writing user stories which, hats off to you, it’s all good too, as long as you’re staying in that more iterative responsive collaborative mode and not waterfall, one step, then the next step, then the next step, and the hand-offs, and the throwing things over the wall. That’s a great way to be more collaborative and iterative with your team, and make sure everybody is on the same page about what the software requirements are.

Just wanted to share my thoughts on use cases and user stories. I would love to hear your thoughts. Below, there’s a lot of debate about this topic within the business analysis profession, as well as within the agile community. It’s an important topic. I think we need to talk about it, we need to understand it, we need to understand why we’re teaching different techniques, and how they work together.

Not just to facilitate an efficient software development process, but also to facilitate the right business analysis process that ensures that everyone understands the business problem we’re trying to solve.  And how we’re solving that with technology, and has a set of tools that the business community can understand, validate, review and approve in a meaningful way so that we’re building what the community needs and will benefit from with the software.

Again, I’m Laura Brandenburg from Bridging the Gap. Whether you write use cases or user stories, hats off to you for being a business analyst. Thank you for being here.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>Click here to download the Use Case Template<<

Use Cases and User Stories Are Only Two Ways to Analyze the Functional Requirements

Discover how use cases and user stories are just two types of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

What’s Important – Get Clear on Your Business Analysis Process

Whether you are using use cases, user stories, or some other type of requirements documentation, what’s important is to get clear on your business analysis process and ensure it’s integrated with the practices of the other members of your team.

If you don’t have a business analysis process, feel free to start with ours. Here’s a video outlining our 8-step business analysis process framework:

If you find yourself in a business analyst role on an IT project, it’s likely that at some point you’ll need to create a functional specification – and these can take many different forms depending on the methodologies in place at your organization. But what is a functional specification? Why do you create a functional specification? And, perhaps more importantly, what goes into a document like this?

Functional Specifications Take Many Forms

• Functional Requirements Document
• System Requirements Specification
• Business Requirements Document (contrary to the name, they commonly do not include only business requirements but also functional, software requirements)
• Use Cases and User Stories, which is what we teach at Bridging the Gap.

Whatever template is in place at your organization, the purpose of the functional specification is to capture what the software needs to do to support a business user. Often it is reviewed and approved by both business and technical stakeholders. The business users confirm that yes, this is what they really want the system to do. The technical users confirm that, yes, these requirements are feasible, implementable, and testable.

The Functional Spec is Where Business Meets IT

What Actually Goes Into this Spec?

I’ll share examples of a use case and user stories. But first, let’s discuss the longer documents – FRDs, SRSs, or BRDs.

• In an FRD, SRS, or BRD, functional requirements are typically represented as ‘system shall’ statements. You’ll typically have a list of ‘system shalls’, often organized in tables by feature with a priority identified. For example, “The system shall enable course participants to submit a question.” or “The system shall enable the course instructor to view all course participant questions.”
• In a Use Case, functional requirements are typically represented as a series of steps. The use case puts a collection of functional requirements into the context of user action, which typically eliminates a lot of ambiguity that makes its way into an out-of-context list of ‘system shalls’. For example, “Course participant selects to submit a question. Course participant provides their name, selects a question category, and provides a textual question. System sends an email to the course instructor containing the information provided by the course participant.”
  • You can use the link below to download my use case template – it’s absolutely free.
• In a User Story, functional requirements are typically captured in the following syntax: “As a {user}, I can {do something} so that {I receive some benefit}. When used appropriately, the user story syntax is brilliant at capturing user goals, functional requirements, and business benefits altogether in one concise statement.  For example, “As a course participant, I can submit a question so that I get my concerns about the course materials addressed” and “As a course instructor, I can view all course participant questions so I can respond in a timely manner.”

Each of these ways of capturing functional requirements has its pros and cons.

• ‘System shall’ statements are easy to track in requirements management systems but difficult to implement and test as they are often presented without context.
• Use cases provide great context which helps get the right functional requirements approved and implemented, but it’s also easy for the scope inside a use case to expand while meeting user goals (which may not align to business goals) or for individual requirements to get lost in larger use case documents.
• User stories link together business benefits, functionality, and user goals and are often at the right level of detail to facilitate easy planning, but it’s easy to lose track of the big picture if you focus on user stories alone.

The approach you choose will often be dictated by organizational standards. In the absence of standards, you get to define your own. It’s a good idea to start by asking the business and technical stakeholders what they’d like to see in a spec, as this can help you avoid a lot of issues down the line. Believe me, I know from some personal, painful experiences.

The Importance of Use Case Thinking to Create Good Functional Requirements Specifications

And no matter what specification format you use to document your functional requirements, ensuring you get the right requirements requires use case thinking, often with corresponding wireframes.

When you think in terms of the interchange of a user and system interaction, you will get to the right level of detail in your software requirements and often discover requirements that otherwise will often get missed.

This is why we teach use cases as a core foundational skill at Bridging the Gap.

And if you want to learn more about that and get started right away, again you can download my absolutely free use case template below.

We build our profession one business analyst at a time, and success starts with you.

Download Our Free Use Case Template

And if you want to learn more about that and get started right away, again you can download my absolutely free use case template.

>> Click here to download the use case template <<

• Clear requirements are less likely to be misunderstood by business stakeholders and technical implementers.
• Clear requirements require fewer review cycles to confirm and validate them.
• Clear requirements lead to insightful questions, that show your power and value as a business analyst.

But what does “clear” really mean? And, more importantly, how do I know if my requirements are clear or not?

In this video, we cover 3 ways you can ensure your requirements are clear.

For those who like to read instead of watch, here’s the full text of the video:

Hello, this is Laura Brandenburg from Bridging the Gap. Today, we’re here to talk about how to write clearer requirements. Writing clear requirements is a foundational business analyst skill and is a foundation of writing good requirements.

When you write requirements in a clear way, you are making sure that they’re going to be properly understood by your business and your technical stakeholders. Clearer requirements tend to have fewer review cycles and validation cycles because you’re focusing less time on, what does this requirement mean instead of what do we want it to mean, and what do we what the requirement to be, which is how we should be investing our time and meetings as business analysts.

This is the important one  ̶  when you write clear requirements and you take that time to make sure they’re clear, you’re going to come up with more questions…insightful questions that you can ask your business and technical stakeholders. This is going to showcase your power and your value as a business analyst.

Let’s jump right in. I’m going to share three ways that business analyst can write clear requirements, and how you can avoid mistakes and ambiguity.

Clear Requirements Tip 1 – Use Active Present Tense

The first tip, and the first thing to focus on is to write your requirements in what’s called active present tense. We have a tendency, sometimes, to use passive voice. We use passive voice when we are missing a piece of information that’s critical to the requirement.

For example:

1. Job posting details are entered.
2. Job posting details are saved.

That “is” and that “are” are indicators of passive voice. We want to avoid those like the plague in our requirements. Because it’s not clear who’s responsible for each step. I’m going to read you the alternative.

If I were putting these in a use case, I would write these two steps:

1. Job poster enters job posting details
2. The system saves the job posting details.

Now we’ve added a “who” or a “what” that clarifies who’s doing that action, which was missing before in the passive voice. We’ve replaced that “is” or “are” with an action verb that clearly describes the requirement. It’s much clearer as a result.

Clear Requirements Tip 2 – Use Terminology Consistently

The second way that we tend to be unclear about our requirements as business analysts is when we use terminology inconsistently. This can sneak into our requirements just by small variations of terms where when you have a community of people that are all familiar with the domain, they can read between the lines and they kind of know what you’re talking about.

But then, suddenly, you bring in a new developer, or you hire another person on your business team who’s sitting in on the requirements sessions, or you scale your team and some of that work is outsourced, or a new business analyst comes in and they’re trying to pick up the requirements where you left off. Those small variations are all going to create doubts. Are these really the same thing?  Is a job poster and a job posting agent the same?  Is job posting details the same as job details, or are they different?  Somebody who’s really looking at your requirements with a fine-tooth comb could either have questions or they could make assumptions that aren’t actually true.

You want to go through and make sure that you’re using terms consistently. Take the time to define them in a glossary or a business domain model, and then as you write your business processes and your use cases, or however you document your processes and functional requirements. You want to make sure you’re using those terms consistently throughout as well.

Check out this quick video for more tips on using terminology consistently.

Clear Requirements Tip 3 – Avoid Combining Requirements

The final tip I want to share with you today is to avoid combining requirements. Often, words like “and,” “or,” “before,” and “after” mean that you’ve lumped multiple requirements together. It’s easy when you have that kind of lumping together, to focus on one part of the requirement and not the other and have either the business stakeholder miss validating part of the requirement, or the technical stakeholder and tester miss implementing part of that requirement. I’m just going to read you an example and see what you think.

“Job poster enters job posting details and reviews them before saving.”

Is that a clear requirement?  There are a lot of active verbs in there. There’s not passive voice, but there are three requirements in that statement. I’m going to read it again. “Job poster enters job posting details and reviews them before saving.”

There’s a requirement for entering the job posting details. There’s a requirement for reviewing them. And there’s a requirement for saving them. Before saving, there’s this whole other requirement that kind of got tagged at the end with those two words.

If you were discussing that for implementation, some of those requirements would be likely to get missed. There’s a lack of clarity in our requirements. When we break it out in separate requirements, it’ll be much clearer.

Make Your Requirements Clearer Using These 3 Simple Checks

What I want you to do as a next step is use these three checks. I want you to go and look at your most recent requirements document, whatever kind of requirements document it was, and see if you can find any corrections to make.

As a bonus step, this is where your career starts to take it to the next level, see if you can find another business analyst in your organization or outside your organization, go to your local chapter meetings and collaborate, connect with another BA, and review each other’s documentation. What’s going to happen as you do that, is you’re going to learn a lot more. It’s harder to see our own mistakes. It’s easier to see other’s mistakes.

This is why we offer instructor reviews as part of our virtual, business analysis training courses because people will go through the courses, go through these detailed checklists we provide, and they still don’t see their own mistakes, and then an instructor can point it out. The switch flips, and they’re able to make that correction.

You can do this on your own by doing peer reviews within your company or outside your company. You’ll learn a lot when you review somebody else’s as well because you’ll see what doesn’t come across as a clear requirement, and what kinds of ways that you need to improve your documentation to make sure it’s clear as well.

I want you to go ahead and do that. Please comment below any aha’s you’ve had from this lesson, any takeaways, any action steps that you’re going to take to review your documentation and share that with others.

Again, my name is Laura Brandenburg from Bridging the Gap. We help you start your business analyst career.

>>Improve Your Requirements Writing Skills

When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

>> Click here for more information about The Blueprint <<

And missed requirements cause unnecessary rework on software development projects.

While use cases aren’t always the best business analysis technique, they are a perfect choice more often than not. And in this video I share the 3 situations in which they are absolutely the perfect tool for your work as a business analyst.

Download the Use Case Template

You can download our Use Case Template for FREE. The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:

• Validating that the use case reflects true end user needs.
• Describing system and user steps at the right level of detail.
• Ensuring your software requirements are clear and complete.

>> DOWNLOAD FREE USE CASE TEMPLATE <<

For those who like to read instead of watch, here’s the full text of the video:

This is Laura Brandenburg from Bridging the Gap. Today, I want to talk about when to write a use case. Because I love use cases. Not everyone does, but they are a useful analysis tool and I can guarantee you, if you’re writing software of functional requirements today, and you’re not at least thinking in use cases, you are missing requirements.

What are the scenarios that we need to be either writing a use case, or making sure we’re thinking strongly in use cases?

Use Cases Defined

First, let’s talk about what a use case is.

A use case is a textual document that outlines the system functionality in the context of user actions.

Think of it like ping pong. A user does this, the software system does this. A user does this, the software system does this. Back and forth, back and forth until a goal is accomplished for that user.

That goal is pretty discreet. It’s something that a software system can do. Not like “better life” or “improve your process”.

Goals like:

• Find customer
• Generate report
• Deliver document.

Something very specific, very concrete that the software can do.

That’s what you’re documenting in a use case. You’re getting specific about the software functionality and the sense of what software functionality is visible to a user, not what’s happening underneath the hood, not how the technology is designed, but what does the user experience with that software.

If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:

What are the situations when we’re documenting functional or software requirements like that where we would use a use case?

#1 – Utilizing Use Cases to Document Existing System Functionality

The first one that comes to mind is when we’re documenting functionality of an existing system. Systems tend to grow up and they get messy and complicated.

One of the jobs I was in, they had a document delivery system that had been in place for 10 or 15 years before I started there as the business analyst, and they never did full testing or requirements or analysis of what they were building, and they just kind of kept adding on pieces. Software systems have this, especially legacy ones like that, get to the point where you’re duck taping pieces together to make things work.

It seemed like every time we went to enhance that system, or add on to that system, or introduce a new capability, something over here would break, and we wouldn’t know why because it was challenging to do the analysis about how that system worked because we didn’t have a full set of documentation about how that system worked.

One of the things I took it upon myself to do is to go and start to work with a developer and the business sponsor to understand the capabilities of the system and the logic that was happening behind the scenes, not in terms of the technical, how is it built, but things were getting routed in very specific ways and flowing through the system. I did this so that we could start to see the big picture of how that system actually worked so when we were analyzing requirements to add on and enhance that system. We could better gauge the impact that we were going to make and look at the impacts of new requirements on that full system instead of just the piece we were focused on improving.

It ended up adding a lot of value and made that system, even though it was still difficult to maintain, easier to update and improve upon, and definitely easier for new business stakeholders who were getting involved in the business to understand the scope of what it did and think through the implications of the requests and the requirements.

Use cases are great tools to analyze existing functionality.

#2 – Document Functionality for New Systems in Use Cases

The next thing to think about is functionality for new systems. Say we were going to replace that system. We would need a new set of use cases that define the requirements and capabilities and the user actions that could be supported in that new system.

Sometimes, today, we are using COTS systems and SaaS systems – Commercial Off The Shelf and Software As A Service Systems – are definitely getting much more prevalent, but there are still cases where we’re building custom code existing systems from the ground up inside our organizations.

In that case, every single feature that you want to build, and that you’re building from scratch, every user goal needs to have a use case defining what those requirements are. That’s what your developers can use to build from and your testers can use to test from, and your business stakeholders can use to wrap their mind around what the system that doesn’t exist yet is going to do from them, and how does it fit into their business process. That’s a big part of it. It needs to go together.

Use case is much more defined and discreet than the business process itself. That’s the second time is when you’re creating a new system from scratch. Definitely want to be analyzing that and thinking through that in use cases.

#3 – Specify Updates to Existing Systems in Use Cases

The final case is what if you’re updating an existing system? A lot of us have existing systems today and we’re making those little tweaks like I talked about in the first scenario. Let’s just update that and add this here, and add this here. It’s a great opportunity to also create a use case, especially if you don’t, if you can combine where you’re analyzing what exists today and what’s the incremental change that we’re making to what exists today.

This helps you think through that impact of all the places that requirement might affect until you put into a use case or thinking, oh, we’re just adding this little field to this page. And then you put a use case around the goal associated with that, and any related goals, and you start to see, oh, added that field affects this thing over here, and it affects this report over here. It helps you start to think through some of those implications.

When you’re updating that functionality, one tip of what I like to do, I like to color code my use case so that the current state functionality is represented just in general black/white documentation and then color code enhancements or the changes so that it’s clear what we’re changing, what we’re retiring, what we’re adding on to, and that can make it easy to break that apart into specific design tasks for user stories, if you’re using user stories to implement your requirements, or to manage your software development process.

Yes, agile software development teams can most certainly benefit from use cases! Here is what Dave Gallant had to say about applying use cases and user stories on an agile team.

Bonus – Design Customizations and Configurations of COTS/SAAS Systems in Use Cases

Related to this enhancing new functionality, a lot of us, today, aren’t actually enhancing the functionality in our company systems; we’re enhancing the functionality of systems that we’ve licensed or bought from third party vendors. That would be the COTS or the SAS system like I talked about before.

You can still use use cases, then, to talk about what those customizations would be, or even like an area that’s going to be heavily configured, you can think of that as an addition to existing functionality. Maybe out of the box the system does one thing and you can configure all of these different ways. It’s mind-bending, I think, to try to jump into what are all the configurations we want out of the box solution.

It’s difficult for a business stakeholder to think what all the configurations are I want. I don’t know. I know when I sit down, and I use the screen I want it to look like this. I know when I go from here, to here, to here, to here, these are the things I need to accomplish. Putting that functionality together in a use case, as opposed to a list of configuration options, can be useful as a way to walk through what that system will be like once those configurations are made, or once any enhancements and customizations are made as well.

Jami Moore did this for an area of functionality on a Salesforce project, and look at the feedback she received:

Use Cases – a Beautiful Way to Get to the Functional Requirements

There are just three scenarios to be thinking about applying use cases in your projects. Again, they’re focused on the functional or the software requirements. The software that’s delivering value to your business users. Use case is a great tool that business users with a little bit of training and walk through can understand and dig their teeth into to understand what the software is going to do from them, and then your technical stakeholders can use to design and build the system, and your testers can use to generate all kinds of test cases. The test cases almost just like fall out of the use cases. It’s kind of a beautiful process.

Be thinking about where you could be using use cases in your environment. What are the tricky project challenges? That functional requirements list just isn’t working for you anymore. I hope this helps you think about where you might introduce my favorite requirements tool, the use case, into your business analysis process.

Again, I’m Laura Brandenburg, from Bridging the Gap. We help business analysts start their careers. Thanks for watching. Thanks for learning more about use cases.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

Click here to download the Use Case Template<< 

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

And that might leave you wondering what exactly you should do when your organization is running a cloud implementation project? While specifying requirements at a detailed functional level tends to become less important, as most tools are not infinitely customizable, and therefore you run the risk of excluding potential vendors or creating nearly impossible implementation plans.

3 Types of Requirements are Essential on Cloud Implementation Projects

Yet, there are still some very important areas of requirements to consider. In this video, I walk you through the 3 categories of requirements that will make for a more successful cloud implementation.

For those who like to read instead of watch, here’s the full text of the video:

Today I want to talk about an important shift in the software industry that’s impacted the business analysis role, and that’s the introduction and the acceptance of more cloud based solutions or software as a service, otherwise known as SaaS solutions.

Lisa asked a question, “Knowing that the industry and many companies now are opting to license these sorts of solutions rather than build custom software in-house, how does this affect the level of detail that I need to go through as a business analyst? It seems like I should be able to be a little bit less detailed about my requirements.” Lisa is correct. Let’s talk about what the requirements process looks like on these kinds of projects.

The Requirements Process on Cloud Implementation Projects

Lisa is totally right. It’s not necessary to get as detailed about the functional requirements of the software system because you’re licensing something that’s already been built. You don’t have to specify, in exact detail, of what that thing needs to be. It’s already built. That’s part of what you’re buying as an organization. To invest a lot of time in specifying those details wouldn’t make a lot of sense.

However, there are still some important requirements deliverables and pieces to put together. They allow us to add even more value as a business analyst.

We’re going to talk about three models – business process models, configuration, and customization requirements, and then, finally, data models.

Cloud Implementation: Business Process Models

First, let’s talk about business process models. When you are implementing that new system, it’s probably replacing something that exists today or giving your organization functionality that it doesn’t have today. That’s going to impact your business processes.

When we implemented a new shopping cart, we got some integration with our email management system which allowed us to eliminate a bunch of manual processes that were in place before (or our As Is Business Processes). There were a few things that we had to do a little bit differently because of the way the orders were coming in. We had to go and update those business processes, or create To Be Business Processes.

Cloud Implementations Provide Great Opportunities to Introduce Efficiencies

We had to eliminate some business processes, which is also a great thing from an efficiency standpoint. But if you never go back and do the work to figure out what you can eliminate, business users will continue doing what they’ve always done and you won’t achieve that ROI on the project. Looking at how that business process is impacted by the new software is important. There are new features that you’re buying from that software that are going to add value to your organization – making sure your business processes are in place, and actually use those features and receive that value in your organization.

A great way to start analyzing a business process is by creating a process map – here’s a video tutorial on creating a process map.

Cloud Implementation: Configuration and Customization Requirements

Most of the larger more competitive tools available today offer some level of customization. It’s not like just one thing and you have to use it as is. You can add some custom feels or customize some workflows, choose how you link things together or display things on the user interface.

It’s important to walk through and understand the capabilities of that tool. Usually, side by side with your business processes, look at the tool and discuss those configuration options to make sure that you’re configuring the tool to receive the most possible benefit from that tool for your organization.

The Difference Between Configuration and Customization Requirements

• Configuration is what that tool enables out of the box.
• Customization is what you would add, new functionality that would be specific to your organization.

Usually, you’re going to pay for customization. Not all tools enable you to do that kind of customization. In that case, it’s just the same process as when you build new software. In your organization, you’re going to need those more detailed functional and visual requirements to make sure you’re clearly communicating what you want that new system to do.

You can model configurations and customizations in use cases. Here’s a video tutorial on analyzing software requirements using a use case:

Cloud Implementation: Data Migration Requirements

Finally, let’s talk about data modeling requirements. These are extremely important when you are going into the cloud for a set of functionalities.

There are two sets of data requirements to be aware of. The first is the data migration requirements. Is there any data that your organization manages today that might be in a software system, might be in a spreadsheet or somebody’s Access database? Who knows where that data is. That’s part of the analysis process, to figure out what data do we want to pull into that new system, and how does that map over?

Often, that starts at a very high level, like, we want our customer data to map over, we want our order data to map over. Then you get very granular. We need the customer name, the customer ID, the customer address. Here are the specific fields that it’s going to map to. You want to look at those data migration requirements, or data maps.

Cloud Implementation: Data Integration Requirements

The second piece is once that system is in place and running in your organization, are there any other systems that it needs to talk to? That is called data integration or system integration requirements. You want to look at the system you’re using today.

• Does that talk to any systems?
• If so, how do you replicate that using the new system?
• Is there just an efficiency to be had by implementing an integration?

When we built our new shopping cart, we got that integration with our email management system. That enabled us to eliminate a lot of manual business processes, but we also had to make sure we configured things to get that right. That was a big feature that we were choosing the shopping cart for, the ability to do that. We really paid attention to make sure that integration point was implemented correctly.

You want to look at those things as well. Sometimes you’ll have to replace integrations that already exist today. Sometimes they’ll just have to be updated to make sure they’re working with the new system.

Data mapping is a next-level skill for a lot of business analysts, and it’s absolutely essential for cloud implementations. Here’s a data mapping tutorial:

Cloud Implementation – Don’t Overlook Important Selection Criteria Early On

What we didn’t talk about in this video are the selection criteria that you might use to choose one of these systems in the first place. In many cases, it’s not like there’s just one solution. There are dozens of solutions out there and you want to make sure you’re choosing one that meets your business needs, your security requirements, is going to work within your work flow, have the key functionality you’re looking for, and integrate with your systems. It’s a whole other topic about choosing the right vendor or choosing the right tool.

What we talked about today is once you’ve chosen a solution, what are the requirements analysis deliverables that you need to work through to make sure that you can implement that solution and deliver real value to your business.

Just to recap, those are business process models, configuration and customization requirements, and data models.

Cloud Implementations – Frequently Asked Questions

What types of requirements should I analyze for cloud implementations?

You’ll want to pay special attention to business process models, configuration and customization requirements, and data mapping requirements when specifying requirements for a cloud implementation.

What kinds of requirements do I not need to analyze for cloud implementations?

When you are implementing a cloud solution, you don’t need to specify the detailed functional requirements for the software that already exists. Focus only on the configuration and customization requirements.

What’s the most common requirements mistake in cloud implementations?

Overlooking the business process and failing to analyze how business users will use the new system. Comprehensive business process analysis is necessary to ensure a seamless transition.

A second common mistake is failing to do a detailed analysis of what data will be migrated into the new system, and ensuring that data fields are mapped appropriately to support the business.

How can I learn more about data modeling?

We have a free data modeling tutorial walking you through the most common data modeling techniques, and how to apply them on a real-world project.

Here is a list of 65 business analysis techniques that are useful to know about. Not that you would use every technique on every project (though some of these are definitely my tried-and-true, go-to, techniques), but so you have a toolbox of ideas to refer back to when your business analysis process isn’t flowing like it should, so you can get your project unstuck and moving forward again.

**If you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.**

And please feel free to add a business analysis technique in a comment below. Just be sure to include a description so we know what it is and/or link to an article that shares more detail about it.

1. Active Listening – A communication technique that involves paraphrasing back what you heard during a conversation to confirm understanding.
2. Agenda – A document containing the pertinent details for a meeting, including an objective and list of topics to be discussed.
3. As Is Process Analysis – Defines the current state of a business process in an organization.
4. Brainstorming – A spontaneous group discussion designed to generate ideas without initial critique or evaluation.
5. Business Analysis Plan – Document that summarizes the business analysis approach, list of deliverables, and schedule for completing the business analysis deliverables.
6. Business Domain Model – A visual model that logically represents the business concepts to be fulfilled by the system and how they relate to one another.  It should not be confused with a data diagram, which represents the actual database design or architecture.  Although they may look similar, a business domain model should use terms that are in the business domain.
7. Business Process Model – A step-by-step description of what one or more business users does to accomplish a specific goal. Those steps can be manual, paper-based, or software-based.
8. Business Process Modeling Notation (BPMN) – A standardized notation for creating visual models of business or organizational processes.
9. Business Rules – A statement that defines or constrains some aspect of business.
10. Change Request – A document or collection of information summarizing a change to be made. Often associated with a formal approval process.
11. Competitive Comparison – Document or matrix comparing the current or potential future state of a product or system to that of an organization’s competitors.
12. Conference Call – A meeting conducted via a conference bridge, with multiple participants joining from different physical locations via a phone line.
13. Data Dictionary – Also called a Data Definition Matrix, provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values.
14. Data Feed Specification – A document containing the business and technical details involved in exchanging data between organizations. Can be used as part of managing API integrations or other types of ongoing data feeds.
15. Data Flow Diagram – Illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.
16. Data Mapping – A specific type of data dictionary that shows how data from one information system maps to data from another information system. Creating a data mapping specification helps you and your project team avoid numerous potential issues, the kind that tends to surface late in development or during user acceptance testing and throw off project schedules, not to mention irritating your stakeholders.
17. Deliverables List – A list of deliverables to be created as part of the business analysis effort for a project or initiative.
18. Document Analysis – The process of analyzing documentation to discover information related requirements.
19. Entity Relationship Diagram (ERD) –  A data model describing how entities (or concepts or things) relate to one another. When created by business analysts, ERDs can be used to understand the business domain, clarify business terminology, and connect business concepts to database structures (see Business Domain Model above).
20. Feature Map – A visual representation of multiple features, often user stories on a product backlog, that shows their relationships.
21. Given When Then Statements – A formula for writing acceptance tests for a user story. Given (some context). When (some action is carried out). Then (description of observable consequences, or requirements).
22. Glossary – A deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization.
23. Grooming the Product Backlog – A process for reviewing new product backlog items for clarity, estimation, and priority, prior to or during sprint planning.
24. Interface Analysis – The process of analyzing an interface, such as a user interface to connect between two software systems, to discover information related to the requirements.
25. Interview – A session with one to multiple stakeholders to ask and answer questions related to any aspect of the problem, project, or requirements.
26. Issues List – A document or repository that contains a list of all issues relating in any way to the requirements for a project.
27. Meeting Notes – A document capturing the essence of topics discussed during a meeting, along with any resulting decisions and action items.
28. Mind Map – Suggested by Bola Adesope, a visual model with a topic in the center that shows a hierarchical relationship between different concepts and ideas. This is a great tool for brainstorming.
29. Observation – The process of observing people using a system or executing a process, often in their actual work environment, to discover information related to the requirements.
30. Organizational Chart – A visual model representing the organizational hierarchy in place for an organization or a part of an organization.
31. Performance Measurement – Process of collecting, analyzing and/or reporting information regarding the performance of an individual, group, organization, system or component.
32. Performance Report – Document or model showing the results from a project, project phase, or business activity.
33. Portfolio Management – Process for organizing, prioritizing, and showing relationships between multiple active and proposed projects for an organization.
34. Problem Definition – The process of discovering and defining the actual problem to be solved by a project or solution.
35. Process Improvement Progress Report – Visual model showing the improvements made to a business or technical process as the result of a project or initiative.
36. Process Walk-Through – A working session in which subject matter experts walk through a future state process to validate it.
37. Product Backlog – List of all requirements under consideration (written using a user story syntax), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization for an agile software development team.
38. Project List – A single list of prioritized projects under consideration by a team or organization.
39. Prototype – A functional visual model that shows the user interface of a not-yet-built software system. Often prototypes allow for some limited interaction based on sample data.
40. Requirements Questionnaire – A list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective).
41. Requirements Review –  A meeting gathering stakeholders together to walk through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project.
42. Retrospective – The process of reviewing a work completed (often for a project or segment of a project) to discover and bring forward lessons learned.
43. Root Cause Analysis – The process of analyzing a problem to discover the underlying causes, or true issues, creating the problem.
44. Scope Model –  A visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.
45. Stakeholder Analysis – A document defining who is part of the project team and what they are responsible for.
46. Stakeholder Map –  A visual diagram that depicts the relationship of stakeholders to the solution and to one another.
47. Stakeholder Request List – List of requests related to a project or solution prior to defining scope.
48. Survey – A series of questions posed to multiple stakeholders in an asynchronous format, such as an online questionnaire. Useful for gathering lots of information from multiple people.
49. SWOT Analysis – A visual model showing information about the Strengths, Weaknesses, Opportunities, and Threats an organization faces.
50. System Architecture Diagram – Visual model that identifies the system components and how they interact as part of the solution and can help you figure out how to best organize the detailed requirements.
51. System Context Diagram – A visual model defining the primary system to be addressed during a project or initiative and the relationships between the primary system and other systems.
52. To Be Process Analysis – Defines the future state of a business process in an organization to clarify how the business process will work, at some point in the future, once changes are made.
53. Traceability Matrix – Suggested by Nikkita Nguyen, this document is used to map business requirements to functional requirements.
54. Triple Constraint – A model showing the balance between project budget, schedule, scope, and quality.
55. Use Case – Use cases are a type of textual requirements specification that captures how a user will interact with a solution to achieve a specific goal. They describe the step by step process a user goes through to complete that goal using a software system.
56. Use Case Diagram – A UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them.
57. User Acceptance Testing – A validation process in which business users use a new solution, often before it’s deployed, to confirm it will meet their needs.
58. User Interface Specification –  A document defining the rules of engagement for a user interacting with a specific page on a website or screen within an application.
59. User Story – A short document capturing a description of a software feature from an end-user perspective. User stories are often written in the following syntax: As a ____ {user}, I want ____ so that ______. User stories are often coupled with acceptance criteria (see Given When Then Statements).
60. Video Conferencing – An expansion on a web conference, where participants are also able to share video of themselves.
61. Vision Document – A document describing the business objectives and scope of a project.
62. Web Conference – A meeting held via a webinar, online meeting, or combination of screen-sharing software and conference bridge, with multiple participants joining from different physical locations via an internet connection being able to all see one visual screen and talk to one another.
63. Wireframe (Also called a Mock-Up, Related to a Prototype) –  A visual representation of a user interface screen, typically one that is fairly low-fidelity.
64. Workflow Diagram (Also called Activity Diagram) – A simple visual model that captures the steps, decisions, start point, and end point of a functional, technical, or business process.
65. Workshop – A meeting in which real-time collaboration on one or more work products, such as requirements deliverables, occurs inside the working session.

What business analysis techniques do you use most often? Do you have a favorite technique that’s not included on the list? Please share it via comment below and be sure to include a short description to define what it is and when to use it.

And, if you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.

Use cases are a valuable requirements tool for capturing functional requirements in the context of user actions. Along with their super-powerful side-kick, wireframes, they can be a tool to finally get everyone on the same page about software requirements.

But some very common use case mistakes make use cases difficult to understand, and can actually create more ambiguity about the requirements.

You can avoid a lot of pain and suffering for everyone on your team by being sure you don’t make some of the most common use case mistakes that lead to ambiguity.

(These are real mistakes that I see again and again in the first drafts of our business analysis course participants, but not in their second! And if you are ready to get started writing a use case, be sure to download our free use case template today.)

Download the Use Case Template

You can download our Use Case Template for FREE. The best part is that when you learn to analyze requirements in use cases, you can look like the smartest person in the room by avoiding these common challenges:

• Validating that the use case reflects true end user needs.
• Describing system and user steps at the right level of detail.
• Ensuring your software requirements are clear and complete.

>> DOWNLOAD FREE USE CASE TEMPLATE <<

Use Case Writing Mistake #1 – Include User Interface Details

By far the most common mistake we see in use cases is that they use the language of the user interface to talk about the user behavior. For example, instead of  “Actor X creates a new account” they read as “Actor X clicks the new account button (or tab, or whatever).”

Using user interface details leads to ambiguity.  This is counter-intuitive because “clicks the new account button” seems much more specific than “creates an account.”  However, sometimes the name of the user interface element doesn’t clearly identify the action the user is taking and so it creates ambiguity about the actual step that we need from the user for the system to be successful. (Moreover, if you happen to change the name of the button or the tab, you could have a lot of use case updates to make. Talk about a maintenance nightmare!)

But, we’ve gone on for awhile about this mistake. Let’s get to the others, because there are plenty!

Use Case Writing Mistake #2 – Not Specify a System Response to a User Action

The next most common mistake we see, especially from individuals without a lot of exposure to information technology projects, is that the use cases are very business process-oriented. The use case is crystal clear about all the steps the user needs to take, but it is missing the corresponding system action that needs to happen in response to each user step.

In a use case, just about every user step should have a corresponding user response or action. If it doesn’t, your development team isn’t clear on what the system is supposed to do to hold up its part of the bargain. This leads to assumptions being made or questions being asked during implementation.

This one is such a big deal, I recorded an entire video about it:

Use Case Writing Mistake #3 – Include Technical Details

Another common mistake, and this one tends to come from more technically-focused professionals, is that the use case includes technical details that are not required to understand how the user interacts with the system.

Common examples of technical details include:

• Specific data elements or data tables.
• Names of system components that wouldn’t be visible to an ordinary end user of the system.
• System-triggered processes or procedures that need to run.

Including too many technical details can clarify things for the technical team, but breaks the flow of the use case and makes it difficult for your business stakeholders to understand and your testers to test. These details are best saved for a technical design document.

When it comes to data elements, a best practice is to use a data dictionary or data map to analyze the data requirements.

Here’s a video explaining how to create a data map:

Use Case Writing Mistake #4 – Inconsistent with Wireframes

While use cases can stand alone as a requirements document, often they are created along with wireframes that show either the flow or one possible flow through a set of screens to realize the use case.

It’s very common for the use cases and the wireframes to get out of sync. For example, there could be a sequence of steps that’s not represented in the wireframe or the wireframe could lack the buttons and triggers necessary to fully realize the functionality in the use case.

Inconsistency in final deliverables creates confusion because it’s not clear which deliverable should be the true source of requirements. (And when there is lack of clarity, developers tend to choose visuals because they are easier to consume.)

Here’s a video explaining how to create a wireframe:

Use Case Writing Mistake #5 – Unclear Where Alternates and Exceptions Branch Off the Main Flow

One of the useful elements of use cases is that they enable you to focus on the basic flow or “happy path” independent of all the variations that can occur along that path. These variations are called alternate and exception flows.

Here’s an example for “Remember me” functionality in a Login use case:

2a – Remember Me

• The system detects that the user’s computer has a saved username and password.
• The system bypasses steps 3 and 4.
• Continue with Basic Flow, Step 5.

When detailing an alternate or exception flow, it’s preferable to identify a specific step in the basic flow where the alternate or exception begins or is triggered. Similarly, when the description of the flow is complete, you should indicate the step in the basic flow where the flow picks back up.

This habit makes less likely that you’ll miss steps in your basic flow. (Often when I notice these mistakes, there is no appropriate step in the basic flow to branch off from, which often means a system check is missing.) It also clarifies for your reader exactly when and how the alternates and exceptions get triggered.

Use Case Writing Mistake #6 – Include Out of Scope Steps

A use case should be fairly discrete. It should describe the sequence of steps (and all necessary variations) for accomplishing one specific user goal, such as creating an account or sending an email or generating a report.

A common mistake is to include steps that happen before the pre-conditions, after the post-conditions, or are otherwise unrelated to the user’s goal in the use case. This mistake is an indicator that the use case needs to be split into more than one use case.

This mistake leads to missing requirements because the more you try to cover in a single use case, the more likely you are to overlook steps and alternate paths through it.

Here’s

Use Case Writing Mistake #7 – Inconsistent Terminology

A final mistake that can cause significant confusion is when BAs use terms inconsistently. For example, it’s common for a use case to describe a flow of steps to process a specific type of information.

Let’s just say in this scenario, we’re talking about creating a new article to publish on this website. If step 1 refers to an article as a “blog post,” step 3 as an “article,” and in step 5 there’s a reference to a “published content item,” it’s unclear as to whether these are all the same concepts or different concepts.

Not knowing the business jargon, your technical stakeholders will most likely assume that there are three different concepts that need to be implemented with different data elements and then have questions about how one ties to another.

And while it might seem like a lot of work, investing in creating a glossary to clarify terms and their definitions can save a lot of time and confusion in the long-run.

If you want to go deeper into how to check for inconsistent terminology and train yourself to find it, check out this video I recorded on the topic:

How to Avoid These Mistakes When Writing Use Cases

If you are making any of these use case writing mistakes, you could be losing the opportunity to create clear and concise functional requirements specifications that are easy for your stakeholders to understand, provide feedback on, and implement.

Review your latest use case for each of the mistakes mentioned and work to correct it. Better yet, trade use cases with a peer and review each other’s work for evidence of these 7 mistakes. Often an outside observer can see what we don’t.

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

>Click here to download the Use Case Template<<

Learn How to Write a Use Case

Want to back-up and learn step-by-step what goes into a use case? Watch my full use case tutorial below:

Use Cases Are One Way to Analyze the Functional Requirements

Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.

Use Cases vs. User Stories

Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.

When the data isn’t in the right places, it does appear to a business user like the entire system is broken. Defining data migration requirements is a key aspect of successful business analysis.

In this article, we’ll look at the business analyst role on a data migration project and how to plan the data migration so that potential data mapping issues are discovered before they derail the project.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

Data Migration: The Business Analyst’s Role

System migration projects involve migrating functionality supported by one system to a new system. In today’s technology climate, often organizations are migrating legacy technology systems, such as those that are proprietary and custom to a single business, to commercial off-the-shelf systems that are supported by third-party vendors. For example, an organization could replace their homegrown lead and customer management system with Salesforce.com or SAP.

Another scenario is when an organization is moving from one third-party system to another. For example, at Bridging the Gap, we’ve changed email marketing software, shopping cart software, and online course deliver software. All of these required some sort of data migration work.

A business analyst can take on many different roles in a data migration.

• At a minimum, the business analyst should be involved in clarifying the business requirements for the data migration, and helping answer such questions as what types of data will be migrated from one system to another. (For example, when we moved shopping cart systems, we migrated our products but not the order history.)
• The BA’s role can greatly expand to include analyzing all aspects of moving data from one system to another, without actually doing the technical work of migrating the data itself.

Data Migration Projects Bring Up Lots of Questions

While the actual loading of the data is a technical process, there are important business decisions to be made, such as:

• Do we bring over all data or recent data?
• For any two fields, do they actually mean the same thing? Or, is there logic in either system that will impact how we want the data brought over, based on our understanding of the business process and functional system flow.
• Do all fields have a home in the target database? And vice versa?
• And so on and so on.

Without a business analyst proactively planning the migration, it’s not uncommon to have a client-side database developer provide a recent dump of data and have the vendor-side database developer sort through how to import it into the new tool. This approach can lead to data issues surfacing late in development, potentially throwing the project off course.

Let’s take a look at the data modeling techniques a business analyst can use to clarify these types of requirements.

Data Migration Technique #1: Model Data Flow with a System Context Diagram

In the early stages of the project, while you are still clarifying scope, start by clarifying the high-level data flow. What systems are impacted? How is data flowing or migrating from one system to another?

A System Context Diagram can be useful here to show how the current systems support the business process, or how data flows through those systems. Here’s a video with more details on a System Context Diagram.

Data Migration Technique #2: Get Clear on Business Concepts with a Glossary and Entity Relationship Diagram

Another early analysis step is to understand the the business perspective on the information model.

• A Glossary is a useful technique to identify and clarify business terms and concepts.
• An Entity Relationship Diagram will show the critical relationships between business concepts.

When you move data from one system to another, it’s incredibly common for there to be shifts in the information model, or how the business manages information.

For example, if your current system has a way to associate one customer with multiple sub-accounts and the future system does not, this issue likely impacts a wide range of business processes and even how your stakeholders will think about the requirements for the new system.

I consider ERD’s a critical BA skill set in our current data-oriented world, even if you don’t want to code and don’t know SQL. Here’s an ERD tutorial so you can learn more about this foundational skill set.

(Yes, it is totally possible for a BA to create an ERD, even if you don’t know SQL and don’t consider yourself technical. In fact, this is a great technique to help facilitate better communication with technical stakeholders.)

When I create an ERD, I like to start with the business’s perspective and model how information is organized conceptually by the business. Then, I work with the development or database design team to present this understanding, explore how to reconcile it with the existing database design, and discuss potential adjustments and customizations.

This understanding is essential as I evaluate how to transition business processes and even consider functional system enhancements.

Data Migration Technique #3: Get Specific with Data Dictionaries and Data Maps

The next step is to get really specific and identify how each individual field or attribution from the original system will get loaded into the new system.

• A Data Dictionary for each database will identify key fields and business rules, such as how long the field can be and whether the value is chosen from a list or typed in free form.
• A Data Map identifies how each field from the source database maps to a field in the target database, and any translation rules or data clean-up that’s needed for a successful transition.

It’s not uncommon to map a free form field into a multi-select field or a field with a longer character count to a shorter one. Instead of waiting for these issues to surface during testing, upfront analysis and business involvement can streamline the entire data migration project.

It’s really tempting to leave this work to the database developers – and it’s very likely they will need to augment and update your data maps in order to do a complete data import. As the business analyst, you can bring the business perspective to this analysis, since you’ll understand not just what data is in the field, but how that information is used as part of the business process. That’s key information that not everyone has access to.

Expertise from both the business and technology teams, as well as both the source and the target system, is needed as part of the mapping, so typically there is a lot of collaboration. Here are some of the issues you can expect to work through:

• For mapped fields, you’ll be looking at whether they actually mean the same thing in both systems or whether there is logic in either system that will impact how the data should be migrated over to the COTS product.
• You’ll also want to be sure that all of the important data has a home in the target database, or that they are comfortable letting go of that data or creating a separate back-up.
• You’ll want to evaluate the data source has all the data needed to populate the new system in the format that’s required. Otherwise, a data clean-up project may be required prior to the data migration.
• As you work through these decisions, the team will need to decide where any clean-up and translation rules get implemented, whether in advance of the migration or as part of the data migration process.
• Finally, you’ll have decisions to make about what data to bring over. It’s not uncommon to archive older data and only bring over recent or active data, as this helps expedite the data migration process.

As you can see, there is quite a bit to think about for a data migration project, and we’ve only dug into the details specific to the data migration. A data mapping specification will help you identify the potential issues before the migration happens, creating a smoother transition to the new system.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll look at how data models are easier to change than databases, why data models are easier to review than database designs, and consider how data modeling principles will help you succeed in a wider range of software projects.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

#1 – Data Models are Easier to Change than Databases

There is a big difference between putting together a skeleton spreadsheet of a data dictionary or data map and putting together a relational database design to meet real or supposed business needs.

A spreadsheet is easy to change.

• You don’t need this field? Let me delete it.
• This isn’t a text field? Let me put a new attribute type in that column.
• You need to split these fields apart? Let me add that in.

In a database that’s already been designed and perhaps built, you may be a little more reticent to make these types of changes, meaning that you unconsciously push back on what the business wants just because it will be more work for you.

Yes, your technical skills can help you move into more of a business analyst type of role, but it’s imperative that you also learn to appreciate business needs, wants, and requirements as part of the analysis process.

While it’s conceivable that you are a super hero and willing to do whatever it takes to meet the business needs, no matter how much work it means for you, let’s look at another reason to work on data modeling before database design – it’ll save you a bit of time too.

#2 – Data Models Are Easier to Review than Database Designs

While you can output versions of just about any entity relationship diagram or data dictionary from your database development, these models aren’t necessarily ready for review by the business. They tend to contain an overwhelming about of information for a business stakeholder – a lot of information the business doesn’t care about.

Business analysts create meaningful abstractions that help business stakeholders make decisions. These are easier to review and provide feedback on. While you could simplify automated output to create such an abstraction, it’s likely to be more work than just creating the abstraction in the first place.

Finally, if you are looking at a long-term business analyst career, there is one more reason to focus on data modeling over design.

#3 – Data Models Will Help You Succeed On More Projects

While on today’s project you might understand the database technology in place in your organization, perhaps because you’ve built it, tested it, or maintained it, as you grow your business analysis career, your technical skills will fade into the background.

Let me give you an example. You don’t hear me talk much about the data querying I’ve done because I only ever learned to use a proprietary search engine syntax called CCL that has since been replaced at the only organization in which it was ever used. You also don’t hear me talk about the programming I learned, because it’s limited to a PASCAL class in high school.

These are extreme examples because I left my pursuit of technical skills behind long, long ago. But picture yourself 10, 15, 20 years in the future. If you continue to focus on your business analysis skills, any one of the following situations could be true:

• You’ll be in an organization that won’t let you have access to the physical database.
• You’ll be working on a project using database tools you are unfamiliar with.
• You’ll find yourself without the time to dig into the deeper design details of putting the database together.

In any one of these situations, you’ll still need to communicate data requirements, you just won’t be able to do so using your typical technical tools. And you’ll be glad you learned how to use data modeling techniques from a business analyst’s perspective.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

In this video, we’re going to pick apart the difference between data modeling and data analysis, and give you a clear view as to when each skill set is required as you plan out your business analysis career path.

For those who like to read instead of watch, here’s the full text of the video:

Today I want to talk about data analysis and data modeling in business intelligence roles and data related requirements in business analysis roles. So, it’s a big topic, but we’re really just going to hit the key points.

We’ve been receiving a ton of questions at Bridging the Gap about how to define a career path in business analysis. Is data analysis required? Is the role being overcome by business intelligence roles? And, really, the key to interpreting what’s happening in the job market, as well as defining where you want to go in your business analysis career, comes down to the distinction between data modeling and data analysis. Let’s talk about what those mean and then look at what it means for you in your business analysis career.

If you looking for more guidance on building a business analyst career path, check out this video:

Data Analysis Evaluates the Data Itself

First, is data analysis. Let’s talk about what that means.

Data analysis is evaluating the data itself. It’s doing things like running reports, customizing reports, creating reports for business users, using queries to look at the data, merging data from multiple different sources to be able to tell a better and more informed story than when you look at each source independently. That kind of skill set definitely takes some business acumen. You have to understand what the data means to the business.

But it also takes a lot of technical skills. You need to know whatever database system your organization uses, you need to be able to use those queries. A lot of times, somebody in that kind of role is using a data warehouse or business intelligence system to run those reports. So, you would need to know the ins and outs of that system to use it effectively to tell a story with the data.

Data Modeling Evaluates How an Organization Manages Data

Data modeling evaluates how an organization manages data. On a typical software project, you might use techniques in data modeling like an ERD (entity relationship diagram), to explore the high-level concepts and how those concepts relate together across the organization’s information systems.

Here’s a tutorial on ERDs:

You might create a data dictionary that details, field by field, what are the pieces of information we need to store in this database to meet the software requirement features or to implement this business process change.

You might create a data map that shows how we’re going to move data from one system to another, or how we’re going to integrate and make those systems talk to each other on an ongoing basis to make a feature or business process available to our community.

Here’s a tutorial on data maps:

Data Modeling Can Require Some Data Analysis

Here’s where it gets tricky. Data modeling requires a little bit of data analysis. In order to say this field is going to map to this field in a systems integration project, you probably need to look at the data and understand how the data is put together. This is why we see some job descriptions requiring concepts or technical skills like SQL because if you know SQL and can query the database, it’s a little bit easier to be able to research that information and figure it out for yourself using a little bit of data analysis to inform your data models.

However, there’s a lot of technical professionals, or a lot of business analysis professionals, myself included, who don’t know SQL or don’t use it regularly. You think maybe they know it but aren’t granted access to the database. That comes up too. You have to rely on some other skills to get that information.

For me, it’s been a lot about collaborating with the technical professionals asking questions. Sometimes asking for sample data so they can create a dump of some of the records in a spreadsheet format that I could review and look for so I could find potential data mapping or modeling issues. I’m able to analyze the data without having to know how to analyze the data in the database itself. That’s where we start to see a little bit of the overlap, and there’s some confusion.

It’s Not Uncommon to Find Combined BI/BA Roles

A reason there’s some confusion is because there’s this increased abundance of roles that are really combined business intelligence experts with business analysis roles. The competencies that we just talked about, while they are separate skill sets, they really do go hand-in-hand. If you can model the organization’s data and analyze that data to create more intelligence inside the business, that’s a powerful skill set. We’re seeing a lot of roles pull those two things together sometimes.

You can learn more about business intelligence analysis roles in this video:

A lot of times these roles also have the business analyst job title, which just adds to the confusion. You’ll look at it and it’s, “Oh, it’s a business analyst.” “Oh, wait, this is more of a business intelligence analyst. Why isn’t it given the business intelligence analyst role?” That’s just because business analyst job titles are used in multiple different ways, not just here, but in particular here in this area where it can be really confusing when you’re first looking at job descriptions.

For more insights on the business analyst job titles, roles, and skill sets, check out this video:

It is a very popular growing field to have a business intelligence area of expertise. It doesn’t mean that you have to have it to succeed as a business analyst. We’re still seeing a lot of more general functional business analysis roles out there, and, so, it’s a choice you can make if you are really into that kind of thing for sure. Business intelligence is a ripe field with a lot of career potential. But if you’re not, there are still going to be opportunities for you.

Regardless, data modeling is an important competency to have because you need that if you’re working on a business intelligence project. You need it if you are implementing any kind of software or business change to make sure those information systems are really capturing and storing the right data to meet that end business need that you’re trying to get to with your project.

So this has been a crash course on some different data-related skills and why we see some confusion in the business analysis job marketplace.

>>Learn More About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

For Long Lists of Fields in Use Cases

A use case captures how a user interacts with a software solution to achieve a specific goal. One of the most frequently asked questions from our use case course participants is what to do with long lists of fields that find their way into a use case.

While a certain amount of data information can be incorporated into a use case, once a list spans longer than about 5 fields or starts to include supplemental information about each field, a data dictionary is a better choice.

Connecting these two models is simple. If there is a step inside a use case referencing a collection of fields, simply refer to your data dictionary or a section of your data dictionary from inside the use case.

For Data-Entry Elements in User Interface Wireframes

Similar to use cases, user interface wireframes often contain many data components, often when data is being added or updated. For example, the wireframe screen for creating a new account would contain a user interface element for each piece of data supplied by an end user to create the account.

When this happens, it can be tempting to annotate the wireframe with a lot of data-related rules. Instead, like with a use case, break apart the data elements from a wireframe into a data dictionary, which is specifically designed to handle these rules.

For Data-Related Steps in Workflow Diagrams

Business analysts create workflow diagrams, or models visualizing the steps of a process, to show how business or technical processes flow. Close cousins of workflow diagrams are state diagrams, activity diagrams, and data flow diagrams, which are more specific ways of capturing technical processes. Value stream mapping is a special way of modeling a business process, focusing on the activities that generate the most value to the business.

An activity step in a workflow diagram could involve creating, updating, saving, validating, archiving, or deleting data. Since with workflow diagrams you don’t have a lot of visual room to expand the details of any given step, referencing a set of attributes from a data dictionary is a great practice.

Business Analysts Blend Techniques

While data requirements can be captured using use cases, wireframes, or workflow diagrams, none of these models is designed specifically to help you analyze and organize data requirements. If you find yourself forcing data requirements into a different kind of model or struggling to see the big picture of how all the data requirements relate together, it’s a good sign that a data dictionary would be a useful supplemental specification for your project.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

Here are 10 articles to help you get started with data modeling. These are perfect if you want to brush up on data modeling or get fresh ideas to improve your business analyst work.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

But onto the articles!

• How to Data Model Without Getting Too Technical (or the what and the how)
• How Data Modeling Fits Into the Business Analysis Process
• When it Works to Create a Data Map and a Data Dictionary at the Same Time
• What Software Tools Business Analysts Use for Data Modeling
• 6 Things You Can Do When Your Data Dictionary Gets Messy
• You Are Not a Magician (Or Maybe You Are)
• How to Blend a Data Dictionary with Use Cases, Wireframes, and Workflow Diagrams
• The Difference Between Data Analysis and Data Modeling
• 3 Reasons to Data Model (Even if You Can Design Databases)
• How to Approach the Data Migration for a COTS (or Saas) Project

If you already know something about data modeling, take a look as you might find some fresh ideas.

And here are articles describing four of the core data modeling techniques that we cover in our in-depth course – Data Modeling for Business Analysts – because they can help you solve tricky project challenges:

• Glossary – for clarifying terminology and simplifying data modeling.
• Entity Relationship Diagram – to visualize relationships between key concepts.
• Data Dictionary – to communicate data requirements in a well-organized way.
• Data Mapping – to resolve data issues for data migration or integration projects.

>>Learn EVEN MORE About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll discuss the types of tools used to generate different types of data models, and then specifically look at how you can use tools you are most likely familiar with to do data modeling.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

Database Tools Can Generate Complicated-Looking Models

Most database models we see are physical-level models representing the actual database structure. The good news is that no one is manually creating these models. Most often, they are generated output direct from the database software itself.

This also happens to be one reason they are so difficult to read from a business perspective. These models do not represent meaningful abstractions designed to help business stakeholders make decisions about data requirements. They simply show us what exists today, in all its wonderful and gory detail.

(Luckily, as a business analyst, you won’t be creating these models, although you may need to review them to understand the current state. If you haven’t already checked out this article on how to data model without getting too technical, be sure to do so. We define the difference between physical, logical, and conceptual data modeling there and draw a line in the sand regarding what type of data modeling is typically done by business analysts.)

Business Analysts Use Tools Like Visio and Excel

When we are updating existing data models or communicating the requirements for creating new database designs, we don’t have automated tools to generate these specifications. So, yes, we do need to create the models from scratch…manually.

Here are 3 tools commonly used by business analysts to complete conceptual and logical data modeling.

• For creating ERDs, Visio is a common choice. It’s a full-featured software tool that many organizations already have. (Microsoft also offers a 60-day full-featured free trial of Visio, making it easy to practice using it even if your organization doesn’t have a license.)
• Alternatively, if you don’t have access to Visio, there are many web-based diagramming tools offering similar functionality to Visio. Gliffy is my favorite because it’s simple and easy to use. You can also create and save up to 5 diagrams for free.
• For a data dictionary or data mapping, Microsoft Excel is a common choice. Sometimes Excel can get a little messy and so it might be better to bring your matrix over into a Microsoft Word table, which will make it easier to add more formatting and narrative.

(In the Data Modeling for Business Analysts course, we’ve included templates and samples in these formats so you’ll be able to get started right away.)

More Sophisticated Modeling Tools Can Generate Code

When it comes to software tools and data modeling, there is one more practice you should be aware of. There are a collection of visual modeling tools that can be used to automatically generate code or databases. These are used by developers and simplify the process of programming.

If you are modeling using one of these tools, you are definitely treading outside the boundaries of a business analyst role. If you are not a developer and not responsible for designing and building database structures, you shouldn’t need to use these tools. Or, if you do use them, your models should be considered drafts for a technical design to iterate from when implementing the technical solution, not final models designed to generate code.

When in Doubt, Keep it Simple

Data modeling is complex enough without worrying about learning a lot of new software too. When in doubt, choose a piece of software that’s readily available or that you are comfortable with. Focus on communicating the data-related business requirements in the best possible way, and you’ll be achieving exactly what you need to do as a data modeling business analyst.

>>Learn More About Data Modeling

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In a certain set of circumstances, they can be done simultaneously as one stream of analysis activity. We’ll talk about when and how that works in a bit, but first let’s clarify the difference between the two deliverables and when to create each of them.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Difference Between a Data Dictionary and a Data Mapping Specification

• A data dictionary defines the data elements, meanings, and allowable values, often for a single data source.
• A data mapping specification defines how information from one system or data source maps to a separate system or data source.

In order to create a data mapping specification, you need to understand the data dictionaries for each of your data sources. In fact, your data mapping spreadsheet will take key pieces of information about the attributes of both sources and present them side-by-side. This allows you to evaluate how the data will flow from one source to another and what translation rules are required.

When to Create a Data Dictionary

You’ll create a Data Dictionary for the following types of projects:

• Updates to existing databases or information systems
• New databases or information technology systems
• Any project where multiple systems are using a single data source

You can create a current state dictionary to understand the data requirements for an existing data source, or a future state data dictionary to spec out the key data requirements for a to-be-created data repository.

When to Create a Data Mapping Specification

You’ll create a data mapping specification for the following types of projects:

• When source data is migrated to a new system as part of a data migration
• When source data is sent to a target data repository on a regular basis as part of a data or system integration

The type of system doesn’t really matter, they could be Commercial-Off-the-Shelf, Sofware-As-a-Service (SaaS), or in-house proprietary systems. If data is moving from one system to another, a data mapping specification will help you model those requirements.

Again, a data mapping specification can be created to model an existing data integration. But most commonly you’ll create them to model how a new data migration is supposed to be handled or a new data integration needs to work.

When to Do Both Together

Now, to the question of if and when these two documents can be created together.

Data modeling can be a complex activity that requires a lot of intellectual activity for a business analyst and a lot of collaboration with business and technical stakeholders. One reason to keep these two deliverables separate is simply to break apart the analysis into interim steps and keep things moving smoothly.

If you are working on a significant data migration project with hundreds of fields and you jump right into a data mapping exercise, you are likely to get stuck. And stuck = frustrated. One way to get unstuck is to back-pedal and create a separate data dictionary for each data source or even an ERD (entity relationship diagram) modeling out the whole project.

That being said, here are some scenarios when it could work to do the exercises together.

• You are updating the data mapping specification for an existing data integration.
• You are creating a new data model by evaluating a pre-existing data model, and so the mapping exercise is a tool for requirements discovery.
• You are working on a data migration or integration that touches a relatively small number of attributes.

It’s also likely that your data mapping exercise will require changes to one of your data models, so data mapping can lead to data dictionary updates.

When it comes down to it, as long as your data map helps you discover and resolve all of the data requirements, you’ve done what you need to do as a business analyst. If you are new to data modeling, data dictionaries and data maps will be easier to apply as discrete activities. And since they will not always be done together, you get to add two data modeling techniques to your BA toolbox.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, you’ll learn what data modeling techniques to consider in specific project contexts so that you can leverage your business analyst tool box in the best possible way on any given project, making you more effective and part of driving more successful project outcomes.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

A Case Study in Selecting Data Modeling Techniques

This can start to get a little theoretical, so let’s start by looking at a sample project, why I chose each technique, and how they fit into the business analysis process. This particular project was a customer-facing information management system that was designed to replace a forms-based paper process.

• I chose to start with data mapping because I needed to understand how the information flowed from the paper-based forms to the existing information technology system. (This happened at the beginning of the project, as part of defining scope and understanding the current state.)
• Then I created a conceptual entity relationship diagram (ERD) because we needed a way to blend our new business concepts into our pre-existing database structure. (This happened in the middle of the project, as part of transitioning from requirements analysis to technical design.)
• Finally, I got into the details with a data dictionary because we were working from one data source that needed to support two separate systems. (Although I could have started the data dictionary earlier, alongside my wireframes and user stories, it was actually completed more as a wrap-up deliverable towards the end of requirements, during technical design and implementation of a future state system.)

In this particular project, I happened to use all of the techniques. However, I’ve worked on several projects throughout my career that applied only one or two of these techniques, and a few with none at all.

Different Projects Call for Different Techniques

The project you are working on will inform what techniques are appropriate. Here are some general guidelines you can use to help you decide what techniques to consider for your project.

• On a data migration project, you’d optionally start with an ERD, move on to creating current state data dictionaries for both systems (unless they already exist), and then create a future state data mapping specification to show how data moves from one system to another. If changes to either data source are required, they could be specified using a future state data dictionary.
• For a relatively small change to a pre-existing system, you might make a small update to an existing data dictionary, glossary, or ERD, but it would most likely be unnecessary to recreate all 3 of these models from scratch to represent the current state.
• For a system integration project, you might start by creating a system context diagram to map the flow of data from one system to another, move on to creating data dictionaries for each data source, and finally, if needed, create a data mapping specification. (You’d only need a data mapping if data is actually moving from one system to another, which is not always the case. More often, system integration projects, like the one mentioned in the case study above, are using a single data source.)

But again, data modeling is not required for every project. For example, a change that only impacts the user interface or flow of the application and does not actually touch the data model would not require any of these data modeling techniques.

What’s more, if you are working with a data architect or analyst, it may be that your involvement in more detailed specifications like a data dictionary is in more of an input and review capacity than a creative one.

Data Modeling Adds to Your BA Toolbox

Most business analysts think of the set of techniques they know more like a toolbox and less like a process. The techniques get swapped in and out depending on the needs of the project. Most of them can be used independently but each tool you bring out builds upon the others.

The bigger tool box you have as a business analyst, the more types of projects you’ll be able to handle successfully.

Given today’s emphasis on information technology systems, reporting, and data intensive applications, you can safely assume that you should be at least evaluating the data modeling techniques in your toolbox to see if any of them would be relevant to your project. And then you want to double check that someone with a business perspective (not technical expertise) is paying attention to them. If no one suitable comes to mind, that person is most likely to be you!

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

In this article, we’ll look at the 3 different levels of modeling, describe how detailed business analysts typically get in data modeling, and look how relevant technical details get filled in.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The 3 Different Levels of Data Modeling

Data models can look very complex, but they can also be completed at different levels of abstraction.

Let’s take a quick look at the 3 different levels of modeling:

• Conceptual Models – Represent business concepts and ideas with no consideration for the technical design. Conceptual models definitely fall under the umbrella of what the business wants.
• Logical Models – Make the business concepts theoretically implementable in a database design, but still may not include all of the details of the physical database structure. Logical models fall right in the intersection of what the business wants and how the solution team will implement it.
• Physical Models – Specify the actual database tables and fields that are created as part of the database. Physical models are under the umbrella of how the database will be designed and implemented.

Business Analysts Stick to Conceptual and Logical Models

Any of the data modeling techniques can be completed at different levels of abstraction. As business analysts, we’re most likely going to stick to conceptual and logical models. And when creating logical models, we’re most likely collaborating with more technical professionals.

For example, while ERDs can be created to model physical database structures and indicate exactly what tables to create, what primary keys to validate, and what attributes belong to each table, those details typically fall to a database architect or developer. However, a business analyst may indeed create a conceptual level ERD to visually show how business terminology, the set of terms that would be included in a glossary, relate to one another.

Similarly, when creating data dictionaries, business analysts commonly create logical models, not physical ones. A logical data dictionary would leave out many attributes and attribute details required by the database design that have no relevance to the business. (We’ll look at exactly how this works in the next section.)

How the Technical Details Get Filled Into a Data Model

While you as the business analyst may not be responsible for technical details, or the how, the project team definitely needs them. Let’s look at how a project team might evolve a conceptual or logical model into a physical database model, using the example of a data dictionary.

First, the business analyst could identify the following types of information:

• Attribute names for attributes required by the business. These are likely to surface in your  functional requirements
• Attribute types, assigned at a high level, which may or may not be the exact type assigned in the physical database
• Whether each attribute is required or optional
• And finally, any notes or additional information important to the business stakeholders that could influence the database design

At this level of detail, it doesn’t really matter if your data requirements will be built in Oracle, SQL, or some other database or data structure.

After reviewing this level of a data dictionary collaboratively with the business analyst, a database developer might identify the following types of information:

• Primary keys and unique IDs required to create a structurally-sound relational database
• Database field names that meet organizational and best-practice technical standards
• Specific attribute types, given the type of database system in place in your organization
• And perhaps a whole lot more that is rather invisible to us as business analysts

A similar process can be followed for any type of data modeling technique, with the business analyst discovering, analyzing, and validating the higher level details and a technical stakeholder fleshing out the complete design.

Let the Business Perspective Guide You

While it’s possible that the tool or technique you are using could theoretically be used to create a physical data model, that does not mean you are responsible for capturing all of the physical level, or technical how details. Whether you create conceptual what models or logical what-how models, you’ll be helping your business make better data-related requirements decisions and smoothing out the technical design process.

At the end of the day, as a business analyst the most important thing you can do is ensure the business perspective informs critical technical decisions. You are responsible for discovering the what and collaborating to help define the what-how, whether we are talking about data modeling or any other technique.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

• Entity Relationship Diagram – A handy tool that helps visualize relationships between key business concepts to encourage business-focused database designs.
• Data Dictionary – A spreadsheet format that enables you to communicate to business stakeholders clearly and in an organized way, eliminating long lists of fields inside use cases or other requirements document.
• Data Mapping – An essential template for a data migration or data integration project that will ensure any data-related issues are discovered and resolved ahead of the last-minute data crunching that often derails big projects.
• Glossary – Along with encouraging more effective communication among stakeholders, clarifying your requirements documents, and helping you learn about a new business domain, a glossary will make the rest of the data modeling techniques easier, as you’ll be working from a clear and unambiguous collection of terms.

Take a look through all 4 of these articles and make yourself more adept at both data modeling and handling tricky project challenges.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

While creating a glossary can take a bit of time and attention, doing so will generate many benefits, such as:

• Facilitate learning about a new business domain, by keeping terminology variations and acronyms straight.
• Clarify your requirements documents, by providing clear definitions of the important terms used inside them.
• Save time in requirements meetings, since stakeholders will be using a common language.
• Encourage more effective communication among stakeholders, by resolving terminology disagreements.
• Pave the way for data modeling and database designs that accurately reflect true business requirements.

As we’ll see, creating a glossary is the first step to achieving these benefits. The second is encouraging the use of the glossary terminology. You’ll receive tips for both steps in this article.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Key Elements of a Glossary

In its essence, a glossary is a list of terms, with accompanying definitions, and is not unlike a dictionary. However, unlike a dictionary, a glossary contains only terms that are unique to a business domain or uniquely used within that business domain.

For example, although “customer” is a commonly used word, it might also be a term in your glossary as it’s not uncommon for different business stakeholders to have different definitions of what a customer is.

Let’s look at the key elements of a glossary:

• Terms – This is the unique words or short phrases that are part of business conversations. Typically terms are nouns – or persons, places, or things.
• Definitions – Provides the exact meaning of a term in an unambiguous way and clarifies the boundaries of when the term can appropriately be used in communication.
• Alias – A word, phrase, or acronym that is used interchangeably with the primary term in your glossary.
• Related Terms – References to separate terms in your glossary which are similar to, but not interchangeable with, your primary listed terms.

Often business analysts focus on documenting lengthy glossaries that capture all possible terms used inside an organization. While hefty, these documents are rarely as useful as they feel (although they can help the business analyst tremendously in getting up to speed in a new business domain). Next let’s consider some tips for using a glossary to clarify communication.

For a quick view of why this is all so important, check out this video on the challenges created by the inconsistent use of terminology:

Using a Glossary to Clarify Communication

If we agree that the purpose of a glossary is to encourage consistent use of terminology by stakeholders and clarify requirements, then we’ll quickly realize that the glossary is only the beginning. A glossary is your reference tool and a way to capture terms, definitions, and variations as they come up in your requirements meetings.

Just as important, however, is that you encourage the consistent use of terminology. Here are a few tips for doing so:

• Use the terms consistently – absolutely consistently – in your requirements specifications, as even small variations can cause confusion. (Out of the hundreds of requirements documents I’ve reviewed, inconsistent use of terminology is one of the most common mistakes I see.)
• During requirements meetings, clarify unfamiliar or new terms before moving on. Doing so will often save lots of time resolving other requirements-related conflicts between stakeholders, as often these boil down to varying definitions between terms.
• Encourage the use of business terminology in data models by bringing forward business terminology into your ERD (Entity Relationship Diagram and Data Dictionaries. Often these documents use technical language that is confusing to business stakeholders, and technical terms can be helpfully included as aliases in your glossary.

With persistence and consistent use of glossary-based terminology, your stakeholders will start communicating more effectively, your requirements specifications will be better understood, and your data modeling will be easier.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

Essentially, a data dictionary provides a tool that enables you to communicate business stakeholder requirements in such a way that your technical team can more easily design a relational database or data structure to meet those requirements. It helps avoid project mishaps such as requiring information in a field that a business stakeholder can’t reasonably be expected to provide, or expecting the wrong type of information in a field.

What’s more, if you’ve been wondering what to do with long lists of fields inside use cases or other requirements documents, you’ll be happy to learn that they have an ideal home in a data dictionary.

Alternatively, if you’ve been creating spreadsheets to organize data-related information, you might be surprised to learn that you’ve been creating a form of a Data Dictionary. For a long time, I simply referred to these types of specifications as “content specs” or a “data matrix,” only to discover I’d been creating Data Dictionaries for over 10 years of project work.

(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)

The Key Elements of a Data Dictionary

A Data Dictionary provides information about each attribute, also referred to as fields, of a data model. An attribute is a place in the database that holds information. For example, if we were to create a Data Dictionary representing the articles here on Bridging the Gap, we’d potentially have attributes for article title, article author, article category, and the article content itself.

A Data Dictionary is typically organized in a spreadsheet format. Each attribute is listed as a row in the spreadsheet and each column labels an element of information that is useful to know about the attribute.

Let’s look at the most common elements included in a data dictionary.

• Attribute Name – A unique identifier, typically expressed in business language, that labels each attribute.
• Optional/Required – Indicates whether information is required in an attribute before a record can be saved.
• Attribute Type – Defines what type of data is allowable in a field. Common types include text, numeric, date/time, enumerated list, look-ups, booleans, and unique identifiers.

While these are the core elements of a data dictionary, it’s not uncommon to document additional information about each element, which may include the source of the information, the table or concept in which the attribute is contained, the physical database field name, the field length, and any default values.

Example of a Data Dictionary

You are probably wondering how all of this comes together.

Here’s a look at a simplified example data dictionary that contains the attribute from our Bridging the Gap article example, along with critical information about each attribute.

As you can see, a data dictionary defines critical information about each attribute in a business-focused way. It also organizes information that might otherwise be scattered across multiple different documents and specs, making it easier for your database developer to design or update a database that meets business requirements.

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

Participants who complete Crafting Better Requirements may have very different educational and professional backgrounds, but they all have one thing in common: they leave the course with a unique set of strategies to successfully communicate requirements to the various audiences of their requirements documents.

Let’s look at the improvements a few selected course participants have made. It may be that in reading their stories, you find your most common mistake and can benefit from their feedback as well.

Issue #1: Using “User”

Take Tina*, for example. In her first attempt to capture functional and non-functional requirements for an online web store, she did a great job creating precise requirements, but repeatedly made the mistake of using the generic term “user” to refer to very different types of users of the web store application. All her requirements started with, “The user will be able to…”  While for business stakeholders this may not be a problem (since they implicitly know what actors are expected to have access to specific functions in the system), for the development team this could be a source of misunderstandings that might delay the delivery of a usable solution. With the feedback provided during the course, Tina was able to quickly improve the way she was capturing requirements, starting to use specific actors to identify who would be able to perform each function described (“the customer can add products to cart”, “the webstore manager can run daily reports of online orders”, and so on).

Issue #2: Vague Requirements

Bob*, on the other hand, already had the habit of identifying the correct actors, but was used to writing vague requirements that elicited lots of questions from the development team. For example, as part of the requirements for a keyword-based search, he would write, “Search engine should return search results fast to customer.” But  what does “fast” mean? The business could be thinking that it means returning results in less than 2 seconds, while the development team is assuming 10 seconds or less (because it would already be a challenge to retrieve the results in this amount of time using the existing IT infrastructure). QA would not have enough information to create test cases in order to ensure this requirement had been fulfilled. Once this weakness was identified, Bob was able to train himself to look at his requirements from the viewpoint of the people who would need to implement and test them (rather than just from the perspective of the stakeholders who will benefit from the solution, and thus know what the expectations are). By always asking, “How would I test if this requirement is correctly implemented?”, he was able to increase the level of detail of his specifications and substantially reduce the number of questions he got from the development team to clarify requirements.

Issue #3: Poor Organization

Jane* was always trying to get her manager and colleagues to look at her requirements to find areas for improvement before she shared her specifications with technical and business stakeholders. However, her manager wasn’t trained in requirements documentation, and the other BAs on her team didn’t have time for more than a cursory look at her documents, so the feedback she’d get was insufficient to surface the problems with her specifications. Only during the final review would the stakeholders give their full attention to her requirements, and ask questions that required Jane to go back and make a series of updates in the documentation before getting the necessary approvals.

During the course, Crafting Better Requirements, Jane finally had a chance to receive in-depth feedback for her requirements statements, and identify the flaws in the way she was documenting them. She learned some useful strategies, such as grouping requirements by functional area and user type to make it easier to spot missing requirements. Using her new set of strategies, she was able to decrease the number of review sessions required to get sign-off for her requirements documents.

* Names have been changed for privacy.

How to Leverage Feedback for Improvement

In these and other success stories collected over the years since the launch of Crafting Better Requirements, the main benefit the participants received from the course is the ability to focus on their own specific weaknesses, rather than follow a predefined curriculum. Based on the identified areas of improvement, some participants will spend most of the time practicing writing requirements statements to make them more concise and less ambiguous, while others may dedicate more cycles to creating diagrams to augment their requirements using visual representation, or learning how to create more effective acceptance criteria for their user stories. Instead of standardized teaching, they are able to experience customized learning based on individual feedback and personalized instruction and assignments which, in the words of a participant, “drastically reduced my learning curve.”

As a result of the customized feedback provided throughout the course, and the opportunity to use deliberate practice to overcome their individual weaknesses, these business analysts not only acquired new valuable skills, but also increased the value they provide to their organizations. The benefits for the companies these BAs work for include shorter requirements cycle time, less back and forth with developers to clarify requirements after sign-off, and fewer change requests submitted during user acceptance testing due to incomplete or incorrect requirements.

Those new to BPMN understandably find it overwhelming. There are flow objects, connecting objects, swim lanes, and artifacts. And that’s just the categories within the notation. Overall, there are over 40 different elements, each with rules about when it can and cannot be used.

(In contrast, our quick list of workflow diagramming elements in the Business Process Analysis course contains the 5 elements that are used by the majority of practicing business analysts.)

If you are new to business analysis, looking at the skill set for models completed in alignment with the BPMN standard might stop you in your tracks.

As it should.

For all of us, new to business analysis or not.

(Before I forget, be sure to download our free business process template.)

When to Use BPMN

In my experience, there are only 3 good reasons for using BPMN notation.

1. You find yourself stuck using the handful of most commonly used workflow diagram elements to represent a concept. In this scenario, it makes sense to selectively draw from BPMN to model the process.
2. Your organization requires you to use it. If this is the case, the application of BPMN should be tied to a larger organizational objective. It also typically means you are completing more formal modeling that is implementable in business process management tools.
3. You are applying for a job you are otherwise qualified for that requires knowledge of or experience with BPMN notation. By all means, learn the techniques and create a few work samples using the notation.

Unless one of these 3 reasons applies, using BPMN for the sake of doing BPMN can do more harm than good.

Risks of Using BPMN

And there are many risks to using BPMN, when it’s not expressly needed.

• The models we create are more difficult for our stakeholders to understand, potentially leading to business processes that include incorrect information.
• It’s more complex for us to create models, meaning we need more analysis time to deliver the same amount of value, unless the use of the notation is specifically tied to other business objectives.
• We’re more likely to make modeling mistakes, which decrease rather than increase the clarity of our process flows.

Like any analysis tool in your business analyst tool belt, choose BPMN with care. And if you are just starting out as a business analyst, it’s probably going to make more sense for you to pursue business analysis jobs requiring workflow diagrams and process models rather than those requiring BPMN techniques. BPMN is an advanced technique and you can learn it once you’ve mastered the more fundamental skills of a business analyst.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project.

Click here to download your free business process template today

Choosing the best deliverables for a project situation is a necessary skill to be an effective and valued business analyst and sometimes use cases are simply not the right choice. In certain project contexts, choosing use cases means creating way too much documentation. In other contexts, the use cases make it difficult to highlight the most important requirements so they can be easily implemented. Other times, they are simply not an appropriate tool for the type of requirements you are creating.

That being said, I do have my own love affair with use cases, the latest installation of which is facilitating a virtual course called Use Cases and Wireframes. Love affair or not, use cases are not always the best choice.

Let’s look at 3 signs you shouldn’t be writing a use case.

Sign 1: You Are Not Specifying Software Requirements

Use cases are ideal for specifying functional requirements in such a way that shows how the user interacts with a software system to achieve a specific user or business goal. If you are not documenting requirements for software, then you shouldn’t be writing a use case.

If you are not specifying software requirements, you are most likely defining requirements for a business process change. If so, consider a business process model.

Sign 2: Software Changes Are Not Interactive or User-Driven

A use case is an ideal choice for providing context to user-driven or interactive software features. Because each functional requirement happens in response to a user action, there is a flow to a use case that makes them easy to understand and review. However, it’s possible to specify software changes and requirements that are not particularly interactive.

For example, let’s look at reporting requirements. Typically when you write reporting requirements you are working from an existing reporting system. The functionality already exists for selecting a report, selecting criteria, and generating the report. A typical small project will add a new report to the existing system. It might be tempting to write a use case to describe the report, but unless the report itself is interactive (for example, if you click on a data row, then filtering is applied) there is not much value in writing a full-blown use case to capture these requirements. Instead a detailed wireframe (perhaps with an accompanying user interface specification) or sample report would be better choices.

Of course, if you are building a new reporting system or updating the flow of an existing reporting system, then a use case could be entirely appropriate. For instance, if users are going to be able to generate their own reports for the first time by specifying criteria and choosing from a list of report types, then a use case could be a very logical choice for detailing these functional requirements.

Sign 3: Your Team Prefers Another Form of Documentation

No matter how much we like one business analysis technique, it’s important that we customize our business analysis activities to meet the need of our stakeholders. When it comes to functional software requirements, the needs of our technical implementation stakeholders in software development and quality assurance are of primary concern.

They might prefer a functional specification so that all of the requirements are included in one document. Or, if they are using agile methods on their project, they may prefer a collection of user stories with a few selected visual models to tie the requirements together. In light of your team’s preferences, you might choose not to write use cases even if they’d be a logical and appropriate choice otherwise.

(On the flip side, if your technology team has been asking for a simpler solution to a functional requirements spec, you could run a few use cases by them and see if they work better than your current process. Or, you might find that you do your best analytical thinking by writing use cases and so create some working drafts that do not become part of your final work product.)

How to Choose Your BA Deliverables Wisely

There is no one type of business analysis deliverable that must be created in all situations. Smart BAs make smart choices based on the type of requirements they are specifying and the needs of the project team. Make a choice that you can defend and start with it. Seek feedback and iterate until you find a deliverable mix that works for you, your business stakeholders, and your implementation team.

When in doubt, remember that it’s not likely your project is destined to fail if you choose a technique that’s not a perfect fit. You’ll have many opportunities to course correct as long as you pay attention to feedback and keep an eye on your project’s scope along the way.

Learn How to Create Use Cases
(and Wireframes Too)

Interested in learning how to write a use case? Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

Let’s take a look at some of the circumstances that slow the requirements process down and how visuals can create breakthroughs that help you get things done faster.

Speed Up Requirements Discovery With A Clarifying Model

First and foremost, the time I turn to visual modeling is when stakeholders are failing to understand each other. While clarifying language and asking good questions can clear up many ambiguities, sometimes it’s simply not enough to talk through a problem or issue.

For example, on one project we were figuring out how to provide customer access to a collection of information previously restricted to internal users. The way the customers thought about the information was very different than how the system that had been created 10+ years earlier stored the information. Every time we started a conversation, stakeholders would be talking in a mix of customer terminology and database fields and everyone would be so confused that we didn’t get very far.

I decided it was time to take a step back. I created a very rough draft of a business domain model in the customer’s terms and we walked through it step-by-step, making adjustments as we went along. For the purposes of the discussion we ignored the database fields or how the information was actually stored. The meeting took nearly 2 hours but at the end we had a working set of language from which we could discuss actual requirements and the requirements process started moving briskly. The visual model was critical to help everyone see how the concepts related and learn to use a shared language.

(By the way, this is a scenario we dive into more deeply in the Visual Modeling Guidebook included with the Visual Model Sample Pack.)

Break Down a Complex Problem Faster with a Diagram

A second scenario where visual models can speed up the requirements process is when there is a complex problem to analyze. I can’t count how many times I’ve stared at a blank sheet of paper or requirements template only to not have any clue what goes where. In these cases, starting a diagram, often on a sheet of scrap paper, helps me think better and analyze the problem more completely.

For example, I drew and redrew the process model version of the BA Career Roadmap at least 5 times before using a tool to capture it electronically. Then and only then did my designer start working to bring it to life as a roadmap.

Drawing the process was not academic. I was working through different aspects of the process and rethinking how to present the information. It was much faster to draw new versions of the process model than, say, write up a formal textual model or narrative. Those elements were important and they came later, once I’d worked through the most complex issues.

While I don’t always share these rough diagrams with my stakeholders, sometimes I do, and that brings me to the next scenario.

Accelerate Requirements Reviews by Providing Context

Just like you can get stuck staring at a blank template, your stakeholders can get stuck reading a filled-in document.

• What does this requirement mean?
• How does it fit into the other requirements?
• Is it right or is it wrong?

Requirements reviews can create a lot of anxiety for stakeholders. On the one hand, they know they need to provide good feedback to get what they want. On the other, they may not fully understand what they are reading.

Diagrams can help speed up their understanding and help stakeholders feel more comfortable with the business analysis process. Diagrams like workflow models put processes in context. Diagrams like business domain models clarify complex concepts in business terms. Diagrams like a wireframe provide an idea of what the requirements might look like on the screen, making it much more clear how the details fit together.

And all of this means that you get better feedback on your textual requirements earlier in the process.

Recapture Time You’re Losing Now By Using Visual Models

The time you spend creating visuals has an immediate payoff – so while they do take time to create, you recapture the time you would have spent in meetings wrangling concepts that the visuals easily explain. Just like good cooks get all their ingredients prepared in advance and good painters prep the walls and trim with tape and paper, good analysts prep visual models so they get as much as possible right the first time.

As we consider what the industry is asking us to do as business analysts – digging further into discovering and delivering value, paying attention to business outcomes and increasing  stakeholder involvement – getting good at visual modeling gives us an edge that people notice. It’s one of the tools in our tool belt we need to hone because it helps us think more clearly and communicate more easily.

I’m excited to be able to help you learn to use visual models on this part of your BA journey. The Visual Model Sample Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.

Click here to learn more about the Visual Model Sample Pack

I had a template, a big one in fact. It had 20, maybe even 30 sections in it. And my discipline led me to believe that putting something in each and every one of those sections was the best way to be effective as a business analyst.

After all, someone wouldn’t have added it to the template if it wasn’t important, right?

So, what could go in this particular section?

If I didn’t have an idea, I’d ask the project team. After all, that’s what I’d seen the other BAs do when I was sitting in on their requirements meetings.

So I’d ask. And wait. And think. And struggle a bit.

And by now we are all feeling a bit squeamish and uncomfortable. That hot-head architect is just dying to take a pot shot at me and start a discussion about the template itself and completely derail my meeting. I can feel it coming.

“Oh! What about this?” says the product manager.

{collective sigh of relief}

Yes, that works, a few people nod.

I write a note.

We move on.

Of course, I know that we’ve already captured “this” in another section and I’m crossing my fingers under the conference room table that the uber-smart architect doesn’t call me out on it. But since it also fits here, I can decide how to handle the duplication when I get back to my desk. For now, I’m quickly moving on to a more interesting part of this particular requirements review meeting before anyone else notices.

{fast forward a few years}

I switch organizations and am responsible for starting a new BA practice-of-1. One day while working on a draft of my requirements specification, I realize that I own this. No one at this organization has ever seen this template. No one. They won’t know if I just remove a section or two or three or (yikes!) four and let it die a slow and painful death on my PC.

I think about the pros and cons of this decision.

• I realize that I’ve been letting the templates be my master instead of mastering them.
• I realize that as safe as it feels to fill in every section of a trusted template, it’s not safe at all, especially if no one is reading the thing.
• I realize that I can choose a better way.

My business analysis life starts afresh. I will do better. I will write better. I will serve better. Over the course of the next several years, a transformation happens.

• Instead of thinking big, I start to think small.
• Instead of thinking fill in the blank, I think about decisions and next steps.
• Instead of thinking about an abstract sense of completeness, I think about usefulness.

It all starts with losing my dependence on the long, laborious templates that felt very, very safe. Somewhere along the way I shed my greenness and while I keep my discipline, I apply it using a different set of principles. Somewhere along the way, my requirements start to get just a little bit spunky.

From time to time, I still look back.

I wish that way back when I had the license to cut up my templates so that my documentation would have been shorter and relevant and my meetings less painful.

I wish that way back when I had a more concise starting point so that my documentation would naturally be more readable.

I wish that way back when I was told to add if needed instead of play a game of fill-in-the-very-large-set-of-blanks.

I can’t get back the hours I wasted and the spunk I sucked out of those early requirements documents (and their meetings). But I can give you a simpler starting point.

And that’s exactly what I’ve done with the Business Analyst Template Toolkit. The templates are short and you are welcome to add or subtract. The Toolkit also includes work samples so you can see exactly how the template works and what it helps you accomplish in your requirements documentation. And a guidebook walks you through my approach so you can use it as a starting point for your next project.

I wish I had a lighter starting point way back when, so I wouldn’t have had to learn how to streamline my documentation in a much more painful way. And that’s why I’ve annotated my templates and am sharing them with the business analyst community.

>>Learn More About Templates and Requirements

Click on one of the links below to learn more about how we approach templates and requirements:

• I’m Letting Go of the Big Thick Requirements Document, Are You?
• How to Present Yourself as Capable of Doing Requirements Specifications (Even If You’ve Only Created Informal Documentation)
• Requirements Templates: What To Do When You Must Start From Scratch

In this article, we’ll discuss what these terms mean, as well as provide some examples that you can use to match up your own career experience.

But first, a story.

My husband and I have taken to watching a lot of Jimmy Fallon lately. (We love to laugh and Jimmy is great, especially when replayed on the DVR at 8:30 pm. :-)) In one show, Jimmy had someone on his show with a plastic 3-D printer. These have been around for years, but now they are affordable outside of big scale R&D organizations.

That’s a fairly interesting development, don’t you think?

For a few thousand dollars and some extra garage space, I could print out plastic prototypes of physical objects. If I was designing a physical product, I could actually hold that product in my hands before investing in producing the real thing.

Have you ever held a pen that didn’t feel right in your hand while scribbling down meeting notes?

Did you wish someone had let someone like you try the pen before they produced it?

With prototyping, this becomes an economically viable expectation.

And prototyping is a relevant technique when creating IT systems too. Except it’s not about printing plastic. But it’s still called a prototype. Well, sometimes. Other people call it user interface mock-ups. You’ll also see them called wireframes.

Each of these terms has their own formal and closer-to-“right” definitions and we’ll get to those below. But the reality is that the terms can almost be used interchangeably. What’s more, depending on who you are talking to they can mean very different things (or the same exact things). This means that when any one of these terms are used in a job posting, it’s best to clarify what exactly is meant. (And especially to do so before saying, “I’m not qualified to do that!” because you may very, very well be qualified.)

The General Definition of Wireframe, Mock-Up, or User Interface Prototype

Let’s look at the collection of activities that might be considered relevant to anyone using prototype, wireframe, mock-ups, visual renderings, or any other variation on these terms.

In short, any of these visual renderings is a representation of a graphical user interface (GUI), or any interface that allows a user to interact with a device using images and clicks rather text commands.

• This web page and any other you might browse is a GUI and so are the apps you download to your iPhone.
• The TV programming screen where we select the recorded Jimmy Fallon episode with the highest potential to make us laugh is a GUI.
• If your organization has a proprietary software system, whether it’s web based or deployed on employees’ desktops, it probably has a GUI.

As a quick aside, I once worked for a company that called their internal system simply the “GUI”. As they replaced a phone based information management system, their consultants told them they were building a GUI and the application never got a more specific name. GUIs are everywhere. But I digress.

Let’s get back to the visual representation of the GUI, because that’s the part you might work on as a business analyst. The representation can include one or more screens or pages, show the navigational elements on each page, and sometimes show the navigation between pages.

We cover this in more detail in The Business Analyst Blueprint® certification program, where you can earn your Applied Certification in Business Analysis.

What a Mock-Up or Wireframe Typically Looks Like

For example, here’s a visual rendering I created for Bridging the Gap.

(This type of rendering is closest to what would typically be called a mock-up or wireframe, because it’s low fidelity, and I would typically create one to accompany a use case. It was created with a tool called Balsamiq which is available for less than $100. The tool is much more powerful than what you see here. If I had invested more time, I could have made this look a heck of a lot better. But I tend to take shortcuts when wireframing so that I don’t get bogged down in the process.)

What a Higher Fidelity Visual Rendering, or Prototype, Looks Like

And here’s an example of what a designer created to turn this conceptual rendering into a higher fidelity visual rendering.

Starting to look a bit more beautiful, eh?

(This type of visual model is close to what would typically be called a rendering, because it is showing the exact intended look or what’s called high fidelity. And because my designer chose to create this rendering in a web framework, it is actually more like what would most commonly be called a prototype, because I could click around and get the experience of the new website, just like I could hold a plastic pen in my hand and pretend to write.)

Let’s talk a little bit more about prototypes, shall we?

In general, like the WordPress prototype my designer created for Bridging the Gap, a prototype is functional in nature. And that means your user can actually click things and have something reasonable pop up as a result, which helps them provide a great amount of feedback in the elicitation process. (I’m expecting that any day now my designer will stop being so gracious about my feedback and adjustments!)

Without any coding knowledge, I’ve created similar, albeit less visually pleasing prototypes (again, I love those shortcuts), using a tool called Axure.

Here’s an example of a a pretty ugly prototype that ended up being the a really, really old home page here at Bridging the Gap. (This is a screen shot from a click-through prototype created in Axure – those yellow icons indicate clickable buttons.)

Have You Created Wireframes, Mock-Ups, or Prototypes?

If you’ve ever created anything along the lines of what you see above – or significantly less beautiful (such as a hand-drawing or whiteboard drawing) or significantly more beautiful (such as a rendering created in Photoshop) or significantly more functional (such as working code that was intended for a demonstration), you have relevant experience in this area of business analysis.

At the end of the day, it’s not about the technology you used. What “counts” as relevant experience is the putting something visual and tentative in front of people who will actually use the finished product and getting their feedback.

Essentially, you allow your users to hold a plastic pen. Now I’m going to head back to watching the next promising Jimmy Fallon episode.

How to Learn More About Wireframes (and so much more…)

If you are looking to gain more confidence in wireframes, along with the other foundational skill sets that are key to success as a business analyst, check out  The Business Analyst Blueprint® certification program.

Will the next track be by an epic rock legend, or will it be a remix of some trashy 90’s pop song?

The mystery is part of the fun!

After hitting the “shuffle” button this morning I was rewarded with the excellent 80’s track, “Atomic” by Blondie.  In a moment of lateral thinking, this 80’s new-wave song prompted me to think about requirements, and specifically about requirements quality.

Let me explain…

Good quality requirements have a number of characteristics.  Many authors have produced guidance around requirements quality, and as an example, the BABOK guide suggests good requirements should be:

• Cohesive
• Complete
• Consistent
• Correct
• Feasible
• Modifiable
• Unambiguous
• Testable

(See “A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) BABOK v2.0”, sec 6.5.4)

As part of cohesiveness, BABOK states:

“A cohesive set of requirements relates to only one thing,” 

I would extend this definition and say that each individual requirement  within the set should relate to one and only one thing. Or, put another way, each requirement should be atomic.  This is of relevance to detailed textural requirement artefacts – for example, declarative requirement statements (“The system shall…” or “A user can…”) or textural business rules.  It wouldn’t normally apply to a model or a high level scoping statement.

The Importance of Atomic Requirements

If you are using declarative requirement statements or similar artefacts, there are several advantages to ensuring each requirement is expressed atomically.  One of the most significant advantages is it helps to avoid prioritisation anomalies.  When several requirements masquerade as one, it makes prioritisation difficult.  For example, imagine a requirement was stated as:

“A user must be able to add, edit and delete a new customer record”

This is actually several requirements bundled into one.  Perhaps the most important priority is to add (create) the record.  Edit might be important, but not critical for day 1 (perhaps it could wait for a second release, depending on the nature of the system).  It might be possible to defer the “delete” function even further. This level of prioritisation can only happen if the requirements are split out.  Otherwise, it’s likely the whole requirement will be seen as a “critical” day one requirement, even though elements of it could wait.

Muddled and combined requirements also create issues with traceability.  What if a different person “owns” each part of the combined requirement above? It would be difficult to show this relationship.  Equally, showing relationships and dependencies between requirements becomes more difficult, as it isn’t clear which part of the requirement has the dependency.  Muddling requirements makes requirements analysis and requirements management more difficult and causes problems further down the project lifecycle.

So, when you’re using declarative requirement statements, think “atomic” as well as “cohesive”!

>>Improve Your Requirements Writing Skills

When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

>> Click here for more information about The Blueprint <<

In what follows, I’ll share my tested shortcuts for creating wireframes, which I normally create right alongside use cases. These shortcuts ensure wireframes remain a productive part of the business analysis process and not a distraction for me or my stakeholders.

(Wireframes happen to be just one of many visual models created by business analysts. For a more comprehensive list, click here to read about 22 visual models used by BAs.)

#1 – Limit the Scope of the Wireframes

Software applications can be big. Does your wireframe need to capture every piece of functionality? Not hardly.

Most projects are updates to existing functionality. In this case, I focus only on what’s changing and not so much on what exists today and is not changing. This cuts down tremendously on the amount of prototyping work you need to do and helps focus your reviews.

For a new software application, I focus on wireframing core functionality that helps my stakeholders get the intent behind the application. And if we are using an iterative requirements / development process, often by the time I get further into the requirements, I’m able to grab screen shots from the development environment that makes the wireframing process much easier, which leads me to my next point.

Rule of Thumb: Focus on getting a few scenarios right in your wireframes. You can easily expend a lot of effort prototyping out multiple scenarios or flows through an application. Focus on the primary scenarios. It’s OK to talk users through some of the alternate paths or add textual notes describing what will be different for a less frequently used scenario.

#2 – Re-Use Existing Elements in Your Wireframe

To save time on recreating existing screens, I use screen shots to capture the existing application. (In the absence of an existing site, I’ll copy and paste elements from applications with similar functionality.)

I copy the screen shot into paint, capture the relevant pieces, and copy them as a starting point for my new or edited screen. This can work even if you need to edit significant portions of the screen. Most prototyping tools have widgets that allow you to overlay a box on an image and color the background to closely match the original capture.

Rule of Thumb: Stay focused on the value the wireframes are driving in the conversation. Are they helping people see the requirements in reality and ask good questions? Are they helping you drive alignment and understanding? Are they helping reduce confusion?

#3 – Keep the Wireframe Low-Fidelity

For new applications, I stick to low-fidelity, exploratory prototypes in the early stages. Low fidelity means no colors, no images, and little bother with navigational elements. I keep the wireframes focused on fleshing out the work-flow requirements and functionality. This makes them easy to evolve as the team’s understanding of the application grows.

For existing applications, I’ll grab the UI template from the existing site in my screen shots, but otherwise keep new features in the default fonts and colors provided by the prototyping tool.

Rule of Thumb: If a feeling of dread comes over, you are working too hard. When a business stakeholder asks for a change and your stomach drops, then you are either using the wrong tool or have invested too much in a high fidelity prototype too early. The wireframing process is an enabler to elicitation, analysis and validation; never let it be a deterrent to getting the requirements right.

Learn to Create Wireframes

Looking to incorporate wireframes on your next project? Want to learn how to blend wireframes with use cases to create a package of requirements that helps everything gel?

Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

Click here to learn more about Use Cases and Wireframes

Are you confident in your ability to create formal requirements specifications just like a tried and true business analyst would?

Let’s look at how business analysts approach requirements specifications, what a hiring manager is looking for when they ask for experience with specific templates, and how to determine what your real capabilities are in creating requirements specifications.

How BAs Approach Requirements Specifications

If you begin to look at formal templates and BA methodologies, this can quickly become overwhelming. Sure, there are some big templates out there and you can find formal work samples well in excess of 50 pages, but the reality is that the best business analysts, in my not-so-humble opinion, create documentation that meets the need at hand, even if that means it doesn’t look very formal.

Yes, they might leverage their own repository of templates as a starting point or a checklist of questions to ensure the document is of high quality, but they realize the structure itself is not as important as the usefulness of the document in the context of the project and the stakeholder group. At their best, templates and checklists provide a structure that give you a starting point and can help improve your analysis processes.

Let’s look at some interesting examples that blend a user focus with just enough structure to be useful.

• Tony Heap gives us an example of a graphical functional specification that combines anything-goes diagrams with context diagrams and graphical use cases.
• I share my experience creating a user interface specification to document visual requirements as well as the various ways I’ve used use cases, even if it meant combining the “what” and the “how”.
• And here, Adriana Beal shares how she has used a wiki to manage requirements.

In each of these cases above, the business analyst has leveraged pieces of what you might find in a formal template and presented the information in such a way that it is easier for their stakeholder audience to consume, approve, and use.

What Are Hiring Managers Looking For?

While all of this can be true, what do you make of the job qualifications that speak to BRDs (Business Requirements Documents), SRSs (Software Requirements Specifications), Scope Documents, Vision Documents, Product Backlogs, User Stories, Business Process Models, etc.?

Well, before providing an answer, let’s do a little analysis of what a hiring manager might be looking for when they add such a qualification to their job description.

• They need someone who can package the requirements in a usable way (and their understanding of usable might mean by using a specific template).
• They need someone who can write requirements clearly and using unambiguous language.
• They need someone who can elicit the information and analyze the requirements so that the specification can be created in the first place.

Your skills in creating informal documentation, if it’s clear documentation that was usable by stakeholders and served a project need, satisfies the lion share of these requirements. Your skills eliciting and analyzing requirements at the level required by the requested requirements specification (business or process-related requirements for a BRD, scope document, or business process model, and functional requirements for an SRS, Use Case, or functional work-flow), will also be critical. The template or package is secondary.

But how do I convince a hiring manager of this, you ask? Well, let’s get to that next.

How Do I Determine My Requirements Specifications Capabilities?

You still need to be able to speak authoritatively as to how your documentation experience relates to what you will do in a business analyst role and specifically to the business analyst skills required by a job you might be interviewing for. Luckily, there is a simple way to cultivate this understanding so you can present yourself as capable of doing similar specifications.

Here’s my suggestion.

1. Download some “standard” templates. (My Business Analyst Template Toolkit is a good starting place.)
2. Go back to your old documentation. Remember what problem you were trying to solve in the first place and the context in which this deliverable fit into the project.
3. Rework your documentation using a more standard template. Make sure you leverage the new template to solve that same problem – this might mean consciously removing a specific section or adding a new one. You’ll be working here as a BA would do, not mindlessly copying and pasting information into a template, but making conscious decisions about how to best present information to your stakeholder group.

After completing this exercise, you should be confident that you could create a new deliverable in the standard format if required. You will also have a work sample you can present in a business analyst job interview. If you are not completely confident after going through this process, ask a senior BA to review your work and provide concrete feedback for how to leverage the template and communicate information to your stakeholder audience. And don’t forget to update your resume. Use that BA terminology to describe what you did on that past project. Because, hey, you just proved you could do it.

Build Your Documentation Skills

For help applying the standard structures to make your documentation more formal or, just as important, improving the language you use in specifications so that it’s clear and unambiguous and solves the problem at hand, we do have some courses that can help. Business Process Analysis and Use Cases and Wireframes would be good choices. Each provides templates you can use to structure your documentation, work samples you can review, and include instructor feedback on your deliverables.

(Before I forget, be sure to download our free business process template, which incorporates a host of best practices when it comes to process modeling.)

1 – Identify Your Start Point and End Point

In all likelihood, you’ve got a name for your process. Perhaps it’s “Process Monthly Reports” or “Release New Software Changes.” Names begin to narrow our focus, but they tend to be ambiguous. You get stuck because you don’t really know what’s included and what’s not.

In addition to a process name, identify the discrete starting point and ending point of your process. Now every activity that comes to mind will clearly fit in scope of the process you are capturing or fall outside that start/end point boundary and can be safely captured for another process to be documented on another day.

2 – Work on Paper First

Yes, we live in a digital age and yes it’s very likely that your process will eventually need to make it into electronic form. But that doesn’t mean it needs to start in electronic form. While it can feel like an extra step to draw things out on paper and then to capture it electronically, this practice can save you time.  The simplicity of pen and paper as a tool allows you to focus all of your mental energies on what matters – capturing the key elements of the process and how they relate to one another.

3 – Know Your Audience

Not all process documentation is created for the same reason. You might need approval from an executive team, input from those who will use the process, or validation from those who will support it. If you are stuck, it might be because you don’t know who your audience is or because you are trying to use one document to meet the needs of several stakeholders.

Clarify your audience and their expectations and often the most appropriate level of abstraction will become self-apparent. Which leads us to the next practice.

4 – Keep It High-Level

In our Business Process Analysis course, the biggest mistake I see people make is to dig into the details too quickly. Once you are in the details of the process, more often including the step-by-step procedural tasks, it’s difficult to step back and see the big picture.

Instead, start high-level. Confine yourself to one page or 5-7 workflow boxes. When your thinking exceeds these artificial constraints, look for ways to abstract the information you are putting into your model by combining boxes or streamlining parts of the flow. Identify workflow elements that can be further defined by their own sub-processes.

Keeping it simple takes disciplined thinking and it doesn’t mean you’ll never get to the detailed analysis. It means you’ll be sure to understand the big picture process first before digging into the details, and be less likely to get stuck when you do elaborate on those details.

5 – Let Go of Perfect Expectations and Expect to Iterate

Another reason we get stuck is because we don’t just want to document a business process, we want to document a process perfectly. If you are using a new technique or learning a new domain, that’s an unrealistic expectation. Instead, expect to iterate and improve your documentation with feedback from your stakeholders.

This does require that you develop a healthy sense of separation from yourself and your work. Consider Adriana Beal’s advice left in recent post comment:

I recommend using strategic wording to prevent criticism from getting to you:

“Hi, everyone! I realize it’s too soon for us to be able to capture with any level of precision what sort of business process we need, but just to jump start the conversation, please find attached a very early draft of a process flow. Any feedback is very welcome, you can either send it by email before our next meeting, or provide your recommendations during our next requirements session. Thanks!”

Alternatively, seeking out a trusted mentor or a particularly kind stakeholder to provide a first pass review can help you iterate privately before you share your work publicly.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project.

Click here to download your free business process template today

In the BABOK Guide, the purpose of Requirements Validation is defined as follows:

Ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need.

It’s Easy to Conflate Validation and Verification

Many BAs, myself included, conflate requirements verification and validation. (Here’s a challenge: Read the comments on the Requirements Verification post and see if you can find evidence of validation instead. And be nice. We’re all learning here.)

It wasn’t until I was deep in my preparation for the CBAP exam that the difference finally sunk in. And still, in reality, the activities of validation and verification are often done together. We might hold a requirements review and in the process discover ambiguous requirements (verification) and unneeded ones (validation).

In fact, very often I’ve found that an ambiguous requirement is ambiguous because the business value is unclear. We might start debating the semantics of a term and discover we’re solving the wrong problem and end up throwing out the requirement completely.

In my early days as a business analyst, my requirements verification and validation activities happened together, in a big room or an over-crowded small room with business and technical stakeholders walking through a draft of the requirements specification…

r e q u i r e m e n t

…….

by

……..

r e q u i r e m e n t.

But as I reflect more deeply on my requirements validation experience, walk-throughs, while the obvious candidates, don’t make up the half of it.

If You Are Doing It Right, Validation Happens Early, And It Happens Often

Before we even had a draft specification, I was meeting with the primary business stakeholder to iterate through potential requirements, understand the business value and fit them together in a logical way. I was clearly, but unknowingly, doing validation. The BABOK recognizes this too. It says:

Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements.

So in those early meetings with the sponsor, I was ensuring the alignment of stakeholder requirements and business requirements. In the detailed meetings with the entire stakeholder team, I was ensuring alignment of solution requirements and business requirements.

But since those early days, most of which involved big thick requirements documents and (yes, and) detailed use case specifications (oh, my, the documentation to validate and verify!), I’ve developed some much more nimble requirements validation practices.

Here Are Some Nimble Ways to Approach Requirements Validation

• With one particular client, I used a series of click-through wireframes to walk my stakeholders step-by-step through the requirements.  I subsequently documented the textual requirements in user story format for the technical stakeholders. This required a lot of ownership – I was primarily responsible for ensuring the stated requirements specifications reflected the business needs and requirements – but it worked amazingly well for this stakeholder group. And that’s requirements validation.

• Another nimble example goes into the way back machine… way back before I was a BA. As a QA engineer, I was responsible for pulling together bug reports and a recommended priority of addressing each fix. What I was really doing was aligning all of these “change requests” to the original business case for the project and sorting them by the value that fixing them would have to the end user.  And that’s requirements validation.

• While new to an agile software environment and creating a product backlog, I immediately saw the value of the “value” statement that gets embedded right into the user story syntax: “As a {user}, I want do {do something} so that {perceived benefit}. Right there in that third part? That’s the business value. Instead of manually tracing functional requirements to business requirements and potentially overlooking the actual contextual connection, the syntax forces you to contextualize the business value into each and every requirement you write. And that’s requirements validation.

Requirements validation is a critical activity. And while sign-off is often thought of as the tried-and-true way to validate requirements, the reality is that every question you ask to ensure the completeness of your requirements and their link back to the business need is part of requirements validation.

This post is one installment in our Journey Through the BABOK with BA Stories series.

>>Learn How to Ask the Right Questions During Validation

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

The purpose of Verify Requirements is to:

“Ensure that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.” (114)

The BABOK lists 8 characteristics of requirements quality:

• Cohesive
• Complete
• Consistent
• Correct
• Feasible
• Modifiable
• Unambiguous
• Testable

There are three types of requirements verification I’ve performed as a business analyst.

1. Verified my own requirements.
2. Verified others’ requirements (on a shared project).
3. Verified requirements for a mentee or coaching client.

Let’s take a quick look at each type of work.

Verifying My Own Requirements

I’ve never sent out a document I haven’t gut-checked against the quality standards I knew about at the time. And, really, producing verified requirements is the baseline of skill required to be a good business analyst. If your requirements are full of inconsistencies and ambiguities, it doesn’t matter how good you are at using elicitation techniques or communicating about the requirements.

For me, this kind of verification means I read and re-read my requirements, looking for items that don’t match up, terms that are used inconsistently, or requirements that will not be clearly understood. It also means that I’ve done some analysis, looking for holes that would indicate the requirements are incomplete.

For example, if I’ve included a requirement to edit a set of information, do I have a requirement to create that information? Do I need a requirement to delete it as well?

Regardless, I’ve had stakeholders, especially testers (we love them, don’t we!) find new holes, inconsistencies and ambiguities. I’m not as perfect as I’d like to be!

Verifying Other’s Requirements

In my very first BA role, I initiated a BA team meeting where we each took turns presenting our requirements to the other BAs on the team. We were a young and relatively immature team in the sense that we were all applying slightly different standards of quality to our requirements documentation. We also didn’t have any specific bar for what “quality requirements” meant. So by reviewing each others’ specs we gradually aligned our practices and became more consistent across projects.

But even before I became a BA, I participated in requirements verification. One of the quality characteristics is “testable” and as a QA engineer I would review requirements to ensure I had the information I needed to test them appropriately and ensure the requirements were met. Often this feedback was provided during document review sessions or collaborative design sessions.

Verifying Requirements for a Mentee or Coaching Client

Finally, I’ve verified a mentee’s requirements specifications. From a BA career perspective, this was a watershed moment for me, when I realized that I could assess the quality of a requirements specification without having much context for the business domain or the project. It’s actually quite amazing what you can find. Inconsistencies stick out like a sore thumb when you don’t understand the business language and I am finding more ambiguities because of my outsiders’ perspective. This is also a feature of our virtual, instructor-led courses, which all include documentation reviews.

This post is one installment in our Journey Through the BABOK with BA Stories series.

If so, look no further than the “Allocate Requirements” knowledge area of the BABOK.

Allocating Requirements is a task that is done by someone, and if it’s not done by the BA, we might be missing an opportunity to create more value for our customers. So, yes, BAs no doubt have a role in aspects of the solution design.

The purpose of Allocate Requirements is:

“Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team.”

To read the first part of this sentence you’d think the BABOK has us bleeding into project management activities! Urgh! But if you finish through to the end, you’ll find this is not so. The real underlying purpose of this task, like so many in business analysis, is to maximize business value.

How I understand it, this task can happen at multiple levels. And I have examples from my career at varying levels of granularity. During use case review meetings, we would decide what requirements would be implemented in what technical solution component – there were 3 or 4 main components and each had a different technical owner. To finalize the requirements (for feasibility) we’d need to have representatives from each technical component involved in the decision-making and design process. As the BA, I was again in a bit of a watch cop role, ensuring each requirement was fulfilled through the design. Sometimes I’d also discover areas where we could enhance the solution a bit without increasing technical scope – is it just as easy to implement with an extra field because the stakeholder mentioned that would be useful, but not necessary? If yes, that extra requirement was slid in – more benefits, same cost.

On the completely opposite scale, while I was working on one variation of the plan to implement the consolidated system for 5 independent companies, I was largely responsible for allocating high-level solution requirements amongst various projects and releases of the new system. This involved an understanding of inter-dependencies within the system as well as what requirements were most likely to deliver the most value first to the business. (Even at the time I remember thinking this was more of a PM task, not realizing it was truly a BA task until preparing for my CBAP).

In the middle, where I’d expect most BAs have some experience, is in the negotiation between whether to allocate a requirement to a business process or a technical solution. As we explore the value of building a specific technology feature vs. creating a business process to deliver a specific business capability, we’re allocating requirements based on business value.

For example, as a consequence of web-enabling several features for our customers on one project, we needed to build new internal capabilities. We looked at these capabilities carefully, explored the potential solutions, and then decided what aspects of the capability to automate vs. keep manual. In many cases, the manual process was preferable for a variety of reasons, so this allowed us to keep our technology support for the internal process very simple, while still achieving the business goals of the process.

This post is one installment in our Journey Through the BABOK with BA Stories series.

According to the BABOK, the purpose of Prepare Requirements Package is:

“To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups.”

And the BABOK goes on to further articulate why this is important.

“Requirements should be presented in formats that are understandable by the stakeholder. This task describes the work required to decide which format(s) are appropriate for a particular project and its stakeholders. They must be clear, concise, accurate, and at the appropriate level of detail. Requirements documentation should be created only to the extent needed to ensure clear understanding by the team.”

I think this is a powerful task because it clearly separates the elicitation and analysis of requirements from the creation of a package to communicate requirements. This is essentially saying that discovering the requirements is not the end-all-be-all of business analysis. We must also invest the effort in creating packages that support our stakeholders in understanding those requirements.

And these packages are not necessarily documents. They can also be presentations or visual models.

It’s difficult to think about a project where I didn’t create a requirements package of some sort. And they have ranged significantly from a collection of nicely formatted wiki pages to slide decks presented to the board of directors to formal documentation (aka big thick requirements documents) reviewed by a large cross-functional stakeholder group. As I matured as a BA, this is one area that I found myself experimenting with, always looking for a simpler and easier way to communicate the essence of the requirements to inform a particular decision or follow-up task.

One example I’m especially proud of is a one page epic I created to scope a significant feature to be developed using agile. On one page I captured the business rationale for the feature, key stakeholders, essential business requirements, constraints, risks, and unknowns. It was easy to review and validate, and a great touchstone for elaborating the requirements into a product backlog and user stories.

Just like the perfect birthday or holiday gift starts with understanding what the person really wants, the perfect requirements package starts with understanding what your stakeholders really need and how they will best understand it.

This post is one installment in our Journey Through the BABOK with BA Stories series.

However, in the midst of eliciting, analyzing, and specifying requirements, there is a context at play. One of these contexts is the business need. Another two elements are much more pliable – those are the assumptions and constraints. Most requirements deliverables have a special place for these little pieces of information. And in most of the specifications I’ve evaluated, the BAs do a poor job of articulating the assumptions and constraints and an especially poor job of communicating how these factors impact the project or the requirements.

What are Assumptions and Constraints?

Let’s look at how the BABOK defines this business analysis task. The purpose of Define Assumptions and Constraints is to:

Identify factors other than requirements that may affect which solutions are viable.

Assumptions are factors believed to be true, but not confirmed. Constraints can be business or technical in nature and are defined as restrictions or limitations on possible solutions. The project budget, time restrictions, and technical architecture decisions are all examples of constraints.

Like requirements, assumptions and constraints are not just sitting on trees and bushes ready to be “gathered up.” In fact, while they may be much more easily communicated by our stakeholders than requirements, they are more than often invalid. The BABOK gives us these two statements to build on.

Assumptions may reflect an understanding of how desired outcomes are likely to be achieved. For instance, stakeholders may believe that customers will respond in a certain way to a change in how a product is delivered, but there may only be anecdotal evidence to support that belief (112).

Constraints should be carefully examined to ensure they are accurate and justified (112).

What Should We Do With Assumptions and Constraints?

It’s easy to say, “the budget is XYZ” or “we can’t change that part of the system,” just like it’s easy to say, “all requirements are top priorities.” But this doesn’t really get us anywhere as a project team that needs to make intelligent and informed decisions based on relevant information.

So it comes back to understanding why an assumption is held or a constraint is limiting the solution, and perhaps digging deeper back into the factors really driving the project.

The Crux of the Matter

In essence, assumptions and constraints are not really managed the way requirements are managed. Requirements represent capabilities the solution must have. Assumptions and constraints are fuzzier: they impact the creative process. They are easily forgotten or overlooked. They crop up on us in the 11^th hour, invalidating numerous decisions about the solution, throwing project schedules and budgets out the window, and causing general distress.

In my first BA role, there was one sub-system that was particularly challenging to update because it was used by every one of the 30+ products supported by the IT team. If your project required an update to this sub-system, then you had to wait for a release which required extensive regression testing, your schedule became tied to other otherwise unrelated projects, and your budget and resources took a steep climb up. Almost every requirements document started with a constraint saying changes to this sub-system would not be required for this project. But at the level of the business requirements, we often had no idea if we could meet our business need within this constraint. Sometimes a particular requirement was questionable, and in this case we’d add a risk that we might not be able to adhere to the constraint. But we really didn’t do anything productive with that information early in the project.

It wasn’t until we were exploring the nuances of specific functional requirements and how they would be designed technically, that we’d discover with certainty whether or not this sub-system would not support the requirements. Then, when the constraint was tested, we’d discover how important the requirement really was to the project and whether the sponsor was ready to take on the increased risk, technical scope, and scheduling constraints to obtain the requirement.

This example from my career history shows that it’s not enough to just to say, “here’s a constraint.” Our solution approach and solution requirements must actively take that constraint into account. And each of these activities, more than being constrained by the constraint, will actually test the validity of the constraint.

Reader 1: As rules are mostly hardcoded and code walkthrough is too time consuming in mainframe systems, what is the best way to extract business rules from legacy systems without using the tools?

Reader 2: In most modern systems, business and processing logic/rules are defined in a separate Business Rule engine; but in Legacy systems it’s the other way as their logic and rules are hard coded or defined in the code itself. So how does a BA who is suppose to work on a legacy modernization project gather the requirements for these rules and logic as he can’t go and see the code and then understand?

Aaron’s reply:

These questions come quite timely as I have just completed a legacy modernization project for one client and have begun another one for a new client.  The one thing I believe is that there is no substitute for the code walkthrough.  The first reader doesn’t want to take the time to do a code walkthrough, but if you want absolute correct requirements, and business rules you must go through the code walkthrough.  Now, I am not saying it has to be a formal code walkthrough nor have several people involved.  The more people you have involved, the more correct your requirements and business rules are apt to be.  The fewer people you have involved to faster the process is likely to go.  I am not sure what tools Reader 1 is referring to, but I am not aware of any tool that can read legacy code and extract business rules; that will take a trained human being.

I actually suggest a two prong approach to legacy modernization projects; technical and functional.  The technical is the code review/walkthrough.  Have a Developer/Analyst, or a team, walkthrough the code and extract the business rules from the code.  The second prong, functional, is having a Business Analyst (BA) interview the business people who interact with system under investigation and extract the functional rules from them.  The business people who use the system every day know how the system acts.  They know the “quirky” things that the system does.  The BA should observe the business people interacting with the system, which could lead to more questions about the system.

The BA and Developer/Analyst can confirm with each other what they learn about the system.  As a Developer who has transitioned into a BA role, I performed both the functional and technical reviews of a legacy ERP system for a client, to draw out the business rules and functional requirements of the system, as the company was preparing to replace their ERP package.

While interviewing and observing the Order Entry business people of the company, I learned that during order entry they would type the word “USUAL” in the ship via on the order.  The system would see that, go to the Preferred Carrier table for that customer and retrieve the name of their preferred carrier and replace “USUAL” on the order with that carrier’s name.  The Order, Invoice, Bill of Lading and other documents would print with the actual carrier’s name.  Being the technical person on the project, I was able to confirm this during the code review, and see exactly how the system went about accomplishing that task.  If I were not the technical person on the project, I would compare business rules with the Developer/Analyst and see if he/she found the “ship via replacement” rule of the Order Entry system.  If it was not listed in their rules, I would ask them to confirm the rule as I received it from the Order Entry business people.

So you have two take-aways from this:

1) Like it or not, there is no substitute for a code walkthrough/review to help ensure you get the business rules correct.

2) Take a two prong approach to legacy modernization projects; technical and functional.

>> Learn to Ask the Right Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

I read an article today from our respected colleague, Yaaqub Mohamed about the importance of data analysis as part of a good analyst’s tool belt. Well that is not exactly how he put it, but you get the gist.

Anyhow, it got me to thinking about another type of data that often goes unnoticed until it is far too late to even say, “Oops!” Yes, yes I’m speaking of nomenclature and that involves the identification of terminology and the definitions and aliases used to capture meaning.

It doesn’t seem all that important, but it can be as dangerous as a missed stakeholder with a bad attitude and political agenda if not properly handled. Allow me to paint you a scenario to consider.

I work for an organization that started with one division and it ended up buying three more along the way. We all do the same thing, but we do it in different states under different legal guidelines and the like. Each division had been in business for a number of years prior to being merged with the others. So, it stands to reason that each division’s employees does things a little differently while achieving the same goal. Along with that, each division refers to the same entities by a different name. Imagine trying to build an enterprise application with this standing in the way. I cannot begin to tell you how interesting the JADs are before we realize that there are either four names for the same thing or one definition applied to four disparate terms.

It would seem that a glossary would cover the issue and we could move on with our lives, but that requires people to read it. When was the last time you took the time to look up a word that you didn’t understand? The real issue rears up with usage, context and general comprehension during conversation. Most of the time we can figure out context while holding conversations and can even pick up an accurate meaning periodically.

However, when there are 30-40 people arguing about things while using often very similar, yet still completely different terms, the last thing that people seem to do is whip out their trusty glossary. Most of us go with the flow, so we don’t appear stupid, and that is about the stupidest thing we could do. If terminology is not clearly and consistently understood, there is a huge margin for error in the solutions that you as analyst recommend to your audience. If there is more than one audience and they aren’t on the same page, then guess what happens? Yup! Think about the error conditions of implementing business rules if there is not clear terminology for governing the entities of the organization. Migrate those problems into code and you have real issues.

The analyst has a grandstand seat to watch these struggles in order to understand trends between stakeholders, and plays an important role in bringing people together to talk and listen to one another in order to find common ground in terminology. Failure to do so can lead to costly, yet surprisingly simple errors. Here are a few things you can do…

• Identify your terms. As you take notes and write documentation, pick out the domain terms that are repeated or singled out as words that have meaning to your stakeholders….especially those that can have multiple meanings.
• Make a simple glossary a mandatory part of your documentation. Even if everyone speaks the same language (meaning dialect) and calls an orange an orange….your writing will capture that fact. Eventually, someone will be hired who refers to an orange as a lemon and you will have the baseline established.
• Ask if you don’t know what something means! If anyone is going to ask stupid questions, it better be you functioning as an analyst. That is why you are there…and don’t forget that! We ask the questions that people having been avoiding for years while they were trying to look smart. Why do you think they need analysts now?
• Validate your terms and definitions against the business rules, whether in text or code.
• Validate your terms and definitions with ALL stakeholders.
• Define all known aliases to bring mindsets and conversation together.

In summary, take a little time to make your life and that of your stakeholders and developers by calling out variations in the words you hear used to describe the domain that you are working in. Take ownership of controlling this knowledge, and put it to use as a part of your project. You will not believe all the use a good set of terms can have, not the number of times others tell you how great it would have been if they had it previously.

If you are a BA working on the IT space, you may be responsible for creating multiple deliverables, many of them intermediate documents such as meeting minutes and as-is/to be business models. You may also be in charge of producing important and high-visibility requirements specifications such as a Vision document describing the application in general terms (including, for example, descriptions of the target market, system users, and the application features), or Business Requirements Document (BRD), describing, at a high level of abstraction, the business needs.

Regardless of how many artifacts you produce in a project, unless you are working on a pure agile environment, the Software Requirements Specification (SRS, sometimes called functional specification, product specification, system specification, or requirements document) will be the most valuable document you will produce during the course of many of your projects. Practicing and improving this skill is something I help analysts do in my course Crafting Better Requirements. What follows is a synopsis of what a software requirements specification is and why it’s a valuable skill.

What is a Software Requirements Specification?

As the name says, the SRS is the specification for a particular software product (or for a specific release, module or component of such product). A Software Requirements Specification must describe all the capabilities a product must have in order to fulfill the business, stakeholder and user needs. It defines the inputs, outputs, functions, and attributes of the system, as well as the attributes of the system environment. According to the IEEE Guide to Software Requirements Specifications, a good software requirements specification leaves out design, verification, and project management details (except for required design constraints), in order to provide the design and development team with maximum flexibility to arrive at the best technical solution that can fulfill the stated needs.

What is the Software Requirements Specification used for?

The Software Requirements Specification is such an important piece of software documentation that it is sometimes produced even after the software product has been designed or developed, to serve as a reference for testing and to address the needs of the operations and maintenance teams.

Besides establishing a clear agreement between supplier and customer on what the completed software must do, a Software Requirement Specification provides crucial information that the Quality Assurance team needs to create test plans that will verify whether the system is indeed fit for purpose. It also offers valuable information for the operations and maintenance teams–for example, an indication of when a software component may be retired because it only supported a temporary need, or which modules or functions of the system are particularly critical for the business, and consequently must be monitored and protected against failure to prevent financial loss or other negative impacts.

A Specification is Not Supposed to Replace Conversations

Clearly, even the finest Software Requirements Specification document will never replace interpersonal discussions that will need to happen throughout the project. It is virtually impossible to discover–and document–every single fragment of information that feeds into software development upfront. A considerable part of the job of an IT analyst is to keep the lines of communication open between the technical and business teams, so that issues that may surface during the project, trade-offs that must be discussed, and requirements details that may have been overlooked can be addressed in a timely and effective manner.

Anyone in IT Will Be Valued for SRS-Writing Skills

In “Testing SAP R/3: a manager’s step-by-step guide”, authors Jose Fajardo and Elfriede Dustin define quality in the context of a software product as:

a system that performs as expected, making available the required system features in a consistent fashion, demonstrating high availability under any type of constraint (i.e., stress, concurrency, security breach, etc.); thus, consistently meeting the user’s expectations and satisfying the system’s user needs can be considered to be high quality.

Undoubtedly, a software product will have a much higher probability to meet users and business expectations if there is a solid reference from which the development team can work and which addresses all relevant aspects of the solution, from the sources of inputs, to performance and external interface requirements. Analysts with the ability to document functional and non-functional requirements that carefully trace back to business requirements and provide a solid foundation for the design and development team to build a solution that achieves the organization’s goals are hard to find, and such skills generate career progression opportunities for analysts who demonstrate talent in this area.

Even when you progress in your career to a position in which is no longer your responsibility to write requirements specifications, your ability to inspect requirements documents to determine their quality will be instrumental for ensuring that the development team has the appropriate input for their work.

If you are interested in developing skills in this area, a good starting point is to dissect Software Requirements Specifications written by talented authors such as Karl Wiegers, read high quality books such as Software Requirements, Third Edition (Pro-Best Practices), keep valuable references to consult during your projects, such as The Software Requirements Memory Jogger: A Pocket Guide to Help Software And Business Teams Develop And Manage Requirements (Memory Jogger), and most importantly, practice, practice, practice.

As well put by Karl Wiegers in his book More About Software Requirements: Thorny Issues and Practical Advice,

You won’t learn how to write good requirements from reading a book on software requirements engineering or a book on technical writing. You need practice. Write requirements to the best of your ability, and then enlist some of your colleagues to review them. Constructive feedback from reviewers can help anyone become a better writer. In fact, it’s essential. Requirements quality is in the eye of the reader of the requirements, not the author. No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.

The organization I work for is expanding its Business Intelligence capabilities, introducing a new Enterprise Data Warehouse for management reporting. This is based on the concept of OLAP Data Cubes – permitting greater flexibility for user reporting.

My question is – what’s the best approach for eliciting and documenting requirements for BI/Data Cubes? There’s less emphasis on the structure of reports due to the flexibility of the cube, and more emphasis on the definition of the data and the ways in which it can be manipulated. To what degree should I be focusing on the detail of the data? Should I learn about ‘star schemas’ and how to structure the data in ‘dimensions’? Or should I focus more on the business need – on what metrics are required, what the data/reports are to be used for, by who, how frequently etc.

I know that there is never a cookie cutter approach to eliciting and documenting requirements of any kind, but I’d be eager to know of any specific areas I should be covering to ensure that the specification I handover is comprehensive.

Finally, if there are any recommended books on Business Intelligence & BI requirements, I’d be grateful for any suggestions.

Anup’s Answer:

You are asking all the right questions. This reminded me of my first BI project.

My First Business Intelligence Project

The request from the client consisted of an excel sheet with some existing reports that needed some changes. They also wanted some new reports. Since these reports were manually created, they were always concerned about the accuracy of the data. Also the reports were delivered late due to the time taken to generate the reports.

(Click here to learn more about how to collect reporting requirements)

We jumped on it and built the cubes (explained later) and delivered the reports. Everyone was very happy. However, after 3 months; the management wanted new reports and enhancements to existing reports. Though this required substantial changes to the solution, we were able to meet the requirements. However, by the time we delivered these, the management wanted more reports and changes.

This did get us thinking and we got together to figure out a better way of handling the project. By this time, we had understood that requirements for BI solutions had to be handled in a different way. Most of us are used to doing requirements for Transactional systems; i.e. applications that help in day to day operations of the business which are very different from Business Intelligence applications. BI applications leverage the data from the Transactional systems to help management make informed decisions and take calculated risks.

This was a big turning point and led to defining an overall approach for handling BI projects in general. We broke the team into 3 groups which were responsible for OLAP Database, Cubes and Reporting Dashboard. A fourth group was added later to take care of the Data Mining area.

OLAP Team Created the Data Archive

The focus of this group was to create the OLAP (Online Analytical Processing) database from the current OLTP (Online Transaction Processing) database. The key difference between the two is that while OLTP databases are designed to support the day to day functions (transactions); OLAP databases are designed to support analysis of the data. Data is pushed to OLAP databases from OLTP database through the process known as ETL (Extraction, Transformation and Loading). The key responsibility of the team was to define an overall archiving strategy to move data from OLTP DB to OLAP DB so that this data can be used for analysis.

One of the key activities of this team was to identify data elements that can be used for analysis and discard other unnecessary details. For example: We just retained the zip codes of shipping and billing addresses instead of the whole address. Another interesting addition was to have flags to indicate whether these addresses were same or different.

Other activities included performance tuning of this database. Performance tuning of OLAP database is different from OLTP. OLAP databases are generally tuned for bulk inserts and retrieval; while the OLTP databases are tuned for smaller but frequent inserts and updates.

From Business Analysis function perspective, we had data analysts in this team who worked with the management and development team to create the OLAP database. They defined data extraction, standardization and transformation rules to facilitate this process.

Cubes Team Focused on Analyzing Data to Support Reports

In general databases are two dimensional, i.e. rows and columns. Cubes are multi-dimensional databases and store the data with more than two dimensions. Cubes facilitate faster processing of large amount of data. This team focused on developing the cubes that would be used for reporting.

The team started with building dimensions and fact tables. Their key focus was to identify hierarchy for each dimension and how different data elements can be used. The team consumed the OLAP database, and providing feedback to the OLAP team on the changes required. The idea of adding flags for different addresses was one of the inputs from this team. The data analysts on this team defined the dimensions, fact tables and KPIs (Key Performance Indicators) as per the requirements of the management keeping the big picture in mind.

Reporting Dashboard Team Defined Reports and Security

This team worked with the executive team to understand their needs and define requirements. In a way this part of the process was closest to the requirements gathering processes followed for any project. The Business Analysis team here consisted of functional analysts. They defined the reports in detail including report formats and filters. They also detailed the requirements around the delivery and distribution of the reports including security. The team also identified the need for Statistical analysis. This lead to the creation of Data Mining group.

Data Mining Team Leveraged the Data for Business Insights

Data Mining team was added later to the project. This consisted of members focused on applying statistical tools to identify trends and data patterns to provide valuable business insights.

Together, we Defined Supporting Processes to Ensure Success

In addition to identifying the groups, we laid down some other processes. These processes were very instrumental in success of our project.

• Each group worked independently. It was very critical that the OLAP and the Cubes team worked independently and were focused on the bigger picture. Initially they were guiding by the reporting needs which skewed the overall framework.
• Security was a key concern. We were dealing with sensitive and confidential business information that had major repercussions if it landed in wrong hands. The need to understand reports and security together led to the development of the reporting dashboard team which streamlined the delivery of the reports and took care of the security aspects as well.
• One of the key changes was to reset the expectations of the management and other teams. Before, when we received a change request, the teams scrambled to deliver it through the cubes which resulted in a ripple effect of changes across the systems. Now, the reports were delivered from the OLAP database or even OLTP database if they could not be supported from the cubes. Of course, the reports took longer to generate but ensured the overall schema was not compromised. The underlying queries were expected to change as soon as cubes and OLAP databases supported it. To address the performance issue, a feature was developed to deliver the reports through email to the respective managers.

This post lays out about a 20,000 feet view of the entire process of building a BI solution. Depending on your industry and domain, these processes may vary.

>>Learn More About What Questions to Ask

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

It is critical that business process owners be involved with this process and can work with the actual script to validate the requirements.  You as a BA cannot sign off for the business owner – the risk if you do the sign off can be high if a critical requirement was interpreted incorrectly.  The business owner would then have every right to put a halt to any roll out of the process or system.

Currently, I am writing UAT scripts with the business owners for our team.  Three other BAs are writing UAT scripts for this large and complex project.  So how do we keep this fun, keep the motivation high and keep smiles on people’s faces?

I have employed the following tools throughout the process:

1. The rapport I have developed with the business process owners is critical here and I have talked about this before.  The relationships require trust and understanding.
2. Laugh – when you are through a difficult negotiation or a tough patch of scripting – joke!  Make people laugh.  Find a way to inject humour into this tense time.
3. Feed them – lunch is a good start, but snacks are important too.  When you are locked in a room for 5 days from 8 am to 4 pm – treat people as you would want to be treated!  What’s a little sugar or salt to keep people moving forward…
4. Take breaks – my team looked at me in amazement when I forced them to take a 20 minutes break.  We went outside, for a walk, answered some email – whatever worked but we all came back fresh and with less tension in our shoulders.
5. Thank them very much for their ideas along the way, for their contribution at the end of each day, for all that.
6. Have some jokes – email jokes work well – handy to share.  Even the cute ones will work depending on the audience.

For something as serious as UAT scripting – keep it light where you can and you will be successful!

New to Business Analysis?

Learn more about getting started in a business analyst career. Click the link below to sign-up for our free step-by-step BA career planning course:

http://www.bridging-the-gap.com/free-email-course-for-business-analysts/

“How do people go about collecting report requirements from clients and trying their best to reduce overheads whilst still fulfilling the data needs? I know there has been a big drive recently for Green IT and how companies can reduce their carbon footprint, is this a tactic that should be used?

In addition, how are the report lists maintained and captured – do people have a report book template they can provide. I suppose the best way forward is to persuade clients to consolidate and condense their reports, which will reduce complexity.”

Aaron’s reply:

Remember that the Business Analyst (BA) gathers and documents requirements then makes recommendations.  The Stakeholder, or client, is the decision maker.  So “Green IT…is this a tactic that should be used?” That is for the client to decide, based on their business needs.

You ask a multitude of questions within your question, you asked about reduce overhead cost, fulfilling data needs, Green IT, carbon footprint and report lists. You are asking the right questions and considering more than just report contents.  Every good BA will consider all the necessary components and gather requirements from the stakeholders about all the components, not just the contents of the report.

Report Contents

The data fields contained in the report and how it is formatted is where the stakeholders will want to spend their time.  They usually have a good idea of how they want the report to look.  However, stakeholders may not be aware of technology capabilities that can highlight certain data on the report by changing color, bold, or changing the font or size of the text.  The BA should be aware of these capabilities and elicit the requirements around highlighting certain data on the report.

Report Format

Along with content of the information contained in the report, in what format should it be delivered?  Paper reports are no longer the only option.  Some recipients may wish to reformat or resort the data once the report is delivered; Excel spreadsheet makes a good format for these recipients.  When this is not necessary, yet you wish to go Green, PDF format may be a good option.

Underlying Infrastructure

Consider the infrastructure in place when making recommendations on changing the reporting system of the organization.  Making a recommendation that completely changes the infrastructure, or that the current infrastructure can not support usually will meet with great opposition.  Is the client running a Windows or Linux network, IBM midrange or mainframe system?

Report Delivery System

The days of the large data center with 10 printers that look like washing machines that print reports all day and then someone walks throughout the office delivering paper reports are coming to an end.  You may be able to find this still today in very large organizations, but just like the floppy disc, this too will some day be a thing of the past.

Organizations that wish to reduce their paper usage can consider having reports delivered to shared folders on the company’s network or through the company’s email system.  Both PDF and Excel reports can be delivered either way.

You can further reduce costs by having the application that creates the report deliver it to its final destination in the format desired.  Most systems have tools built within them that assist in accomplishing this task.  There is usually third-party software available that can do this when the system lacks the tools itself to get the job done.

Security

Some reports may have sensitive or proprietary information, such as financial or executive reports, that you will want to limit the access to these reports.  Reports delivered via the company’s email system are delivered to individuals or distribution lists; so you control who gets these reports.  The downside of this method is that if the report was delivered to 10 recipients you now have 10 copies of a sensitive report out there.

Windows network folders can have limited access rights assigned to them.  So setting up folders and assigning limited access rights to them then having reports delivered directly to those folders solves many issues related to delivering reports for the organization.

Report List

Organizations have spent a lot of money trying to maintain report lists.  Keeping it current with additions, removals and delivery instruction changes can be a daunting task.  Sometimes when an application is used to deliver reports, necessary information can be extracted from the setup to create a report list.  If the reports are delivered to Windows network folders, open the folder…there is your list.  Reducing the resources necessary to maintain the report list is another way to save your client money.  So capture it from an application setup or from the network folders to automatically create the list.  Also, if a list is not required, don’t spend the resources to maintain one.

So when working on an enterprise reporting system, remember there is more to consider than how the report looks.

>> Learn What Questions to Ask When Creating a New Report

“Create Report” is one of the 18 requirements checklists in the  Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence. I

Click here to learn more about the Requirements Discovery Checklist Pack

The story with me has been that if I am hired to create documentation and other deliverables for either my development or business audiences, they have an obligation to read what I’ve done for the sake of the project and organization. While I do still believe that is true, I have also spent the better part of a year observing my working environment and reading the posts of respected peers and experts regarding documentation, methodologies, bridging the gaps of communication, etc. Why? Because something has been gnawing at me about this scenario. Why is it that people are not using or reading what I deliver?

Well, the fact is that there is not much value in the physical or perceived weight of my deliverable. Think about it. There is a line of diminishing return as the page turns in a massive BRD; I’m sure one that steeply drops into the abyss somewhere around page 319. So the more people are reading, the less they are absorbing and processing for use in their real work.

I’ve been failing. Period. My audiences are diverse and very busy; they simply don’t have the time they need to do things the way they should. Also, as the business world has become more competitive due to many factors, there is less money to produce documents that no one reads. So, I’ve found myself in the middle of a metamorphosis that I’m sure will have Scott Ambler ringing my doorbell any moment. Alas, this is not Agile requirements that I’m talking about (yet). It’s figuring out how I can adapt to serve my customers (Business and Technical) and deliver to them what they need in smaller volumes, without ambiguity yet with enhanced clarity.

See if you can respond with exceedingly good ways to deliver quality requirements WITHOUT mentioning any methodologies or best practices.

>>Let Go of Your Big Thick Requirements Document

Check out the Business Analyst Template Toolkit – the set of requirements templates host Laura Brandenburg has been using to replace 50+ page requirements specifications with a sequence of shorter, actionable documents, most of which are less than 3 pages long.

Click the link below to learn more:

http://www.bridging-the-gap.com/business-analyst-template-toolkit/

I could cite many reasons for why this happened. There were some legitimate challenges, one of which is we are all in separate locations, so we relied primarily on phone and email for communication. But the hard truth is that I forgot to simply ask the developers what would help them most.

I got started quickly and got lost in my own assumptions about what would be good requirements spec and where my role would fit into the development process. I relied more on my prior experiences of what has worked in the past than on what would work in this situation. I mistakenly assumed that because my way of doing things had worked before, it would work now.

I realized that no matter how similar a situation seems to a prior experience, there is one variable that is different: the people. And the people count big time. Because as people we do unexpected things and have unexpected perspectives and expectations.

What do you do when your development team tells you (directly or indirectly) that the way you specified the requirements is not working for them?  How do you respond? What do you say?

I think you have to start by taking 27 steps back and setting aside all assumptions, frustrations, and, most importantly, your ego. As Cecilie Hoffman told me in a recent interview “check your ego at the door.”  Or, maybe, you need to put your ego in a locker and give the key to a trusted friend who has a heart of steel. You are going to feel pretty battered as they tell you exactly why the requirements you pulled together won’t work for them. Embrace the feedback. Remain open, non-confrontational, and non-defensive.

Take the time to figure out exactly what it is that will make them successful. And then go about figuring out how you can make that happen. Just like code, requirements can be refactored to make them more usable and extensible for your situation. It will take much less time to do this than you think.

And on your next project remember: Ask the developers first, write the requirements specifications second. Because at the end of the day, if your developers won’t or can’t build the solution to your requirements, you’re not going to be successful as a business analyst.

(I love use cases so much, I give away my beloved use case template for free. Imagine that!)

Use Case Reviews Mixed with Design

In my early days as a business systems analyst in a relatively-RUP process, the use cases were the center of our world. After “baselining” a hefty 50-60 page requirements document, we’d dive into use cases. We’d hold reviews with the business stakeholders, development team, project managers, and QA and painstakingly review the details of the use case alongside the user interface wireframes. Many of these discussions were essentially design discussions as we all struggled together to figure out what, how, and what’s possible all at the same time.

I’ve come to realize that these meetings were woefully inefficient and violated the basic tenet of separating “what” and “how”, but man were they fun! We had a great time debating details, discussing options, and finding solutions. At the end of the process, we all had a fairly good shared understanding of what was to be done.

By the way, if you are not familiar with use cases check out this video to learn how to write one step by step:

Keeping On with Use Cases as a Solo BA

The love affair continued through my next two positions. First as a solo BA in a small start-up and next as a BA manager at a larger “reborn” start-up where we were merging the IT systems of 5 real start-ups into one. Truth be told, I didn’t really know any other way to be a business analyst.

Focus on the use case I kept saying and eventually we will figure this whole implementation thing out. Use cases have a sort of internal beauty. They just so perfectly get you from point A to point B. The very act of writing a use case inspires some of my best systems thinking. The act of reviewing and validating a use case can create active discussions about the actual requirements.

Finding Agile and Still Writing a Use Case or Two

Then I come along to my first project as an agile business analyst. It becomes agile after I start it as RUP (because that’s what I know and that’s what the client had used before). So I’ve got a use case list and it needs to become a user story list. User stories are smaller, more granular, and development driven.

After a month or so fighting through this transition,  it clicks. User stories, done well, could solve many of the conflicts that surface when requirements intersect with delivery. They elevate all kinds of details that use cases brush under the rug. They force me to prioritize that new alternate flow that “just has to be there” instead of embedding it into a use case and hoping it makes it’s way into a design document or project plan.

All good. All good.

In this project, I also have the opportunity to document some business process improvements. And where do I start? Of course, with my beloved use cases.

If you are looking to learn more about user stories, here’s a quick tutorial:

Can Good Wireframes Supplant Use Cases?

Then I land a client with even less process, more desire for quick results, and smaller development team than anywhere I’ve worked before. At first they just want wireframes because they find them easy to develop from. This works for phase 1 because it’s a fairly simple project, but phase 2 is heavy on functionality and interactivity.

I can almost smell it…we need some use cases.

I start with using use cases simply to analyze the problem, never showing them to anyone. I fully realize now how much I love them because of the good thinking that comes from them. You simply do not think this well staring at a set of wireframes. The rules don’t elevate themselves, the analysis just doesn’t happen.

But then we start to struggle in the wireframe reviews. The developers need the use cases too. They don’t want them, but they need them.

Wary of “too much requirements documentation” phobia I try something different. I throw out my templates with headings, and document information tables, and numbers like section 3.1.1.2. I start with a blank Word document. I write a description. I create a flow of events with basic 1, 2, 3 numbers. I add in alternate flows and exception flows, again 1, 2, 3. I add a bullet list at the end to capture open questions and key discussion points.

I’ve captured the absolute essence of a use case in its most simple form. Most use cases fit on a page.  In the end, these use cases passed the muster of a simple document for a team that didn’t want too much documentation.

Want to add wireframes to your requirements process (I highly recommend it!). Here’s a video explaining how to create a wireframe:

Still In Love with Use Cases

And then my next project. Again responsible for building a requirements process, but not too much of one at first as we begin to integrate the BA role into the development process. Again figuring out how to bring multiple new stakeholders into an agile environment. Again using use cases upfront to analyze the problem and knowing I’ll need them again on the back-end to document the system. And again trying to find if they have a place in between or if user stories will fill the bill.

I’ve had a long history with these BA deliverables we call use cases. One might even call it a love affair of sorts. Many, many thanks to Ivar Jacobson for creating them way back in the day.

It’s always nice to find a tool that makes you better at what you do. I think no matter what I do, use cases and use case thinking will have a home in my mind and a bit in my heart.

And to Today, Training High-Performing Business Analysts on…Use Cases

Inn 2008 I founded Bridging the Gap, a training company for business analysts. The second course I developed was called Use Cases and Wireframes, which is now part of The Business Analyst Blueprint training program.

Use cases are a core foundational technique we teach in The Blueprint. I love teaching participants how to write them, breaking down all the minute details that separate an ambiguous use case from one that’s clear and complete. I love helping participants understand WHY to write them and also when to write a use case (as well as when not to).

Wondering when to write a use case? Check out this video:

Download Your Use Case Template Today

Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.

We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.

Click here to download the Use Case Template<< 

If you’ve gotten this far and aren’t swooning over use cases yet, perhaps process maps are more your style? Here’s a video on this technique – they go hand in hand with use cases:

Use Cases Are One Way to Analyze the Functional Requirements

It’s also important to remember that use cases are just one type of functional requirements specification that you can use on a software project. You leverage use case thinking skills even if you are creating other types of requirements documentation. Get all the details on functional requirements here:

Adriana has already shared her views on how BAs help improve the quality of documentation on agile teams. I definitely concur! And today, I’d like to expand on that view by separating out the ideas of technical specs and system documents.

My Old Way of Doing Things

One beautiful thing about use cases is that they can play triple-duty. They are a decent tool as a technical specification. A developer can take a use case and begin to design and build code to support the functional requirements in the use case. They also often double as system documentation, which means that after all the code is written, the use cases are usable requirements documents in understanding the requirements of the system. Use cases are also a wonderful analysis tool in that they encourage you along your way of doing the hard thinking about how a system works.

As I became immersed in agile practices, I began to realize that placing these three different needs onto every document I produced created unnecessary headaches. I sometimes stalled as I took time to “figure it all out”. If your documentation is going to help the team deliver AND be useful long-term, you need to know a lot more about the product you are building before you write it.

Similarly, I fought requests to change or refactor documentation, which I now see as a sometimes necessary part of the business analysis process. An update to one use case often means a bunch of related updates to other use cases. When you are on a quest for perfect system documentation, you can feel a lot like a juggler during the delivery cycle.

The Goal of Technical Specs

Agile practices, especially the focus on ensuring documentation is relevant to building working software, helped me see that there is a lot of value in customizing how you present the requirements specifically for the development team. When working with an agile team, the user stories organized in a product backlog are the main communication points about requirements. I break up and rewrite user stories all the time to suit the needs of planning and prioritization.  I aim to compartamentalize the requirements into small chunks of valuable functionality that can be built by the team in 1-3 days. This means that as I learn about the system and what it takes to build a specific feature, I update the backlog of stories. This requirements approach allows me to cater specifically to developers and help them be more effective.

Because use cases are such a wonderful analysis tool (just one of the many reasons I love them), I’ll often do some early use cases before I start defining my user stories. It helps me keep the big picture in mind and can be a useful tool to review with stakeholders and developers to understand the requirements and the concept. But I typically don’t use them as part of my technical specifications in an agile project.

The Way of the System Documentation

I still believe you need system documentation because it provides lasting value. I actually think that a documented system is more valuable than an undocumented system. Don’t you? Tracing through a large collection of user stories that build on top of another is an inefficient way of finding the answer to “how does the system work?”. And six months from now after you’ve left this project in the dust someone is going to ask you just that.

Thankfully, I’ve found that writing use cases after the system is built is a fairly low-bandwidth activity. Once you’ve built a product, retrospectively writing the use cases and capturing key decisions can typically be done in a small fraction of the time you spent on the product originally. For example, for a six month project I spent just a few days creating and updating system documentation.

The Pros and the Cons

I will admit, handling system documentation and technical specs separately does take more bandwidth from the business analyst on the project. In my experience, most of this bandwidth is consumed in reconfiguring the technical specs (or user stories) as you learn about the system and the delivery cycle.

But I think the reality is that if I wasn’t doing this in my more traditionally managed project, then someone else was. This probably fell to the tech lead or the project manager. And in the process, I’m sure some of the requirements were missed and we delivered less value than we could have. The business analyst can bring a lot of value to this reconfiguration because you can keep the whole system held together and ensure that each story continues to focus on value to whoever will use the system. You are not just splitting stories apart into pieces of code. You are splitting features apart into incrementally delivered requirements.

The other positive that comes from this additional effort is that I have a better tool to validate requirements with the technical team. In the past, this work typically ended with a use case review and a formal nod indicating “yes, we can do that.” And then I had to wait until the code was delivered to see if that was true. As part of being involved in planning and reconfiguring stories, I get a much better idea if the developers can make sense of the requirements and how they intend to build them. With improved requirements validation, I end up with better requirements in the end.

Looking to Improve Your Documentation?

Check out the Business Analyst Template Toolkit – my repository of go-to templates for streamlining communication amongst the business and software development teams.

Click here to learn more about the Business Analyst Template Toolkit

Given that this is a common challenge, I thought I’d share a bit on the way I approach project situations with little to no processes in place or templates to use.

1. First, I get my head around the scope of the project and the need for documentation. Documentation should fill a need.  The more I know about how my documentation will be used, the better I will be able to provide the right documentation.
2. I evaluate what stage the project is in. Is there a budget in place and a development team ready to start? Is there a need to evaluate off-the-shelf solutions? Do we need to start with a scope document to support a go/no-go decision on project funding? I make sure whatever my first deliverable is helps drive the next project decision forward.
3. I often hunt around in my archives of past work for something I’ve done to fill a similar need. After a few years, I’ve got a repository of everything from a 100-page requirements monster to a 1-page epic to a data feed specification to a user interface specification to a 10 page project scope document. I’ve also started building a repository of templates to use with my favorite sections, questions, and gotchas. (If you don’t have the advantage of an archive of past work, you might be interested in my Business Analyst Template Toolkit where I’ve annotated my most useful templates so you don’t have to start from scratch.)
4. If I’m approached with a new situation, I do a few internet searches to see if there are any suggested practices out there. I also pull out my favorite books for ideas. I might reach out to a few colleagues or contacts for help. As a side note, asking for help with requirements challenges is a great way to stay in touch with your professional network.
5. I create a preliminary plan of what deliverables will best serve the project. Sometimes this is a full-fledged requirements management plan. Other times it is simply a plan to get to the next decision.
6. Finally, I discuss some options with the project leadership and document consumers. I seek out their input on what would help them take the next step.

I’m probably a bit unique in that I never fully trust a template, which is why it took me so long to annotate mine and finally make them available. A template is a good starting point, but you also need to apply your own independent thinking and seek input from your stakeholders about what works for them. Every project is a little bit different and needs some special TLC.

Don’t Start From Scratch

Check out the Business Analyst Template Toolkit – my repository of editable and annotated templates you can use so you don’t have to start from scratch on your next business analyst project.

Click the link below to learn more:

http://www.bridging-the-gap.com/business-analyst-template-toolkit/

Within the business analysis community, the debate still reigns about whether how the application will look and how the screens will be laid out is technically part of requirements or design. This debate centers around the wrong question.

The right question is “When is the most effective time to introduce visual prototypes into your requirements process?”. My answer: As soon as it makes sense to do so.

Another good question to consider is “What requirements do a prototype or wireframe represent?” My answer: It depends. It depends on where you are at from a requirements process perspective (eliciting, validating, analyzing, or a bit of each), what types of requirements management practices you have in place, and what level of user interface expertise is available across members of the team.

I’ve worked on teams where the user interface wireframes or prototypes, coupled with some textual rules, formed the main body of functional requirements. I’ve also worked on teams where the prototypes were thrown away or merely used to capture representative screen shots. I’ve also partnered with a UI/UX Designer who creates the CSS/HTML for implementation alongside the functional requirements.

Regardless of where wireframes fit into the requirements package, they can be useful in all phases of the requirements process, from defining the scope to the implementation hand-off.

Using Prototypes During Initiation

During the initiation of a new project, some rudimentary mock-ups can help elicit new requirements and create alignment around project scope. These mock-ups might look nothing like the finished product, but showing one possible solution to a set of high-level business requirements can help get everyone is on the same page. It’s important to keep these wireframes very rudimentary, separating out look-and-feel to focus on the basic concepts to be introduced with the application.

Using Prototypes To Get to Detailed Requirements

As you start to dive deeper into the project requirements, wireframes become more tangible. I often create wireframes for an end-to-end work-flow, leaving gaps for areas that are open to trigger discussion points. It’s not uncommon for me to hold a walk-through and show off wireframes with bright red text and an arrow indicating “how should this work?” or “what should happen if the user clicks this button?” or “what if this rule is true?”.  Walking through a new work-flow using visuals helps elicit hidden business rules, alternate paths and creates good discussions. Taking the wireframes through an end-to-end work-flow also helps drive some analysis. I often find gaps as I try to get from point A to point B to realize we have missed a field or an entire screen and overlooked an important requirement as well.

Using Prototypes to Validate Requirements

In the final stages, prototypes can also be used as a tool to vet the final rules. These rules are probably documented in a separate document, such as a UI specification, use case, or business rules spec. But rather than do a comprehensive document review, I sometimes talk through the rules in reference to the user interface.  An example of this might be in an integrated environment  when you are looking at a screen that is going to feed data to a native application. These rules will likely be documented in a spreadsheet of some kind with all the data mapping details, but instead of reviewing the spreadsheet I’ll bring up the UI screens and visually reference the mapping. So this field will go there…and then if the this field meets this condition, we’ll map it over there…etc, etc.

Interesting in seeing how prototypes can be part of your next project?

Learn to Create Useful Prototypes

Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

Click here to learn more about Use Cases and Wireframes

Why Specify User Interface Requirements?

Think about the home page of your company’s website or your LinkedIn home page. Complex pages that display massive amounts of information in intelligible ways don’t just create themselves. They are products of intentional design and careful analysis.

• As a BA, do you tend to leave these “design” elements to your development team to flesh out?
• How much churn is that creating during implementation?
• Would you be interested in exploring a better way to capture these rules, without over-stepping your role as a business analyst?

Elements of a User Interface Specification Template

A UI specification defines the rules of engagement for a user interacting with a specific page on a website or screen within an application. A UI specification can have the following elements, take or leave a few depending on the situation:

• Visual overview of the screen. Break the screen up into sections. This will help organize your document. You can do this in Word with a few text boxes. Label each section and include a “section” in your document for it.
• Within each section, look for the display rules. For example, on a search results page, how are items sorted? What fields are displayed? What if a particular field is missing?
• Consider messaging. Do you want to display specific messages in specific conditions? If so, what are they?
• Evaluate the links. Is it obvious what pages each link should be directed to? If not, specify it.

Good UI specifications take into account the data and context of the user within the application. This sort of requirement specification does not replace UI design, but it does help you lead your team through thinking through the UI design and how users will actually experience information within it.

Fitting the UI Specification Into Your Requirements Model

There’s an obvious blend here between functional requirements and non-functional ones. Sometimes a few functionality requirements make their way into your screen specs. I try not to worry about this to much. But if you find yourself writing out a bunch of “if then” statements, then you are probably trying to use a UI specification to substitute for a use case or other functional spec, and you might consider breaking it out and simply “calling” that use case within the screen spec.

And on a final note, not every screen needs a UI specification, only the more complex screens. The intent is to reduce ambiguity and drive alignment around complex rules. For a simple screen with a few rules, these rules might be best captured in the special requirements section of a use case or in a separate business rules document.

>>Don’t Start From Scratch

If you’d like to create these types of user interface specifications on your next project, I’ve made an fully annotated version of my UI specification template available (along with a host of other useful and practical templates) in the Business Analyst Template Toolkit. The toolkit includes 11 additional templates covering common BA documents, each accompanied with a work sample too.

Click here to learn more about the BA Template Toolkit

There are a host of activities that happen between a semi-defined need (i.e. an epic) and a list of defined requirements to be built (i.e. the user stories). The goal in creating an epic to scope out a feature or a project to get just enough clarity around the what and the why and dig into just enough of the how to create a common understanding of what will be achieved with a given set of work. An epic is a great way to keep track of the big picture in agile environments.

With that context, here are the sections of the epic template I use:

• A one sentence description of the feature, written in the syntax of a user story “As a [user] I can [do something] to [achieve some benefit]. This is probably the “epic” on your product backlog.
• Benefits. A list of the specific benefits to be achieved via the implementation of the feature. The goal is to answer the question of, “why bother?”
• Scenarios. If your feature supports more than one business process scenario, this is a good section to include.  Capturing the scenarios keeps the requirements process aligned with how people will actually be using the new software.
• Features list. Identify the features that are included in the “scope” of the epic. These can be written in the user story syntax as well and might logically become the product backlog items or the be broken up into multiple user stories.
• Existing functionality to integrate. Often you’ll be building a new feature on top of some existing functionality.  Overlooking the current capabilities the software needs to continue to fulfill is a common requirements oversight I want to avoid.
• Assumptions. A list of things you’ve assumed to be true that were validated (or invalidated in some cases) by the business stakeholders.
• Nice to have features.  More of the above, but these will result in lower priority or non-existent product backlog items.
• Out of scope. Especially if you come from a traditional background, it’s difficult to resist including this beloved section for what you’re not doing. And it can help keep your team on track in terms of delivering what absolutely is needed to create value. Without this section, otherwise out-of-scope items might creep into your product backlog and divert your team’s focus from delivering on the value proposition.

All of the above looks a lot like a typical requirements document. The difference is it defines the scope around one feature (not an entire project) and, although you might need to succumb t small margins and minimal formatting, you can fit the information onto a single page.   It’s more agile than traditional approaches in that we’re not scoping a huge project and then diving in.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

I call this the “gnarly part” of the project and no matter what your methodology or expertise, you are likely to hit it at some point.

One technique I like to use when I sense my project team is failing to communicate about important concepts is a Business Domain Model.  A domain model logically represents the business concepts to be fulfilled by the system and how they relate to one another.  It should not be confused with a data diagram, with represents the actual database design or architecture.  Although they may look similar, a domain diagram should use terms that are in the business domain.

(Both Business Domain Models and Data Diagrams are two of many visual models that BAs use in their work.)

Here’s an example of a domain model

This is a small section of a domain model I completed a few jobs back.  It probably won’t mean much to you, because without understanding the business context and what the terms mean, domain models do not really tell you much.  However, I’ve found them to be great conversation pieces, much like a coffee table book of your favorite vacation spots.

Let’s take a quick look at each element of the domain model

The boxes represent entities, or business concepts, and the lines between them explore the relationships between each concept.  In this example, an RC Account can be related to zero to many VL customer profiles.  This was a key concept for this product as we were leveraging a one-to-many relationship between the accounts in our legacy system and the accounts in our new system.  As can be imagined, there was a lot of disagreement and discussion about this.  Hence, the coffee table book effect.

Within each box, you list key data elements (in a precise data model these would be the fields in the table) that are part of the business concept. You can also identify whether each element can have multiple values.

>>Interested in Learning More?

We provide more detail about  business domain models and 21 other models BAs use in the Visual Model Sample Pack. The Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.

Click here to learn more about the Visual Model Sample Pack

In what follows, I’ll share my 4 step process to getting from initial elicitation meetings to a complete and validated requirements document.

Step 1: Document Meeting Notes

Instead of sitting down and attempting to translate what you’ve just heard into usable documentation, I’d recommend first typing up meeting notes that are more representative of “stream of consciousness” writing.  Read through your hand-written notes and type not just what you managed to get down on paper but everything else these reminders trigger.  Your first goal is to get down on paper “what you heard” and then “what you were thinking”.  I like to use parenthesis or brackets to call out implications of what I heard, for example:

Jane noted that they use they use search to find newly registered customers and verify their credit card transactions went through successfully. [Note to self: why would a credit card transaction not go through? Are we not validating this before registering the customer?]

Writing up notes typically triggers all kinds of questions we simply did not think of while actively engaged in dialog.  This is OK.  Although you can minimize your follow-up questions after meetings, some follow-up questions are simply part of the process.

Step 2: Ask Follow-Up Questions

If you find big gaping holes, you will want to go back to your subject matter experts and ask some follow-up questions.  If your questions are specific to one feature or you do not expect the answer to have a significant implication, you can ask those questions during validation.  Be sure to capture those questions so you don’t lose them, either in an requirements issues list or within the documentation you are creating.

Step 3: Analyze and Document

Now it’s time to begin to analyze the information you’ve pulled together. Using a structured template can help you analyze the problem space.  I like use cases because laying out the functionality in a sequence of steps, with alternate paths and exception flows helps me think through all the possible scenarios and identify gaps in my thinking. But there are many different requirements documentation formats a BA can choose from. Choose the one that best solves the problem to be solved by your project.

Once you’ve drafted documentation and before you begin to send it out for review, let it rest for a day or two.  Go back with a fresh perspective as a potential new reader of the documentation.

• Is it clear?
• Would you be able to gain an understanding of the system?
• Could you add on to it as the system changes or you learn more about the project?

We often think about the usability of our systems, but rarely about our documentation.  The common thinking is that any documentation is better no documentation.  I disagree. No documentation is better than bad documentation.

Step 4: Validate the Documentation

Once you have a draft ready to go, you’ll want to validate your documentation with your subject matter experts.  This activity closes the loop (for them and for you) by presenting back the details of what you understand.  If your subject matter experts are new to this type of documentation, you may want to host a brief tutorial on what the document is and how it will be used.

Always be very upfront about the kind of feedback you expect and very open to comments like “you didn’t get that right.”  In most situations, I’d recommend a brief in-person or over-the-phone walk-through of the document and this is a great time to ask your smaller follow-up questions.

Nothing gets a discussion going like you admitting you did not get all the details in the original discussion.  It makes people more open to provide feedback. On occasion, you and your team will identify some significant holes to be filled. Significant holes are best filled in new elicitation sessions, not in a validation meeting. So, back-up, conduct the elicitation session, and work your way back through the four steps.

>>Improve Your Requirements Writing Skills

Looking for practical ways to reduce requirements defects while also improving your requirements specifications? Check out one of our business analysis training courses:

• Business Process Analysis
• Use Cases and Wireframes
• Data Modeling for Business Analysts

At Bridging the Gap, we help you start your business analyst career and gain confidence in your business analysis skills.

It’s so easy to get into a rhythm of looking at one story after another, eliciting the requirements, defining the stories, and prepping them for implementation. After a few weeks of this, you can lose track of where you are at in the context of the project as a whole and it can become increasingly difficult to groom the product backlog.

On one particular release I worked on, there were 4 main pieces of functionality and about 60+ product backlog items that collectively delivered on that functionality.  Although most backlog items are relatively independent from the perspective of implementation they are inter-related in terms of how they fit together to achieve our defined business objective.

Moreover, much of this new application will be interfacing with a legacy system and database and exposing data from that system live to customers on the web for the first time.  The small minutia of what’s in a database field or what the status of a record is in a given state can have significant business implications and impact how decisions are made in the minutia of detailing out other stories.

The challenge I faced was how to expose these inter-relationships in a coherent way to support my own analysis and get meaningful sign-off on the product requirements.  In the past, I have relied on the rigor of more comprehensive use cases with accompanying wireframes to “hold it all together” so to speak.  Oftentimes 2 or 3 use cases might be inter-related to deliver a complex feature, but now I’m often faced with 10+ stories, which is a mite beyond that infamous “rule of seven” that the brain can hold at any given time.

What I ended up doing was creating a feature map, with each user story laid out in a hierarchy and used color-coding to show which stories were implemented and which were not. This helped us see that we’d been cherry-picking important stories across different big features, but hadn’t really finished a single big feature on the project.

We re-prioritized our stories, looking at what stories were most important by feature and what minimum number of stories could be used to consider a feature complete. This allowed us to approach a collection of related user stories together and made the requirements process go a lot more smoothly. I felt a lot more like I was writing my beloved use cases.

And it also helped me keep my sanity.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

Organizations invest a significant amount of time and money in establishing data feeds. While the technical implementation is typically relatively simple, the coordination between partners, mapping of data elements, and decisions around what functionality is required can create complexity.

The Data Feed Specification Template

If you are going to be setting up new feeds on an ongoing basis, a best practice is to develop a standard requirements specification template for new feeds and a package of support materials for partners. The package should minimally include a description of your preferred standard format for sending or receiving data, a sample, a list of fields and business rules for populating them, and a sample data file. If it’s possible to include developer tools, such as a validator or converter, that’s ideal.

The template should be specific to the type of content exchanged but should minimally include the following elements:

• Frequency with which the file will be delivered (and day/time)
• File format
• Filename
• File transfer instructions (FTP server address, API format, etc)
• Data mapping instructions

(By the way, while you can certainly recreate this yourself, I’ve included my Data Feed Specification template as part of the Business Analyst Template Toolkit. Why not save yourself a little time?)

This is the high-level view of what to include, now let’s drill into what you should be thinking about for the data mapping instructions. Then we’ll look at the types of questions you want to ask and answer to fill in the rest of the template.

Details About the Data Fields to Be Included in the Feed

The logistics of the file is one thing. The actual data to be included in the file is another. It’s in structure and content of the data file that most technical issues surface.

You’ll want to answer these types of question:

• What fields are required?
• What fields are optional?
• Do any fields have default values? Can these be specified by feed?
• For fields that must be matched to a specific set of values, will the partner be asked to provide the field IDs or a set of terms?
• What are the business rules for inserting a new record into your database? For example, if it’s an order, do you need to have a customer record set-up? Are there any limits to how many records a partner can post? Are the records loaded directly to a live system or do they go through a review process (manual or automated) first?

Many of these questions could be answered by reviewing or creating a data dictionary for your system and then thinking through how you’d want new records added to your system.

Don’t Overlook Data-Related Functional Requirements

In addition to creating a template and instructions to send to your partners and specifying field-specific rules for data feed, you’ll need make some business decisions as to accepting the feed and making it live in your system.

Consider the following types of questions:

• Will you ask your partners to push files to you or will you pull the files from your partner?
• On what schedule will the file exchange happen?
• Will each file have a full set of all active data, or will you need to trigger adds, updates, and deletes?
• What will happen to invalid files?
• Will you be able to isolate invalid records and load the valid records?
• Who will receive notification of invalid files and what can they do to rectify the errors?
• Will you check for duplicates? If so, what rules are used to flag a duplicate and what happens to a duplicate record?

Specifying data exchanges is an important part of getting the technical requirements right for the business. One wrong field or missing rule, and your business users will be in a world of hurt!

This is a lot to think about! You can learn more about the process of data mapping in this video:

>>Get the Data Feed Specification Template

You can grab my Data Feed Specification Template along with a corresponding work sample as part of the Business Analyst Template Toolkit. The Toolkit also includes templates for 11 other common business analyst documents.

Click here to learn more about the BA Template Toolkit

>>Learn More About Data Modeling (Free Training)

Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.

A product backlog contains a complete list of all requirements under consideration (written using a user story syntax – more on that below), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization.

Let’s look at how the product backlog emerged for one particular project and how decisions were made about what to include in the product backlog.

Switching from Traditional to Agile – And Getting Started on the Product Backlog

This project was initiated with a traditional approach. The business analyst created a fairly traditional scope statement and features list. The features list was fundamentally business-driven.  When I started work on the project we had not yet defined how we’d manage requirements communication with the out-sourced development team.

At the project kick-off with the development team, we reviewed a fairly final draft of the scope statement and started discussions around detailed requirements communication.  The development team is part of an agile shop, so regardless of who did it, a product backlog and user stories would be created. The team agreed that it made sense for the business analyst to own creating and maintaining the product backlog and user stories.

Blending Requirements and Design in the Product Backlog

Identifying a user story blends elements of requirements and design.  As I worked through my list, driven by my understanding of what the business wanted, I kept running up against the question of, “How will it make sense to build this in a delivery cycle?”

To balance these two perspectives, I drafted the product backlog, then we tore it apart as a team into deliverable nuggets of functionality. For us, the question the product backlog answered was, “Given what we know about scope, what is the best way to deliver in an agile environment?”  So, we were blending agile with more traditional methodologies a bit to the benefit of the business team (that cares about scope) and the technology team (that has optimized their development process to deliver in sprints).

Using the User Story Syntax in the Product Backlog

The second challenge I encountered really centered around the syntax of a user story. In the past, I’ve been an “ability to” analyst…never again.  This time I used the following syntax to write requirements in my original scope statement.

“[Somebody] does [something] with [some information]”.

This provides a much more powerful way to capture features and also ensures you are capturing all aspects of the feature. And the standard user story format?

“As a [user], I can [do something] so that [perceived benefit].”

These were surprisingly similar.  I really played around with the benefits statement and found that sometimes it added real value to the story and other times real confusion.  I decided to consider it optional for this project.

But the standard user story format was missing the “some information” component that had really helped flesh out many of my requirements.  Therefore, most of the product backlog ended up in the following blended format (items in parens are optional):

“As a [user] (with some information), I can [do something] (with some information) (for some perceived benefit).”

Evolving the Product Backlog

Over the course of the project, the product backlog continued to evolve and was “groomed.” As we drilled into the requirements behind some of the earlier user stories, we discovered they were bigger than anticipated. We broke apart user stories into two or more product backlog items. On occasion, we combined stories.

As new stories were added, we assigned them story points (a kind of estimate) and a general priority. We rank ordered the next 20 or so user stories. As stories were targeted for a specific sprint, we added that information.

The backlog became a tool to scope and re-scope the project and it proved exceedingly flexible. Since we were using Team Foundation Server (TFS) to manage our user stories, I could download the complete product backlog and with some simple formatting in Excel share it with the business team. Then I could input my changes and update the user stories. Eventually, we even got the syncing functionality to work so I could make updates in Excel that were reflected back in TFS.

Managing a product backlog is a key way for the business analyst to add value to an agile project. It’s a wonderful tool for keeping business needs in sync with development deliverables and for streamlining how the requirements get managed throughout the development process.

>> Learn More About Agile Requirements

Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.

Click here to learn more about Use Cases and Wireframes

Let’s just be clear here: Someone who cannot clearly articulate how they will finish their primary task is not likely to be hired into the role.

So, what does it mean to be done with requirements?  There are three basic criteria:

#1 – Alignment:

You have created alignment among your business stakeholders around what needs to be built to drive business value.  The evidence of this alignment is clearly documented.

#2 – Buildable:

You’ve elaborated your set of requirements into a level of detail that an your implementation team can build from.  For example, a software developer can’t build “advanced search” but s/he can build the “ability to search the full-text of the article, where full-text includes the title, summary, and full article content, and present the article titles of all matching results”.

This requirement has a slew of other related requirements as part of a complete system and is probably best documented in a use case, but the requirement itself passes muster in that it’s ready to be built.

#3 – Quality test:

The requirements meet your organization’s test for quality and applicable industry standards.

Inside The Business Analyst Blueprint® training program,  you’ll discover how to review your own requirements against a set of industry-standard criteria, and then provide expert instructor reviews so that you also learn from your own mistakes.

Here’s the deal…

To answer this question confidently and with expertise, you really need to have a business analysis process framework. You need to be able to articulate the steps you go through to take a project from start to finish, so you can clearly define “done”.

The good news is that you don’t need to start from scratch – you can leverage Bridging the Gap’s Business Analysis Process Framework.

And be sure to join the Quick Start to Success as a Business Analyst free workshop for tips on how to leverage this framework to maximize your effectiveness.