By search term

By author
  • Methods

The Context-Canvas


The description of complex systems becomes a challenge with the increasing progress of digital transformation, particularly in the development of new machine systems. To equip machines for the future, a variety of aspects need to be considered already in the requirements analysis. The conventional methods, practiced for centuries (i.e. German mechanical engineering development guidelines - VDI 2221), provide lists of requirements and design models that do not contain the level of relevance needed today for usability and software. Requirements analysis and system design is therefore subject to a methodological weakness, which is practiced mainly – out of habit – in small and medium enterprises. Engineers and developers are often unaware of the complexity and scope of future systems. This leads to the necessity of various iterations at the beginning of the REprocess to find a balance between goals, complexity of the system and given constraints. During this iterative process, the customer loses time and money.

In the start-up phase, where complex relationships, such as business models, are examined, mapping tools have been proven to be effective. Throughout several years they have been used successfully to map whole business models, important contextual elements and interactions between them in order to achieve a quick assessment and comparison. This way, with relatively little effort, a statement can be made in advance as to which concept should be further investigated. The detailed concept is documented in the business plan. There are various similarities between a business plan and a system-specification. Before creating a systemspecification all factors that influence the target system should be considered.

In order to provide a quick assessment of the development project – including goals, context complexity and constraints – prior to a time- and cost-intensive specification, the Context-Canvas was developed. This simple tool provides the possibility to outline and evaluate different objectives and their effect on the final system context. The Context-Canvas is based on elements of the classic (software-based) RE-process and was combined with elements of classic German mechanical engineering methodology. In particular, stakeholders untrained in methodology can follow the simple structure, providing the basis for a successful and effective RE-project. As a consequence of the effective use of Context-Canvas, the Requirements Engineer is less distracted by discussions and conflicts between stakeholders and can instead focus on the requirements. The result is a clear increase of quality of the system-specification in the time available.

Who is the Context-Canvas for?

Generally, the Context-Canvas can be used by any person with a major interest in, or responsibility for, an effective and efficient requirements definition phase of a complex system development project. Although this visual approach was found to be very helpful working with mechanical engineers on machine integrated IT-systems, it can also be applied to pure IT-Systems as well. Examples of users are

  • Requirement Engineers – Support with CC: Complete overview of system context, requirements sources and clarification of project characteristics.

  • Sales People – Support with CC: Quick overview and documentation of customers (sometimes hidden) intentions and project extent for improving proposal quality.

  • Developers – Support with CC: Overview of project goals and interdisciplinary complexity as well as basis for clear communication with experts from other fields.

  • Project Leaders – Support with CC: Overview of Problem-Solutions-Fit, Evaluation TimeBudget-Functionality-Balance and clarification of needed project team members

How will the Context-Canvas improve the REprocess?

In software development, the context of a system is traditionally taken into account during requirements elicitation. Initially the system will be identified and separated from its surroundings, that is, its context. Subsequently, the resulting context requirements can be determined.

In mechanical engineering, the requirements elicitation is often performed using spreadsheets and feature lists. The visual structure is habit and necessity at the same time. Especially at the beginning of development projects, concepts, objectives and context elements are not obvious to all stakeholders. This ambiguity often leads to extensive discussion at the beginning of a project. Internal discussions often lead to frustration among the project participants and to additional costs during the specification project.

The Context Canvas provides a new approach as a base document for the context elements of mechanical system development. The need to define precise and unambiguous terms for the core elements of the system context promotes understanding about the project goal. The simple visual design and systematic approach allows users with different backgrounds and education levels to quickly get an overview of the intended system. It allows at an early stage estimating the right balance between time, budget and the targeted solution, promoting realistic project planning. Therefore, more emphasis can be put on the quality of requirements and not the solving of conflicts about concepts and communication.

What does the Context-Canvas look like?

Based on approaches to visualize the system context and known categories as sources for system requirements, the Context-Canvas was designed to summarize core information on one page.

Figure 1: Derivation of Context-Canvas layout and levels

The Context-Canvas is divided into three areas and eleven modules (see Figure 1). Each section contains a different level of abstraction, therefore it is advisable to first edit the cells according to the recommended order. In order to develop the modular content, key questions for each module need to be answered concisely and accurately in a few words. For the sake of clarity, full sentences should be avoided. In particular, in collaboration with several stakeholders, it is important to choose clear and precise words.

