chapter 2 syse

Chapanis (1996) also defined systems design as a seven-step process in his process model:

"Requirement Analysis, Systems Design, Hardware and Software Design, Hardware and Software Development, Systems Integration, Installation/Transition & Training, and Maintenance & Operation"; the three strands of development hardware, software, and users are woven together into one integrated system.

Websters definition of "life cycle"

"a series of stages through which something (as an individual, culture, or manufactured product) passes during its lifetime." Almost everything has a life; even the sun on which our planet Earth relies has a life of approximately 14 billion years, starting from a large cloud of dust and gas 5 billion years ago, to become a giant red star in another 5 billion years, and eventually a black dwarf approaching the end of its life.

Generally speaking, the system life cycle consists of seven major phases:

1) the operational need for the system; (2) system concept; (3) system concept exploration and validation; (4) engineering model development; (5) systems production, deployment and distribution; (6) systems operation and maintenance; and, finally, (7) system phase-out and retirement.

The analysis of the detailed design will lead to a comprehensive description of the system configuration in terms of system components and operations. With these descriptions, it should be easy to build or install the system with minimum confusion. The detailed design configuration usually consist of the following design baselines:

1.Product baseline (Type C specification): This, according to Blanchard and Fabrycky (2006), describes the technical requirements for any items below the system level, either in inventory internally or that can be procured commercially off the shelf. Type C specifications cover the configuration of the system at the system elements and components level; it comprises the approved system configuration documentation, including the component/part lists, component technical specifications (TPMs), engineering drawings, system pro-totype models, and integrated design data, which also includes the changes made and the trade-off studies/models for the decisions made for the components. 2.Process baseline (Type D specification): This, according to Blanchard and Fabrycky (2006), describes the technical requirements for the manufacturing or service process performed on any system ele-ments or components to achieve the system functions. It includes the manufacturing processes necessary for system components, such as welding, molding, cutting, bending, and so on, or the service/logis-tics processes such as material handling, transportation, packaging, and so forth; and any related information processing procedures, including any management information systems and database infrastructure for the design. 3.Material baseline (Type E specification): This describes the techni-cal requirements pertaining to the materials of the system elements/components, including the raw materials, supporting materials (such as paints, glues, and compounds), and any commercially avail-able materials (such as cables and PVC pipes, etc.) that are necessary for the construction of the system components. These baselines are built on one another, and are derived from the system technical requirements and system analysis, taking into consideration eco-nomic factors from the global supply chain, and gradually lead to the realiza-tion of the system.

During the system phase-out and retirement phase of a systems life cycle

At the system retirement stage, the system is often char-acterized by a reduction in the number of customers, increasing numbers of system problems, high costs, and difficulty of maintenance. System functions are terminated and the system is disassembled to the level of its components; the system is disposed of.

Definition of a function

Functions - a special action or activity that a system does or provides, a meaningful purpose for which the system is developed or designed for. syntax: verb + noun. For example: verify user account.

Definition of re-manufacturing in system phase-out & retirement

Remanufacturing (also known as closed-loop recycling, or sometimes called refurbishing) implies a series of activities to put a retired system back into use in its complete form, by repairing or replacing faulty parts, to become operational again.

engineering economy

The subject of studying the time value of money and its related models is called engineering economy

Engineering model format

a) Part list B) material list C) Blueprint D) computer aid design (cad) data

Blanchard and Fabrycky (2006) defined the systems design and life cycle as a process with two major steps,

the acquisition phase and the utilization phase; the acquisition phase consists of conceptual design, preliminary design, detailed design and development, and production and construction; the utilization phase consists of product use, phase-out, and disposal. There are many other variations of the processes.

In the detailed design phase, system engi-neers will

(1) develop design specifications for all the lower-level components and items; (2) develop, procure, and integrate the system components into the final system configuration; (3) conduct a critical system review, identify any possible problems with the system configuration with regard to systems requirements, and control/incorporate changes to the system configuration.

System concepts are explored and validated by translating the conceptual functional model to the allocated components model. Whats in the model

A component allocation model is built to verify that, firstly, the conceptual model is feasible to be implemented by systems components, including hardware, software, and human operators. That brings us to the second verification in this phase, which is that systems requirements are verified by the physical models.

Variations among different people regarding the naming of the systems life cycle

Clark et al. (1986) defined systems life cycles as stages of "planning, definition, design, integration acceptance, delivery product"; Blanchard and Fabrycky (2006) used the terms need identification, conceptual design, preliminary design, detailed design, production and construction, utilization and support, and systems phase-out and disposal.

To obtain a complete and detailed system configuration, the systems specification is translated from what (functions) and who (allocations) to how and how much. how is this accomplished

