Functional versus non-functional requirements considered harmful Abstract - Requirement elicitation and requirement engineering are crucial steps in system design, implementation, and maintenance. In addressing software intensive distributed socio-technical system such as trusted workflows in life-critical situations or information sharing support systems, we claim that the traditional division between functional and non-functional requirements is difficult and even harmful to maintain. We propose in this paper a more principled and context dependant approach towards requirement engineering and high-level system validation. Keywords: Requirement elicitation, Requirement engineering, non-functional requirements 1 Introduction We have during the last decade designed and implemented software intensive systems in the areas of distributed healthcare [16, 30, 31], critical infrastructures [17, 18, 23, 24, 25, 26], workflow support in life critical situations [4, 22, 39], and information sharing [38]. Lessons learned from those investigations are that a principled approach of requirement elicitation and requirement engineering is an important ingredient in designing, implementing, and maintaining trustworthy socio-technical systems. As a matter of fact, the most crucial requirements underpinning user acceptance and trust falls within what traditionally is termed non-functional requirements. A simple example, stakeholders involved in system specifications might have concerns related to information security (can be classified as a non-functional requirement). However, a mean to implement information security is to apply cryptography (a functional transformation of information). This coding is typically a result of applying an algorithm. That is, a nonfunctional requirement has in the design and implementation phase been transformed into a function (algorithm) that in turn has to compete with other algorithms for resources at runtime. Another important lesson that follows from this typical example is that we cannot focus on “an important class of functional requirements” when designing and implementing systems and hope to add other requirements as add-ons. All system-sensitive requirements have to be addressed properly from the outset of the system engineering efforts. We argue that the present classification of requirements into functional or non-functional requirements has at least the following shortcomings: • Presupposes a fixed ontology of functional and non-functional requirements independent of stakeholders and context. • Might focus on non-relevant issues found out at later stages of the system development process. • Does not easily allow assessments of trade-offs between requirements. These shortcomings might lead to focusing on wrong and/or non-important requirements while not detecting important requirements when designing and implementing trustworthy software-intensive systems. In short, we regard the current principle of distinguishing between functional and non-functional Rune Gustavsson, Jenny Lundberg, Christer Rindebäck, Kerstin Ådahl School of Engineering Blekinge Institute of Technology SWEDEN Fax: +46 457 106 67