Demand tracing method based on OSLC standard

Abstract

The invention discloses a demand tracing method based on an OSLC standard. The method comprises the following steps of S1, developing a demand software adapter; s2, developing a modeling software adapter; s3, designing a client application to obtain and display data; s4, establishing a traceability relationship between the demand and the model; step S5, realizing query and visual display of the traceability relationship; and S6, demand change influence analysis is realized. According to the method, the OSLC standard is fully utilized, seamless integration of heterogeneous tools can be realized without large-scale transformation through data standardization of the demand software and the modeling software, the universality and interoperability between the tools are greatly improved, the implementation cost is effectively reduced, the bidirectional tracing capability between the demand and the model is provided, and the method is suitable for popularization and application. The demand integrity and the model consistency are ensured, and the quality management capability in the system development process is remarkably improved.

Description

Technical Field

[0001] The invention belongs to the technical field of computer software, and relates to a demand tracing method, and in particular to a demand tracing method based on the OSLC (Open Service Lifecycle Collaboration) standard. Background Art

[0002] In the development process of modern complex systems, requirements management and system modeling are two core links. Requirements management tools (such as IBM DOORS, Jama Connect) are widely used to capture and manage system requirements, while modeling tools (such as MATLAB / Simulink, Modelica, Rhapsody) are used to convert requirements into system design models. As the scale and complexity of the system increase, traceability management between requirements and models becomes particularly important, which is of great significance for ensuring that requirements are correctly implemented, reducing design defects, and improving system development efficiency. However, there is often a lack of efficient integration between requirements software and modeling software, which is mainly manifested in the following problems:

[0003] 1. Data silos: Demand management tools and modeling tools usually run independently, and the data storage and management formats between different tools are different, resulting in the inability to directly interact between tools and the creation of information islands.

[0004] 2. Difficulty in tracing: The correlation between requirements and models cannot be automatically maintained by tools. The development team needs to rely on manual or external document records for tracing, which increases the risk of errors and management costs of tracing.

[0005] 3. Difficulty in managing demand changes: When requirements change, it is impossible to quickly locate and update related models, which may cause subsequent designs to deviate from requirements.

[0006] To address these challenges, OSLC, as an open standard, provides a universal solution for the integration of heterogeneous tools. OSLC enables data interaction and collaboration between requirements management tools and modeling tools by providing a unified and standardized description of resources, defining a unified resource model and interface protocol, and thus supporting requirements traceability across tool chains.

[0007] In the OSLC-based integration framework, requirements and models can be used as standardized resources, reference each other through RESTful interfaces, and build a traceability relationship across tool chains. However, in actual applications, there are significant differences in the interfaces and data formats of different requirements software and modeling software, which leads to certain complexity and limitations in the direct implementation of OSLC standards. Therefore, developing adapters that comply with OSLC standards, unifying the data formats of heterogeneous tools, and establishing and maintaining the traceability relationship between requirements and models through the client have become key technical means to solve the above problems.

[0008] At present, the research and application of demand traceability are mainly focused on the traceability relationship management within a single tool chain, while in multi-tool chain and heterogeneous environment, the traceability solution based on OSLC is still in the exploratory stage. Especially between demand software and modeling software, how to achieve efficient traceability and support complex system development requirements through standardized methods is still a topic worthy of in-depth research. Summary of the invention

[0009] In order to achieve demand tracing between demand software and modeling software, and solve the problems of independent operation of existing tools, data islands, and difficulty in tracing between demand and model, the present invention provides a demand tracing method based on the OSLC standard. The method designs a technical solution that OSLC standardizes the data of demand software and modeling software by developing an adapter, and establishes a tracing relationship between demand and model through the client. Through the present invention, users can easily achieve two-way tracing between demand and model in a heterogeneous tool environment, and improve the efficiency and consistency of the system development process.

[0010] The objective of the present invention is achieved through the following technical solutions:

[0011] A requirement tracing method based on the OSLC standard includes the following steps:

[0012] Step S1, developing a demand software adapter: developing a demand software adapter for the demand management tool, the demand software adapter can access the data of the demand management tool and convert it into a resource description format that complies with the OSLC standard, and provide a RESTful interface for client access. The specific steps are as follows:

[0013] Step S1.1, analyze the requirements of the adapter, clarify that the purpose of developing the adapter system is to obtain the requirement data in the requirement management tool and standardize it on OSLC. After clarifying this goal, determine the resource types and service capabilities to be exposed by the requirement management tool. For the requirement management tool, its core resource is the requirement, and the management of the requirement is the main service it provides;

[0014] Step S1.2, clarify the mapping relationship between the data to be exposed by the requirement management tool and the OSLC resources: In the requirement management tool, the project is the organizational unit of the requirements. Each project contains a large number of requirements. This hierarchical relationship is expressed in the OSLC standard through the relationship between ServiceProvider and ChangeRequest. By mapping the project to ServiceProvider and the requirements to ChangeRequest, a mapping relationship model is constructed. After determining the mapping relationship, the resource class design is carried out to model the resources in the target system.

[0015] Step S1.3, design the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the realization of core services, namely data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system;

[0016] Step S1.4, implement the adapter service, including creating a service provider and implementing CRUD operations;

[0017] Step S1.5, complete authentication and security configuration, where user identity verification and authorization are implemented through the integrated OAuth protocol;

[0018] Step S2, developing a modeling software adapter: developing a modeling software adapter for a modeling tool, the modeling software adapter can access the model data of the modeling tool, and standardize it into data that conforms to the OSLC resource format, and provide a unified access interface. The specific steps are as follows:

[0019] Step S2.1, analyze the requirements of the adapter, clarify that the purpose of developing the adapter system is to obtain the model data in the modeling tool and standardize it on OSLC. After clarifying this goal, determine the resource types and service capabilities to be exposed by the modeling tool. For the modeling tool, its core resource is the model, and the management of the model is the main service it provides;

[0020] Step S2.2, clarify the mapping relationship between the data to be exposed by the modeling tool and the OSLC resources: map the model in the modeling tool to the ChangeRequest in OSLC. In order to adapt to the OSLC standard, each model is mapped to an independent ChangeRequest instance. This mapping is achieved by inheriting the ChangeRequest class. After determining the mapping relationship, start designing other resource classes.

[0021] Step S2.3, designing the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the realization of core services, namely data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system;

[0022] Step S2.4, implement the adapter service, including creating a service provider and implementing CRUD operations;

[0023] Step S2.5, complete authentication and security configuration, where user identity verification and authorization are implemented through the integrated OAuth protocol;

[0024] Step S3, designing a client application to obtain and display data: The client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the demand software and the modeling software, implements the data parsing function in the client, displays the acquired demand data in a list form, and displays the modeling data in a graphical form. The specific steps are as follows:

[0025] Step S3.1, the client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the requirement tool and the modeling tool. The data formats directly supported by OSLC include RDF, JSON and XML.

[0026] Step S3.2: The client application needs to design parsing modules for the demand data and modeling data respectively, extract key information therein, and display the parsed data in a list form. For the demand data, an intuitive table or tree view is provided to display the hierarchical relationship and detailed information of the demand; graphical tools are used to display the model data in a topology diagram, flow chart or other interactive view to show the interaction relationship between system components;

[0027] Step S4, establishing a traceability relationship between requirements and models: Establishing and managing the traceability relationship between requirements and models through the client, storing the traceability relationship established by the user in the client in the traceability relationship database, and updating the data in the adapter at the same time to ensure the long-term maintenance and availability of the traceability relationship, and facilitate consistency checking. The specific steps are as follows:

[0028] Step S4.1, define multiple traceability relationship types to meet system engineering requirements, including dependency relationships, implementation relationships, and verification relationships. The user manually selects requirements and model elements through the client interface, creates a traceability relationship, and specifies its type;

[0029] Step S4.2: Store the traceability relationship established by the user in the client into the traceability relationship database, and update the data of related resources in the adapter. The traceability relationship database contains the following key table structures: requirement table, model element table, and relationship table;

[0030] Step S5, query and visualize the traceability relationship: The client supports querying the model elements of the modeling tool related to a certain requirement of the requirement management tool, or tracing back to the corresponding requirement from a certain model element of the modeling tool, so as to realize the two-way traceability between the requirement and the model and display it in a graphical interface. The specific steps are as follows:

[0031] Step S5.1, the query function includes query from requirement to model and query from model to requirement, wherein: in query from requirement to model, the user selects a requirement in the requirement management tool, and the client automatically retrieves all model elements related to it, supporting conditional filtering and fuzzy search functions; in query from model to requirement, the user selects a model element in the client, and the client traces back to the requirement list associated with it, supporting model element type filtering and navigation by hierarchy;

[0032] Step S5.2: Display the query results in the form of a topology diagram or a relationship diagram. Nodes represent requirements or model elements, and edges represent the traceability relationship between the two. Color or line type is used to distinguish relationship types. The diagram supports interactive operations. In addition, the client supports displaying query results in the form of a matrix. Rows represent requirement elements, and columns represent model elements. If there is a traceability relationship, it is indicated by a special mark in the corresponding cell.

[0033] Step S5.3, the query results are exported as PDF, Excel or image files for easy analysis and archiving. The client generates a visual traceability relationship report based on the query results, including charts, data tables and analysis summaries;

[0034] Step S6: Implement the impact analysis of requirement changes: Based on the established traceability relationship, analyze the impact of requirement changes on the model, traverse the traceability relationship, determine the affected model resources and display them in the interface. The specific steps are as follows:

[0035] Step S6.1: When the client's requirements change, the system automatically traverses the traceability relationships involved in the requirements, locates the model elements directly associated with the requirements, and then further analyzes the interaction relationships between these model elements to identify indirectly affected model resources;

[0036] Step S6.2: According to the impact scope, the system classifies the model resources directly associated with the change requirement as direct impact, and classifies the model resources caused by the interaction relationship of the directly associated resources as indirect impact.

[0037] Compared with the prior art, the present invention has the following advantages:

[0038] 1. Make full use of OSLC standards and support heterogeneous tool integration: The present invention implements data standardization of demand software and modeling software through OSLC standards, improves the versatility and interoperability of data, and achieves seamless connection between demand software and modeling software. It can realize the integration of heterogeneous tools without large-scale transformation of existing tools, greatly reducing the implementation cost.

[0039] 2. Bidirectional traceability support: The present invention provides forward and reverse traceability capabilities between requirements and models, ensuring the integrity of requirements and the consistency of models, significantly improving the quality management capabilities during system development, and simplifying the development and verification process of complex systems.

[0040] 3. Flexible traceability relationship management: In the present invention, users can freely define and modify the traceability relationship between requirements and models on the client side, and uniformly manage the traceability relationship through the database, support version control and change management of requirements and models, and adapt to the needs of different development processes.

[0041] 4. Support change analysis and improve collaboration efficiency: The present invention reduces the impact of demand changes on system development through automated impact analysis and improves the maintainability of the system. At the same time, through standardized interfaces, the present invention promotes efficient collaboration between the demand management team and the modeling team, reduces information islands, and contributes to the efficient development of complex systems.

[0042] 5. Strong scalability: The development of the adapter and the design of the client in the present invention are highly flexible and can be customized and expanded according to different demand software and modeling tools to adapt to a variety of development scenarios. At the same time, the adapter design and client architecture support the integration of more tools in the future, providing a good development space for complex system engineering. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a flow chart of the OSLC-based requirement tracing method;

[0044] Figure 2 A workflow diagram for adapters, including a requirement tool adapter and a modeling tool adapter;

[0045] Figure 3 An example diagram for modeling requirement resources in the requirement tool adapter;

[0046] Figure 4 Flowchart for adapter development;

[0047] Figure 5The modeling example diagram of the model resource in the modeling tool adapter, (a) is the modeling example diagram of the use case diagram in sysml, in which the Actor class and UseCase class used by the attribute need to be defined by the user, (b) is the modeling example of the attribute UseCase in (a), and (c) is the modeling example diagram of the block in sysml;

[0048] Figure 6 Figure 1 is an example of a service provider data resource that has been converted to conform to the OSLC standard, where (a) is a data resource in RDF+XML format, (b) is a data resource in JSON format, and (c) is a data resource in XML format;