Details of systems components are specified, including the systems component/assembly specifications, what materials are involved, and how to assemble them together. The system evolves from the functional allocation baseline (Type B specification) to the product baseline (Type C specification), process baseline (Type D specification), and material baseline (Type E specification

There are various types of documents involved in the engineering model, based on different types of systems, what are they usually

Generally speaking, the model usually consists of the part list, material lists, blueprints, computer-aided design data (such as AutoCAD and CATIA design drawings), and specifications for the interfaces between components.

Definition of a prototype

In the detailed design, prototype-based simulation is of importance for validating the design. A prototype is a simulated representation of the sys-tem that enables designers and users to visualize, conceptualize, touch and feel, and interact with it to validate the design effectively and efficiently. Prototypes come with different kinds of forms and levels of detail. They range from concept cards, cardboard, hand-sketched flow charts, and story-boards, to near complete complex versions of the system interface or hard-ware mock-ups. Prototypes are used at all stages of the system design, with different levels of information and different aspects of the system for dif-ferent purposes.

There are two basic types of customers involved in systems engineering (these are not exactly the same as the system users; we will talk about system user classes in greater detail in Section 2.2.3)

One type is the government agency; Government agencies such as the FAA and Department of Defense (DoD)play an important role in prompting systems engineering, as most of the systems they need are large and complex, and often have a tight budget and schedule. These government systems usually have more strictly defined structures and specifications (for example, for the DoD, a commonly used structure is Department of Defense Architecture Framework (DoDAF))

he computer technology applied in systems design generally serves two categories of purposes:

Project management and documentation: In this category, the com-puter serves as a project management tool, enabling designers to develop a database for the design data, document the design ele-ments, establish and provide traceability among different design elements, generate reports and different models, and aid trade-off studies. Commonly used tools include Rational DOORS by IBM and CORE by Vitech Corporation. These tools provide a well-controlled environment for systems design, to efficiently manage and commu-nicate systems design activities=. Engineering design aid and prototyping: This category is very com-mon and seen in almost all kinds of systems design. Tools in this cat-egory primarily include prototype tools such as AutoCAD, LabView, CATIA, computer-aided manufacturing (CAM) tools, and model-ing/simulation software such as ARENA, ProModel, and FlexSim.

Definition of reuse in system phase-out & retirement

Reuse is the highest level at which a system is preserved—usually a nonfaulty system—to keep it at a degraded function level to prolong its life cycle (one can think of this as a semiretirement phase). For example, older computer systems may not be fast enough for laboratory scientific computation purposes, but since they are still functional, they may be donated to charity for educational purposes in schools and offices.

The life cycle consideration of system design enables designers to take systems retirement into account in the early phases of the design process by

assembling it in a way which will simplify its disassembly—to facilitate the system being phased out and retired, to impact the environment at a minimum level, and meanwhile save internal costs and energy

Besides the three feasibility criteria of system analysis, there is another source of feasibility criteria that need to be taken into account in system development: these are

legislation, regulations, standards, and codes, which can also be called legal feasibility.

Definition of recycling in system phase-out & retirement

Recycling is a process that retrieves useful raw materials, to reduce waste and the cost of procuring similar fresh new materials. It is believed to benefit the environment by reducing pollution and saving the energy consumption of obtaining new materials. Although a common practice for a long time, it did not catch people's attention until the twentieth century; as an outcome of the industrial revolution, productivity has increased tremendously, as has demand for materials.

Definition of a requirement

Requirement - a single formal statement containing "shall" to define a need that a system must provide or perform. syntax: system (or sub-system or component) + shall +verb +noun (i.e. provide a specific function) + (applicable parameters that this requirement pertains) + (applicable environmental or contextual information for the requirement). For example: system XYZ shall have a mean time between failure (MTBF) at least 10,000 hours under specified operating conditions and environment (temperature 50F to 60F and humidity of 30% to 80%).

The conceptual model is the first model that the system evolves from its need. In the conceptual model, systems needs are organized as requirements. What are requirements

Requirements are formal documents that define the system's intended purposes. From the requirements, operational concepts will then be developed. These depict a complete picture of the systems operations

some examples of the different requirement formats include

Shall statement: The new display shall present the required time of arrival (RTA) status upon request by the pilot.Should statement: The new display should be two-dimensional in an exocentric format.May statement: The new display may make it possible for the pilot to select the color of their choice

Parallel to the system life cycle, there are a series of activities that bring systems into being; this series of activities is called systems engineering processes, or more specifically, system design processes. According to INCOSE.org, the systems engineering process is comprised of seven typical tasks: "State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate. These functions can be summarized with the acronym SIMILAR

State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate" or SIMILAR.

For non government customers, the need for a new system or product originates from organizational strategic planning.

Strategic planning for a new system or product emerges from a number of sources, including marketing surveys and customer feedback/complaints, changing environments, new technologies and new resources, depletion of old resources, and so on. Unlike government projects, in which a strict documentation format has to be followed, in non-government projects, the operational need is developed internally and does not usually have a unified format which must be adhered to.

What do technical performance measures (TPM) facilitate

TPMs facilitate the efforts of system tests and evaluation. For every requirement and function, a quantitative TPM makes it easier for verification of that requirement

advatages of the spiral model

The advantage of the spiral model is flexibility. It allows the changes to the design to be implemented at any stage of the design in a relatively quick manner. As the design does not change when completing one phase and moving to the next, but rather is kept open ended during the process, this means that changes may be implemented without impacting the design too significantly. The second benefit of the spiral model is the level of user involvement. Users are involved in the design process by providing feedback on the design prototypes on a continuous basis, thus retaining more control over the direction of the project. With constant interaction, users' knowledge and understanding of the system requirements will grow as the design pro-gresses, making interaction and communication more effective in the later stages.

what is the verification process

The verification process is to make sure the systems requirements are being met at different phases in the system life cycle; that is, the systems requirements are translated, carried over, implemented, and materialized throughout the system life cycle. Systems requirements are traced through this translation, and the design models are verified against the requirements parameters by using reviews and tests at different stages; sometimes, users are also involved in the tests and reviews. "DO THINGs RIGHT"

disadvantages of waterfall model

There are also some criticisms of the waterfall model. The main concern is also one of its benefits mentioned above: its simplicity and linear nature. Many believe that it is impossible for any complex design project to follow the waterfall model strictly; it is difficult to finish one phase completely before moving on to the next phase. For large, complex systems, it is not uncommon that users do not know exactly what they want at the beginning of system design. After seeing a number of prototypes, users usually change their requirements or add something new to them. System designers have little control over such changes. If these changes occur later in the waterfall model, the cost incurred could be tremendous and significant delays could result. It is apparent that the waterfall model is not flexible enough to accom-modate constant changes, due to its rigid structure and lack of interaction between different phases. This limitation leads researchers to look for more responsive and iterative variations of the waterfall model; the spiral model is one of these variations.

advantages of waterfall model

These advantages include: 1.The model is linear in nature, which makes it simple to understand. 2.A limited amount of resources is needed to implement the model as the model clearly defines efforts and little interaction across stages is needed. 3.The model provides a clear structure for the system design life cycle, making it easy to document; it also provides a clear structure for system intermediate checkpoints and evaluations.

operational profile can also be developed to accompany them, to give a more comprehensive picture of the system concepts, what does the profile include

This profile includes a graphical representation of the systems operations spatial profile, a timeline of the operations temporal profile, a chart of user/operator characteristics, and an interaction diagram to illustrate the exchange of information, materials, and energy flow between users, systems, and the environment.

Once the requirements have been captured and organized, the question to be addressed is what functions the system needs to have to fulfill these requirements. how is this question answered

This question is answered by conducting functional analysis at the system level. Functional analysis is an important activity for system design besides requirement analysis, as it is the first step in describing what the system should do. A system function, according to INCOSE, is a unique action or activity that must be performed by the system to achieve a desired outcome. For a product, it is the desired system behavior. A function can be accomplished by "one or more system elements comprised of equip-ment (hardware), software, firmware, facilities, personnel, and procedural data (INCOSE 2012) A function is an action performed by systems that may or may not involve system users.

Which definition of systems life cycle does liu and the class adopt

We will adopt Chapanis' definition, with a focus on system status and state, not on design activities. The two fundamental characteristics that set this definition apart are that the system life cycle starts with a need and evolves from general to more specific. Typically, operational needs documents follow a specific format: Introduction Missions Technical Objectives Constraints

Operational concepts

are commonly written in narrative format; sometimes they are also called operational scenarios. Scenarios tell a complete story of the system's intended activities, if designed and developed, and how it will be utilized by its operators/users.

Allocation to humans also involves trade studies, as decisions about the allocation can be complex for large systems. Questions to ask include:

What is the role ofhumans within the system functions? What are the advantages and disad-vantages of human control versus automated control of particular functions? What is the interaction style between users and the system? What kind of data is involved? What kinds of skills are necessary to operate the system?

The results of the user-system interaction analysis lead to

a detailed description of the user-system interface requirements and related compo-nents, including input devices, output devices, and the forms of dialogs the interface will contain. We have to keep in mind that, at this stage, the mecha-nism of implementing the interface is still to be determined. The detailed format of the interaction should evolve together with the other system com-ponents, as they are not totally independent of each other.

there are two fundamental characteristics of the systems life cycle that need to be brought to the reader's attention, what are they

1) any system starts from a need; this need determines the system's concepts. From the concepts, system functions are derived, decomposed, and allocated to the system's components—hardware or software—all the way to its final configuration: developed, constructed, and delivered. All the different stages of the systems life cycle and different forms of systems are driven by the initial needs. 2) from the first characteristics just mentioned, one can easily see that the system evolves from a general form to specific forms. This evolvement is a top-down process, starting with the big picture—the need for the design of the system—with further details added in the various life cycle phases. In the following section, we will describe the major phases in the system life cycle; these life cycle phases summarize a common form for most systems. Despite the fact that different systems have different variations of these forms, the fundamental phases should be similar.

