Patterns and the Evolving Business Analyst


I’ve  stated before that I believe the primary difference  between the novice and expert analyst – all else being equal – lies in the ability to recognize and apply patterns to solve problems. Today,  I’d like to expound a bit more on that idea.

As with all trades, there is a learning curve to business analysis. Part of the curve pertains to increasing knowledge and experience specific to where you work (business and technical domains), and part consists of developing the skills specifically important to the BA role; basically, the stuff in the BABOK, and “soft” skills (interpersonal skills, communication, professionalism) common to the BA job description.  I consider the ability to learn, recognize and apply patterns  in those areas to be the capstone to an analysts development or “evolution.”

What do you mean by “patterns”?

So, when I mention applying patterns, what exactly am I talking about?

I found a great answer as I was scanning one of my favorite reference books, Patterns for Effective Use Cases by Adolph and Bramble, from which the authors quote Christopher Alexander’s 1977 book,  A Pattern Language: Towns, Buildings, Construction. Alexander defines a pattern as:

Each pattern is a … rule, which expresses a relation between a certain context, a problem, and a solution.


[A] pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you could use this pattern a million times over without doing it the same way twice.

Why are patterns important?

Patterns (and anti-patterns) enable us to use accumulated knowledge and experience to solve present problems. Beyond that, they help us to avoid repeating mistakes of the past.

Patterns are used in some form or another in every discipline.  Meteorologists use atmospheric patterns to forecast the weather, health care professionals study biological patterns to treat health problems, law enforcement professionals analyze behavioral patterns for use in tracking down criminals. Note than in none of those cases are the patterns a 100% guarantee on expected results but they can allow you to proceed more quickly and with a higher level of confidence than starting from zero.

Steven Withall, author of the book “Software Requirement Patterns” describes the importance of patterns in a requirements context:

Many types of requirements crop up again and again, no matter what a particular new system is for. The idea of requirement patterns is to provide guidance on how to specify common types of requirements, to make it quicker and easier to write them, and to improve the quality of those requirements.

With that in mind, we recognize that the requirement document templates we use are just prompts to follow patterns for specifying requirements and even our methodologies are nothing more than collections of patterns believed to aid in delivering successful solutions that have been formalized, socialized and then adopted.

But Beware…

There is a danger in using patterns when we try to force problems to fit a template just because we have a template. Just as there is no silver bullet with regard to delivery methodologies, no pattern is applicable all the time.

I found some wise counsel to this point in a post on ifacethoughts:

There is a lot of angst against patterns since they seem to impose rather than give space for innovation. There is a reason why patterns are not standards, because it is quite possible that they apply in most of the cases, not all. Patterns should be used as guidelines, not as a must-comply-with standard.

You may recognize arguments such as, “do we have to fill out every section on the template?”, or “do we have to follow every step in the SDLC to the letter?” Another aspect of becoming an expert analyst is that of knowing rules from guidelines and having the intuition to make the proper decisions on what needs to be done and how. It’s important to note that patterns are not of themselves “requirements”. When used properly, they don’t constrain, but provide guidance.

My approach to using patterns..

One thing I’ve made a conscious effort to do, and that I think has made a difference, is to be a near-obsessive note taker. Anything I learn that I think I might be able to use again later gets noted, tagged and filed – including, occasionally, things that I see in an old spec that I didn’t like accompanied by how I’d do it differently now.

With each new project I’ll look for aspects that are similar to problems I’ve dealt with in the past, and ask myself questions such as:

  • How is this “item” (read: problem, process, function, interpersonal conflict, etc.) similar to others I’ve worked with in the past?
  • What types of techniques and information were successful in our past dealings with the similar item? In the case of requirements, I might review specific requirements, questions I asked to identify them, constraints, types of visuals, etc. we found successful.
  • What are some things  that were problematic with how we dealt with the item previously that we want to be sure to handle differently this time? What did we miss last time that we want to be sure to catch this time?
  • How could the other BA’s benefit from what I’ve learned, and what might they be able to add to our collective knowledge of these patterns?

