Transition from Requirements to Architecture: A Review ... - IEEE Xplore

Transition from Requirements to Architecture: A Review and Future Perspective Matthias Galster Department of Electrical and Computer Engineering University of Calgary Calgary, AB, Canada [email protected]

Armin Eberlein Department of Computer Engineering American University of Sharjah Sharjah, United Arab Emirates [email protected]

Abstract Elicitation, modeling and analysis of requirements are main challenges during software development. In parallel, Software Architectures have become a well established area in Software Engineering research and practice. However, there is still a lack of fundamental process models and guidelines for the transition between the two important phases of Requirements Engineering and Software Architectures within the software development cycle. Substantial progress has been separately made in both areas but very little research achievements can be found that address the relation between requirements and architectures. When doing a review on existing methods that try to overcome this gap we realized an urgent need for fundamental research in this area. The paper first presents, compares, classifies and evaluates the suitability of current approaches. Then, evaluation criteria and requirements for a transition methodology are defined. Finally, directions for further research are presented.

1. Introduction There is a strong agreement in industry as well as in academia that Software Requirements Engineering and Software Architectures are crucial factors for the success of a software project and the quality of its products. The outcome of Requirements Engineering and the design of Software Architectures have tremendous impact on all remaining aspects of the software development cycle (e.g. implementation, testing). However, research progress has mainly been achieved within these areas in separation [1]. It is only recently that more attention has been paid to bridging the gap between these two stages (e.g. STRAW’01,

STRAW’03, IEE Proceedings Software [2]). Nevertheless, there is still a lack of systematic guidelines, processes, and tools that provide support when building architectures based on requirements. The next section of this paper gives a more detailed problem description; section 3 presents further information on existing methodologies and a classification. In section 4 we present the context of research, then define requirements and suitability criteria for a transition process in section 5 and propose steps for further research in section 6. The objective of this paper is to provide an insight into the current status of missing links and relations in the two fields of requirements and architectures. Additionally, we propose evaluation criteria for current approaches, requirements for a transition methodology, and directions for further research.

2. The Problem Pressman emphasizes that we must design architectures explicitly [3]. We will otherwise spend the rest of the software development project trying to make the design fit the requirements. Even so, we are still unsure if all the requirements and their intents are considered in the final system. Having about 2,500 distinct statements of requirements in a typical medium-sized software development project [4] results in high complexity. It makes it difficult to meet all functional and non-functional requirements when designing or modifying a software architecture because each requirements statement may result in a variety of development specifications and rationales. There are three main reasons why we need to care about architectures: Firstly, they support communication among stakeholders and create a basis for mutual understanding, and negotiation. Secondly, architectures represent early design decisions and

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

Mahmood Moussavi Department of Electrical and Computer Engineering University of Calgary Calgary, AB, Canada [email protected]

allow further analysis of the system. Thirdly, they provide developers with an implementationindependent, reusable and transferable abstraction of the future system [5]. Generally, a good architecture is characterized by high modularity, high cohesion, and low coupling [6]. The transition process from requirements to architectures requires expertise and extensive resources. Currently, this process is mainly based on experience, intuition, communication, and domain knowledge of architects and designers. This makes the quality of the architecture and design heavily dependent on the skills and cognitive capabilities of developers [7]. In other words, architecting and designing systems is still done in an ad-hoc, unsystematic and informal manner [8]. Moreover, many organizations struggle in defining good software architectures. Architectures often solve the wrong problem, their importance is not seen by stakeholders or not understood by developers, or the created architecture does not support subsequent steps in the development process [9]. Consequently, this reduces the capability of an architecture to support communication, further analysis of requirements and constraints, and for system’s feasibility evaluation. In addition, the architectural design becomes less appropriate for subsequent architecture-based implementation, which, in turn, results in poor quality of the final software product. Software Architectures have long been recognized as having a profound impact on the achievement of functional and non-functional goals [10]. Therefore it is surprising how little research has been done so far towards systematic architecture derivation and refinement based on requirements. Research in this area is one of the open challenges in Requirements Engineering [11].