terms are general in systems engineering and they will be used quite frequently throughout the book:

1). Requirements: A requirement is a single formal statement containing shall to define a need that a system must provide or perform. It has the following syntax: system (or subsystem or component)+shall+verb+noun (i.e., provide a specific function)+(applicable parameters to which this requirement pertains)+(applicable environmental or contextual information for the requirement). For example, "the portable water purification system shall be able to purify at least two gallons of water per minute." 2). Functions: A function is a specific action or activity that a system does or provides; it is a meaningful purpose for which the system is developed or designed. Since it is an action, a function usually contains a verb. The common syntax for a function is verb+noun. It is easy to confuse functions with tasks; especially for novice designers, it is a common mistake that user tasks are sometimes defined as functions. For instance, in ATM systems, "deposit cash," "deposit check," and "transfer funds" are all ATM functions; but "insert debit card" and "key in passcode" are user tasks, not functions. One has to keep in mind that tasks support functions; any user task should relate to one or more system functions—in other words, without a function, there are no tasks. That is why functional analysis of the system usually comes before task analysis. 3). Components: Components are what constitute the system; they are the elements of system construction. A system may have dif-ferent kinds of components. Generally speaking, system com-ponents consist of three basic types: physical components—the hardware to build the system; electrical and computer software components—the software of the system—namely, the programs and codes that control and regulate system operations; and lastly, human components, sometimes called livewire. Humans can be important components for some systems; their interaction with hardware and software are essential for the carrying out of the system functions. There are different levels of human involvement in systems; we will be describing the user classes in Section 2.2.3 4). Input/Output: As the dynamic entities of the system, system components need input to perform their functions; and since components are connected to each other, some components may, in the meantime, also generate output to some other components; these inputs/outputs may be materials, energy, information, or actions. 5). Baseline: In systems engineering, a baseline is a basis for evalu-ation; it is a reference point for system design to be evaluated. At certain stages of systems design, to verify that the design meets the system requirements, one needs to conduct tests and evalu-ations to make sure the design is on the right track; these are conducted on the intermediate results of the design, which are referred to as baselines. For example, after function analysis, the functional baseline (also called Type A specification) is devel-oped, which contains the functional models of the system. When functions are analyzed and allocated to components to perform the functions, the allocation baseline (also called Type B specifi-cation) is derived. When the design progresses to more detailed information, the production configuration (product baseline, or Type C specification), the manufacturing and assembly process (process baseline, or Type D specification), and the material base-line (Type E specification) are developed; the system can be built in its final form and verified/validated against the requirements. To some extent, system design is a process of translating user needs to requirements, and then different specifications/base-lines of the system can be constructed/developed. The informa-tion pertaining to design baselines will be visited again in greater detail in Section 2.3.

Despite the various names for the various phases of life cycle they all have the same characteristics which can be summarized as

1.) The system engineering process is requirement driven: Systems design starts with identification of the need; the need is the problem statement that the system is designed to address. Once this need is identified, system requirements are derived and these requirements are tailored throughout the system design processes, from the beginning to the end of the whole process, from concept exploration until the system is retired. 'Requirement driven' is the key element for the system engineering process; requirements are the guide for the design. 2.)Systems design follows a general-to-specific evolvement process: The top-down systems' requirement-driven features imply that systems evolve from general requirements to specific functions and components; this process is to ensure the system is designed in an effective and efficient way, by having a big picture first to guide one through the process. Through test and evaluation, the requirements are traced, confirmed, and translated to detailed design specifications. 3.)System design activities are iterative in nature; there is no clear cut between design activities and the system design process is by no means a linear manner. In any design process, one can expect the cycle of design-verification-modification to iterate many times until the design outcomes are validated and approved. Chapanis (1996) also calls this a 3D process: define-develop-deploy; Blanchard and Fabrycky (2006) used the circle of analysis-synthesis-evaluation to illustrate this iterative process.

SysML was developed in 2003, as a dialect (or profile) of the popular UML. It uses part of the UML construct, removing those constructs that are not needed in systems, and also provides an extension of UML modules for unique systems engineering applications.SysML including the following diagrams:

1.0 Behavior diagram1.1 Activity diagram1.2 Sequence diagram1.3 State machine diagram1.4 Use case diagram2.0 Requirement diagram3.0 Structure diagram3.1 Block definition diagram3.2 Internal block diagram3.3 Package diagramAmong these diagrams, the requirement diagram is unique to SysML; the other diagrams are either the same as in UML or modified from UML.An in-depth review of SysML is beyond the scope of this book; please refer to Friedenthal et al.'s (2009) book for a more comprehensive review of the subject.Using MBSE, systems can be described via different forms of models, depending on the perspective from which a system is studied. Generally speaking, there are three models that are most commonly used for the system description: functional models, operational models, and physical models.

In the preliminary design phase, since the level of complexity greatly increases as the design evolves from functions to subfunctions and compo-nents, CAD tools provide great advantages, just as Blanchard and Fabrycky (2006) pointed out. CAD offers advantages including:

1.Enabling designers to address different alternatives in a relatively short period of time, thus making the evaluation and modification of the design more convenient and efficient. 2.Enabling designers to simulate, visualize, and manipulate the design configuration by providing a three-dimensional prototype at low cost and in a relatively short period of time. 3.Enhancing the changing process of the design, in terms both of time and accuracy of data presentation. A well-defined change procedure can be managed and tracked easily with CAD tools, in conjunction with other tools such as electronic mail and computer office systems 4.Improving the quality of the design data, in terms of both the vol-ume of the data and its precision/accuracy. With a high quality of data, system analysis and modeling become easier, as does the capa-bility of building large, complex system models. 5.Facilitating communication among design teams and the training of personnel assigned to the project. With a common database, the designers can easily synchronize the design effectively, ensure all design activities are tracked so that everyone is "on the same page" and, moreover, provide a platform for brainstorming, discussion, and training of new personnel, as a design project will usually last years and there is inevitable turnover of designers.

The following example illustrates typical operational needs:

1.Introduction: This section gives the background and scope of the systems to be designed/requested. 2.Missions: This section defines the highest level of mission that this design tries to accomplish. Missions may be broken down into specific phases and time periods if required. 3.Technical objectives: This section defines the major functions required for the system to be designed. Major function performance parameters are included for these functions. These functions/parameters may be accompanied by technical performance measures. 4.Constraints: This defines the time/cost restrictions on the project and the major milestones and deliverables required.

Some of the values and benefits for the detailed design, according to Blanchard and Fabrycky (2006), include:

1.Provide the designers with opportunities to experiment with dif-ferent detailed design configuration ideas, including (not limited to) facility layout, interface style, packaging schemes, controls and dis-plays, cables and wires, and so on. 2.Provide different engineers with a test bed to accomplish a more comprehensive review of the system configuration, including sys-tem functions and operations, reliability and maintainability, human factors and ergonomics, and support and logistics. Reviews are more open and straightforward, with the possibility of interac-tions between different problem domains. 3.Provide design engineers with a test bed for conducting user task analysis, including the task sequence, time constraints, and skills requirements, which in turn specify the training requirements for system operators and maintainers. 4.Provide a vehicle for designers to demonstrate their ideas and design approaches during the design review. 5.Provide a good tool for training purposes. 6.Provide a good reference for tools and facility design. 7.Serve as a tool in the later stages for the verification of a modification kit design prior to the finalization of data preparation.

Component selection With regard to the sources of the components, the selection approach has to be based on system specification and driven by requirements, but gen-erally speaking, the following sequence is usually followed:

1.Use a standard COTS item. COTS items are usually easy to obtain from a number of suppliers. The benefits of using a standardized part is because most suppliers specialize in manufacturing those parts, which usually conform with established government and industrial regula-tions and specifications, such as FAA or ISO9000/ISO9001. These parts are often produced in large volumes at a relatively low unit price. Using standard parts can significantly reduce the cost and increase the efficiency of system development, and even system maintenance/support. The objective of selecting the right components from COTS is to derive detailed requirements for these components through system design analysis, to pick the appropriate supplier for the parts. 2.Modify an existing COTS item to meet the system requirements. If a COTS item cannot meet the configuration requirements completely, a close form of the item obtained from COTS can be modified. These modifications may include adding a mounting device, adding an adapter cable, or providing a software module. The rule for the mod-ification is that it should be kept to a minimum and be simple and inexpensive, to ensure that no new problems or new requirements are introduced to the system design. 3.Design and develop a unique component for the system. If there is no standard component available and it is not possible to modify a standard part to meet our needs, designing a special unique part is our only option. The manufacturing process and materials used for the part, defined in the Type C, D, and E specifications, need to be based on the systems requirements, and it is desirable to use stan-dard tooling/equipment and assembly parts for ease and economy of the installation, operation, and maintenance. Component selection decisions should be systems requirements driven. The decision-making process usually involves vigorous modeling, simula-tion, and prototype testing, using systems TPMs as the decision-making criteria. , the selection process is a combined approach, both from the top down and the bottom up; it is systems requirements driven and, meanwhile, involves familiarizing oneself with the available technology and suppliers.

why does supply chain play an important role in system production, distribution and deployment

A final production of the system may involve hundreds or thousands of suppliers, depending on the level of complexity of the system. The supply chain plays an important role at this stage, as greater cost may be incurred in distribution and deployment than in the production/assembly itself.

what is a functional model of a system ; what is a operational model of a system ; what is a physical model of a system

A functional model of the system describes the system functions architecture. It illustrates the hierarchical relationships among systems functions. A system operational model describes the systems in terms of the system operations. Similarly to the system functional flow block diagram, it illustrates the system operations from a temporal perspective, describing the systems operations in terms of timeline relationships. A physical model describes the physical components of the system, includ-ing system hardware, software, and the geographical location information for physical model distribution, as well as environmental information for the components These three models are instances of MBSE design outputs. They describe and define the systems from different perspectives, and we can say that none of the models is 100% complete; they address the system from one particular dimension of the system characteristics.

A general approach involved in economic analysis

A general approach involved in economic analysis includes the following steps: identifying the stakeholders; identify-ing the cost factors; selecting measures for all the cost factors and elements; predicting the monetary outcome of the costs and benefits over the life cycle time period; applying the appropriate model to integrate all the values from different time periods into one common basis of measure; comparing the costs and benefits; calculating the net benefit of the system; and performing sensi-tivity analysis to make the comparison more robust

After the operational needs are identified, an integrated systems concept will be developed. This concept is illustrated by a conceptual model. WHy is this important

A model is the abstract representation of the real-world object; it focuses on the factors most relevant to the system needs, conveying the important relationships between these factors, and ignores non relevant factors. For large complex systems, using appropriate models is of the utmost importance, as there are usually hundreds or thousands of factors involved in the design.

Where do operational needs come from

A system starts with a need; a need gives the reason for such a system—that is, why does one need such a system and what is needed—at a very high level. Needs come from customers.

A typical SEMP document includes the following outline:

A typical SEMP document includes the following outline: • Title, cover page, table of contents, scope. • Applicable document .>This section includes all the documents that initiate the system, including the RFP, relevant standards, codes, and government/nongovernment documentation related to this project. • Systems engineering process .>This section conveys how the organization performs systems engineering efforts, and should include the organization's sys-tems engineering policies and procedures, which contain the organizational responsibilities and authority for systems engineering activities and control of subcontracted activities, define the tasks in the systems engineering master schedule (SEMS) and the milestones of the systems engineering detail schedule (SEDS). These tasks and milestones encompass the following activities .−System engineering process planning .−Requirement analysis. −Functional analysis. −Synthesis. −Systems analysis and control, including trade studies, cost analysis, risk analysis, configuration analysis, interface and data management, TPMs, review and evaluation efforts .• Transitional critical technologies. >Describes the key technologies (current and emerging) that the system will be using and their associated risks for systems devel-opment. Provides criteria for selecting technologies and transi-tioning these technologies. • Integration of the systems engineering efforts. >Describes how the various systems design efforts will be integrated and how interdisciplinary teaming will be implemented to involve appropriate disciplines and expertise in a coordinated sys-tems engineering effort. Tasks include team organization, technol-ogy verifications, process proofing, manufacturing of engineering test articles, development testing and evaluation, implementation of software designs for system end items, sustaining develop-ment/problem solution support, and other implementation tasks .• Additional systems engineering activities. >Includes other areas not specified in previous sections but essential for customer understanding of the proposed systems engineering effort. These activities include long lead items, engi-neering tools, design to cost, value engineering, system integra-tion plans, compatibility with supporting activities, and other plans and controls. • Systems engineering scheduling .• Systems engineering process metrics. >Including the cost and performance metrics and process control measures .• Role of reviews and audits .• Notes and appendix.

Roughly speaking, there are basically three levels of user involvement within the context of systems engineering:

A)System users/operators: Also sometimes called customers, system users can be further divided into two categories, direct end users and indirect users. The term end users is easy to understand; these are the people that interact with the system directly. Chapanis (1996) also argued that different names should be used for this category; users refers to small-scale systems, such as a tool, consumer product, or equipment—for example, a micro-computer system user; for large complex systems, such as military aircraft systems or unmanned aerial vehicle ground control systems, people whose use these type of systems are called operators. Besides end users/operators, there are also people who do not directly interact with the system; however, their opinion will impact the end users so much that they cannot be neglected—for example, family members of end users, or managers or supervisors of operators. These indirect users play a significant role in influencing users'/operators' decisions and behaviors; their needs constitute a major part of the system requirements. B)System maintainers/supporters: Another group of humans involved in the system design and life cycle are those who maintain and sup-port the system. The system has reliability, but sometimes it might fail; this implies that the system needs to be maintained and supported, both from a preventive and a corrective perspective. The system's life cycle cost and operational effectiveness also include maintenance efficiencies. This, in turn, requires that the system design also needs to consider the system maintainers' requirements. As part of the sys-tem requirements, the system design should also make maintenance activities easier and more efficient, including indication of the prob-lem area for easy identification of the failure, ease of accessibility for faulty components, standardized tools, equipment and components used in the design to facilitate the maintenance, and so forth. Design requirements for system maintainers' needs should be considered and specified in the early design phase, as they also have a major impact on the system configuration in later stages. C)System designers: These are the third class of human involved in system design and include the systems engineering team members and related system management personnel/administrators. System designers are those who bring the system into being; the system design's focus for this group of users is the documentation of the design. In other words, how does one manage a systems engineer-ing project so that coordination and communication among team members are smooth? For a system with a high level of complex-ity, there are easily hundreds, even thousands, of people involved in the design, and communications are often not synchronized, as the team members may be distributed all over the world. Traditional, paper-based documentation may not be sufficient to handle the high volume of data. The design should follow a unified standard. Systems engineering is itself about the structure of the design; it is about following procedures to make sure things are done correctly from the beginning. Current systems engineering projects are usu-ally managed by computerized software to provide real-time coordination, prompt responses, and efficient communication, strictly controlling changes and precisely tracing design efforts. It will also provide some basic analysis modules to analyze the data. For example, Microsoft Office, CORE (VitechCorp), and DOORS (IBM) are among the most popular commercial systems engineering management software available.

what does the system istallation & development, operation and maintenance consist of

At the system installation and deployment phase, system speci-fications need to be strictly followed and no major changes or modifications are expected. The focus of system installation is on the efficiency and effec-tiveness of manpower and cost. Supply chain management (SCM) plays a more significant role in the installation process, by defining the optimum procedure and locations for the system components and resources. A similar focus is carried on to the system operations and maintenance phase, which occurs after systems installation and deployment. During the system opera-tions and maintenance stage, systems designers and engineers are primarily concerned about the follow-up evaluation and feedback from the users, to find out how well the system performs at the user's site and what difficulty users have with the systems. Incidents and accidents need to be documented and investigated, to find their cause and make improvements in the next version of the system. Necessary maintenance and support activities are carried out; for example, recalling faulty components, providing updates/patches, and supporting the system maintenance and warranty activities. These activities are carried out on a continuous basis, possibly until the end of the system life cycle, to provide data for system improvements, materials for training, and, more importantly, for the next version of the system to be more competitive.

Different engineers use different terminology when defining system life cycles. Some of the most common are:

Clark, Cramer, et al. (1986) - Planning, definition, design, integration acceptance, and delivery of the product. Blanchard and Fabrycky (1996) - Need identification, conceptual design, preliminary design, detailed design, production and construction, utilization and support, and systems phase-out and disposal. Chapanis (1996) - Operational need for the systems, system concept, system concept exploration and validation, engineering model development, systems production, deployment and distribution, systems operation and maintenance, and system phase out and retirement.

In the conceptual design stage, the major design activities include:

Identify system users and system needs; this could be a new need or one to correct a deficiency of a current system. Translate user needs into a formal definition of system requirements. • Conduct feasibility analysis to identify the technical, social, environ-mental, and economic issues for the system design approach; work out a feasible course of action plan for system design processes. • Develop system operational requirements that describe the sys-tem functions and their contextual information. These require-ments should include the normal system functions as well as the system maintenance and support concepts for the normal functions. Technical performance measures (TPMs) for these functions are also defined for these functions at the system level .• Accomplish a system-level functional analysis, defining the hierar-chical structure of the functions and the operational relationships between the functions. • Perform a system-level analysis and trade-off studies, using a num-ber of systems analysis techniques and models. • Produce the Type A specification of the system, which is the func-tional baseline, documenting the results for the above activities. • Conduct the conceptual design review.

What is fidelity

In software interface design, fidelity is used to measure the level of detail included in the prototypes. Fidelity of the prototype refers to the degree of closeness of the prototypes to the system counterparts they represent; the closer to the real system, the higher the fidelity. Fidelity is also used in the aviation training and simulation community to measure the qual-ity of the training devices; it has a similar meaning here as with prototypes, as the training devices are often replicas of the real system; for example, the personal training devices (PTD) to train novice pilots. In detailed design, high-fidelity prototypes are to be developed to serve as the test bed for validating the system components configuration. Prototypes enable designers from different disciplines to come together to communi-cate in a very cost-effective and time-efficient way.

Difference between function and tasks

It should be noted that there is a difference between functions and tasks. Tasks support functions. Any user task should relate to one or more systems functions. Without a function, there are no tasks needed. Functional analysis typically comes before the task analysis for a system.

Based on the system concepts developed, systems functions are decomposed to subsystem level; to configure the components to achieve these functions, the question of how the system functions are accomplished is first addressed. In other words, the system functional model is translated into system operational models and physical models. These models are instances for the application of model-based systems engineer-ing (MBSE) philosophy what is that

MBSE is a formalized application of models to design systems, defining system requirements, system elements, verification/validation, and relevant design activities, to support structures and communications in systems engineering efforts throughout the system life cycle. MBSE uses struc-tured modeling languages and semantics to define systems elements and their relationships, such as System Modeling Language (SysML). SysML is inspired by Unified Modeling Language (UML), a commonly used object-oriented design language for software engineering.

Just as in the conceptual design stage, there are also two types of evaluation at the preliminary design phase. The ongoing informal review and evalu-ation is conducted on a daily basis, where the designers check their own work, providing technical data and information for the design teams; formal reviews are conducted at the end of the preliminary design stage, to verify that the design results follow the design requirements. But, generally speaking, the formal reviews at the preliminary design phase usually include the following:

System Design Review: This is a formal review usually conducted after a preliminary allocation base-line is completed. The system design review is intended to evaluate how well the system configuration, derived from the allocation baseline, will meet sys-tem requirements. This review focuses on the overall system configuration, not the individual components and items. The system design review cov-ers a variety of topics, including system and subsystem functions (including related maintenance functions), function allocations to components, TPMs on subsystems and components, design data and reports (including trade studies results, drawings, part lists, and prototypes), user-system interac-tion/interface, facilities, environmental conditions, and personnel require-ments. A system design review is usually conducted with the involvement of system users to provide feedback on any possible updates and modifications pertaining to the system requirements and configurations. Preliminary Design Review : Also called the hardware/software design review, this is usually conducted after a hardware and software components specification is completed, before implementing these components into the design. In the preliminary design, design data related to system hardware and software are reviewed and a variety of test beds are used for the review, usually including the drawings, part lists, trade-off study reports, simulations, mock-ups, and prototypes. Software and hardware performance and the interface between components and users are assessed. The approval of the preliminary design review leads to a design-to systems specification; that is, system components are ready to be procured and system items to be developed, which is the goal for the system detailed design phase.

Generally speaking, there are three interrelated types of feasibility that need to be taken into account—technical feasibility, economic feasibility, and operational feasibility.

Technical feasibility refers to the practicality of a specific technical approach for the proposed system and the availability of technical resources, including the readiness and maturity of current and emerging technology. Operational feasibility measures how well the proposed system solves the problems, and takes advantage of the opportunities identified during needs definition and how they satisfy the requirements identified in the require-ments analysis phase. In other words, operational feasibility tells us how well the system will work in or fit in the current environment, given the current status of the designing organization. Historically, it was found that operational feasibility is often overlooked or taken for granted. Typically, for operational feasibility analysis, if a new system is being proposed, we need to answer the following questions: How does this system work well with the existing operational system? Is there any resistance to the new system from the end users? How does the system fulfill customer needs? Are the operational characteristics of the system compatible with the current exist-ing management style? What are the potential pros and cons of the system's operational efficiency? Do we have the necessary resources to design such a system, including facility support, management support, capacity/capability of the organization, resource readiness, workforce skills/training, and so on? Economic feasibility, also called cost-benefit analysis (CBA), measures the cost-effectiveness of the proposed system. Economic analysis is a systematic process to compare the costs and the benefits of the system over its intended life span, to see if the benefits outweigh the costs. As a basic requirement for the design project to be economically feasible, the cost-benefit analysis is expected to show positive net benefit over cost. Economic feasibility is considered the most important decision factor for the system design project, as the ultimate goal of a business organization is to make a profit; the system design project is considered as a capital investment, and treated in the same way as other financial investments.

