How Static Modeling Skills Can Improve Your Performance as a Business Analyst


Static Model - Class Diagram - Fact ModelWhile most business analyst roles don't explicitly require static modeling expertise, developing a better understanding of static modeling concepts can be a measurable forward step for business analysts seeking to develop new competencies. Such skills can be useful in many aspects of the BA work, from obtaining a better understanding of stakeholders' information needs, to documenting those needs in unambiguous ways and communicating them more effectively to the technical team.

The static (structural) model

Most business analysts are more used to working with dynamic (behavioral) models than with static (structural) models. While dynamic models (workflow diagram, use case diagram, process model, etc.) define what a system does, static modeling is used to define what a system is.

Static models, including class diagram, domain model, context diagram, and data flow diagram, deal with the description of objects.Static modeling can be used to unambiguously depict the logical aspects of the data components of a business problem, improving not only communication, but also the discovery and further investigation of business requirements.

How static modeling helps define better solutions

The quality of project requirements starts with a project glossary (a dictionary of relevant terms). A good glossary removes ambiguity, reduces the risk of misunderstandings, and speeds up communication by allowing abstract terms to be consistently used within the project. As the project evolves, a business analyst with solid modeling skills will be able to develop a series of models to augment the natural language requirements documentation produced. Such a BA will be able to choose, among the various types of models available, the best alternatives to properly capture the business subject matter.

Many business analysts focus exclusively in the description of software behavior (the dynamic model). However important dynamic models are, they do not do not adequately represent considerations of structure and dependency management. For example, based exclusively on a use case “update employee profile” for its HR system, a company with many subsidiaries could miss the requirement that employee-employer should be a many-to-many relationship to account for employees working for more than one of its subsidiaries. Focusing on the “nouns” of the system and the relationship between them, static models complements the work done during the dynamic analysis, preventing that important requirements are overlooked. Ideally, BAs will iterate between dynamic and static models, driving them to converge on an acceptable solution.

How knowledge of data concepts can improve project communication

The BA is at the center of all communications among the groups involved in a software project, interacting with everyone from project sponsors and subject matter experts to developers, database administrators, QA, user interface designers, and other professionals on the project team. Besides being useful for defining and communicating core aspects of software requirements, knowledge of static models can help BAs act as a “bridge” to help teams overcome problems created by specialized roles that have difficulties relating to each other, as in the following scenarios:

  • a data architect too focused on the overall data needs of the organization is failing to take into consideration the immediate needs of a project team;

  • a database administrator overly concerned with “protecting” the databases from change is slowing the progress toward meeting the data needs of a group of stakeholders;

  • a senior Java developer unfamiliar with data concepts is refusing to discuss database normalization during the design phase, putting in risk the consistency of the application data;

  • a data modeler used to the traditional model of creating a mostly complete domain model upfront is having trouble working with a team using an agile/evolutionary framework.

A BA with good knowledge of static modeling will be much more effective at avoiding tension between those different roles and at removing the communication barriers that prevent individuals from reaching consensus about what needs to be done. Ellen Langer, professor of psychology at Harvard University, did a study that showed that including listeners in the reason why something is happening increases their cooperation rate from 60 to 94%. Oftentimes alternatives or constraints surface during a project, and modeling kills will help the business analyst to act as an effective mediator. Knowledge of data concepts will enable the BA to become a better liaison between the business and technical teams and between different specialized roles, helping ensure that the optimal decisions can be made throughout the implementation process.

Static modeling and related skills a business analyst should develop

Static models are important to get across project requirements in an unambiguous, standardized way, and help ensure a better alignment among different sets of stakeholders and members of the project team. You might find that enhancing your knowledge about the following topics will help improve your elicitation, communication, negotiation, and collaboration skills:

Relational database technology
The basics of RDBs, the challenges surrounding the technology, and when it is appropriate to use RDBs.

Object orientation
With the prevalence of programming languages such as Java, C++, etc., and agile development, object-oriented technology has become the approach of choice for software development. BAs should gain a basic understanding of the object paradigm to be able to understand where application developers are coming from, and to be able to communicate well with them. This includes understanding basic concepts such as inheritance, polymorphism, and object persistence, as well as class normalization, the object oriented version of data normalization.

Unified Modeling Language (UML).
UML diagrams, when appropriately used, can help the project team overcome many project complexities. UML can be used as part of modeling, analysis and documentation of business requirements, as well as during the transition to software design. In addition to the more common UML dynamic models, such as use-case, workflow, and sequence diagrams, business analysts should make an effort to develop an understanding of the class diagram (the UML standard type of diagram for static modeling, used to represent the domain model).

How object and relational technologies work together.
Because projects will typically use object technology and relational databases together, it is important for a BA to understand the mismatch that can happen between the two technologies, and how to overcome it.

Fact models
As Ronald Ross explains in
this article, a fact model provides the basis for consistent and unambiguous verbalization of business rules and other form of operational knowledge. Fact models are useful to unambiguously communicate ideas between the business and technical domains because they use verbs to clarify important ideas that would normally remain hidden in a data model or class diagram.

Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions. Adriana offers executive-level, management consulting on technology and process solutions and expertise in business-side IT operational functions and processes at Beal Projects.

Like this article:
  24 members liked this article


inptisto posted on Monday, October 18, 2010 5:54 PM
Very Good Article.

