A requirement traceability method based on OSLC standard

Abstract

The application discloses a demand traceability method based on an OSLC standard, and comprises the following steps: step S1, developing a demand software adapter; step S2, developing a modeling software adapter; step S3, designing a client application to acquire and display data; step S4, establishing a traceability relationship between demands and models; step S5, realizing query and visual display of the traceability relationship; and step S6, realizing demand change influence analysis. The application fully utilizes the OSLC standard, realizes seamless integration of heterogeneous tools without large-scale modification through data standardization of demand software and modeling software, greatly improves the universality and interoperability between tools, effectively reduces implementation cost, provides bidirectional traceability capability between demands and models, ensures demand integrity and model consistency, and significantly improves the quality management capability in a system development process.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of computer software, and relates to a requirement tracing method, in particular to a requirement tracing method based on OSLC (Open Service Life Cycle Collaboration) standard. BACKGROUND

[0002] In the development process of modern complex systems, requirement management and system modeling are two core links. Requirement 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. With the expansion of system size and the increase of system complexity, the traceability management between requirements and models becomes particularly important, which is of great significance to ensure that requirements are correctly implemented, reduce design defects, and improve system development efficiency. However, at present, there is often a lack of efficient integration between requirement software and modeling software, which mainly manifests in the following problems:

[0003] 1. Data island: requirement management tools and modeling tools usually run independently, and the data storage and management formats of different tools are different, which leads to the inability of direct interaction between tools and the generation of information island.

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

[0005] 3. Difficulty in managing requirement changes: when requirements change, it is difficult to quickly locate and update related models, which may cause subsequent design to deviate from requirements.

[0006] In order to cope with these challenges, OSLC as an open standard provides a general solution for the integration between heterogeneous tools. OSLC defines a unified resource model and interface protocol through the unified standardized description of resources, which makes the data interaction and cooperation between requirement management tools and modeling tools possible, thereby supporting cross-tool chain requirement tracing.

[0007] In the OSLC-based integration framework, requirements and models can be standardized resources, and can be referenced to each other through RESTful interfaces to build traceability across tool chains. However, in practical applications, the interfaces and data formats of different requirement software and modeling software are significantly different, which leads to certain complexity and limitations in the implementation of the OSLC standard directly. Therefore, developing an adapter conforming to the OSLC standard, unifying the data formats of heterogeneous tools, and establishing and maintaining the traceability between requirements and models through the client have become the key technical means to solve the above problems.

[0008] At present, the related research and application of requirement traceability mainly focus on the management of traceability within a single tool chain, and in a multi-tool chain and heterogeneous environment, the OSLC-based traceability solution is still in the exploratory stage. Especially between requirement software and modeling software, how to achieve efficient traceability through standardized means and support complex system development requirements is still a topic worthy of in-depth study. SUMMARY

[0009] In order to realize the requirement traceability between requirement software and modeling software, and solve the problems of existing tool independent operation, data island and traceability difficulty between requirements and models, the present application provides a requirement traceability method based on OSLC standard. The method designs a technical scheme for OSLC standardization of data of requirement software and modeling software through development of an adapter, and establishment of traceability between requirements and models through a client. Through the present application, users can easily realize bidirectional traceability between requirements and models in a heterogeneous tool environment, and improve the efficiency and consistency of the system development process.

[0010] The purpose of the present application is achieved by the following technical scheme:

[0011] A requirement traceability method based on OSLC standard, comprising the following steps:

[0012] Step S1, developing a requirement software adapter: developing a requirement software adapter for a requirement management tool, the requirement software adapter can access data of the requirement management tool, and convert the data into a resource description format conforming to the OSLC standard, and provide a RESTful interface for the client to access, and the specific steps are as follows:

[0013] Step S1.1, requirement analysis is performed on the adapter, and it is clear that the purpose of developing the adapter system is to obtain requirement data in the requirement management tool and to perform OSLC standardization on the data, and after the target is clear, the resource types to be exposed by the requirement management tool and the service capabilities thereof are determined, and for the requirement management tool, the core resource is requirement, and the management of the requirement is the main service provided thereby;

[0014] Step S1.2, determine the mapping relationship between the data exposed by the requirement management tool and the OSLC resource: the project in the requirement management tool is the organizational unit of the requirement, and a large number of requirements are contained in each project. This hierarchical relationship is expressed through the relationship between ServiceProvider and ChangeRequest in the OSLC standard. By mapping the project as ServiceProvider and the requirement as ChangeRequest, a mapping relationship model is constructed, and after determining the mapping relationship, the design of the resource class is expanded, and the resources in the target system are modeled;

