Embedded — system perspective
Let me briefly explain what is a system approach. It defines #design as black boxes with special functionalities connected with some interfaces. Robot from our example would be described as one block whose main task would be to clean the floor and which is connected to a smartphone with a wifi interface.
To describe in detail what are the tasks to do, constraints need to be defined. The most popular approaches rely on:
- use-cases & use stories — in our example this could be cleaning one floor or only a single room,
- requirements — we require from device to be able to suck the dirt, detect walls and move through some area.
The first one is great when contacting clients/investors etc, second when contacting engineers.
Last but not least is the architecture of the system which could describe:
- physical elements of the system like processor, sensors & actuators, housing
- logical components which cover functions like cleaning management, navigation, and remote control.
The system approach is sometimes undervalued both by management and developers as it seems to be drawing boxes or writing down obvious things. However, I think this is an essential link between customers and implementation.