Session:Architecture Modeling and Requirements--Discussions
From WICSA Conference Wiki
Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.
Contents |
Attendees
Please add yourself to this list. Tell us something about your background. Add to the Discussions questions section below a few sentences about the working session topic such as your position and questions you would like to see discussed.
- Andre Bondi, Siemens Corporate Research, Session Chair
- Dan Paulish, Siemens Corporate Research, General Chair
Key ideas
(key ideas, how papers relate to each other and support the session theme)
- key idea 1
There appears to be an implicit theme running through the papers in this session: that [requirements||non-functional requirements||choice of platform || limitation on platform choice] can all constrain the form that the architecture of a system will take as well as the components that a system will use.
In the paper by Miller and Madhavi, questions are raised about how architectural choices will limit the features to be supported, rather than about how the desire to support certain features will affect the architecture. This highlights the notion that an architectural choice that enables support of some features may complicate the support of other features.
The paper by Cortelessa et al introduces the notion of a nonfunctional MDA to validate nonfunctional requirements. It would be interesting to see how this might be extended to drive choices of architectural styles and patterns, whether subject to middleware constraints as discussed in the paper by Giesecke et al, or to meet the (parameterisable?) NFRs of a set of systems based on a product line architecture, which imposes constraints of its own, as described in the paper by Dhungana et al.
Discussion questions
The following were posted by Andre Bondi on 18th December at 14:00 GMT. They are arranged by paper.
Giesecke et al: 1. How doers the method capture descriptions of synchrony or asynchrony? 2. How are performance artifacts linked to the style and how do they impact the use of the style or the choice of style?
Dhungana et al: 1. What are the criteria for making architectural decisions once the constraints have been laid out? 2. How does one decide that one constraint is more acceptable than another? What makes a constraint acceptable? 3. How are scalability constraints and needs captured in this method? E.g., variable speed, transaction rate, scaling to encompass more entities
Navarro et al: 1. What happens if the chosen operationalisation is unable to support one or more nonfunctional requirements? Is this remedied on subsequent iterations? What conflicts might arise? Miller et al: 1. This process seems iterative. How do the functional and nonfunctional requirements drive the architecture in your study?
Cortellessa et al: 1. Can sensitivity analysis be formalized in your framework so as to gauge the impact of variability in the parameters of the NFRs or the beliefs about the values of the parameters? 2. Can you give an example in which extreme sensitivity to the parameters might trigger a radical change in the architecture?
-=-=-=-=-=-=-=end of Andre's posting=-=-=-=-==-=-=-=-=-
Discussions
(pre-session, session, post-session, post-mortem) Posted by Andre Bondi after the meeting:
Many of the points in the papers and in the discussion could be seen as continuations of the discussions in Paul Clements' two sessions the day before. As moderator, I attempted to place the papers and discussion in that context.
The following questions and points emerged during the working session: General Questions: • In a new application, what are the key requirements? • What should be documented for the REs about the architecture [of an associated system]? • Stakeholder needs vs. stakeholder satisfaction? o How strong is a requirement? When do we push back? o Constraints: will not start over when a legacy system or platform is present. Must build on what we have, because of labour shortage, or platform constraints • Risk inherent in a solution? Time, budget, risk to customer of not completing the system satisfactorily • Context of a (development) process? Topic: Rule Sets and Requirements o What is the relationship between rule sets and requirements? o How does one distinguish between rule sets to choose an architecture? o To what extent are requirements driven by decision rules and vice versa? o What are the tradeoffs between conflicting functional and nonfunctional requirements (quality attributes)? Topic: Interaction Between Architecture and Requirements • There are chicken-and-egg questions relating to the interaction between an architecture and the requirements. o Are specifications an input to the architecture or an outcome of it? o When and to what extent is the architecture influenced by the requirements? o When and to what extent are the requirements affected or even driven by the architecture? Topic: Enabling vs. Constraining Features of Platforms and Legacy Systems when Architecting Additions • Analogy: When designing an addition to an existing building, we look at the features of the existing building when proposing an addition. o How do we do this in the requirements process when adding a feature to • The analogy gives rise to the following questions: o When and to what extent does the architecture influence the requirements and vice versa? o When and to what extent is the architecture of an existing system a constraint on the architecture of an addition? o When and to what extent is the architecture of an existing system an enabler of the architecture of an addition? Could tools to describe these interactions be helpful? • Problem: The use of an existing platform can be viewed as constraining the architecture, or enabling it, depending on one’s point of view and on the circumstances. o The constraints arise because a system built on a platform or with an existing legacy system (denoted henceforth as associated systems (term chosen by the session chair)) must interface with it. Its performance and other quality attributes will be limited by those of the associated systems. o Other discussants took the view that the platforms should be regarded as enablers, because they provide services and enable the new architecture to be based on the existing associated systems. Topic: Application to Product Lines: o When a new product is to be added to the line, e the common features enabling or constraining? o Is the existing feature set enabling or constraining? o What is the impact of the quality attributes of the underlying system on the new member of the product line?
