A System Requirements Analysis Method Based on System Scenario

Abstract

This invention discloses a system requirements analysis method based on system scenarios, including: task scenario analysis; scenario operation description; establishing a system capability network; and system function partitioning and requirements analysis. The task scenario analysis includes selecting an initial scenario, clarifying scenario roles, and determining high-level scenario concepts. The scenario operation description includes descriptions of scenario operation activities, scenario operation sequence, and role status. Establishing the system capability network includes selecting a capability framework, activity-capability mapping, and capability relationship description. System function partitioning and requirements analysis includes system function description, system function analysis, and function-requirement mapping. This invention provides a good solution for system requirements demonstration using scenarios as input in engineering applications, solving the problem of difficulties in promoting requirements demonstration for complex systems and the lack of a scenario-based system requirements analysis methodology in existing technologies.

Description

Technical Field

[0001] This invention relates to a process and method for conducting system requirements analysis in the early stages of system development in model-based system engineering and system engineering, belonging to the field of systems engineering, and specifically to a system requirements analysis method based on system scenarios. Background Technology

[0002] With the increasing complexity of application requirements and scenarios, and the continuous expansion of system architectures, the complexity and diversity of system needs are becoming more prominent than ever before. During system design, designers often face the influence of external stakeholders and the interplay of multiple task requirements. To address this complex challenge, the design philosophy of systems engineering has emerged. Systems engineering systematically describes multiple systems and their interrelationships, taking a more macroscopic approach and conducting comprehensive analysis and design of systems from a task-oriented perspective. How to effectively utilize the scenario analysis concepts inherent in systems engineering and use them to guide the development of complex systems is a pressing issue that needs to be addressed in the fields of systems engineering and systems as a whole.

[0003] In the system development lifecycle, for novel systems, the effectiveness of the requirements validation process directly impacts the quality and efficiency of subsequent system development. A crucial step in the requirements validation phase is capturing and analyzing the effective system requirements for the system's operational scenarios. Successful implementation of this process enables targeted and efficient development of system requirements within specific task scenarios. Effective system requirements analysis not only lays a solid foundation for forward system design but also facilitates the simulation and verification of the system's digital twin prototype, shortening the development cycle and improving system reliability and adaptability. To quickly and effectively transform scenario analysis into system requirements, a scientific methodology is needed to guide this process.

[0004] In recent years, the construction of combat systems and the research and development of key combat systems have increasingly become an important part of national defense and military construction. In the development of some emerging combat equipment, unlike the traditional single-equipment design approach, the broader system environment upon which the equipment operates is often taken into consideration. A wider perspective is used to explore the basic requirements that the equipment needs to meet. Combat system design has gradually evolved from the operational dimension of a single combat domain or a single weapon system to a comprehensive, diversified, and broad system dimension. The demonstration system has shifted from the demonstration of individual equipment to a higher-level system demonstration. The combat system-based design method can shift the thinking of equipment design from the narrow perspective of a single piece of equipment to a broader perspective of the combat system. After the combat system is interpreted, a certain degree of understanding of the application scenarios and basic characteristics of the equipment is achieved. Then, the focus shifts to the individual equipment design or the capture of equipment requirements. This makes the process of capturing equipment requirements more complete and reliable, and the designed equipment more suitable for a specific scenario.

[0005] Against this backdrop, the DoDAF framework, as a standardized architecture tool, demonstrates its significant advantages in the development of complex systems. DoDAF can comprehensively represent the system's structure, capabilities, and role relationships within a scenario through multiple views, thus providing strong support for system construction and analysis. By applying the UPDM language to describe process views, multi-level expression and analysis from task scenarios to system requirements can be achieved. This approach provides effective theoretical and tool support for system construction and analysis, enabling a smoother process of requirements justification from task scenarios to system capabilities and then to system requirements, ultimately achieving the systematization and standardization of system requirements analysis.

