Product / Solution Design: Difference between revisions

Line 18: Line 18:


= Requirements & Design =
= Requirements & Design =
What is the next step after agreeing on the first iteration of the business model and securing funding for execution? In the traditional waterfall world, the answer is relatively clear: Documentation of requirements with a high level of detail and accuracy, as the stable foundation for planning, design and execution. However, in the software world we have learned that getting stable, long-term requirements is often difficult. Consequently, traditional requirements management often has a bad name in the agile community. Instead, agile best practices are focusing on the backlog as the central means of managing requirements and work items. The Product Backlog is ''"an emergent, ordered list of what is needed to improve the product"''. The sprint backlog then takes items from the product backlog and provides an actionable plan for delivering the next increment as the outcome of the next sprint (typically 3-4 weeks).
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it's not necessary to start a project with a lengthy, upfront effort to document all requirements.


The design of the smart, connected product or solution will have a significant impact on user acceptance and business success. It is important to notice that design is a living thing, and will evolve over time. Especially for products, the software and AI-enabled parts are likely to undergo constant change, based on customer feedback and product performance. However, it is important to notice that certain design decisions made in the early stages of product development will be difficult to be changed. This includes fundamental system architecture decisions including software and AI, as well as everything related to hardware - be it the IT-side of hardware, the mechatronical side, or product body or chassis.
The design of the smart, connected product or solution will have a significant impact on user acceptance and business success. It is important to notice that design is a living thing, and will evolve over time. Especially for products, the software and AI-enabled parts are likely to undergo constant change, based on customer feedback and product performance. However, it is important to notice that certain design decisions made in the early stages of product development will be difficult to be changed. This includes fundamental system architecture decisions including software and AI, as well as everything related to hardware - be it the IT-side of hardware, the mechatronical side, or product body or chassis.

Revision as of 19:50, 9 August 2021

More...More...More...More...More...More...More...0.2-Design.png


Requirements & Design

What is the next step after agreeing on the first iteration of the business model and securing funding for execution? In the traditional waterfall world, the answer is relatively clear: Documentation of requirements with a high level of detail and accuracy, as the stable foundation for planning, design and execution. However, in the software world we have learned that getting stable, long-term requirements is often difficult. Consequently, traditional requirements management often has a bad name in the agile community. Instead, agile best practices are focusing on the backlog as the central means of managing requirements and work items. The Product Backlog is "an emergent, ordered list of what is needed to improve the product". The sprint backlog then takes items from the product backlog and provides an actionable plan for delivering the next increment as the outcome of the next sprint (typically 3-4 weeks).

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it's not necessary to start a project with a lengthy, upfront effort to document all requirements.

The design of the smart, connected product or solution will have a significant impact on user acceptance and business success. It is important to notice that design is a living thing, and will evolve over time. Especially for products, the software and AI-enabled parts are likely to undergo constant change, based on customer feedback and product performance. However, it is important to notice that certain design decisions made in the early stages of product development will be difficult to be changed. This includes fundamental system architecture decisions including software and AI, as well as everything related to hardware - be it the IT-side of hardware, the mechatronical side, or product body or chassis.

Due to the complexity of most AIoT products and solutions, the design will need to capture many different perspectives. Consequently, the AIoT Playbook defines a number of design viewpoints, which will be introduced in the following.

Of course the design needs to be closely aligned with the requirements. In traditional, often waterfall-oriented projects, a clear differentiation between requirments and design is made. However, agile best practices have led to an approach which merges requirements and design, at least to a certain extend: agile user stories are a mixture of requirements and feature

The Agile Approach

Story Maps

Story Map Overview

Example: AIoT Story Map & User Stories

Story Map details

AIoT System Design

AIoT Design Viewpoints

Product / Solution Design - Overview

AIoT Viewpoint Details

Click HERE for more details on AIoT product / solution design viewpoints.

AIoT Design Viewpoints - Overview

From requirements and design to implementation and validation

From design to implementation and validation

Design vs co-creation & sourcing

Story Map vs Sourcing Perspective