System Engineering

We move into the Detailed Design and Development stage whenever there are elements of our design that are not off the shelf, or where we need to make some modification to off the shelf items. Select the most correct option below relating to the detailed design process and its output.

• Once detailed design is complete, we are left with our Product Baseline (PBL) consisting of the detailed design specifications, process specifications, and parts/materials specifications. When detailed design is complete, we pause the project because we need to start considering production requirements.

• Detailed design and development is an iterative process that involves design, prototyping, testing, reviews, and redesign until we are satisfied with the design. It also includes maintaining a good record of the parts, materials and fabrication processes that are needed to produce or construct our design.

• Detailed design and development makes use of modern computer-aided design (CAD) technology to develop our detailed designs. These tools have replaced the need for the time-consuming process of prototyping, integration testing, and documentation of materials and fabrication processes. This allows us to move straight from CAD to production.

• When detailed design is complete, and we are satisfied that our PBL has been finalised, we are able to start planning for through-life support of the system. It is during this planning, that critical through-life requirements such as reliability, availability and maintainability can first be considered.

Requirements analysis and allocation is a key systems engineering activity in Preliminary Design. Which of the following statements best describes this process and its outcome?

• The requirements analysis process “reverse-engineers” the subsystems and the components that the Contractor wants to incorporate into the design. From there, they allocate these requirements to Development Specifications and trace the Development Specifications back to the SyRS. This gives the Customer the illusion of a “top-down” process without jeopardising the preferred detailed design.

• . Requirements analysis is only required if there is developmental technology involved in the design. Off the shelf technology already exists therefore there is no need to worry about analysis of the requirements for these subsystems. For developmental subsystems, requirements analysis and allocation generates a Development Specification to support detailed design for that subsystem.

• Requirements analysis (during Preliminary Design) is conducted by the Customer in order to determine which parts of the design are to be allocated to the Contractor and which parts of the design will be developed in-house by the Customer. This is known as requirement allocation. The requirements allocated to the Customer are placed in the SyRS and the requirements allocated to the Contractor are placed in the relevant development specification.

• . Requirements analysis takes the requirements in the SyRS and analyses them further to derive the requirements relevant at the subsystem-level. These requirements are then allocated to one or more of the subsystems via a requirements allocation matrix or equivalent. The result is a collection of subsystem specifications called “Development Specifications” that are traceable to and from the SyRS and upon which preliminary design decisions can be based.

• Requirements analysis commences just prior to Preliminary Design Review (PDR) and usually forms an entry criterion for that review. PDR investigates how the requirements have been allocated to design space within the design to justify the selection and use of off the shelf technology. Requirements analysis must be completed prior to the end of preliminary design.

Configuration audits have been discussed as an important part of the systems engineering process, and are one of the four areas of focus within configuration management of our systems. Which of the following statements is most correct with regard to configuration audits?

• There are two broad categories of audits conducted in a standard systems engineering process - functional configuration audit (FCA) and physical configuration audit (PCA). We perform audits to confirm that the as-built system is accurately described by its technical documentation. These audits are typically conducted by the customer during the acceptance process.

• Configuration audits in general confirm the correct operation of our configuration management system. Physical configuration audits make use of activities like inspections during construction and production to confirm alignment between as-built systems and their technical documentation. This becomes critical during the sustainment period.

• Function and physical audits (FCA and PCA) are a critical part of the systems engineering design process and support development of the Functional Architecture and Physical Architecture respectively. Change to these architectures becomes increasing difficult with time which is why FCA and PCA are important parts of the earliest design reviews.

• Functional and Physical Configuration Audits (FCA and PCA) are certainly critical parts of a robust systems engineering and configuration management process. Both types of audits are applicable to system developments involving "hardware" (structures, computer hardware, mechanical systems and so on). They are, however, not applicable to software because software does not have a physical form.

• There are two broad categories of audits conducted in a standard systems engineering process - functional configuration audit (FCA) and physical configuration audit (PCA). We perform audits to confirm that the as-built system is accurately described by its technical documentation. With this in mind, audits commence after the system is completely constructed or produced.

Tendering was used in this course as an example of a system-level synthesis process. Tendering may result in a number of solution options being presented to the customer and may result in the revision of the system requirements specification. Which of the following statements most accurately describes this?

• Following release of the RFT and receipt of the responses, the customer checks the proposed costs first and tends to accept the lowest cost option. They then begin negotiation on issues such as technical compliance. In this way, the customer not only ends up with the cheapest option but also ends up with the greatest level of technical compliance.