[0006] Existing system modeling and MBSE modeling methods mainly belong to the forward modeling methodology. In general, the system requirements are relatively clear, and there is a lack of a requirement demonstration methodology that starts from the system operation scenario and conducts analysis on complex systems in the conceptual stage.

[0007] This invention proposes a step-by-step, clearly defined system requirements analysis method based on the DoDAF framework's basic view. It begins the analysis with the proposed task scenario, and then uses the DoDAF multi-view modeling concept to select some DoDAF viewpoints and related views to carry out modeling work. This completes the step-by-step construction and analysis of the task scenario, system capabilities, and system requirements, solving the problems of a lack of relevant methodological support in the task scenario input modeling process and an insufficiently comprehensive and standardized capability analysis process in the early stages of system demonstration. Summary of the Invention

[0008] To address the problems of poor effectiveness, difficulty in advancing the requirements demonstration process for complex systems, and lack of scenario-based system requirements analysis methodologies in existing technologies, this invention aims to provide a system requirements analysis method based on system scenarios. Utilizing the existing DoDAF system modeling framework and applying the standardization principles of systems engineering, the invention tailors existing DoDAF views, selecting commonly used views for scenario modeling and system requirements analysis. This determines a DoDAF system modeling method, enabling the standardized construction of system requirements analysis based on system scenarios. This method facilitates engineers in quickly completing system requirements analysis and proceeding to the next stage of system design.

[0009] To address the aforementioned technical problems and the objectives of this invention, a system requirements analysis method based on a system scenario is proposed, comprising the following parts:

[0010] Step A: Task scenario analysis, wherein the specific method of task scenario analysis is to analyze the running scenarios that play a key role in the system to be analyzed and the execution status of tasks that are of concern to the requirements analyst.

[0011] Step B: Scene operation description, wherein the specific method of the scene operation description is to analyze and describe the activities, timing and role status of the scene operation in the running scene;

[0012] Step C: Establish a system capability network. Specifically, the system capability network is established by taking the task scenario in Step A as the goal and, based on the scenario operation description formed in Step B, decomposing the operational scenario environment conditions required to achieve the goal into the capabilities that each scenario role should possess, and arranging the capabilities according to a certain ordered organizational structure to establish a system capability network.

[0013] Step D: System function division and requirements analysis. Specifically, the system function division and requirements analysis are carried out by: transforming the indicators implied by the system capabilities into the elements required for system development, dividing the functional components required to meet the system functions, and analyzing the system requirements that the system should meet based on the system functions.

[0014] Preferably, the task scenario analysis includes the following steps:

[0015] Step A1: Select an initial scenario. Specifically, the initial scenario selection process involves selecting a suitable actual system operation scenario based on task requirements and the needs of conceptual system design to conduct system requirements analysis.

[0016] Step A2: Define the scene roles. Specifically, the process of defining the scene roles is as follows: based on the initial scene selected in Step A1, use systems engineering principles to select the scene lifecycle boundary and define all participating roles within the selected scene.

[0017] Step A3: Determine the high-level concept of the scene. Specifically, the high-level concept of the scene is determined by describing the interaction relationships between the system and the external environment, and between the systems, based on the results of steps A1 and A2.

[0018] Preferably, the scenario operation description includes the following steps:

[0019] Step B1: Scene operation activity description, wherein the specific method of the scene operation activity description is as follows: based on the initial scene, scene roles and high-level scene concepts defined in steps A1-A3, analyze the scene operation activities of the system and external environment roles, and further analyze and describe the activities of important roles as needed below;

[0020] Step B2: Scene runtime sequence description, wherein the specific method of the scene runtime sequence description is as follows: based on the initial scene, scene roles and high-level scene concepts defined in steps A1-A3, and referring to the scene runtime activity description carried out in step B1, the scene runtime sequence of the system and external environment roles is analyzed.

[0021] Step B3: Role state description, wherein the specific method of the role state description is as follows: based on the initial scenario, scenario roles and high-level scenario concepts defined in steps A1-A3, and referring to the scenario operation activity description and scenario operation sequence description carried out in steps B1 and B2, the operation state of the system of concern is analyzed.

[0022] Preferably, the establishment of the system capability network includes the following steps:

[0023] Step C1: Capability framework selection, wherein the specific method for selecting the capability framework is as follows: based on the system capabilities and indicators of concern, select a top-level capability classification method of the system as a container to describe the system capability structure that encompasses all capabilities.

[0024] Step C2: Activity-Capability Mapping, wherein the specific method of the activity-capability mapping is as follows: based on the scene operation activity description formed in step B1, the system capabilities required to support the execution of a certain scene activity in the corresponding swimlane of the execution role are defined, and the support relationship between activities and capabilities is represented by a mapping matrix.

[0025] Step C3: Capability Relationship Description, wherein the specific method of capability relationship description is as follows: based on the system capabilities conceived from the activities in step C2 and the top-level system capabilities selected in step C1, all existing capability granularities are assigned to their related roles, and the hierarchical relationship and dependency relationship between capabilities are conceived and described, thereby forming a multi-view system capability network.

[0026] Preferably, the system function division and requirements analysis includes the following steps:

[0027] Step D1: System Function Description, wherein the specific method of the system function description is as follows: based on the system capabilities allocated to the system of concern in step C3, the support relationship between the system functional components and the system capabilities associated with the system of concern is mapped, and a system functional component description is formed;

[0028] Step D2: System function analysis, wherein the specific method of the system function analysis is as follows: based on the scene operation activity description determined in step B1 and the role status description determined in step B3, a system function activity diagram is established with functional components as role swimlanes, and the full life cycle function operation process of the system corresponding to the role in the scene is analyzed.

[0029] Step D3: Function-Requirement Mapping. Specifically, the function-requirement mapping is performed as follows: based on the system functional component description formed in Step D1 and the system functional analysis formed in Step D2, and according to the existing functional components of the system, the system requirements required to satisfy a certain function of the system are defined, and the support relationship between the system functional components and the defined system requirements is mapped, thereby completing the system requirement description.

[0030] Through the above steps, this method proposes a system requirements analysis approach based on system scenarios, addressing the difficulties in proving requirements for complex systems and the lack of a scenario-based system requirements analysis methodology in existing technologies. It completes system requirements analysis based on system scenarios from the perspectives of system engineers and architecture engineers. The modeling rules established by this method can be reused in the design of complex systems across multiple fields, providing a scenario-based framework for inputting requirements conditions for subsequent digital twin design and digital prototype simulation of the system.

[0031] The innovations of this system requirements analysis method based on system architecture scenarios are mainly reflected in the following aspects:

[0032] 1. Scenario-based requirements analysis: This method introduces scenario-based system requirements analysis, which belongs to the non-forward system engineering modeling approach. It flexibly selects known conditions and describes them around the task scenario, ensuring that the system requirements and capabilities analysis are closely integrated with the actual scenario, thereby improving the effectiveness and pertinence of requirements demonstration.

[0033] 2. Introducing DoDAF trimming for multi-view modeling to assist requirements analysis: The existing DoDAF modeling framework is trimmed based on requirements, and views related to scenario modeling and system requirements analysis are selected. This reduces unnecessary view construction in the forward system engineering and system engineering design process, while improving modeling efficiency by conducting requirements analysis of the system through effective multi-view perspectives.

[0034] 3. Combining System Engineering and Systems Engineering: By combining the concepts of system engineering and systems engineering, and through standardized processes and steps, the comprehensiveness and scientific nature of requirements analysis are ensured, providing a standardized and structured requirements analysis method.

[0035] In summary, this system requirements analysis method based on system scenarios provides a good solution for demonstrating system requirements in engineering applications with scenarios as input. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart of the method described in this invention. Detailed Implementation

[0038] The method of the present invention will be further described below with reference to the accompanying drawings and specific implementation examples. It should be understood that the implementation examples described herein are only for illustration and explanation of the present invention and are not limited to the present invention.

[0039] The purpose of this invention is to provide a system requirements analysis method based on system scenarios. Considering the difficulty in conducting capability analysis of key roles within a scenario based solely on scenario input, this invention, combined with the DoDAF view framework, first discusses the task effectiveness that scenario analysis and the system should possess. Then, it transforms the constructed scenario activities and system effectiveness into a system-specific analysis process. This ensures that the requirements demonstration process is interconnected, improving the effectiveness and relevance of the process demonstration while maintaining the speed and continuity of engineering analysis. It has significant practical application value.

[0040] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0041] This invention takes a close-range strike system as an example, focusing on a small glide bomb from a drone as the object of study, and illustrates the method of this invention. The requirements for close support and close-range strikes necessitate that drones employ suitable munitions to conduct close-range attacks on the enemy. Based on this requirement, researching low-cost, low-yield, precision-strike weapons from drones has become an urgent action for both sides in a conflict. Based on this mission requirement, it is now necessary to analyze the system scenario, thereby highlighting the key requirements for small glide bombs.

[0042] To achieve the above objectives, the technical solution adopted by the method of the present invention is as follows:

[0043] This invention provides a system requirements analysis method based on a system scenario, the process of which is as follows: Figure 1 As shown, the steps are as follows:

[0044] Step A: Task scenario analysis;

[0045] Step B: Scenario execution description;

[0046] Step C: Establish a system capability network;

[0047] Step D: System function division and requirements analysis.

[0048] Through the above steps, this method solves the problem of gradually advancing from scenario analysis and gradually extracting the system's relevant capabilities through task requirements. Furthermore, the modeling process based on the DoDAF framework used in this method is highly reusable, facilitating further development and implementation of subsequent model-based capability analysis, and has good practical application value.

[0049] The specific method for task scenario analysis in step A is as follows: Analyze the operational scenarios that play a key role in the system to be analyzed and that are of concern to the requirements analyst regarding task execution. The task scenario analysis in step A includes the following steps:

[0050] Step A1: Select the initial scene;

[0051] Step A2: Define the roles in the scene;

[0052] Step A3: Define the high-level concepts of the scene;

[0053] The specific steps for selecting the initial scenario in step A1 are as follows: Based on the task requirements and the need for conceptual design of the system, a suitable actual operating scenario of the system is selected to conduct system requirements analysis. In this step, the AV-1 view of the DoDAF2.0 view is used to carry out the description work.

[0054] Specifically, the process of defining the scenario roles in step A2 is as follows: Based on the initial scenario selected in step A1, the scenario lifecycle boundary is selected using systems engineering principles, and all participating roles within the selected scenario are defined.

[0055] The specific meaning of the high-level scenario concept mentioned in step A3 is as follows: The term "high-level scenario concept" is derived from the broad extension of the high-level combat concept in the DoDAF view. It is expressed in a way that combines graphics and text to highlight the interaction between the system and the external environment, and between systems in the scenario, providing a conceptual scenario for a large system architecture model involving multiple roles.

[0056] The specific steps for determining the high-level concepts of the scene in step A3 are as follows: Based on the results of steps A1 and A2, the interaction relationships between the system and the external environment, and between systems, contained in the scene are described. In this step, the OV-1 view of the DoDAF2.0 view can be used to carry out the description work.

[0057] Specifically, for step A, the initial scenario selected is a UAV close-range strike system. Based on the UAV close-range strike system, an AV-1 scenario overview view and an OV-1 scenario high-level operational concept diagram are established. In a specific implementation case, the detailed description of the view establishment is as follows:

[0058] The AV-1 overview view used will show the initial system scenario objectives, the elements included in the initial system scenario architecture, and the tasks of concern in the initial system scenario, so as to facilitate further analysis based on the system scenario in the following text. In the case, it is reflected as the tasks that the close-range strike system should accomplish and the architecture of the close-range strike system.

[0059] The OV-1 high-level conceptual view of the scene is used to depict the important interactions of the characters in the scene. While establishing the prototype of scene analysis, the OV-1 view analysis can clarify the information flow and the performance of the interactions of the characters of concern. In the case, this is reflected in the scene characters of the close-range combat system and the important interaction relationships between the characters.

[0060] The specific steps for describing the scene operation in step B are as follows: Analyzing and describing the activities, timing, and role states within the running scene. The scene operation description in step B includes the following steps:

[0061] Step B1: Description of the scenario execution activity;

[0062] Step B2: Scene runtime sequence description;

[0063] Step B3: Character Status Description;

[0064] The specific steps for describing the scene operation activities in step B1 are as follows: Based on the initial scene, scene roles, and high-level scene concepts defined in steps A1-A3, the scene operation activities of the system and external environment roles are analyzed, and the activities of important roles are further analyzed and described in detail as needed below. In this step, the description work can be carried out using the OV-5b view of the DoDAF2.0 view.

[0065] The specific steps for describing the scene runtime sequence in step B2 are as follows: Based on the initial scene, scene roles, and high-level scene concepts defined in steps A1-A3, and referring to the scene runtime activity description carried out in step B1, the scene runtime sequence of the system and external environment roles is analyzed. In this step, the description work can be carried out using the OV-6c view of the DoDAF2.0 view.

[0066] The specific steps for describing the role status in step B3 are as follows: Based on the initial scenario, scenario roles, and high-level scenario concepts defined in steps A1-A3, and referring to the scenario operation activity description and scenario operation sequence description carried out in steps B1 and B2, the operational status of the system of concern is analyzed. In this step, the SV-10b view of the DoDAF2.0 view can be used to carry out the description work.

[0067] Specifically, for step B, the detailed description of creating the view in a specific implementation example is as follows:

[0068] In the OV-5 runtime activity view used, based on the relevant view built in step A of the case, the runtime activities of the entire scene are analyzed, including the description of the high-level concepts of the scene and the activities of the role objects. In the case, this is reflected in the description of the entire process of the close-range strike system from the discovery of important enemy targets to the strike by unmanned aerial vehicles.

[0069] In the OV-6c runtime sequence view used, based on the relevant view constructed in step A of the case and the scene operation activity diagram constructed in step B1, the scene runtime sequence is further analyzed, including the description of the signal evolution and execution order of each role based on the scene runtime sequence. In the case, this is reflected in the time sequence description of the relevant roles in the entire process of the selected close-range strike system activity.

[0070] In the SV-6c role status view used, based on the relevant view constructed in case step A and the scenario operation activity diagram and scenario operation sequence diagram constructed in case steps B1 and B2, the system of concern to be captured capability is further analyzed, including the description of the execution status, state evolution strategy and state transition signal of the concern system. In the case, this is reflected in the state description of the concern system of the selected close-range strike system - the glide guided bomb system.

[0071] The specific method for establishing the system capability network in step C is as follows: taking the task scenario in step A as the goal, based on the scenario operation description formed in step B, the operational scenario environment conditions required to achieve the goal are decomposed into the capabilities that each scenario role should possess, and the capabilities are arranged according to a certain ordered organizational structure to establish the system capability network. The establishment of the system capability network in step C includes the following steps:

[0072] Step C1: Capability framework selection;

[0073] Step C2: Activity-Capability Mapping;

[0074] Step C3: Description of ability relationships;

[0075] The specific steps for selecting the capability framework mentioned in step C1 are as follows: Based on the system capabilities and indicators of concern, select a top-level capability classification method as a container to describe the system capability structure, which can be used to describe the system capability structure. In this step, the CV-1 view in the DoDAF2.0 view can be used to carry out the description work.

[0076] The activity-capability mapping described in step C2 is implemented as follows: Based on the scene operation activity description formed in step B1, the system capabilities required to support the execution of a certain scene activity in the corresponding swimlane of the execution role are defined, and the support relationship between activities and capabilities is represented by a mapping matrix. In this step, the CV-6 view in the DoDAF2.0 view can be used to carry out the description work.

[0077] The capability relationship mentioned in step C3 specifically means: the cross-linking relationship between system capabilities, including hierarchical relationships and dependency relationships;

[0078] The capability relationship description described in step C3 is specifically implemented as follows: Based on the system capabilities conceived from the activities in step C2 and the top-level system capabilities selected in step C1, all existing capability granularities are assigned to their related roles, and the hierarchical relationship and dependency relationship between capabilities are conceived and described, thereby forming a multi-view system capability network. In this step, the CV-2 and CV-4 views in the DoDAF2.0 view can be used to carry out the description work.

[0079] Specifically, for step C, the detailed description of creating the view in a specific implementation case is as follows:

[0080] In the CV-1 capability top-level view used, based on the relevant views constructed in steps A and B of the case study, a suitable top-level capability classification method is selected to facilitate capability allocation and hierarchical needs. There are many common system effectiveness or system top-level capability classification methods, such as the six-attribute capability classification method, the joint operations doctrine requirement classification method, and the US military C4ISR requirement classification method. In this case study, because it is necessary to reflect the relevant capabilities of close-range strike operations, the commonly used military framework C4ISR is selected as the basic system capability classification approach. The various capabilities that the close-range strike system needs to meet are divided into command, communication, reconnaissance, and combat capabilities, and assigned to their related roles as the top-level capability classification method.

[0081] In the CV-6 activity-capability mapping matrix view used, based on the scenario operation description view constructed in step B of the case study, and according to the capability top-level view established in step C1, the capabilities that important scenario operation activities need to meet are defined, mapped in the view, and the capabilities that the defined activities should meet are categorized according to the classification method of the scenario top-level capabilities. In the case study, based on the scenario operation description in step B, the allocation relationship between the included scenario activities and the capabilities that the activities should meet is defined, ultimately forming the CV-6 activity-capability mapping matrix view.

[0082] In the CV-2 capability classification view used, based on the scenario operation description view constructed in steps A and B of the case study, and according to the capability top-level view established in step C1 and the activity-capability mapping matrix view established in step C2, capabilities are further assigned to roles, supplementing the capability descriptions that each role needs to meet in the system, thereby establishing a hierarchical relationship description between capabilities. In the case study, based on the capability top-level view established in step C1 and the activity-capability mapping matrix view established in C2, a hierarchical relationship description view of the close-range strike system capabilities is formed.

[0083] The CV-4 capability dependency description view used, based on the scenario operation description related views constructed in steps A and B of the case studies, and the activity-capability mapping matrix view established in step C2, describes the capabilities that each activity needs to satisfy and the dependencies between capabilities. This serves as a supplementary view to the CV-2 capability classification view used, illustrating the interconnected relationships between system capabilities. In the case study, based on the activity-capability mapping matrix view established in C2 and referring to the close-range strike system activity diagram, the dependent capabilities of the system's concerned system capabilities are described. For example, for the target destruction capability in the system, this capability depends on the target guidance capability of satellites and guided bombs, the maneuverability of guided bombs, bomb payload capability, UAV maneuverability, and UAV payload capability. Attention can be paid to the dependent capabilities to improve the target destruction capability.

[0084] The specific steps of system function division and requirements analysis in step D are as follows: The indicators implied by the system capabilities are transformed into elements required for system development; the functional components required to satisfy the system functions are divided; and based on the system functions, the system requirements that the system should satisfy are analyzed. Step D, the system function division and requirements analysis, includes the following steps:

[0085] Step D1: System Function Description;

[0086] Step D2: System Function Analysis;

[0087] Step D3: Function-Requirement Mapping;

