Lonsdale Systems

The Requirements Discovery Canvas in a Nutshell

My original post describing the Requirements Discovery Canvas is quite lengthy and requires a fair investment of time to read. This post is for those wanting to get a quick overview of the canvas and how it is used.

The Requirements Discovery Canvas is a visual tool that helps teams discover and organise software requirements. Inspired by the Business Model Canvas, it provides a framework for collaboration leading to shared understanding, that can be used by both agile and traditional software development teams.

For agile teams, the canvas provides a context for populating a product backlog that drives the incremental delivery of a solution.  For traditional teams, the canvas serves as a front-end tool for scoping the features of a solution that will later be elaborated into detailed requirements.

The Requirements Discovery Canvas guides teams through the discovery process in two ways. First, it prompts the team to consider some fundamental requirements questions. Secondly, it serves as a visual framework for organising what the team discovers.

The canvas is not tied to a particular requirements philosophy or approach. Teams are free to choose the approach that suits them best. They can choose between a simple approach guided by the structure of the canvas. Or they can use the canvas in conjunction with a more elaborate approach if they wish. The canvas has three major sections.

Business The Business” section of the canvas answers the fundamental requirements questions:

It consists of four areas.

This area identifies the product owner who is responsible for controlling the scope of the solution and ensuring that it provides value to the organisation as a whole.

For agile teams, the product owner is usually a business representative who serves as a full-time member of the team.

For traditional projects, the product owner is often a steering committee whose members provide a balanced representation of all business areas.

This area identifies the subject matter experts (SMEs) who possess expert knowledge of either the business area under investigation, or some aspect of a proposed (or existing) solution.

This area identifies other stakeholders such as:

This area identifies and describes the operational goals of stakeholders.  While most stakeholders can easily identify and describe strategic goals, many have difficulty articulating their operational goals.  Activities provide an indirect way of identifying operational goals.  Activities should be described using active verb-noun phrases such as Accept reservation for rental cars”.   

Reversing the verb and noun in the activity description reveals the intended outcome (goal) of the activity.  Stakeholders should find it easy to confirm that Reservation for rental cars accepted” is an important outcome describing one of their operational goals.

If the business area is large and includes many activities, it is useful to group activities into higher-level business capabilities. These describes a business area’s ability to repeatedly perform a group of related activities.

Need The need section of the canvas answers the fundamental requirements question:

The canvas allows for two different levels of need: 

In the context of the Requirements Discovery Canvas, a Need” is something that can be satisfied by a software feature.

The Need” section of the canvas consists of three areas.

This area identifies strategic needs that often emerge from a SWOT analysis. Strategic needs describe the ability to:

This area identifies and describes the information required to support stakeholder goals as described by the activities they perform.

This area identifies and describes the rules that must be enforced to support stakeholder goals.

Solution The solution section of the canvas answers the fundamental requirements questions:

Some may ask what place a description of the proposed solution has in a requirements canvas? There are several reasons why a strictly solution-independent view of requirements is less useful than in the past:

In addition, teams that support existing solutions need to understand the existing solution’s components, APIs and user interfaces so that they have a good baseline on which to base future enhancements.

Those wishing to develop a truly solution-independent list of features can simply ignore the final column of the canvas with the possible exception of the solution vision.

The Solution” section of the canvas consists of four areas.

This area lists software features that will be implemented by the solution. Software features are short statements describing a software capability or constraint.

Stakeholders should be able to recognise the purpose of a feature and confirm that it satisfies one or more of their needs.

Capabilities describe functions that:

Constraints are restrictions that can be placed on individual capabilities; or limit the entire solution in some way. Constraints often describe qualities such as reliability, usability, security or performance.

This area describes the vision for the solution including:

This area identifies and describes the most important user and system interfaces (APIs) provided by the solution.

This area identifies and describes the most important components of the solution.

The Requirements Discovery Canvas in a Nutshell

Courses Resources Blog Portfolio About Contact Search Feed
Lonsdale Systems