Requirements guide the development of a software intensive system, whereas the software architecture largely dictates the achievable properties of the system. This interplay of requirements and architectures has been largely accepted by the researchers and practitioners alike. Despite the common understanding of the general approach, the exact guidelines on how to develop systems in practice are missing. Features are often used to map customer requirements into product properties. However, our experience shows that features are often misused. Their real role is not understood or they are used for premature design and solution specification purposes. A number of different methods for either analysing and modelling requirements or for designing architectures exists, but the combination and customisation of these methods is left for the practitioners. The transition from problem definition to architecture is mainly dependent on the creativity and problem understanding of the chief architect. In this paper, we argue how 4 existing models, problem domain models, context diagrams, feature models, and architectural descriptions can be used together to make the transition process more transparent.
|Title of host publication||AWRE 2002 : The seventh Australian Workshop on Requirements Engineering : proceedings|
|Editors||Jacob Cybulski, Lemai Nguyen, John Lamp, Ross Smith|
|Place of Publication||Deakin University, School of Information Systems|
|Number of pages||15|
|Publication status||Published - 3 Dec 2002|
- software architecture