How many development teams have heard those few, innocent words uttered from Marketing/Management toward the end of the development phase of a project, only to have their schedule blown out of the water?  The phase of development into which the change is introduced determines the size of the concentric rings that ripple outward:  the later the phase, the greater the impact.  But, I’m not telling you anything that hasn’t been one of the main sources of humor in Dilbert cartoons for 20+ years.  It seems to be a given that changes will occur throughout the development cycle.  This implies that change should be accepted and managed properly to control the impact to schedule, product quality, and safety.

One part of the IEC 61508 standard’s Functional Safety Lifecycle model that helps with this issue is Safety Requirements Management.  Management of safety requirements includes many different activities and artifacts: 

• Correctly identifying requirements
• Recording and controlling identified safety requirements
• Requirements allocation
• Requirements derivation
• Requirements traceability
• Verification and validation of requirements

Let’s take a quick look at the life of a requirement.  During the conception phase of a project, marketing requirements are documented and passed to Engineering and others for further refinement.  These requirements are refined into one or more product requirements, usually in terms of overall product architecture.  One of these product requirements may be to meet certain requirements of a standard (for example, “The product shall comply, as certified by an accredited functional safety assessment organization, with the requirements of the IEC 61508 standard, for use in SIL 3 safety functions.”).  This product requirement may be further refined into a set of derived product requirements which identify all of the project specific requirements to meet this “parent” requirement.  Derived product requirements are further derived into architecture specific design requirements (e.g., “Bit errors occurring in memory used by software programs shall be detected.”).  These architecture design requirements are then allocated to the specific components to which they apply.  A Software Safety Requirements specification, for example, might contain all of the software design requirements that apply to the software component.

In my next blog entry, I will discuss the concepts of requirements allocation and requirements derivation.