You are required to read and agree to the below before accessing a full-text version of an article in the IDE article repository.

The full-text document you are about to access is subject to national and international copyright laws. In most cases (but not necessarily all) the consequence is that personal use is allowed given that the copyright owner is duly acknowledged and respected. All other use (typically) require an explicit permission (often in writing) by the copyright owner.

For the reports in this repository we specifically note that

  • the use of articles under IEEE copyright is governed by the IEEE copyright policy (available at

  • the use of articles under ACM copyright is governed by the ACM copyright policy (available at

  • technical reports and other articles issued by M‰lardalen University is free for personal use. For other use, the explicit consent of the authors is required

  • in other cases, please contact the copyright owner for detailed information

By accepting I agree to acknowledge and respect the rights of the copyright owner of the document I am about to access.

If you are in doubt, feel free to contact

Tailoring a method for system architecture analysis


Joakim Fröberg , Stig Larsson

Publication Type:

Conference/Workshop Paper


9th Annual Software Engineering Institute Architecture Technology User Network Conference, SATURN


SEI, Software Engineering Institute


The architecture of a system involves some of the decisions that, more than others, affect the outcome of a development effort in terms of meeting system goals, system qualities, and overall project success. Engineering the system architecture of a complex system involves the tasks of analyzing architectural drivers, identifying crucial design considerations, and performing decision making among alternatives. Systems engineering guidelines provide models and advice for what information entities to consider when engineering the architecture of a system, e.g., architectural concerns, but only limited guidance of how to do it. The guides are limited both in preciseness of definition of the information entities, e.g., what defines an architectural requirement, and also in process description, e.g., how do 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 on going 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 are applicable to the case, 3, Interpret meaning and make add-ons and changes necessary.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: 1. 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. 2. We interpret and define the concepts proposed by MFESA and define their relationships. 3. We propose a stepwise procedure for carrying out the work.To summarize, we have 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. In order 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.


author = {Joakim Fr{\"o}berg and Stig Larsson},
title = {Tailoring a method for system architecture analysis},
month = {April},
year = {2013},
booktitle = {9th Annual Software Engineering Institute Architecture Technology User Network Conference, SATURN},
publisher = {SEI, Software Engineering Institute},
url = {}