Requirements under construction

Radical Constructivism – an abstract

There are various research papers and publications on radical constructivism. Yet, the article will only introduce the main idea of radical constructivism as a foundation for further requirements engineering related issues. We consider the following postulate by von Foerster as crucial for mapping requirements engineering and radical constructivism:

“[T]he environment as we perceive it is our invention.” (translation: KS)^[3]

Everybody invents his / her own image of our environment. There is no real, neutral or even objective reality. Accepting that our environment is an invention requires receptiveness as it requires people to take responsibility for their actions. It is we and not somebody else who are responsible, or even to blame, for what we are doing^[4]. Consequently, if everybody invents his / her environment, the source of requirements is personal and originates from diverse images of our world.

Paul Watzlawick’s theory of reality also explains diverse images of our world. First of all though, there is a first-order reality on which communication is based. There are facts which can be proven with experiments over and over again. Look at the physical properties of gold for example. They will always be the same, no matter by whom and where the measurements are made. Chemical and physical characteristics of gold will not change. The second order reality is a real challenge for communication and thus for requirements engineers. The second order reality is based on personal experience, thoughts, decisions etc. They are attributed to the first-order reality. Gold, for example, is among other things associated with jewelry, wealth and coins. Nevertheless, the second-order reality does not have much in common with the first-order reality. It is a mere attribution of human perspective. Requirements engineering and especially eliciting requirements mainly deals with second-order reality. On the one hand, when observing and doing interviews, a requirements engineer’s approach and methods result from his / her reality. On the other hand, stakeholders form their requirements based on their own individual reality. This can be seen as an explanation for many varying, diverse requirements.

This theoretical introduction is followed by outlining the impact of radical constructivism on requirements engineering. Are there certain aspects which are crucial for the work of a requirements engineer? As there is no neutral, objective world, it is the requirements engineer’s task to be aware of all those different radical constructions. The requirements engineer - as the center of communication – has to deal with many different ideas and beliefs and eventually to document them as agreed requirements. Von Glasersfeld considers radical constructivism as a means to bring “a certain order in experiences [of stakeholders]” (translation KS)^[5].

The stakeholder under a radical constructivist’s point of view

At the beginning of a project it is important to speak with more than just one stakeholder about the purpose of the project. Speaking with one stakeholder only (many might see the sponsor here) results in high level requirements based on his / her personal environment. It might contradict the requirements of other stakeholders and could result in highly conflictive project. A simple and well-known resource can help to avoid this situation. A stakeholder list is essential when it comes to scheduling interviews or apprenticing sessions. Moreover, it can also be seen as a checklist. Is the requirements engineer in touch with more than one stakeholder? Do the stakeholders represent the different departments of the company? Only if this applies, will the requirements engineer be able to elicit requirements based on various constructions of the stakeholders.

The requirements engineer under a radical constructivist’s point of view

A requirements engineer is expected to ignore his / her own wishes and ideas within the elicitation process. Personal opinions shall not be part of requirements^[6]. From a radical constructivist’s point of view this is impossible. A requirements engineer will always place his / her own ideas within the elicitation process as e. g. his / her interview questions are based on his / her invented environment. Considering an everyday project, there might be requirements engineers who present their own ideas to the stakeholders. This, however, should be pointed out clearly to the affected stakeholders. Radical constructivism should not be an excuse for a system which is developed without considering the stakeholders’ requirements. Questions such as “Do you have other topics in mind?” or “Did I miss anything” should be asked more often in communication between stakeholders and requirements engineers. If communication is based on assertions of requirements engineers only, the stakeholders will not be able to address his / her individual reality. Constraints shall be named as an example for a personal invention. They are an important, often legally bounded source of requirements. Even if all involved stakeholders are familiar with a constraint (e.g. a new law or standard), they still interpret the constraint in a different way. This results in varying requirements. It is the requirements engineer’s task to address gaps in requirements and hence the radical constructions behind the requirements.

To make sure that it is not only the reality of one requirements engineer that is the foundation of a project, more than one requirements engineer should be part of a team. Even if more resources (e. g. due to coordination) are necessary, the major advantage of a requirements engineering team is the following: agreed points of view ensure high quality requirements. It goes without saying that the participating requirements engineers need to discuss and exchange the requirements they have elicited. These thoughts are applied to an example: Two requirements engineers conduct an interview on one topic but with different stakeholders. The interviews are followed by a discussion. Based on the discussion of the elicited information the requirements engineers document the requirements. Following this procedure, it is possible to not only discuss and compare the stakeholders’ reality but also the requirements engineers’ reality. If conflicts occur, the awareness that constructions are the source of the requirements in question might make it easier to solve the conflict.

Interview – classic and yet underestimated

