Technical Processes
ISO/IEC/IEEE 15288 defines 14 technical processes that are used concurrently, iteratively, and recursively throughout the system life cycle. These processes define the requirements of the system, translate them into an effective product, enable consistent reproduction of the product where necessary, use the product, provide the required service, sustain that service, and ensure that the product is put into service. This is necessary to process when you are evicted.
Technical processes help systems engineering (SE) practitioners coordinate interactions among engineering professionals, other engineering disciplines, purchasers, operators, manufacturing/production, and other system stakeholders. It also covers compliance with societal expectations and legal requirements. This process leads to the creation of a system solution that meets the necessary and sufficient requirements and required capabilities.
Although technical processes appear to be linearly transformed, in reality they are performed concurrently, iteratively, and recursively as the project team moves down the hierarchy of the system architecture. After each conversion, the Verification process verifies that the output artifact has been converted correctly against system requirements, and the Validation process verifies that it is the correct artifact that meets the needs and demands of stakeholders.
After an SoI is deployed, post-deployment validation is performed to ensure that it continues to meet real-world stakeholder expectations, and post-deployment validation is performed to ensure that it continues to meet requirements over time.
4-1 Business or Mission Analysis Process
The purpose of the business or mission analysis process, as specified in ISO/IEC/IEEE 15288, is to define a strategic problem or opportunity, characterize the solution area, and determine classes of potential solutions that can solve the problem or exploit the opportunity.
This process begins the life cycle of the system by defining the problem or opportunity space. It also defines the mission, business, and operational problem or opportunity, identifies key stakeholders, characterizes the solution area through environmental conditions and business constraints, identifies and prioritizes business requirements, and provides critical business success indicators. Define .
Based on this information, an initial life cycle concept (operations, acquisition, deployment, support, decommissioning, etc.) is developed from the organization’s perspective, and alternative solution classes are evaluated to select the preferred solution class. This process is an essential step in deriving an effective solution and plays an important role in establishing the direction of the project.
- IPO
4-2 Stakeholder Needs and Requirements Definition Process
According to ISO/IEC/IEEE 15288, the purpose of the Stakeholder Needs and Requirements Definition process is to determine the needs and requirements of stakeholders for a system that can provide the capabilities that users and other stakeholders require in a defined environment. It’s about defining it. A successful project relies on meeting the actual expectations of stakeholders throughout the system life cycle.
This process elicits stakeholder needs, clarifies operational cases, scenarios and life cycle concepts, and assesses development risks. Stakeholder needs are analyzed and translated into stakeholder requirements for the system, which play an important role in defining the scope of development and constraining the required solution space. Additionally, this course provides the basis for specifying technical details when an organization acquires a system.
- IPO
4-3 System Requirements Definition Process
According to the ISO/IEC/IEEE 15288 standard, the purpose of the system requirements definition process is to translate stakeholder needs and user-centric functional requirements into technical solutions to meet users’ operational needs.
System requirements are the basis for system definition and serve as the basis for system architecture definition, design definition, integration, and verification processes. Since each requirement carries a cost, the minimum necessary but sufficient system requirements must be established. If requirements have significant uncertainty, that uncertainty must be managed until the requirements mature.
This process generates system requirements from a technical perspective, which reflect the needs and requirements of stakeholders. The system requirements definition process is iterative and recursive and occurs concurrently with other technical processes, especially the stakeholder needs and requirements definition process and the system architecture definition process.
With each iteration, more detailed information is discovered and defined based on the analysis and maturation of life cycle concepts and system solutions. Additionally, this process is applied recursively to define the requirements for each subsystem element within the SoI architecture. The output of the system requirements definition process should be consistent and traceable to life cycle concepts and stakeholder needs and requirements, and should not introduce unnecessary implementation bias.
- IPO
4-4 System Architecture Definition Process
The purpose of the system architecture definition process specified in ISO/IEC/IEEE 15288 is to generate a variety of system architecture alternatives, select one or more alternatives that address stakeholder concerns and system requirements, and express them in a consistent view and model. It will. This process addresses relevant architectures (strategic, enterprise, reference, system-of-systems architecture, etc.), organizational and project policies and guidelines, life cycle concepts and constraints, stakeholder concerns and requirements, and system requirements. Translate basic concepts and properties into principles that govern the evolution of systems and related life cycle processes.
The system architecture definition process results in a system architecture description for use by the project, organization, other organizations, and various stakeholders. This process provides necessary and useful information for identifying and characterizing the basic concepts and properties of systems, which may be inherently human-centric in systems of human activity that consider technological elements as enabling assets.
Architectural information can be implemented through the design of systems and system elements, which can be aligned with stakeholder and system requirements (traceable to business/mission requirements where applicable) and life cycle concepts (e.g. operations, acquisition, deployment, support). , retirement) satisfies to the fullest extent the problem or opportunity expressed by it.
This process is iterative and requires the participation of architects, systems engineering practitioners, and experts in related fields. It continues recursively through each level of the system and system elements, with consistent feedback ensuring that the system design continues to meet stakeholder needs and system requirements.
- IPO
4-5 Design Definition Process
According to ISO/IEC/IEEE 15288, the purpose of the design definition process is to provide sufficiently detailed data and information about the system and its elements to enable a solution to be realized according to the system requirements and architecture. This process is driven by a more detailed analysis of requirements and feasibility, verified through architecture.
The design definition process translates the architecture and requirements into the design of a feasible system. This process results in sufficiently detailed data and information about the system and its elements to enable implementation consistent with the architectural entities defined in the architectural model and view of the system architecture.
It also conforms to applicable system requirements and is aligned with design guidelines and standards adopted by the organization or project. In this process, often system elements are identified, and their basic concepts and properties are characterized by the system architecture definition process. Design information and data define the expected properties and characteristics assigned to each system element and enable the transition toward their realization.
- IPO
4-6 System Analysis Process
According to the ISO/IEC/IEEE 15288 standard, the purpose of the systems analysis process is to provide the necessary data and information to support decision-making and technology evaluation throughout the life cycle. This course utilizes models and simulations to evaluate the usability and integrity of system requirements, architecture, and design.
A system model expresses system properties at various levels as quantitative and qualitative variables, thereby providing answers to four types of questions (descriptive, predictive, prescriptive, and definitional). Modeling approaches include MBSE, mathematical analysis, stochastic and statistical modeling, and simulation, which perform sensitivity analysis of variable values at all stages of the life cycle.
- IPO
If you are interested in other articles about ASEP PREP Series, please refer to the links below!
[ASEP-Prep] #1. What is System LIFE CYCLE?
[ASEP-Prep] #2. Agreement and Enabling Processes
[ASEP-Prep] #3. Technical Management Processes
[ASEP-Prep] #5. Technical Processes – System Realization, Deploy and Use
[ASEP-Prep] #6. Quality Characteristics