[0015] Step S1.3, expand the design of the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the implementation of the core service, i.e. 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 the authentication and security configuration, wherein the verification and authorization of user identity are implemented through the integration of OAuth protocol;

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

[0019] Step S2.1, requirement analysis of the adapter, the purpose of developing the adapter system is to obtain the model data in the modeling tool and to standardize it according to the OSLC standard. After determining this goal, determine the resource type exposed by the modeling tool and its service capability. For the modeling tool, the core resource is the model, and the management of the model is the main service provided;

[0020] Step S2.2, determine the mapping relationship between the data exposed by the modeling tool and the OSLC resource: map the model in the modeling tool to ChangeRequest in OSLC. In order to adapt to the OSLC standard, each model is mapped to an independent ChangeRequest instance. This mapping is implemented by inheriting the ChangeRequest class. After determining the mapping relationship, the design of other resource classes is expanded;

[0021] Step S2.3, expand the design of the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the implementation of the core service, i.e. data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system;

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

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

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

[0025] Step S3.1, the client application obtains the data resources conforming to 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;

[0026] Step S3.2, the client application needs to design a parsing module for requirement data and modeling data respectively, extract the key information therein, and display the parsed data in the form of a list. For requirement data, intuitive tables or tree views are provided to show the hierarchical relationship and detailed information of requirements. Graphical tools are used to display model data in the form of topological graphs, flowcharts or other interactive views to show the interaction relationship between system components;

[0027] Step S4, establishing the traceability relationship between requirements and models: the establishment and management of the traceability relationship between requirements and models are realized through the client, the traceability relationship established by the user in the client is stored in the traceability relationship database, and the data in the adapter is updated at the same time, ensuring the long-term maintenance and availability of the traceability relationship, facilitating consistency checking. The specific steps are as follows:

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

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

[0030] Step S5, query and visual display of the traceability relationship: the client supports querying the modeling tool model elements related to a requirement in the requirement management tool or tracing back to the corresponding requirement from a model element in the modeling tool, realizing bidirectional traceability between requirements and models and displaying them in a graphical interface, and the specific steps are as follows:

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

[0032] Step S5.2, display the query results in the form of a topology graph or a relationship graph, with nodes representing requirements or model elements and edges representing the traceability relationship between them, and using colors or line types to distinguish relationship types, and the graph supports interactive operations, in addition, the client supports displaying the query results in a matrix form, with rows representing requirement elements and columns representing model elements, and if there is a traceability relationship, it is represented by a special identifier in the corresponding cell;

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

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

[0035] Step S6.1, when a requirement in the client changes, the system automatically traverses the traceability relationship related to the requirement, locates the model elements directly associated with it, and then further analyzes the interaction relationship of these model elements to identify the indirectly affected model resources;

[0036] Step S6.2, the system classifies the model resources directly associated with the changed requirement as direct impact and the model resources triggered by the interaction relationship of the directly associated resources as indirect impact according to the impact range.

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

[0038] 1. Make full use of OSLC standard, support heterogeneous tool integration: the application realizes data standardization of requirement software and modeling software through OSLC standard, improves the universality and interoperability of data, realizes seamless docking of requirement software and modeling software, realizes integration of heterogeneous tools without large-scale modification of existing tools, greatly reduces the implementation cost.

[0039] 2. Bidirectional traceability support: the application provides forward and reverse traceability between requirements and models, ensures the integrity of requirements and the consistency of models, significantly improves the quality management capability in the system development process, and simplifies the development and verification process of complex systems.

[0040] 3. Flexible traceability relationship management: in the application, users can freely define and modify the traceability relationship between requirements and models on the client side, and 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 application reduces the impact of requirement change on system development through automatic impact analysis, improves the maintainability of the system. At the same time, through the standardized interface, the application promotes efficient collaboration between requirement management team and modeling team, reduces the information island phenomenon, and helps efficient development of complex systems.

[0042] 5. Strong scalability: the development of the adapter and the design of the client have high flexibility, which can be customized and extended according to different requirement software and modeling tools, and adapt to various development scenarios. At the same time, the adapter design and client architecture support the integration of more tools in the future, providing good development space for complex system engineering. BRIEF DESCRIPTION OF DRAWINGS

[0043] Figure 1 Requirement traceability method flowchart based on OSLC;