Initially, major project intentions will be described and clarified in the problem/solution-fit area.


The starting point in the Context Canvas is the problem definition. In this step, the central problem is defined and an initial delineation is carried out. In particular, for the goals defined subsequently, it is advantageous to have a clearly described problem. For this reason, there is not only the main problem to define but two other important problems that need to be solved. The key questions are:

  • What are the three biggest problems?
  • What annoys you the most?
  • What is most time consuming/expensive?
  • What problem do you want to solve most urgently?

Derived from the main issue and the other two, a main goal, as well as two further goals, can now be defined. They should be formulated SMART and defined with characterizing keywords. Solutionlimiting formulations should be avoided. For abstract and unclear problems, it is also possible to begin in this module. In that case, possible incorrect or unspecific definitions of goals due to unclear problems need to be considered and should be avoided. Exemplary key questions are:

  • What are the three most important goals you want to reach?
  • What benefits do you want to achieve?
  • Which goal is the main objective to be achieved?
  • Which goal do you want to achieve through the solution of which problem?

During this step, a solution approach should be defined in one compact sentence. Here we can already examine whether the existing idea solves the main problem and achieves the main goal.
Exemplary key questions are:

  • What is the idea you have to solve existing problems and achieve intended goals?
  • What benefits do you expect from this approach?
  • Why do you choose this approach?
  • Are there arguments against this approach?

This module is supposed to give compact information about the two most important project related constraints – deadline(s) and available budget.

In the following section, the system context to the selected approach is systematically investigated.


Stakeholders are an important source for requirements. All persons or organizations that affect the requirements for the solution should be stated.
Exemplary search fields are:

  • Management
  • Project team
  • Departments (marketing, sales, R&D, quality, logistics, etc.)
  • Partners (suppliers, distribution partners, etc.)
  • Service providers (designers, developers, consultants)
  • Customers
  • Users

Exemplary search fields for hardware systems with impact on the requirements for the solution are:

  • Machines
  • Computers/servers/mobile devices
  • Control units
  • Mechanical components
  • Energy supplies
  • Material flows

Exemplary search fields for software systems with impact on the requirements for the solution are:

  • Programmable Logic Controllers (PLCs)
  • Manufacturing Execution Systems (MES)
  • Process Planning Systems (PPS)
  • Computer Aided Design (CAD)
  • Enterprise Resource Planning (ERP)
  • Cloud Solutions
  • IT tools (software, apps, etc.)

Exemplary search fields for documents with impact on the requirements for the solution are:

  • Technical documentation (Product descriptions, requirements documents, instructions)
  • Legal norms, standards, guidelines
  • Security policies
  • Internal company policies (operating agreement)

This module includes all processes the future system (depending on the chosen solution approach) needs to interact with or will be influenced by. Processes can be manual as well as automated. Exemplary search fields for processes with an impact on the requirements for the solution are:

  • Use processes
  • Maintenance/repair/administration
  • Commissioning/assembly
  • Recycling
  • Logistics
  • Production processes
  • Sales processes
  • Business processes

After the most important requirements sources have been summarized from the system context, the latter will be outlined in the next section with simplified context models. As the new system is to be integrated into the existing structure this will help communication and the identification of interface requirements.

Partners in interaction

In this module a simplified sketch is provided to clarify which people and possibly systems interact with the new system. Interaction partners are a subset of the stakeholders and software systems. Depending on requirements and time, the sketch can be refined by the addition of the interaction type (e.g. communications, mass transfer, energy exchange). Key questions for creating the sketch are:

  • Which stakeholders and systems interact with the new solution and with each other? (e.g. users, service technicians)
  • How is the interaction characterized? (e.g. communication, heat transfer, energy exchange)
Structure of interaction

In this module a simplified sketch is provided for structural connection. Accordingly, mainly those hardware structures mentioned in the system context and their connections (e.g. network, internet, fixed or releasable mechanical connection) represent the new system. It will thus be clear whether the new system is an additional element to existing systems or will work independently. Key questions for creating the sketch are:

  • Which systems (primarily hardware) will be structurally connected to the solution?
  • How shall the solution be integrated to the existing hardware systems? (e.g. networking, mechanical connection to the machine)

