The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
Eliciting requirements is a key skill in requirements engineering. A requirements engineer is supposed elicit requirements in a way that is both unbiased and neutral. So far, so good. However, looking at various projects we come across a lot of situations where a requirements engineer neglects the premise of neutrality subconsciously. This article tries to explain what is behind this observation. The article is based on a theory which might be for some readers far from requirements engineering. However, looking closer, the theory of radical constructivism appears to be an interesting source for requirements engineering. Ernst von Glasersfeld (1917-2010), Heinz von Foerster (1911-2002) and Paul Watzlawick (1921-2007) made major contributions to the theory of radical constructivism. First, the article presents a short description of what radical constructivism actually is. Second, the stakeholder, the requirements engineer and the interview as the most famous elicitation technique are analysed in regards to radical constructivism. Last but not least, a summary of questions which should be considered when thinking about requirements engineering and radical constructivism is given.
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)
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. 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).
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.
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. 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.
There is a variety of elicitation techniques. 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 which – among others – helps in choosing the appropriate elicitation technique. General questions which a requirement engineer should answer are the following:
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.