EN 
DE Possibilities and approaches for integration into the development process
Author: Antonio Jesus de Loureiro, agosense GmbH
Contribution – Embedded Software Engineering Congress 2015
Software and systems development is virtually inconceivable today without a methodological approach – not least for reasons of product safety and quality, and the associated traceability of activities and results. Application Lifecycle Management (ALM) tools and platforms help support various practices and methods by visually representing dependencies between development artifacts and activities. But is that enough?
A closer look at development organizations reveals that products are rarely created from scratch. In many cases, existing products are further developed, improved, or serve as a template for additional product variants. Viewed in this light, a large portion of development activities is characterized by modifications to existing products. And these modifications, or rather their management, don't begin only with implementation or in the production phase, but much earlier in the product development process – for example, during requirements management.
Efficient work requires the reuse and modification of existing artifacts or documents and optimal support for these methodologies by the ALM tools used within the development process. This approach has been known for a long time and is already established in the field of version control and source code management with terms such as checkpoints, baselines, variants, versions, change lists, etc.
But why shouldn't it be possible to make these possibilities available for practical requirements management? The challenges and questions are virtually identical. How can baselines or variants be used for requirements planning? Or how can planned changes to a specification for a new product iteration be explicitly extracted and applied to an existing requirements document? How can it be quickly and easily shown which task or change request underlies a specific change to a specification?
Since then, 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 is now changing with agosense.requirements. 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 to ensure that development activities can be precisely reproduced 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 according to the established process.
To make this process as efficient as possible and, above all, to ensure that the implemented changes actually correspond to the plan, agosense.requirements 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 (see also Fig. 1, PDF).
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.requirements using the interface technologies provided by agosense. This integration allows, among other things, the associated planning artifacts from change management to be directly selectable by the user in agosense.requirements. 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.
In agosense.requirements, 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 ("Apply"). Simultaneously, the corresponding status of pending tasks or change requests in the respective linked system is also updated (see also Figure 2, PDF).
Depending on the maturity level or formality of the predefined work processes, the specifications undergo a review process before they are actually released for implementation. In our example, this means that for each change request, the respective change set goes through the review process. The reviewer is presented with detailed information about the specific changes in an integrated diff view. In this view, comments can be added and corrections or rework requested before a change set is released. Once all change sets for a specific release level have been accepted, a baseline for the document can be generated, which then represents the released version.
Here too, the approval process can be controlled via the integrated change management system. For example, the reviewer can access the change set view in agosense.requirements directly via a hyperlink in the change request – depending on the user's preferred workflow.
As previously described, branches are key functions when it comes to defining product variants or creating derivations from existing product definitions. Therefore, it is essential to have these functions available as an integral component of requirements management.
Few tools on the market offer true branching, and when they do, it's often only available via add-ons. These add-ons typically rely on cumbersome copying mechanisms that unnecessarily inflate data storage in the background and slow down the application over time. agosense.requirements offers native support for true branching. Documents or requirements are not generally duplicated. The architecture of agosense.requirements is designed so that individual requirements are reused or referenced within branches and, thanks to the implicit versioning engine, do not need to be copied.
All functionalities described here also apply outside of branches, and it is of course possible to compare each document variant (whether Baseline, Variant, Tentative or Base) with each other in any combination in the Diff-View.
If simple branching is no longer sufficient for specific customer requirements, for example, if a description of function trees with corresponding dependencies needs to be specifically managed when creating product variants, then agosense.requirements offers the possibility to directly integrate variant management systems, such as "pure::variants" from pure-systems GmbH.
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 nowadays to extend the domain of requirements management to include planned change management? This will be explained below using a few brief examples.
Assuming a requirements document has been released and the product is already being developed based on this specification: What is necessary to best incorporate subsequently changed requirements? Because the requirements cannot simply be changed; they must now be integrated into product development as part of a planned change process.
- 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 modified 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, and especially into 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 tool offers open interfaces and can be seamlessly integrated into their existing tool landscape (e.g., with test management, modeling, change management, etc.). However, very few vendors have a strategy for integration once 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-critical products, such as automobiles, 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 can only be achieved through integration, as most companies have highly heterogeneous tool environments and data storage systems.
agosense.requirements provides optimal support by displaying trace information for data from other tools directly in a view, and even allowing users to create or edit it within that view. This makes it possible to establish cross-tool traceability and present it in real-time reports via dashboards in agosense.requirements.
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
Requirements management rarely begins from scratch these days. This means that existing product versions or variants are defined and developed in parallel. It is precisely at this point that planned changes often become disconnected from the concrete content of the requirements and specifications. As a result, it is usually no longer possible to trace in detail which individual changes have been incorporated into a document. While it is generally still possible to identify the differences between two milestones or baselines, a detailed correlation between granular changes within a document and the planned or implemented changes is no longer feasible.
This article illustrates how a tool-supported methodology can establish this connection and fully integrate requirements management into the modern development process. New possibilities for establishing change-based requirements management with clearly defined responsibilities 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.
