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 goal is to capture the high-level, long-term vision on a more abstract level (e.g. via so-called epics and themes), and then provide a detailed and precise work definition only for the next upcoming sprint (sprint backlog - created for each sprint; typical sprint duration is 3-4 weeks). This way, the agile approach ensures that no waste is created by investing in detailed, long-term requirements which are likely to change over time anyway.

Most AIoT projects or product developments will need to combine both perspectives. For the standard software part - and probably also the AI part - agile planning will work well. For those parts involving hardware and telecommunications infrastructure - as well as any part with complex dependencies - a more planning-centric approach will most likely be required. Enterprise sourcing processes will add their part to limit a pure agile approach.

Nevertheless, a good starting point will be the agile best practices in this area, which we will discuss first. Next, a short look at more traditional requirements will be taken, before looking at how to derive an AIoT system design from all of this. This will be completed by a discussion of the entire cycle from requirements and design to implementation and validation. Finally, we will discuss the dependencies between AIoT system design and co-creation/sourcing.

The Agile Approach

The agile pendant to requirements management is the backlog. The product backlog is a list of all the work items required to build and improve the product. It represents the single source of work definitions accepted by the scrum teams. For each upcoming sprint and each sprint team, a sprint backlog is created, which defines the work to be done by the team in the next sprint. Product backlog items can have different granularities, as will be discussed in the following. Sprint backlog items must be implementable in a single sprint. Story maps often serve as the visualization of the product backlog, as will be described in the following.

Story Maps

Story maps are a useful tool to manage the high-level requirements and structure of a product. Depending on the school of thought, they are either described as a visualization of a product backlog or as a customer journey-centric way of structuring the body of work on the highest level. Especially in the early stages of product creation, story mapping is used as a technique for product discovery, helping to outline the structure of a new product (or a complex, new feature for an existing product). To achieve a higher level of abstraction and orientation than a linear backlog, story maps typically arrange lower-level features in higher-level, functional groups.

Typical units of work in story maps include so-called themes, epics, features and user stories. For the purpose of simplicity, the AIoT Playbook is focusing on epics, features and user stories:

Epics are a high-level body of work, typically representing 2-6 months in duration. An epic can span multiple releases, and more than one team. Epics often are aligned with senior management. Epics contain features.
Features describe a specific functionality of the product. They are smaller than epics and typically contained within a specific release and assigned to a specific team (see => feature team). Features are typically managed by product owners. Features contain user stories.
User stories are the smallest definition of an increment, usually less than a week. They are bound to a specific sprint.