Lead Authors: Alan Faisandier, Ray Madachy, Contributing Author: Rick Adcock Show
System analysis allows developers to objectively carry out quantitative assessments of systems in order to select and/or update the most efficient system architecture and to generate derived engineering data. During engineering, assessments should be performed every time technical choices or decisions are made to determine compliance with system requirements. System analysis provides a rigorous approach to technical decision-making. It is used to perform trade-off studies, and includes modeling and simulation, cost analysis, technical risks analysis, and effectiveness analysis. Principles Governing System AnalysisOne of the major tasks of a systems engineer is to evaluate the engineering data and artifacts created during the systems engineering (SE) process. The evaluations are at the center of system analysis, providing means and techniques:
The Analysis and Selection between Alternative Solutions article in the Systems Approach Applied to Engineered Systems knowledge area (KA) of Part 2 describes activities related to selecting between possible system solutions to an identified problem or opportunity. The following general principles of systems analysis are defined:
Trade-Off StudiesIn the context of the definition of a system, a trade-off study consists of comparing the characteristics of each system element and of each candidate system architecture to determine the solution that best globally balances the assessment criteria. The various characteristics analyzed are gathered in cost analysis, technical risks analysis, and effectiveness analysis (NASA 2007). Guidance on the conduct of trade studies for all types of system context are characterized in the above principles and described in more detail in the Analysis and Selection between Alternative Solutions topic. Of particular interest to SE analysis are technical effectiveness, cost, and technical risk analysis. Effectiveness AnalysisThe effectiveness of an engineered system solution includes several essential characteristics that are generally gathered in the following list of analyses, including (but not limited to): performance, usability, dependability, manufacturing, maintenance or support, environment, etc. These analyses highlight candidate solutions under various aspects. It is essential to establish a classification that limits the number of analyses to the really significant aspects, such as key performance parameters. The main difficulties of effectiveness analysis are to sort and select the right set of effectiveness aspects; for example, if the product is made for a single use, maintainability will not be a relevant criterion. Cost AnalysisA cost analysis considers the full life cycle costs. A cost baseline can be adapted according to the project and the system. The global life cycle cost (LCC), or total ownership cost (TOC), may include exemplary labor and non-labor cost items such as those indicated in Table 1.
Methods for determining cost are described in the Planning topic. Technical Risks AnalysisEvery risk analysis concerning every domain is based on three factors:
The technical risks appear when the system cannot satisfy the system requirements any longer. The causes reside in the requirements and/or in the solution itself. They are expressed in the form of insufficient effectiveness and can have multiple causes: incorrect assessment of technological capabilities; over-estimation of the technical maturity of a system element; failure of parts; breakdowns; breakage, obsolescence of equipment, parts, or software, weakness from the supplier (non-compliant parts, delay for supply, etc.), human factors (insufficient training, wrong tunings, error handling, unsuited procedures, malice), etc. Technical risks are not to be confused with project risks, even if the method to manage them is the same. Although technical risks may lead to project risks, technical risks address the system itself, not the process for its development. (See Risk Management for more details.) Process ApproachPurpose and Principles of the ApproachThe system analysis process is used to: (1) provide a rigorous basis for technical decision making, resolution of requirement conflicts, and assessment of alternative physical solutions (system elements and physical architectures); (2) determine progress in satisfying system requirements and derived requirements; (3) support risk management; and (4) ensure that decisions are made only after evaluating the cost, schedule, performance, and risk effects on the engineering or re-engineering of a system (ANSI/EIA 1998). This process is also called the decision analysis process by NASA (2007, 1-360) and is used to help evaluate technical issues, alternatives, and their uncertainties to support decision-making. (See Decision Management for more details.) System analysis supports other system definition processes:
Like any system definition process, the system analysis process is iterative. Each operation is carried out several times; each step improves the precision of analysis. Activities of the ProcessMajor activities and tasks performed within this process include:
Artifacts and Ontology ElementsThis process may create several artifacts, such as:
This process handles the ontology elements of Table 2 within system analysis.
Checking Correctness of System AnalysisThe main items to be checked within system analysis in order to get validated arguments are:
See Ring, Eisner, and Maier (2010) for additional perspective. Methods and Modeling Techniques
Often used analytical models in the context of system analysis are summarized in Table 3.
Practical ConsiderationsKey pitfalls and good practices related to system analysis are described in the next two sections. PitfallsSome of the key pitfalls encountered in planning and performing system analysis are provided in Table 4.
Proven PracticesSome proven practices gathered from the references are provided in Table 5.
ReferencesWorks CitedANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998. NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105. Ring, J, H. Eisner, and M. Maier. 2010. "Key Issues of Systems Engineering, Part 3: Proving Your Design." INCOSE Insight 13(2). Primary ReferencesANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. Blanchard, B.S., and W.J. Fabrycky. 2010. Systems Engineering and Analysis, 5th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall. NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105. Additional ReferencesRing, J, H. Eisner, and M. Maier. 2010. "Key Issues of Systems Engineering, Part 3: Proving Your Design." INCOSE Insight. vol. 13, no. 2. < Previous Article | Parent Article | Next Article > SEBoK v. 2.6, released 20 May 2022 |