Workshops to identify requirements for IT-projects: how and why to carry them out?

Why bother to write about any workshops? After all, requirements can be collected in simpler ways, for example, by organizing several Skype calls or a series of interviews. But will it always work?

Imagine creating an information system for a state organization. Such an organization, as a rule, has a complex hierarchical structure with many subdivisions: departments, administrations, all kinds of departments - legal, financial and economic, personnel department, public relations department, etc. All these divisions have established processes that, having optimized as much as possible, need to be transferred to the system being created.
')
What difficulties may arise here?

It will take a lot of time to collect requirements from each unit separately. And it can hardly be done through Skype calls.
When you try to combine the requirements of different departments into one big picture, conflicts will surely arise: each department has its own vision of the interface and business processes.
Requirements do not fit into the pre-agreed budget, will have to reduce the amount of work, and, of course, none of the parties concerned will want to remove the functionality that would be useful to her.

What to do?

Of all the variety of requirements collection techniques, it is worth highlighting one that is aimed at solving such problems (problems of large-scale projects with many stakeholders and conflicting requirements) - this is a workshop for collecting requirements , and we want to tell you about it.

What is a workshop?

The workshop is one of the standard practice of gathering requirements, which has received unduly little attention in the literature, probably due to the difficulty of formalizing the process. From the very name “Workshop” it is clear that within its framework there is an active activity. Accordingly, those present by definition cannot take a passive part in what is happening. The point is that interested people come together to determine the requirements for the final product. Representatives of the contractor and the customer must be present at the workshop. As a rule, the workshop takes at least half of the working day.

The workshop differs from a regular meeting in that its purpose is not to discuss various issues, but to produce a specific result — in our case, this is a document with the identified requirements.

The practice developed by IBM in the late 70s. They were then called JAD sessions (Joint Application Development) and later formed the basis of the Joint Application Development methodology. In one form or another, workshops are used in many development processes, but can be considered as a separate technique, without being tied to any process.

When and why to spend them?

If we are talking about the development of another clone of Candy Crash or a startup where the requirements are formed by you and the users yourself, the workshop will be a waste of time - that's for sure.

A workshop can be useful if several conditions are met:

• You develop a complex system with non-trivial business processes . This is perhaps the main condition. For example, the system is designed for a specific industry or has no ready-made counterparts.
• There are many conflicting requirements in the draft, which require collective discussion.
• Critical business projects. It is difficult for the customer to see the benefits of such workshops, especially considering their labor intensity. Therefore, the more critical the project, the more the customer will be interested in its success, which means it will be more willing to devote time to it.
• The project is big enough . According to statistics (C. Jones. Software assessments, benchmarks, and best practices. Addison- Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2000) workshops are most often used on projects with a size of more than 100 functional points (Functional points).
• In the final product is interested in several user groups . For example, the ERP-system will be used by specialists of different profiles.
• The need to quickly identify requirements. For example, in situations where the market is already winning competing solutions.

Summarizing the above, workshops are a tool that allows you to simultaneously resolve conflicting requirements, analyze the needs of stakeholders and make sure that the requirements take into account these needs .

Some statistics

The complexity of this event, coupled with the amount of time that will be spent on the workshop, can scare away any enthusiast. But according to the figures provided by EBG Consulting, workshops:

• Reduce the number of defects in the final product by 20-50%
• Reduce the risk of an uncontrolled increase in the volume of work by 10-80% ; at the same time the maximum result is achieved when using prototyping along with workshops
• Save 5-15% of the time and effort required to collect requirements during the entire project

Where to begin?

It is considered good practice to start everything with planning, in the case of workshops, this is more relevant than ever. To do this, first of all, you need to decide what we want from the workshop, what goals are we pursuing? This could be an improvement in the business process, identification of functional requirements (for example, in the form of usage scenarios, user histories), specification of architecturally significant requirements, etc. In addition, the purpose of the workshop can be the creation of both a draft and a final version of the requirements document.