[0044] Figure 2 Adapter workflow diagram, including requirement tool adapter and modeling tool adapter;

[0045] Figure 3 Modeling example diagram of requirement resource in requirement tool adapter;

[0046] Figure 4 Adapter development flowchart;

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

[0048] Figure 6 Example diagram of data resources to be converted into service provider data resources conforming to the OSLC standard, (a) is a data resource in RDF+XML format, (b) is a data resource in JSON format, (c) is a data resource in XML format;

[0049] Figure 7 Functional module diagram of the requirement traceability client. DETAILED DESCRIPTION

[0050] The technical solutions of the present application are further described below in conjunction with the drawings, but are not limited thereto, and any modification or equivalent replacement of the technical solutions of the present application without departing from the spirit and scope of the technical solutions of the present application shall be covered in the protection scope of the present application.

[0051] The present application provides a requirement traceability method based on the OSLC standard, which comprises the following steps:

[0052] Step S1, developing a requirement software adapter: developing a requirement software adapter for a requirement management tool (such as IBM DOORS, Jama Connect), the requirement software adapter can access the data of the requirement management tool and convert it into a resource description format conforming to the OSLC standard, and provide a RESTful interface for the client to access, and the workflow of the requirement software adapter is as shown in Figure 2 This step is one of the foundations of the entire traceability process, which ensures that the obtained data can be standardized according to the OSLC standard to support subsequent interaction and traceability.

[0053] In this step, the development of the requirement software adapter is based on the Eclipse Lyo SDK and the methods in the OSLC4J library are called. The development of the requirement software adapter is to complete the standardization of the data of the requirement management tool, that is, the data source of the requirement software adapter is the requirement management tool, and the OSLC resource conforming to the OSLC standard is obtained after the source data is standardized by the requirement software adapter.

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

[0055] In this step, for the requirement management tool, its core function is usually to record, manage and track requirements in projects. 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 through the relationship between ServiceProvider and ChangeRequest in OSLC standards.

[0056] In OSLC standards, ServiceProvider is a resource type that represents a service provider or a collection of resources in a specific context. For the requirement management tool, a project is often a logical grouping unit of requirements, which defines an independent requirement scope. Mapping the project to 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 ServiceProvider, enhancing the flexibility of the system. Each ServiceProvider can independently expose a specific set of requirements, and the requirement software adapter can control the access rights of the data according to 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 requirement 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 rich extension attributes that can map various specific fields of requirements, supporting flexible expansion. After the requirements are exposed in the form of ChangeRequest, they can establish a unified data flow with other OSLC compatible tools, enhancing the collaboration capabilities of the system.

[0058] In this step, a clear logical and semantic consistent mapping relationship model can be built by mapping projects as ServiceProvider and requirements as ChangeRequest. This mapping method can maximize the advantages of 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, i.e. defining the OSLC representation of resources in the target system. In this step, OSLC annotations (such as @OslcName, @OslcNamespace) can be used to define resource classes. Figure 3 An example of modeling requirements resources is shown in the table below. The attribute state is used to indicate whether the current requirement has been successfully traced or not. If it is successful, the value is true, otherwise it is false. The attribute father is used to indicate the parent requirement of the current requirement. If the current requirement is a top-level requirement, the value of father is -1. The OSLC annotations above the Get method provide a description and specification for each attribute. The @OslcOccurs annotation is used to specify the number of occurrences of the attribute. Then, the OSLC service capabilities are implemented, including query capability, creation capability, and update capability, and RESTful API is provided. The specific development process of the requirement software adapter is shown in Figure 4

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

[0061] In this step, the development of the modeling software adapter is based on the Eclipse Lyo SDK and calls the methods in the OSLC4J library. The development of the modeling software adapter is to complete the standardization of the data of the modeling tool, i.e. the data source of the modeling software adapter is the modeling tool. After standardizing the source data through the modeling software adapter, OSLC resources conforming to the OSLC standard are obtained.

[0062] In this step, when constructing the modeling tool adapter, models are the core design elements, and these models need to be mapped to the resource types defined in OSLC to ensure data interoperability 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 resource model of OSLC, the model is mapped to ChangeRequest in OSLC.​

[0063] In OSLC, ChangeRequest is a resource type that is commonly used to represent a specific change request or requirement item. In modeling software, although the model itself is not directly equivalent to a change request, in order to adapt to the OSLC standard, it is necessary to map each model to an independent ChangeRequest instance. This mapping can be achieved by inheriting the ChangeRequest class, so as to provide specialized extension or customized attributes for each type of model or model element. For example, a specific model or module in modeling software can be made to conform to the standard format of OSLC by inheriting the ChangeRequest class and adding new fields such as model version, status, and belonging component, while not losing the original semantic of the model.

