Context Unleashed: The Secret Weapon of Business Analysts

We’ve all heard the phrase, “Context is everything.”. In business and software development, this is especially true. Without analyzing the context, we might misunderstand the client. Without studying the context, we impose our own, based on previous projects. And that’s a big mistake.

This can lead to creating an unsuitable product because we don’t grasp the full situation.

Whether the weather affects business outcomes or not — it influences many things and processes. Whether we buy from a neighbour or import from other countries determines the complexity of the process and whether it will be in focus. Whether we sell perishable goods or not influences how we approach procurement and storage. Understanding the context helps us understand the goals and reasons, why things are the way they are and changes in which direction will be improved, not the other way around.

For instance, when choosing a car, we make decisions based on our context: do we need it for city driving or travelling? Do we drive on asphalt or off-road? Is it for family use or to show off in front of friends? How many people should it accommodate? What’s our budget for fuel and the purchase?

Different people will need different cars based on their unique contexts. There’s no one-size-fits-all solution.

Therefore, it’s crucial to thoroughly study the context at the beginning of a project and build with thoughtful consideration.

Context is everything related to the business; context is the environment of the business, and new goals are supposed to be reached within the context. The context affects the change and is affected by the change concurrently. Context helps us reveal why the change is needed and broadens our vision of the need.

This can involve relationships, culture, terminology, processes, products, projects, sources of losses and incomes, sources of funds, sales, technology, infrastructure, languages, legislation, competitors, demographics, seasons, weather, and others.

How do we investigate it?

Besides specific techniques related to the mentioned things such as Organizational charts, process modelling, Business rules, Market research and others, we can apply techniques that help us to investigate and analyze the context as a big picture:

Glossary

Domain diagram or the conceptual level of the data modelling

Conceptual modelling

The glossary helps us to define relevant business concepts and should be maintained and continue to be filled in during the whole project.

We can use glossary entities in the next techniques. Let’s start with the Domain diagram or the conceptual level of the data modelling.

It is easy to find entities by listing each noun separately. Next, we should check all possible connections between entities by combining any pair.

For example, you identify entities related to the sales process: client, order, product, and price.

Then we inquire about the relationships between pairs of entities: how many orders can one client have? Can one order belong to multiple clients simultaneously? One client — many orders. One order — one client.

How many products can be in one order? Can one product be in several different orders? One order — many products. One product — many orders.

Is the product directly linked to the client? No, it can be bought by different clients.

How many prices can a product have? Several, depending on the discount.

So, in the end, we will have a conceptual model where 1 means one, and n — many.

And so on for all possible pairs.

Understanding all components of the business will not only help us understand it but will also serve as the foundation for building the system architecture. Later on, this model will become more detailed and evolve into a logical and physical data model.

Furthermore, it helps us uncover deeper questions and identify entities within the system itself. For example, if a client can only have one address, and it’s not associated with other entities, you can make the “Address” field part of the “Client” entity. But if a client can have multiple addresses, and these addresses are linked to geolocation, for instance, then addresses should be a separate entity with a one-to-many relationship to the client.

Moreover, like everyone else, this technique helps generate questions to further unearth requirements.

Concept modelling.

Like the domain diagram (conceptual level of the data model), it begins with collecting all nouns and organizing the glossary. However, it doesn’t stop there. Next, we capture all verbs related to nouns. In other words, what actions one entity can perform concerning another, we add these verbs to the diagram.

It might look like this:

Additionally, we explore each entity to determine:

• Whether they have a classification.
• Whether they have categories.
• Whether this entity is part of another (sub-entity) or has other entities as parts (parent entity).
• Whether the entity relates to a role or set of roles.

This is standard usage, resulting in a lot of structured information about the domain, business, and product.

My customization:

During the identification of verbs, I apply questions to expand those verbs, such as:

• How?
• Where?
• How is it understandable that it’s successful?
• What can hinder?

This way, I uncover the implicit entities and their contexts.

Let’s try: The customer makes an order.

How does the customer make an order?

Where does the customer make an order?

How does a customer understand that an order is made and received?

What can hinder making an order?

If we add the question “How many?” — “How many orders might a customer make?” we create 2 diagrams at once: A conceptual model and the highest level of Data model.

I hope it was helpful and you are eager to try it in your work.

You will be surprised how many details it uncovers and how many questions it enables you to generate.