How to use it: Best-Practice

The use is illustrated by the following example (Figure 2) in which a conventional braiding machine (by Koerting Nachf. Wilhelm Steeger GmbH & Co. KG) is being modernized ("retro-fitted") for an Industrie 4.0-showcase at ITMA 2015 in Milano, Italy.

Figure 2: Exemplary use of the context canvas applied to a braiding machine automation

First, the problems to be solved (1) are clearly described. Existing problems can be determined for example by a professional situation analysis. The prioritized problems are high downtime, the high set-up costs and the inaccurate data collection.

Based on the main problem, the main objective (2) of the development project can be derived (here: downtime reduction by 50%). The same applies to the other two objectives. In this way, general but often used words such as "optimize”, “faster”, “better”, “more efficient" are easier to specify, especially for inexperienced stakeholders.

Based on the goal definition, a solution approach needs to be developed (3). Often, solution approaches are already given by the environment (existing expertise, market, initial ideas, etc.). In other cases, ideas can be generated by existing creativity techniques e.g. Method 365. In this example, an automation approach is pursued.

The Problem-Solution-Fit Level will be completed with the determination of the main project-related constraints (4). Depending on the approach, different budgets (here: 15.000 €) or time objectives (Deadline/Duration: 8th November /6 months) are given.

Depending on the pursued approach, the context of the intended system is examined. In this example, the category stakeholders (5) includes the operator, production manager (head of production), development teams and external organizations.

The hardware environment (6) is characterized by the braiding machine, the carriers and the bobbins supplied by Steeger. Furthermore, the high voltage power connection is considered in this category.
The given software environment (7) is characterized by the built-in braiding machine control software from Schneider Electric.

Important documents (8) that need to be considered are the user manual of the Steeger braiding machine, technical data sheets/specifications of the carrier, existing documentation of machine downtime and (exhibition) safety instructions or regulations.

In the next category, processes (9) are listed that affect the new system. These include logistics and transportation processes, carrier change, bobbin change, data collection, maintenance, installation and production.

Based on the defined system context, the last two steps focus on sketches (superficial models) of the system context, in order to give different perspectives on the system and a better understanding of its boundaries. From the perspective of partners in interaction (10), the system has relationships with selected stakeholders (see 5) and software systems (see 7). From the perspective of the structure of interactions (11), the structural links, relationships and network peripheral systems are sketched. The previously determined hardware systems (see 6) can be used as a source.

With the compact overview the first investigations for completeness, scope and plausibility of the system development can be performed. Examples of control questions are:

  • Can responsible stakeholders agree on a major problem/goal?
  • Will the problems be solved by the defined goals?
  • Can the solution approach meet the goals?
  • Can all identified stakeholders be associated with a person/contact?
  • As part of which processes do individual stakeholders interact with the system?
  • Are all the involved surrounding (hard- and software-) systems shown in the sketches?
  • Are deadline and budget targets still realistic (stakeholder availability considered)?

After preliminary examination, the ContextCanvas can be optionally used to investigate effects of variations of individual modules. For instance, the change of a goal may have an effect on the preferred approach (see Figure 3). The new approach might have a different system context (for example, more IT integration) and might therefore need a larger development effort, which can jeopardize the budget and time constraints. Major variations should be documented in separate Canvases for easier evaluation purposes. Minor variations can be documented in the same canvas as product options.

Figure 3: Effects of a goal variation on the system context [red marks additional aspects to be considered due to the variation]

Subsequently, the different variants can be quickly evaluated. Evaluation criteria should be defined by the project managers according to priorities. Exemplary search fields for criteria can be:

  • Timetable/Deadline
  • Budget
  • Functions
  • Stakeholder access/availability
  • Complexity
  • Business Strategy

With selection of the preferred variant of system development, the responsible stakeholders have common knowledge of the intended system and can pursue concrete steps. The project team members for the specification phase can be quickly informed using the stakeholder list and informed about the project goal.

In case of the ITMA project, the initial idea was sketched by the project owner (one person) within one hour. Based on the document, the idea (and its Context-Canvas) were discussed and specified in a two-hour meeting with initially identified stakeholders (core project team). The decision for the automation approach was followed by the detailed elaboration of the system-specification and project plan. The final system was exhibited on 8th of November 2015 at ITMA Fair in Milano as shown in Figure 4.

