Practical solutions for requirements gathering: preparation

What is requirements gathering?

Requirements gathering activities are geared towards building a real understanding of a business, encompassing its customers, goals, and the wider market landscape. The process can encompass numerous techniques including SWOT and competitor analysis, collaborative workshops, and user and staff interviews and surveys.

Why is good requirements gathering important?

Correct gathering and analysis of requirements is a fundamental part of any engineering project, software included. The consequences of invalid, incorrect or missing requirements can be potentially horrifying, as this video about the usually excellent French railway system shows:

Think of the word “requirements” though, and you may well picture a long, boring document that goes into tedious detail about what is wanted in a system. Often, even these monumental documents miss details such as particular edge cases, or even acceptance criteria – and hence are still incomplete despite their size! Some software engineers and authors are so fed up of this approach that they have come to dislike the term “requirement”; I use it, however, merely as an umbrella term to describe some form of information about a user, business or technical need.

It doesn’t have to be this way. Much has been spoken and written about Agile working, which we at Box UK have embraced and have a proven track record in. Working in an Agile way does not remove the need for requirements; developers and stakeholders still need to know the ‘goalposts’ they are aiming for in any given task, but generally those requirements are generated and expressed in a different way (and at a different time) to traditional software development. Agile requirements management means gathering, expressing, prioritising and re-prioritising requirements throughout the project, to take advantage of everything that has been learned to date. This is a fundamental practice of Agile, and you can find out much more about it in our training and coaching courses.

The key reasons to gather and analyse requirements are the following: initially, to understand the current state of the business system, covering its strengths, weaknesses and opportunities. This is establishing the “As-Is” situation. On understanding this, we can explore and capture potential improvements to the business system, whether these are through evolution or a completely new product or approach; this is generating the “To-Be” situation. Once we have understanding of the “As-Is” and potential “To-Be” situations, even at a high level, then we can start to solve problems.

How do I gather requirements for my project?

When generating and managing requirements throughout your Agile project, there are certain options and steps that should be taken. Here, we look at the preparation that’s required to set you up for success; options for gathering requirements and analysis are set to be covered in future posts.

Preparation is an often overlooked aspect of requirements gathering, and it goes beyond setting the agenda of a session. Initial preparation generally splits into two areas: what do I need to find out, and who do I need to speak to in order to do this? After this, there are practical considerations to make sure your requirements gathering exercise runs as smoothly as possible.

What do I want to find out?

This is the fundamental question for every requirements gathering exercise. To get your answer, you would initially want to ask questions such as:

• What are the overall business objectives?
• What are the objectives for this project, and how do they feed into the business?
• How will success be measured?
• Who are your key user groups?

From there you will want to investigate end users and their needs, aligning these with the needs of the business to help form an overall vision and high-level scope for the project. Subsequently you will likely require sessions that delve into the further detail of any given themes that are identified, although it is useful to try and establish the breadth of a project before going into too much detail in any one area; this way, you can get an early picture of a high-level system and iterate your entire engineering process.

SWOT analysis

One method for exploring and understanding this question is SWOT analysis. Here, stakeholders discuss, or are asked individually to identify, specific Strengths, Weaknesses, Opportunities and Threats. Strengths and Weaknesses are internal positive and negative aspects of the project; Opportunities and Threats are the equivalent external positive and negative aspects. This could start off with a very high-level business view, or progress straight to the business area your project is addressing. Playing back these findings to the business helps stakeholders understand the current situation and what needs to be covered by – or, just as importantly, excluded from – the project.

Who do I want to speak to?

It is impractical to gather every single viewpoint on what is needed, so you will likely want to speak to informed stakeholders and/or subsets of user groups. It is important to make sure that these groups are representative of the main user and business groups affected by the project, so that the right requirements are captured and that prioritisation of these requirements is representative. Use of analytics can provide valuable insight into user habits, paths and needs, but for the foreseeable future interaction with people will still be a major source of information.

Part of answering this question may involve…

Stakeholder analysis

Stakeholder analysis is a traditional business analysis technique that still applies to Agile requirements. It seeks to identify the right stakeholders for the project, along with those stakeholders to whom you should be paying extra attention, and why. It is also an early opportunity to obtain stakeholder views, not just about the project in question but the wider context in which it will sit. There are many techniques for stakeholder analysis, but here are a few that we use at Box UK.