When the goals are known, the scale of the work is clear, you can estimate how many such activities will be needed for your tasks. If it is impossible to keep within one workshop, then you need to plan the schedule of all sessions and documents to be created.

Below are summary data describing the use of workshops in Western companies. You can safely rely on them when organizing your own workshop.

Number of participants	On average 4-12, no more than 25
Session duration	3 to 8 hours
Session frequency	2-3 times a week
Number of workshops per project	1-8
Preparation time	2 times more than the session itself

There are several different requirements for conducting workshops. We decided to elaborate on the technique described in the framework of the ACDM methodology. ACDM (Architecture Centric Design Method) is an approach to software development, its feature is the emphasis on architecture. This is far from the most popular methodology (recently someone even deleted a page with its description on Wikipedia), however, it contains the most detailed description of the technique of the workshop, which (adding our observations and observations) we will give here.

So, the workshop consists of three main parts: planning, implementation and final part.

1. Planning

The outcome of the workshop is largely determined by how thoroughly prepared for it. They didn’t think about transportation - half of the participants were late; late sent the project documents - half of the workshop will be spent on their reading; forgot to invite the right person - all work will need to be redone. In short, you need to understand that you are busy with many people (as a rule, managers, and, therefore, their time is most valuable), and you need to do everything possible to get the most out of the action.
At the planning stage, you need to decide on the following main points:

• A place
• Members
• Program
• Project overview presentation>
• Materials
• Nutrition
• Transportation

A place. It is very important that all the main actors are physically present at the workshop, because, as experience shows, it is difficult for people who are present to be involved to take part in the process, as well as communication delays and failures prevent other participants from concentrating.
If this is possible, then it is better to choose a neutral place - one where the workshop colleagues will not pull the participants of the workshop.

The participants. First you need to decide who are interested in the project. Potential participants of the workshop are customers, end users, developers, analysts, integrators, testers, system administrators ... in short, everyone who is related to the project. And if the project unites several companies-customers and / or several companies-performers, then, of course, the presence of representatives of all these companies at the event is necessary. In addition to interested persons, subject matter experts may be invited to the workshop.

The team - the organizer (it can be a team of analysts or architects, depending on the process) should be very careful in choosing the participants of the workshop. It is necessary to evaluate the role of each participant in the organization that he represents, his attitude towards the product being developed - the missing participant, as well as the extra one, can cause a lot of trouble. Therefore, in some cases, it is worth politely refusing the presence of a potential participant or, on the contrary, not holding a workshop until you can reach an agreement with the right person.

As a rule, to gather all the right people together is not an easy task, especially if not all participants understand why this workshop was completely surrendered. Therefore, it is ideal to have a “person” on the client’s side, often in the person of the manager, he will coordinate the participants, set a date and convince them that the workshop is a priority task.

The author of the ACDM methodology recommends limiting it to 25 participants, it is very difficult to coordinate more.

It is also important to define roles before the workshop. Conventionally, all participants of the workshop are divided into representatives of the customer and representatives of the artist. The first are the main source of requirements, while the second are passive listeners, the purpose of their presence is to immerse themselves in the context of the project, as well as take notes during the meeting. However, between them it is necessary to distribute the minimum set of roles:

• Coordinator. (workshop leader) This should be an experienced person, able to lead the workshop and coordinate the discussion. As a rule, this role is played by a leading analyst.
• Timekeeper. Monitors the timeframe of the workshop (each point in the meeting should have a certain duration) and tells the coordinator if he goes beyond them.
• Secretary A very important role, this person will record all decisions made and open questions. Since this activity is very tedious, you should think about alternating roles.

It is also recommended that the executive team hold a preliminary meeting, where participants will be formally introduced to each other, introduced in the course of business, and will be assigned roles.

Workshop program. The coordinator should prepare a draft version of the program and send it in advance to all participants so that they have an idea of ​​the plan of the event and they can make their own changes.