chrisM posted on Tuesday, October 19, 2010 6:20 PM
Thanks for the article. It made me realize that in my organization we focus too much on software behavior and it would be a good topic to discuss in one of our next meeting, how to incorporate static modeling into our process.
maximus posted on Saturday, October 30, 2010 12:54 AM
You are swinging so far to System Analyst infusion - that you lose the plot of the fundamentals of a Business Analyst – totally disagree that this is a role of a Business Analyst. You are working upstream – Systems knowledge and modeling – hello

There is a demarcation - Business Analyst evolved from System Analyst - simply because they didnt understand Business Requirements - now you lead us back to Adam and Eve - Demarcation of skills is required - or DMZ

Sorry Mate - otherwise appreciated the effort
Mick Wren posted on Thursday, November 4, 2010 7:01 AM
Adriana, it is a damning statement of the state of our 'profession' that you even need to write this article. The primary role of any anlayst is to understand and static modelling techniques provide enormous value in understanding a business. I always (whether it is requested or not) combine dynamic and static modelling (the verbs and nouns).

Your article possibly confused things in mentioning all the 'physical' or system aspects such as OO and UML which is the only reason I can think it evoked the above response from scuze (Oct30, 12:54)(Although there's no excuse for his tone.) This is not a systems issue it is a business issue. Businesses use process and data regardless of which techology is or is not used and these logical modelling techniques need to be used by any self respecting analyst.
Vergis thomas posted on Thursday, November 4, 2010 9:23 AM
Hi Adriana,
Fully Agree with you. Static modelling can be used by a BA to understand the relationships between Oragnisations, Departments, persons, Systems , Systems components depending on what level the analysis is being done.

Then a matrix can be drawn between dynamic behaviour and Static entity. this can be a Use case to entity matrix. this will help in validating the analysis by identifiying missing entities and missing use cases.
zarfman posted on Saturday, November 6, 2010 1:43 AM

In your paper you discuss dynamic and static modeling. My understanding is that a dynamic system takes into consideration time, static systems do not. Time can be discrete or continuous. Models can be linear or non-linear. Do the models consider or implement the concept of feedback? Moreover, I consider corporations to be affected by time, uncertainty, and exogenous influences. Witness the last three or four years of what one might call disorder in corporate systems. You didn’t seem to touch on these modeling problems.

Vergist wrote; then a matrix can be drawn between dynamic behavior and Static entity. This can be a Use case to entity matrix. This will help in validating the analysis by identifying missing entities and missing use cases.

Zarman writes; I have no idea how one would construct such a matrix. What kind of transform would one use to accomplish such a task?


Adriana Beal posted on Sunday, February 6, 2011 12:30 PM
My apologies to all for not offering any responses to your comments or questions before today -- I never received a notification from this page to know that comments existed.

@scuze: no need to apologize; different viewpoints are always welcome. I suggest you visit Bridging the Gap ( where a smart community of BA frequently discusses this demarcation you talk about, with may different views by experienced BAs.

@mick.wren: I don't necessarily agree with your interpretation of my article mixing "physical aspects", but the comments area here is not very conducive of a more elaborate discussion. You are welcome to write to my email hello [at] adrianabeal [dot] com to continue the conversation about this topic. I appreciate you taking the time to share your views!

To anyone else who left comments, a big thanks for observations, and the same I wrote to Mick applies to you--feel free to contact me with questions, objections or comments.


Mick Wren posted on Monday, February 7, 2011 5:27 AM

I'm not sure that we need a more elaborate discussion. I agree entirely and very strongly with your premise that we, as BAs, need to use both static and dynamic models. My only concern was your inclusion of OO and UML. Having re-read those paragraphs I agree with the points you make about needing to understand these approaches but those points detract from your key message. We don't need OO or UML to do either dynamic or static business modelling.

Regarding the Ronald Ross article you link to, he's making all sorts of assumptions about how data modelling is done. I've been logical data modelling for over 25 years and, by using meaningful relationship names have been capturing most, if not all, of the verbish rule types he mentions.

As for demarcation, BAs don't take nearly enough responsibility for representing the business through the lifecycle. Systems designers and developers should be answerable to BAs for any denormalisation (which in itself requires the BA to have a mastery of normalisation) or any other physicalisation decisions that compromise or constrain the business solution. (That should get a few responses).

Maybe you're right after all. This may require a more elaborate discussion.


Adriana Beal posted on Tuesday, February 8, 2011 9:02 PM

Thank you for clarifying what you meant. Yes, I agree, we do not need OO or UML to do static business modeling.

The idea behind this article was to point out some opportunities for BAs looking for areas to expand their competencies (other authors and I are always getting this type of question, "what areas should I be focusing on to develop my expertise?"). Like you, I think that exploring static modeling concepts is important for BAs, many of whom tend to focus exclusively on dynamic models. My reason for suggesting reading about topics such as relational database technology, OO and UML is that, based on my experience, they make it easier for someone to gain more understanding about static modeling. I hope I didn't give the impression that I am suggesting that BAs should become experts in UML, nor that it would be a good idea to have a BA in charge of doing physical database modeling, for example.

Re: Ronald Ross article, I don't necessarily agree with all his statements either, but I consider his work worth checking out for anyone interested in learning more about business rules and related topics.

I truly enjoyed reading your views, and hope we can keep the conversation going (perhaps at the Modern Analyst forum at LinkedIn? This small box for comments with even smaller letters are definitely not conducive to a good conversation :-).


Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC