Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The knowledge areas are:
• Life Cycle Models
• Concept Definition
• System Definition
• System Realization
• System Deployment and Use
• Systems Engineering Management
• Product and Service Life Management
• Systems Engineering Standards
Systems Engineering Definition
There is not community consensus on a single definition for "systems engineering"; the term has different connotations in different domains. However, one of the more commonly recognized definitions in the field is that of the International Council on Systems Engineering (INCOSE): An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:
• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal
Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE 2012)
Process
A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations. Processes can be performed by humans or machines transforming inputs into outputs. In SEBoK processes are interpreted in several ways, including: technical, lifecycle, business, or manufacturing flow processes. Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, Life Cycle Models applies the concept at the high level of a program lifecycle sequence (e.g. rational unified process (RUP), Vee model, etc.).
Architecture
An architecture refers to the the organizational structure of a system, whereby the system can be defined in different contexts. Architecting is the art or practice of designing the structures. Architectures can apply for a system, product, enterprise, or service.
Frameworks are closely related to architectures, as they are ways of representing architectures. The terms Architecture Framework and Architectural Framework both refer to the same. Examples include: DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.
Requirement
A requirement is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints. Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time. System Definition has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement). It discusses how different process roles/ states, levels, and the nature of requirements apply to the understanding of requirements.
Life Cycle Models
The life cycle model is one of the key concepts involved in systems engineering (SE). A life cycle (glossary) for a system (glossary) generally consists of a series of stages (glossary) regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.
A Generic System Life Cycle Model
A life cycle model for a system identifies the major stages that the system goes through, from its inception to its retirement. The stages are culminated by decision gates, at which point the key stakeholders decide whether to proceed into the next stage, remain in the current stage, or terminate or re-scope related projects. Its inception begins with a set of stakeholders agreeing to the need for a system and exploring whether a new system can be developed, in which the life cycle benefits are worth the investments in the life cycle costs.
To be successful, most organizations must adapt to the need for “Competing on Internet Time” (Cusumano and Yoffee 1998), subsequently causing a need for rapid adaptation to unforeseen changes. This has caused many organizations to emphasize evolutionary development with emergent requirements as compared to a traditional development with a fixed set of requirements. Yet, there are still significant areas in which development driven by fixed requirements is appropriate.
The System Definition Stage begins with a decision by a protagonist individual or organization to invest resources in a new or improved system. It’s normally concurrent activities include: determining the system’s key stakeholders and their desired capabilities, developing the system’s concept of operations and business case, negotiating the system’s requirements among the key stakeholders, selecting the system’s non-developmental items (NDIs), developing the system’s architecture and systems-level life cycle plans, and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. There may be one or more intermediate decision gates within the definition stage. The transition into the system development stage can lead to either single-pass or multiple-pass development.
It should be noted that the system definition activities above constitute the major portion of the activities performed by systems engineers when performing systems engineering. Other activities include: prototyping or actual development of high-risk items to show evidence of system feasibility, collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into development, and continuous improvement of the systems engineering process.