Introduction
The term “system” appears some 700 times in the CPRE foundation level handbook (hereafter abbreviated CPRE), second only to the term “requirement”. This is an average of about 5 occurrences per page! Undoubtedly, this term is of utmost importance for requirements engineers. To see why, we can examine the very definition of the term requirement in the CPRE (Glinz 2020, p. 8):
“DEFINITION 1.1. REQUIREMENT: 1. A need perceived by a stakeholder. 2. A capability or property that a system shall have. 3. A documented representation of a need, capability, or property.”
Definitions 1.2 and 1.3 bind the notions of stakeholder, desires, needs and system together (Glinz 2020, p. 9):
“DEFINITION 1.2. REQUIREMENTS ENGINEERING (RE): The systematic and disciplined approach to the specification and management of requirements with the goal of understanding the stakeholders’ desires and needs and minimizing the risk of delivering a system that does not meet these desires and needs.”
“DEFINITION 1.3. STAKEHOLDER: A person or organization who influences a system’s requirements or who is impacted by that system.”
From these definitions it becomes clear that the notion of system is very important to requirements engineering. The system, it is said, must meet stakeholders’ desires and needs. The CPRE further states that there are typically many stakeholders whose desires and needs must be met and that these stakeholders have different points of view about the system, which shape their desires and needs. Requirements engineering would be much easier had there been only one stakeholder or if all stakeholders had the same desires and needs. Since this is not the case, one of the main duties of requirements engineers is to meet (as many as possible of) these disparate desires and needs by reconciling the stakeholders’ viewpoints. The CPRE is not very clear about why stakeholders’ viewpoints differ. The definition of a system is given as an object dissociated from any observation; it should therefore be the same for all stakeholders. The notion of viewpoint is then added without being explained. In practical terms, this leads to endless arguments among stakeholders about the nature of the system to be built and about their desires and needs to be met. By defining the system as a point of view, it is possible to avoid at least some of these arguments by focusing the discussion among stakeholders on “their system” instead of on “the system.” The exploration of the problem and solution space is about the merits of stakeholder 1’s system as it is confronted with stakeholder 2’s system.
In this paper, we examine the definition of the term system in the CPRE and propose amending it slightly by adding to it the concept of the observer: the person who has a point of view. We examine the existing CPRE definition of a system and propose adding five words to it. This change may appear minor in terms of quantity but can result in substantial simplification and clarification of the overall text of the handbook. Our proposals are mere pointers to changes that can be brought to the CPRE, the exact changes needing much more time and effort.
We use the term “parties involved” to refer to all people linked to a requirements engineering activity including the requirements engineers themselves, as defined in the CPRE (Glinz 2020, p. 16): “RE creates, fosters, and secures shared understanding between and among the parties involved: stakeholders, Requirements Engineers, and developers.”
We begin by examining the definition of a system and follow it up with an analysis of some parts of the CPRE where our proposed change can clarify matters.
What is a System?
Jerry Weinberg was a prolific author who wrote or co-wrote dozens of books about software development, systems, project management and consulting. The CPRE handbook references one of his books (Exploring Requirements: Quality before Design), written with Don Gause, because it explicitly refers to requirements. The large majority of Weinberg’s books, whether as a single author or co-authored with others, are very useful for requirements engineers even if they do not explicitly mention requirements in their title [1] . Weinberg’s book ‘An Introduction to General Systems Thinking’ is or should be quite well-known for requirements engineers. Among a wealth of knowledge about why systems thinking is important, and where and how to apply it, Weinberg asks (Weinberg 1975, p. 52): “What is a system?” and answers, (Weinberg 1975, p. 52): “As any poet knows, a system is a way of looking at the world.” You might be thinking: well that’s good for poets, but this article is for engineers, not poets! What does it have to do with me? Weinberg was also writing for engineers; he knew he had to be careful with these kind of notions. He therefore acknowledged that scientists are often frightened by this notion of relativity even though (Weinberg 1975, p. 54): “it was Einstein who put forth the Theory of Relativity, which rocked the scientific world just because it was based on the premise that we could only know the external world through our perceptions.”
The role of the observer has been central to the theory of relativity, the social sciences as well as the cornerstone of second-order cybernetics, the cybernetics of observing systems (von Foerster 2003, p. 285). But it is very often forgotten. Weinberg shows how (Weinberg 1975, p. 63):
Weinberg continues by explaining that most definitions of a system employ the notion of a set of objects and relationships between them. He then asks the question, “Where did these objects come from?” “They might have dropped from the sky.” and explains that these definitions “fail to give the slightest hint that the system itself is relative to the viewpoint of some observer.” He notes that set theory “tells us much about the properties of sets, but tells us nothing about how observers might choose them.” (Weinberg 1975, p. 63).
Most writers about systems thinking still employ the same sort of definition that hides the observer. The CPRE foundation level handbook is one of the more recent examples (Glinz 2020, p. 9):
DEFINITION 1.4. SYSTEM: 1. In general: a principle for ordering and structuring. 2. In engineering: a coherent, delimitable set of elements that—by coordinated action—achieve some purpose.
Just like Weinberg, we may ask who decides all of the properties of the system: what is coherent; what is the set of elements and what is its limit; what lies beyond it; what is considered as coordinated action or even action itself; what is the purpose of this thing. In General Systems Thinking, this entity who makes these judgments is called “the observer.” We propose adding the observer in the definition of a system, resulting in the following:
a coherent, delimitable set of elements that—by coordinated action—achieve some purpose, as defined by an observer.
The advantage of this definition is that it simplifies and justifies the discussions about points of view, shared understanding and interpretations in the handbook. This is because the system itself is a point of view. The system is different for different stakeholders: they each see a different set of elements that therefore has a different boundary and a different purpose. It is because of these differences that they need to reach a shared understanding (Principle 3 in the CPRE foundation). It is not that there are systems in reality which are coherent, delimitable and that achieve some purposes. All these properties are up for grabs. Every observer sees what they are ready to see, and therefore the very system they identify is different.
This is aptly described by Checkland and Holwell (1998, p. 12-13):
The 'hard' systems engineer chooses to see the world as a set of systems, and hence assumes that it is easy to answer the question: what is the system in question? He or she then carefully defines the named system's objectives; and numerous techniques are available to enable the system to be engineered to meet those objectives. Alternatives are modelled, and carefully defined criteria are used to choose between them.
It was discovered that in the kind of problematical situations within and between organizations with which managers have to cope, the inability to decide 'the system' and name 'its objectives' was often what caused the situation to be regarded as problematical in the first place.
For example: was the Anglo-French Concorde project to be regarded simply as a system to create the world 's first supersonic aircraft ? Or as a political system to persuade the French the British could be good European partners? Or as a system to help maintain a UK precision engineering industry? Or as a system to ensure that the Europeans - not the Ameri cans - were world leaders in at least one advanced technology? In the real Concorde project all these considerations and many others were relevant.)
The prescription proposed by Checkland and his team was to include the worldview that underlies perceived reality in every SSM model. This was part of the root definition called CATWOE, which stands for (Checkland and Scholes, 1999, p. 35), Customers, Actors, Transformation process, Weltanschauung, Owner and Environmental constraints. Weltanschauung is German for Worldview and is said to make (Checkland and Holwell, p. 13):
We propose that this be applied to the CPRE in practical terms by simply adding the observer to the definition of the system. For example, the CPRE (Glinz 2020, p. 33) states some potential pitfalls that requirements engineers should strive to avoid. Among them is the following: “Passive voice. Sentences in passive voice have no subject. If a requirement is stated in the passive voice, this may hide who is responsible for the action described in the requirement, leading to an incomplete description.” Adding the observer to the definition of a system means that the active voice must be employed wherever possible to define whose system it is.
Stakeholders’ Satisfaction and Shared Understanding
Satisfying stakeholders’ desires and needs and creating a shared understanding among stakeholders are the second and third of the nine fundamental principles of requirements engineering according to the CPRE.
The CPRE explicitly addresses the issue of stakeholders’ differing points of view, as in (Glinz 2020, p. 16): “Stakeholders in different roles naturally have different viewpoints [..] of a system to be developed.” Where do these different viewpoints come from if a system exists without any observer? Why can’t the different observers just see the system for what it is? As we have seen above, they cannot. By adding the role of the observer in the definition of the system there will be no need to resort to external constraints such as the use of the word “naturally.” It will be sufficient to say that definition 1.4 means that stakeholders in different roles see different systems and therefore are likely to have different requirements.
The very mission of the requirements engineer is to create a shared understanding among these points of view, as described by the CPRE (Glinz 2020, p. 16): “RE creates, fosters, and secures shared understanding between and among the parties involved: stakeholders, Requirements Engineers, and developers.” This is nicely put, because it shows that the shared understanding is among all “parties involved”, including the requirements engineers themselves. Requirements engineering was created to help developers to understand what they need to develop. Requirements engineers are therefore the intermediaries between the fuzzy needs of the stakeholders and the stringent needs of the developers. It is up to them to appreciate the many diverse views in this situation. Defining the system as a point of view may help requirements engineers to accept or even encourage these diverse points of view in order to reduce the risk of creating a situation that none of the stakeholders really appreciate.
In SSM this is done by seeking an accommodation between the points of view, as explained by Checkland and Holwell (1998, pp. 13 – 14):
It is not for the requirements engineer to decide what the requirements are. They must accept the viewpoints of the other parties. They must identify an accommodation of viewpoints as proposed by Checkland et al. Everybody must be able to express their viewpoints and then accept what can be done. Requirements engineers must not strive to get everybody to agree on the system, but to accept what can be done. They must be ready to appreciate the viewpoints of the other parties and among themselves. To explain to one party what the other sees. The goal is not to obtain a consensus, but to help the parties to see and appreciate the viewpoints of the others.
Boundaries
The CPRE distinguishes several kinds of systems, e.g., software system, socio-technical system, but most of the time the single term system appears in the text with the probable, implicit meaning of software system, as in the following quote (Glinz 2020, p. 63): “These requirements then serve as input for a development team that will build and implement the system.”
The issues of system kind and system boundary are tightly linked. Obviously, if we observe a different kind of system, its boundary will change. If it contains physical components, people and organizations, it will be called differently (cyberphysical, socio-technical) and its boundaries will change. Because it is treated separately in the CPRE, we address it separately in this article.
The discussion about boundaries is linked to the notion of context, which is requirements engineering’s fourth fundamental principle, according to the CPRE. For the CPRE context is highly important because (Glinz 2020, p. 18): “Systems cannot be understood in isolation.” This notion is developed into a set of definitions of the terms context, context boundary, system boundary and scope (CPRE p. 18).
Let us consider the concept of system boundary. It is defined as (Glinz 2020, p. 18):
DEFINITION 2.3. SYSTEM BOUNDARY: The boundary between a system and its surrounding context.
It is further noted that “The system boundary delimits the system as it shall be after its implementation and deployment.”
Now let us reexamine the definition of a system (Glinz 2020, p. 9): “a coherent, delimitable set of elements that—by coordinated action—achieve some purpose.” The boundary delimits the system, and so do the set of elements and their coordinated action. So these two concepts are inherently linked together: when the set of elements or their action changes, the boundary changes and vice versa. If we adopt the observer-dependent definition of a system, the boundary will therefore depend on the observer.
In the CPRE, the context and system boundaries seem to be considered as absolute dimensions. Statements such as the following (Glinz 2020, p. 18):
This gives the impression that the boundary is the same for all parties involved, stakeholders, requirements engineers and developers. Using the observer-dependent definition will clarify that the parties are very likely to see a different context and system boundaries. Clarifying the boundaries is, therefore, a task that is related to creating a shared understanding among stakeholders. It should not be seen as a totally separate task as it is right now.
Kinds of Requirements
Consider the kinds of requirements described early on in the CPRE. This distinguishes between 3 kinds of requirements (Glinz 2020, p. 8):
Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment.
Quality requirements pertain to quality concerns that are not covered by functional requirements — for example, performance, availability, security, or reliability.
Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality requirements.
Looking closely at this definition, we can see that we cannot know what is a functional requirement if we don’t know what functions that system provides. Because stakeholders are unlikely to know what are the functions of the system, it is unlikely that they will be able to know what are the functional requirements. Since quality requirements and constraints are defined only by reference to functional requirements, it is quite probable that stakeholders will not be able to separate these kinds of requirements at all.
This difficulty has been recognized in the CPRE, which states that (Glinz 2020, p. 8): “Distinguishing between functional requirements, quality requirements, and constraints is not always straightforward.”
Why is it not straightforward is not explained in the CPRE, but it is readily explainable as a result of our definition of system as observer-dependent. Let’s discuss the examples given in the CPRE.
One of the examples explaining the difference between functional and quality requirements in the CPRE is the following (Glinz 2020, p. 9):
In this case, who decides that “requirements concerning data volume or processing speed” are quality instead of functional requirements? If the stakeholder of the system (the physicist) gives this requirement as a direct answer to the question “what shall the system do?” then for them it is a behavior of the system. The requirements engineer can categorize the requirement as a quality, but for the physicist it can remain what the system does, i.e., a functional requirement for the requirements engineer. Taking the observer-dependent view of the system, we propose adding this explicitly into the CPRE by saying that the kinds of requirements are useful for requirements engineers to make sure that the requirements are complete and sound, but that this separation may not be understandable by the stakeholders. It is therefore not necessary to impose this point of view on the stakeholders. The requirements engineers, knowing that it is their point of view, can elicit the requirements by probing stakeholders for the results they need, the availability, security, reliability, constraints etc., and then translate those requirements into their model of functional, quality and constraints for analysis.
Conclusion
People in general are often sure that what they see in themselves and in their environment is real and true, and that if other people do not share this view, they are most probably wrong. It is therefore an easy trap to fall into by requirements engineers to think that they themselves have an independent and objective view of the system. This is probably also the belief of the other parties involved, the stakeholders and developers. In our practice, we often need to elicit requirements from people who disagree on the very basic features of their work. Adding to the definition of a system the notion that it is itself a point of view may counter this tendency of human beings to think that their view is the only correct view. Adding the notion that a system is dependent on the observer may help requirements engineers to “really” understand that their system is not the stakeholders’ system, which is why what they see may not be what their stakeholders see.
We hope that this work may help in making the CPRE text clearer about the differences in viewpoints among the parties involved and may help practicing requirements engineers to better appreciate what they may perceive as the idiosyncrasies of these parties. From our point of view, these are not idiosyncrasies or biases but rather the readiness to see one’s reality in a specific way inherited from experience. There is a long tradition of research and practice in this interpretive stance, which up till now has not much influenced requirements engineering. May this be a beginning.
References
Checkland, Peter, Scholes, Jim. (1990): Soft Systems Methodology in Action, Wiley.
Checkland, Peter and Holwell, Sue. (1998): Information, Systems and Information Systems - making sense of the field, Wiley.
Glinz, Martin, van Loenhoud, Hans, Staal, Stefan, Bühne, Stan. (2020): Handbook for the CPRE Certified Professional for Requirements Engineering, Foundation Level - Version 1.0.0, IREB.
von Foerster, Heinz. (2003): Understanding Understanding: Essays on Cybernetics and Cognition. Springer.
Weinberg, Gerald M. (1975): An Introduction to General Systems Thinking. Wiley
Footnotes
- [1] For a very short list, see The Psychology of Computer Programming, Are Your Lights On (with Don Gause), Secrets of Consulting and General Principles of Systems Design (with Daniela Weinberg), now split in two books called General Systems Design Principles: Passive and Active regulation.
Gil Regev has been a researcher at EPFL since 1997 in the fields of enterprise information systems, requirements engineering, change management and knowledge management. Since 2008 he is also manager and consultant at Itecor, a boutique consultancy firm. Previously Gil developed software for computer peripherals at Logitech, in Switzerland and California.
Alain Wegmann is a full professor at the School of Computer and Communication Sciences, EPFL, Switzerland. He worked 14 years for Logitech (Switzerland, Taiwan, US) in positions ranging from software developer, IS manager, manufacturing engineering to VP of engineering and OEM marketing before joining the EPFL in 1997. His teaching, consulting and research are in the fields of enterprise architecture, requirements engineering and service engineering.
Comments (2)
Dear Mr Regev, dear Mr Wegmann, dear Mr Hayard,
I can totally see the fundamentals and implications of this article.
Everybody has a different view of a system and more or less every stakeholder in a project will not use and see all subsets of features implemented. They will more or less for sure not value features all the same way.
But I differ in your conclusion; in naming every view of a stakeholder a system the discrepancy and dispute will not go away. It will on top leave the developers in the end puzzled on what to implement. In keeping the naming in line with other disciplines, I suggest keeping the system as the core thing to be created at the end.
This implies, the system is the sum or the integration of all of the stakeholders views.
Given that and emphasizing the worth of the different view, requirements engineering can be improved without redefining already commonly used keywords.
You can tell a stakeholder this is their view on the system and the view differs from another stakeholder's view. This gives appreciation to the stakeholders and opens their mind for the existence of other views.
Naming it system will probably result in phrases like "can I have my system now?", which will not help in consolidation the different views.
Best Regards,
Jan Marc Stockschläder
Dear Mr Stockschläder,
Thank you very much for your comment. It helps me clarify our position.
When you write "keeping the system as the core thing to be created at the end” it raises the obvious question: what is this system and who determines it. Since you’re also referring to developers who will be puzzled about what to implement, I suppose you implicitly refer to an IT system as the system to be created. If this is a given at the outset of the project, as I think is very often the case for requirements engineers, then the developers have the upper hand in defining requirements, because they own the system whereas the other stakeholders only have points of view.
Defining the system itself as a point of view helps level the field and give the other stakeholders as much power in the definition of the requirements. It places the developers in one stakeholder group, and not necessarily the most important one. In the end, then, the system to be created may not be an IT system at all. Getting bogged down in disputes is indeed a risk that is taken by anyone who opens up a discussion and invites other peoples’ viewpoints to be equal to their own. The process had better be managed so that the points of view can converge, but as proposed by Karl Weick (The Social Psychology of Organizing), it should not be done by avoiding the debate itself. It may be precisely this debate, where all points of view are at least registered, that according to Weick leads to a better outcome, or in RE terms to better requirements, then if the debate is reduced to opinions about a system that has already been at least implicitly decided on.
RE was born as an antidote to developers delivering an IT system without consulting with stakeholders first. In this article, we attempted to move this idea a bit further so that requirements engineers, who are supposed to be neutral, don’t take for granted that there is an IT system to be built, but rather create a debate among stakeholders about what their problems are and what could be seen as a proper solution. An IT system is often part of this solution, but it should not be focal point at the beginning of the project.
I hope this clarification helps, and will be happy to pursue this debate further.
Best wishes,
Gil Regev