Bridging Users’ Values and Requirements to Architecture Alistair Sutcliffe School of Computing and Communications, University of Lancaster, Lancaster, LA1 4WA, UK Abstract- The paper describes a process for bridging from users' values and goal oriented requirements to architecture via architecture patterns. User values, such as privacy, sociability, creativity, etc are introduced and their implications for system architecture are explained. Many architectural implications are common to several user values so architecture patterns are proposed to collate these as high level requirements for components which can then be related to NFRs as well as user values. The process of analysing user values through to design of system architecture is illustrated with a case study in health informatics. I INTRODUCTION Use of problem frames [1] has attracted considerable attention as a bridging model between requirements and architecture [2- 4], in particular for privacy and security non-functional requirements where architecture components can be directly related to requirements for security barriers, threat detection and monitoring. However, problem frames only provide a small number of high-level abstractions (i.e. the workpieces, required behaviour, commanded behaviour and transformation frames [1], which are far removed from most application-level requirements problems. The connection therefore has to be made via a contextual analysis process, so the transition from requirements to architecture specification, even via problem frames, is primarily guided by methodology. Bridging from architecture to requirements has more solid guidance in the form of architectural strategies, tactics and several model driven architecture methods [5-8]. While these tactics and methods can advise on the architectural implications for NFRs (non- functional requirements) (e.g. reliability, performance, maintainability), they do not connect easily to application-level functional requirements. The methods route for bridging between architecture and requirements [6], [8] may suffice for experts who have many years’ experience and tacit knowledge of sets of problem abstractions in the requirements realm and solution abstraction in the architecture realm; unfortunately, such knowledge is not available to novices, who struggle with only methods guidance to make the transition from requirements to design. Prototyping and cycles of user evaluation is one answer but this is expensive on resources and does not scale well to large, complex systems. The alternative is to provide novice developers with sets of bridging abstractions, or conceptual models as expert knowledge, so they can develop more effective solutions that map to particular classes of problems. Ideally, bridging abstractions in the form of patterns or conceptual models should be accompanied by a guiding method so novice designs are supported both during requirements analysis and the transition to design. This paper proposes architecture patterns which are motivated by users’ values, and hence facilitate user-centred design of software architecture. Architecture patterns are related to a VBRE (value-based requirements engineering) method which is described in more depth in [9]. II. USER VALUES AND DESIGN PATTERNS Users’ values are generic attitudes or beliefs that shape stakeholders’ requirements of systems; for example, trust in others as a person value may reduce the need for controls and legal contracts in relationships, although there may be requirements for visibility and transparency of user actions. User values may have implications for NFRs and impact directly on design decisions concerning functional requirements. While many user values will have domain- specific interpretations which can not be analysed a priori, there are implications which can be recorded as generic functional requirements with design rationale, as illustrated in Table I. The mapping between values, generic functional requirements which may satisfy user values and design implications that give the context for arguments and options, are explained in more depth in the following sections. Trust. This value concerns trust of another agent (which may be human or automated) or trust in data.. We also base trust on what people do, the reliable behaviour of agents, and accurate content of information. This requires behaviour to be visible and inspectable. Trust therefore implies generic requirements for reputation mechanisms as recommended in web services, e.g. security certificates, membership of reputable organisations, references of repute from others. Visibility and transparency requirements are for all behaviour to be accessible and shared with others, with graphical shared-awareness displays of where agents are, what they are doing, statements of intent, etc. Design implications are for developing monitors for user behaviour, database updating, and audit trails of agents’ and system activity. Sociability. This value is oriented towards cooperating with other people and seeking social relationships, rather than being 978-1-4799-0962-9/13/$31.00 c  2013 IEEE TwinPeaks 2013, Rio de Janeiro, Brasil 15