search menu icon-carat-right cmu-wordmark

Tailoring a Method for System Architecture Analysis

May 2013 Presentation
Joakim Fröberg (Mälardalen University), Stig Larsson (Effective Change AB), Per-Åke Nordlander (BAE Systems AB)

A presentation from the ninth annual SATURN conference, held in Minneapolis, MN, April 29 - May 3, 2013.

Publisher:

Software Engineering Institute

Abstract

The architecture of a system involves some decisions that affect the outcome of a development effort more than others in terms of meeting system goals, system qualities, and overall project success. Engineering the system architecture of a complex system involves analyzing architectural drivers, identifying crucial design considerations, and making decisions among alternatives. Systems engineering guidelines provide models and advice for what information entities to consider when engineering the architecture of a system, such as architectural concerns, but only limited guidance of how to do it. The guides are limited both in preciseness of definition of the information entities, such as what defines an architectural requirement, and in process description, such as how the information entities relate and what order to proceed through the work tasks. These questions need to be addressed by any development team that faces an architectural driver analysis in an actual case.

We are currently performing system architecture analysis in a project developing a hybrid electric drive system for heavy automotive applications. Our analysis method is instantiated using the Method Framework for Engineering System Architectures (MFESA). We also used elements of other theories, including CAFCR, QAW, and ATAM. Execution of the project is ongoing, and roughly half of the method activities have been carried out so far.

The steps we have performed in order to instantiate and tailor the method are summarized: (1) Define the criteria for what practitioners perceive as a practical method for analyzing system architecture, (2) instantiate a method by tailoring the MFESA tasks that apply to the case, and (3) interpret meaning and make add-ons and necessary changes.

We have instantiated a method from the MFESA framework. Based on the practitioners' criteria, we alter the method to suit the case. We point out three additions that are not directly derived from the MFESA framework and could be useful in other cases. The most significant changes were as follows:

  • We employ use cases as a means to model and identify architecturally significant requirements. We choose to start with use cases and progress by elaborating the architecturally significant ones by defining detailed scenarios.
  • We interpret and define the concepts proposed by MFESA and define their relationships.
  • We propose a stepwise procedure for carrying out the work.

To summarize, we participated in a development project and were given the task to provide a system architecture definition. We defined our method by using the MFESA framework and added some method components from other theories. Still, the resulting method is not directly applicable. To perform the method, we had to clarify the interpretation of some of the work products and define the relationship between information entities. In addition, we had to specify a stepwise working procedure. Some of the additions could be considered as case-specific tailoring, and some may be useful in general. We present lessons learned from this case and discuss a possible validation effort for an architectural analysis method.