Improving quality with well-written requirements

I discussed with a colleague about how to improve specifications and we agreed that one of the actions that would yield quality improvements with very little investment was to educate people in our organisation on how to write good requirements.
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:

• The Story of the Paperclip: Writing Good Functional Requirements from StartupCTO
• Writing Good Requirements – The Big Ten Rules from Tyner Blain
• Writing good requirements is a lot like writing good code by Jim Heumann, IBM
• Writing Good Requirements (A Requirements Working Group Information Report)
• SMART Requirements by Mike Mannion and Barry Keepence

"Start with a Walking Skeleton"

I try to explain to my students that they should start with structure before programming any features. Get the OS to run with some reasonable tasks, exchange some information/messages/... between sub-systems or processes, etc.
There seems to be a proper term for this: Start with a Walking Skeleton. Apparently the term originates with Alistair Cockburn. It is often used in conjunction with the Incremental Architecture pattern.
I feel rather stupid of not knowing what others had done before, but at least I know of the concepts...

It says that this is a useful strategy for large systems. I think it is quite useful for small systems as well, especially if you are not very familiar with the features to be developed. A walking skeleton allows you to try different things in a running platform and with decent version control you can always reverse to something that is running, even if it has little customer value. And the effort of making the skeleton work is never wasted.