As a new BA,  a form to complete and a process to follow may be the only patterns initially at your disposal. While that doesn’t sound like much,  it’s ok. Business analysts with the basic BA skill set can –  and absolutely should – be effective in their roles. The important thing to remember is to write down and begin to catalog the things you learn. Also, be aware of the concept of patterns so you can begin looking for them as you gain knowledge and experience.

Quick summary –

I was a bit longer-winded than normal in this post, so if you’re just looking for the digest, here are the main points I wanted to get across:

  • Business Analysis expertise doesn’t come overnight.
  • It can come more quickly if we’ll strive to understand and use patterns in our working environment.
  • Patterns are not just for requirements. Patterns in the specific business and technical domains, as well as those concerning soft/professional skills are every bit as important.
  • Patterns are guides; not rigid, unbreakable rules.
  • Take good notes on everything you learn and catalog them. Patterns will begin to take shape and you’ll be able to apply them to work smarter and faster.
  • Share what you learn with your team.
  • You don’t have to know all the patterns or be an “expert” to be successful as a new or junior BA, but it helps to be aware of them conceptually and to keep them in mind as you accumulate knowledge over time.

Additional Reading

So, there’s a quick overview of requirement patterns along with some of my own thoughts on them. If you’d like to know more about requirement patterns and how they can be used, I’ve provided a few useful links below:

  • Requirements Patterns via Events / Use Cases by Suzanne Robertson. I’ve never used Robertson’s approach specifically, but she does a great job of covering some of the fundamentals and provides lots of images and examples.

Stay tuned! And as always, I’ll look forward to any comments you may have on the key areas of BA knowledge, use of patterns, or how business analysts mature and evolve.



  1. Hi Jonathan

    Thanks for a great site and a great article. I stumbled upon it a little over an hour ago and have found the contents very relevant to my day-to-day working environment.

    You mention the importance of documenting and cataloging (tagging) everything you learn twice in this article.

    How do you do this practically? Is there a tool that you use for this?

    Thanks again!



    1. Thanks for stopping by and commenting, Francois. Yes, I do emphasize the importance of cataloging the new things I come across. I’ve lost count of the number of times I’ve come across a situation where I’ve been able to benefit from knowledge I stored away years ago. The key is making it easily accessible, and easy to get to the specific information you’re looking for – hence the mention of tagging.

      I’ve used a couple different methods of cataloging and tagging. Initially, I used an MS Excel spreadsheet, but that is only because the great note-taking and collaborative tools that we have not weren’t available.

      I currently use Evernote for my personal notes. It enables you to have separate notebooks on different topics and supports tagging. I’ve been really pleased with it so far. Evernote also stores all your notes online so they are accessible from anywhere you can get a connection. It also enables you to share notebooks if you want to collaborate on a small scale.

      If you prefer, MS OneNote provides similar capabilities.

      For information to be shared in a collaborative team environment, I’d recommend a wiki. Our company is using an open source version of MindTouch Deki.

      Hope this helps. Let me know if I can be of additional help.

      I can’t tell you how many times I’ve come across some issue or challenge and remembered that I noted an approach for something similar previously and been able to pull it up for reuse.

  2. I have got my own site about the similar things. I found a lot of interesting information at your blog and I would like to use them. Is it posibble? I am inviting to my site, perhaps you will find also something interesting on my site.

  3. patterns is a very useful thing, besides familiarizing with patters a BA should make a collection of patters, re-think the collection from time to time when more experience is gained. you are 100% that BA experience can’t come overnight. I am making the collection of rqts patters on my blog.

  4. I am so glad you mentioned that patterns are guides not rules. That is important to note because setting up a business strategy or even a project that is based solely on patterns is a little risky because patterns change frequently that’s why they are patterns not engrained behaviors.

Post a Reply to Francois Cancel Comment

Your email address will not be published. Required fields are marked *