The Requirements Discovery Canvas in a Nutshell
Posted on March 25th, 2015
The original post describing the Requirements Discovery Canvas is quite lengthy and require 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, 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 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.
- 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. The context for exploring stakeholder needs is provided by the “Business" section of the canvas.
- A “Solution" section that 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.
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.
Subject Matter Experts
- 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 expected impact; and
- “anti-stakeholders" such as competitors, who should have restricted access to information about the features of a proposed solution.
This element identifies what is needed to support the stakeholder goals. 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 elements.
- build on or preserve a strength;
- remedy a weakness;
- exploit an opportunity; or
- avoid a threat.
In contrast to strategic needs, operational needs consist of:
- the need to store, retrieve and manipulate information; and
- the need to enforce rules that define, constrain or guide some aspect of a business area.
The “Solution" section of the canvas consists of four elements.
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.
- 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.
Proposed (or Existing) Solution
There are several reasons why a solution independent view of requirements is less practical than in the past:
- Teams supporting existing solutions need to understand the solution’s components, APIs and user interfaces. This provides a necessary baseline for future enhancements.
- In a similar manner, 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.
- 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 technologies must take into account the unique characteristics of each technology 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.
- 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.