Acme: an architecture description interchange language
CASCON '97 Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research
Modelling strategic relationships for process reengineering
Modelling strategic relationships for process reengineering
Architecture Decisions: Demystifying Architecture
IEEE Software
Goal-centric traceability for managing non-functional requirements
Proceedings of the 27th international conference on Software engineering
Software Architecture as a Set of Architectural Design Decisions
WICSA '05 Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture
Traceability and completeness checking for agent-oriented systems
Proceedings of the 2008 ACM symposium on Applied computing
Relating Software Requirements and Architectures
Relating Software Requirements and Architectures
Building up and reasoning about architectural knowledge
QoSA'06 Proceedings of the Second international conference on Quality of Software Architectures
Changing attitudes towards the generation of architectural models
Journal of Systems and Software
EA-tracer: identifying traceability links between code aspects and early aspects
Proceedings of the 27th Annual ACM Symposium on Applied Computing
COMPSAC '12 Proceedings of the 2012 IEEE 36th Annual Computer Software and Applications Conference
Hi-index | 0.00 |
Requirements models can be used to describe what is expected from a software system. On the other hand, architectural models can describe the structure of a system in terms of its components and connectors. However, these models do not capture the rationale of the decisions made during architectural design. This knowledge is important throughout the maintenance and evolution of the system, as it allows a better understanding of the system as well as the impact of changes on it. In this paper, we consider existing proposals for architectural decisions documentation to define a template for recording the rationale of architectural design decisions. This template is based on a metamodel, which borrows concepts from the NFR Framework to express such rationale. Documenting decisions enables the evaluation of architectural design alternatives when requirements evolve or when new alternatives are devised. Moreover, the metamodel provides a relationship between requirements and architectural design fragments, facilitating the maintenance of traceability between the problem and the solution. We illustrate and discuss the use of this metamodel in the context of Acme architectural models and i* requirements models.