Business Analyst Times

During a recent client visit I encouraged the use of modeling as a way to uncover hidden requirements and expectations. One of my clients expressed her rather strong opinion that modeling requirements was not and should not be a part of business analysis work. Oh, she could accept the fact that uncovering gaps between the "as-is" and "to-be" using process models made some sense, but she was adamant that this gap analysis should be done by a business SME, not by a business analyst (BA). As to data modeling, well that was technical in nature and if done at all, she said, it should be done by the technical IT staff. Use cases were helpful to the testing staff, but were clearly technical and were not to be done by BAs. Prototyping? This should be done by developers-no question about that one!

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that "solution" requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant's mantra "it depends?" In this instance I'm not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we're creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don't. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I'm now going to go out on a limb and make the case that BAs are best suited to model them. Here's why:

1. Modeling is a great way to uncover expectations-those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions. Business analysts are in the best position to understand this structure and ask questions of the business subject matter experts (SME)s. They also are in the best position to interpret the answers and understand the impacts of responses they receive. Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models (business process, data, use case, low-tech prototypes) provide these different viewpoints (more about which in a future blog).
2. Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected-the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done be those who understand their importance in eliciting requirements.

Don't forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth's speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide - Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide - 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner's Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at elizabeth.larson@watermarklearning.com

Comments (15)

Subscribe to this comment's feed

..., Low-rated comment [Show]

...
written by dschrenk, January 26, 2010

Unfortunately, it occurs too often that the effort to model the requirements is not included in the project estimate. As a result, there is not enough time to create what some people might consider unneeded artifacts. But, as you state, they are great tools for uncovering missing requirements and the effort to produce them should be planned for in the project estimate.

• 
• +3
• 
• 

...
written by lmunday, January 26, 2010

I have met this person many times in my travels. They are generally someone who is happy doing the same job that they have doing all their life and are terrified of learning a new technology, in case it changes their life in some way.

• 
• +3
• 
• 

...
written by foxes96, January 26, 2010

I agree the BA is perfectly suited to the modeling and low-tech prototyping you describe. The BA's key function is to live in this area between Business and IT, looking for new ways to uncover and develop requirements, and modeling is a great tool to do that.
http://buddingba.wordpress.com

• 
• +3
• 
• 

...
written by gsad1000, January 26, 2010

There is no doubt that modelling requirements adds value to a project as a 'picture speaks a thousand words'and english can be a very imprecise language.
I think that the modelling question comes from which area the BA's are sourced from and the skills they have. An SME turned BA would not see modelling as part of their role, however a BA professional would. Am I wrong?

If an organisations BAs come via the SME route then they would not consider themselves modellers.

• 
• +1
• 
• 

...
written by tiadpeterson, January 26, 2010

When I was a BA on a team using a number of agile techniques, I did use modeling quite a bit. My first reaction to your beginning paragraphs was complete confusion - because that was my job as BA - to model.

• 
• +3
• 
• 

...
written by aamaxwell@gmail.com, January 26, 2010

On any reasonable sized project, when working with only text requirements, I find it very difficult to ensure and prove all of the pieces of the puzzle are actually known and documented.

The core modelling techniques like process modelling, data modelling and use cases etc have diagramming conventions and rules that when used properly and combined together, help the BA/user to ensure their understanding of the domain and the requirements are complete and internally consistent.

Visual representations of the system are also invaluable when communicating information to stakeholders, and so relevant and accurate models are a useful bridge.

I am not sure what special circumstances exist for the person/organisation described, but as a BA, I would consider nmyself as being less than professional if I routinely avoided modelling any aspects of the domain I was working on.

• 
• +1
• 
• 

...
written by a guest, January 26, 2010

I totally agree with modelling by the BAs they are already doing it. It would be great if the models that are created are useful and people used the models. In this case to identify issues with requirements. I have used a requirements modelling methodolgy for the last two years called Behavior Engineering. It is a graphical modelling language that models the behavior of a system it is easier to read than UML and has more flexibility than flow diagrams. We have found that anyone developing Behavior Trees (one of the models in behavior engineering) does not need to be a SME. In fact if the analyst is not an SME they are more likely to identify possible issues easier because the analyst is required only model the language as written. Any interpretation on the part of the analyst is flagged as an issue for clarification. If you would like to know more goto www.behaviorengineering.org or email me.

• 
• +0
• 
• 

...
written by laxman, January 27, 2010

Im new as a BA. I may not know much but i agree with Elizabeth Larson.

• 
• +0
• 
• 

...
written by rforsberg, January 27, 2010

Should BAs model Requirements? If models are representations of larger (more complex) concepts then the real question is - could we perform our BA role effectively without models? Models are simply a means of effective communication. I can't imagine doing my job without a set of modeling tools. Here's the catch - your models better communicate to your audience - i.e. Find out what models your audience is comfortable with and use those. If a static prototype communicates the data requirements to an end-user more effectively than and ER diagram - then use a prototype.

• 
• +0
• 
• 

...
written by rforsberg, January 27, 2010

forgive my grammatical errors.

• 
• +0
• 
• 

...
written by aogiss, January 28, 2010

Models are paramount to understanding the problems, needs, goals and potential solutions. I use models to validate the requirements, and vv. As one of my BA colleagues says, if you don't model, you are an order taker...and anyone can take orders. BAs deconstruct the problems and goals such that no element of information or function is left behind when the requirements are approved. Often I will model something incorrectly on purpose to draw the stakeholders out on complex points.

To address a comment above, modeling should be accounted for in your requirements plan...elicit, model, draft, review, approve. For me, elicitation and modeling are inseparable; both are major factors to arriving at the correct set of requirements.

Regarding another article recently posted here at BA Times, models help with final reviews/approvals as well. When you have hundreds or thousands of requirements, models both enhance global understanding and expedite approvals, allowing stakeholders to better focus on the details found in the text.

• 
• +0
• 
• 

...
written by aogiss, January 28, 2010

One more thing. While it is important to understand the common models and be able to employ them correctly, don't let them limit you. Your imagination and the mystery at hand should dictate your modeling. I often combine use case maps, context diagrams, personas, etc., in one big 'thing' to define scope and groups of work. Just be consistent within and across your diagrams for a given project so you don't confuse yourself.

• 
• +0
• 
• 

...
written by John Talbot, January 29, 2010

Thanks for the article Elizabeth - my first reaction was "What does your SME think a Business Analyst should do?" Maybe she doesn't know and there is the awful possibility that she doesn't actually want BAs around! We need to be clear not only in the scope of our work on a project but on the scope as BAs as a whole.

As aogiss says we aren't here to take orders, but to understand the business from first principles, so some business model, whether of data flows, processes or even use cases with faults is much better than reams of paper that are open to interpretation or no model at all. Put it up for the SMEs and others to comment on and treat the review as another stage of requirements elicitation!

• 
• +0
• 
• 

...
written by Riz, January 31, 2010

Given that every one is following agile methodologies these days and ignoring alot of useful documentation processes which should be followed for a successful development and implementation of their business solution. But shoudl BA do modeling ? YES, no question about it. Many people are afraid of trying new thing in their professinal life because they think that will impact their life which they really don't want.

Modeling, Prototypes and use cases are always helpful in identifying the hidden gaps which customer him/herself may has missed. Above all if you don't create visual artifacts then it's going to be a big pain to identify the impacts when any changes arises. You might not be able to make a proper traceability Matrix and in the end you either spend a lot of time in identify the changes and/or miss some areas which are also impacted by the change.

I have been working as BA since 4 years now and modeling is one of the best thing which I always love to do.

Cheers!

• 
• +0
• 
•