G2 SEBo K
G2 SEBo K
G2 SEBo K
Communities of Practice Local Chapters Working Groups Interest Groups Forums & Chats
What is/isnt the G2SEBoK Guide? What is unique about the G2SEBoK? When is the G2SEBoK useful? Doesnt this knowledge already exist?
Systems Engineering Primer on Systems Engineering Activities Important Concepts of Systems Engineering
Key References
Systems Engineering
Systems Engineering is a holistic, product oriented engineering discipline whose responsibility is to create and execute an interdisciplinary process to ensure that customer and stakeholder needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a systems life cycle.
Science determines what IS Component engineering determines what CAN BE Systems engineering determines what SHOULD BE.
Project Management ensures that the trains run on time Systems Engineering ensures that the trains run at all.
Key References
Key References
Key References
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Variations
Key References
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Investigate Alternatives
Alternative solutions are created and are evaluated based on performance, schedule, and cost figures of merit. No single solution is likely to be the best across all the figures of merit. Multicriteria decision-aiding techniques are available to help discover the preferred alternatives. This analysis should be repeated, as better data becomes available. For example, figures of merit should be computed initially based on estimates by the engineering design team. As the project evolves, models should be constructed and evaluated; simulation data should be collected and analyzed, 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.
Customer Needs
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
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 to facilitate the movement of physical items, information and energy. Subsystems should be defined along natural boundaries. Subsystems should be defined to minimize the amount of information, physical items and energy to be exchanged between the subsystems via interfaces. 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. Typical products produced by the systems engineering process are a mission statement, a requirements document including verification and validation methods, a description of functions and objects, figures or 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.
Customer Needs
Statethe the State Problem Problem Investigate Investigate Alternatives Alternatives Model the Model System System
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Customer Needs
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Assess Performance
Figures of merit, technical performance measures and metrics are all used to measure 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 monitor system performance during the design, development and manufacturing. Metrics (including customer satisfaction comments, productivity, number of problem reports, or whatever one believes is critical to a ventures success) are used to help manage organization processes. Measurement is the key. If you cannot measure it, you cannot tell success from failure and therefore 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.
Customer Needs
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Re-evaluate
Re-evaluate is arguably the most important of these functions. Since the first systems developed by the ancient engineers in Egypt, Greece and Rome, improved designs have been the result of feeding back what was learned in testing and using previously developed systems. Feedback 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. The Systems Engineering process illustrated in Figure 1 clearly shows the distributed nature of the re-evaluate function in the feedback loops. It is not necessary for all these loops be used. The actual loops used are unique to the particular problem being solved.
Customer Needs
Integrate Integrate
Output
Re-evaluate
Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate Re-evaluate
Re-evaluate
Key References
Variations
Like all processes, good engineering practice dictates that the Systems Engineering processes implemented by an organization should be documented, measurable, stable, of low variability, used consistently throughout an organization, 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 one of many that have been formulated. Some are more complex and some are simpler. But all contain elements of the process discussed above.
Key References
Purpose
has a
End Product
operates in
External Systems
performs interacts with via items
operates in
must be based on
Operational Environment
required for
System
built from
has a
Life Cycle
performs
Stakeholders Expectations
defined In terms of
focuses on focuses on
Enabling Products
Function
performs receives, transforms, sends
Systems Engineering
is a
Components
performs carries
Cost, Schedule, Performance
balances
performed by a
Item
is a is a
Interface
is a
Physical Entity
Energy
Information Entity
Key References
Key References:
SE Fundamentals
Key References
Reviews
System Implementation System Requirements Defintion System Design Preliminary Design Detailed Design System Integration and Test System Installation and Acceptance System Operations And Maintenance
Baselines
Allocated Baseline
Development Baseline
Product Baseline
Operational Baseline
Key References
Detailed Design:
Right of Way Plans Final Construction Plans
Surveying Design Analyses Aerial Mapping Environment Photogrammetry Cultural Terrain Modeling Resource Economic Drainage Traffic Community Impact Displacement
Horizontal Right-of-Way Plans Interchanges Property ID At-Grade Easements Connects Access Traffic Flow Acquisition Restrictions Hearings Vertical Taking Maximum Final Construction Grades Plans Sight Distances Maintenance Truck Lines Drainage Cross-Section Structures Roadway Width Grading Shoulder Width Earthwork Slope Limits Pavement Pavement Estimates Template
Key References
Key References
Time and Baseline Maturity
In-Process Validation
Planned Verification
Time Now
Off-Core Opportunity & Risk Management Investigations and Actions
How are the opportunities and risks of the proposed baselines being resolved?
Key References
Baseline Validation
Is the right solution being built?
Baselines to be Verified
Baseline Verification
Is the solution being built right?
Baselines Verified
Time Now
Time and Baseline Maturity Off-Core Verification Problem Investigation and Resolution
Is the problem cause understood?
Key References
The processes selected for this model are those associated with EIA632 and the Integrated Capability Maturity Model (CMMI). One purpose for selecting these systems engineering processes is to use those most recognized as the core processes for most systems engineering projects. A second purpose is to identify other systems engineering processes used on many projects, but are not recognized as common enough to be included in formal standards.
This model defines eight high-level activities, each of which is composed of two to eight lower level activities. These high level activities span the front end marketing and business capture to operations and maintenance portion of the life cycle.
Close Technical Effort
Project Management Plan Technical Effort Initiate Technical Effort Monitor and Control Technical Effort
Program Office Support/Systems Integration Track Action Items Manage Configurations Manage Risks Ensure Quality Manage Schedules Manage Performance Manage Data Integrate Disciplines
Requirements and Architecture Development Understand Customer Needs Define System-Level Requirements Assess and Select Solutions
Verify System
Time generally starts at the top and proceeds to the bottom. However the dual up and down Analyze and Evolve arrows between Project Management and Synthesize Detailed Code Allocate System Design Design and Test Program Office Support/Systems Integration, Requirements Architectures as well as Program Office Support/Systems Integration and each of Requirements and Architecture Development, Product Design and Development, and Systems Integration and Test indicate that time is not strictly moving down. The presence of these dual arrows indicates that information and physical items can move in both directions between lower level functions of the associated high level activities. Within some of the boxes associated the high-level activities there are arrows that move generally from left to right; in these cases time does move from left to right and the intention is to have the lower level activities proceed serially. The remaining high-level activities do not have arrows between lower level functions inside the box. In these cases all of the lower level functions can proceed concurrently due to the complex and iterative nature of the systems engineering process.
Validate System
Deployment and Transition Plan Deployment Train and Demonstrate System Transition to Operations
Key References
Know What the Customer Wants Know What the Customer Wants and How the System Must Perform and How the System Must Perform) (Requirements Analysis and Baselining
(Requirements Analysis and
Program Rules, Orders, Requirements Regulations,
Standards
Baselining )
Technical Requirements
(Systems Engineering Mission Analysis,Planning, Mission Baseline Management &Analysis, Change Control, Baseline Management & Change Control, Decision Criteria Development Decision Criteria Development System Integration & Interface Control) System Integration & Interface Control)
Plan and Integrate Plan and Integrate Your Work Work (Systems Your Engineering Planning,
Determine Desired Functionality Determine Desired Functionality to Meet Customer Needs to Meet Customer Needs (Functional Analysis and Decomposition)
Functional Hierarchy Functional System Architecture
Systems Engineering supports programs and projects by performing the following activities): defining and managing system requirements, identifying and minimizing risk, integrating system components (physical and organizational), managing system complexity, enhancing communication and system understanding, conducting trade studies as a basis for informed decision making, verifying that products and services meet customer needs.
Study Various Options and Study Various Options and Determine a Preferred Solution Determine a Preferred (Alternatives Analysis & System Solution Synthesis)
Parametric Data Ranked Decision Criteria
Analytical Data
Know What the Customer Wants Know What the Customer Wants and How the System Must Perform and How the System Must Perform) (Requirements Analysis and Baselining
(Requirements Analysis and
Program Rules, Orders, Requirements Regulations,
Standards
Baselining )
Technical Requirements
These five planning and integrating efforts are different from the four main functions in that they are typically done by systems engineering practitioners acting on the team-based input from the previous step. While many cycles of the SE process typically occur during the course of a project, each cycle covers the same basic steps only with different levels of emphasis and rigor.
Verification Matrix
Customer Needs/Expectations List System Requirements Documents System Requirements List (with Customer Approval) Top-level Functional Architecture Alternatives Designs (e.g., sketches, designs, etc.) Decision Criteria (System has to ... list with measurable units) Concept Matrix (Decision Criteria vs . Alternatives) Decision Criteria
System Engineering Management Plan (SEMP) Document Control Log Customer Requirements and
Test Plans
assess specific program and customer needs and expectations through interaction and facilitation of groups meetings and discussions Systems Engineers at the Idaho National Engineering and Environmental Lab to perform the following roles in support of implement an appropriate graded SE approach to meeting program and customer needs identify and manage system requirements, including the use of requirements management tools identify and develop system alternatives analyze system alternatives to ensure program requirements are met, including evaluating system risk, cost, and other performance measures using computer simulation models and other techniques
perform the following roles in support of Lockheed Martin Idaho Technologies Company and U.S. Department of Energy programs and projects:
System Performance Measures Initial Program and Technical Interface Requirements Formalized Functional Hierarchy Detailed Alternative Concepts
System Functional Architecture Technical, Cost Baselines Trade Studies/Analysis Plans and Results System Baselines Revisions
provide what-if scenario modeling for sensitivity analysis of changes in program requirements and/or system variables document and validate analysis results
(Systems Engineering Mission Analysis,Planning, Mission Baseline Management &Analysis, Change Control, Baseline Management & Change Control, Decision Criteria Development Decision Criteria Development System Integration & Interface Control) System Integration & Interface Control)
Plan and Integrate Plan and Integrate Your Work Work (Systems Your Engineering Planning,
Determine Desired Functionality Determine Desired Functionality to Meet Customer Needs to Meet Customer Needs (Functional Analysis and Decomposition)
Functional Hierarchy Functional System Architecture
Study Various Options and Study Various Options and Determine a Preferred Solution Determine a Preferred (Alternatives Analysis & System Solution Synthesis)
Parametric Data Ranked Decision Criteria
Analytical Data
This process typically creates the following products: Systems Engineering Management Plan, risk mitigation, configuration management, and verification plans; mission and customer needs statements; system requirement, description, and specification documents; Technical Performance Metrics and progress towards them; Functional Flow Block Diagrams, N2 charts, functional hierarchies, system physical architecture(s); system alternatives, trade study results, and preferred solution(s); cost, schedule, and technical baselines; interface/integration control agreements and Interface Control Documents; and verification matrices/verification discrepancies.
Key References
Acquisition Request
Requirements Definition Process Solution Definition Process Designs Product Realization Implementation Process Transition to Use Process Products Technical Evaluation Systems Analysis Process Requirements Validation Process System Verification Process End Products Validation Process
System Products
Key References
More Detail
Acquisition Request
Requirements Definition Process Solution Definition Process Designs Product Realization Implementation Process Transition to Use Process Products Technical Evaluation
System Products
This process shown to the right is for the system level. The basic steps listed above are focused in the System Design process block. It is iterated at lower levels to produce hardware, software, and service implementation requirements. The process involves a Requirements Definition Process that establishes both performance (quantified) requirements and functional area (architecture) requirements, and a Solution Definition Process that translates those requirements into design and operations concepts solutions. Overarching Technical Management Processes and Technical Evaluation Processes are performed continuously throughout the development processes. A clear understanding of the difference between defining what must be done and how well it must be done is mandatory for effective systems engineering. Unless requirements are expressed in measurable terms, it is difficult to determine when a job is done or when a product is acceptable. Also, a requirement is not effective unless it can be verified. The systems engineering process is used iteratively at each phase of the development cycle to generate more detailed descriptions of the system under development. These descriptions constitute the Decision Database. The database includes what needs to be achieved (functional requirements), how well it must be achieved (performance requirements), how it is to be achieved (design and operation concepts), and analysis or test results of the latters capability to actually satisfy requirements (verification). The hardware engineers traditionally developed physical views of the systems, while software engineers traditionally provided functional views of their code. Systems engineers must be able to assist hardware engineers to appreciate the power of functional views, and assist software engineers to link physical descriptions to their functional processing. The keys to effective systems engineering are to effectively communicate a "shared vision" of the systems being developed and avoidance of omissions or confusion that often result from a lack of integration.
Systems Analysis Process
Key References
Key References:
SE Processes
SE Competency Areas
1. Requirements Analysis and Management How to generate, deploy and manage mission, originating, system, and subsystem level requirements. 2. Decision Analysis Simulation, optimization and decision-making techniques to support the evaluation and selection of alternative system architectures. 3. Systems Engineering Understanding and application of basic phases of system development and how those phases interface with the project management process and the system life-cycle. 4. Risk Management Methodologies to identify, assess, and mitigate system and process risks. 5. Modeling Tools that support the development of the functional, operational, physical, and interface architectures of systems. 6. Human Factors Understanding requirements for human-system and human-human interfaces. 7. Engineering Management Understanding the technical, administrative, budget and scheduling aspects of effective project management in conjunction with the development of the people aspect of system development. 8. Discipline Oriented Skills Development of domain specific skill sets in related technical and managerial disciplines. 9. Service Skills to provide mentoring, research, teaching, and service to the discipline. 1] List was developed from Training Technologys Maestros, by Beth Panitz, in the November 1997 issue of ASEE Prism, pp. 18-24.
SE Competency Levels
Knowledge: Knowledge consists of the facts, conventions, definitions, methodologies, procedures and technical terms that define the field of systems engineering. An SE must be fluent in systems engineering knowledge, although knowledge by itself is not sufficient for problem solving. An example of SE knowledge is being able to list the stages of a system's life cycle. Comprehension: Comprehension is the ability to understand the meaning of knowledge. An SE must be able to take knowledge, understand it, and communicate it to others. An example of SE comprehension is the ability to compare and contrast the product development processes between to different organizations. Application: Application is the ability to apply knowledge and comprehension to solve specific problems. An SE must be able to solve real world engineering problems. An example of systems engineering knowledge is determining schedule, cost and risk variances of an actual project's performance versus planned performance. Analysis: Analysis is the ability to decompose a complex problem into its component parts, and then solve each of the parts. A key SE skill is the ability to support the analysis of specific subsystems, components and parts. An example of a SE analysis would be to evaluate the energy usage for the components of a specific subsystem to determine if the overall subsystem meets total power consumption requirements. Synthesis: Synthesis is the ability to take individual pieces and combine them into a new solution. This is a key component of engineering in general and SE specifically. An example of SE synthesis is the ability to conduct system-level trade studies to evaluate the insertion of alternative components into an existing system architecture. Evaluation: The highest level of SE cognitive development is the ability to evaluate and provide a judgment about a proposed solution, process, design, or analysis. The evaluation is comprehensive. At a minimum it looks at the logic, accuracy, presentation, documentation and logic of the proposal. An example of an SE evaluation is to serve as a member of an independent review team assessing a proposed system design.
Scope of Capability
Processes: The processes are necessary in that they define what has to be done to convert customer requirements into system products that satisfy the customer and the other interested parties. These processes are selected as applicable to the organizations business. By themselves processes are not sufficient, however. Processes are applied within a given organizational context to include the concepts of systems engineering adopted by the organization and the common methods and tools adopted to perform process activities and tasks. Context: A uniform understanding of basic systems engineering concepts facilitate enhanced organizationwide communications though use of a set of common terminology. Important concepts include: How the organization looks at the system to be engineered. Also the products that enable the operational products to perform within the various stages of the system life cycle. Life cycle service functions -- enabling systems. How the organization looks at the role of systems engineering within the life cycle model used by the organization to guide a system through its service life. Thus systems engineering capability includes not only engineering the right system but also creating the information required to make appropriate life cycle management decisions with respect to the system. Workforce: Two attributes of the workforce help determine the systems engineering capability of an organization-Knowledge and skills. The workforce requires the domain knowledge essential to the system being engineered and also knowledge of the processes to be used for systems engineering, understanding of the concepts adopted by the organization, and knowledge of project management. The individuals within the workforce also need the special skills required to perform systems engineering processes; use the common methods and tools applicable to their assigned work; and work in an integrated, multi-disciplinary team environment.
Context
Context: A uniform understanding of basic systems engineering concepts facilitate enhanced organizationwide communications though use of a set of common terminology. One important concept that needs to be defined is how the organization looks at the system to be engineered. One system definition has a focus on the products that will perform the operational functions. This system concept is called the system-of-interest in ISO/IEC 15288. Another system definition defines the system to consist of not only the products that perform the operational functions but also the products that enable the operational products to perform within the various stages of the system life cycle. This system concept is defined in ANSI/EIA 632 calls the products that perform operational functions end products and those that perform life cycle service functions as enabling products. ISO/IEC 15288 includes consideration of the life cycle service functions and calls the products as enabling systems. ISO/IEC 15288 has only a loose connection between systems-of-interest and enabling systems whereas ANSI/EIA 632 has a strong system project link between end products and enabling products. The organizations concept of the system will influence the scope of a projects concern with respect to engineering a solution to a customers problem that provides life cycle satisfaction to the customer and also considers the interest of other parties involved in that life cycle. This leads to the second important concept that needs to be defined by an organization. This concept is how the organization looks at the role of systems engineering within the life cycle model used by the organization to guide a system through its service life. Such a model has early exploratory phases such a pre-concept definition and/or concept definition to study technologies and feasible concepts and later an execution phase in which the system is designed; pre-production models created and proofed; products produced, utilized and supported; and then retired. Typically organizations have gates within a life cycle model that are used to determine whether a system is continued to the next service life phase, terminated or retired, or redirected (through appropriate improvements). To provide management with the information to make decisions at each gate the system has to be appropriately engineered to create the needed information to meet decision gate criteria.
Communities of Practice
Reference Works
INCOSE Membership
Related Resources