System Engineering Requirements - Aircraft System Development Process - EASA Rotorcraft & VTOL 2019

Introduction to System Engineering and Requirements

In this section, Nick introduces himself as the senior technical officer for Sikorsky Aircraft Lockheed Martin and discusses the importance of system requirements in the development process.

Understanding System Requirements

• System requirements are the starting point of any design and define the intended function and conditional behavior of a system or device.

• Requirements need to be written in a verifiable manner, with verification in mind. However, most requirements in the industry are currently not verifiable.

Importance of Using Requirements

• Requirements serve as metrics for defining a design's performance and compliance with aviation and safety regulations. They also provide clear design characteristics for technical teams and serve as a basis for verification.

Types of System Requirements

• Customer type requirements are associated with specific aircraft functions or subsystems based on customer needs.

• Operational requirements define how a device is supposed to function, including crew interactions and interfaces.

• Performance-based requirements determine the anticipated characteristics that a device should meet.

• Physical requirements include dimensions, volume, and maintenance considerations for continued airworthiness.

• Interface requirements cover power consumption, thermal characteristics, etc.

• Certification requirements ensure compliance with regulations, safety standards, etc., but are often overlooked until later stages of the process.

• Safety is a critical aspect that should be considered from the beginning, including performance constraints and overall system integration.

Documenting Requirements

• Gathering and structuring all requirements into a coherent set is a critical aspect of the system requirement process. Clear documentation is essential to convey design functionality.

The Importance of Clear Requirements

In this section, the speaker emphasizes the importance of clear and well-structured requirements in the design process. They highlight that good requirements should be comprehensive enough that someone could recreate the design solely based on them.

• Good requirements should be able to stand alone and allow someone else to recreate the design without any additional input.

• Unfortunately, many designs today do not meet this criteria.

• A typical good requirement decomposition starts with top-down events such as aircraft function, safety functions, system architecture, and organic or inherent design requirements.

• Organic requirements refer to reusable components like specific functions, circuit boards, or mechanical devices.

• Decomposition involves breaking down high-level system requirements into lower-level requirements for sub-assemblies, circuit boards, and PLDs (Programmable Logic Devices).

• Each level of decomposition should have distinct sets of direct or alligator requirements on the left side and derive requirements on the right side.

Recursive Nature of Requirements Verification and Design

This section discusses the recursive nature of requirements verification and design. It highlights how these processes are interconnected and require constant evaluation throughout the development lifecycle.

• The process of requirements verification and design is recursive; it needs to be repeated multiple times to ensure correctness.

• There are relationships between requirements, verification conditions, and design elements.

• Feedback loops are intentionally included in order to ensure that all aspects - design, verification, and requirements - work together effectively.

• Balancing these three elements simultaneously can be challenging but crucial for successful product development.

• Focusing too much on one element while neglecting others can lead to issues such as unverifiable requirements or unbuildable designs.

Structure for Electrical Example

This section presents an example structure for electrical designs. It explains how each phase of the design process should be broken down into key elements and associated requirements.

• The example structure for an electrical design includes high-level system requirements, assembly level, circuit card level, and PLD level.

• Each level of the design should consider customer requirements, internal or organic requirements, performance, certification, and safety.

• Decomposition ensures that each tier of the design holds water and meets all associated requirements.

Types of Requirements

This section provides an overview of different types of requirements typically encountered in the field. It covers functional requirements, application requirements, implementation input types, indirect or refer-to requirements, and global requirements.

• Functional requirements define what a system or component should do.

• Application requirements specify how a system or component will be used in a particular application.

• Implementation input types refer to specific inputs required for implementing a design.

• Indirect or refer-to requirements are those that reference other documents or standards.

• Global requirements encompass broader aspects that apply across multiple systems or components.

Types of Requirements

This section discusses different types of requirements and their characteristics.

Application Requirements

• Describe how a particular piece of hardware or software will be used.

