Clear software requirements can feel like a complex puzzle. Each stakeholder sees the system from a different angle. Therefore, Viewpoint Oriented Requirement Validation helps me compare perspectives, resolve conflicts, and build shared understanding. As a result, I improve collaboration and create requirements that better match real expectations.
What Is Viewpoint Oriented Requirement Validation?
Stakeholders rarely see a system in the same way. A customer focuses on business value. An operator considers daily work. A developer thinks about technical constraints. Meanwhile, a compliance specialist may focus on rules and risks.
These differences do not automatically indicate a problem. In fact, they often reveal information that a single perspective would miss.
However, problems arise when stakeholders make incompatible assumptions or use the same term differently.
For example, one stakeholder may require immediate access to customer data. Another may require strict authorization before anyone can access that data. Both requirements can appear correct when I examine them separately. Nevertheless, they create a conflict when I consider them together.
Viewpoint Oriented Requirement Validation therefore validates not only individual requirements but also the relationships between different stakeholder interpretations.
I use the method to identify these differences explicitly and resolve the important ones before development progresses.
Viewpoint Analysis and Viewpoint Reconciliation
I divide viewpoint resolution into two main activities.
Viewpoint Analysis
First, I analyze the available viewpoints.
I look for:
- contradictory statements
- inconsistent terminology
- missing information
- different assumptions
- overlapping requirements
- incompatible priorities
- different interpretations of the same process
- conflicts between business needs and technical constraints
For example, two departments may use the word “customer” differently. One may mean the person who signs the contract. Another may include every person who uses the service.
Neither definition is necessarily wrong. However, the difference can make requirements ambiguous.
Therefore, I do not immediately force both viewpoints into one model. Instead, I first make the difference visible.
A disagreement that remains hidden inside a requirement is difficult to solve. A disagreement that I describe explicitly becomes something I can analyze.
Viewpoint Reconciliation
Next, I reconcile the relevant differences.
Here, I determine why the viewpoints differ. I then work with the stakeholders to decide which interpretation, combination, or compromise should become part of the requirements.
Sometimes I can resolve a disparity through clarification. In other cases, I need a business decision.
For example, stakeholders may disagree about whether users can modify an order after submission. Analysis can identify the conflict. However, analysis alone cannot decide which business rule should apply.
Therefore, reconciliation requires communication and decision-making.
I document the result and, importantly, the reason behind it.
The goal is not to eliminate different viewpoints. The goal is to resolve the differences that would otherwise make the requirements inconsistent or incomplete.
The Core Concepts Behind Viewpoint Resolution
To apply Viewpoint Oriented Requirement Validation systematically, I distinguish several concepts.
Universe of Discourse
The Universe of Discourse defines the part of reality that I want to understand and describe.
It can include people, processes, information, business rules, systems, external organizations, events, and technical constraints.
In simple terms, it defines what belongs to the problem space.
This boundary matters. Otherwise, stakeholders may discuss different parts of reality while assuming that they discuss the same system.
Actors
Actors participate in or observe the Universe of Discourse.
I can broadly distinguish between a demand side and a supply side.
The demand side includes people such as customers, users, operators, subject-matter experts, and information providers. They describe needs, goals, processes, and constraints.
The supply side includes people such as requirements engineers, architects, developers, consultants, and managers. They analyze those needs and help create the solution.
However, I do not treat these groups as homogeneous. Two users can have completely different goals. Likewise, two technical specialists can interpret the same requirement differently.
Viewpoint
A viewpoint describes the position from which an actor observes the subject.
A person’s role, responsibilities, knowledge, objectives, and interests influence this viewpoint.
For example, a sales employee and a data protection specialist may examine the same customer database. However, they will probably focus on different qualities of that database.
A viewpoint explains why a stakeholder sees certain information as important.
Perspective
A perspective represents information captured from a particular viewpoint.
For example, I may document:
- data structures
- business processes
- interactions
- responsibilities
- events
- business rules
Therefore, the viewpoint describes the observer’s position, while the perspective contains what I model from that position.
This distinction helps me avoid treating every model as an objective representation of reality.
View
I create a view when I integrate relevant perspectives into a more coherent representation.
A view should not simply combine everything stakeholders have said. Instead, I must resolve important inconsistencies first.
As a result, the resulting view represents agreed knowledge rather than an accumulation of conflicting statements.
Hierarchies
Hierarchies help me organize complex information.
For example, I can use an “is-a” hierarchy to classify concepts:
Vehicle
→ Car
→ Electric Car
I can also use a “part-of” hierarchy to describe composition:
Order
→ Order Line
→ Product
These structures are useful because stakeholder disagreements often concern classification or decomposition.
How I Apply Viewpoint Oriented Requirement Validation
I can use viewpoint resolution without turning it into a complicated formal exercise.
First, I identify the stakeholders who possess relevant knowledge or decision authority.
Next, I determine which viewpoints matter for the requirement under examination. I may consider business, user, operational, technical, legal, security, or data viewpoints.
Then, I capture the relevant perspectives separately. This prevents one dominant stakeholder from defining the model too early.
After that, I compare the perspectives systematically.
I record each significant disparity. For example:
- Stakeholder A says an order cannot change after submission.
- Stakeholder B says customer service can change an order until shipment.
- The process model currently contains no exception.
- Therefore, the requirement and process model conflict.
I then classify the disparity.
It may represent:
- a contradiction
- an ambiguity
- missing information
- a terminology problem
- a different level of abstraction
- a business-rule conflict
- a different priority
Next, I investigate the reason.
Finally, I reconcile the disparity with the relevant stakeholders and update the affected requirements and models.
I consider a disparity resolved only when the resulting requirement is clear and I can trace the decision that resolved it.
A Practical Example
Suppose I define requirements for an online ordering system.
The customer service viewpoint states:
Customer service must be able to modify submitted orders.
However, the accounting viewpoint states:
Submitted orders must not change after invoicing.
At first, these requirements appear contradictory.
Therefore, I investigate the underlying process.
I discover that customer service needs to modify orders only before invoicing. Accounting needs the financial record to remain stable after invoicing.
I can now reconcile the viewpoints:
Customer service can modify a submitted order until the system creates the invoice. After invoicing, the system must prevent direct modification and require a defined correction process.
The conflict revealed an important business rule that neither original requirement expressed completely.
This is one of the main strengths of viewpoint validation. Different perspectives do not merely create problems. Instead, their differences can expose missing requirements.
Where VWPL Fits
Formal approaches to viewpoint resolution have used languages such as VWPL to describe and compare viewpoints systematically.
In such an approach, analysts can model several perspectives of the Universe of Discourse, such as data, processes, and actors. They can also organize concepts through hierarchies. They then compare these models to identify disparities.
The analysts analyze each disparity and reconcile the underlying viewpoints. They repeat this process until the resulting views become sufficiently consistent.
I do not need VWPL to use the underlying principle in everyday Requirements Engineering. However, the formal approach illustrates an important idea.
I should represent viewpoints explicitly before I try to reconcile them.
Otherwise, I risk creating apparent agreement by merging information too early.
What Viewpoint Validation Improves
Viewpoint Oriented Requirement Validation gives me several practical advantages.
First, it exposes conflicts earlier. Therefore, I can address them before they reach design, implementation, or testing.
Second, it reveals hidden assumptions. Stakeholders often consider their own knowledge obvious and therefore do not state it.
Third, it improves completeness. When I compare perspectives, one stakeholder often identifies information that another stakeholder omitted.
Moreover, it improves terminology. I can detect when different groups use the same word for different concepts or different words for the same concept.
Finally, it strengthens traceability. I can document where a requirement came from, which viewpoints affected it, which conflicts occurred, and why stakeholders selected the final solution.
Viewpoint Validation Is Not Consensus at Any Cost
I do not expect every stakeholder to agree with every decision.
Some requirements involve genuine conflicts of interest. A security requirement may reduce convenience. A regulatory constraint may limit a business process. A budget restriction may prevent a technically preferable solution.
Therefore, reconciliation does not always produce consensus.
Sometimes the correct result is an explicit decision by the person who has the necessary authority.
Good requirements validation makes disagreement visible, structured, and decidable. It does not hide disagreement behind vague wording.
Final Thoughts
Viewpoint Oriented Requirement Validation gives me a structured way to deal with a basic reality of Requirements Engineering: different stakeholders understand the same system differently.
I first capture those differences. Then, I analyze contradictions, assumptions, gaps, and terminology. Afterward, I reconcile the relevant viewpoints and document the resulting decisions.
This process improves more than consistency. It can reveal requirements that no stakeholder expressed completely on their own.
A strong requirement does not merely describe one stakeholder’s perspective accurately. It survives comparison with the other viewpoints that matter to the system.
What’s Next?!
Now that you’ve discovered how Viewpoint Oriented Requirement Validation helps align diverse perspectives, it’s time to go deeper. Validation is only one part of the quality equation. To fully understand how requirements are checked and confirmed, explore the next article — The Difference Between Requirements Verification and Validation — and learn how both processes work together to ensure accuracy and success.
Connect Requirements Work from Idea to Delivery
I use Requirements Engineering to create a clear path from early needs to successful systems. First, it helps me elicit stakeholder expectations and document them in a structured way. Then, it supports validation, testing, and continuous requirements management. Moreover, system analysis helps me understand context, interfaces, and constraints. Read the main article on Requirements Engineering to see how these activities work together and why they matter for better software decisions.
Credits: Photo by RDNE Stock project from Pexels