[0064] In this step, ServiceProvider is the core component of OSLC, mainly used to provide services for resources such as resource creation, update and query functions. However, ServiceProvider is not directly mapped to a specific concept 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, the service provider needs to focus on how to provide services for these resources when designing, without being closely bound to the specific model types or concepts in modeling software. This design makes ServiceProvider more versatile and flexible, and can provide consistent access to multiple types of resources.

[0065] In this step, a special attribute is added to the model resource to represent the association or trace path between the model and the requirement. However, in the initial stage of resource conversion, this trace attribute is usually empty, because the specific establishment of the trace 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 trace relationships in the database. In this way, the client can not only ensure the accurate trace between the model and the requirement, but also maintain the dynamic update and management of the trace relationship. The modeling example of the model resource is shown in Figure 5 , where (a) is a modeling example of use case diagram in sysml, where the relationship between actor and use case is represented in Actor class, and the relationship between use cases is represented by UseCase class; (b) is a modeling example of attribute UseCase in (a), where the relationship between use cases is represented by List; (c) is a modeling example of block in sysml.

[0066] Step S3, the client application obtains and displays data: the client application obtains data resources conforming to the OSLC standard by calling the adapter interface of the requirement software and modeling software. In the client, the data parsing function is implemented, and the obtained requirement data is displayed in the form of a list, and the modeling data is displayed in the form of a graph.

[0067] In this step, the client application obtains data resources conforming to 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 The data of the service provider is shown in the table below.

[0068] In this step, the client application needs to design parsing modules for requirement data and modeling data respectively, extract key information from them, and convert them into formats suitable for display. It is recommended that the client display the parsed data in the form of a list to show the requirement data, and provide intuitive tables or tree views to show 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 the form of topology, flowchart, or other interactive views to show the interaction between system components.

[0069] In this step, 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 traceability module, and requirement change impact analysis module. Among them: the data processing module is mainly responsible for data acquisition, parsing and display of the system, and is the basis for requirement traceability and analysis. The client obtains data from the adapter, then parses and displays the data in multiple forms; the requirement traceability 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 relationship, consistency checking and displaying traceability relationship functions; the requirement change impact analysis module is used to analyze the potential impact of requirement changes on models and other requirements, and its functions include finding affected models and displaying affected models. The function module diagram of the client is shown in Figure 7 .

[0070] In this step, OSLC4J or other open source libraries supporting OSLC standards are used in the development of the client application to implement data interface calling and parsing; modern front-end technology stack (such as React, Vue.js or Angular) is used to develop the user interface, and graphical libraries (such as D3.js or Cytoscape.js) are used to realize the graphical display of modeling data; lightweight frameworks such as Spring Boot or Flask are used to build the backend service to provide data support for the front end.

[0071] Step S4, establishing the traceability between requirements and models: the establishment and management of the traceability between requirements and models is realized through the client, the traceability established by the user in the client is stored in the traceability database, and the data in the adapter is updated at the same time, ensuring the long-term maintenance and availability of the traceability, and facilitating the consistency check;

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

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

[0074] Step S5, query and visualization of traceability: the client supports querying the modeling tool model elements related to a requirement from the requirement management tool, or tracing back to the corresponding requirements from a model element in the modeling tool, realizing the bidirectional traceability of requirements and models and displaying them in a graphical interface.

[0075] In this step, the implementation of the query function includes requirement-to-model query and model-to-requirement query. In the requirement-to-model query, the user selects a requirement in the requirement management tool, and the client automatically retrieves all related model elements, supporting conditional filtering and fuzzy search functions; in the model-to-requirement query, 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 hierarchical navigation.

[0076] In this step, the query results can be displayed in the form of a topology graph or a relationship graph, with nodes representing requirements or model elements and edges representing the traceability between them. The relationship types are distinguished by color or line type, and the graph supports interactive operations such as dragging, zooming, and clicking on nodes to view details. In addition, the client supports displaying the query results in matrix form, with rows representing requirement elements and columns representing model elements. If there is traceability, it is represented by a special identifier in the corresponding cell.

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

