Clarifying non-functional requirements to improve user acceptance - experience at Siemens
Abstract
The starting point for software development is usually the system requirements. The requirements, especially non-functional requirements specified in a document are often incomplete and inconsistent with the initial user needs and expectations. [Question/problem] 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. [Principal ideas/results] 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. [Contribution] 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.
