Why Modeling Is the Hidden Challenge in Software Engineering—and How to Master It

What Is Modeling?

In various fields such as mathematics, physics, finance, and computer science, “modeling” means creating a mapping from the real world to a specific discipline’s abstract world.

Mathematical modeling : converting a real problem into a mathematical one, as in university competitions.

Physical modeling : representing physical phenomena (e.g., a block sliding down an inclined plane).

Computer modeling :

Business‑logic modeling – all business logic ultimately maps to three code structures: sequence, selection, and loop.

Data modeling – diverse data types (linear, tree, graph) are represented as two‑dimensional relational tables.

Algorithm modeling – examples include LR, decision trees, neural networks.

Why Do Humans Need Modeling?

Modeling is a simplification of reality because the human brain cannot hold all information of the real world. Models are inevitably imperfect (“all models are wrong”), but as long as the error stays within acceptable bounds, they remain useful.

Modeling as a Software‑Engineering Problem

Modeling is difficult for three main reasons:

Language ambiguity – natural language is vague and ambiguous, making precise requirements hard to express.

Real‑world complexity – the world is far more complex than any single discipline can capture.

Organizational factors – information silos, communication loss, differing stakeholder perspectives, rapid iteration, and the challenge of finding the right “fire” (balance between over‑design and under‑design).

Three Types of Modeling in Software Engineering

After requirements and product specifications are defined, software engineering typically goes through three modeling stages, each producing specific artifacts.

Business Modeling

Outputs include four items:

Business use cases

Business flow diagrams (swim‑lane or sequence diagrams)

System use cases

System use case specifications

The flow is: Business use case → Business flow diagram → System use case → System use case specification. A standard business flow diagram should use swim‑lanes that represent either a role or an entire system (not internal modules). The diagram treats each system as a black box; mixing internal technical details turns it into a system flow diagram.

Key points:

Define the correct number of swim‑lanes (participants).

Distinguish between business flow (value‑oriented) and system flow (implementation‑oriented).

Identify the true “user” of a value point – the organization’s external customers, merchants, or internal stakeholders.

Value points can be fragmented across multiple teams, leading to misalignment of user, company, team, and personal values.

Domain Modeling

Domain modeling bridges the gap between the business world and the computer world, serving as the most critical of the three modeling types.

Data Modeling

Data modeling is the most familiar to developers; it is taught in university courses on database principles and involves defining entities, relationships, and normalization (1NF, 2NF, 3NF, ER diagrams, primary/foreign keys).

System Use Case Specification

A system use case specification provides a detailed, structured description of the interaction steps required to achieve a system’s value point. It follows a formal template (e.g., as shown in the book “Software Methods”) and can be managed with tools like Enterprise Architect.

Conclusion

Understanding and correctly applying business, domain, and data modeling helps teams align on value, avoid ambiguous requirements, and build maintainable software systems.