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.

Books on programming embedded systems

I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.

A quick search on Amazon shows some which could be relevant:

• Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
• An Embedded Software Primer by David E. Simon
• Embedded C by Michael J Pont
• Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao

Especially the latter sounds interesting since I like the software architecture book from the same author.

I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:

• Introduction to C, since embedded systems are programmed in C. Period....
  I like K&R, but you can choose any book that suits the bill.
• Good coding practices in C, for example MISRA C rules.
  Read some example of MISRA C-rules here, here and here.
• RTOS basics, since this is what is used on most embedded systems.
  Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability.
• Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
• Development environments, and compilers for embedded development
  My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial.
• Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
  You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited.
• Debugging - Too much to cover for this blog post. This is the real dark arts...
• Architecture of embedded systems
  Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?