[0049] Figure 7 This is the functional module diagram of the demand tracing client. DETAILED DESCRIPTION

[0050] The technical solution of the present invention is further described below in conjunction with the accompanying drawings, but is not limited thereto. Any modification or equivalent replacement of the technical solution of the present invention without departing from the spirit and scope of the technical solution of the present invention should be included in the protection scope of the present invention.

[0051] The present invention provides a demand tracing method based on the OSLC standard, the method comprising the following steps:

[0052] Step S1, developing a demand software adapter: developing a demand software adapter for a demand management tool (such as IBM DOORS, Jama Connect), the demand software adapter can access the data of the demand management tool and convert it into a resource description format that complies with the OSLC standard, and provide a RESTful interface for client access. The workflow of the demand software adapter is as follows: Figure 2 This step is one of the foundations of the entire traceability process, ensuring that the acquired data can be OSLC standardized to support subsequent interaction and traceability.

[0053] In this step, the development of the demand software adapter is based on the Eclipse Lyo SDK, calling the methods in the OSLC4J library. The development of the demand software adapter is to complete the data standardization of the demand management tool, that is, the data source of the demand software adapter is the demand management tool, and the source data is standardized by the demand software adapter to obtain OSLC resources that meet the OSLC standard.

[0054] In this step, the role of the demand software adapter is to act as a bridge between the client and the demand management tool, enabling them to work together under unified standards. It plays a core role in system integration. Before developing the demand software adapter, it is necessary to clarify the data to be exposed by the demand management tool and its mapping relationship with OSLC resources. This is a key step in the design of the demand software adapter, because the correct mapping relationship can not only ensure the semantic consistency of the data, but also greatly improve the interoperability and scalability of the system. If the mapping relationship is inappropriate, it may cause data semantic loss, leading to user misunderstanding or failure of data docking between tools, thereby destroying the collaboration of the entire tool chain and bringing additional burden to subsequent expansion and maintenance.

[0055] In this step, the core function of the requirement management tool is usually to record, manage and track the requirements in the project. The project in the requirement management tool is often the organizational unit of requirements, and each project contains a large number of requirements. This hierarchical relationship can be expressed in the OSLC standard through the relationship between ServiceProvider and ChangeRequest.

[0056] In the OSLC standard, ServiceProvider is a resource type that represents a provider of a service or a collection of resources in a specific context. For requirement management tools, a project is often a logical grouping unit of requirements, which defines an independent requirement scope. Mapping a project to a ServiceProvider can clearly reflect this grouping structure, thereby providing a clear context for subsequent requirement management and traceability relationship establishment. In a multi-project environment, the requirements of different projects can be managed separately through different ServiceProviders, enhancing the flexibility of the system. Each ServiceProvider can independently expose a specific set of requirements, and the requirement software adapter can control data access rights based on the project scope.

[0057] In OSLC, ChangeRequest is a resource type used to describe specific requirements, change requests, defects, or improvement suggestions. Each requirement in the requirements management tool can be mapped to a ChangeRequest because the semantics of the two are highly consistent: each requirement usually contains information such as identification, title, description, status, priority, etc., which can be directly mapped to the attributes of ChangeRequest. Secondly, ChangeRequest provides a wealth of extended attributes that can map various specific fields of requirements and support flexible expansion. After the requirements are exposed in the form of ChangeRequest, a unified data flow can be established with other OSLC-compatible tools to enhance the system's collaborative capabilities.

[0058] In this step, by mapping the project to ServiceProvider and the requirement to ChangeRequest, a mapping relationship model with clear logic and consistent semantics can be constructed. This mapping method can maximize the advantages of the OSLC standard and lay a solid foundation for data interoperability between requirement management tools and other engineering tools.

