曝光臺(tái) 注意防騙 網(wǎng)曝天貓店富美金盛家居專營(yíng)店坑蒙拐騙欺詐消費(fèi)者

The software safety organization should flow requirements into the Software Requirements Document (SRD)
and the Software Interface Specification (SIS) or Interfaces Control Document (ICD). Safety-related
requirements must be clearly identified in the SRD
SIS activities identify, define, and document interface requirements internal to the sub-system in which software
resides, and between system (including hardware and operator interfaces), subsystem, and program set
components and operation procedures. Note that the SIS is sometimes effectively contained in the SRD, or
within an Interface Control Document (ICD) which defines all system interfaces, including hardware to
hardware, hardware to software, and software to software.
J.3.1 Development of Software Safety Requirements
Software safety requirements are obtained from several sources, and are of two types: generic and specific.
The generic category of software safety requirement is derived from sets of requirements that can be used in
different programs and environments to solve common software safety problems. Examples of generic
software safety requirements and their sources are given in Section J.1.4.3 Generic Software Safety
Requirements. Specific software safety requirements are system unique functional capabilities or constraints
that are identified in three ways:
·  Through top down analysis of system design requirements (from specifications): The
system requirements may identify system hazards up-front, and specify which system
functions are safety critical. The (software) safety organization participates or leads the
mapping of these requirements to software.
·  From the Preliminary Hazard Analysis (PHA): The PHA looks down into the system
from the point of view of system hazards. Preliminary hazard causes are mapped to, or
interact with, software. Software hazard control features are identified and specified as
requirements.
·  Through bottom up analysis of design data, (e.g. flow diagrams, FMEAs, fault trees etc.)
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-4
Design implementations allowed but not anticipated by the system requirements are analyzed and new
hazard causes are identified. Software hazard controls are specified via requirements when the hazard causes
map to, or interact with, software.
J.3.2 Safety Requirements Flowdown
Generic safety requirements are established “a priori” and placed into the system specification and/or overall
project design specifications. From there they are flowed into lower level unit and module specifications.
Other safety requirements, derived from bottom-up analysis, are flowed up from subsystems and components
to the system level requirements. These new system level requirements are then flowed down across all
affected subsystems. During the System Requirements Phase, subsystems and components may not be well
defined. In this case, bottom-up analysis might not be possible until the Architectural Design Phase or even
later.
An area of concern in the flowdown process is incomplete analysis, and/or inconsistent analysis of highly
complex systems, or use of ad hoc techniques by biased or inexperienced analysts. The most rigorous (and
most expensive) method of addressing this concern is adoption of formal methods for requirements analysis
and flowdown. Less rigorous and less expensive ways include checklists and/or a standardized structured
approach to software safety as discussed below and throughout this guidebook.
The following section contain a description of the type of analysis and gives the methodology by defining the
task, the resources required to perform the analysis, and the expected output from the analyses.
Checklists and cross references
Tools and methods for requirement flow down analyses include checklists and cross-references. A checklist
of required hazard controls and their corresponding safety requirements should be created and maintained.
Then they can be used throughout the development life cycle to ensure proper flow down and mapping to
design, code and test.
·  Develop a systematic checklist of software safety requirements and any hazard controls,
ensuring they correctly and completely include (and cross reference) the appropriate
specifications, hazard analyses test and design documents. This should include both
generic and specific safety requirements.
·  Develop a hazard requirement flowdown matrix that maps safety requirements and
hazard controls to system/software functions and to software modules and components.
Where components are not yet defined, flow to the lowest level possible and tag for
future flowdown.
　
中國(guó)航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊(cè)下(127)