Designing in simple steps

I like reading books about military history. Recently, I have read “One bullet away” by Nathaniel Fick. The author describes the training he had to complete in order to become an officer in US Marine Corps. One of the things he described was how the young officers are made to write lots of written orders in five-paragraph format called SMEAC. It stands for situation, mission, execution, administration and logistics, command and signal. The point of all this writing was to make sure that all those issues are remembered extremely well and become part of the thought process of the trained person.

I think that my line of work, writing computer software, can learn a lot from the military. So today, for my own use, I created a similar format I will follow when given a task to design a software component. The elements are:

1. Mission statement – what should the component do? It should contain any functional and non-functional requirements.
2. Environment – where should it run?
3. Restrictions – what are the known restrictions on the component? Those usually are existing legacy systems and interfaces.
4. Assumptions – for me, this means stating clearly what are the things I don’t know when creating the design and how I deal with the resulting risks.
5. Description of the component – most designs I see seem to only have this part and quite often it leads to lots of wasted effort.

Just as the officer on a battlefield, I often have no time to write formal documents. But I am posting this very simple process description on this blog so that I remember about it. I hope that even considering those things in my mind before starting work will be a good thing.