[Context and motivation]
The starting point for software development is usually the system requirements. The requirements, especially nonfunctional requirements specified in a document are often incomplete and inconsistent with the initial user needs and expectations.
Experience at Siemens showed us that programmers working on software development often have trouble interpreting under-specified non-functional requirements, resulting in code that does not meet the users’ quality expectations and contains “quality faults” that can only be detected later through expensive user acceptance testing activities.
In this problem statement paper, we investigate the need for clarifying non-functional requirements in software specifications to improve user acceptance. In particular we focus on establishing the role of non-functional requirements on user acceptance.
Our contribution is that we emphasize the need for a systematic empirical study in this area. We propose a possible set-up where a number of hypotheses have been developed that a systematic experiment will help to validate. Our work is based on industrial experiments at Siemens, in the particular context of the installation of a Product Lifecycle Management (PLM) system.