Having a design document is essential to any well-considered system, especially one that has to be maintained. However, it is NOT the starting point. Simon Sinek managed to summarize decades of experience into three words "Start with Why". Why are you doing this, or, better, what benefits will stakeholders get from whatever it is you are proposing. And no, that's not a Functional Specification. Start with the objectives, as in the template here, but before you start to design your solution, define what it is your stakeholders will gain from the system. By the way, don't think this means a waterfall, define enough that you can make progress with an acceptable level of risk in case you got this wrong. Now define what the system must do in order to deliver what the stakeholders need. That is the Functional Specification (or in more modern terms the System Requirements Specification). Now define your architecture - the big chunks your system is made of. This is where you first start doing trade-offs. For example, if you want to grill food, you need a source of heat and a place for the food to be cooked. Your design then says that this is a cooktop with electric heating (or whatever best works for you). So you are also doing trade-offs in design. Of course, this whole process will be recursive for any but fairly trivial systems.