Requirements Discovery Canvas

What is the Requirements Discovery Canvas?

We’ve seen a surge of Canvas Models in the last years. Especially the Business Model Canvas has seen a has gained a lot of popularity mostly thanks to today’s StartUp Hype. Many more Canvases for specialized topics have been proposed, such as the Product Canvas, the Service Model Canvas or the Lean User Experience Canvas.

And what if you are a Business Analyst in a software project like me? We’ve got your own canvas! Let’s check out the “Requirements Discovery Canvas” as proposed by Phil Robinson. Phil Robinson runs Lonsdale Systems, an IT consulting company that provides training courses for clients throughout Australia and SE Asia. He has also published a number of articles on IT Architecture in various journals.

In 2015 he published the Requirements Discovery Canvas, which he describes as follows: “The Requirements Discovery Canvas is a visual tool that helps teams discover and organize software requirements. Inspired by the Business Model Canvas, it provides a framework for collaboration, that can be used by both agile and traditional software development teams.”

It’s important to understand that the canvas is not confined to the use in agile teams even though sometimes we have the feeling that agile teams like to embrace and adopt new ideas or tools faster than traditional teams.

Let’s be clear, in the same way the Business Model Canvas is not a tool to manage your business, the Requirements Discovery Canvas is not a tool to manage your requirements, but to provide context. It is best used in the initial stages when you are about to start your project and have nothing but an idea or maybe a vague concept. That can be well before we even think about setting up the project in an agile way or not, or at least at the same early stage.

The Requirements Discovery Canvas is designed to fill the gap between a vague idea or a business case that hasn’t got a whole lot to do with the real implementation and “provide teams with a context for populating a product backlog.”

Instead of populating a product backlog the canvas can also come in handy for the initial scope definition in a traditional project handbook. In my opinion it is also an excellent instrument that you can use when you are trying to price your service or frame a contract.

At the beginning of a project the business side is usually never slow to state their perceived needs, after all, why would they want a new project if they hadn’t plenty if needs to begin with. Enabling the stakeholders and/or product owners to understand the context and their own real business problem in a more concise fashion, usually leads to a higher quality of requirements, since many perceived needs or requirements are solving the wrong problems. There is an short, yet interesting article on solutionsiq.com by David Bland to encourage product owners to be relevant in their respective projects.

But let’s get back to the Requirements Discovery Canvas.

Major Questions of Requirements Engineering

What the canvas does is to make you think in a structured way about some fundamental questions of requirements engineering regarding „who“, „what“ and „how“.

• Who is involved? Who is using going to use the solution? Who has other interests? Who are my stakeholders?

• What do they do? What are the tasks or processes they perform?

• What do they need? What are their current problems?

• How could they use a software tool? How does can the solution support them? How can it relieve their pains? How can it increase their gains?

• What is the existing vs. propose solution? What do we actually want to provide for them?

Major sections

So let’s jump into the three major sections the canvas is comprised of. The Business section, the need section and the solution section. That’s also the order you will usually walk through the canvas in a workshop when trying to populate it.

• The “Business“ section prompts the team to identify the product owner, subject matter experts and stakeholders and understand their goals as well as the activities they perform.

• The “Need“ section prompts the team to explore stakeholder needs. The context for exploring stakeholder needs is provided by the “Business“ section of the canvas. The need section itself is broken down into the strategic needs, information needs and into business rules.

• The “Solution“ section prompts the team to propose solutions that will satisfy stakeholder needs. The context for proposing solutions is provided by the “Need“ section of the canvas. On the one hand the “Solution” section describes the Features and Vision of the software product, one the other hand adds a more technical perspective by looking at the most important interfaces and components.

Note that I didn’t cover every detail here, but if you want to read more, why not check out Phil Robinson’s blog first-hand!?

Pros?

So what kind of advantages do I see?

A canvas-sized approach makes you want to scale it down to fill only the most-important aspects of each part, which hopefully leads to a little less feature creep.

The advantage of the canvas over a mere checklist is that it also inspires communication and discussion and leads to better and more creative ideas, while a checklist often focuses more on completeness.

The canvas is vendor and domain independent and doesn’t focus on any specific kind of IT project. The canvas can be applied to a cloud storage solution as well as to an E-Commerce system. Should be a given anyway, yet is not always the case.

Any cons?

The canvas doesn’t help you much in prioritizing features other than sticking them top to bottom in the sense of a backlog. A small weakness, if you want. You could however argue that that’s just not it’s focus.

The canvas doesn’t really help you in requirements validation. The canvas gives you a good context spanning from the business section via needs to solution, therefore it lessens the concerns on validity of the discovered requirements, however, consistency, completeness, realism and verifiability are still issues to be addresses by the Business Analyst. If you are concerned with requirements validation, you can also check out Omar El Gabry’s blogpost on requirements validation on medium.com.

So far I haven’t found any tool that explicitly supports the requirements discovery canvas, but I don’t really see any special tool-support as necessary as it would be pretty easy to customize Jira or Trello to it. If you know any tool, I’d appreciate if you told me in the comments below.

If you want to use it in a workshop-style the way I would, Phil Robinson also offers a blank template of the canvas here. Some classic approaches never go out of style.

Summary

Personally I see the canvas as a great tool for requirements discovery. You just need to know when to use it.

If you want to learn more on how to properly fill the different sections of the Requirements Discovery Canvas in a meaningful way, tell me in the comments below or follow Lean Coders.

Further ressources

If you need more resources on the Requirements Discovery Canvas check the affiliate-links down below. These are two of the books I often recommend in order to get the most out of your requirements workshops:

• “Executable Specifications with Scrum: A practical Guide to Agile Requirements Discovery” by Mario Cardinal AND

• “How to Run Awesome Discovery Sessions” by Trond Frantzen.

If you want to take a shortcut, try reading: What Questions Do I Ask During Requirements Elicitation? It’s much shorter and, well, you don’t need to buy a book.

Me and Lean Coders

My name is Patrick Schmöllerl. I work as a self-employed Business Analyst, currently with a focus on Requirements Engineering. I met Christoph on a project where we were working together on an e-Commerce solution for our client. I hold him in great esteem and therefore, when he asked me about writing a guest post for his blog I was more than willing to do exactly that. If you want to find out more, check me out at patrickschmoellerl.com