UNIT 3 SELECTED INVESTIGATIVE TECHNIQUES Flashcards
Describe the Change of Perspective (or Six-Hat Thinking) creativity technique.
Change of perspective is a creativity technique used to examine a problem from different angles. One variation is six-hat thinking, where each hat represents a perspective of a problem. Participants in the application of this method are given symboli-
cally different colored hats that identify the perspective from which the stakeholder will view the problem. The hats represent the following attributes:
* The white hat stands for objectivity and neutrality. The stakeholder primarily pays attention to facts and figures.
* The red hat stands for a subjective opinion and personal feelings. The stakeholder expresses their feelings, fears, and hopes.
* The black hat makes the stakeholder argue objectively, but negatively.
* The yellow hat makes a stakeholder argue objectively, but positively.
* The green hat puts creativity in the foreground. The stakeholder is eager to come up with new ideas.
* The blue hat stands for the control and organization of the whole thinking process.
The person with the blue hat moderates and coordinates the idea generation process. This perspective is also taken by different stakeholders, not only the requirements engineer,
who typically moderates. Stakeholders who are particularly convinced of their point of view are encouraged to adopt new views through a change of perspective. Therefore, the
method is particularly suitable for expanding narrow viewpoints. The change of perspective can also be used to examine existing solutions from different angles. However, gathering requirements with a high level of detail is very time consuming; for introverted and conservative stakeholders, the method can seem aloof. The requirements engineer must be careful when introducing the method so as not to run the risk of being put directly into an “esoteric corner,” as this can reduce the stakeholders’ willingness to cooperate.
Describe the Verbal Brainstorming creativity technique.
Verbal brainstorming is done with a group of five to ten people. This group collects ideas about a certain topic within a given period of time. The stakeholders express their ideas
and use the ideas of the other stakeholders as inspiration for further ideas. Brainstorming is therefore particularly successful if the participating stakeholders are selected as heterogeneously as possible and are stimulated by external influences, which lets them flow into their own idea generation.
The requirements engineer notes down all ideas without evaluating them and makes sure that all stakeholders accept each other’s ideas, no matter how different they may be. No
evaluation or criticism is allowed during the collection, as this inhibits the creative process and may demotivate stakeholders. After the collection, the ideas are analyzed and aggregated, duplicate ideas are eliminated, and it is possible to classify the ideas. By using modern information and telecommunication software, it is also possible to conduct brainstorming with spatially distributed stakeholders. The advantages of brainstorming are that many ideas can be collected in a relatively short time and innovative requirements can be
identified. However, if the group dynamics are difficult, poor or few results can be expected. This also applies if there are dominant stakeholders in the group. Furthermore, it is
challenging for the requirements engineer to quickly note down all the information.
Describe the Written Brainstorming creativity technique.
If the group dynamics, dominant stakeholders, or hierarchical conflicts in the stakeholder group impair the quality of the results, written brainstorming can be used. Stakeholders
calmly collect their ideas and write them down. The boundary to verbal brainstorming can be blurred if electronic collaboration tools are used for collection. Stakeholders write down their ideas on a tablet, for example, and each idea is sent to a server and displayed for all stakeholders (e.g., via a projector).
If the ideas are collected digitally, this is less work for the requirements engineer, who does not have to note down the ideas. This also means that there is no danger of forgetting ideas when they are expressed at the same time, and the creativity process is not inhibited by asking questions. However, the collection of ideas can also be carried out anonymously by stakeholders noting down their ideas but not expressing them aloud. Anonymity helps to prevent negative group dynamics and hierarchical conflicts. The disadvantage can be that creativity is not stimulated by the ideas expressed by other stakeholders.
Describe the Written Brainstorming With User Stories creativity technique.
User stories are functional requirements formulated from a user’s point of view. In practice, it has proven useful to write user stories on an index card with a thick pen. The limited space encourages stakeholders to formulate precisely; the cards can then be easily sorted and grouped, and duplicate ideas can be eliminated. To use user stories as a creativity method, the stakeholder must briefly explain the concept of user stories and their scheme. Then, the stakeholders receive index cards and are asked to collect ideas for functional requirements from a certain perspective. Experience has shown that the stakeholders should be asked to collect ideas from any perspective and without rationale, so as not to hinder the creativity process.
The stakeholders write down their functional requirements on the index cards and pin them on a board after the collection phase is over. If the collection is not anonymous, it is
advisable to let the stakeholders present their respective requirements and ask for a technical justification for the requirement at this point. If a plausible justification is provided,
the stakeholder notes it on the index card; if it is difficult to formulate a justification or no justification is provided, it must be revised. If the requirement is then less important, it can be postponed or eliminated. If the collection is carried out anonymously, time must be given after the collection phase to note down the justification. This also helps the stakeholders review the formulated requirements.
After the requirements have been collected, duplicate requirements must be eliminated. Furthermore, it is possible to group the requirements according to topics (e.g., user
administration). This procedure is repeated until the stakeholders have no new ideas. To produce more ideas, the six-hat thinking method can be combined with the user story
technique.
Describe the 6-3-5 Method creativity technique.
The 6-3-5 method is a written creativity technique. Six participants each develop three ideas at the same time and write them down on a card. After a fixed period of time (typi-
cally three to five minutes), the cards are passed on to the respective neighbor. The neighbor reads the ideas of their predecessor and is inspired to write down three more ideas.
This is repeated until each participant has had each card once, i.e., five times. Then the ideas (25 in this case) are collected and evaluated, and the requirements are derived.
Three typical ways to develop ideas are as follows:
1. Repeating the idea according to the principle of the genetic algorithm. Successful ideas survive.
2. Permutation. Ideas are modified.
3. New idea. The participant is inspired by other ideas and adds a new idea.
This technique is easier for the facilitator to use than, for example, brainstorming, because the collecting, writing, and grouping of ideas is done by the participants themselves. Thus,
the 6-3-5 method is a good entry-level technique for less experienced facilitators. Difficult group dynamics are much less of an issue with the 6-3-5 method, as each participant is equally involved and there is neither silence nor the need to stop dominant participants. Of course, you can also use variations of the method, such as 7-3-6 or 6-4-5.
Describe the Design Thinking creativity technique.
Design thinking is an innovation model that iteratively develops needs and solutions with different stakeholders. The aim is to understand the need from different perspectives and develop ideas in iterations, evaluate them, and, based on the evaluation, develop new ideas that convince the user. The mandatory result-oriented, prototypical approach avoids typical thinking traps that arise, for example, from complacency.
The following list explains each of the six steps in design thinking:
1. Understanding means assessing the situation. It is about finding as many data, facts, and questions as possible to understand the issue and be able to talk about it. This is
preparation for the next step.
2. Observation is done to find out the real needs of the users that have not been addressed so far. Design thinking assumes that many needs cannot be named by the users and must be observed in the context of the use of a product or service.
3. Synthesis means that the data from understanding and observation are collected and needs are derived from them.
4. Developing ideas is an important step. The goal is to develop as many ideas as possible and select those with the greatest potential.
5. Prototypes are used to concretize the ideas, develop simple prototypes, make them tangible for the user, and develop them step by step. The user can quickly experience the benefits of prototypes made of paper, clay, or software.
6. Testing is carried out when the prototypes are made available to target users for testing. The prototypes are refined with feedback from the users.
Design thinking draws from classic prototyping, but the purposeful reuse of known good practices does apply to Agile development in general. It is clear that, as in classic prototyping, the results are initially “throwaway prototypes,” and are usually unsuitable as a later product. It is advisable to plan enough time in design thinking to start again from scratch, also taking into account the previously ignored boundary conditions and, above all, the quality requirements.
What are some methods to produce results in the Design Thinking creativity technique?
Different methods to produce specific results are used according to the situation. Some examples include:
* business model generation and business model canvas (strategic management and lean start-up template for developing new, or documenting existing, business models). This can be, for example, lean and demand-focused representation of a business model based on assumed market principles.
* benchmarking (After determining key performance indicators for a business process a comparison between different companies in the same industry becomes possible). This is constantly and consistently learning from the best, especially
across products and sectors.
* prototyping. This is the systematic development of possible solutions for the initial need. The aim is to better understand the need and experiment with the use and business model at an early stage with open results.
* persona. This is the assumed typical role pattern of later customers or users, especially if, in business to consumer (B2C) or business to business (B2B), the actual customers are
not on board in the design workshop.
* focus groups. These promote the active involvement of later users in early prototypes to evaluate ideas and develop new ones.
* reframing and 5 Why. These processes systematically question assumptions, constraints, goals, and perceived need in five steps with the question “Why is this so?”
* Pecha Kucha (400 seconds to tell your story, with visuals guiding the way) and elevator pitch. These models involve briefly summarizing an idea and its value in twenty seconds with the aim of convincing a decision-maker or user group.
Describe the Workshop creativity technique.
In a workshop, different stakeholders come together to work on the identification of requirements. When the requirements engineer invites the members of the workshop, they have to ensure that these representatives are equipped with the necessary expertise and decision-making authority to obtain the agreed requirements as a result of the workshop. The physical proximity and direct exchange among participants help to identify conflicting requirements and obtain agreed requirements by resolving the conflicts. Often, the stakeholder whose group has the most power, e.g., the group with budget responsibility, “wins” in such workshops, which means that their requirements will prevail.
To conduct a successful workshop, fixed rules must be defined, and the workshop must be led by an experienced requirements engineer who can moderate complicated group-dynamic processes in a goal-oriented manner. In workshops, requirements are often classified according to relevance, consolidated in terms of content, and concretized. A workshop consists of three phases: preparation, implementation, and follow-up.
In the preparation phase, the requirements engineer defines the goals of the workshop. Based on the objectives, the work results are determined and a procedure for achieving the objectives is defined (e.g., a combination of the techniques described above). Then, the place, time, and duration of the workshop are defined, and an appropriate room with the necessary materials (projector, whiteboard, etc.) is booked and set up. The requirements engineer selects the stakeholders, invites them, and agrees on the workshop objectives with them. The requirements engineer then assigns the role of the minute-taker.
The implementation starts with an opening from the requirements engineer, welcoming the stakeholders and explaining the objectives and results of the work, as well as the procedure. In addition, the techniques to be used (e.g., written brainstorming and change of perspective) are introduced, and the rules for the workshop are presented (e.g., no criticism during the brainstorming process). In the working part, the requirements engineer moderates and the minute-taker documents the results of the work. The implementation
is concluded with a collection of open questions and a retrospective of the workshop. The follow-up of a workshop serves to process the results of the work by the requirements
engineer and obtain the approval of all involved stakeholders.
What happens in the first phase of a standard interview?
To conduct an interview, the requirements engineer must know the technical language or terminology of the interviewee and use it. Furthermore, the explicit definition of the interview objective, the selection and invitation of the participants, the determination of the interview location, and the concrete design of the interview questions are part of the preparatory activities.
The interview questions can be open or closed. With open questions, the interviewee must answer independently and freely. Open questions give the respondent the freedom to provide a lot of information, which is also more difficult to evaluate. For closed questions, direct questions and statements have proven particularly effective. To answer the closed questions, there are various predefined answer options. Yes or no answers ask for agreement or disagreement with a direct question. Rating scales ask about the degree of agreement with a statement. It depends on the formulated statement whether the scale offers an odd or even number of possible answers. A neutral response option is always given with an odd number of
response options and can lead to stakeholders choosing the middle if they do not want to decide. With an even number of response options, the stakeholder must express a tendency to agree or disagree.
What happens in the second phase of a standard interview?
If the requirements engineer and the interviewee do not know each other, the interview begins with an introduction of the interviewer (requirements engineer) and a short thank you to the interviewee for taking the time to participate. An introductory question can also be asked, which does not necessarily have to be part of the interview questions. It serves to create a pleasant, relaxed, and positive atmosphere. The requirements engineer then explains the aim of the interview and begins the questioning.
What happens in the third phase of a standard interview?
The answers to the questions must be recorded, so a transcriber can be present or the interview can be recorded. In both cases, this must be discussed with the interviewee
beforehand. The requirements engineer gives the interviewee feedback on their answers to check whether they have understood correctly. However, more in-depth, further questions can also be asked. In addition, the requirements engineer should make sure to regularly take small breaks (e.g., after each answer), which gives the respondent the chance to reflect on what has been said.
What happens in the fourth phase of a standard interview?
The implementation is concluded with a summary of the interview results, a thank you, and the indication that the respondent will receive a summary of the results. For the follow-up, the protocol is prepared and sent to the interviewee for a confirmation of the results.
How could a requirements engineer conduct a questionnaire as an interview technique?
Questionnaires are suitable for interviewing a large number of stakeholders. First of all, the stakeholders must be chosen (a full survey is generally preferable). If a full survey is not possible, the requirements engineer must select a representative set of stakeholders. Because the requirements engineer does not have the possibility to actively steer the survey, the questions must be formulated carefully.
The elicitation of questions can be supported, for example, by a creativity technique or workshop. It may be necessary to prioritize the questions. For example, if the respondent
loses interest or has too many questions to answer, there is a high risk that the survey will be abandoned. In addition to prioritizing the questions, it is also necessary to determine the level of detail the questions should have, then decide which questions are to be open and which are to be closed. In many cases, sending out a questionnaire is the first step, followed by individual interviews in which, e.g., answers to open questions can be clarified. Digital questionnaires can be created and carried out either in word processing programs or specially developed tools. The advantage of using a tool is the possibility to evaluate the data directly in the tool.
What is the Field Observation as an observation technique?
In a field observation, the requirements engineer is on site and directly observes the business processes taking place. They record the activities and their chronological order to determine the work processes. The observer does not have to observe passively; they can actively ask questions and have work processes explained to them. Before conducting a field observation, the observer must have a basic understanding of the stakeholders’ working environment and what they do.
The danger of field observation is that the requirements engineer is perceived to be supervising the stakeholders’ work. Therefore, the requirements engineer has to be very sensitive. If the stakeholders feel watched or controlled, this can impact the way they work, thus distorting the processes and, ultimately, the requirements. Another challenge is critically questioning all processes in order to identify potential for optimization. Processes that are stuck and in need of improvement should not be transferred one-to-one into the new system. The requirements engineer can support the field observation with audio and video recordings, but, in this case, they must first obtain the consent of those observed. Field observation can be used to identify processes that are difficult to convey in language and unconscious requirements that are taken for granted.
What is the Apprenticing observation technique?
Apprenticing is another observation technique. It differs from field observation in that the requirements engineer both observes and performs processes. The requirements engineer apprentices with stakeholders and learns what they do. As an apprentice, they can directly question unclear or incomprehensible actions and processes. Furthermore,
unconscious processes can become explicit for the requirements engineer, and requirements that are self-evident for the stakeholder can be highlighted through questioning. This way, the stakeholder no longer feels controlled, but in a lofty position, as they are allowed to pass on their knowledge as a teacher.
Learning different activities is very time-consuming, which can be a disadvantage of this technique. It also cannot be used in every field. Safety-critical activities, such as monitoring a power plant or production line, are less suitable because the learner can cause considerable damage if mistakes are made.
