Therefore, software integrity and dependability are fully dependent on properly implementing quality procedures throughout the specification, design, and coding of the software. This activity should be coupled with meticulous testing and validation activities that can find and correct inadequate requirements, bugs, and discrepancies as early as possible in the design, development, and validation process.
In addition to verifying basic functional operation per the requirements covered in the various industry standards on software development, procedures that also evaluate functional robustness, fault tolerances, and – for devices with operator interfaces – user‐friendliness should also be considered. The following procedures are recommended for use in the specification, creation, development, and validation processes of functional safety of critical software.
Table 2.1 Common quality and reliability issues.
| Area of concern | Impacted item | Failure mechanism | Testing method | Inspection technique |
|---|---|---|---|---|
| Moisture sensitivity | Plastic IC packages, optocouplers, other polymer‐based components | Popcorn delamination at higher reflow temperatures. Heat damage of IC packages | Moisture sensitivity testing | Visual inspection |
| J‐STD‐020 | C‐SAM | |||
| Heat damage | All passive components, circuit boards, connectors | Cracking, dielectric breakdown (capacitors), PCB delamination, warping, or via cracking | Heat resistance, MIL‐STD 202G #210F, decomposition temp., time to delamination, package planarity, JESD22‐B108 | Visual inspection, functional verification |
| Poor wetting | All solder joints | Cold joints or weak joints fracture in the use environment | Solderability, J‐STD‐002, J‐STD‐003 | Wetting balance, visual inspection, x‐sectioning, lead pull |
| Solder fatigue | Solder joints, particularly on high‐CTE components | Cracked solder joints | Thermal cycling, JESD22‐A104, HALT, Vibration | Electrical continuity, visual inspection |
| Mechanical shock | Solder joints particularly on higher‐mass components | Solder joint failure during shipping or handling | Shock test | Electrical continuity, visual inspection |
| Sn whiskers | Sn and SnCu‐plated components | Shorting | iNEMI / JEITA procedures | SEM |
| Surface mount process control | Insufficient process window creates poor solder joints | Solder joint failures in the use environment | Precondition and assembly, JEDEC 22‐A113 | X‐ray, X‐section, visual inspection, reliability test |
| Rework process | Poor solder joints, damaged components | Joint failures or cracked vias in the use environment | Rework components followed by reliability testing | X‐ray, X‐section, visual inspection, reliability test |
| Wave solder process | Incomplete hole fill, fillet lifting, damage to the board | Failed through hole, cracked vias, weak joints | Thermal cycle, HALT Vibration | Electrical continuity, visual inspection |
| Electrochemical migration | Board surface with no‐clean paste residue | Shorting between biased traces in a moist environment | Bellcore GR‐78‐CORE, J‐STD‐004 SIR | Visual and resistance after 35 C/85%RH exposure at 50 V |
2.3.4 General Software Requirements
Requirements Verification Assessment for Accuracy and Completeness
Historically, many software discrepancies can be traced back to specification inadequacies, such as inconsistent, incomplete, imprecise, or vague requirements. Therefore, the first step in any functionality/software validation effort is for the responsible software design organization to perform an analytical review with the specifying organization. The review facilitates an understanding of the requirements, ensures accurate requirements communication, weeds out obvious discrepancies before they are incorporated into the code design, and determines and documents the readiness of the specification for starting the design effort. With this knowledge, corrections can be rapidly implemented.
The review results should be documented in an electronic format (spreadsheet or database) that allows it to be a living document for program tracking, management, and corrective action purposes. It should be organized around the functionality requirement number and title of the software specification. For each requirement line item, there should be a category field or cell to document the following requirement status:
Requirement is missing.
Requirement is incomplete or contains to‐be‐determined items (TBDs).
Requirement is vague or not understood.
Requirement is inconsistent or incompatible with other requirements.
Missing identification of requirements that involve regulatory certification.
Requirement is not optimized or not user‐friendly. Include why and recommendations.
Requirement is not robust.
Requirement is inadequate or undefined. Include specifics and recommendations.
Resolution responsibility and/or owner.
Date the issue was resolved.
Resolution comment. Upon resolution, move the original issue(s) to a cleared‐issue field, and add a summary of the corrective action.
The knowledge and requirements understanding gained in the specification review should also be used in the creation of the software development validation plan.
Software Development/Validation Plan
The software design organization