3. State of The Art In the following sections we present the current state of research in the area of bridging the gap between requirements and architecture. In the last subsection we introduce a classification that allows the comparison and evaluation of methodologies.

3.1. Architecture (ADL)

Description

Languages

Description: ADLs provide precise and abstract architecture descriptions by representing information, components, relations, and constraints using formal techniques. Several ADLs have been proposed, e.g. Wright [12], Rapide [13], UniCon [14], SDL [15] or

CSP [16]. ADLs can be supported by module interaction languages (MIL), hardware description languages (VHDL), and object-oriented CASE tools. A good classification framework that also provides an extended overview on ADLs can be found in [17]. Features and Contribution: ADLs provide all advantages of formal descriptions (e.g. validation, verification). Each ADL focuses on different aspects or supports particular features (e.g. architectural styles, real-time systems, user interfaces, refinement). On the other hand each ADL lacks in certain areas (e.g. asynchronous / synchronous communication, component behavior) or is domain specific. ADLs also lack a semantic model that is common to all of them. This requires the use of an interchange language [18]. Moreover, formal methods in general have a significant learning curve and are not widely accepted in practice [19]. Overall, ADLs focus on explicit functions and data and neglect non-functional aspects which are more difficult to represent [3]. Additional problems with ADL can be found in [20] . ADLs offer means of representing Software Architectures; however, they do not adequately support the transition from requirements to architectures.

3.2. Goal-Based Approach Description: The approach performs a transition from requirements to architecture to meet functional and non-functional requirements [8]. It can be regarded as a combination of qualitative and formal reasoning based on KAOS [21]. Related approaches are: the NFR framework [22], Gross’ agent-oriented extension [23], Perry’s empirically motivated work [24], and the Preskriptor process which is a prescriptive architecture specification language that provides a high-level architecture [25]. This list shows that goal-oriented techniques are quite popular when trying to bridge the requirements – architecture gap. Features and Contribution: The process starts with analyzing the global impact of goals on architectures. The software specification is created based on underlying system goals by deriving requirements. Functional specifications are considered in the architectural draft that is built in a second step. This draft is then refined to fulfill the domain constraints. The final architecture which complies with all non-functional requirements is achieved using recursive refinement. This approach supports intertwinement of requirements and architecture creation and allows the extraction of different views (e.g. security view, fault tolerance view). One drawback is the qualitative reasoning in the refinement process that should be more formal to allow

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

extended tool support. Also, when architectural features need to be propagated bottom-up this approach is limited as it focuses on refinement. A combination of bottom-up and top-down might help. Furthermore, the relation between global architecture decisions at early stages of the process and the final refinements to meet all non-functional requirements should be more explicit.

3.3. Problem Frames Description: Problem frames allow the classification of software problems and the decomposition of a large problem into sub-problems. These sub-problems can then be solved and combined into a solution of the original problem [26]. Features and Contribution: Problem frames can express the relationship between requirements, domain properties, and machine descriptions. When bridging requirements and architecture, problem frames can model the organization of requirements in the architecture. This allows us to deal with undesired effects, e.g. overlapping event reactions. The hierarchical solution structure ensures scalability of the system and traceability of architecture decisions. Problem frames describe architectural structures, services, and artifacts as part of the problem domain. The developer can focus on the problem domain instead of inventing solutions because the idea is to delay solution space decisions until a good understanding of the problem is gained. A drawback is that it is not clear if the notation covers all aspects for creating proper architectures.

3.4. Use Case Maps (UCMs) Description: UCMs present scenarios as visual behavior structures, manipulated, reused, and understood as architectural entities. The primary objective is to ease understanding in all phases of development by neglecting details. UCMs can also be used to describe how organizational structures of complex systems and behavior are intertwined [27]. Features and Contribution: UCMs show causal paths directly between responsibilities in organizational structures of abstract components. They combine behavior and structure into one view and allocate responsibilities to architectural components [28]. Related use cases are shown in map-like diagrams. These diagrams focus more on a dynamic picture, not on source code organization. UCMs provide a light-weight notation that scales up, while covering complexity factors. All artifacts of UCMs (i.e. paths, components, responsibilities) can be