[0059] In this step, after determining the mapping relationship, the resources can be modeled, that is, the OSLC representation of the resources in the target system can be defined. In this step, OSLC annotations (such as @OslcName, @OslcNamespace) can be used to define resource classes. Figure 3 This is an example of demand resource modeling, where the attribute state is used to indicate whether the current demand has been successfully traced. If successful, the value is true, otherwise false; the attribute father is used to indicate the parent class demand of the current demand. If the current demand is a top-level demand, the father value is -1. The OSLC annotation is used above the Get method to provide a description and specification of each attribute, where @OslcOccurs is used to specify the number of occurrences of the attribute. Then implement OSLC service capabilities, including query capabilities, creation capabilities, and update capabilities, and provide RESTful APIs. The specific demand software adapter development process is as follows: Figure 4 shown.

[0060] Step S2, develop a modeling software adapter: Develop a modeling software adapter for modeling tools (such as Simulink, Modelica, Rhapsody). The modeling software adapter can access the model data of the modeling tool and standardize it into data that conforms to the OSLC resource format, providing a unified access interface. This step is one of the foundations of traceability, ensuring that the acquired model data can be OSLC standardized.

[0061] In this step, the development of the modeling software adapter is based on the Eclipse Lyo SDK, calling the methods in the OSLC4J library. The development of the modeling software adapter is to complete the data standardization of the modeling tool, that is, the data source of the modeling software adapter is the modeling tool, and the source data is standardized by the modeling software adapter to obtain OSLC resources that meet the OSLC standard.

[0062] In this step, when constructing the modeling tool adapter, the model is the core design element, and these models need to be mapped to the resource types defined by the OSLC standard to ensure the interoperability of data between different tools. Each model in the modeling software often involves multiple systems or subsystems, and may have multiple different representations or versions. Therefore, in order to be consistent with the OSLC resource model, the model is mapped to the ChangeRequest in OSLC.

[0063] In OSLC, ChangeRequest, as a resource type, is usually used to represent a specific change request or requirement. In modeling software, although the model itself is not directly equivalent to a change request, in order to adapt to the OSLC standard, each model needs to be mapped to an independent ChangeRequest instance. This mapping can be achieved by inheriting the ChangeRequest class to provide special extensions or customized properties for each type of model or model element. For example, a specific model or module in the modeling software can inherit the ChangeRequest class and add new fields to it (such as model version, status, and component to which it belongs) to make it conform to the standard format of OSLC without losing the semantics of the original model.

[0064] In this step, ServiceProvider, as the core component of OSLC, is mainly used to provide services for resources, such as resource creation, update and query functions. However, ServiceProvider is not directly mapped to specific concepts in modeling software, but is designed around resources. Its role is to provide a unified interface through which clients can interact with different types of resources (such as models). Therefore, when designing, service providers need to focus on how to provide services for these resources without being tightly bound to specific model types or concepts in modeling software. This design makes ServiceProvider more general and flexible, and can provide consistent access methods for multiple types of resources.

[0065] In this step, a special attribute is added to the model resource to represent the association or traceability path between the model and the requirement. However, in the initial stage of resource conversion, this traceability attribute is usually empty because the specific establishment of the traceability relationship is completed in the client. The client establishes the association between the model and the requirement through the interactive interface or based on business logic, and stores these traceability relationships in the database. In this way, the client can not only ensure the accurate traceability between the model and the requirement, but also maintain the dynamic update and management of the traceability relationship. The modeling example of the model resource is as follows: Figure 5 As shown, (a) is a modeling example diagram of the use case diagram in sysml, in which the relationship between the executor and the use case is represented in the Actor class, and the relationship between use cases is displayed by the UseCase class; (b) is a modeling example of the attribute UseCase in (a), and the relationship between use cases is represented by the list List; (c) is a modeling example diagram of the block in sysml.

[0066] Step S3: Design a client application to obtain and display data: The client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the demand software and the modeling software. The data parsing function is implemented in the client, and the obtained demand data is displayed in a list form, and the modeling data is displayed in a graphical form.

[0067] In this step, the client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the requirement tool and the modeling tool. The data formats directly supported by OSLC are RDF, JSON and XML. Figure 6 This is an example of service provider data.

[0068] In this step, the client application needs to design parsing modules for the demand data and modeling data, extract key information, and convert it into a format suitable for display. It is recommended that the client display the demand data in a list format after parsing, provide an intuitive table or tree view to display the hierarchical relationship and detailed information of the requirements; use graphical tools (such as D3.js, Plotly, or embedded graphics libraries) to display model data in topology diagrams, flow charts or other interactive views to show the interaction between system components.

