In general, nailing down requirements is a very tricky part of engineering.
Having a system/body of knowledge to map requirements to implementation is really important.
Specific to software engineering, this process is best supported with BDD and TDD (in my opinion). BDD gets you 100% coverage of behavior: what the "customer" wants. TDD helps you cover edge cases which improves on robustness (which is the process you are describing above).
Coding before you have behavior (what customer wants) is, in my opinion, a bad idea (product market fit first).
Any type of development approach, ill-relevant of it being coding or visually oriented, is going to be iffy without using best known practices.
Now, if you are doing R&D then I would ignore the above process of BDD/TDD with the understanding that any code/program written would be "thrown out" (not put into production).
Having a system/body of knowledge to map requirements to implementation is really important.
Specific to software engineering, this process is best supported with BDD and TDD (in my opinion). BDD gets you 100% coverage of behavior: what the "customer" wants. TDD helps you cover edge cases which improves on robustness (which is the process you are describing above).
Coding before you have behavior (what customer wants) is, in my opinion, a bad idea (product market fit first).
Any type of development approach, ill-relevant of it being coding or visually oriented, is going to be iffy without using best known practices.
Now, if you are doing R&D then I would ignore the above process of BDD/TDD with the understanding that any code/program written would be "thrown out" (not put into production).