How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Caveats in Eliciting Mobile App Requirements

Factors such as app stores or platform choices heavily affect functional and non-functional mobile app requirements. We surveyed 45 companies and interviewed ten experts to explore how factors that impact mobile app requirements are understood by requirements engineers in the mobile app industry. We observed a lack of knowledge in several areas. For instance, we observed that all practitioners were aware of data privacy concerns, however, they did not know that certain third-party libraries, usage aggregators, or advertising libraries also occasionally leak sensitive user data. Similarly, certain functional requirements may not be implementable in the absence of a third-party library that is either banned from an app store for policy violations or lacks features, for instance, missing desired features in ARKit library for iOS made practitioners turn to Android. We conclude that requirements engineers should have adequate technical experience with mobile app development as well as sufficient knowledge in areas such as privacy, security and law, in order to make informed decisions during requirements elicitation.Comment: The 24th International Conference on Evaluation and Assessment in Software Engineering (EASE 2020

Application of Design Thinking for Elicitation Requirements in Mobile Applications

In the context of software development methodologies, activities and requirements elicitation practices adopted by organizations present challenges regarding the definition and understanding of system requirements and in relation to communication between the project team and stakeholders. Requirements elicitation is the process through which analysts determine stakeholders software requirements. Requirements elicitation is seldom well done, and an inaccurate or incomplete understanding of user requirements has led to the downfall of many software projects. The Design Thinking methodology has been used by organizations as a requirement elicitation technique for making use of the immersion procedure that, as a consequence, brings the team stakeholder closer to the software project and allows the creation of projects with a design that is closer to the end user and with higher quality, minimizing the problems in requirements elicitation. This work evaluates the elicitation process of software requirements of the mobile applications developed in a Brazilian Public Agency, from the use of the concepts and procedures recommended by Design Thinking (DT). Furthermore, a practical case study is presented in which the use of DT is used in eliciting requirements of developed applications. The development process phases adopted by the Agency were also compared with the phases of the model adopted by DT. The comparative study demonstrated that the traditional methodology adopted today is bureaucratic and difficult the creation process, as well as the interaction between stakeholders and members of the development team and the knowledge transfer

Bridging the Gap Between Stakeholder and Software Products: A Review of Software Requirement Engineering Techniques

Effective software requirement engineering plays a crucial role in bridging the gap between stakeholders and software products. The success of any software project heavily relies on accurately capturing, analyzing, and documenting stakeholders' needs and expectations. This article provides a comprehensive review of various software requirement engineering techniques that facilitate the alignment of stakeholder requirements with software product development. Software requirements are extracted from a variety of stakeholders, but the decision of "what to develop" is a difficult one. Stakeholders' lack of clarity about what they want makes requirement elicitation a difficult and vital task. It explores the significance of understanding stakeholders' perspectives, discusses popular requirement engineering approaches, and highlights their strengths and limitations. The article concludes by emphasizing the importance of selecting appropriate requirement engineering techniques based on the project's context and offers recommendations for future research in this domain