[0088] The system function description described in step D1 is specifically implemented as follows: Based on the system capabilities assigned to the system of concern in step C3, the support relationship between the system functional components and the system capabilities associated with the system of concern is mapped, and a description of the system's functional components is formed. In this step, the description work can be carried out with the help of the SV-4 view in the DoDAF2.0 view.

[0089] The system function analysis described in step D2 is specifically performed as follows: Based on the scene operation activity description determined in step B1 and the role status description determined in step B3, a system function activity diagram is established with functional components as role swimlanes. The full life cycle function operation process of the system corresponding to the role in the scene is analyzed. In this step, SysML activity diagrams can be used to carry out the description work.

[0090] The function-requirement mapping described in step D3 is implemented as follows: Based on the system functional component description formed in step D1 and the system function analysis formed in step D2, the system requirements required to satisfy a certain function of the system are defined according to the existing functional components of the system, and the support relationship between the system functional components and the defined system requirements is mapped. In this step, the CV-6 view in the DoDAF2.0 view can be used to carry out the description work, thereby completing the system requirement description.

[0091] Specifically, for step D, the detailed description of creating the view in a specific implementation case is as follows:

[0092] In the SV-4 system functional description view used, based on the system capability network constructed in step C of the case study, the system capabilities of concern to the system to be analyzed are extracted. Then, based on the system's unmet capabilities and actual design requirements, a system functional component description is formed. This completes the system functions and demonstrates the system capabilities that the concerned system can fulfill based on the functional components, thus forming the system functional description. In the case study, based on the close-range strike system capability network constructed in step C, and referring to the actual system composition of the glide-guided bomb, a functional component description of the glide-guided bomb system is formed. The relationships between the system's corresponding required capabilities and functions are assigned, illustrating the allocation relationship between functional components and system capabilities.

[0093] In the SysML activity diagram used, based on the scenario operation description view constructed in step B of the case study, and according to the system functional component description formed in step D1, the activities corresponding to the system swimlanes of the scenario operation activity description established in step B1 are assigned to the system functional components for further description. This shifts the perspective from system activity to internal system function, thereby achieving system function analysis. In the case study, the entire process of a guided bomb system in close-range strikes, from power-on to detonation, is redescribed from the perspective of internal system function, demonstrating the internal mechanism of the guided bomb system.

[0094] In the CV-6 activity-capability mapping matrix view used, based on the system function description view established in step D1 and the functional analysis results carried out in step D2, the system requirements that each functional component of the system should fulfill are hypothesized, and a system function-requirement mapping matrix view is completed. Through this view, the traceability relationship between system requirements and system functions is established. In this case, the system requirements on which the system functions depend are taken as the main capability segmentation perspective. Through the established guided bomb system function description and combined with the guided bomb system function analysis results, the requirements of the guided bomb system are analyzed.

[0095] Based on the above steps, the specific implementation of the system requirements analysis method based on system scenarios can be completed. It should be noted that the accompanying figures are only analysis examples involving a single scenario and a single complex system to be analyzed. When conducting system requirements analysis for multiple scenarios, it is necessary to construct various scenario operation descriptions for multiple scenarios in step B; when analyzing multiple complex systems to be analyzed, it is necessary to construct system requirements analysis descriptions for multiple systems in step D.