developed in different orders, depending on the starting point and objective. That makes UCMs useful for requirements exploration and architectural design. Details can be added when needed by using notations like UML, ADL, and by providing additional system views and transformations. UCMs can be combined with formal descriptions such as the User Requirements Notation (URN) [29] and the Goaloriented Requirements Language (GRL) [30]. The lack of well-defined semantics and the large human input required when using UCMs may be seen as a disadvantage.

3.5. Model Bridging Description: Many different types of models are used during software development which causes information discontinuity. Model bridging was proposed by Medvidovic et al. [31] and uses connectors to connect models of requirements and architectures. Features and Contribution: The objective is to overcome information inconsistency across models. The procedure is based on the WinWin model [31] to refine artifacts into design decisions. The goal is to close the large semantic gap between high-level requirements and low-level architecture artifacts. Core of the approach are synthesis (defined by the approach as transformation of model information) and analysis (defined as comparison of model information). Complexity and properties are hidden within connectors. The authors use the CBSP (Component, Bus, System, Property) approach which creates intermediate models to bridge Requirements Engineering and Software Architectures [32]. Tool support is provided for CBSP but significant human involvement is required. One difficulty of this approach is the lack of precise guidance on how to assign a Win condition to one CBSP artifact. Additionally, the methodology recommends optimized CBSP views and suggests key architecture elements but, on the other hand, does not provide detailed instructions for achieving the topology of these elements. Finally, each architectural model may require elements which are not part of the requirements model and vice versa. A more detailed approach is necessary to identify and define these elements. Model bridging also can be done with Data Flow Diagrams to transit between analysis and design, or Feature-driven mapping [33].

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

3.6. Rule-Based Decision Making Description: This framework is based on the assumption that architectural decisions are labor intensive and difficult to make [34]. The framework supports automated reasoning for eliciting architectural decisions based on requirements. Features and Contribution: The framework consists of two main modules, a reasoning module and a presentation module. The reasoning module contains a mapping process which allows the generation of decision trees. These trees provide guidance through the decision making process. They are used to manually map each requirements specification into architectural properties. An addition to the actual transition process is the capturing of mappings and the process of mapping to study how decisions are made. This supports later architectural decisions. Again, significant human interaction is required to perform the transition from requirements to architecture.

3.7. Architecting Requirements Description: By structuring and organizing requirements we may be able to identify components for a prospective architecture already during the Requirements Engineering phase, before actual design and implementation [35]. Features and Contribution: The methodology is based on a requirements hierarchy created by applying a requirements hierarchy method defined by the approach. This method models entities and relationships. It allows a dynamic adaptation of the architectural structure and the derived architecture components, even with changing requirements. Compared to the approaches mentioned so far, this work uses new ideas to solve the problem of transition from requirements to architecture. One question still open in this approach is what kind of architectural representation is generated as output of the process and what aspects of an architecture are addressed. Also, the way interactions are handled could create some restrictions when developing different levels of architectural granularity. Additionally, the impact of environmental factors handled by the approach in later stages should be considered in earlier stages of development as they might have an impact on early architecture decisions.

3.8. Object-Oriented Transition Description: The idea of this methodology is to transform the object-oriented output(s) of the

Requirements Engineering phase (analysis) into an object-oriented architecture / design. Features and Contribution: Traceability seems to be possible in object-oriented models. Nevertheless, they do not provide a complete solution for mapping requirements into architectures. This is due to the fact that internal structures of a system are described from a developer’s point of view in the design; object-oriented analysis describes the user view. Both stages present different information or lack information that is of interest to the developer or the customer [36]. Moreover, a transition from analysis objects to design objects implies that real world objects become software objects and that the object-oriented analysis model deals with internal design. Following this, objects at different stages have different abstractions levels and different purposes. As a consequence objectorientation does provide similar models but does not allow mapping between the requirement and architecture stage.

