system engineering process

  

Definition of a system

A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000). Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle. This process is usually comprised of the following seven 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, I ntegrate,Launch, Assess and Re-evaluate. This Systems Engineering Process is shown in Figure 1. It is important to note that the Systems Engineering Process is not sequential. The functions are performed in a parallel and iterative manner. State the problem The problem statement starts with a description of the top-level functions that the system must perform: this might be in the form of a mission statement, a concept of operations or a description of the deficiency that must be ameliorated. Most mandatory and preference requirements should be traceable to this problem statement. Acceptable systems must satisfy all the mandatory requirements. The preference requirements are traded-off to find the preferred alternatives. The problem statement should be in terms of what must be done, not how to do it. The problem statement should express the customer requirements in functional or behavioral terms. It might be composed in words or as a model. Inputs come from end users, operators, maintainers, suppliers, acquirers, owners, regulatory agencies, victims, sponsors, manufacturers and other stakeholders. Investigate Alternatives Alternative designs are created and are evaluated based on performance, schedule, cost and risk figures of merit. No design is likely to be best on all figures of merit, so multicriteria decision-aiding techniques should be used to reveal the preferred alternatives. This analysis should be redone whenever more data are available. For example, figures of merit should be computed initially based on estimates by the design engineers. Then, concurrently, models should be constructed and evaluated; simulation data should be derived; and prototypes should be built and measured. Finally, tests should be run on the real system. Alternatives should be judged for compliance of capability against requirements. For the design of complex systems, alternative designs reduce project risk. Investigating innovative alternatives helps clarify the problem statement. Model the system Models will be developed for most alternative designs. The model for the preferred alternative will be expanded and used to help manage the system throughout its entire life cycle. Many types of system models are used, such as physical analogs, analytic equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations and mental models. Systems Engineering is responsible for creating a product and also a process for producing it. So, models should be constructed for both the product and the process. Process models allow us, for example, to study scheduling changes, create dynamic PERT charts and perform sensitivity analyses to show the effects of delaying or accelerating certain subprojects. Running the process models reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of effort. Product models help explain the system. These models are also used in tradeoff studies and risk management. As previously stated, the Systems Engineering Process is not sequential: it is parallel and iterative. This is another example: models must be created before alternatives can be investigated. Integrate No man is an island. Systems, businesses and people must be integrated so that they interact with one another. Integration means bringing things together so they work as a whole. Interfaces between subsystems must be designed. Subsystems should be defined along natural boundaries. Subsystems should be defined to minimize the amount of information to be exchanged between the subsystems. Well-designed subsystems send finished products to other subsystems. Feedback loops around individual subsystems are easier to manage than feedback loops around interconnected subsystems. Processes of co-evolving systems also need to be integrated. The consequence of integration is a system that is built and operated using efficient processes. Launch the system Launching the system means running the system and producing outputs. In a manufacturing environment this might mean buying commercial off the shelf hardware or software, or it might mean actually making things. Launching the system means allowing the system do what it was intended to do. This also includes the system engineering of deploying multi-site, multi-cultural systems. This is the phase where the preferred alternative is designed in detail; the parts are built or bought (COTS), the parts are integrated and tested at various levels leading to the certified product. In parallel, the processes necessary for this are developed – where necessary - and applied so that the product can be produced. In designing and producing the product, due consideration is given to its interfaces with operators (humans, who will need to be trained) and other systems with which the product will interface. In some instances, this will cause interfaced systems to co-evolve. The process of designing and producing the system is iterative as new knowledge developed along the way can cause a re-consideration and modification of earlier steps. The systems engineers' products are a mission statement, a requirements document including verification and validation, a description of functions and objects, figures of merit, a test plan, a drawing of system boundaries, an interface control document, a listing of deliverables, models, a sensitivity analysis, a tradeoff study, a risk analysis, a life cycle analysis and a description of the physical architecture. The requirements should be validated (Are we building the right system?) and verified (Are we building the system right?). The system functions should be mapped to the physical components. The mapping of functions to physical components can be one to one or many to one. But if one function is assigned to two or more physical components, then a mistake might have been made and it should be investigated. One valid reason for assigning a function to more than one component would be that the function is preformed by one component in a certain mode and by another component in another mode. Another would be deliberate redundancy to enhance reliability, allowing one portion of the system to take on a function if another portion fails to do so. Assess performance Figures of merit, technical performance measures and metrics are all used to assess performance. Figures of merit are used to quantify requirements in the tradeoff studies. They usually focus on the product. Technical performance measures are used to mitigate risk during design and manufacturing. Metrics (including customer satisfaction comments, productivity, number of problem reports, or whatever you feel is critical to your business) are used to help manage a company's processes. Measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it. Important resources such as weight, volume, price, communications bandwidth and power consumption should be managed. Each subsystem is allocated a portion of the total budget and the project manger is allocated a reserve. These resource budgets are managed throughout the system life cycle. Re-evaluate Re-evaluate is arguably the most important of these functions. For a century, engineers have used feedback to help control systems and improve performance. It is one of the most fundamental engineering tools. Re-evaluation should be a continual process with many parallel loops. Re-evaluate means observing outputs and using this information to modify the system, the inputs, the product or the process. Figure 1 summarizes the Systems Engineering Process. This figure clearly shows the distributed nature of the Re-evaluate function in the feedback loops. However, all of these loops will not always be used. The particular loops that are used depend on the particular problem being solved. Variations Like all processes, the Systems Engineering process at any company should be documented, measurable, stable, of low variability, used the same way by all, adaptive, and tailorable! This may seem like a contradiction. And perhaps it is. But one size does not fit all. The above description of the Systems Engineering process is just one of many that have been proposed. Some are bigger, some are smaller. But most are similar to this one.