[0069] In this step, in order to improve the flexibility and scalability of the system, a modular architecture is adopted, and the client application is divided into three modules: data processing module, requirement tracing module and requirement change impact analysis module. Among them: the data processing module is mainly responsible for the data acquisition, parsing and display of the system, and is the basis of requirement tracing and analysis. The client obtains data from the adapter, and then parses and displays the acquired data in various forms; the requirement tracing module is mainly responsible for establishing and maintaining the traceability relationship between requirements and models, ensuring the traceability and consistency of requirements, including establishing traceability relationships, consistency checks and displaying traceability relationships; the requirement change impact analysis module is used to analyze the potential impact of requirement changes on models and other requirements. Its functions include finding affected models and displaying affected models. The functional module diagram of the client is shown in the figure below. Figure 7 shown.

[0070] In this step, use OSLC4J or other open source libraries that support the OSLC standard to implement data interface calls and parsing in client application development; use a modern front-end technology stack (such as React, Vue.js, or Angular) to develop the user interface, and combine it with a graphical library (such as D3.js or Cytoscape.js) to achieve graphical display of modeling data; use lightweight frameworks such as Spring Boot or Flask to build back-end services to provide data support for the front end.

[0071] Step S4, establishing a traceability relationship between requirements and models: Establishing and managing the traceability relationship between requirements and models through the client, storing the traceability relationship established by the user in the client in the traceability relationship database, and updating the data in the adapter at the same time, ensuring the long-term maintenance and availability of the traceability relationship, and facilitating consistency checks;

[0072] In this step, multiple traceability relationship types are defined to meet system engineering requirements, including dependency relationships, implementation relationships, and verification relationships. Users can manually select requirements and model elements through the client interface, create traceability relationships, and specify their types. During the manual creation process, the client can provide suggested traceability relationships for users to confirm or edit.

[0073] In this step, the traceability database needs to include the following key table structures: Requirement table: stores the unique identifier, name, priority and other information of the requirement; Model element table: stores the unique identifier, type, description and other information of the model element; Relationship table: stores the association information between the requirement and the model, including the relationship type and metadata (such as creation time, maintainer). After the traceability relationship is established, the data of the related resources in the adapter must also be changed accordingly.

[0074] Step S5, realize the query and visual display of the traceability relationship: the client supports starting from a certain requirement of the requirement management tool, querying the model elements of the modeling tool related to it, or starting from a certain model element of the modeling tool, tracing back to its corresponding requirement, realizing two-way traceability between requirements and models and displaying it in a graphical interface.

[0075] In this step, the query function includes query from requirement to model and query from model to requirement. In the query from requirement to model, the user selects a requirement in the requirement management tool, and the client automatically retrieves all model elements related to it, supporting conditional filtering and fuzzy search functions; in the query from model to requirement, the user selects a model element in the client, and the client traces back to the list of requirements associated with it, supporting model element type filtering (such as components, interfaces, signals) and navigation by hierarchy.

[0076] In this step, the query results can be displayed in the form of a topology diagram or a relationship diagram. Nodes represent requirements or model elements, and edges represent the traceability relationship between the two. Color or line type is used to distinguish the relationship type. The graph supports interactive operations, such as dragging, zooming, and clicking nodes to view details. In addition, the client supports displaying query results in matrix form, with rows representing requirement elements and columns representing model elements. If there is a traceability relationship, it is indicated by a special mark in the corresponding cell.

[0077] In this step, the query results can be exported as PDF, Excel or image files for easy analysis and archiving. The client generates a visual traceability relationship report based on the query results, including charts, data tables and analysis summaries.

[0078] Step S6: Implement the impact analysis of requirement changes: Based on the established traceability relationship, analyze the impact of requirement changes on the model, traverse the traceability relationship, determine the affected model resources and display them in the interface.

[0079] In this step, when the client's requirements change, the system automatically traverses the traceability relationships involved in the requirements, locates the model elements directly associated with them, and then further analyzes the interaction relationships of these model elements to identify indirectly affected model resources. Based on the scope of impact, the system classifies model resources directly associated with the changed requirements as directly affected, and model resources caused by the interaction relationships of directly associated resources as indirect impacts.

