Requirement analysis, but remote

Can there be anything better than dealing with the requirements of a software or system to be developed? For a requirements analyst probably not. The requirements collection and requirements analysis lays the foundation for the success of a development. Requirements must be

• complete,
• clearly defined and delimited,
• described in a comprehensible way,
• atomically broken down,
• consistent,
• identifiable,
• verifiable,
• comprehensible,
• consistent and
• uniformly documented.

Wow, what a challenge. And this makes requirements analysis a supreme discipline in the development of new solutions, not only in terms of content and methodology, but also from an interpersonal perspective.

And now all of a sudden everything is different. All of a sudden the requirements have to be collected remotely. A new client from the other side of the planet is acquired at short notice, an additional partner from a different time zone is added, or a pandemic changes everything overnight. What to do? How does requirements analysis work, but remote?

The tasks and methods in requirements engineering

The tasks in requirements engineering are very far-reaching and also differ depending on the angle of view. It applies for example

• to determine the system context,
• to manage the stakeholders, i.e. to identify them, recognize their goals, motives and attitudes, analyze their wishes, needs and conflicts
• to define use cases or misuse cases,
• to describe different scenarios with regard to the system to be developed, the interaction with the system and the organization,
• to identify the requirements and the architecture in lockstep
• and to specify, document and check requirements.

It is not surprising that there is a wide range of techniques or methods that can be used for these tasks in requirements analysis. Here is a small selection:

• Observation techniques such as field observation, apprenticing, interview, questionnaire or self-writing,
• Creativity techniques such as brainstorming, brainwriting, braindumping, change of perspective, mind mapping or analogy techniques,
• Artifact-based techniques such as document analysis or source analysis.

In addition, numerous supporting techniques, methods or principles such as the Kano Model, the Impact Mapping, the KISS principle or the YAGNI principle can be applied. The beautiful world of requirements engineering is a wide field of requirements analysis.

The challenges of a remote requirements analysis

What are the challenges of remote requirements identification and analysis? At first glance, of course, the distance. If the requirements analyst, the business analyst or the requirements engineer – whatever he or she is called – cannot be in the same place as the communication partner(s), methods such as field observation, apprenticing or brainwriting are no longer applicable. Other tools can also be used remotely, such as interviews, self-writing, document analysis; all you need is a telephone or a collaboration software. Supposedly.

In fact, a lot changes when communication parameters change. A 1:1 communication on an agreed topic via videoconference is not really a challenge, even if there are sometimes technical stumbling blocks, the image or sound transmission gets stuck or the connection breaks down for no apparent reason. Essentially, however, this settles down quickly and with a little practice, the exchange is almost like a conversation face-to-face. The real challenges begin with a 1:n communication, when familiar aspects of group leadership, the consistent orientation to the topic, the integration of all those present become difficult. What to do if facial expressions and gestures are missing or cannot be recognised? When participants switch off mentally? Or if the simple illustration of connections on a whiteboard does not work as usual?

The answer is: Good practices, to which organisers, moderators and participants have become accustomed, have to be rediscovered and worked on. The real challenge is that this has to happen parallel to the supreme discipline of developing new solutions, i.e. the collection and analysis of complete, clearly defined and delimited, comprehensibly described, atomically decomposed, consistent, identifiable, verifiable, comprehensible, consistent and uniformly documented requirements.

Tips for a remote requirements analysis

Workshops are very popular as a format for 1:n communication. Of course, a workshop for requirements analysis offline and online needs good preparation, excellent execution and smart follow-up. At Best Practices for Requirements Workshops you will find many tips on this topic. If you are dealing with the topic of remote requirements analysis, you should look at these tips from a concrete point of view: what does this mean for your remote requirements analysis?

Here you will find some additional tips:

• Mindfulness is important, especially because online exchange can be new territory for many participants. Mindfulness towards the other participants, but also towards yourself. Maybe you can also observe yourself a bit and recognise what the changed interaction, behaviour, technique and acting in uncertainty is doing to you. And if you observe corresponding changes in yourself, then you will also know that other participants feel the same.
• Try to be lenient. Be indulgent with “other opinions”, but also with the technology and idiosyncrasies of other participants who may use features less intuitively than you do. Ideally, make sure early on that all participants have a basic understanding of the tool used to conduct the meeting. Specify where questions are asked (in general chat, in private chat or in a separate Q&A forum) and how they are answered and when by whom. For example, explain how documents are uploaded, edited and saved, or how to work together on graphics or drawings.
• Deliberately start the online session a few minutes earlier. On the one hand, this will allow you to clarify any technical difficulties with regard to video and audio in advance. And on the other hand, you promote an interpersonal unfreezing, as is usual in offline meetings. This unreezing is particularly important, because most people are used to establishing interpersonal relationships through personal contact, handshakes or eye contact. Since this is understandably only possible to a limited extent online, it is also more difficult to start a trusting relationship.
• Integrate “energy boosters” like surveys or discussions in break-out rooms. Schedule breaks, more than usual.
• Use moderation cards if necessary. This is both fun and useful. (Heiko Bartlog has developed a great free print template).
• Accept the speed. You will find that especially in the beginning the cooperation works slower than you are used to. Similar to a relay race, the slowest runner is decisive. So try to focus on the novices especially at the beginning. You will notice that with generally increasing experience the speed will automatically increase again.
• Learn to only answer questions that you are asked. Do not try to solve other participants’ problems, even if you mean well. Cacophony would be the consequence (Gerhard Schröder, the former German Chancellor, sends his regards).
• Reinsure yourself, i.e. ask whether what you have understood and what someone else has said are identical. This is particularly important, as linguistic subtleties such as irony or body language are often not visible as additional indicators.
• Sometimes less is more. It is not about experiments, about new cool things, but simply about requirements analysis.
• Think carefully about who you invite, because the more participants in the exchange, the more difficult it becomes. Pay attention to group size, group composition and possible group dynamics.
• Communicate which phase of requirements analysis – collecting, sorting, supplementing, verifying or releasing – you are in. This increases the common understanding. Formulate a clear topic such as working on the value proposition, describing use cases, collecting features, defining key components or determining interfaces. And name a clear goal for the meeting.
• Try to develop a structured approach without micro-managing the participants. For example, do not try to convince participants to activate their camera if they do not want to do so. In the worst case you will succeed, but the participant will mentally switch off.
• Always do a Lessons Learned session at the end of a meeting. Ask each participant briefly what he or she would like to keep, change, try out or leave out the next time. This input is the basis for planning for the upcoming meeting and a first step towards new rituals.

In addition, there are certainly many other small tips. However, whether it is worthwhile to always have a piece of chocolate at hand, I unfortunately cannot give a general answer. 😉

Conclusion

The requirements analysis is an essential task on the way to the development of successful products. If the analysis is carried out remotely, this task becomes a particularly big challenge. In terms of content, methodology and interpersonal skills. In terms of content, because it becomes more difficult to identify important aspects for development together in the group. Methodically, because established aspects no longer function as usual. And interpersonal, because the entire cooperation has to be developed anew. The interaction is different. Facial expressions and gestures are hardly recognisable. Linguistic subtleties may be lost. Trust is harder to build. The group dynamics become a noble goal. Thus, the interpersonal aspect changes the entire requirements analysis. Aspects such as mindfulness, forbearance and reassurance become more important. And that is great news, isn’t it? People are moving back into focus. Those who understand this can master the requirements analysis, even from remote locations.

Notes:

Michael Schenkel has published further articles on dealing with requirements in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.