Below we give an approximate template of the program. In the form proposed by the ACDM methodology, the workshop takes a whole working day, i.e. eight hours.

A place: …
Date: …
Start time: ...
End time: …
NB: Attention, turn off the phones at the time of the workshop

Activity	Who	Time
Introduction of participants	<Coordinator>	~ 15 min
Project overview presentation	<Customer Representative>	~ 1 hour
Break	Everything	~ 15 min
Identify functional requirements	<Discussion under the control of the coordinator>	~ 2 hours
Dinner	Everything	~ 1 hour
Identification of quality characteristics (non-functional requirements)	<Discussion under the control of the coordinator>	~ 2 hours
Break	Everything	~ 15 min
Identify business and technical constraints	<Discussion under the control of the coordinator>	~ 1 hour
Summarizing	<Coordinator>	~ 15 min

Overview presentation of the project. The planning stage is the time to ask the client to prepare such a presentation. Why is this necessary, if there is already a pile of project documentation?
The fact is that some documents may contain a number of unclear points, others may even become outdated, so during the presentation process, participants often have questions that reveal problem areas in a project.

Ideally, the client should prepare a graphic presentation (rather than an oral presentation). Below is an example presentation template:

Theme	Description
General business context	Describe: Brief history of the company and the market Distinctive features Current needs and how the project will help to meet them
Interested people	Describe who the key stakeholders in the project are (legal / physical), their roles and areas of responsibility. If interested parties directly use the system, explain how.
General functionality	Describe the approximate functionality of the system. Concentrate on the essentials, avoid details.
Technical limitations	Describe: The hardware and / or software that the developed system must for certain reasons use Other systems you need to integrate with Mandatory technical standards, GOSTs, protocols
Business restrictions	Describe: Time frame Budget constraints Legal aspects
Qualitative characteristics	Tell us about the quality requirements for the system, such as performance, availability, security. Literally explain why and to whom (from stakeholders) they are needed.

The presentation should be coordinated with the representatives of the artist - in addition to the relevance of the content itself, attention should be paid to the size of the presentation. If it does not fit in the allotted time, then we must ask the client to reduce its volume, get rid of unnecessary details, or increase the allotted time. In addition, the workshop can be divided into several parts, but it should be understood that this is justified only in the case of really very large projects.

As the workshop approaches, it will be necessary to deal with logistics as well:

Materials All necessary materials must be in place in advance. And this is not only paper and pens. You need to think about the seating of people, calculate the number of flipcharts, projectors, cables, prepare document templates, etc.

You can organize the space as follows:



Nutrition. Hungry belly to work dull. To save time at lunch, it is better to spend it near the venue of the workshop, for example, in the same building. In this case, you can avoid situations where lunch is delayed due to the fact that someone has been looking for too long where to eat. Do not forget to pre-book a place, make an order. Also, so that those present are not hungry and bored during the workshop, think about a small snack: tea, coffee, snacks.

Transportation. Typically, a team of performers arrives at the office to customers, but there may be alternative options. Sometimes it makes sense to organize joint transportation of participants to the venue of the workshop, and if this requires long-distance flights, it is necessary to resolve the issue with tickets in advance.

2. Conducting a workshop

To begin with, the coordinator presents the workshop program to all participants and explains the basic rules:

• Turn off the phone
• Do not criticize the ideas of other participants.
• Do not be distracted - on how involved participants of the workshop, depends on the completeness of the collected requirements

After the announcement of the rules, it is worth briefly describing the objectives and procedure of the workshop.

Then the customer presents the project (the presentation, as we remember, was prepared in advance by the customer). Conducted by the project manager on the part of the customer.

Next, the requirements collection process begins:

• Functional requirements. Here it is important to ensure that participants do not begin to describe the finished technical solution, but concentrate on what tasks the system will solve.
• Qualitative characteristics of the system. First, a complete list of them is determined, it should take no more than ten minutes, then detailed scripts are written for each of the quality characteristics.
• Business constraints , such as deadlines, budget, legal aspects, and more.
• Technical limitations include the need to use a particular technology (library, framework, platform, OS, etc.).

