Best practices for requirements workshops

Just as A comes before B and 1 before 2, so requirement determination comes before requirement implementation. This is not surprising, because only if you know what a software, a system or a service should perform, you can implement this accordingly. And how can you determine correct, unambiguous, consistent, verifiable, modifiable and traceable requirements that are evaluated in terms of importance and/or stability? The answer is: with requirements workshops. The range of topics that can be addressed in requirements workshops is very wide; it ranges from working on individual characteristics such as consistency or the correctness of the requirements formulation to more general topics such as, for example,

• the identification of stakeholders and their goals, as well as the coordination of goals,
• the definition of a product vision,
• the delimitation of the system and/or the identification of interfaces
• the discussion of use cases,
• the derivation of requirements from objectives, scenarios, the delimitation of the system, from use cases etc.,
• the collection, refinement and evaluation of requirements,
• the definition of a customer or requirement specification,
• or the definition of project requirements (which should ideally be documented in the project order or in a project manual) such as deadlines, milestones, dates, budgets, etc.

Requirements workshops are popular in many companies, but poorly organised workshops can lead to disputes and thus to a bad mood in organisations. Good preparation, constructive implementation and structured follow-up are the three essential phases of successful requirements workshops. And for each phase there are best practices.

Preparation of requirement workshops

Good preparation is essential for the success of a requirements workshop. It is the basis for a target-oriented implementation. There are many small questions, i.e. who, when, where, how and what:

• Who should participate in the workshop and who will moderate the exchange?
• How is the workshop organised, how long does the meeting last and where does it take place? How often does the group gather (once a whole day, several times in an agreed period of 4 hours, regularly after a release release?), how is the invitation done, how does the communication with the participants take place before and during the workshop, what is the procedure, how are the results documented and how do all participants continuously have their say?
• What should be achieved, what are the goals – e.g. what is the primary goal and what are the secondary goals?

Why is the preparation so important for the success of requirement workshops? Once you have attended an event and you didn’t know the agenda, you didn’t have work materials, the technology didn’t work on site, it was too warm, noisy or stuffy – how great was the event? More importantly, how good were the results? The preparation lays the foundation for meaningful cooperation, for effective work at pre-defined points. Even if you personally have a lot of experience in conducting requirements workshops, it can look different for each individual participant. It therefore helps to put yourself in the position of the participants in advance and to shed light on the process and the exchange from their point of view. The following best practices are available for the preparation of requirements workshops:

• Determine the goal of the workshop and define the desired result.
• Plan the topic and the course of the event to achieve the desired result.
• Identify the most important stakeholders and invite them with hints on the goal, topic and process. This is very important because you need the participation and input of the stakeholders. If possible, you should therefore issue invitations in person. Ideally, you should not invite all stakeholders to each requirements workshop, but only those who can contribute to your defined topic.
• Use suitable techniques for interaction and communication such as brainstorming, brainwriting or braindumping. Very modern formats such as session planning at bar camps are becoming more and more popular, but do not fit into a structured requirements workshop.
• Find a location with one or more rooms so that you can perform the planned exercises such as group work or fishbowl discussions well. The longer you are on site with the participants, the more you should pay attention to a pleasant climate – a room in the basement without daylight, fresh air or freedom of movement cannot have a positive effect on the exchange and quality of the results. Also make sure you have sufficient materials such as flipcharts, whiteboards with washable pens, beamers, paper, etc. The presence of drinks can also work wonders.

It is advisable to hold initial workshops, in which topics such as goals, vision and typical applications are discussed, together with all participants in one place. At a later date, individual participants from other locations can also be connected via the Internet. Of course, this also requires appropriate preparation, testing of the technical connection, separate techniques for interaction, etc.

Implementation of requirements workshops

The success of a requirements workshop stands and falls with the execution of the meeting. Stakeholders’ time is limited and they are often used to their statements being implemented directly. A requirements workshop, however, is about the consensus of a goal definition, a common product vision or the evaluation of requirements. Different opinions will almost automatically lead to discussions. A clear, neutral and yet goal-oriented moderation is particularly important here. The following best practices are suitable for conducting requirements workshops:

