Workshops on identifying requirements for IT projects: how and why to carry them out?

    image

    Why even 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 government organization. Such an organization, as a rule, has a complex hierarchical structure with many divisions: departments, departments, various departments - legal, financial and economic, personnel department, public relations department, etc. All of these units have well-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 separately from each unit. And it is unlikely that this will be possible through Skype calls.
    When you try to combine the requirements of different departments into one big picture, conflicts will certainly arise: each department has its own vision of the interface and business processes.
    Requirements will not fit into the previously agreed budget, it will be necessary to reduce the amount of work, and, of course, none of the interested parties will want to remove the functionality that would be useful to her.

    What to do?

    Out of the whole 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 requirements collection workshop, we want to tell you about him.


    What is a workshop?


    The workshop is one of the standard requirements collection practices, which is undeservedly given little attention in the literature, probably due to the difficulty of formalizing the process. From the very name “Workshop” it is clear that active work is taking place within its framework. Accordingly, those present by definition cannot take a passive part in what is happening. The point is that stakeholders come together to determine the requirements for the final product. Representatives of the contractor and customer are necessarily present at the workshop. As a rule, a workshop takes at least half a working day.

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

    The practice was developed by IBM in the late 70s. Then they were 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 carry them out?


    If it comes to developing the next Candy Crash clone or startup, where you and the users form the requirements, the workshop will be a waste of time - that's for sure.

    A workshop can be useful if several conditions are met:

    • You are developing 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 does not have ready-made analogues.
    • The project has many conflicting requirements , the resolution of which requires a collective discussion.
    • Business - critical projects. It is difficult for the customer to see the benefits of such workshops, especially given their complexity. Therefore, the more critical the project, the more the customer will be interested in its success, which means that 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 larger than 100 Functional points.
    • In the final product, several user groups are interested . For example, specialists from different profiles will use the ERP system.
    • The need to quickly identify requirements. For example, in situations where competing solutions are already gaining market share.

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

    Some statistics


    The complexity of this event, coupled with the amount of time that will go to the workshop, can scare away any enthusiast. But according to 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% ; the maximum result is achieved when using prototyping along with workshops
    • Save 5-15% of the time and labor for collecting requirements throughout the project

    Where to begin?


    It’s good practice to start with planning, in the case of workshops this is more relevant than ever. To do this, first of all, it is necessary to decide what we want from the workshop, what are our goals? This can be an improvement of the business process, identification of functional requirements (for example, in the form of usage scenarios, user stories), clarification of architecturally significant requirements, etc. In addition, the goal of a workshop can be to create both a draft and a final version of a requirements document.

    When the goals are known, the scale of the work is clear, you can estimate how many such events will be needed for your tasks. If you cannot keep up with one workshop, then you need to plan the schedule of all sessions and documents that must be created.

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

    Number of participantsOn average 4-12, no more than 25
    Session duration3 to 8 hours
    Session Frequency2-3 times a week
    Number of workshops per project1-8
    Preparation time2 times more than the session itself

    There are several different collection techniques for collecting requirements. We decided to dwell in detail on the technique described in the ACDM methodology . ACDM (Architecture Centric Design Method) is an approach to software development, its feature is an emphasis on architecture. This is far from the most popular methodology (recently someone even deleted the page with its description on Wikipedia), but it is in it that the most detailed description of the workshop technique is given, which (supplementing with our comments and observations) we will provide here.

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

    1. Planning


    The outcome of the workshop is largely determined by how carefully prepared for it. They didn’t think about transportation - half of the participants were late; late sent documents on the project - half of the workshop will go to read them; forgot to invite the right person - all the work will need to be redone. In a word, you need to understand that you take the time of many people (usually leaders, 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
    • Overview presentation of the project>
    • Materials
    • Nutrition
    • Transportation


    A place. It is very important that all the main characters are physically present at the workshop, because, as experience shows, it is difficult to involve people present virtually in the process, as well as delays and communication failures that prevent other participants from concentrating.
    If this is possible, it is better to choose a neutral place - one where the participants in the workshop will not be pulled by colleagues.

    The participants.First you need to decide who are the people interested in the project. Potential participants in the workshop are customers, end users, developers, analysts, integrators, testers, system administrators ... in a word, everyone who is involved in the project. Moreover, if the project brings together several customer companies and / or several implementing companies, then, of course, the presence of representatives of all these companies at the event is mandatory. In addition to interested parties, subject matter experts may be invited to the workshop.

    The organizing team (this may be a team of analysts or architects, depending on the process) should be extremely careful in choosing the participants for the workshop. It is necessary to evaluate the role of each participant in the organization that he represents, his attitude to 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 to refuse the presence of a potential participant or, conversely, not to conduct a workshop until you can agree with the right person.

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

    The author of the ACDM methodology recommends limiting oneself to 25 participants; a larger number is very difficult to coordinate.

    It is also important to determine the roles before the workshop. Conventionally, all participants in the workshop are divided into representatives of the customer and representatives of the performer. The former are the main source of requirements, the latter are passive listeners, the purpose of their presence is to plunge into 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 must be an experienced person who is able to lead the workshop and coordinate the discussion. As a rule, a leading analyst plays this role.
    • Timekeeper. He follows the time frame of the workshop (each item in the meeting plan 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 tiring, it is worth thinking 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 to the course of affairs, and roles will be assigned.

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

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

    Place: ...
    Date: ...
    Start time: ...
    End time: ...
    NB: Attention, turn off the phones during the workshop


    ActivityWhoTime
    Presentation of the participants<Coordinator>~ 15 min
    Project overview presentation<Customer Representative>~ 1 hour
    BreakAll~ 15 min
    Identification of functional requirements<Discussion supervised by the coordinator>~ 2 hours
    DinnerAll~ 1 hour
    Identification of quality characteristics (non-functional requirements)<Discussion supervised by the coordinator>~ 2 hours
    BreakAll~ 15 min
    Identify business and technical constraints<Discussion supervised by 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 obscure points, others may even become outdated, therefore, during the presentation process, participants often have questions that identify problem areas in the project.

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

    TopicDescription
    General business contextDescribe:
    • A brief history of the company and the market
    • Distinctive features
    • Current needs and how the project will help them meet

    Interested peopleDescribe those who are key stakeholders in the project (legal / physical), their role and area of ​​responsibility. If interested parties will directly use the system, explain how.
    General functionalityDescribe the approximate functionality of the system.
    Focus on the essentials, avoid details
    Technical limitationsDescribe:
    • Hardware and / or software that the system being developed must use for certain reasons
    • Other systems to integrate with
    • Mandatory technical standards, GOSTs, protocols

    Business restrictionsDescribe:
    • Time frame
    • Budget constraints
    • Legal Aspects

    Quality characteristicsTell us about quality system requirements, such as performance, availability, security. Explain verbatim why and to whom (from interested parties) they are needed.


    The presentation should be agreed with the representatives of the contractor - in addition to the relevance of the content itself, attention must be paid to the size of the presentation. If it does not fit into the allotted time, then you need to ask the client to reduce its volume, getting rid of unnecessary details, or to increase the allotted time. In addition, you can break the workshop into several parts, but you must understand 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:

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

    You can organize the space as follows:

    image

    Food. A hungry belly is deaf to work. To save time at lunch, it is better to hold it near the venue of the workshop, for example, in the same building. In this case, you can avoid situations where the dinner is delayed due to the fact that someone was looking for too long where to eat. Do not forget to reserve a place in advance, make an order. Also, so that those present do not get hungry and do not get 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 alternatives. Sometimes it makes sense to organize joint transportation of participants to the workshop venue, and if this requires intercity flights, it is necessary to resolve the issue of tickets in advance.

    2. Holding a workshop


    To begin with, the coordinator presents the workshop program to all participants and explains the basic rules:
    • Disconnect phone
    • Do not criticize the ideas of other participants
    • Do not be distracted - the completeness of the collected requirements depends on how involved the workshop participants are.

    After the announcement of the rules, it is worthwhile to briefly describe the objectives and procedure of the workshop.

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

    Next, the requirements collection process begins:
    • Functional requirements. It is important to ensure that the 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, their complete list is determined, this should take no more than ten minutes, then detailed scripts are written for each of the qualitative characteristics.
    • Business restrictions , such as deadlines, budget, legal aspects, and more.
    • Technical limitations include the need to use some specific technology (library, framework, platform, OS, etc.).


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

    For each category of requirements, we recommend that you prepare a template in advance. For example, a template for use cases can be found here.. So it will be easier for participants to orient themselves and they will be able to write down their ideas. In addition, templates help achieve uniformity in the design of requirements. Participants are given some time to record preliminary ideas. In one of the ways described below, the coordinator collects preliminary requirements from each of the participants. When the participant voices another demand, the rest help him to supplement it, make comments, and the coordinator controls the discussion. When the requirement is fully described, it should be displayed on the projector or written on the board - this way you can avoid repetition.

    image

    There are several ways to organize the requirements collection process:
    • By request . Everyone voices the requirements that he wrote when he wants. This can work in teams with fairly talkative people, otherwise comments can not wait.
    • In a circle . The advantage of this method is that everyone is involved in the process of collecting requirements. However, after a person voiced his idea, he can distract from the process. It is worth considering the possibility of skipping a circle in case the participant runs out of ideas.
    • Random survey . Something between the 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 the part of the system that is interesting to him. This method is effective when several users use the system for different purposes. 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 their desire to participate in the discussion at all.


    At the end of each stage, prioritize as follows: give out votes to all participants (in terms of number they should be from a third to half the number of requirements). Each participant can vote on the requirements as he sees fit. Thus, in voting, participants can determine the relative degree of importance of the requirements, as opposed to prioritization in the spirit of high-medium-low. You can vote both openly and closedly.

    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 for some requirement there is not enough information, postpone the questions (for example, write down on a sticker and hang on a separate board) in order to return to them in the future after the meeting.

    On this the main part of the workshop ends. It is worthwhile to warn participants that their help may be needed at the stage of processing the collected information.

    3. The final part


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

    The diagram below shows the process of processing requirements collected in the framework of one or more workshops:
    image

    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 depends on the level of organization, therefore it is advisable to put a person with experience in conducting such events on the role of coordinator. In extreme cases, the one who at least once attended the workshop.
    • The participants . It is important to gather people who are able to make their own decisions for the group that they represent. In addition, before starting the workshop, it is worth clarifying that the opinion of all participants is equally important.
    • Start with the requirements and goals that cause the most controversy . This is obvious, but do not miss this moment.
    • If several participants cannot come, postpone the workshop . It will be a shame to spend so much time and leave more questions than answers.

    To summarize


    So, the workshop consists of three parts: planning, conducting and processing the information received. At the planning stage, all participants familiarize themselves with the available documentation, during the requirements are identified and specified, at the processing stage, documentation is generated on the basis of the collected requirements.

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

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

    Learn more about the MSIT-SE program here .

    Also popular now: