The gathering of requirements is part of the requirements management in method engineering. In order to model a complex system the knowledge about what should be modeled needs to be available. Requirements engineering is a process, which covers this topic. Besides the modeling itself it consists of elicitation. This paper focuses on a method, which is performed during the elicitation. More specifically, it is a method for validating requirements through viewpoint resolution. The main article used for this paper was Requirements Validation Through Viewpoint Resolution  by several members of the IEEE. This research proposes a specific technique of validating requirements, with the use of a viewpoint language, and is therefore also the origin of the method. For the first step of the method an article called Requirements analysis of large software systems  is used as well. Futhermore, university documentation  was used for the SPM framework and maturity levels. Since some concepts were not clearly defined in those articles some other research  is also used.
Before the process of requirements engineering takes place, the system engineering process is executed. This process has certain deliverables like the context definition and goals of a software artifact. The context set resulting from this process is called the universe of discourse. Some examples are software for monitoring systems, medical systems in hospitals or navigation systems for airplanes. This is an important part of the process of requirements engineering, since the process takes part in this universe. Furthermore, the process can be divided into two main parts; elicitation and modeling. By using viewpoints during elicitation it is possible to give validation in a very early stage. This technique, called viewpoint resolution, compares distinct views. It supports negotiations by providing scheme for negotiation of conflicts. The main result is the unfolding of knowledge for the modeling part of requirements engineering. Viewpoint resolution can determine discrepancies between two different viewpoints. It classifies and evaluates those discrepancies and integrates alternative solutions into one representation.
In order to make viewpoint resolution possible, it is necessary to know what viewpoints to consider. This can be done by first identifying the actors, which have different viewpoints. This is one of the steps of the universe of discourse definition. Actors can be users on the demand side, but also software engineers on the supply side. After the actors are identified, a selection is made to choose which actors are to be considered in a viewpoint resolution scheme. One of the deliverables is an abstract user tree. This tree shows all the actors with their level of abstraction. This tree can be composed using a set of heuristics . As shown in Figure 1 an abstract user tree consists of a main actor with underlying actors, which again can have underlying actors themselves. Table 1 shows a clear definition of the actor.
|ACTOR||Actors are the different people involved in the universe of discourse. Basically, we could divide actors into users on the demand side and software engineers on the supply side (Leite, J. F., Freeman, P.A., 1991). A set of heuristics can be used to compose such an abstract user tree (Burstin, M., 1984).|
Of course the relationships between entities and attributes, also known as facts, need to be validated. However, this method assumes these facts are already available before the viewpoint resolution strategy is performed. It is therefore no part of the method and not displayed in the meta-model. Table 2 shows a compact definition of the sub-activities mentioned before.
|Universe of discourse definition||Identify actors||The task of identifying which viewpoints to consider is one that depends on the identification of which people are in the universe of discourse. An identified person is called an ACTOR.|
|Choose actors||Once an ACTOR is identified, some policy may be used to choose if it is going to be considered in a viewpoint resolution scheme, when all others are identified as well. An abstract user tree is made by an aggregating the ACTOR.|
An actor can have different perspectives for a certain system. One perspective could be how he sees the data structure of a system. Another one could be the way he sees the processes of that system. Since there is a high probability they do not correspond, critiques will be brought forth. An actor will create an agenda which consists of all his or her critiques. This will be used as input for the actor's view. The actor will update the view until no further critiques in the agenda hold. The definition of each of the explained terms is presented in Table 3.
|AGENDA||A document containing problems of identification of discrepancies and the classification of these discrepancies to base evaluation and integration of viewpoint upon (Leite, J. F., Freeman, P.A., 1991).|
|CRITIQUE||A result of analysis of perspectives used for individual integration of producing a final view (Leite, J. F., Freeman, P.A., 1991).|
|PERSPECTIVE||A perspective is a set of facts observed and modeled according to a particular
modeling aspect and a viewpoint. An example of such a particular modeling
aspects is what is known as "data modeling" (Leite, J. F., Freeman, P.A., |
|VIEW||A view is an integration of perspectives. This is achieved by a view-constuction process. (Leite, J. F., Freeman, P.A., 1991).|
There will of course still be different views, because of the different actors involved. As stated before, this validates requirements through viewpoint resolution. Now the views of actors are derived the viewpoints can be analyzed. A short description of each sub-activity can be found in Table 4.
|View constructing||Analyze perspectives||An ACTOR (i.e. a system analyst) use different PERSPECTIVES to improve their own VIEW. Once a series of CRITIQUES is provided, each ACTOR solves the internal conflicts by updating an AGENDA and integrates his final perception into a VIEW.|
|Solve internal conflicts||In order to construct a VIEW, a system analyst describes the problem using different perspectives.|
This method uses a rule-based language called VWPL (Viewpoint Language) to express functionality and constraints for the elicitation of requirements. This way different views or perspectives can be automatically compared. This is done by a static analyzer, which can detect differences between two almost similar rule sets. Since a perspective or view can be translated to such a rule set, rule pairs can be made of similar type rules. For this the static analyzer produces the most alike rule pairs. After all possible rule pairs are recognized by the static analyzer, it has to identify the most probable rule sets. Some rule sets cannot be linked to other rule sets, because they deviate too much from every other rule set. In this case, the rule set will be identified as rules with no pair. Both elaboration processes will run parallel, because the static analyzer does not prioritize one above the other. After determining the rule pairs, discrepancies between those sets can be derived by the static analyzer.
|DISCREPANCY||A result of comparing two different rule bases, each one representing a different view of perspective according to a viewpoint (Leite, J. F., Freeman, P.A., 1991).|
|RULE||Part of a representation of a perspective or viewpoint made in a rule-based language. (Leite, J. F., Freeman, P.A., 1991).|
|RULE PAIR||The result of matching rules (Leite, J. F., Freeman, P.A., 1991).|
|VIEWPOINT||A viewpoint is a standing or mental position used by an individual when examining or observing a universe of discourse. It is identified by an individual, e.g., his name, and his role in the universe of discourse, e.g., a systems analyst, programmer of manager (Leite, J. F., Freeman, P.A., 1991).|
|SRS||A software requirement specification is an abstraction of an implemented
(or to be implemented) software system (Tran-Cao, D., Levesque, G., Abran, |
A discrepancy has a certain type. Three different types of discrepancies are possible. These are:
After the identification of all discrepancies a final viewpoint can be made that conforms to the view of an actor and can be used as a guide for the SRS (Software Requirements Specification). This document contains a complete description of the behavior of the system that needs to be developed. Table 6 shows description of each of the mentioned sub-activities.
|Viewpoint analyzing||Produce most alike rule pairs||Given two sets of production rules in the viewpoint language, the most alike (most similar) RULE PAIRS are produced.|
|Identify most probable rule pairs||Given alike RULE PAIRS produced by the static analyzer, the most probable RULE PAIRS are identified.|
|Identify rule with no pair||Given alike RULE PAIRS produced by a recognition strategy process, the RULES with no pair are identified.|
|Identify discrepancies||Given the most probable RULE PAIRS a DISCREPANCY can be identified, having one certain type being wrong information, missing information of inconsistency.|
Figure 4 displays the entire process deliverable diagram of the method. All connections between the deliverables can be seen in this figure, including those between the different subfigures. It shows a view and perspective can be translated to a rule set. Here we see the actor also has one certain final viewpoint after the processes are executed, which conforms to the view of an actor.
Since this paper describes the method in several parts, each of those parts is explained with the use of an example. As shown in Figure 2 users can be defined by using an abstract user tree . This implies it has a root, which splits up into one or more subusers, containing subsubusers and so on. Figure 5 shows a tree that represents the users of a software system for a certain library. In this case all actors are called users and the universe of discourse is the software system for the library. The term actor, as represented in the process deliverable diagram, is actually the name for a user in a certain universe of discourse.
Imagine all users initially were identified as staff users, ordinary borrowers and senior members, each having certain subusers. Furthermore, a software system needs to be made for people between 10 and 50 years old. The process of choosing relevant actors after identification can lead to the removal of the senior members group, leaving us with staff users and ordinary borrowers the tree as represented in Figure 7. This completes the universe of discourse definition section of the diagram, since facts are not treated as mentioned in the process chapter.
After the universe of discourse definition the views will be constructed. As shown in Figure 3 an actor can have multiple perspective of a system. An example could be that an actor has two perspectives represented by a data model and a process model. Checking out a book is a process in the process model, but the data model has no book entity. While analyzing these perspectives, the actor will bring forth this critique in an agenda together with other critiques. The actor will use this agenda to solve his or her own conflicts and make final view. In this case the book entity could be included in the process model to confirm with the data model.
As mentioned in the process section views and perspectives can be represented in the rule-based language VWPL. While perspectives in this language are compared to bring forth critiques, views are compared for viewpoint analyzing. Figure 6 shows views of different actors.
This is a clear example of a rule pair produced by the static analyzer, because of the similar type of construction. According to Figure 4 the static analyzer will identify the most probably rule pairs and rules with no pair. Since the example not only has a similar construction, but also similar facts, like officer and sailor, the static analyzer will identify them as a probable rule pair. After this the static analyzer will identify the discrepancies. This is represented with the red ovals and arrows and will be explained from top to bottom:
 Leite, J.F. (1991). Requirements Validation through Viewpoint Resolution. IEEE Transactions on Software Engineering, 17(12), 1253-1269.
 Burstin, M. (1984). Requirements analysis of large software systems. Israel: Ph. D. diss., Tel-Aviv University.
 Weerd, I. van de, Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., Bijlsma, L. (2006). On the Creation of a Reference Framework for Software Product Management: Validation and Tool Support. Proceedings of the 1st International Workshop on Product Management, Minneapolis/St. Paul, Minnesota, USA, pp. 3-12.
 Weerd, I. van de, Versendaal, J., Brinkkemper, S. (2006). A product software knowledge infrastructure for situational capability maturation: Vision and case studies in product management. Proceedings of the Twelfth Working Conference on Requirements Engineering: Foundation for Software Quality, Luxembourg, pp. 97-112.
 Tran-Cao, D., Levesque, G., Abran, A., (2002). Measuring software functional size: towards an effective measurement of complexity. Software Engineering Management Research Laboratory, University of Quebec at Montreal (UAQM).