Embedded systems nerd. Became a Systems engineer out of desperation because the ad-hoc processes don't work. Now, I do the whole documentation/design process, which forces one to think thru the design in the context of the system.
One must keep the scale of the project in mind. A requirements spec of 2..3 pages and 20 simple requirement is usually sufficient (mainly stating the obvious). A functional spec that describes the *what* of the system gets the client focused.
Also, the requirements and functional spec are usually one document. Get it signed by the shareholders. Resistence to signing is a sign something is not ready, or a client (boss) doesn't want the project in the first place.
The design document - the *how* - spend time on this.
I did a project a year ago; a data acquisition system with really tight data rates and timings. The paper process took three months. The actual HW/FW/testing took another three months. While we had a few issues, they were minor and solved quickly. This included all new hardware. We should have spent a week on the hardware review instead of the day or two.
One thing I insisted on was we took a big sheet of paper (3x8 ft) and drew, with pencil, the *entire* system on it. Found many little issues that would have cost a lot of time to fix.
Do the process - it works, reduces risk, and cuts way down on the deathmarch.