[0078] Step S6, implement requirement change impact analysis: based on the established traceability relationship, analyze the impact of requirement change on the model, which can traverse the traceability relationship to 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 relationship involved in the requirements, locates the model elements directly associated with it, and then further analyzes the interaction relationship of these model elements to identify the indirectly affected model resources. The system classifies the model resources directly associated with the changed requirements as direct impact, and the model resources triggered by the interaction relationship of the directly associated resources as indirect impact.

[0080] The present application makes full use of the OSLC standard, and realizes seamless integration of heterogeneous tools without large-scale modification through data standardization of requirement software and modeling software, greatly improves the universality and interoperability between tools, effectively reduces the implementation cost, provides bidirectional traceability between requirements and models, ensures the completeness of requirements and consistency of models, and significantly improves the quality management capability in the system development process. At the same time, the present application can flexibly define and manage the traceability relationship between requirements and models, support version control and change management, adapt to the needs of various development processes, and also improve the maintainability of the system, promote team collaboration, reduce the information island phenomenon, and help the efficient development of complex systems. In addition, the present application has high scalability, and the adapter and client design can be customized according to different requirements, and can support more tool integration in the future, providing a broad development space for complex system engineering.

[0081] Embodiment:

[0082] The present embodiment provides a requirement traceability method realized by using the above process, which specifically includes the following steps:

[0083] Step A1, based on the requirement software adapter developed in step S1 which can unify the data format, obtain the requirement data in the requirement management tool, and convert it into standardized data conforming to the OSLC resource description format, usually in RDF, JSON or XML format;

[0084] Step A2, based on the modeling software adapter developed in step S2, obtain the model data in the modeling tool, and convert it into a resource description format conforming to the OSLC standard;

[0085] Step A3, get the requirements and model data which have been standardized by OSLC by calling the RESTful interface of the adapter through the interactive interface in the client, parse the data and display it;

[0086] Step A4, select the requirements resource and modeling resource in the client interface, establish the traceability relationship for the selected resource and define the relationship type, such as "implementation", "dependence" or "implementation", update the traceability relationship to the adapter through the OSLC interface, and store it in the client database;

[0087] Step A5, perform consistency check, mark the uncovered requirements or isolated models;

[0088] Step A6, perform requirement change impact analysis, detect changes in requirement data, analyze the affected model resources through traceability relationship and mark them.

Claims

1. A requirement traceability method based on OSLC standards, characterized in that The method comprises the following steps: Step S1, developing a requirement software adapter: developing a requirement software adapter for a requirement management tool, the requirement software adapter can access data of the requirement management tool and convert the data into a resource description format conforming to an OSLC standard, and provides a RESTful interface for a client to access, and the specific steps are as follows: Step S1.1, requirement analysis is performed on the adapter, it is clear that the purpose of developing the adapter system is to obtain requirement data in the requirement management tool and perform OSLC standardization on the requirement data, after the target is clear, the resource types to be exposed by the requirement management tool and the service capabilities thereof are determined, for the requirement management tool, the core resource is a requirement, and management of the requirement is a main service provided by the requirement management tool; Step S1.2, a mapping relationship between data to be exposed by the requirement management tool and an OSLC resource is determined: projects in the requirement management tool are organizational units of requirements, a large number of requirements are contained in each project, and the hierarchical relationship is expressed through a relationship between a ServiceProvider and a ChangeRequest in the OSLC standard, the mapping relationship model is constructed by mapping the project into the ServiceProvider and mapping the requirement into the ChangeRequest, and after the mapping relationship is determined, the resource class is designed, and the resource in the target system is modeled; Step S1.3, the design of the adapter is expanded, including functional design and non-functional design, wherein: the functional design is concentrated on implementation of core services, that is, data standardization, and the non-functional design is concentrated on performance, availability, security and scalability of the system; Step S1.4, the adapter service is implemented, including creation of a service provider and implementation of CRUD operation; Step S1.5, authentication and security configuration are completed, wherein user identity verification and authorization are implemented by integrating an OAuth protocol; Step S2, developing a modeling software adapter: developing a modeling software adapter for a modeling tool, the modeling software adapter can access model data of the modeling tool and standardize the model data into data conforming to an OSLC resource format, and provides a uniform access interface; Step S3, designing a client application to obtain and display data: the client application obtains data resources conforming to the OSLC standard by calling adapter interfaces of the requirement software and the modeling software, implements a data analysis function in the client application, displays the obtained requirement data in a list form, and displays modeling data in a graphical form; Step S4, establishing a traceability relationship between requirements and models: the establishment and management of the traceability relationship between the requirements and the models are implemented through the client application, the traceability relationship established by a user in the client application is stored into a traceability relationship database, meanwhile, data in the adapter is updated, long-term maintenance and availability of the traceability relationship are ensured, and consistency checking is facilitated; Step S5, query and visual display of the traceability relationship: the client supports querying the modeling tool model elements related to a requirement from the requirement management tool, or tracing back to the corresponding requirement from a model element of the modeling tool, realizing the bidirectional traceability between the requirement and the model and displaying it in a graphical interface; Step S6, realizing the requirement change impact analysis: based on the established traceability relationship, the impact of the requirement change on the model is analyzed, the traceability relationship is traversed, the affected model resources are determined and displayed in the interface.

