Clarifying Non-functional Requirements to Improve User Acceptance – Experience at Siemens

[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.

[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.