• When a customer issues an RFT, it is automatically open to any entity in the world who believes they have a compliant solution. Customers therefore often receive a large number of responses to RFTs. This can create evaluation problems for the customer who is often inundated with compliant offers from all over the world but restricting an RFT is illegal.

• When responding to an RFT, companies state that they are compliant to the draft contract even if their solution is non-compliant in some areas. Stating non-compliance with the draft contract is avoided as this will make them uncompetitive in the tender process. Once at the negotiating table, areas of non-compliance can be raised and removed from the contract.

• The RFT normally includes a draft Contract and solicits sufficient information for the customer to evaluate the responses. Responses are expected to vary in terms of compliance (against the draft Contract), costs, schedules, and levels of risk exposure. The customer generally selects a preferred tenderer based on the preferred blend of these variables.

• When a company receives an RFT from a potential customer, they are legally required to respond. If they do not want to respond, they will provide the just the customer with the minimum amount of information and include a large price premium to indicate a lack of interest in the contract.

Developing key "scenarios" was discussed as a potentially useful thing to do during conceptual design. Which of the following provides the best description of scenarios in the context of systems engineering and conceptual design.

• Scenarios are an important part of the Stakeholder Requirements Specification. They are developed using formal language and constructs to ensure they are a suitable basis for both system design and system verification. Scenarios are used by both the customer and the contractor to better understand stakeholder requirements.

• Scenarios form an important attachment to the System Requirements Specification and therefore the functional baseline of the system. They are written in such a way as to "tell a story" about what the stakeholders want to achieve with the system. Scenarios are used by both the customer and the contractor to better understand stakeholder requirements.

• Scenarios are developed by key customer stakeholders to explain what they want to achieve with the new system without requiring them to be systems engineering experts. The scenarios are then used by systems engineers to develop a more formal set of requirements in the form of the System Requirements Specification.

• Scenarios are developed by potential contractors to help explain (to customer stakeholders) exactly what their proposed solution will be able to deliver in terms of capability. Scenarios are written in "customer's language" to help non experts to understand the proposed function and performance of the new system.

• Scenarios are written by customer stakeholders to explain what they need from the new or improved capability. When a contract is eventually established with a contractor, the scenarios are attached to the contract in a section appropriately called the "Statement of Requirement" (SOR).

Assume that we are designing a complex system which consists of many parts/elements and involves significant and sustained design and development effort. Standard configuration management processes generally see at least three (3) distinct baselines established during the design and development process: functional, allocated, and product baselines. Which of the following statements best describes the fundamental configuration management process of establishing and auditing baselines at particular points in time?

• These baselines roughly correspond to system-level, subsystem-level, and component-level detailed design. Establishing the baselines is only part of the process. Configuration audits check each baseline against one another to discover any conflicts between the different baselines. If there is a conflict, the product baseline takes priority because it supports production.

• These baselines roughly correspond to system-level, subsystem-level, and component-level detailed design. Establishing the baselines is only part of the process. Configuration audits check each baseline against one another to discover any conflicts between the different baselines. If there is a conflict, the allocated baseline takes priority because it supports the CI identification process.

• These baselines roughly correspond to system-level, subsystem-level, and component-level detailed design. Establishing the baselines is only part of the process. Configuration audits (normally conducted during the production and integration process) compare as-built systems against the relevant baselines to confirm completeness and accuracy.

• These baselines are established to support the contract management of the system development and roughly correspond to prime-contract level, sub-contract level, and equipment supplier level of design respectively. The term “allocated” gets its name from the fact that requirements are being allocated to a sub-contractor. The term “product” gets its name from the fact that it is defining a product or part.

• These baselines are established to support the project management of the system development. The product baseline represents the function and performance of the system at the system level and is often used as the Statement of Requirement (SOR) on a contract. The functional baseline is derived from the product baseline and is used to describe the function and performance of the individual configuration items (CIs) within the design.

What is the best description of the Preliminary Lifecycle Concept Document (PLCD) that is developed early in the Conceptual Design phase?

• The PLCD defines the need to key lifecycle issues such as spares, training, test equipment and support facilities. If these issues are not accounted for, we may be left with a system that fails to deliver a capability to stakeholders. This is an extension of the POSTED concept introduced in this course.

• The PLCD is developed early in the conceptual design stage as a way of modelling the life cycle cost (LCC) of the system. In this way, key LCC drivers associated with the system can be identified with a view to minimising LCC. One of the benefits of systems engineering is that it aims to minimise LCC

• The PLCD identifies and describes the conceptual approaches to the key lifecycle stages such as operations, acquisition, deployment, sustainment and retirement. It is important to do this early as key stakeholders may have life-cycle related preferences that will influence and/or constrain the subsequent systems engineering effort.

