Requirements Quality vs Process and Stakeholders' Well-being: A Case of a Nordic Bank

AI-generated keywords: Requirements Quality Software Development Stakeholders Well-Being Descriptive Interview Study Nordic Bank

AI-generated Key Points

The license of the paper does not allow us to build upon its content and the key points are generated using the paper metadata rather than the full article.

  • The study explores the relationship between requirements quality and its impact on software development process and stakeholders' well-being
  • Descriptive interview study conducted at a sub-organization of a Nordic bank that develops its own web and mobile apps
  • 20 practitioners interviewed, including requirements engineers, developers, testers, and newly employed developers with five interviewees from each group
  • Different roles have different views on what makes a requirement good quality
  • Negative emotions, more work and overhead communication experienced when working with poor-quality requirements; positive effects on performance and positive feelings when working with good-quality requirements
  • Investing in high-quality requirements can lead to better outcomes for both the development process and stakeholders' well-being
  • All relevant stakeholders should be involved in defining requirements quality criteria to ensure everyone's needs are met
  • Understanding practitioners' perceptions regarding requirements quality is important as it can impact the effectiveness and efficiency of the development process as well as stakeholders' well-being
  • Identifying causes of poor-quality requirements and potential solutions for them can improve software development processes while ensuring employees' satisfaction.
Also access our AI generated: Comprehensive summary, Lay summary, Blog-like article; or ask questions about this paper to our AI assistant.

Authors: Emil Lind, Javier Gonzalez-Huerta, Emil Alégroth

Submitted to Software Quality Days 2023 Conference

Abstract: Requirements are key artefacts to describe the intended purpose of a software system. The quality of requirements is crucial for deciding what to do next, impacting the development process's effectiveness and efficiency. However, we know very little about the connection between practitioners' perceptions regarding requirements quality and its impact on the process or the feelings of the professionals involved in the development process. Objectives: This study investigates: i) How software development practitioners define requirements quality, ii) how the perceived quality of requirements impact process and stakeholders' well-being, and iii) what are the causes and potential solutions for poor-quality requirements. Method: This study was performed as a descriptive interview study at a sub-organization of a Nordic bank that develops its own web and mobile apps. The data collection comprises interviews with 20 practitioners, including requirements engineers, developers, testers, and newly employed developers, with five interviewees from each group. Results: The results show that different roles have different views on what makes a requirement good quality. Participants highlighted that, in general, they experience negative emotions, more work, and overhead communication when they work with requirements they perceive to be of poor quality. The practitioners also describe positive effects on their performance and positive feelings when they work with requirements that they perceive to be good.

Submitted to arXiv on 11 Nov. 2022

Ask questions about this paper to our AI assistant

You can also chat with multiple papers at once here.

The license of the paper does not allow us to build upon its content and the AI assistant only knows about the paper metadata rather than the full article.

AI assistant instructions?

Results of the summarizing process for the arXiv paper: 2211.06122v1

This paper's license doesn't allow us to build upon its content and the summarizing process is here made with the paper's metadata rather than the article.

This study by Emil Lind, Javier Gonzalez-Huerta, and Emil Alégroth explores the relationship between requirements quality and its impact on the software development process and stakeholders' well-being. The authors conducted a descriptive interview study at a sub-organization of a Nordic bank that develops its own web and mobile apps. They interviewed 20 practitioners, including requirements engineers, developers, testers, and newly employed developers with five interviewees from each group. The study aimed to investigate how software development practitioners define requirements quality; how the perceived quality of requirements impacts the process and stakeholders' well-being; and what causes poor-quality requirements and potential solutions for them. The results showed that different roles have different views on what makes a requirement good quality. Participants highlighted that they experience negative emotions, more work and overhead communication when they work with requirements they perceive to be of poor quality. On the other hand, they described positive effects on their performance and positive feelings when they work with requirements that they perceive to be good. This suggests that investing in high-quality requirements can lead to better outcomes for both the development process and stakeholders' well-being. The authors recommend involving all relevant stakeholders in defining requirements quality criteria to ensure everyone's needs are met. Overall, this study highlights the importance of understanding practitioners' perceptions regarding requirements quality as it can impact the effectiveness and efficiency of the development process as well as stakeholders' well-being. By identifying causes of poor-quality requirements and potential solutions for them, organizations can improve their software development processes while ensuring their employees' satisfaction.
Created on 09 Apr. 2023

Assess the quality of the AI-generated content by voting

Score: 0

Why do we need votes?

Votes are used to determine whether we need to re-run our summarizing tools. If the count reaches -10, our tools can be restarted.

The previous summary was created more than a year ago and can be re-run (if necessary) by clicking on the Run button below.

The license of this specific paper does not allow us to build upon its content and the summarizing tools will be run using the paper metadata rather than the full article. However, it still does a good job, and you can also try our tools on papers with more open licenses.

Similar papers summarized with our AI tools

Navigate through even more similar papers through a

tree representation

Look for similar papers (in beta version)

By clicking on the button above, our algorithm will scan all papers in our database to find the closest based on the contents of the full papers and not just on metadata. Please note that it only works for papers that we have generated summaries for and you can rerun it from time to time to get a more accurate result while our database grows.

Disclaimer: The AI-based summarization tool and virtual assistant provided on this website may not always provide accurate and complete summaries or responses. We encourage you to carefully review and evaluate the generated content to ensure its quality and relevance to your needs.