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.
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. 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.
The “Business" section of the canvas consists of four elements.
This element 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.
Subject Matter Experts
This element identifies the subject matter experts (SMEs) who possess expert knowledge of either a business area, or some aspect of a proposed (or existing) solution.
This element 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 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 and describes the goals of the stakeholders. However, stakeholders often find it difficult to clearly articulate their goals. Many find it it easier to describe the activities they perform.
Activities can provide an indirect way of identifying goals, if the desired outcome of the activity is clearly stated. For example the activity "Accept reservation for rental cars" can be reworded as the outcome "Reservation for rental cars accepted". Stakeholders should then be able to confirm that this outcome is important and represents one of the goals of their business area.
If the business area is large and includes many activities, it can be useful to group activities into business capabilities. These describes a business area’s ability to repeatedly perform a group of related activities.
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.
This element identifies strategic needs that often emerge from a SWOT analysis. Strategic needs describe the need to:
- 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.
This element identifies and describes the information required to support stakeholder goals.
This element identifies and describes the rules that must be enforced in support of stakeholder goals.
The “Solution" section of the canvas consists of four elements.
This element 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 element 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.
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.
This element identifies and describes the most important user interfaces and APIs provided by the solution.
This element identifies and describes the most important components of the solution.