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.