<> "The repository administrator has not yet configured an RDF license."^^ . <> . . "Measuring anticipated satisfaction"^^ . "When developing a software system, one of the early steps is to create a requirements specification.\r\nValidating this specification saves implementation effort which might be otherwise spent\r\non building a system with the wrong features. Ideally, this validation should involve many stakeholders\r\nrepresenting different groups, to ensure coverage of a variety of viewpoints. However,\r\nthe usual requirements validation methods such as personal interviews only allow the involvement\r\nof a few stakeholders before the costs become prohibitive, so it is difficult to apply them at\r\nthe needed scale.\r\nIf the finished software system contains undesirable features, they are likely to be discovered\r\nduring usability testing. Many usability methods can involve a high number of users at a low\r\ncost, for example satisfaction surveys and A/B testing in production. They can give high quality\r\ninformation about improving the system, but they require a completed system or at least an\r\nadvanced prototype before they can be used.\r\nWe create a method for measuring user satisfaction before building the system, which we call\r\nanticipated satisfaction to distinguish it from the actual satisfaction measured after the user has\r\nexperienced the system. The method uses a questionnaire which contains short descriptions\r\nof the software system’s features, and asks the users to imagine how satisfied they would be\r\nwhen using a system with the described features. The method is flexible, as we do not create\r\na single questionnaire to use. Instead, we give guidance on which variables can be measured\r\nwith the questionnaire, and how to create questions for them. This allows the development team\r\nto tailor the questionnaire to the specific situation in their project. When we applied it in two\r\nvalidation studies, it discovered significant issues and was rated favorably by both the software\r\ndevelopment team and the users.\r\nOur method contributes to the discipline of software engineering by offering a new option for validating\r\nsoftware requirements. It is more scalable than interviewing users, and can be employed\r\nbefore the implementation phase, allowing for early problem detection. The effort required to\r\napply it is low, and the information gained is seen as useful by both developers and managers,\r\nwhich makes it a good candidate for use in commercial projects."^^ . "2018" . . . . . . . "Rumyana"^^ . "Proynova"^^ . "Rumyana Proynova"^^ . . . . . . "Measuring anticipated satisfaction (PDF)"^^ . . . "phd-thesis-proynova.pdf"^^ . . . "Measuring anticipated satisfaction (Other)"^^ . . . . . . "indexcodes.txt"^^ . . . "Measuring anticipated satisfaction (Other)"^^ . . . . . . "lightbox.jpg"^^ . . . "Measuring anticipated satisfaction (Other)"^^ . . . . . . "preview.jpg"^^ . . . "Measuring anticipated satisfaction (Other)"^^ . . . . . . "medium.jpg"^^ . . . "Measuring anticipated satisfaction (Other)"^^ . . . . . . "small.jpg"^^ . . "HTML Summary of #25327 \n\nMeasuring anticipated satisfaction\n\n" . "text/html" . . . "004 Informatik"@de . "004 Data processing Computer science"@en . .