Failure Mode and Effects Analysis (FMEA) - A bottoms up systematic, inductive, methodical analysis to determine and document the effects of identifiable failure modes of all system hardware components. The FMEA will produce a list of critical items that when failed, will cause hazardous results. When combined with a Criticality Analysis, each critical component is ranked in order of highest probability of failure, assisting in targeting fixes in the most critical first.

Software FMEA – a technique where critical software variables or modules (functions) are presumed failed and an analysis of the effects on the overall system. A Software FMEA will assist in locating software processes or functions that are critical to system operation.

Reliability Block Diagram Analysis - An analysis to determine a system's probability of success for a given period. An RBDA hierarchically lists the contributors and detractors to the system's reliability to show where the design can best be improved. The RBDA analysis is the starting point for a Reliability Prediction or Failure Mode and Effects Analysis.

Maintainability Analysis - An analysis to determine the probability that a failed unit will be operationally restored within a given period of time when the maintenance action is performed, (Mean Time To Repair, MTTR).

Sneak Analysis - A powerful, topological technique for exposing system anomalies that cause unwanted or unintended events to occur even though no components of the system have failed. Sneak analysis will also uncover anomalies that can inhibit a designed or intended event from occurring. Sneak conditions are manifested as sneak paths, labels, timing, or indications.

Hazard Analysis - Identification and evaluation of potential hazards within a system and the recommendations for averting for the hazards are suggested.

Preliminary Hazard Analysis - An analysis of the initial system concepts to identify all the sources that consitute inherent hazards, analyze them for possible accidents in every mode of system operations, and to identify methods of protection against all possible
accidents.

Fault Tree Analysis - An analysis beginning with an undesired system event that constructs a symbolic logic diagram to show cause-effect relationships between the top undesired event and one or more causes. IDA has now added system software events to the Fault Tree showing end-to-end connectivity for the undesired event through microprocessor based control systems.

HW/SW Interface Analysis - A Sneak analysis tailored only for the interfaces between: Hardware/Software, Hardware/ Hardware, Subassembly-to-Subassembly, etc, Software/ Software, and Custom-to-COTS.

Reliability Prediction Analysis - An analysis to calculate the reliability (Mean Time Between Failure, MTBF) of a system or component modules to establish a common basis for comparing and evaluating related or competitive designs.

Worst Case Analysis - An analysis to determine a circuit's performance by imposing the most undesirable circuit tolerance limits to obtain the worst performance. This analysis assists in designing reliability into the hardware and to identify overstressed components.

Test Optimization Analysis - An analysis of the design's hardware and software in order to formulate the most effective tests necessary to verify system functionality. The analysis aids in writing procedures that will effectively test the nominal and off-nominal conditions imposed on the system. The results greatly streamline the test and verification process in a design.

Software Reliability – a combination of Software Sneak analysis and a Software FMEA. These two analysis combined can uncover logic errors performed by the software and program construction that may decrease the "robustness" of the design.

Traceability Analysis or Requirements Traceability Analysis – an analysis of the system’s requirements and requirements coverage in the completed design’s implementation. A very useful tool in design verification to assure that all of the requirements have been implemented. IDA’s output product from this analysis produces a "waterfall" type diagram allowing a trace of a lower-level requirement back to the parent requirement(s). This can be very useful when performing system modifications and identifying where in the system the changes will be most effective.