Should Business Analysts Model Requirements?

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 Subject Matter Expert (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 SMEs. 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 , such as business process, data, use case, low-tech prototypes, provides 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 by those who understand their importance in eliciting requirements.

For Additional Learning:

Check out two of our modeling courses:
Data Modeling Course
Use Case Modeling Course

View our article: Oh No, You Gave Me What I Asked For (pdf). (You must be a Watermark Learning Member to access this article. Membership is free and allows you to access valuable skill-development tools, such as articles, webinars, eNewsletters and special discounts.)