Disadvantages of the spiral model

The disadvantages of the spiral model are primarily related to its imple-mentation. The model works best for large, complex systems with possi-bilities to construct prototypes, such as large-scale software engineering projects. It may not be appropriate for small systems that involve little varia-tion to the requirements, since the requirements are not defined rigidly at the beginning of the spiral model, making such systems development less structural. The model also needs extensive skills in risk assessment and management, requires more in-depth modeling and analysis of risks and uncertain factors. Improper assessment of the risks can lead to a significant increase in system costs.

One essential immediate output from requirement analysis and functional analysis is

The identification of the major system parameters and their quantitative target value. Generally speaking, the system perfor-mance Y is a function of two types of variables or parameters: Y=f(Xi, Xd). Xi represents design-independent parameters and Xd design-dependent parameters. •Design-independent parameters (DIPs) are those attributes or variables external to the system design, but influencing the system performance. The design cannot alter the DIP values, but has to take them into consideration. DIPs usually define the environmental conditions for and constraints of systems operations, such as the labor rate, resources costs, demand rate, service rate, customer pref-erences, interest rate, regional electricity voltage/frequency, and so on. These external factors directly influence the design decisions and system effectiveness. They are independent to the systems design decisions .•Design-dependent parameters (DDPs) are the attributes/variables that are inherent in the system design; these are the variables that designers can decide on and alter to achieve optimal system perfor-mance. Examples of DDPs include system mean time between failure (MTBF), system life cycle cost, output power capacity, acceleration, velocity, weight, dimensions, color, size, and so on. These variables have unique values for the system being designed; in other words, they are dependent on the system itself. •Technical performance measure (TPMs): these refer to the quan-titative values for DDPs. For example, system MTBF of 3000 h, weight less than 40 lb, and so on. These values define the system effectiveness objectives, often included in the system requirements. Quantitative values make it possible for these requirements to be verified.

Life cycle of an engineering system

The life cycle of an engineering system is a sequence of stages/phases in the life of the system. It is the life span or history of the system, from the need to create the system to the point that the system is retired and removed from service.

The detailed design review is a critical checking point, since it is the final review for the system design phase; sometimes it is also called the critical design review (CDR). Detailed design purpose is

The purpose of the critical design review is to formally review all the system components, hardware, and software with the real users, for compliance with all the system specifications. The critical design review usually involves all the stakehold-ers and the complete set of data, including all the baselines, design drawings, applicable analysis reports and trade studies results, detailed plans on the production, operation, and distribution of the system, and system retirement plans.The critical design review usually involves all the stakehold-ers and the complete set of data, including all the baselines, design drawings, applicable analysis reports and trade studies results, detailed plans on the production, operation, and distribution of the system, and system retirement plans.

what is the spiral model

The spiral model was initially developed for the software development pro-cess; it is based on the concept of fast prototyping in the process, combining both the top-down design process from the waterfall model and the bottom-up process from prototype development and evaluation, to quickly address the constant changes and modifications identified from prototype evalua-tion in the requirements-driven design process. he key idea of the spiral model is continuous development through prototyping to manage the risks. Unlike the waterfall model, the system is not completely defined at the beginning, and each of the phases is not completed prior to progressing to the next one; instead, only the most important requirements are addressed, and the detailed requirements are gradually put in place through iterative prototype feedback with user interaction.

Functional Analysis and Function Allocation

The subsystem functional analysis starts with the functional baseline developed from the conceptual design stage. For each of the main system functions, further functional decomposition is conducted and a lower-level functional flow block diagram (FFBD) is developed. The process is very similar to the FFBD in the conceptual design stage, except that it occurs at the lower level. During this decomposition process, for each of the system functions not only the operational functional sequence is identified, but also the maintenance functions if the operational function fails. During subsystem functional analysis, system requirements and related TPMs are also assigned to the sublevel. For example, a reliability of 99% at system level might require a certain level of component performance to achieve that goal. The system itself is not a single object; its performance objectives, defined in TPMs, are accomplished by the components that con-stitute the system.

vee model information

The vee or V-model is another extension of the waterfall model, but instead of strictly following a linear pattern, the design processes are bent upward after the detailed design phase to form a V-shaped process. The vee model establishes a relationship between the phases of system design and its asso-ciated phase of verification and validation, which is achieved by testing and evaluation. The vee model was first developed simultaneously but independently in Germany and the United States. It is now found widely in commercial and defense systems design. On the left-hand side of the V, the system is defined, leading to the system structure and configuration, just as in the early phases of the waterfall model; on the right-hand side of the V, system integration and verification of subsystems and components occur, resulting in opera-tions being verified and validated at the complete system level. The vee model integrates users and designers by linking the system defi-nition phase and system components verification and validation phases; it focuses on the systems life cycle, just like the waterfall model, but provides a mechanism to quickly address the responsibility between the design and ver-ification; thus, the changes can be implemented more efficiently. Criticisms of the vee model primarily concern the application aspect: it is argued that the model does not address the supporting structure of the design, but focuses on the project rather than the organization, and the concepts of maintain-ability and supportability of systems are hardly covered. Separate efforts are needed to define these concept

what is the waterfall model

The waterfall model was originally a model for software project develop-ment. It has been adopted and widely used for general systems design mod-els due to its simplicity. The key idea of the waterfall model, as its name implies, is that system design systematically progresses from one phase to another, in a downward fashion. The process follows an iterative manner as well; that is, at any phase, the design can go back to its previous phase to adjust the design results based on the feedback received from the review.

What is the role of top down processing in systems engineering

The whole idea of systems engineering is the implementation of a top-down process; that is, starting from a problem or a need, it gradually evolves from a design concept to a tangible system that can be used. The key issue in a top-down systems engineering design process is a big-picture perspective; that is, designing the system from a life cycle perspective.

What is the difference between users and operators

Users and operators are usu-ally the same group of people; the difference between these two lies in the complexity of the system itself. If the system is fairly simple in nature, the term users, that is, the user-equipment combination, is employed; if the system is very large and complex, the term operators is used instead. System users and operators essentially represent the same type of user class; namely, the end customer of the system.

simplified way of comparing validation and verification

briefly summarizing the two terms, verification means doing things right, following the systems engineering process and structure, while validation is to make sure we are making the right thing, providing the correct outcome for the users' needs. These two activities go hand in hand, and are closely related to each other; without a good verification plan and process, there will be no valid system to be designed.

The purpose of functional analysis at the subsystem level is to

eventually allocate the system functions to components, so that the system functional model can be translated to the physical model. Theoretically, functions can be decomposed into deeper lower levels, all the way to the nuts-and-bolts level; system designers should know when the functional analysis has arrived at the bottom level to stop further decomposition The results of functional analysis at the subsystem level lead to the develop-ment of a second system design baseline, the allocation baseline, also called specification Type B;

