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.

• A “Business” section that prompts the team to identify stakeholders and understand their goals.
• A “Need” section that prompts the team to explore stakeholder needs, with the context for needs provided by the “Business” section of the canvas.
• A “Solution” section that prompts the team to propose solutions that satisfy stakeholder needs. The context for proposed solutions is provided by the “Business” and “Need” section of the canvas.

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

• Who is involved (stakeholders)?
• What do they do (stakeholder goals)?

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:

• regulatory bodies, who often have a major influence on requirements when there is a need for compliance;
• stakeholders who may be less “expert” than the SMEs, but never the less have requirements to contribute;
• stakeholders affected by a proposed solution, who need to informed of the anticipated impact; and
• “anti-stakeholders” such as “roosters” who strut around the organisation offering endless opinions on “how things should work”; or competitors, who must be kept in the dark about solutions offering some strategic advantage.

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:

• What do they (the stakeholders) need?

The canvas allows for two different levels of need: 

• high-value strategic needs; and
• less valuable operational needs such as: 
  • the ability to store, retrieve and manipulate information; and
  • the ability to enforce business rules that define, constrain or guide some aspect of the business.

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:

• build on or keep a strength;
• remedy a weakness;
• exploit an opportunity; or
• avoid a threat.

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:

• How could they (the stakeholders) use software as a tool?
• What is the proposed (or existing) solution?

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:

• Solutions based on mobile devices, coupled with cloud-based APIs often require features that reflect the underlying architecture. For example, “syncing” a mobile device via a cloud-based API.
• Solutions based on a mixture of different devices must take into account the unique characteristics of each device that may enable or constrain certain features. For example, the small screen size of mobile devices may require additional features to pan and zoom the display and the lack of a GPS feature on most laptops will make location tracking impractical. 
• Teams implementing packaged solutions need to understand the major components and APIs of the package before they can configure it to satisfy the stakeholder’s business needs.
• With the growing emphasis on interaction and visual design it has become more important to identify the physical characteristics of each user interface during requirements discovery.

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:

• store and retrieve data;
• interact with users;
• interact with external systems and devices; and
• enforce business rules.

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:

• the target customer for the solution;
• the customer’s most important operational or strategic need;
• the key benefit or compelling reason to acquire the solution; and
• what differentiates the solution from competing solutions or practices.

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.