DO-178B Table A-1 objective #2 requires that transition criteria, relationships, and sequencing is defined for the various processes. Simply put, you need to think about not only each of the individual processes (writing requirements, implementing code, verifying, performing CM, etc) but how they relate to each other.
To some extent this is a no-brainer: first you write requirements, then you write code, then you verify, then you CM the whole thing at release time. To some extent these tasks will probably overlap: you’ll probably start coding before all the requirements are written, and you’ll probably start verifying before you’re completely done coding. The important thing with objective #2 is that you define when these processes will happen, with respect to each other.
This is also as good a place as any to start with the reminder that these tasks should be performed roughly in order. You don’t want to be coding the whole application first, then backward-engineering the requirements to match what you coded. It’s just not good practice, and it’ll lead to headaches in the end. The best projects I’ve ever worked on in my avionics career have been the ones where requirements and design were rigorously documented prior to coding. It makes the coding task easy and definable, and it leaves you with a easily-certifiable product when you get done.
Let’s end this with an analogy. I think of process as something akin to the protected areas of my favorite Unix box. In normal user mode, I can’t make changes to those areas or settings, nor should I. At times, though, it becomes necessary to make changes. At those times I make judicious use of the sudo command and perform the changes that I need. Then I go back to working in user mode, and back to working under the rules and permissions that I’ve set up.
Processes work the same way. Yes, there are ways you can go and change them, and times when it is appropriate to do so. But other than those times, work in user mode and follow the processes.
