Design requirements and constraints

Design requirements specify features of our object or system that are required in the case of our specific design. They may be stated in both symbolic and numerical terms. For example, a design requirement may state that our truss should have sufficient stiffness. A symbolic attribute will be used, and this requirement presented as 

This requirement may be also much more specific and may be presented using a numerical attribute and its specific numerical value  

In more general and computational terms, a design requirement can be defined thus  

Design constraints identify features of our object or system that must be avoided in our design. They may also be stated using both symbolic and numerical attributes. For example, a constraint may state that concrete may not be used as a material for our bridge. In this case, obviously only a symbolic attribute may be used and the constraint will be presented as 

A numerical attribute will be used in a constraint specifying that steel with a specific yield point (yield strength) cannot be used. For example, 

---

Among the sub-systems mentioned above, the design of the electrode array (also called the exciter array) is the critical factor that will determine the design requirements and constraints for the other three sub-systems. 

Differentiating between design requirements and constraints makes a lot of sense from the perspective of a human designer who wants to know and understand what is expected from him or her in terms of the desired and undesired features of his or her future design. From the computational point of view, however, this distinction is not important and only complicates calculations. Since it is possible to formulate design requirements as constraints,... 

Provides specific design requirements and constraints, which must be... 

The first paper. Challenges Associated With the Design of Oil-Gas Separation Systems for North Sea Platforms" by Penick and Thrasher, discusses and reviews the different design aspects, requirements, and constraints associated with oil and gas separation facilities in the North Sea. Specifications of crude-oil vapor pressure and gas dewpoint are reviewed from a pipeline standpoint, and potential solutions and design approaches to meet the separation objectives are presented. 

The optimization process required the problem to be posed in the formed of an objective function, designed variables and constraints. The least squares of the potential on the element of the surfaces with respect to the potential target value of the surfaces were used as an objective function to smooth the potential [5,6],... 

Blood Gas Analysis Cell. The blood gases enter the mass spectrometer by permeation through a thin Teflon membrane enclosed in the blood gas cell (BGC). The design of the stirred BGC was determined by the following general requirements and constraints ... 

System engineering starts with first determining the goals of the system. Potential hazards to be avoided are then identified. From the goals and system hazards, a set of system functional and safety requirements and constraints are identified that set the foundation for design, operations, and management. Chapter 7 describes how to establish these fundamentals. 

As the design process progresses and design decisions are made, the safety requirements and constraints are further refined and expanded. For example, a safety constraint on TCAS is that it must not interfere with the ground-based air traffic control system. Later in the process, this constraint will be refined into more detailed constraints on the ways this interference might occur. Examples include... 

The safety requirements and constraints on the physical system design shown in section 7.3 act as input to the standard system engineering process and must be incorporated into the physical system design and safety control structure. An example of how they are used is provided in chapter 10. 

Additional system safety requirements and constraints, including those on operations and maintenance or upgrades will be used in the design of the safety control structure at the organizational and social system levels above the physical system. There is no one correct safety control structure what is practical and effective will depend greatly on cultural and other factors. Some general principles that apply to all safety control structures are described in chapter 13. These principles need to be combined with specific system safety requirements and constraints for the particular system involved to design the control structure. 

The reengineering process starts with the definition of the hazards to be eliminated or mitigated, system requirements and constraints necessary to increase safety, and the design of the current safety-control structure. Analysis can then be used to drive the redesign of the safety controls. But once again, just like every system that has been described so far in this chapter, the process starts by identifying the hazards... 

In analyzing an existing organizational or social safety control structure, one of the first steps is to determine where the responsibility for implementing each requirement rests and to perform a gap analysis to identify holes in the current design, that is, requirements that are not being implemented (enforced) anywhere. Then the safety control structure needs to be evaluated to determine whether it is potentially effective in enforcing the system safety requirements and constraints. 

Once the mapping is complete, a gap analysis can be performed to ensure that each system safety requirement and constraint is embedded in the organizational design and to find holes or weaknesses in the design. In this analysis, concerns surfaced, particularly about requirements not reflected in the defined ITA organizational structure. 

One key to having a cost-effective safety effort is to embed it into a system engineering process from the very beginning and to design safety into the system as the design decisions are made. Once again, the process starts with the fundamental activities in chapter 7. After the hazards and system-level safety requirements and constraints have been identified the design process starts ... 

The primary responsibility of the process controller is to produce conutiands to fulfill its control responsibilities. Again, the STPA hazard analysis and safety-guided design process will produce the application-specific behavioral safety requirements and constraints on controller behavior to ensure safety. But some general guidelines are also useful. 

The requirements and constraints include links to the hazard analysis that produced the information and to design documents and decisions to show where the requirements are applied. These two examples have links to the parts of the hazard analysis from which they were derived, links to the system design and operator procedures where they are enforced, and links to the user manuals (in this case, the pilot manuals) to explain why certain activities or behaviors are required. 

Safety-related constraints should have two-way links to the system hazard log and to any analysis results that led to that constraint being identified as well as links to the design features (usually level 2) included to eliminate or control them. Hazard analyses are linked to level 1 requirements and constraints, to design features on level 2, and to system limitations (or accepted risks). An example of a level 1 safety constraint derived to prevent hazards is ... 

Once the system design features are determined, (1) an internal control structure for the system itself is constructed along with the interfaces between the components and (2) functional requirements and design constraints, derived from the system-level requirements and constraints, are allocated to the individual system... 

Software need not be treated any differently than the other parts of the system. Most safety-related software problems stem from requirements flaws. The system requirements and system hazard analysis should be used to determine the behavioral safety constraints that must be enforced on software behavior and that the software must enforce on the controlled system. Once that is accomplished, those requirements and constraints are passed to the software developers (through the black-box requirements specifications), and they use them to generate and validate their designs just as the hardware developers do. 

At this point in development, the safety requirements and constraints are documented and traced to the design features used to implement them. A hazard log contains the hazard information (or links to it) generated during the development process and the results of the hazard analysis performed. The log will contain embedded links to the resolution of each hazard, such as functional requirements, design constraints, system design features, operational procedures, and system limitations. The information documented should be easy to collect into a form that can be used for the final safety assessment and certification of the system. 

These recommendations and those resulting from other thoroughly investigated accidents also provide an excellent resource to assist in generating the system safety requirements and constraints for similar types of systems and in designing improved safety control structures. 

The separation in space principle needs to be used when dealing with requirements and constraints related to the spatial aspects of design. For example, an inventor is working on a concept for a snowmobile to be used behind the Arctic Circle to transport frozen seafood. The traditional thinking about designing commercial vehicles for the Arctic Circle is simple Insulate the entire vehicle as much as possible. In our case, this heuristic is simply inadequate and we need to use the separation in space principle. 

Testing and verification of the ISS have involved a number of unique requirements and constraints. The major contributing factors include the on-orbit assembly process, the series of vehicle stages defining the incremental steps in the assembly process (each with unique functional performance requirements), and the requirement to operate and support human activity under the extreme environmental conditions of space. Add to this that the system is designed, built, and deployed by a consortium of 16 nations, and its parts delivered to their final assembly location by the most complex space vehicle ever built (the Space Shuttle), and the result is arguably the most difficult test and verification program ever attempted. 

---