As a Requirements Engineer, I use interdisciplinary ideas to solve stakeholder challenges more clearly. Piaget’s Schema in requirements engineering helps me understand how people structure and process information. Therefore, I can improve communication, reduce misunderstandings, and support better problem-solving in complex projects.
What is a schema in Piaget’s theory?
Jean Piaget used the concept of schemas to explain how people organize knowledge and interpret experience. A schema represents a structured way of understanding something.
People do not process every new situation without context. Instead, they connect new information with structures they already have. As a result, previous knowledge influences what they notice, how they interpret it, and what they expect.
For example, a stakeholder may already have a clear idea of what an “order,” “customer,” or “approval” means. However, another stakeholder may associate the same word with a different process or business rule.
A shared term does not necessarily mean that stakeholders share the same understanding.
This is where the schema concept becomes useful for my requirements work.
Why schemas matter in requirements engineering
During elicitation, stakeholders rarely describe a system from a neutral perspective. They rely on their experience, responsibilities, terminology, and existing processes.
Therefore, two stakeholders can observe the same business process and construct different explanations of it.
A sales employee may understand a customer as someone who has placed an order. In contrast, a marketing employee may include prospects. Meanwhile, accounting may only recognize customers that have a financial account.
None of these perspectives must be wrong. Instead, each perspective reflects a different conceptual structure.
I therefore treat stakeholder statements as evidence of an underlying mental model, not automatically as complete requirements.
My task is to uncover these models, compare them, and establish the distinctions that matter for the system.
Assimilation: fitting new information into existing knowledge
Piaget described assimilation as the process of interpreting new experiences through existing schemas.
I can observe a similar pattern during requirements elicitation. When stakeholders encounter a new system or concept, they often explain it through something they already know.
For example, a stakeholder may describe a new workflow as “basically the same as our current approval process.” This comparison helps me understand the starting point. However, it can also hide important differences.
Therefore, I ask what remains the same and what changes.
I might examine:
- roles and responsibilities
- business rules
- triggers
- process steps
- information
- exceptions
- decisions
- expected outcomes
This allows me to use the familiar concept without assuming that the new situation works identically.
Accommodation: changing the existing mental model
Assimilation does not always work. Sometimes new information contradicts the existing schema.
Piaget called the adjustment of a schema accommodation.
I see this when stakeholders discover that their original understanding cannot explain a requirement or business situation. For example, they may initially assume that every order belongs to one customer. Later, I may discover that the business also supports anonymous orders or purchases involving several organizations.
The original model must then change.
A contradiction during elicitation is often useful because it reveals where an existing understanding no longer fits reality.
Therefore, I do not try to remove contradictions too quickly. First, I investigate them.
I ask for examples, exceptions, boundary cases, and counterexamples. As a result, I can determine whether I need to refine a definition, split a concept, add a business rule, or revise the underlying model.
I use models to make schemas visible
Mental models remain difficult to compare while they exist only in people’s minds.
Therefore, I externalize them.
Depending on the problem, I may use:
- process models
- context diagrams
- state models
- use cases
- data models
- UML diagrams
- decision tables
- glossaries
A model gives stakeholders something concrete to examine.
For example, a stakeholder may agree with a verbal explanation of a process but immediately notice a missing path when I represent the same process visually.
This does not mean that the diagram creates the knowledge. Instead, it helps expose assumptions that previously remained implicit.
I use requirements models not only to document knowledge but also to test whether stakeholders understand a subject in the same way.
Different schemas can create stakeholder conflict
Some requirements conflicts are not primarily conflicts of interest. Instead, stakeholders may structure the problem differently.
One stakeholder may think in terms of organizational departments. Another may think in terms of customer journeys. A developer may think in terms of system components, while a business specialist thinks in terms of activities and responsibilities.
Consequently, they may disagree even when they pursue compatible goals.
The schema concept reminds me to investigate the conceptual difference behind the disagreement.
I can ask:
What does this concept mean to each stakeholder? Which distinctions does each person make? Which assumptions differ? Which examples support each interpretation?
Once I make those differences explicit, I can discuss the actual requirement more precisely.
Schemas also change during elicitation
Requirements elicitation does not simply transfer existing knowledge from stakeholders to me.
The conversation itself can change how everyone understands the problem.
A stakeholder may discover an exception while answering a question. Another stakeholder may introduce information that changes the original interpretation. A process model may reveal a missing decision. A prototype may expose an assumption that nobody had previously questioned.
Therefore, requirements work is partly a learning process.
Good elicitation can change the stakeholders’ understanding of the problem as well as my own.
This is one reason why I refine requirements iteratively rather than assuming that the first statement represents a stable and complete need.
How I apply the schema concept in practice
I use Piaget’s concept as a thinking aid rather than as a formal requirements engineering technique.
First, I identify the concepts stakeholders use. Then, I ask what those concepts mean to them. Next, I look for assumptions, examples, exceptions, and conflicting interpretations. After that, I make important structures visible through definitions or models. Finally, I validate the resulting understanding with the relevant stakeholders.
Throughout this process, I remain alert to both assimilation and accommodation. Sometimes new information fits an established model. In other cases, the model itself needs to change.
What Piaget’s schema concept adds to requirements engineering
Piaget did not develop schema theory for requirements engineering. Therefore, I do not treat it as a substitute for established elicitation, modeling, validation, or requirements management practices.
Instead, I use it to understand an important aspect of stakeholder communication: people interpret information through structures they already possess.
That insight changes how I listen.
I pay more attention to terminology. I question apparently obvious concepts. I investigate contradictions. Furthermore, I use examples and models to uncover hidden assumptions.
For me, the practical value of Piaget’s schema concept lies in recognizing that requirements depend not only on what stakeholders say, but also on how they currently understand the world they are describing.
Once I understand that structure, I can help stakeholders develop a clearer shared understanding. As a result, I can formulate requirements that are more precise, consistent, and useful.
What’s Next?!
Understanding how people think through Piaget’s Schema is only one part of better collaboration. Therefore, I continue with Understanding Cognition: A Requirements Engineer’s Perspective to explore how stakeholders process information, remember details, and form decisions. After that, the next step is mastering how I communicate these insights effectively. Strong communication bridges gaps between stakeholders, reduces misunderstandings, and drives project success. Ready to take your teamwork to the next level? Continue with Effective Communication in Requirements Engineering for Successful Projects.
Explore the Full Requirements Engineering Journey
Continue with Requirements Engineering to see how I turn unclear ideas into clear system direction. In the main article, I connect elicitation, documentation, validation, testing, management, and system analysis into one practical overview. Therefore, you can see how each activity supports better communication, stronger decisions, and more reliable software. As a result, requirements engineering becomes a complete path from early stakeholder needs to systems that create real value.
Then read Personal Growth to strengthen the human side of requirements work. In the main article, I connect self-understanding, change, habits, discipline, decisions, stress, personality, cognition, and openness with practical stakeholder work. It also shows how personal growth improves stakeholder management, elicitation, body language, presentation, storytelling, repartee, negotiation, and effective communication. Therefore, you can grow as a person and become more effective as a requirements engineer.
Credits: Photo by Andrea Piacquadio from Pexels