EN 
DE Questions, opportunities and best practices for cross-domain traceability
Author: Bernd Röser, agosense GmbH
Contribution – Embedded Software Engineering Congress 2017
Software and systems development is virtually inconceivable today without a methodical approach – not least for reasons of product safety and quality, and the associated traceability of activities and results. Dependencies between the respective development artifacts and activities should be clearly depicted to enable rapid analysis when changes are made to these artifacts.
Until now, establishing a controlled and, above all, comprehensive change process in the domain of requirements management has been laborious and only possible with considerable manual effort. In most cases, the integration between requirements and change management is limited to simply linking requirements and change requests. These links are usually created manually and are not actually binding or verifiable. After all, how can this ensure that requirements cannot be changed without authorization, or that the changes actually made truly correspond to the planned changes?
This changes with the use of agosense.fidelia. The methodical approach of this tool allows every change to a document/requirement to be recorded and, furthermore, enforces that a document can only be edited in conjunction with an associated task or change request.
In regulated industries, it is essential to document every single development step in order to accurately reproduce development activities at any later time. To enable this, further developments and changes are recorded, planned, and assigned to the responsible individuals or groups. These development steps are then reviewed and approved within the framework of the predefined process (see also Figure 1)., PDF).
To make this process as efficient as possible and, above all, to ensure that the changes implemented actually correspond to the plan, agosense.fidelia records all granular changes to the document (here: "sheet"). For this purpose, the system creates a so-called "change set" for each task or change request, in which the edits to the document are automatically recorded in granular detail – similar to how software version control tools already work.
The change requests or tasks linked to the change sets typically originate from existing change management systems (e.g., IBM RTC, Atlassian JIRA, etc.), which are directly integrated with agosense.fidelia using the interface technologies provided by agosense. This integration allows, among other things, the user to directly select the associated planning artifacts from the change management system within agosense.fidelia. Naturally, information about changes, change sets, approvals, and much more can also be transferred back to the change management system.
Change sets represent an isolated set of changes to a document, assigned to a task, change request, etc. These changes can then be incorporated into the document, for example, through a structured approval process. This ensures that a document version precisely matches the plan and that changes can be traced down to the character level at any time (see also Figure 2)., PDF).
In agosense.fidelia, the current, released version of a document is referred to as the "Base." To edit this version (or an older version of a document – then in a branch), the user simply selects an assigned task and begins editing. A "Tentative" version of the document is automatically generated from the Base version, serving as the working copy for editing.
From this point on, all changes to the document version are automatically recorded in the change set. Once the work is completed, the user can submit their change sets for review or add them directly to the document, depending on the desired process. During this process, the changes are officially transferred to the base version as valid ("Apply"). Simultaneously, a corresponding status change occurs for the pending tasks or change requests in the respective linked system (see also Figure 3)., PDF).
As mentioned in previous sections, embedding requirements management in the overall development process is of great importance. The following section will explain where the typical points of contact lie and how these can be implemented in the best possible way to meet today's requirements for traceability and comprehensibility.
To what extent is it necessary today to extend the domain of requirements management to include planned change management? This will be explained below using a few brief examples:
- Changes must first be evaluated based on various criteria (e.g., costs, risk, ...).
- Dependencies must be checked: test cases, use case models, etc. may also need to be changed.
- The specification itself must be changed and released.
- Changed requirements must be communicated and passed on for implementation.
To efficiently accomplish all these tasks, a deep integration of requirements management into all other directly adjacent domains, especially global change management, is essential.
Requirements management has become an integral part of the development process and can no longer be considered in isolation. Therefore, it is crucial for most companies that their requirements management (RM) tool offers open interfaces, allowing for integration into their existing tool landscape (e.g., with test management, modeling, change management, etc.). However, very few vendors have a strategy for integration when it extends beyond their own product portfolio. This often leads to significant effort and frustration for customers, especially when it comes to maintaining these (usually custom-developed) integrations and providing support. Furthermore, the in-depth knowledge and expertise required for tool integration across all the tools involved is often underestimated.
Ideally, manufacturers of requirements management tools should offer at least open interfaces for all possible integration technologies and, ideally, also have a clear strategy and corresponding expertise in this area. agosense has a clear strategy, years of experience in tool integration, and offers the agosense.symphony integration platform as an optimal complement.
Especially with safety-relevant products, legal regulations require that certain maturity levels be guaranteed within the product development process. This is intended to fundamentally improve product quality, but also to help reconstruct any potential chain of errors at any time for root cause analysis – all the way back to the starting point, the product requirements. Ultimately, this is only achievable through integration, as most companies have highly heterogeneous tool environments and data storage systems.
agosense.fidelia provides optimal support in this regard by displaying trace information for data from other tools directly in a single view, and also allowing users to create and edit such information within that view. This makes it possible to establish cross-tool traceability and present it in real-time reports via dashboards in agosense.fidelia.
Organizations characterized by tightly organized planning and development processes are given, for the first time, the opportunity to easily ensure the complete traceability of all activities, right up to requirements management.
Summary
Almost all safety standards today require the traceability of requirements across the various development artifacts, all the way back to the source code or test results. This is intended to fundamentally lead to improved product quality, but also to help – in terms of root cause analysis – to reconstruct any potential chain of errors at any time.
When cross-reference lists are used in Excel, it quickly becomes apparent that the effort required for their creation, and especially for their maintenance, can be very high. Furthermore, maintaining Excel lists is hardly a developer's favorite task and is prone to errors.
This article illustrates how a tool-supported methodology can establish this connection and fully integrate requirements management into the modern development process. In addition to traceability within a domain, a cross-domain perspective is also crucial for change analysis in networked systems. This allows the impact of a planned change to a specification on other domains, such as test scenarios or standards, to be tracked. These new possibilities for establishing traceability across domain boundaries and sustainably increasing the depth of traceability in development significantly improve communication and coordination between different responsibilities within requirements management and the entire development process.
Requirements – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
