When I evaluate the quality criteria of requirements models, I concentrate on three essential dimensions: syntactic, semantic, and pragmatic quality. Each plays a distinct role in determining how clearly and effectively a model communicates information. Syntactic quality ensures correctness of structure, semantic quality secures meaningful content, and pragmatic quality guarantees usability and understanding. Together, they define the overall effectiveness and reliability of any requirements model.
The Three Dimensions of Model Quality
A requirements model can fail in different ways.
It may violate the rules of its modeling language. It may follow every rule but describe the wrong system behavior. Alternatively, it may contain correct information but remain too complex for its audience.
Therefore, I assess three separate dimensions:
- syntactic quality: Is the model formally correct?
- semantic quality: Does the model represent the intended requirements correctly?
- pragmatic quality: Can the intended audience understand and use the model?
A high-quality requirements model must be formally correct, factually correct, and suitable for its intended purpose.
Syntactic Quality
Syntactic quality concerns the rules of the modeling language.
Every modeling language defines which elements I may use and how I may connect them. Therefore, I check whether my model follows these rules.
For example, BPMN defines specific rules for events, activities, gateways, sequence flows, and message flows. Likewise, UML defines syntax for elements and relationships in its different diagram types.
If I violate these rules, readers may interpret the model incorrectly. In some cases, the model may no longer have a valid meaning within the language.
Therefore, I ask:
- Do I use valid model elements?
- Do I connect them correctly?
- Do I follow the notation rules?
- Do I use each element according to its defined purpose?
Modeling tools can detect some syntactic errors automatically. However, tool support does not replace my own review. A tool can often tell me whether a relationship is allowed. It cannot always tell me whether I chose the right relationship.
Syntactic quality ensures that I express the model in the language correctly.
Semantic Quality
Semantic quality concerns the meaning of the model.
A model can follow every notation rule and still describe the wrong requirements. Therefore, syntactic correctness alone never guarantees a good model.
I compare the model with the relevant reality, stakeholder needs, requirements, and domain knowledge.
For example, a process model may use BPMN perfectly but omit an important exception path. Likewise, a state model may contain valid transitions but allow a state change that the real system must prevent.
I therefore examine two central questions.
First, is the information in the model correct?
Second, does the model contain all information that matters for its defined purpose?
These questions address correctness and completeness.
However, completeness does not mean that I must model everything. A model always reduces reality. Therefore, I only expect it to contain the information required for its purpose and scope.
Semantic quality means that the model represents the relevant requirements correctly and sufficiently completely.
This distinction is important. A simplified model can have excellent semantic quality if it deliberately focuses on a limited question. In contrast, a large model can have poor semantic quality if it contains incorrect assumptions or misses essential behavior.
Pragmatic Quality
Pragmatic quality concerns how well people can understand and use the model.
A technically correct and semantically accurate model can still fail if its audience cannot interpret it.
Therefore, I consider the intended users of the model.
A business stakeholder may need a different view from a software architect. Likewise, a tester may need more detail about conditions and alternative paths than a senior manager.
I therefore adjust the level of abstraction, detail, terminology, and presentation.
For example, I avoid unnecessary technical detail in a model that supports a business workshop. However, I add more precise conditions when developers or testers need the model for implementation or verification.
I also keep models visually manageable. Too little information can make a model ambiguous. However, too much information can hide the important relationships.
Pragmatic quality means that the right audience can understand the model and use it for the intended task.
Consequently, pragmatic quality always depends on context. The same model may work well for one audience and poorly for another.
The Three Criteria Depend on Each Other
I do not evaluate the three criteria in isolation.
A syntactically perfect model may contain incorrect requirements. A semantically correct model may violate notation rules. Likewise, a correct model may become useless because nobody can understand it.
Therefore, I need all three perspectives.
For example, consider a BPMN model of an approval process.
First, I check whether the BPMN notation is correct. That concerns syntactic quality.
Next, I check whether the process actually reflects the required approval logic, including exceptions. That concerns semantic quality.
Finally, I check whether the stakeholders can understand the model and use it to discuss the process. That concerns pragmatic quality.
No single quality criterion can compensate for serious weaknesses in the other two.
How I Assess a Requirements Model
I follow a simple sequence.
First, I check the syntax. Formal errors are usually easy to identify and should not distract from the deeper review.
Next, I review the meaning. I compare the model with requirements, stakeholder knowledge, domain rules, and other relevant information.
Finally, I review the model from the perspective of its audience. I check whether terminology, abstraction, structure, and detail support the intended use.
This sequence also helps me diagnose problems precisely.
If a model uses an invalid relationship, I have a syntactic problem. If it represents the wrong relationship, I have a semantic problem. If the relationship is correct but readers cannot understand it, I have a pragmatic problem.
That distinction makes model reviews more focused.
Conclusion
I use syntactic, semantic, and pragmatic quality as three complementary criteria for evaluating requirements models.
Syntactic quality tells me whether I use the modeling language correctly. Semantic quality tells me whether the model represents the relevant requirements correctly and completely. Pragmatic quality tells me whether the intended audience can understand and use the model.
A good requirements model follows the language, represents the right meaning, and communicates that meaning effectively.
By separating these three dimensions, I can identify model defects more precisely and improve requirements models systematically.
What’s Next?!
Now that you know what requirements modeling is and how it supports clear communication between business and technology, it’s time to explore the next layer — connecting written and visual requirements. Curious how both worlds come together in one model? In my next article, “Integrating Textual Requirements in SysML: A Personal Take,” I’ll share how I combine structured diagrams with textual details to create precise, traceable, and powerful system models.
See the Bigger Picture with Requirements Modeling
If I want to understand requirements beyond isolated statements, I need models that make systems easier to explore and explain. The main article on Requirements Modeling brings together essential Modeling Concepts, the dynamic view of Process Modeling with BPMN, and the structural perspective of UML. Therefore, it helps me connect ideas, workflows, and system structures in one clear framework. Click through to see how Requirements Modeling supports better analysis, clearer communication, and stronger system understanding.
This article covers concepts that are also included in the CPRE certification syllabus.