importance of follow-up test and feedback

follow-up evaluation and feedback from the users, to find out how well the system performs at the user's site and what difficulty users have with the systems. Incidents and accidents need to be documented and investigated, to find their cause and make improvements in the next version of the system.

After the physical system model has been built, tested, and finalized, the system will move to the next life cycle phase, which is

full-scale production, distribution, and deployment. The system is in its final format, and is transferred to the production assembly line to start formal mass production. At this stage, the system is produced, possibly in multiple copies. All the components are specified, either produced separately if they are specially designed for the system, or procured if using standard commercial off-the-shelf (COTS) items. These components are delivered to the production site, assembled, and then distributed via retail outlets to customers.

After the proposed system has been shown to be feasible, the corresponding systems engineering program is developed through system planning. This is achieved by preparation of a system engineering management plan (SEMP). According to INCOSE (2012), the SEMP is

he top-level plan for managing the systems engineering effort. The SEMP defines how the project will be organized, structured, and con-ducted, and how the total engineering process will be controlled to pro-vide a product that satisfies customer requirements. A SEMP should be prepared early in the project, submitted to the customer (or to manage-ment for in-house projects), and used in technical management for the study and development periods of the project, or the equivalent in com-mercial practice. The format of the SEMP can be tailored to fit project, customer, or company standards.

what are intangible benefits

here are also benefits that are not easily quan-tified or visualized—we call this type intangible benefits such as increased. environmental friendliness, increased customer loyalty, better quality, better service to the community, better employee job satisfaction, better moral val-ues and ethics, and so on. These benefits are difficult to measure objectively. However, it is believed that the intangible benefits of the system can signifi-cantly impact the economic feasibility of the system, thus cannot be ignored.

he successful bidders will be required to develop a detailed work plan—namely, a statement of work (SOW) to :

illustrate the technical and managerial aspects of systems development, including the personnel qualifications, efforts, and the major time-line and budget.

Systems needs originate from different sources; for government systems, the needs are usually generated from national strategic decision-making, and documented and distributed by a request for proposal (RFP). What is a RFP

is a formal invitation document, distributed to the prospective firms or aca-demic organizations, to describe the needs for the system to be developed, and inviting the qualified organization to propose a systems development plan. Based on the RFP, potential developers will respond with a structured proposal, describing the system in a more technical and operational form, and propose a solution and plan for the system.

what is the validation process

is similar to system demonstration or evaluation: it is to make sure the design outcome is what users want, and that we are designing the correct systems. "DO THE RIGHT THING"

A system (or subsystem or components, depending on the levels of requirements) shall+verb+object (noun)+(target performance metric)+(requirement-related context or environment conditions). Note, here, that the word "shall" is being used in the sentence and carries a very specific meaning

it indicates the sentence is a requirement statement—that this requirement is mandatory and must be followed. There are occasions that "will," "must," "should," or even "may" are used. "Will" and "must" statements signify the mandatory condition that surround the requirements; "should" and "may" statements are less restrictive—usually they are used for nonmandatory or optional require-ments. A "should" statement is a little stronger than a "may" statement; some-times the reason that "should" is used is because it is considered by the design team as important but not yet determined to be mandatory or difficult to ver-ify. A "may" statement is considered as optional, as recommended by research or previous findings, not a contractually binding requirement.

At the end of the conceptual design stage, formal reviews and evaluations are conducted, with representatives from stakeholders (i.e., system users and customers) and designers involved, to determine

• Whether or not the system needs are well understood by all parties • Whether or not the operational requirements are sufficiently devel-oped for the design • Whether or not the functional models are complete and reflect the concepts of the system operational requirements Also called the system requirement review, the conceptual design review uses a variety of techniques and methods, depending on the nature of the system, to gather feedback from stakeholders.

What is Type B specification

it is a system development specification that includes the technical requirements for the system components/items (such as items of equipment, assembly, data packages, computer software programs, facili-ties, support items, and so on). These technical requirements are derived from the original high-level requirements, through the process of analysis, allocation, relevant trade studies, and system modeling. Each of the techni-cal requirements for the items includes the performance, effectiveness, and support characteristics that are required from the system-level requirements and necessary for obtaining the actual items for the system. The allocation baseline (Type B specification) breaks the system func-tions into lower-level functions; thus, the functions can be implemented by system components through an open-architecture configuration structure, providing a foundation through which the subsequent design tasks can be accomplished. Through this baseline, it is ensured that all the subsequent results will follow the original system requirements, providing traceability for design activities. As mentioned earlier, this is the basic design philoso-phy for systems engineering, in such a way that unnecessary changes can be avoided to a great extent

System requirements analysis is the most critical design activity in the conceptual design stage as it( system requirements definition)

it translates the various formats of the system needs from different sources into well-structured system operational requirements, elimi-nating ambiguity, resolving conflicts, and documenting requirements so that they can be followed, traced, and verified.

Sustainable development or green engineering is

one of the most important types of development, depending on the different kinds of components. There may be different end uses for the components: reuse, re-manufacturing, or recycling.

what is the output of functional analysis

output of functional analysis is the functional model or functional baseline. A functional baseline defines what functions the system should perform and the operational structures of these functions, not how the functions are accomplished.

There are two major types of standards that are related to systems engineering:

safety standards and performance standards. These standards include federal and military standards such as MIL-STD-1472D, Human Engineering Design Criteria for Military Systems, OSHA (Occupational Safety and Health Administration) standards for safety; and International Standards, such as ISO (International Organization for Standardization) 9000 (Quality Management Standard). Although some standards are concerned with safety issues, they cannot be ignored in the design and the consequences of not complying with the standards can have a significant impact to system effectiveness, even to the extent of involvement in a product liability lawsuit.

Techniques that can be used in the system operation and maintenance phase are

similar to those in the system design phase, espe-cially in the early conceptual design stage for gathering user needs, such as observation of system operations, surveys and questionnaires, user inter-views and focus groups studies, crucial incidents and accidents studies, and related test/evaluation methods.

During the system operations and maintenance stage of system life cycle

the emphasis is on customer service and support of the system; since the design of the system has been finalized, no further design changes are possible. However, follow-up tests and evaluations of systems are still necessary to identify any problems within operations and maintenance; these test results, together with feedback from customers, serve as a guide for any engineering changes that may be made for the subsequent version or next generation of the system. Emerging problems are addressed and fixed immediately, especially those pertaining to user safety and hazards. Faulty systems are fixed, recalled, or replaced to minimize the impact from these issues. At this stage of the system life cycle, operation, maintenance, and evaluation efforts are carried out continuously, until the system is ready to be retired

Conceptual design is the first step in the systems engineering design process, yet it is the most important step for the overall process. Why is that ?

the focus is on requirement analysis and elaboration. In the conceptual design stage, the problem statements of the system are defined as requirements. As the sources for requirements, system needs are collected and captured, then analyzed and compiled into one comprehensive requirements document. System operational requirements are defined in the requirements document; this document provides a rationale for the system design, explaining why the design is necessary.

Reason for system retirement

the majority of these are incompatibility with emerging technology, discontinuation of supply of materials, changes to legislation and regulations, new trends in customer demand, and so on.

Department of Defense Architecture Framework (DoDAF):