• Focus on the intended use of the system.

Implementation Requirements

• Describe aspects of the design and how it is implemented.

• Provide details about the design process.

Input Requirements

• Express descriptive or interface specifications.

• Can be subjective in nature and difficult to account for all possibilities.

Indirect Requirements

• Imply functionality from an indirect means.

• Have external references to other systems or subsystems.

Global Requirements

• Have a response driven by an event or a set of conditions.

• Require specific events or conditions to occur for something to happen.

Drive Requirements

• Offsprings or parent requirements with higher-level definitions.

• Provide overall direction for the design process.

Functional Breakdown

This section explains how functions are categorized in system requirements, distinguishing between simple and complex systems.

Simple Systems

• Use system-level requirements directly flowing to hardware or software.

• Limited in complexity and becoming less common over time.

Complex Systems

• Highly integrated systems that are more prevalent today.

• Functions are allocated to higher and lower-level requirements.

Layout Approach

This section discusses the approach to layout from a functional standpoint, emphasizing the importance of starting with high-level requirements before considering constraints.

Starting Point

1. Begin with a high-level device and gather functional requirements into sub-element groups.

2. Avoid allocating functions to specific devices at this stage to maintain flexibility in design decisions.

Design Flow

1. Approach design from a hierarchical and organizational structure perspective.

2. Identify how functions and requirements drive the design process.

3. Consider constraints after understanding the functional relationships.

Organizational Constraints

• Organize functional elements based on inputs, outputs, operational sides, and functional sides.

• Collect individual sub-layer requirements under specific functional elements.

• Determine how to organize and integrate these requirements into a circuit card, firmware, mechanical device, or subsystem.

Writing Requirements

This section addresses challenges in writing good requirements and provides tips for effective requirement writing.

Challenges in Requirement Writing

• Engineers often dislike writing requirements.

• Difficulty in achieving the right level of detail.

Use of "Shall"

• Traditionally, it was recommended to use "shall" in all requirements.

• Recent trends challenge this notion as some valid requirements do not contain the word "shall."

Outputs and Triggering Events

• Requirements should explain how outputs respond to valid inputs or triggering events.

• This aspect is often overlooked in requirement writing.

The transcript provided does not include timestamps for all sections.

Tips for Writing Requirements

In this section, the speaker provides tips for writing effective requirements.

Importance of Unique and Concise Requirements

• Each requirement should be unique and specific to avoid a win-win scenario.

• Avoid piling multiple requirements into one sentence; break them up into succinct sentences or functions.

• Use unique identifiers for each requirement, such as those provided by the DOORS system.

Writing for the Target Audience

• Write requirements with the target audience in mind, which includes engineers and technicians who will build the product.

• Avoid assuming prior knowledge; explain concepts at a level understandable to engineers and technicians.

• Be specific and concise in describing what needs to be done and how it should be done.

Using Positive Language and Descriptive Inputs/Outputs

• Express requirements in a positive sense rather than using negations.

• Describe outputs that can be observed and inputs that can be controlled.

• Provide detailed descriptions of how and when specific inputs or outputs occur.

Improving Requirement Writing

This section focuses on improving requirement writing through the use of formats and templates.

Importance of Using a Format

• Use a format or template for writing requirements to maintain control over the content.

• Consistency is crucial when working with teams; using a standard format ensures clarity among team members.

• Avoid situations where each team member uses their own style, leading to confusion during collaboration.

General Considerations for Requirement Writing

• Requirements can have allocation and decompositions across multiple levels of abstraction.

• Be cautious about providing excessive detail at higher levels of decomposition, as it may limit further decomposition possibilities.

• Ensure that requirements are written at an appropriate level of detail to allow for derivation, allocation, and relationships between different levels.

Key Considerations for Writing Requirements

This section highlights key considerations when writing requirements.

Importance of Derive Requirements and Allocations

• Avoid writing requirements at such a detailed level that there is no room for derivation or allocation.