• Welcome the participants, introduce yourself, possibly your role and in any case your task during the workshop. Despite your nervousness, speak with a clear voice, because the first impression counts here as well. You should choose a similar starting point even if you repeat the workshop, because participants can vary. Don’t wait for laggards – this is a sign to those who arrive on time that the missing participants are more important than those already present. Also later explanations of the rules are so directly questioned, because the first rule “beginning at 9.00 o’clock” was bend already.
• If not all participants know each other, you should conduct a short introduction round – gladly on the basis of defined questions such as the name and the activity in the enterprise, the possible role in the project or the use of the solution which can be developed. The inquiry of individual goals in relation to the workshop (“I wish today that …”) is however often not meaningful, because you have already defined the goal of the workshop in the preparation.
• Describe the goal and write it down visibly for the participants at any time. In this way, you can always steer the participants towards the goal in the course of discussions. It is also a good idea to publish the agenda in a visible form – with or without time information. Rules – such as the use of mobile phones and laptops or the documentation of the results by one or more people – can be formulated, but you do not have to formulate them in writing; it is often sufficient to briefly explain them.
• At the beginning it is a good idea to encourage each participant to become active. For example, in five minutes, ask the participants to record their goals for the new software, system or service on moderation cards and attach them to a pinboard. Then group the goals together and identify redundant or contradictory goals. Conflicts about goals can be addressed at the beginning or during the workshop. If, for example, many use cases are defined to achieve a goal, this can be an indication of the significance of the goal. Thus it may be easier for a stakeholder who has formulated a less popular goal to do without it.
• Depending on the orientation of the workshop, you can use open discussions, group work or individual tasks to name use cases or scenarios, system boundaries or project requirements.
• Summarise interim results regularly. This strengthens the consensus in the group and also helps to understand the contents. Often, different interpretations of terms occur in the course of discussions – you can create a glossary here. If requirements are explicitly excluded, you can also create an exclusion list or an out-of-scope document.
• Keep to the agenda. If you have planned too much – despite all experience this happens again and again – it is better to arrange a follow-up appointment.
• Take breaks and observe the group and individual members during the break. Even if this sounds unusual, participants often continue to discuss during breaks and gain new insights. You can easily find out about these by asking a question: “Did you still determine ideas / goals / use cases / requirements / findings etc. during the break?
• At the end of the requirements workshop, summarise the results. Obtain the public agreement of the participants to these results. If there are conflicts and dissonances, record them as well – e.g. on an open points list. Conflicts can then be discussed bilaterally or at the next meeting together in the entire group. It can also be useful to agree individual tasks with the participants.
• At the end you should arrange a next meeting on site if necessary; ideally you already have 2 or 3 appointments in view, which you can vote on. Probably not every participant can appear at each of the suggested dates – that doesn’t matter, because every participant is allowed to send deputies – if it makes sense.
• Get feedback from the participants: What was good, what can be done even better next time? To do this, you can make a short verbal or written enquiry.

By the way, in German speaking countries it is not advisable to set the mutual approach to “first names only” for the duration of a requirements workshop. Especially in an organisation without a generally accepted “first name policy”, employees often choose the mutual approach with caution. If Fred and Martin both call Thomas by his first name, Fred and Martin can still call each other by there last names. It is unnecessary to cancel this by order.

Follow-up of requirement workshops

Often a requirements workshop is followed by another requirements workshop. All agreed contents must be documented. This documentation can be used to start the next meeting and can help to define the next goals. Without follow-up, content may be discussed repeatedly in the next workshops – this would not only be inefficient, but also counterproductive. The following best practices have proven themselves in the follow-up process:

• Document all findings, i.e. goals, use cases, scenarios, system boundaries, software, system or service requirements and all project requirements. Enrich the results with photos from the workshop – this helps people to remember agreed aspects better. For example, create a report including the pre-defined goals, the participants, the agenda, the techniques used, etc. Concrete results can also be recorded in separate documents such as a stakeholder list with goals, a system context diagram, a customer specification, a requirement specification, a list of use cases, a system and software requirements specification, a glossary or a requirement diagram.
• Send the results to the participants with a thank-you for their active participation and an outlook on the next steps ( realisation of the requirements, agreed tasks, subsequent meetings).
• If you have requested the feedback in writing at the end of the implementation phase, you could also send the results. Of course, you could also include a questionnaire afterwards, but it should be kept short, as most participants do not have much time. One or two personal conversations in a coffee kitchen could also provide feedback here. In addition, you should ask yourself: Were the goals achieved from your point of view? What can you do better next time, what worked well, etc.?

Bottom line

Each participant in a requirements workshop invests time. The more participants are involved in the exchange, the greater the overall effort and the more important preparation, implementation and follow-up become. Good preparation is essential for a constructive exchange. By defining the goal of the workshop, you will identify topics and participants, techniques and procedures. Inviting stakeholders with little motivation to a workshop is probably not the best idea; individual interviews or observation techniques often make more sense here.

In the actual implementation it is important to integrate all participants and to control discussions and group work effectively and efficiently. Good knowledge in requirements management or requirements engineering is also rarely disturbing. And of course a goal-oriented, motivating moderation is very important. It conveys a common understanding of goal, procedure and time frame and orchestrates the collection, grouping and evaluation of information. The follow-up documents the results, which can be used for the planning of the implementation and the subsequent realisation of requirements or as a basis for the next workshop. The preparation thus lays the foundation for the implementation, the implementation produces the results, which are recorded in the follow-up. And the results become the input for the preparation of the next workshop or flow into the planning of the requirement realisation. You’ve reached your goal.

Notes:

Michael Schenkel has published more articles in the t2informatik Blog, for example

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