How do requirements become a software architecture?

Efficiently develop a verified product architecture

Author: Peter Schedl, IBM Germany GmbH

Contribution – Embedded Software Engineering Congress 2015

The industry-proven Harmony method for creating architectures for embedded products will be presented. The presentation will describe the interplay between requirements, functional architectures, and design. Particular emphasis will be placed on the importance of continuous verification of the development steps.

Challenge of architectural creation

For years, product development was driven primarily by mechanical and electronic components. Embedded software played only a minor role, typically programmed by a single developer. Consequently, software's importance, especially regarding quality, was also limited. This has now changed dramatically – software is taking over increasingly larger portions of overall product functionality, including safety-critical functions. Against this backdrop, software development techniques and their integration into the product development cycle are gaining entirely new significance. Typical questions then become: "How do I arrive at a product or system architecture, and how do I ensure traceability across the various levels?" The latter is particularly important in the development of safety-critical systems, as the relevant standards rightly require precisely this.

Regarding the topic of traceability, it should only be said that it is primarily a question of tool support and that OSLC (Open Services for Lifecycle Collaboration) [1] is a vendor-independent, cross-tool standard that, among other things, does exactly this.

Introduction to the Harmony Method

The question remains: "How do I arrive at an architecture?" IBM's Harmony methodology [2] provides a proven approach that answers precisely this question. Harmony has been used in industry for over 10 years and is continuously adapted. Therefore, it can be considered a mature methodology. Harmony relies on model-based development and early validation through model execution. It consists of two parts that can be used individually or in combination in projects. One (Harmony ESW) follows an agile approach with very small iterations, specifically designed for software development, including in embedded environments. The other (Harmony SE) follows a parallelized approach with larger iterations, originally intended for systems engineering. Combined, this results in an initial phase for defining a first system architecture, followed by small iterations within the individual domains (such as software development). Newer methods, such as SAFE (Scaled Agile Framework) [3], follow a similar approach. However, it has been shown that especially in product development, particularly in the context of development according to the V-model, Harmony SE is also used to create the software architecture in order to subsequently move to a secure implementation.

Inside Harmony: 1. Requirements Analysis

Harmony consists of three phases: requirements analysis, functional analysis, and design synthesis (see Figure 1)., PDF file).

The starting point for further action is a requirements document, for example, in the form of a customer or client specification document. This is imported into a requirements management tool like DOORS for further analysis and transformed into a system specification, and the system use cases are identified. Harmony uses a simplified SysML notation alongside textual requirements, with a reduced number of diagrams and elements, such as the use cases. This subset has proven effective through its use in numerous projects and can be configured as a profile in the tool, simplifying the initial setup due to its reduced selection.

Inside Harmony: 2. Functional Analysis

The use cases form the basis for creating the functional architecture. Each use case is translated into a simulable functional model, and the requirements are verified through model execution. A key aspect of this process is identifying and mapping the interaction of system functions in the form of an activity diagram. This diagram forms the foundation for all subsequent steps, whether it's deriving test sequences for later integration testing, generating system interfaces, or verifying the results through model execution.
It has been shown that modeling tools can save the user a lot of work here, as several steps can be (partially) automated.

For example, the Rhapsody tool offers a large number of such automated processes, such as generating test sequences from activity diagrams. The result of this phase is a verified black-box view of the system with its interfaces, including traceability to the system requirements for the individual use cases.

Inside Harmony: 3. Design Synthesis

In this phase, an architecture for the system is created based on the identified functions and interfaces, and the elements are mapped accordingly. Thanks to the preliminary work and by applying typical best practices, such as minimizing the number of interfaces between components, an initial architecture quickly emerges, which is then refined in subsequent iterations. In each iteration, the use case models are integrated into the architecture. The mapping process is again automated.

To ensure the correctness of the integrated model, it is executed again, and its consistency with the previous phase is verified, similar to a regression test. The result of this phase is a stable system architecture in the form of a verifiable model and the linked requirements, from the component level through the system specification back to the customer requirements.

Importance of verification

Verification of each step is of considerable importance – especially in the early phases of a project, where uncertainty is typically greatest and the impact of errors is most dramatic.

Of course, verification requires effort, whether it's linking the requirements to each other and to the model, or using metrics and reviews, all the way to simulation. It's no coincidence that many standards require this, especially those for the development of safety-critical products. Early model execution, in particular, repeatedly reveals errors that are difficult to detect in later phases and would therefore most likely only be discovered, if at all, at the very end of development.

However, even using it within Harmony for automated review of architecture creation is more efficient and, overall, involves less effort than manual review.

Bibliography and list of sources

[1] Open Services for Lifecycle Collaboration (OSLC): open-services.net

[2] Harmony Community: https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=dbc39547-3619-4c31-9535-0b583a4e6190

[3] SAFE: www.scaledagileframework.com

Download the article as a PDF file