this is a foundational framework for developing and describing systems architec-ture that ensures a common denominator for communicating, understand-ing, comparing, and integrating architectures across different organizations for DoD-related systems. DoDAF establishes data element definitions, termi-nologies, rules, relationships, and a baseline for consistent development of military systems architectures.

There is no general template or approach to follow to perform the need analysis; its goal is to define what the system should provide, not how it is constructed. According to Blanchard and Fabrycky (2006), a need analysis should provide general answers for the following questions (but not limited to these):

• What is required of the system in functional terms? • What functions must the system perform? • What are the "primary" and "secondary" functions? • What must be done to alleviate the foreseen deficiency? • When must the functions be performed? • When must the system be constructed and delivered? • What is the planned system life cycle? • What is estimated system life cycle cost? • Where is the system intended to be used? • What frequency is the system intended to be used? Answers to the above questions give us a big overall picture of what needs to be done, not how it is done. We must make sure we do not over-specify the needs by adding details of design solutions.

Although they vary with different types of systems at different complexity levels, system operational requirements should at least address the following issues (Blanchard and Fabrycky 2006):(Systems requirement analysis)

• Defining system mission: Identify the primary and secondary mis-sions of the system; namely, what is the overall system objective? What are the main functions that system is intended to provide? Usually a set of operational scenarios (narrative or graphical) are defined to help elaborate the mission profile .• Defining system stakeholder: Identify the major user classes for the system, together with their main characteristics, including demo-graphic information and skill/training levels for each class. • Defining system performance and physical parameters: These are the operational characteristics of the system's intended function; for example, how well the system performs under certain operational sce-narios. These parameters include system deployment and distribution characteristics, describing how the system is deployed geographically. • Defining system life cycle and utilization requirements: What is the intended life span for the system? How is the system utilized (i.e., hours per day, days per week, months per year)? This is closely related to system performance parameters, such as system reliability and maintainability measures, as they are both functions with time and utilization frequencies. • Defining the system effectiveness factors: The system's main techni-cal and economic effectiveness factors are defined at the conceptual design stage; these include life cycle cost, system availability, mean time between maintenance (MTBM), logistic support, failure rate (λ), system operators' and maintainers' skill levels, and so on. Generally speaking, given the system is operational, how efficient and effective is it? • Defining the environmental factors: These are the environmental conditions for the system's operations and maintenance, includ-ing physical environmental conditions (i.e., location, temperature, humidity, etc.), as well as the possible environmental impact from the system. This is essential for system sustainable development, because, during the system life cycle, the system constantly interacts with its ambient environment, especially the natural environment that humans rely on. Environmental friendliness is one of the most important factors for the system's long-term success; this is true even for the system's retirement and recycling of materials. This factor needs to be addressed in the very early stages of system design. The results of the requirement analysis lead to the preparation of system requirement documents. They define, refine, and record a set of complete, accurate, nonambiguous system requirements, usually in an operational hierarchical structure, based on the different levels of system addressing, managed by database-like model-based systems engineering (MBSE) soft-ware (such as DOORS and CORE), and made easily accessible to all designers at appropriate levels.

Allocation of high-level requirements and TPMs to the lower-level components is a necessity to procure the right components. Unfortunately, there are no standards or template to follow to perform these allocations; this is because:

• Different types of requirements necessitate different types of TPMs; some are easy to measure, such as the cost of the components, size, dimensions, and quantitative engineering parameters. These TPMs usually have direct ways to be calculated; some other TPMs are not that easy to measure, especially those involving qualitative parame-ters, such as system reliability, supportability, and most of the human factor parameters. Most of these type of TPMs rely on empirical data for verification—sometimes even subjective data. • Analytical models play a very important role when assigning TPMs for quantitative measurements, such as the faulty tree analysis (FTA) to derive the cause-effect relationship of the failure occurrence prob-ability among components at different levels, or the transition func-tions to study the system control dynamics. However, the majority of the system parameters have no well-defined analytical model to find the optimal solution. In many cases, since the decomposition maps from one (high-level system function) to many (subsystem-level functions), it is nearly impossible to find a unique solution for the assignment. For example, there may be multiple ways of configur-ing the components that can all meet the system reliability require-ments. To find the most feasible solution, one inevitably has to use the most naïve method, trial-and-error, and multiple criteria have to be combined to narrow down the solution space. In the process of decomposition and allocation, often the bottom-up approach is com-bined with the top-down process; as the top-down process cannot lead to a unique solution, we do need to search for what is available and determine what our choices are. In the later chapters (Section II of this book), we will discuss the different models and methods that can be applied to allocate high-level requirements to various lower levels. Readers have to keep in mind that a good designer is always versatile and flexible, and must master a wide range of models and techniques; experience with similar systems will help a great deal.

The preliminary design extends the results from the conceptual design stage to more detailed levels; namely, the subsystem level and component level. The purpose of the preliminary design is to demonstrate that the design concepts are indeed valid in the sense that they can be implemented through systems components, including hardware and software. Design concepts are further explored, with information about component implementation, translating the what aspects of the system (systems functions) to how the system requirements are actually fulfilled (function allocations to components). Generally speaking, the major activities in preliminary design include the following:

• Performing the functional analysis at the subsystem and component levels; taking the functional baseline developed from the concep-tual stage, the system-level functions are further decomposed into the subsystem-level functions as well as the operational structure of these systems. • Developing the specifications for the subsystem and components; this includes components' TPMs, product specification, and pro-cesses/materials related to the procuring or producing of these com-ponents; preparing preliminary configurations for system physical models, including the interaction between components, and between humans and the system .• Documenting the design results using engineering design tools and software, including the design data, drawings, and prototype .• Performing trade-off analysis for the system configuration; optimizing system performance by applying appropriate decision-making models. • Conducting the system design review to verify that the preliminary design results conform to system requirements

The results from the design activities including the need identification, system feasibility analysis, requirement analysis, and system function analysis, are integrated and compiled into one major document for the conceptual design stage, system specification, or Type A specification or A specs. It specifies the system functional models from the highest level, so is called the system functional baseline. A typical Type A specification includes the following information:

• System general description, including system mission, scope, and applicable documents .• System requirements analysis results, including the system-level requirements and their refined sublevel requirements. Requirements may be categorized into different classes, depending on the nature of the system; usually, they include system operational requirements, maintenance requirements, system effectiveness factors (such as reliability, maintainability, human factors and usability, system cost-benefit profile, safety and security, etc.); system design and con-struction considerations (hardware and software technology, data management, CAD/CAM). • Functional structure of the system, including major functions definitions and hierarchical structure at system level; functional model represented by functional flow block diagram; major mainte-nance functions and their relationship with the system operational functions. • Other design considerations and constraints, including system logis-tics and support concepts; test and evaluation plan; major system milestones for system life cycle. As the first system configuration baseline, the system specification (Type A) defines the technical, performance, operational, and support characteristics for the system as an entity at the highest level.

The allocation model usually includes the following items:

•Systems requirements for subsystems and components, refined and quantitative technical performance measures for functions, includ-ing the input, output, and constraining factors for each function •Functional package and assembly lists, including systems compo-nents lists and preliminary configurations for the components •User systems interaction requirements •Design data, validation and evaluation documentation, including the faulty tree analysis (FTA) and failure mode and effect critical-ity analysis (FMECA), human factors tasks analysis, and computer-aided design data