[0080] The present invention makes full use of the OSLC standard, and through data standardization of the demand software and modeling software, it can achieve seamless integration of heterogeneous tools without large-scale transformation, greatly improving the versatility and interoperability between tools, effectively reducing the implementation cost, and providing two-way traceability between requirements and models, ensuring the integrity of requirements and model consistency, and significantly improving the quality management capabilities during system development. At the same time, the present invention can flexibly define and manage the traceability relationship between requirements and models, support version control and change management, and adapt to various development process requirements. It also improves the maintainability of the system through automated change impact analysis tools, promotes team collaboration, reduces information islands, and helps the efficient development of complex systems. In addition, the present invention is highly scalable, and the adapter and client design can be customized according to different needs, and can support the integration of more tools in the future, providing a broad development space for complex system engineering.

[0081] Example:

[0082] This embodiment provides a demand tracing method implemented by using the above process, which specifically includes the following steps:

[0083] Step A1: Based on the demand software adapter capable of unifying data formats developed in step S1, the demand data in the demand management tool is obtained, and the demand data is converted into standardized data in accordance with the OSLC resource description format, usually in RDF, JSON or XML format;

[0084] Step A2: acquiring the model data in the modeling tool based on the modeling software adapter developed in step S2, and converting it into a resource description format that complies with the OSLC standard;

[0085] Step A3: In the client, the RESTful interface of the adapter is called through the interactive interface to obtain the OSLC-standardized requirements and model data, and the data is parsed and displayed;

[0086] Step A4: Select the requirement resource and the modeling resource in the client interface, establish a traceability relationship for the selected resource and define its relationship type, such as "realization", "dependency" or "realization", update the traceability relationship to the adapter through the OSLC interface, and store it in the client database;

[0087] Step A5: Perform consistency check and mark uncovered requirements or isolated models;

[0088] Step A6: Perform impact analysis on requirement changes, detect changes in requirement data, analyze affected model resources through traceability relationships, and mark them.

Claims

1. A demand tracing method based on OSLC standard, characterized by The method comprises the following steps: Step S1, developing a demand software adapter: developing a demand software adapter for a demand management tool, the demand software adapter can access the data of the demand management tool, and convert it into a resource description format that complies with the OSLC standard, and provide a RESTful interface for client access; Step S2, developing a modeling software adapter: developing a modeling software adapter for a modeling tool, the modeling software adapter can access the model data of the modeling tool, and standardize it into data that complies with the OSLC resource format, and provide a unified access interface; Step S3, designing a client application to obtain and display data: the client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the demand software and the modeling software, implements the data parsing function in the client, and displays the obtained demand data in a list form and the modeling data in a graphical form; Step S4, establishing a traceability relationship between requirements and models: Establishing and managing the traceability relationship between requirements and models through the client, storing the traceability relationship established by the user in the client in the traceability relationship database, and updating the data in the adapter at the same time, ensuring the long-term maintenance and availability of the traceability relationship, and facilitating consistency checks; Step S5, query and visualize the traceability relationship: the client supports querying the model elements of the modeling tool related to a certain requirement of the requirement management tool, or tracing back to the corresponding requirement from a certain model element of the modeling tool, so as to realize the two-way traceability between the requirement and the model and display it in a graphical interface; Step S6, implement the impact analysis of requirement changes: based on the established traceability relationship, analyze the impact of requirement changes on the model, traverse the traceability relationship, determine the affected model resources and display them in the interface.

2. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step S1 are as follows: Step S1.1, analyze the requirements of the adapter, clarify that the purpose of developing the adapter system is to obtain the requirement data in the requirement management tool and standardize it on OSLC. After clarifying this goal, determine the resource types and service capabilities to be exposed by the requirement management tool. For the requirement management tool, its core resource is the requirement, and the management of the requirement is the main service it provides; Step S1.2, clarify the mapping relationship between the data to be exposed by the requirement management tool and the OSLC resources: In the requirement management tool, the project is the organizational unit of the requirements. Each project contains a large number of requirements. This hierarchical relationship is expressed in the OSLC standard through the relationship between ServiceProvider and ChangeRequest. By mapping the project to ServiceProvider and the requirements to ChangeRequest, a mapping relationship model is constructed. After determining the mapping relationship, the resource class design is carried out to model the resources in the target system. Step S1.3, design the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the realization of core services, namely data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system; Step S1.4, implement the adapter service, including creating a service provider and implementing CRUD operations; Step S1.5: Complete authentication and security configuration, where user identity verification and authorization are implemented through the integrated OAuth protocol.

3. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step 2 are as follows: Step S2.1, analyze the requirements of the adapter, clarify that the purpose of developing the adapter system is to obtain the model data in the modeling tool and standardize it on OSLC. After clarifying this goal, determine the resource types and service capabilities to be exposed by the modeling tool. For the modeling tool, its core resource is the model, and the management of the model is the main service it provides; Step S2.2, clarify the mapping relationship between the data to be exposed by the modeling tool and the OSLC resources: map the model in the modeling tool to the ChangeRequest in OSLC. In order to adapt to the OSLC standard, each model is mapped to an independent ChangeRequest instance. This mapping is achieved by inheriting the ChangeRequest class. After determining the mapping relationship, start designing other resource classes. Step S2.3, designing the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the realization of core services, namely data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system; Step S2.4, implement the adapter service, including creating a service provider and implementing CRUD operations; Step S2.5: Complete authentication and security configuration, where user identity verification and authorization are implemented through the integrated OAuth protocol.

4. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step S3 are as follows: Step S3.1, the client application obtains data resources that comply with the OSLC standard by calling the adapter interface of the requirement tool and the modeling tool; Step S3.2, the client application needs to design parsing modules for the demand data and modeling data respectively, extract the key information therein, and display the parsed data in the form of a list. For the demand data, an intuitive table or tree view is provided to display the hierarchical relationship and detailed information of the requirements; graphical tools are used to display the model data in a topology diagram, flow chart or other interactive view to show the interaction relationship between system components.

5. The OSLC standard-based demand tracing method according to claim 4 is characterized in that The data formats directly supported by OSLC are RDF, JSON and XML.

6. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step S4 are as follows: Step S4.1, define multiple traceability relationship types to meet system engineering requirements, including dependency relationships, implementation relationships, and verification relationships. The user manually selects requirements and model elements through the client interface, creates a traceability relationship, and specifies its type; Step S4.2: Store the traceability relationship established by the user in the client into the traceability relationship database, and update the data of related resources in the adapter. The traceability relationship database includes the following key table structures: requirement table, model element table, and relationship table.

7. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step S5 are as follows: Step S5.1, the query function includes query from requirement to model and query from model to requirement, wherein: in query from requirement to model, the user selects a requirement in the requirement management tool, and the client automatically retrieves all model elements related to it, supporting conditional filtering and fuzzy search functions; in query from model to requirement, the user selects a model element in the client, and the client traces back to the requirement list associated with it, supporting model element type filtering and navigation by hierarchy; Step S5.2: Display the query results in the form of a topology diagram or a relationship diagram. Nodes represent requirements or model elements, and edges represent the traceability relationship between the two. Color or line type is used to distinguish relationship types. The diagram supports interactive operations. In addition, the client supports displaying query results in the form of a matrix. Rows represent requirement elements, and columns represent model elements. If there is a traceability relationship, it is indicated by a special mark in the corresponding cell. Step S5.3: The query results are exported as PDF, Excel or image files for easy analysis and archiving. The client generates a visual traceability relationship report based on the query results, including charts, data tables and analysis summaries.

8. The OSLC standard-based demand tracing method according to claim 1 is characterized in that The specific steps of step S6 are as follows: Step S6.1: When the client's requirements change, the system automatically traverses the traceability relationships involved in the requirements, locates the model elements directly associated with the requirements, and then further analyzes the interaction relationships between these model elements to identify indirectly affected model resources; Step S6.2: According to the impact scope, the system classifies the model resources directly associated with the change requirement as direct impact, and classifies the model resources caused by the interaction relationship of the directly associated resources as indirect impact.

Images