Following on my first article, I’d like to give some additional, no-nonsense advice on best practices for Safety Critical Processes. I think sometimes we get so entrenched in the details of our current projects, we forget to take a breath, look down at our projects from above, and really ask, “Are we focusing on the right things for success?”
For example, with every project we run for our customers, we perform a Lesson Learned Report, as I’m sure many of those reading this have. How many of us have then used these reports and changed our processes or focuses and incorporated those lessons learned into other projects and the processes at our organization in general? I hope by reading this, people might take a breath, collect their thoughts, and look introspectively on how we are running our projects.
Addressing the Biggest Cost Impact
In the last post, I asked rhetorically “How do I save money on my project?” I answered Requirements, Requirements, Requirements, Requirements. What’s ironic in most engineering projects is that usually the least amount of money (and time, effort, attention, energy) is focused on the requirements phase of any project, yet the requirements for any project are the largest drivers of cost impact and risk to a project. I’d like to repeat that for added emphasis:
The requirements capture phase of any project usually gets the least attention, energy, money, and effort of any project phase yet is the biggest driver of risk in terms of cost and schedule.
Requirements Aren’t Going Away
There are huge misconceptions that Model-Based Systems Engineering (MBSE) and Agile/Scrum methodologies (both of which I am an avid supporter and user), mean that we can abandon the focus on having a good requirement capture effort. In fact, requirements are woven into the SysML standard along with all the tools associated with requirements capture like allocation, tracing, etc.
Practical Example of Wasted Time
Early in my career, I supported a lot of avionics programs in all lifecycles of development, but like most new grads, my first years were spent performing verification and validation. As we all know, requirements are the input of verification. I received a requirement written, “The radio shall never transmit when the following are true…”. After writing a thorough test to prove this requirement, my late friend and peer reviewer, James Bettie, rejected my test as not meeting the requirement. His words: ”you didn’t prove never.” The only way to prove a “never” requirement is to test “forever”. After several rounds, back and forth, meetings with project managers about the right way to test a “never” requirement, etc., etc., we wasted hundreds of man-hours on this requirement that was wrong and should have been deleted or reworded and caught much, much earlier in the process. In fact, it should never have been written. I’ve never seen software do something that it wasn’t programmed to do.
So What Makes Requirements Good
First, requirements should be properly leveled. At the highest level, requirements are more abstract and define the system or product. Each successive level further refines and defines what we are attempting to build. A progression might start at Product Requirements, be followed by System Requirements, then Software Requirements and finally Design Requirements.
It is important not to intermix requirements such that software requirements are in the system requirements. There is an easy method to prevent this from happening: when you start your requirements, draw a box around the “thing” you are defining, draw arrows into the box on the left, draw arrows out of the box on the right. Next for each arrow, label the input or output appropriately, these are now your interfaces. Capture these first and foremost into your requirements document. This will be a living section as your product is further refined. Next, begin to define the functionality of what this box does by writing requirements of Outputs in terms of Inputs.
Output in Terms of Inputs
Requirements should specify a behavior or function you are controlling and is absolutely deterministic. This deterministic behavior should be evident on an output and be controlled only by the inputs. For example, “The output GENERATED_RESULT will be true when DEPENDENT_INPUT is greater than or equal to five”. I know this is overly simple, but I think you get the point.
Use Specific Names of I/O
Remember the interfaces you named previously, try to use only those inputs and outputs. Don’t create new variables, signals, or intermediate values within your requirements. Use only the I/O defined in your interfaces. Keep the naming consistent, the spelling exact, and match 100% with those interfaces.
Avoid Bad Words
Bad words in requirements are “never”, “always”, “sometimes”, “may”. These are ambiguous. Your requirements should only state exactly what you want your product to do.
States are OK
It ok to create states. In fact, use states to group requirements of like functionality. Make sure the states have specific names, don’t rename a state (i.e. Self-Test versus Self Check) halfway through a specification.
Please use a Shall
The shall has become a standard across all industries as the specifier of a requirement, not much more about that.
We really have just brushed the surface, but lots of other qualities such as identifiable, traceable, allocation, derivable, testable, etc. should all be taken into consideration.
Novel Engineering, Inc.’s core competencies in engineering applications for aerospace, rail and transportation has evolved around the company’s expert-level working knowledge of following Safety Critical Processes such as DO-178, DO-254, ED-12, and CENELEC. As the largest and premier engineering service company of its kind on the Space Coast, Novel supports clients across the US in the engineering disciplines of Systems, Software and Electronics.