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.