2. The OSLC standard based requirement traceability method according to claim 1, characterized in that The specific steps of step S2 are as follows: Step S2.1, requirement analysis of the adapter, the purpose of developing the adapter system is to obtain the model data in the modeling tool and to standardize it according to the OSLC standard, after determining this goal, the resource types and service capabilities to be exposed by the modeling tool are determined, for the modeling tool, the core resource is the model, and the management of the model is the main service provided by the modeling tool; Step S2.2, the mapping relationship between the data to be exposed by the modeling tool and the OSLC resource is determined: the model in the modeling tool is mapped to the ChangeRequest in the OSLC, in order to adapt to the OSLC standard, each model is mapped to an independent ChangeRequest instance, this mapping is realized by inheriting the ChangeRequest class, after determining the mapping relationship, the design of other resource classes is expanded; Step S2.3, expanding the design of the adapter, including functional design and non-functional design, wherein: the functional design mainly focuses on the implementation of the core service, i.e. data standardization, and the non-functional design focuses on the performance, availability, security and scalability of the system; Step S2.4, implementing the adapter service, including creating the service provider and implementing the CRUD operation; Step S2.5, completing the authentication and security configuration, wherein the verification and authorization of the user identity are realized by integrating the OAuth protocol.

3. The OSLC standard based requirement traceability method according to claim 1, characterized in that The specific steps of step S3 are as follows: Step S3.1, the client application obtains the data resources conforming to 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 a parsing module for requirement data and modeling data respectively, extract the key information, and display the parsed data in the form of a list, for the requirement data, provide an intuitive table or tree view to show the hierarchical relationship and detailed information of the requirement; use graphical tools to display model data in the form of a topology graph, a flowchart or other interactive views to show the interaction between system components.

4. The OSLC standard based requirement traceability method according to claim 3, characterized in that The data formats directly supported by the OSLC are RDF, JSON and XML.

5. The OSLC standard based requirement traceability method according to claim 1, characterized in that The specific steps of step S4 are as follows: Step S4.1, define multiple traceability relationship types to meet the system engineering requirements, including dependency relationship, implementation relationship and verification relationship, users manually select requirements and model elements through the client interface, create traceability relationships and specify their types; Step S4.2, store the traceability relationship established by the user in the client into the traceability relationship database, and update the data of the related resources in the adapter, the traceability relationship database contains the following key table structures: requirement table, model element table, and relationship table.

6. The OSLC standard based requirement traceability method according to claim 1, characterized in that The specific steps of the step S5 are as follows: Step S5.1, the implementation of the query function includes requirement-to-model query and model-to-requirement query, wherein: in the requirement-to-model query, the user selects a requirement in the requirement management tool, and the client automatically retrieves all model elements related to the requirement, supports conditional filtering and fuzzy search function; in the model-to-requirement query, the user selects a model element in the client, and the client traces back to the list of requirements associated with the model element, supports model element type filtering and hierarchical navigation; Step S5.2, display the query results in the form of a topology graph or a relationship graph, the nodes represent requirements or model elements, the edges represent the traceability relationship between the two, and the relationship types are distinguished by color or line type, the graph supports interactive operation, in addition, the client supports displaying the query results in the form of a matrix, the rows represent requirement elements, and the columns represent model elements, if there is a traceability relationship, it is represented 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.

7. The OSLC standard based requirement traceability method according to claim 1, characterized in that The specific steps of the step S6 are as follows: Step S6.1, when the requirements of the client are changed, the system automatically traverses the traceability relationship involved in the requirements, locates the model elements directly associated with the requirements, and then further analyzes the interaction relationship of the model elements to identify the indirectly affected model resources; Step S6.2, the system classifies the model resources directly associated with the changed requirements as direct impact, and the model resources triggered by the interaction relationship of the directly associated resources as indirect impact.

Images