AIoT Business Viewpoint: Difference between revisions

No edit summary
No edit summary
Line 8: Line 8:
rect 706 1337 2440 1715 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 706 1337 2440 1715 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 2468 55 3122 1711 [[AIoT_Product_Viewpoint|Product Viewpoint]]
rect 2468 55 3122 1711 [[AIoT_Product_Viewpoint|Product Viewpoint]]
rect -4 1041 146 1191 [[Product_Architecture|Product Architecture]]
rect 1 1041 146 1191 [[Product_Architecture|Product Architecture]]


desc none
desc none

Revision as of 06:52, 5 July 2021

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Business Viewpoint

Business Viewpoint

The Business Viewpoint of the AIoT Product Architecture is building on the different artifacts created for the Business Model. In order to refine and validate this information, site surveys and stakeholder interviews should be performed. The definition of personas helps ensuring all key stakeholder perspectives are taken into consideration. The high-level vision and requirements are then captured as epics. From there, a story map is created to capture all high-level requirements. This is the main interface between the Business Viewpoint and the Product Viewpoint.

Business Model


Business Model

ACME:Vac Business Model Canvas

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.

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