3.9. Weaving Requirements and Architecture Processes Description: Nuseibeh proposed weaving the requirements process and the architecture process [37]. He argues that early understanding and construction of an architecture provides a basis for discovering further requirements and constraints, for evaluating the system’s technical feasibility, and for determining alternative design solutions. Features and Contribution: Software companies usually chose either requirements or architectures as starting point for development. This leads to inflexible requirements documents or constrained architectures that resist changes in requirements. The proposed Twin Peaks Model (TPM) intertwines requirements and architectures for incremental development. In practice, the separation of requirements and design steps is difficult because their artificial ordering forces us to focus on either aspect at any given time. In reality candidate architectures can constrain requirements and vice versa. The TPM is a kind of spiral life-cycle model covering the requirements and design / architecture stages. The approach provides a robust and realistic development process that allows working concurrently and iteratively describing the future system. This idea provides a high level-process framework and no detailed description on how to perform the transition. Additionally, it does not provide information on what software architectures are stable when dealing with changing requirements. Which requirements are more stable than others or what kind

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

OO Transition no sf TR

analysis refinement CS no more no partially n/a yes no both no dynamic TR n/a sf Weaving Processes AR = Architecture, RE = Requirements, TR = Transition, f = formal, sf = semi-formal, OO = Object orientation, CS = Case Study, ICS = Industrial Case Study

TR refinement analysis

dynamic analysis, modeling single view

dynamic no

no both

both no

no no

no n/a

n/a no single no

OO

n/a

partially

n/a no single no

Model Bridging

Rule-Based DM refinement RE, TR yes sf n/a dynamic

no sf no

no both

both no

no yes

no WinWin

n/a n/a

no functional no yes n/a

partially

no CS n/a more

UCM no sf

Problem Frames no sf no both no

dynamic

n/a (3) single view AR elicitation, refinement, RE modeling, analysis more views refinement, static analysis, modeling RE more views refinement, dynamic analysis, modeling RE layering modeling refinement AR, TR dynamic CS yes single no

(15) Tool support (16) Application

partially

(14) Iterations

no

(13) Domain specific

n/a

(12) Code derivation

CS yes

(11) Relation to existing RE methodology

partially Problem Frames yes

(10) RE Change

yes f

ADL (9) RE prioritization

CS no single no

• Requirements- and feature interaction play an important role and impact the development of architectures. In our context it is helpful to detect these interactions already in the requirements specification to avoid problems later on when defining component interactions in the architecture. • Component-based development allows the reuse of existing artifacts and knowledge for building new systems. • Investigating multiple viewpoints covering partial requirements definitions that need to be transformed into architectures can help in creating a proper transition methodology. • Reference architectures and their role in the transition process need to be investigated. • Investigating multiple viewpoints covering partial requirements definitions that need to be transformed into architectures can help in creating a proper transition methodology. • Research regarding the bridging between informal and formal approaches in software development could bring benefit also in our problem domain.

(8) Functional or nonfunctional aspects

no

(7) RE classification

partially dynamic

The requirements – architecture transition cannot be investigated in isolation. We identified several related fields:

both

(6) Component interaction

functional

4. Broader Context of Transition Research

no

(5) RE phase

no

(4 ) Level of detail

n/a

(3) Transition focus

no appropriate Goal-based RE no partially

Criterion (1) Notation (2) Novel representation

ICS yes single yes appropriate

Table 1 shows a summary of previous transition approaches in form of a classification according to several criteria. To the best of our knowledge, no current approach provides a complete solution for direct mapping between requirements and architectural aspects. Such direct mapping would require a greater focus on components already during the Requirements Engineering phase. Even so the approaches described in sections 3.3. and 3.7. have greater focus on components, they do not allow total direct mapping. Another important aspect is the classification of requirements and architectural aspects with respect to their impact on the architecture. This is only partially supported by approach 3.2. As we realized in almost all methodologies, considerable human input is required to perform the transition from requirements to architecture.

