曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
Requirements Criticality Analysis
Criticality analysis identifies program requirements that have safety implications. A method of applying
criticality analysis is to analyze the risks of the software/hardware system and identify those that could
present catastrophic or critical risks. This approach evaluates each program requirement in terms of the
safety objectives derived for the software component.
The evaluation will determine whether the requirement has safety implications and, if so, the requirement is
designated “safety critical”. It is then placed into a tracking system to ensure traceability of software
requirements throughout the software development cycle from the highest-level specification all the way to
the code and test documentation. All of the following techniques are focused on safety critical software
components.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-5
The system safety organization coordinates with the project system engineering organization to review and
agree on the criticality designations. At this point the systems engineers may elect to make design changes to
reduce the criticality levels or consolidate modules reducing the number of critical modules.
At this point, some bottom-up analyses can be performed. Bottom-up analyses identify requirements or
design implementations that are inconsistent with, or not addressed by, system requirements. Bottom-up
analyses can also reveal unexpected pathways (e.g., sneak circuits) for reaching hazardous or unsafe states.
System requirements should be corrected when necessary.
It is possible that software components or subsystems might not be defined during the Requirements Phase,
so those portions of the Criticality Analysis would be deferred to the Architectural Design Phase. In any case,
the Criticality Analysis will be updated during the Architectural Design Phase to reflect the more detailed
definition of software components.
The methodology for Requirements Criticality Analysis is:
· All software requirements are analyzed in order to identify additional potential system
hazards that the system PHA did not reveal and to identify potential areas where system
requirements were not correctly flowed to the software. Identified potential hazards are
then addressed by adding or changing the system requirements and reflowing them to
hardware, software and operations as appropriate.
· At the system level: identify hardware or software items that receive/pass/initiate critical
signals or hazardous commands.
· At the software requirements level: identify software functions or objects that
receive/pass/initiate critical signals or hazardous commands.
· This safety activity examines the system/software requirements and design to identify
unsafe conditions for resolution such as out-of-sequence, wrong event, inappropriate
magnitude, incorrect polarity, inadvertent command, adverse environment, deadlocking,
and failure-to-command modes.
· The software safety requirements analysis considers such specific requirements as the
characteristics discussed below as critical software characteristics.
The following resources are available for the Requirements Criticality Analysis. Note: documents in brackets
correspond to terminology from DOD-STD-2167. Other document names correspond to NASA-STD-
2100.91.
· Software Development Activities Plan [Software Development Plan] Software
Assurance Plan [None], Software Configuration Management Plan [Same] and Risk
Management Plan [Software Development Plan].
· System and Subsystem Requirements [System/Segment Specification (SSS),
System/Segment Design Document].
· Requirements Document [Software Requirements Specifications].
· External Interface Requirements Document [Interface Requirements Specifications] and
other interface documents.
· Functional Flow Diagrams and related data.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-6
· Program structure documents.
· Storage and timing analyses and allocations.
· Background information relating to safety requirements associated with the
contemplated testing, manufacturing, storage, repair, installation, use, and final
disposition of the system.
· Information from the system PHA concerning system energy, toxic, and other hazardous
event sources, especially ones that may be controlled directly or indirectly by software.
· Historical data such as lessons learned from other systems and problem reports.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册下(128)