Stakeholder wheel

This is a technique to identify the types of stakeholders you have, as well as the types that you need to engage with. You can also use stakeholder wheels to categorise your known stakeholders. The addition of concentric rings can be used to indicate each stakeholder’s level of involvement, although it is also acceptable to split these into two diagrams for clarity.

Examples of stakeholder wheels

Power-interest grid

After identification and categorisation of stakeholders, a power-interest grid (or matrix) can be used to plan the management and involvement of stakeholders. Each stakeholder is considered and plotted in terms of the amount of power they have in their organisation, against the amount of interest they have in your project. The approach and extent of their management is then indicated by the quadrant in which they reside. Ideally, your stakeholders will tend towards the top-right quadrants – they will have strong interest in your project and be in a strong position to champion it in their organisation.

Example power-interest grid

Note that although we show and discuss a power-interest grid here, this technique can be used in a similar way to visualise a number of stakeholder attributes, such as support, influence or need.

CATWOE

There are numerous variations on this theme, but the aim of this technique is to understand what each stakeholder wants from the project in broad terms, and to uncover the direction that the stakeholder believes the project should take. To do that, a number of simple, standard questions are asked of each stakeholder:

C: Customer: who benefits from the project?

A: Actor: who carries out the activities in the system?

T: Transformation: what is changed into what?

W: World View: what is the wider impact of the changed process/system – why do this at all?

O: Owner: does this stakeholder have authority to make decisions and/or stop the project?

E: Environment: what external constraints and limitations apply to this project?

Perceptions of complexity

This is a more subtle aspect of stakeholder analysis, but still important. Projects will inevitably have areas of complexity – if the need was going to be easy to solve in every way, then it may well have been done already and almost certainly would not need a project to address it.

However – and this is the subtlety – not everyone sees each aspect of a project in the same way. Some stakeholders may see a particular aspect as simple or obvious, whereas others may see that exact same aspect as highly complex. Having a mismatch of expectations across stakeholders can be as deadly to a project as a misinterpretation of requirements – one stakeholder might expect a simple resolution to an issue, which will set their expectation not only for that issue but also related issues and possibly the rest of the project. If this is out of line with the views of other stakeholders then there is potential for conflict. For example, the stakeholder that sees the project as simple may expect fixed milestones and budgets, which if not hit will mean the project has failed, while stakeholders that think the situation is complex may view milestones as review points with opportunities to learn and adjust the project if necessary. Building a shared understanding at the outset is therefore vital to help avoid these kinds of issues arising.

Additionally, if you know a project is complex then you will manage it differently from a simple project; likewise, if all stakeholders have a shared view on the complexity of a project, that understanding will hopefully lead to realistic expectations that are aligned with your management approach.

There are a number of techniques to examine perceptions of complexity, but a popular one is the Cynefin framework. You can use this framework as a basis of conversation about project complexities to arrive at a consensus view.

The crucially important thing about stakeholder analysis, though, is to realise that its power comes from reviewing and updating it through the project. That way, you can ensure that you are listening to the right stakeholders at the right time, assess each stakeholder’s involvement and views against where you need them to be, and manage them accordingly to get the best contribution to the project.

Other aspects of preparation

• Agenda: all meetings should have at least a structure or loose agenda, which is engaging and challenging while remaining realistic
• Rapport: collaborative requirements sessions need to be disciplined enough to maintain focus, but relaxed enough that participants are encouraged to say what they truly think
• Outputs: at the end of the session, the participants should feel that they have learned something, rather than solely passed on their information and insight to someone else
• Documentation: many Agile techniques promote conversation over written documents and this is very true; however a conversation only has lasting value if it can be correctly recalled, so ensure you have sufficient documentation to save those conversation memories and prompt their later recollection
• Follow-up: if you want participants to further contribute to and champion your project, look after them – keep them informed and aware of how their participation benefits them!

Conclusion

Good gathering, processing and management of requirements is as important in an Agile project as in any other; it sets targets for people working on the project to aim towards. Projects can fail when there is a lack of understanding of these targets, and hopefully this post has shown that investing in adequate preparation is a crucial first step to building this understanding.