Writing embedded software without having a firm set of requirements for the project is like starting to build a new house without a clear idea of how many rooms it should have, where the windows and doors should be, and where the plumbing and wiring should run.

While you can totally start writing working code and hammer out a functioning prototype in no time, the reality is that these prototypes are usually put into production without having had time to fully consider the life cycle of the product, or those who will have to keep patching up the firmware over the coming years to add features that the original firmware code was never designed for.

After completing the requirements that the product has to fulfill, these are then translated into an architecture (the overall structure of the application), which is then translated into a design (what will be implemented). The design is then translated into the actual code.

The advantages of this approach are that not only do you need to answer a lot of questions about why something is done a particular way, it also generates a lot of documentation, which can then be used practically as is once the project is completed.

Additionally, in an embedded project having the full set of requirements can save a lot of money and time as it allows one to pick the right MCU or SoC for the project without having to spend more money on a more powerful than needed chip 'just in case'. It also prevents embarrassing mid-project discoveries where a feature which had been 'forgotten' about suddenly necessitates a change in the hardware design.