no sf

3.10. Summary of Previous Research

Goal-Based

Approach

yes sf Architecting Requirements

Table 1. Classification of approaches

ICS yes more

of changes can occur in a system are also open issues when applying the TPM.

• Social, organizational and business aspects which affect architectures could be investigated for building architectural styles.

5. Requirements for the Transition Process A transition procedure must provide certain features to allow helpful and successful guidance. The following lists requirements for a comprehensive transition procedure that aids in the transition from requirements to architectures. These requirements may be tailored for specific domains. The transition procedure must • provide a recursive and iterative process model, • allow the development of various architecture candidates, • support trade-off analysis of architecture candidates, • have an underlying formal approach that allow tool support and enforces consistency and completeness of architecture candidates, • manage different architectural views and their relationships, • support the reuse of existing architecture knowledge (e.g. in form of a pattern library), • allow knowledge sharing throughout all transition stages, • trace rationales behind design decisions, • allow convenient descriptions for humans to apply despite a certain level of formality, • be able to handle various requirements and design notations. Moreover, it must perform activities known from the Requirements Engineering domain:

6. Proposed Research

1.

2.

IEEE

Further

Deeper research into the impact of requirements on software architecture, i.e. which requirements affect which aspects of an architecture and how strong this impact is. Some research has been done regarding requirements volatility [39]. Addressing the problem from different perspectives and domains than done so far and learning form other disciplines that have similar characteristics.

A coarse grained framework for a process model is presented below (figure 1). The idea is to reduce the complexity of the overall transition problem by categorizing requirements into two sets. For the requirements in set A we have knowledge from previous architecture solutions in a pattern library. However, for set B we do not have previous architecture knowledge. This allows us to perform a pattern-based transition for requirements of set A. A

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

for

Our studies of the problem have shown that there are three future directions for research in this area: Firstly, we can try to understand the problem from inside by doing empirical studies on the current practices in research and in industry. Secondly, we can address the problem directly from the requirementsand architecture domain and find direct solution approaches based on existing techniques. Almost all of the presented methods took this approach. Thirdly, we can look at the problem from other domains or perspectives, such as other engineering disciplines or domains which share commonalities with our problem, i.e. supporting requirements and representing information in architectures. We used the latter as starting point for further research and looked at Civil Engineering, Systems Engineering, and the construction discipline. We found that these domains deal with similar problems. We might benefit from process frameworks and progress made in these areas. One example is the application of the Dependency Structure Matrix (DSM) in the Architecture/Engineering/Construction industry. It extends the activity-based DSM applied in systems engineering and focuses on parameter-based integration of low-level design processes based on physical parameter relationships [38]. This could be a starting point for low-level architectural design. Based on the previous findings we conclude that considering the following two points brings the main benefits towards a solution for the problem:

• Evaluate the global impact of requirements on the system in general and its architecture in particular. • Represent changing requirements in the system in general and its architectural structure in particular. As already suggested before in [34] it is beneficial for the transition to support at least a partial mapping of requirement properties and architectural structures. Also, the identification of frequent design decisions helps in the reuse of previous architecture solution knowledge. Risks could guide architectural decisions. Therefore, an approach must provide us with solutions that allow a balance between short-term project goals, long-term organizational goals and risks implied by the architecture.

Direction

second solution space can be generated for requirements in set B by doing a basic transition. This task is more difficult than the previous one. In a last step the two solution spaces are merged to the final solution space. Each result of the basic transition will become part of the pattern library. This allows us to reuse architecture solution knowledge for future requirements and their architectural representation.

