Patterns and the Evolving Business Analyst

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:

• Steven Withall provides an interesting overview of requirement patterns on his website.

• 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.

• Requirements by Pattern by Christopher Creel also provides some nice examples of requirement patterns.

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.