Figure 4: Final braiding machine with automated carrier exchange module [ACEM] at ITMA 2015.

So far, the Context-Canvas has been tested successfully for internal as well as for external system development projects where communication among interdisciplinary development teams or stakeholders were critical for success. Stakeholder feedback focused primarily on the clear and compact overview of the project’s context including commercial purposes as well as necessary expertise. This way, marketing representatives were supported in the understanding of technical issues and accordingly developers received the main commercial purposes/values of their developing efforts. Conflicts between stakeholders were reduced and factual discussions were carried out focusing on core elements.

Secondly, new stakeholders were quickly integrated due to the compact and visual project outline. Especially in cooperation with external development partners, the clarification of the main interfaces and responsibilities (e.g. who delivers which machine part) at this early phase of the project were found to be very helpful.

Furthermore, in projects were the Context-Canvas was applied, scope changes throughout the project could be easily referenced to initial goals and time delays/additional costs could be explained.

The Context-Canvas has also been tested successfully in sales to improve the elicitation of customer needs. The Context-Canvas was filled out in an average of 90 min. interview between salesman and customer. Due to the systematic “workflow”, it guided salesman and customer through important project aspects and identified unspecific areas (fields of discussion and risk). Based on the document, communication between salesman and development co-workers was clear and proposals increased in suitability (with a consequent higher success rate of proposals).

However, despite its value in the beginning of a development project, the Context-Canvas should always be complemented with a proper specification. Therefore, if the digital Context-Canvas is used, the elements can be integrated into known RE-tools, providing a first structure with core elements of the specification document, or be sent to external stakeholders such as RE-consultants or development partners.

What about other canvases?

Canvases have been known and proven their benefits in other fields already, such as Osterwalder’s Business Model Canvas for Business Modelling. Besides other existing canvases (for various fields and purposes) two existing canvases need to be discussed regarding their different purposes in RE compared to the Context-Canvas – Roman Pichler’s “Product Canvas” and Maik Pfingstens “System Footprint 4.0”.

The Product Canvas is mainly used for visualization of development sprints and is a dynamically used tool throughout the development project. Especially in the project initiation phase, additional canvases are provided. However, a summary of the most important context aspects is not intended to be visualized on one page. Furthermore, it appears to be focusing on product development and less on summarizing the context of complex integrated systems with various interfaces.

Maik Pfingsten’s System Footprint 4.0 is used to give a compact overview on the key aspects of a system specification, i.e. similar to the Context-Canvas. Applied to development projects with focus on integrated manufacturing systems, however, the usability for untrained stakeholders has been found to be very challenging as a clear workflow is not presented. In addition, several aspects have been found to be necessary in order to achieve a complete understanding of the system context for interdisciplinary solutions, before elements such as use cases or features can be defined. A detailed focus on stakeholders as well as the detailed examination of processes has been found to be missing, especially when working with stakeholders of the manufacturing sector (e.g. supplier, producer, machine setter, mechanical engineer).

As a result, the above-mentioned canvases have their value and benefits depending on the specific application and development process followed by the user.


The description of complex systems becomes a challenge with the increasing progress of digital transformation, particularly in the development of new machine systems. Engineers and developers are often unaware of the complexity and scope of future systems. This leads to a need for various iterations at the beginning of the RE-process to find a balance between goals, complexity of the system and given constraints. During this iterative process, the customer loses time and money.

In order to provide a quick assessment on the development project including goals, context complexity and constraints, prior to a time- and cost-intensive specification, the Context-Canvas was developed. It supports requirements engineers, sales people, project managers and developers with a compact, visual mapping tool to perform context synthesis and evaluation of development projects for integrated machine systems on one page, as presented in this article. Future activities might include the optimization and optionally the specialization of the canvas-model for individual industry sectors. Furthermore, workshops of Context-Canvas users shall be supported by a respective digital application.

Author's profile
Related Articles
Innovation Arena

An agile and collaborative prioritization technique

Read Article
Think Like a Scientist

Using Hypothesis Testing and Metrics to Drive Requirements Elicitation

Read Article
A key technique

Delegation of requirement verification. A key technique for more mature requirements management.

Read Article