• Systems engineering is a lifecycle discipline and the the PLCD supports this by specifying the through-life support requirements for the system. It is critical to have the through-life support requirements specified as early as possible because research shows that the earlier our requirements are established, the better.

• The PLCD is written by strategic stakeholders within the customer's organisation in order to describe the critical relationship between systems engineering processes and the other related processes such as project management, operations and sustainment. This assists with the systems engineering effort because systems engineering has an "interdisciplinary" focus.

External interfaces (to our system) were identified and defined during Conceptual Design and captured in the SyRS. In Preliminary Design, the subsystems are being designed and this process almost always involves identifying and considering subsystem-level interfaces (that may not be apparent at the system level). Which of the following options contains the most accurate statements about subsystem-level interfaces.

• Subsystem-level interfaces must be identified and documented as they place additional requirements/constraints on our interfacing subsystems. Interface requirements can be captured in the relevant Development Specifications or in a dedicated Interface Control Document, but they need to be mutually agreed between the “design owners” of the respective subsystems.

• Hardware interfaces are the main concern during Preliminary Design and must be documented in the relevant hardware Development Specifications. Software interfaces are much simpler to deal with due to advanced software development environments and methodologies. Accordingly, software interfaces are normally addressed during the writing of code (in the Construction/Production phase)

• Subsystem-level interfaces are managed differently depending on the acquisition concept determined by the Customer. If the system is being developed in-house, subsystem interfaces do not need to be addressed because a single design team is doing the whole design. If the system is being developed by a single contractor, it is the same. If, however, subcontractors are involved, subsystem-level interfaces must then be considered.

• Systems engineering promotes a top-down process where requirements drive design, but when it comes to interfaces, the opposite is true. We design the subsystems (using top-down systems engineering) and then we integrate them together to highlight interfacing issues. Integration normally works but, if it does not work, interface issues that are addressed in the next iteration of design.

• Subsystem-level interfaces are a concern for developmental subsystems because they need to be designed from “the ground up”. There is nothing we can do about the interfaces of off the shelf items so there is no need to identify or consider interface requirements associated with off the shelf technology.

A phase called "Detailed Design and Development" is included in the lifecycle model used in this course. Which of the following statements is is most correct in relation to the detailed design and development process?

• The outputs of the detailed design process will be a collection of designs, parts/materials lists, and fabrication processes. These are reviewed and approved at the Preliminary Design Review and then added to the acquisition contract via a contract change proposal (CCP).

• In a classic “waterfall” process, the outputs of detailed design and development are reviewed at the Critical Design Review (CDR), after which design continues until it is sufficiently complete to support the production/construction process. Design is "frozen" when the initial production process commences and is proven via verification activities.

• It is likely that every design organisation we encounter will have different ways of performing detailed design and development. Despite the differences, we would expect the process to be iterative - involving a repeating process of design, prototyping, review, and redesign until the design is considered complete.

• The detailed design process is a standard process in systems engineering and is comprehensively described in classic standards such as IEEE1220 and EIA632. The customer typically uses these standards to mandate the process in the contract to ensure that the process is largely independent of technology, industry or organisational processes.

• Detailed design and development is a critical part of the systems engineering process that is typically conducted by the customer to ensure that the information provided to the contractors is appropriately focussed on the optimal system-level solution with a demonstrated traceability back to system-level requirements.

Once we have established the Business Needs and Requirements (BNR) from key strategic-level stakeholders, more "operationally-focused" stakeholders refine the need for the new system in the form of Stakeholder Needs and Requirements (SNR). Which of the following statement is most correct with respect to the SNR?

• The SNR is the result of the standard systems engineering (analysis-synthesis-evaluation) loop and is used to develop an unambiguous understanding of the system-level requirements for the new system. In terms of the POSTED construct used in this course, the SNR is very much "E"quipment focused

• The SNR is independent of the BNR. It is put together by operationally-focused stakeholders without reference to the BNR. In this way, it is an independent "error check" on the BNR prior to the more technically-focused systems engineering process.

• The SNR (building on the BNR) contains detailed System Requirements Specification (SyRS), a proposed System Design Description (SDD) and a draft Statement of Work (SOW) as a preliminary form of the Functional Baseline. This is then able to support processes like Requests for Tender (RFTs).

• The SNR is a refinement and development of the Business Needs and Requirements (BNR) and takes the strategic guidance in the BNR to develops more refined life-cycle concepts (in the LCD) and more detailed stakeholder requirements and scenarios (in the StRS).

• The SNR (building on the BNR) captures the needs of all of the stakeholders associated with new system. It is important that all stakeholders who are affected by the new system are consulted during this process to ensure that all needs are captured