[0096] The above provides a detailed description of a system requirements analysis method based on a system scenario provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A system requirements analysis method based on system scenarios, characterized in that, The method includes the following steps: Step A: Task scenario analysis, wherein the specific method of task scenario analysis is to analyze the running scenarios that play a key role in the system to be analyzed and the execution status of tasks that are of concern to the requirements analyst. The task scenario analysis includes the following steps: Step A1: Select an initial scenario. Specifically, the initial scenario selection process involves selecting a suitable actual system operation scenario based on task requirements and the needs of conceptual system design to conduct system requirements analysis. Step A2: Define the scene roles. Specifically, the process of defining the scene roles is as follows: based on the initial scene selected in Step A1, use systems engineering principles to select the scene lifecycle boundary and define all participating roles within the selected scene. Step A3: Determine the high-level concepts of the scene. Specifically, the method for determining the high-level concepts of the scene is as follows: based on the assumptions of Step A1 and Step A2, describe the interaction relationships between the system and the external environment, and between systems in the scene. Step B: Scene operation description, wherein the specific method of the scene operation description is to analyze and describe the activities, timing and role status of the scene operation in the running scene; The scenario operation description includes the following steps: Step B1: Scene operation activity description, wherein the specific method of the scene operation activity description is as follows: based on the initial scene, scene roles and high-level scene concepts defined in steps A1-A3, analyze the scene operation activities of the system and external environment roles, and further analyze and describe the activities of important roles as needed below; Step B2: Scene runtime sequence description, wherein the specific method of the scene runtime sequence description is as follows: based on the initial scene, scene roles and high-level scene concepts defined in steps A1-A3, and referring to the scene runtime activity description carried out in step B1, the scene runtime sequence of the system and external environment roles is analyzed. Step B3: Role state description, wherein the specific method of the role state description is as follows: based on the initial scenario, scenario roles and high-level scenario concepts defined in steps A1-A3, and referring to the scenario operation activity description and scenario operation sequence description carried out in steps B1 and B2, the operation state of the system of concern is analyzed. Step C: Establish a system capability network. Specifically, the system capability network is established by taking the task scenario in Step A as the goal and, based on the scenario operation description formed in Step B, decomposing the operational scenario environment conditions required to achieve the goal into the capabilities that each scenario role should possess, and arranging the capabilities according to a certain ordered organizational structure to establish a system capability network. The establishment of the system capability network includes the following steps: Step C1: Capability framework selection, wherein the specific method for selecting the capability framework is as follows: based on the system capabilities and the indicators of the objects of concern, select a top-level capability classification method of the system as a container to describe the system capability structure, and introduce DoDAF tailored multi-view modeling to assist in requirements analysis. Step C2: Activity-Capability Mapping, wherein the specific method of the activity-capability mapping is as follows: based on the scene operation activity description formed in step B1, the system capabilities required to support the execution of a certain scene activity in the corresponding swimlane of the execution role are defined, and the support relationship between activities and capabilities is represented by a mapping matrix. Step C3: Capability Relationship Description, wherein the specific method of capability relationship description is as follows: based on the system capabilities conceived from the activities in step C2 and the top-level system capabilities selected in step C1, all existing capability granularities are assigned to their related roles, and the hierarchical relationship and dependency relationship between capabilities and the cross-linking relationship between capabilities are conceived and described, thereby forming a multi-view system capability network. Step D: System function division and requirements analysis. Specifically, the system function division and requirements analysis are carried out by: transforming the indicators implied by the system capabilities into the elements required for system development, dividing the functional components required to meet the system functions, and analyzing the system requirements that the system should meet based on the system functions.

2. The system requirements analysis method based on a system scenario as described in claim 1, characterized in that, The system functional division and requirements analysis include the following steps: Step D1: System Function Description, wherein the specific method of the system function description is as follows: based on the system capabilities allocated to the system of concern in step C3, the support relationship between the system functional components and the system capabilities associated with the system of concern is mapped, and a system functional component description is formed; Step D2: System function analysis, wherein the specific method of the system function analysis is as follows: based on the scene operation activity description determined in step B1 and the role status description determined in step B3, a system function activity diagram is established with functional components as role swimlanes, and the full life cycle function operation process of the system corresponding to the role in the scene is analyzed. Step D3: Function-Requirement Mapping. Specifically, the function-requirement mapping is performed as follows: based on the system functional component description formed in Step D1 and the system functional analysis formed in Step D2, and according to the existing functional components of the system, the system requirements required to satisfy a certain function of the system are defined, and the support relationship between the system functional components and the defined system requirements is mapped, thereby completing the system requirement description.

Images