Practical solutions for requirements gathering: elicitation

About this post

This post is one of a series looking at the different stages of gathering business requirements to inform digital projects – providing expert advice and practical tips to help ensure you get the information you want and the software you need. To find out more about the process, be sure to read our posts on requirements gathering preparation and making requirements gathering count, now available on the site.

The heart of requirements gathering

In my last post I explained why effective requirements gathering is crucial to successful software development projects, focusing on the preparation that should be undertaken at the beginning of the process to ensure you get off to the best possible start. Here I look at how to go about actually capturing the information you need in a usable and shareable format; as before, using the term ‘requirements’ to encompass the wide range of user, business and technical needs that your project may need to address. I’ll cover a variety of collaborative and non-collaborative techniques, from which you can choose those that best suit your individual requirements and environment – so let’s get started.

Collaborative techniques

Collaborative requirements gathering techniques are generally preferred at Box UK because they help build a genuine shared understanding of the needs, and possible solutions, in a project. This shared understanding is not limited to the Product Owner and stakeholders, but can and should extend to everyone in the team, including developers, User Experience (UX) designers and Quality Assurance (QA) engineers. It doesn’t mean though that everyone involved has to be in the original requirements session, but techniques, and importantly time, must be invested in collaborative sessions with the wider team.

This may seem like an overhead, but the alternative would be to write a long requirements document and have every team member read it and come to their own conclusions and interpretations, which will inevitably differ. When you consider the primary cost of this approach (document writing and reading) and the secondary cost (defects due to misunderstandings) then there is a clear return on investment from plenty of collaborative sessions. In fact, a client told us that they had accomplished more in two days of Box UK collaborative requirements sessions than they had in months of internal document writing, sharing and updating – the techniques really are that powerful.

Discussion

By this I mean ad hoc conversations to discuss particular tasks or other aspects of the project, taking place throughout the project. These can be used as a flexible gap-filling technique, or to quickly get answers to specific queries. An Agile project is full of these conversations; they are the engine room of shared understanding between the structured collaborative sessions and are where many ‘breakthrough’ moments occur in the wider project. Specifically in terms of requirements gathering, care must be taken to ensure team understanding is updated in response to any outcomes from these discussions; this is led by the Product Owner but is the responsibility of everyone.

Business Process Mapping

This is an established technique that plots out a business process by way of ‘swimlanes’ to identify who does what in the process, and when. This can help identify stakeholders and end users, as well as highlighting blockers and opportunities for improvement. Sessions can be collaborative with stakeholders, or the maps can be used to gather information from non-collaborative techniques and produce a single view. This technique is generally used in early project discovery to establish a current baseline, or ‘As-Is’ situation, and generate or capture an initial set of process or workflow ideas. It is also known as Business Process Modelling (when done with formal notation) or Swimlane Diagramming.

Workshops and User Story Mapping

These are structured group sessions to discuss and learn about key project needs. During early project discovery they should occur frequently to set the right direction for the project. They also need to occur regularly throughout the project to maintain and build shared understanding, and support Agile techniques to discover and manage requirements throughout the project. They are fully collaborative and interactive sessions, but critically require the presence of empowered stakeholders from the right areas of the business.

Box UK favours a type of collaborative workshop and approach known as User Story Mapping. Pioneered by Jeff Patton, it is a powerful collaborative product development approach that is designed around the goal of achieving project-long shared understanding. This technique allows the exploration of user journeys and user stories at multiple layers of detail. It allows intuitive prioritisation and high-level build planning, right down to the details of a task using the same technique, albeit in a slightly different context. User Story Mapping crosses over into analysis of requirements, so we will talk about it again next time.

Discussions, Business Process Mapping and User Story Mapping workshops are the primary collaborative techniques used by Box UK to extract and gather requirements. We can also call on a range of secondary techniques if sessions start to stall, become a little tangential, or if we need to find a different perspective on things…

Round Robin

A facilitator goes ‘around the table’, asking each session participant for a suggestion. While this may put people on the spot, it ensues a fair chance for everyone to contribute.

Greenfield

Often, a project or product has some history or legacy behind it that can influence how stakeholders approach problem-solving. In the Greenfield technique, participants are asked how they would approach this problem from a brand new starting point: “what would we do if we started from scratch?”.