made in Software Engineering and Requirements Engineering. Based on this we conclude that there is a need to do further research and presented a direction for future work. The requirements presented for a transition process could give a first guidance towards more sophisticated approaches. Our objective is to do more fundamental research to understand the problem from different perspectives instead of adapting and extending existing Requirements Engineering techniques towards architecture building.

8. References

Figure 1. Process overview Key activities in this framework are the classification in the classification module, and the transition of requirements in set B. For the basic, nonpattern-based transition process (i.e., requirements in set B) we need to provide proper guidelines for the translation of requirements into architectures. This is based on the idea that a transition process can be seen as a transformation or translation of one representation of information into another one, with changing intent.

7. Conclusion In this paper we discussed why there is still a need for doing fundamental and extended research to close the gap between requirements and software architectures, and to understand the relationship between these two development stages. We first gave an overview of the problem and then presented a short review of existing approaches which try to solve this problem. From this we could see that the current transition benefits from different achievements already

[1] D. M. Berry, R. Kazman, and R. Wieringa, "Second International Workshop on From SofTware Requirements to Architectures (STRAW'03)," 25. International Conference of Software Engineering (ICSE'03), Portland, USA, 2003. [2] J. G. Hall, I. Mistrik, B. Nuseibeh, and A. Silva, "Relating Software Requirements and Architectures," IEE Proceedings Software, vol. 152, pp. 141-142, 2005. [3] R. S. Pressman, Software Engineering - A Practitioner's Approach. New York: McGraw-Hill, 1992. [4] A. Finkelstein and W. Emmerich, "The Future of Requirements Management Tools," in Information Systems in Public Administration and Law, G. Quirchmayr, R. Wagner, and M. Wimmer, Eds., Austrian Computer Society, 2000. [5] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice. Boston, MA: Addison-Wesley, 2003. [6] E. Braude, Software Design - From Programming to Architecture. Hoboken, NJ: John Wiley & Sons, 2004. [7] P. Kroll and P. Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Reading, MA: Addison-Wesley, 2003. [8] A. v. Lamsweerde, "From system goals to software architecture," in Formal Methods For Software Architectures, vol. 2804, Lecture Notes in Computer Science, M. Bernardo and P. Inverardi, Eds., Springer Verlag, 2003. [9] R. W. Schwanke, "Architectural Requirements Engineering: Theory vs. Practice," The Second International Workshop on Software Requirements and Architectures (STRAW '03) at ICSE'03, Portland, OR, 2003. [10] D. E. Perry and A. L. Wolf, "Foundations for the Study of Software Architectures," ACM SIGSOFT Software Engineering Notes, vol. 17, pp. 40-52, 1992. [11] A. v. Lamsweerde, "Requirements Engineering in the Year 00: A Research Perspective," 22nd International Conference on Software Engineering, Limerick, Ireland, 2000. [12] R. Allen, "A Formal Approach to Software Architecture," in School of Computer Science. Pittsburgh, PA: Carnegie Mellon, 1997. [13] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and W. Mann, "Specification and Analysis of

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE

[14]

[15]

[16] [17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

System Architecture Using Rapide," IEEE Transactions on Software Engineering, vol. 21, pp. 336-355, 1995. M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Yelesnik, "Abstractions for Software Architecture and Tools to Support Them," IEEE Transactions on Software Engineering, vol. 21, pp. 314335, 1995. J. Fischer, E. Holz, M. v. Loewis, and A. Prinz, "SDL2000: A Language with a Formal Semantics," Rigorous Object-Oriented Methods 2000, York, UK, 2000. C. A. R. Hoare, Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall, 1985. N. Medvidovic and R. N. Taylor, "A Classification and Comparison Framework for Software Architecture Description Languages," IEEE Transactions on Software Engineering, vol. 26, pp. 70-93, 2000. D. Garlan, R. T. Monroe, and D. Wile, "ACME: An Architecture Description Interchange Language," CASCON'97, Toronto, Ontario, 1997. K. Finney, "Mathematical Notation in Formal Specification: Too Difficult for the Masses?," IEEE Transactions on Software Engineering, vol. 22, pp. 158159, 1996. M. Shaw and D. Garlan, Software Architecture: Perspectives from an Emerging Discipline. Upper Saddle River, NJ: Prentice Hall, 1996. A. Dardenne, A. v. Lamsweerde, and S. Fickas, "Goaldirected requirements acquisition," Science of Computer Programming, vol. 20, pp. 3-50, 1993. L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Nonfunctional Requirements in Software Engineering. Norwell, MA: Kluwer Academic Publishers, 2000. D. Gross and E. Yu, "Evolving System Architecture to Meet Changing Business Goals: an Agent and Goal Oriented Approach," The First International Workshop on Software Requirements and Architectures (STRAW '01) at ICSE'01, Toronto, Canada, 2001. D. E. Perry, "NSF Project: Requirements to Architecture," http://www.ece.utexas.edu/~perry/work/projects/nsfr2a/index.html, 2005. M. Bradozzi and D. E. Perry, "From Goal-Oriented Requirements to Architectural Prescriptions: The Preskriptor Process," The Second International Workshop on Software Requirements and Architectures (STRAW '03) at ICSE'03, Portland, OR, 2003. J. G. Hall, M. Jackson, R. C. Laney, B. Nuseibeh, and L. Rapanotti, "Relating Software Requirements and Architectures using Problem Frames," IEEE Joint International Requirements Engineering Conference (RE'02), Essen, Germany, 2002. R. J. A. Buhr, "Use Case Maps as Architectural Entities for Complex Systems," IEEE Transactions on Software Engineering, vol. 24, pp. 1131-1155, 1998. D. Amyot and G. Mussbacher, "Bridging the requirements/design gap in Dynamic Systems with Use Case Maps (UCMs)," 23rd International Conference on Software Engineering, Toronto, Canada, 2001. D. Amyot, "User Requirements Notation," http://www.usecasemaps.org/urn/index.shtml, 2005.

[30] L. Liu and E. Yu, "From Requirements to Architectural Design - Using Goals and Scenarios," The First International Workshop on Software Requirements and Architectures (STRAW '01) at ICSE'01, Toronto, Canada, 2001. [31] N. Medvidovic, P. Gruenbacher, A. Egyed, and B. W. Boehm, "Bridging models across the software lifecycle," The Journal of Systems and Software, vol. 68, pp. 199-215, 2003. [32] P. Gruenbacher, A. Egyed, and N. Medvidovic, "Reconciling Software Requirements and Architectures: The CBSP Approach," 5th International Symposium on Requirements Engineering, Toronto, Canada, 2001. [33] D. Liu and H. Mei, "Mapping requirements to software architecture by feature-orientation," The Second International Workshop on Software Requirements and Architectures (STRAW '03) at ICSE'03, Portland, OR, 2003. [34] W. Liu and S. Easterbrook, "Eliciting Architectural Decisions from Requirements using a Rule-based Framework," The Second International Workshop on Software Requirements and Architectures (STRAW '03) at ICSE'03, Portland, OR, 2003. [35] W. Liu, "Architecting Requirements," Doctoral Consortium at RE'04, Kyoto, Japan, 2004. [36] H. Kaindl, "Difficulties in the Transition from OO Analysis to Design," IEEE Software, vol. 16, pp. 94102, 1999. [37] B. Nuseibeh, "Weaving together requirements and architectures," IEEE Software, vol. 34, pp. 115-11, 2001. [38] S. T. Pektas, "A framework for building design process modeling with parameter-based design structure matrices," 2nd International Conference on Innovation in Architectures, Engineering and Construction, Loughborough, UK, 2003. [39] N. Nurmuliani, D. Zowghi, and S. Fowell, "Analysis of Requirements Volatility during Software Development Life Cycle," 2004 Australian Software Engineering Conference, Melbourne, Australia, 2004.

Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD’06) 0-7695-2611-X/06 $20.00 © 2006

IEEE