• Writing requirements at the highest possible level allows for better system engineering efforts and identification of relationships.

Using Templates for Concise Requirement Writing

• Utilize templates with a set of conditions to ensure concise requirement writing.

• Include function names, terminology definitions, trace links, outputs, inputs, power-on behaviors, reset responses, assertions, D assertions, and invalid behaviors (if applicable).

• Consistency in format helps maintain clarity and facilitates collaboration among multiple people across different platforms.

System Requirements and Safety Process

This section emphasizes the importance of considering system requirements and safety processes from the beginning of a project. It highlights the need to be familiar with functional hazard assessments and system safety assessments, as well as the mistake of waiting until later stages to address safety concerns.

Importance of System Requirements and Safety Process

• System requirements should capture functionality and additional requirements from the safety process.

• Safety should drive the project from the very beginning.

• Familiarity with functional hazard assessments and system safety assessments is crucial.

• Mistake: Waiting until completing requirement decomposition before addressing safety is too late.

Starting at the Beginning

• The system safety process should run in parallel with requirement decomposition.

• System safety should not be an afterthought or a delay tactic.

• Design should flow out naturally from the process, rather than having preconceived notions about it.

Letting the Process Guide Design

• Allow the process to guide design decisions instead of predetermined ideas.

• The process may reveal unknown factors or incorrect assumptions.

• Applies to software as well, not just programmable logic devices.

Allocation and Decomposition

• Software requirements can be allocated and decomposed for different parts that host them.

• Don't limit software/firmware within device constraints; let it expand as needed.

Design Requirements and Feedback Loop

This section discusses how design requirements should be determined by letting the process guide decision-making. It emphasizes that design needs to align with functionality rather than predetermined ideas. Additionally, it highlights how each level of abstraction can repeat allocated requirements until there is a final design.

Allowing the Process to Guide Design

• Don't predetermine design requirements; let the process flow and guide decision-making.

• The process may reveal new insights and correct incorrect assumptions.

Software and Firmware Requirements

• Software and firmware requirements should not be confined to device limitations.

• They can be allocated and decomposed for different parts that host them.

Repeating Allocated Requirements

• Similar requirements may appear at the same level of abstraction but under different functionality trees.

• This is part of the process and provides visibility into what's happening.

• Don't panic when similar requirements are decomposed; it's a natural part of the process.

Verification of Requirements

This section emphasizes the importance of writing verifiable requirements. It highlights the problem of high-level requirements that lack verification capability, as well as the need to write requirements at a level that allows for effective verification.

Writing Verifiable Requirements

• Requirements should be written with verification in mind.

• High-level requirements without verification capability make it difficult to assess design performance.

• Write requirements at a level that allows for effective verification.

Decomposition for Verification

• Proper decomposition enables verification at the lowest level repeatedly.

• Some higher-level requirements may not be verifiable, but most should be decomposable for effective verification.

[t=0:33:39s] Verification and Testing in the Design Process

In this section, the speaker discusses the importance of verification and testing in the design process. They explain that verification involves inspecting, analyzing, simulating, and testing instructions to ensure that the design meets requirements.

Verification Process

• The verification process typically includes inspection, analysis, simulation, and testing.

• Verification is done at every level of the design process to ensure proper coverage.

• It is important to have coverage at each phase of the process, from hardware level to board level to system level.

• Testing should not be limited to just the highest level; it should be done at the lowest level possible.

• Testing at lower levels allows for identification of issues in the design as it progresses towards higher levels.

• Test results may reveal areas where requirements need improvement or further development.

Importance of Balanced Design and Verification

• The three elements of requirements, design, and verification need to be balanced for successful product development.

• Proper requirement decomposition is crucial for effective design and verification.

• When all elements are balanced and testing is correctly performed, it confirms the design's accuracy and identifies areas for improvement.

The transcript provided does not specify a language. Therefore, I have assumed English as per your request.