Removing non-architecture related features and Resolving quality features

According to van der Linden et al. [38, Chapter 3.1.2], one important issue related to architectures is architectural significant requirements, which encompass two types of requirements: functional requirements and quality requirements. Functional requirements determine what is realised and quality requirements determine how it is realised [38, Chapter 3.1.2]. Non-architecture related (NAR) features are the opposite of architectural significant requirements. In the Public Health Complaint SPL, all subfeatures of Computer infrastructure are NAR features, except Java RMI, Java Servlets, Database, and subfeatures of Compatibility.

Our solution [1] as well as FArM method resolves quality features (i.e. a feature that represents a quality attribute) through the integration with existing functional features. In the Public Health Complaint SPL, the following quality features are integrated with existing functional features: Persistence, Usability, Distribution, Concurrency, Availability, Encryption, and Performance. We describe below how each of these features were resolved:

• Persistence is composed by Database, which can be implemented by either MySQL or Oracle;
• Usability is composed by User interface, which is implemented by Java Servlets;
• Distribution can be implemented by both Java RMI and Java Servlets features;
• Encryption feature, a subfeature of Security, can also be implemented by Java RMI. Although the security mechanism provided by RMI is simples, it was the one the Healthwatcher developers relied on so we followed their decision;
• Concurrency is implemented by Java Synchronization mechanisms [39];
• Availability is supported by the implementation of Exception Handling;
• Performance feature and its subfeature depends on the architectural configuration and it can be achieved by means of architecture styles [24, Chapter4.1]. However, we believe that for Public Health Complaint SPL the performance requirement (see NFR03) should not be a driving requirement for defining the SPL architecture. We assume that Healthwatcher architects also think in this way as they designed a layered architecture (Section 4.1), which is not a performance-friendly architecture style. Furthermore, Healthwatcher implementation [14] does not support any mechanism to improve performance, like the implementation of cache. Therefore, we relied on efficient implementation and on hardware to achieve performance requirements.