There is a variety of elicitation techniques^[7]. The interview, however, has become the most used technique. Many requirements engineers and stakeholders are familiar with this technique. They should nevertheless be aware of how challenging and powerful this technique is. Preparing questions is part of the requirements engineer’s preparation for an interview. Open questions might seem a good method to get the stakeholder to talk and get much information without imposing one’s own opinion. As open questions result from one’s own invented environment, the requirements engineer has to make sure that the interviewee is familiar with this environment. It is the requirements engineer’s responsibility to challenge the answers. The answers are characterised by the stakeholder’s invented environment. S/he cannot understand the questions without the same background. At the same time, the requirements engineer cannot understand the answers without an understanding of the stakeholder’s environment. Checking and rephrasing information should be a dedicated part of any interview. The condition of successful communication (that is common understanding of one’s environment) is missing. Take a requirements engineer interviewing a stakeholder about an interface of an online form. It is the first online form the interviewee is specifying; s/he is not a big fan of the internet anyway. S/he hardly knows about radio buttons, checkboxes, text areas etc. The requirements engineer supported a number of projects developing online forms. S/he knows what is a “good” online form. Hence the interview questions are based on a different construction from the stakeholder who will hardly understand the issue.

Interviews can be held with one or several interviewees. One to one interview sessions might be easier to handle in terms of communication, as these are based on two inventions only. Group interviews have a high risk of “the louder, the better”. Essential information might be missed. The requirements engineer is confronted with various constructions. S/he gets the highly important overview and can differentiate the information provided. Even if one to one sessions are more expensive, they should be considered for top level issues with crucial stakeholders. The sessions are followed by one more challenges for the requirements engineer: s/he has to produce consistent requirements’ documentation. If necessary, workshops could help to reach an agreement among stakeholders. Workshops also provide an opportunity to solve conflicts. Detailed instructions on how to organise and hold such workshops can be found here.

Next, let us look at a support technique of high value for requirements based on constructions: Prototyping. A prototype provides the stakeholders the possibility to experience their requirements. Phrases such as “Oh, this is not what I meant” or “I thought that would be different” are expressed easily. What was the intention of the stakeholder and what is his / her construction behind his / her requirements? Collecting more and more information allows the requirements to be revised. Little by little the construction of the stakeholders becomes apparent to the requirements engineer and ensures better quality requirements.

This article focused on radical constructivism and on one eliciting technique and one supporting technique only. Of further interest (but out of scope of this article) are persona and apprenticing, as both apply to the main thought of radical constructivism: there are many inventions of one’s environment. Requirements engineering somehow should address them.

To sum it up, radical constructivism is not a new elicitation technique. Radical constructivism provides a new perspective on the elicitation of requirements. It is a way of thinking^[8] which – among others – helps in choosing the appropriate elicitation technique. General questions which a requirement engineer should answer are the following:

• Do I elicit requirements based on one construction (one stakeholder) or on mixed constructions (more than one stakeholder)?
• How can I elicit requirements based on various constructions and, even more importantly, how can I consolidate them?
• Did I get an overview of necessary requirements or am I missing important constructions?
• How can I question, reflect and minimise my own constructions?

From a constructivist’s point of view, these questions need to be addressed in order to document requirements which are at least close to neutrality. Eliciting neutral requirements however is not possible - questioning what we call “reality” is.

References

• [1] IREB Certified Professional for Requirements Engineering – Elicitation and Consolidation, Advanced Level – Syllabus. www.ireb.org/content/downloads/7-syllabus-advanced-level-requirements-elicitation-and-consolidation/ireb_cpre_elicitation_and_consolidation_syllabus_version_1.pdf.
• [2] Among others: Foerster, von Heinz: Understanding Understanding: Essays on Cybernetics and Cognition. Springer: New York 2003.
  Glasersfeld, von Ernst: Key works in radical constructivism. Sense Publishers: Rotterdam, Taipei 2007.
  Watzlawick, Paul: The Situation is Hopeless, But Not Serious: The Pursuit of Unhappiness. Norton & Company: London 1993.
• [3] Foerster, von Heinz (2002): Das Konstruieren einer Wirklichkeit. In: Watzlawick (2002). Die erfundene Wirklichkeit. Wie wissen wir, was wir zu wissen glauben? Beiträge zum Konstruktivismus. 15. Aufl. Piper: München u. a. S. 40.
• [4] Foerster, von Heinz et al.: Entdecken oder Erfinden. Wie läßt sich Verstehen verstehen? In: von Foerster (2010): Einführung in den Konstruktivismus. Piper: München u. a.
• [5] Interview Ernst von Glasersfeld, 08.12.2000, anläßlich seines Vortrages an der Universität Koblenz-Landau, Campus Koblenz. www.univie.ac.at/constructivism/EvG/papers/253.pdf.
• [6] IREB Certified Professional for Requirements Engineering – Elicitation and Consolidation, Advanced Level – Syllabus. http://www.ireb.org/content/downloads/7-syllabus-advanced-level-requirements-elicitation-and-consolidation/ireb_cpre_elicitation_and_consolidation_syllabus_version_1.pdf.
• [7] Rupp, Chris und die SOPHISTen: Requirements-Engineering und –Management. 6., aktualisierte und erweiterte Auflage. Hanser: München 2014.
• [8] Interview Ernst von Glasersfeld, 08.12.2000, anläßlich seines Vortrages an der Universität Koblenz-Landau, Campus Koblenz. http://www.univie.ac.at/constructivism/EvG/papers/253.pdf.