Here’s a question related to requirements validation that pops up regularly in the classes we teach: How do I know I’m not missing any requirements?
My first response is: “You don’t!” I know that’s not what you want to hear, but you have to remember that nothing is perfect. Unfortunately, as business analysts we typically have at least a little bit of perfectionist in us by nature so it is no wonder that validating requirements work is important to us. But, since we can’t always be perfect, we should strive for the best we can do given the resources that we have. How do we do that? Let’s break it down into six pieces (it’s always a good analysis strategy to break things down!).
Start with Good Scoping of the Effort
I almost titled this section Start with Good Scoping of the Project but decided to change project to effort, because scoping really should be done before you decide if the effort should be a project or not. I’m not going to address feasibility much, so just be aware that you need to ensure the effort is actually worth doing. Scoping out the effort and then estimating against that scope should give an understanding of at least a rough order of magnitude estimate of cost. Then, compare this cost against the estimated benefits and payback period to make a valid go or no-go decision.
What goes into good scope? For business analysis, there are some areas of the effort on which we should concentrate to ensure we don’t miss more detailed requirements.
- An understanding of the business problem to be solved or the opportunity to be pursued is key. From that, as a project team, we can understand the real business objectives and risks (not just the business ‘wants’!). A true understanding of problems, objectives, and risks will feed into clear understanding of why we are doing the project.
- Scope out the high level business capabilities that will be analyzed for the project. What business functionality are you helping to make better, faster, stronger, cheaper, more flexible, etc. (or are you implementing a new product or service)? I recommend building a context diagram to scope out high level data and the stakeholders and systems impacted, and combining that with a list of the capabilities involved. The capabilities and context diagram together give a great view of what processes, data and stakeholders are involved and need to be analyzed.
Typically, you are able to build these artifacts by doing some current state analysis. For example, you might do as-is workflow analysis, problem analysis, and analysis on current reports and decisions being made.
Get more on Scope and Establishing Context from my colleague Heather’s blog: Project Context is King: Stop, Organize, Think, and Confirm.
If you do a good job up front, usually you have all the pieces put together by the end. How to know if you’re not missing anything really comes down to how to know what questions to ask. If you hit the questions below, then typically you’re going to get to the end and not miss anything:
- Why are we doing this?
- What are we trying to get out of it?
- What do we need in order to get that thing out of it?
- How are we going to do it?
- What does it take?
- What data do we need?
- What processes need to be changed or added to get there?
So let’s move on below to see how to get to the end. For any level of requirements, from scoping down to technical details, you must have the right people in the room willing (and able!) to give the right answers. The right people will know when we are not getting it all.
Break Down Scope into More Detailed Business Requirements
Ok, we have good scope, so now what? In order to avoid misunderstood and missing requirements we need to break down the scoped processes and data into smaller chunks. This helps not only organize thoughts, but also gives you a better chance of not missing anything. The next few topics I do not do in any prescribed order; that just depends on the nature of the project. That said, it all needs to get done to get good results regardless of how you get through it.
As anyone knows who works with me, I’m somewhat of a data bigot. I always take the current state analysis and start understanding detailed data involved in the processes and how it flows. A good understanding of the business data will really help you understand the business and the decisions made based on that data. Analyzing the data also helps the understanding of why and how the process is done now and possibly how it should change.
How do we know we haven’t missed data? Draw out the business data and the relationships between that data in an entity relationship diagram. As you start drawing relationships out, ask questions about the rules that connect data and any new relationships. Seeing the relationships in a visual aids in capturing all the needed data and relationships. This prompts questions like, “Do we have the data we need to make good decisions?” and “Do we need to capture new data or relationships so that we can do some predictive analysis?” As you analyze the data, the business rules typically start to flesh out as well. The business rules tell you what decisions are made throughout the business process. If there are complex business rules, structure them in decision tables to capture all paths a decision can take.
Need help getting started? My colleague and I created a checklist to help you Ask The Right Questions.
Get Into the “How” with Functional Requirements
Now that you have a good understanding of what the business does and the data and business rules that drive the processes, you can now think about how to actually solve the business problems.
Take the business processes we talked about above and start to drive into how the business wants the solution to work, look, and feel. What features and functions do they need to be successful? To map the features and functions out, elicit their needs through user stories. What do your users need and why do they need it? As you elicit those stories, constantly tie them back to the business requirements elicited earlier. Always get more detail on business rules and data as the elicitation progresses, so there is no need to go back and fill in any gaps in our business requirements. Then tie all these user stories back to the business processes to check to make sure that every process is either reflected in a system function or a manual process or a combination of the two.
Thinking About Test Cases Will Help Fill in Any Remaining Gaps
As you elicit and build the user stories with any detail, don’t forget to describe them using Acceptance Criteria. You should be thinking, “How do we verify that this user story will work correctly?” Thinking through all of the decisions to be made in that user story and the expected outcome(s) will help establish that, yep, I got it all!
Take a Walk In The Test Data
Another way to see that you haven’t missed anything is to go one step further with our test case scenarios and actually run through those scenarios. You should be asking for examples of how features and functions can be used. Then you can get start walking the built feature through the examples to make sure all requirements are being met. If you are working on a team where you are not building the system in an agile way, you should be prototyping for these scenarios. Test good data. Test bad data. Test a mix of good and bad data. Test extremes. Test alternate paths. Test in parallel with existing processes. Have someone else test too. In other words, test, test, test!
Put It All Together
If I had to sum it all up, I’d say the key to making sure you aren’t missing anything comes down to being able to:
- Elicit good scope
- Understand the business capabilities involved in that scope, including stakeholders, business rules and data
- Use that understanding to design the functionality of good solutions that actually fulfill the business needs
- Use test scenarios to help fill in any remaining gaps
I hope this helps you have great success and ‘gap-less’ projects!
Thank you,
Ali
Ali Cox
LEAD EXPERT
Alison (Ali) Cox has experience since the mid-1980s in various areas, including business agility, business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunication expense management. She began her career in the financial services area, and then moved into systems development for accounting systems.
Ali has lived through IT and operational initiatives from waterfall to implementing agile in her own small business, then helping other companies do the same through training and mentoring. She believes that having the small business mentality (everyone has to pitch in on everything) is the right kind of mindset for all organizations, no matter the size or industry.
Ali is the author of Business Analysis for Dummies, 2nd Edition.