Transporter

Similarly, the Transporter technique asks stakeholders to imagine that they are a specific different organisation: “how would Company X do this?”.

Assumption reversal

This is similar to the Transporter technique in some ways, but asks participants to imagine their own organisation in a different situation: “assume we are not market leaders; assume we are wannabes – how would we approach this?”.

User journeys

Here, participants are asked to walk through a specific task or tasks in the business system looking at (as a minimum):

• User roles in this part of the system
• Frequency of occurrence
• The background situation
• The start, process and outcome required

This technique can validate, explore and iterate requirements, as well as help identify constraints and boundaries. Successful user journeys can be used as the basis of workshop discussions, modelling and prototyping, user story generation, acceptance criteria and testing, and possibly even client training on an end project. User journeys can be used to assess a wide range of project tasks in the business, from common tasks, responses to important business events, difficult situations, and the boundary or interleaving of tasks. It is important though that if scenarios are used, you do not restrict them to just considering correct system usage.

Storyboarding

This is the generation of one or more diagrams or illustrations of sequential events and the users’ actions within them. User journeys can be used as inputs, and the outputs could be taken on into…

…Design Thinking Workshops

These sessions involve the sketching of User Interface (UI) concepts, to explore various options (including those requirements identified through other techniques) in a low-cost, low-risk environment. After a consensus has been reached as to the most suitable potential solutions, these can then be taken on into prototyping.

(Box UK’s User Experience team is highly accomplished and experienced in both Storyboarding and Design Thinking Workshops, and more information about the sketching technique can be found in our classic blog post on the subject.)

Non-collaborative techniques

Of course, the benefits offered by collaborative approaches doesn’t mean they should be your sole focus. Non-collaborative techniques also have a place in your toolbox of requirements elicitation methods, albeit mostly to support collaborative requirements conversations. Some non-collaborative techniques are genuinely complementary to the collaborative techniques that are the bulk of your effort. For example, observation of end users with an existing system can give new insight or validate statements and assumptions made in collaborative sessions. Also, traditional requirements and business analysis techniques such as interviews and questionnaires can be a partial substitute for participants who are unavailable for collaborative sessions, or who are otherwise hard to reach. The Product Owner then leads on bringing these views together into a coherent form.

Interviewing

Interviews are structured one-to-one question and answer sessions. Good interviews require thorough and thoughtful preparation to ask the right questions across different types: open; closed; multiple-choice; 1-10 scales etc. They are usually used in early discovery, and can be particularly useful in getting an initial picture of individual stakeholder views before collaboration.

Planning and adhering to a good structure can allow direct comparison of answers and quantitative analysis. However, some good judgement can be required during interviews, since a one-to-one interaction can lead to interesting or unexpected aspects that are worthy of further exploration. A disadvantage of interviews is that it can take a long time to achieve a group picture and identify edge cases or outlier answers.

Questionnaires

This is a written question and answer session, often performed remotely with no direct interaction between questioner and participant. While this allows hard-to-reach stakeholders to give their views, questionnaires need to be very carefully designed as there is no context available, and no second chance to clarify the meaning of a question. There is also no guarantee of a reply – indeed, if you are using questionnaire then you should plan for a situation where you do not receive answers from everyone. However, this is a useful technique to gain qualitative insight from a large user group or validate the findings from qualitative approaches with smaller groups; the user surveys that Box UK often use are a form of questionnaire.

Observation

Sometimes referred to as Contextual Inquiry, this is the observation of system users trying to accomplish their goals with a current system. This can uncover unique insight into the strengths and pain points of the system. It is useful when establishing the ‘As-Is’ situation as well as evaluating potential and deployed solutions. There can be a danger that users who know they are being observed can change their behaviour, e.g. if usual practice is to work around a clumsy but mandatory stage of workflow then this valuable insight could be hidden by the users being observed. To mitigate this, Box UK takes multiple approaches to usability testing, either remotely or using our on-site laboratory.

Conclusion

Equipped with the techniques detailed above, you’ll be able to gather high-quality requirements in both traditional and Agile projects. But what do you do with all of that wonderful insight? That’s the subject of my next post, as I look at ways to bring information together in a single coherent picture, for all stakeholders to understand the problem, and from there understand the potential solution.