If you don't ask, you stay stupid!

Asking questions is important - after all, we can't read minds! Asking questions is also an important tool when eliciting requirements. In this article, I will discuss how asking questions can be implemented in practice.

By the way, one way to ask questions is through surveys. I have often conducted surveys and also published them here, such as the Survey on modeling tools. Or also the results published by others, such as the question of the importance of systems engineering.

And I would like to take this article as an opportunity to invite my readers to fill out a survey. The results will be published, which is an important prerequisite for me to pass on. The topic is "Product development: state of the art". Thank you very much for your help! To the survey >>

But now to the question of how to ask the right questions in the project to get good requirements.

Right questions

It's easy to ask the wrong questions: asking without preparation is not a good idea. It is also bad to ask and not use the result (unfortunately this happens far too often!). Asking at the wrong time can also be a problem. Here are a few guidelines to help you ask the right questions.

How to ask?

One Survey is one way to ask. However, this does not allow for any demand Conversation is possible. This can personally or by telephone or even as Chat or E-mail dialog. A face-to-face conversation allows you to include body language, while a telephone call still allows you to include the tone of voice. E-mail (or another asynchronous technique) is helpful if the other person has little time or lives in a different time zone. However, the "conversation" will then take longer.

Questions can be asked synchronously or asynchronously, individually or in groups. [tweetthis]Questions can be asked synchronously or asynchronously, to individuals or groups[/tweetthis].

Discussions can also be held in groups, which, depending on the orientation Focus group or a Workshop can be (for workshops I can recommend the book Workshops in requirements management highly recommended).

The questions can also be given a context: For example, you can look over a user's shoulder while they are working and then ask why they are doing it this way or that. Then the question becomes more of a demonstration.

Who has questions?

The following should be asked Stakeholderswhich were hopefully identified. Not all stakeholders are equally important, and it is perfectly acceptable not to interview all stakeholders (or representatives of all stakeholder groups). However, the risk of omitting a stakeholder group should be rated become.

It is also not unusual that even important stakeholders are not accessible, for whatever reason. It is then important to find someone who can at least assess such a stakeholder.

What questions?

The Aims of a survey should be clearly understood and preferably set out in writing. Then, when drawing up the list of questions, care can be taken to ensure that all questions are appropriate.

As a rule (but not always) Open questions should be preferred. Open questions cannot be answered with yes/no and have the advantage that the respondent is not restricted in their answers. However, open questions must also be evaluated manually. If a large number of people are surveyed, for example via an online survey, then this is a good option, Selection questions to ask. This usually also increases the number of answers.

Questions don't have to be answered in human language: the answer can also be an image. [tweetthis]Questions don't have to be answered in language: the answer can also be an image[/tweetthis].

By the way, an answer must not necessarily in writing have: A sketch or a plasticine model can also be legitimate answers.

When to ask?

It depends on the objective when the question is asked. In principle, questions should be asked as early as possible, as soon as sufficient information is available for the question. An extreme example: In order to be able to conduct a survey on the driving experience, at least one prototype must exist with which this can be evaluated.

Conclusion

It should come as no surprise that asking questions is an important task in systems engineering. However, not asking the right questions can lead to frustration and poor results. Asking a few questions about the questions pays off!

PS: Don't forget: I look forward to your active participation in the survey "Product development: state of practice (English)." Answer the survey now >>

Image: Saulo Mohana / Unsplash