German Title: Messen von vorhergesehener Zufriedenheit

Preview

PDF, English - main document Download (1MB) | Lizenz: Measuring anticipated satisfaction von Proynova, Rumyana steht unter einer Creative Commons Attribution-NoDerivatives 3.0 Germany

Abstract

When developing a software system, one of the early steps is to create a requirements specification. Validating this specification saves implementation effort which might be otherwise spent on building a system with the wrong features. Ideally, this validation should involve many stakeholders representing different groups, to ensure coverage of a variety of viewpoints. However, the usual requirements validation methods such as personal interviews only allow the involvement of a few stakeholders before the costs become prohibitive, so it is difficult to apply them at the needed scale. If the finished software system contains undesirable features, they are likely to be discovered during usability testing. Many usability methods can involve a high number of users at a low cost, for example satisfaction surveys and A/B testing in production. They can give high quality information about improving the system, but they require a completed system or at least an advanced prototype before they can be used. We create a method for measuring user satisfaction before building the system, which we call anticipated satisfaction to distinguish it from the actual satisfaction measured after the user has experienced the system. The method uses a questionnaire which contains short descriptions of the software system’s features, and asks the users to imagine how satisfied they would be when using a system with the described features. The method is flexible, as we do not create a single questionnaire to use. Instead, we give guidance on which variables can be measured with the questionnaire, and how to create questions for them. This allows the development team to tailor the questionnaire to the specific situation in their project. When we applied it in two validation studies, it discovered significant issues and was rated favorably by both the software development team and the users. Our method contributes to the discipline of software engineering by offering a new option for validating software requirements. It is more scalable than interviewing users, and can be employed before the implementation phase, allowing for early problem detection. The effort required to apply it is low, and the information gained is seen as useful by both developers and managers, which makes it a good candidate for use in commercial projects.

Translation of abstract (German)

Beim Entwickeln eines Softwaresystems ist einer der ersten Schritte das Erstellen einer Anforderungsspezifikation. Das Validieren dieser Spezifikation reduziert den Implementierungsaufwand, der möglicherweise beim Entwickeln eines Systems mit den falschen Features entstanden wäre. Im Idealfall werden viele Stakeholder in diese Validierung miteinbezogen, die unterschiedliche betroffene Gruppen repräsentieren, um das Abdecken unterschiedlicher Perspektiven zu gewährleisten. Allerdings erlauben die traditionellen Validierungsmethoden wie Interviews nur das Involvieren von wenigen Stakeholdern, bevor die Kosten untragbar werden, so dass es schwierig ist, diese Methoden im benötigten Umfang anzuwenden. Falls die fertige Software unerwünschte Features enthält, kann man diese mit hoher Wahrscheinlichkeit bei einem Usability Test entdecken. Viele Usability Methoden erlauben das Involvieren vieler Benutzer bei niedrigen Kosten, wie zum Beispiel Zufriedenheitsbefragungen und A/B Tests in der Produktionsphase. Sie produzieren hochqualitative Information zum Verbessern des Softwaresystems, aber sie benötigen ein fertiggestelltes System oder zumindest ein fortgeschrittenes Prototyp um angewendet zu werden. Wir erstellen eine Methode für das Messen von Benutzerzufriedenheit bevor das System implementiert ist, und nennen diese Metrik “erwartete Zufriedenheit”, um sie von der “eigentlichen Zufriedenheit” zu unterscheiden, die erst gemessen werden kann nachdem der Benutzer Erfahrungen mit dem System gesammelt hat. Die Methode benutzt einen Fragebogen, der kurze Beschreibungen von Softwarefeatures enthält, und bittet die Benutzer sich vorzustellen, wie zufrieden sie mit einem System mit den beschriebenen Features wären. Die Methode ist flexibel, da wir keinen festen Fragebogen vorgeben. Stattdessen geben wir eine Anleitung, welche Variablen mit dem Fragebogen gemessen werden können, und wie man Fragen zu diesen Variablen formuliert. Das erlaubt es dem Entwlicklungsteam, den Fragebogen an der spezifischen Situation in ihrem Projekt anzupassen. Als wir die Methode in zwei Validierungsstudien anwendeten, entdeckten wir wichtige Probleme, und die Methode wurde positiv vom Entwicklunsteam und von den teilnehmenden Benutzern angenommen. Unsere Methode trägt zur Disziplin des Software Engineering bei, indem sie eine neue Option für das Validieren von Softwareanforderungen bietet. Sie ist besser skalierbar als Benutzerinterviews, und kann vor der Implementationsphase angewendet werden, so dass sie die frühe Entdeckung von Problemen erlaubt. Der Aufwand für die Anwendung ist niedrig, und die produzierte Information wird sowohl von den Entwicklern als auch von den Führungskräften als nützlich angesehen, deswegen ist sie die Methode für die Anwendung in kommerziellen Projekten gut geeignet.