AIoT Business Viewpoint: Difference between revisions

Line 20: Line 20:
== Business Model ==
== Business Model ==
[[File:2.2.-bv-VacuumCanvas.png|900px|frameless|center|ACME:Vac Business Model Canvas]]
[[File:2.2.-bv-VacuumCanvas.png|900px|frameless|center|ACME:Vac Business Model Canvas]]
== <span id="SiteSurvey"></span>Site Surveys and Stakeholder Interviews ==
In order to capture and validate requirements, it is common practice for IT projects to perform stakeholder interviews. This should also be done in case of an AIoT product/project.
However, an AIoT project is different in that it also involves physical assets and potentially also very specific sites, e.g. a factory. Requirements can heavily depend on the type of environment the assets are deployed in. Also, usage pattern might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.
While many AIoT solutions might be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case it can make sense to actually build a real kitchen as a test lab, to test usage of the product in a realistic environment. Or, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types, different floor surfaces (wood panel, carpet, etc), and so on.


== <span id="Epics"></span>Epics ==
== <span id="Epics"></span>Epics ==

Revision as of 12:34, 5 July 2021

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Business Viewpoint

Business Viewpoint

The Business Viewpoint of the AIoT Product/Solution Design is building on the different artifacts created for the Business Model. As part of the design process, the business model can be refined, e.g. through additional market research. In particular, the detailed design should include quantitative planning, KPIs and a milestone-based timeline. Finally, an agile story map should be created to capture the high-level requirements. This is the main interface between the Business Viewpoint and the Product Viewpoint.

Business Model

ACME:Vac Business Model Canvas

Epics

It is best practice in the agile community to break down a larger body of work into specific work items by using a hierarchical approach. Depending on the method applied, this hierarchy can include themes, epics, features and user stories.

The AIoT Framework is assuming the following hierarchy:

  • Epic: A high-level work description, usually outlining a particular usage scenario from the perspective of one of multiple personas
  • Feature: A specific feature to support an epic, which is further broken down into user stories
  • User Story: short requirements written from the perspective of an end user

Depending on the complexity of the project and the agile method chosen, this might have to be adapted, e.g. by further adding themes as a way of bundling epics.

When starting to break down the body of work, one should first agree on a set of top-level epics, and ensure that they are consistent, not overlapping, and covering everything that is needed.

Story Map

Example: Initial Story Map