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

  • Authors:
  • Christoph Marhold;Clotilde Rohleder;Camille Salinesi;Joerg Doerr

  • Affiliations:
  • Siemens PL (DE) GmbH, Nuremberg, D-90471;Siemens PL (DE) GmbH, Nuremberg, D-90471 and CRI - Université Paris 1, Paris, F-75013;CRI - Université Paris 1, Paris, F-75013;Fraunhofer Institute Experimental Software Engineering, Kaiserslautern, D-67663

  • Venue:
  • REFSQ '09 Proceedings of the 15th International Working Conference on Requirements Engineering: Foundation for Software Quality
  • Year:
  • 2009

Quantified Score

Hi-index 0.00

Visualization

Abstract

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