How to avoid missing requirements

A common cause for consternation in development projects is when requirements or features are missed in the early stages. Missing requirements in traditional development can be very painful, as the gaps are often discovered either in Quality Assurance or in UAT, or later, which means the majority of the development budget and schedule has already been spent and addressing these new requirements will set the project back a significant amount of time. When using an iterative and incremental method, such as Scrum or Kanban, missed requirements are less problematic because development is usually still ongoing and the requirements can be added to a backlog and re-prioritized. However, this can have adverse effects on the release plan and overall budget, and there is still the risk of learning of the gap too late.

The most common cause of missed requirements is that teams and customers focus on the detail of features and technology before the scope is really discussed and understood by all interested parties. Not establishing a “big picture” can result in potential users, stakeholders, functionality, opportunities, dependencies and challenges being missed.

There is no sure-fire way to avoid missing requirements. This is part of the reason that Agile methods rely on iterative analysis, design and development rather than up front analysis – demonstrating and getting feedback on the product from customers quickly and regularly helps reduce some of this risk and also is more likely to identify emergent requirements than reviewing requirements and design documentation. However, whether you’re using Agile, Lean or traditional methods, the following three tips will help avoid big surprises later:

Use several scope definition techniques up front

When planning for a project or even just the next release, you need answers to all of the following questions, so use at least 1 technique from each section below.

Who will the customers be?

Who will use the system, and who else will derive value or benefit from the solution? Who will we need to talk to when designing and building the solution? There are a number of techniques for identifying customers, including Use Case Diagrams, User Profiling and just general brainstorming. It’s also important to understand what the motivation of these users is when using the system and why the project is interested in satisfying them.

What will customers do with the solution?

When developing scope, the stakeholders and the development team need to have a common understanding of what is being automated and built. What business domains are affected? What business processes and procedures are involved?

We’re only looking for a very high level view here and we’re not describing how the system will work yet. Some techiques I’ve used are high level (end-to-end) scenarios, use case brain storming, story boarding and user story mapping.

What is the context of the solution?

One of the areas of highest risk in software development is dependencies and interfaces with other systems or entities. This starts with a conversation about where we will get information from and who or what will we need to provide information to. What processes or entities will we need to interface with? Context Diagrams are useful for this, as well as Use Case Diagrams.

If you can avoid getting into too much detail, none of the techniques above need a lot of time to complete, but can significantly reduce risk of missing important features or needs later.

Stay away from design and problem solving as long as possible

Keep in mind that you’re defining scope of analysis here, not the solution. You’re trying to understand the boundaries of what you’re building (and not building). If technical, legal, regulatory, complexity or other challenges are identified, take note, but stay away from the details until later. Keep things in business terminology and focus on casting the net wide rather than investigating all of the details up front. This is a lot harder than it sounds, which is why it’s usually best to have a facilitator use the techniques described above rather than holding unstructured meetings where people tend to dive deep into the details.

Involve more people rather than fewer

It can be tempting to keep meetings small at first, as larger groups take longer to come to agreement. However, in my experience this additional time is more than made up for in the amount of information gathered and the development of a common understanding of the whole solution. Emphasize getting people together in one meeting, where they can hash out their differences and communicate their perspectives together. Hosting separate meetings with different participants will not be as productive and can result in siloed perspectives.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s