These categories are specific to the ACDM process. In your case, these could be usage scenarios, user histories, and other documents.

For each category of requirements, we recommend preparing a template in advance. For example, a template for use cases can be found here . So it will be easier for participants to navigate and they will be able to write down their ideas. In addition, templates help to achieve uniformity in the design requirements. Participants are given some time to write preliminary ideas. One of the methods described below, the coordinator collects preliminary versions of the requirements from each of the participants. When a participant voices another request, the others help him to supplement it, make comments, and the coordinator controls the discussion. When a requirement is fully described, it should be displayed on a projector or written on a board — this is how repetitions can be avoided.



There are several ways to organize the requirements collection process:

• At will . Each voices the requirements that he wrote when he wants. This can work in groups with quite talkative people, otherwise you can not wait for comments.
• In a circle . The advantage of this method is that everyone is involved in the requirements gathering process. However, after a person has voiced his idea, he may become distracted from the process. It is necessary to provide for the possibility of skipping a circle in case a participant has run out of ideas.
• Random poll . Something in between two previous approaches, but in this case the coordinator selects the next speaker randomly. The main charm of this mechanism is that everyone follows the course of events.
• By interests . Each describes that part of the system that is of interest to him. This method is effective when several users use the system with a different purpose. But, unlike the previous method, it is likely that participants will lose the thread of events. In addition, some of those present may not express a desire to take part in the discussion.

At the end of each stage, prioritize as follows: distribute votes to all participants (they should be between one third and one half the number of requirements). Each participant can give votes to the requirements as he sees fit. Thus, when voting, participants can determine the relative degree of importance of requirements, unlike prioritization in the spirit of high-medium-low. You can vote both openly and closed.

Important points:

• Do not proceed to the next until you describe the current requirement.
• If there are any important topics that are not relevant to the current discussion, or if there is not enough information for a particular request, set aside any questions (for example, write on a sticker and hang on a separate board) to return to them later on after the meeting.

This is where the main part of the workshop ends. It is worth warning participants that their help may be needed at the stage of processing the collected information.

3. The final part

Processing the information received
After the initial stage of collecting requests from interested parties, the team of the contractor is assembled separately to process the information received. Estimated course of events: the secretary of the previous meeting shows his notes on the projector, the team complements and edits, checking with his notes. This stage is the time to return to the topics postponed earlier.
The final version of the document is sent to all participants of the workshop.

The diagram below shows the processing of requirements collected in one or several workshops:

The secret of success

• Preparation All actions that can be done offline must be done by all participants in advance.
• Coordinator . The success of the workshop largely depends on the level of the organization; therefore, it is desirable to put a person with the experience of holding such events as the coordinator. In a pinch, the one who attended the workshop at least once.
• The participants . It is important to gather people who can make their own decisions for the group they represent. In addition, before the workshop, it should be made clear that the opinion of all participants is equally important.
• Start with the requirements and goals that cause the most contradictions . This is obvious, but do not miss this moment.
• If several participants cannot appear, transfer the workshop . It would be a shame to spend so much time and leave more questions than answers.

Let's sum up

So, the workshop consists of three parts: planning, carrying out and processing the received information. At the planning stage, all participants are familiar with the available documentation, during the requirements are identified and clarified, at the processing stage, documentation is formed on the basis of the collected requirements.

Of course, the workshop will not solve all the problems of interaction with the customer and, if mismanaged, will turn out to be an empty and tedious waste of time. However, with proper organization, the workshop is a powerful tool for engaging the customer in the development process, allowing you to come to a common vision of the final product and take into account as much as possible all the features of the developed system.

The material was prepared by the MSIT-SE program of Innopolis University. Details of the requirements collection are discussed in the “Software Design Methods” course .

Learn more about the MSIT-SE program here .