"In Order To" Get Business Analysis Requirements Right

A great topic came up in the IIBA group, Q: ?What's your trick to creating a complete requirements package??. Here was the answer...

?functional decomposition (start with high level objectives and basically making a tree hierarchy down to solution level requirements)?

This was an Aha! moment for me! I realized we can use this approach to elicit the right requirements, identify gaps, and tie to Agile.

And we can do this all with the business actively involved. That way, you have no surprises when it comes to sign-off and buy-in.

Before we get into it, here's some background and a HINT on what we really do in order to get at REAL REQUIREMENTS...

The Business Analyst Goal

One might say the Business Analyst (BA) elicits wants and needs to determine requirements. We've all seen the business "want the moon, but only need a flashlight". Yet, sometimes we feel like monkeys, throwing darts as we try to figure out those requirements!

As you probably know, there are many ways to elicit, but you usually do not know ahead of time which technique will work.

Worse, even if you have the right technique, it may not be the RIGHT requirement! That is why every project needs the "Best BA".

Gathering Requirements

Now that we understand the "Best BA" goal, how do we go about it? Some BAs gather requirements in a haphazard way. They ask random questions and scribble them down on paper.

This might work for a quick understanding, but it is difficult to understand later. It also leads to many gaps, if you forget to gather aspects of the typical Who/What/Why/When/Where model. Worse, it is next to impossible for traceability and collaborating with other teams.

Yet another approach is to use "20 questions". But what happens when you miss something or when the SME you interview is just trying to give answer your guesses - I mean questions?

Jotting It Down

When you only have standard tools like Word and Visio, you distinguish requirements with acronyms, like BR (Business Requirement), FR (Functional Requirement), and NFR (Non-Functional Requirement). Logical numbering gets challenging once complexity and/or scope creep happens. It may work great for small projects, but not so well with complex projects in the real world.

For example, BR1, FR1...FR3 (Whew! So far so good.) Then in the next section, NF1, (okay?)... then a new FR1.1. (Oops!) Where does that go? Yep! Have to shift it all.

Some BAs change it up, organizing requirements by sections in the document. This is a better organization, but still difficult when tying things together.

Elicit and Document: The Real Requirements

A better approach is to use three simple words: "in order to". This comes from Business Modeling Language (BML). The idea is to start with your main high-level business goal or process. Then keep asking that simple phrase with the last known functional activity. When you can't think of anything else needed "in order to" do the activity, you're done!

For example, let's say your goal is to "Get a Job". We've all been there and can relate. Ask, "In order to get a job, what do you need to do?" This makes up the next level down and leads to lower-level requirements.

So, at this point we agree: we need the following [requirements] in order to Get a Job: 1. Apply, 2. Interview and 3. Accept! Now, after mulling it over, does that seem like complete requirements? Could it be that easy? Of course not. We need to keep going down to low enough levels of work and document as we go. Plus we likely need detailed functional and non-functional statements. But this allows you a way to know you aren't just throwing darts!

Transparency, Inspect & Adapt

There's also a hidden Agile benefit of this approach. We start with the first step, "in order to 1. Apply to Jobs...", and further add "what do we need to do?" We then get more refinement that sometimes nobody realizes!

Let's say the next level under 1. turns into 1.1. Create Resume, 1.2. Create Cover Letter, 1.3. Apply to Job Boards, 1.4. Apply to LinkedIn Jobs, etc.

Hmm. Do you see any pattern or differences here? There's buried Agile bonuses with this approach! In going over this with the business (Transparency) we may Inspect and find we need more steps and need to Adapt our hierarchy. In this case, we found two different steps (1.x Create and Apply) from the original (1. Apply). So, we move Apply to the next node in a hierarchy like an org chart. Then, taking the first leg/node all the way down, we could come up with the following:

1. Get a Job > 

1.1. Create Resume >

1.1.1. Research Resume Writing,

1.1.2. Update Old Resume,

1.1.3. Critique Resume,

1.1.4. Post Resume.

1.2. Create Cover Letter >

1.2.1. Research Cover Letter Writing,

1.2.2. Create Cover Letter,

1.2.3. Send Cover Letter,

1.3. Apply to Jobs >

1.3.1. Apply to Job Boards,

1.3.1.1. Search Job Board A, etc...

1.3.2 Apply to LinkedIn Jobs,

1.3.2.1. Search LinkedIn for jobs...

More Information and Examples

This can work if you used Post-it Notes or a whiteboard or many other tools.

However, it's even better if you use Blueworks or a similar tool that allows coloring of the visual process steps. Even better if the tool can hold details. (But I'm getting ahead of myself!)

See my following presentation that gets more into the BML approach, modeling and resulting value - and learn more about how this works and looks - in my How to Add Business Value with Blueworks Mapping article.

Are we done?

OK. Sounds great. But how do we know we are done and have all these high-level activities that are good for requirements? IBM best practices say you should be able to read off your highest-level steps within 5 minutes. I find it is shorter than that, if you do it right.

We finish when we are confident there are no more steps underneath needed to complete the top level. Again, the highest level is your high-level requirements. Your project charter or business objectives should define those.

Then you read back, asking and verifying "in order to complete {higher-level step HL}, we need to complete HL.R1, HL.R2, etc.". If we can read that back to the expert and nobody can think of more steps, we have finished all the main requirements!

What About Details?

Now, we still need to flush out the requirements, adding detailed functional and non-functional aspects...

Requirements might have been missed if we did not first do this BML approach, getting all the key higher-level requirements that needed further detail.

BML gets a lot more complicated than this, adding in the detailed dimensions. (See the presentation above for the WHO, WHAT, WHEN, WHERE, WHICH to ultimately show the HOW for each activity and all the detailed requirements.)

Your requirements must give everything a developer and tester need. However, just start with this approach to get the WHAT aspects first, asking "in order to" and documenting with qualified numbering, and you will be well on your way!

Embrace the Changes

What if another requirement comes up or we get scope creep? This is why you do this exercise first AND keep the numbering going. If you are at 3.4.9 and then 3.5, it is no problem to add something else as 3.4.10. If you had FR3 then NF4, you can add FR3.1.

Don't expect to get it right the first time. That's like trying to ask the one, perfect question of your SME. Don't put that pressure on yourself or anyone else!

Instead, this will take several iterations. Yes, that takes some time. But the bonus is twofold. You and the SME get to verify you've got it right, gaps will emerge and everyone gets the best understanding! (Per Agile, this is the Transparency pillar.)

"One more thing": Plain English, Please

Also, do not make your audience rely on just the numbering, acronyms or fancy models. Those are mainly for you, the BA.

Instead, have good heading structure and start with natural language, followed by anything you need. It would look like "Post Resume FR1.1.4" not "FR1.1.4 Post Resume" or worst, just "FR1.1.4".

Remember, stakeholders have to read, understand and acknowledge the requirements! If using acronyms in a table, define them in a glossary and in table headers on every page.

Conclusions

We described the BA tasks of getting and documenting requirements, using the BML approach, knowing when we are done and handling change. 

We also noted to keep it readable.

I would also add...

Just get it done - there is no such thing as perfect requirements...

Even the business may not know them!

Especially in the Agile world, it is more and more important to get something documented quickly, so your project team can get a working model to the business for verification that you did indeed get the right requirements for their real needs!

Thoughts?

UPDATE 3/28/2017: This article was the basis for a podcast with David Saboe, in MBA117: Getting Requirements Right... and 3 speeches!

UPDATE 5/28/2021: I'm into Agile more than ever. Glad to chat about it!

See my other popular BA articles, a podcast and presentation...