Software Requirements Elicitation Research Articles

Applying Kano’s two-factor theory to prioritize learning analytics dashboard features for learning technology designers

Existing methods for software requirements elicitation, five-point Likert scales and voting methods for requirements prioritization, and usability and user experience evaluation methods do not enable prioritizing the learning analytics dashboard requirements. Inspired by management and product design field, this research applies Kano’s two-factor theory to prioritize the features of learning analytics dashboards (LADs) of adaptive learning platform (ALP) called Rhapsode<sup>TM</sup> learner, based on students’ perceived usefulness to support designers’ decision-making. Comparing usability and user experience methods for evaluating LAD features, this paper contributes with the protocol and a case applying Kano method for evaluating the perceived importance of the dashboards in ALP. The paper applies Kano’s two-factor questionnaire on the 13 LADs features of Rhapsode<sup>TM</sup> learner. Responses from 17 students are collected using a questionnaire, which is used to showcase the strength of the two-factor theory through five tabular and graphical techniques. Through these five tabular and graphical techniques, we demonstrate the application and usefulness of the method as designers and management are often carried away by the possibilities of insights instead of actual usefulness. The results revealed a variation in the categorization of LADs depending on the technique employed. As the complexity of the techniques increases, additional factors that indicate data uncertainty are gradually incorporated, clearly highlighting the growing requirement for data. In the case of RhapsodeTM learner platform, results based on the students responses show that 11 of 13 LADs being excluded due to low significance level in categorization (technique 1) and low response rate.

Elevated Novice Developer Productivity and Self-efficacy by Promoting UX Journey in Software Requirement Elicitation

This study explores the effectiveness of the UX Journey methodology in increasing developer productivity and self-efficacy. Materials: The UX journey, consisting of around 30 activities, offers a user-centric approach to developing solutions, with 86 volunteer respondents from 505 populations. Method: Through a comparative analysis of developer productivity metrics and the General Self-Efficacy Scale questionnaire, this study investigates the impact of UX Journey on self-efficacy before and after implementation. Results: The study's findings reveal a significant positive correlation between UX Journey and increased productivity and an association between self-efficacy variables. By incorporating a comprehensive set of activities and a user-centric approach, the UX Journey enables developers to navigate the design process efficiently while gaining a deeper understanding of user needs. The positive correlation between the UX Journey and increased productivity, as well as the relationships between self-efficacy variables, emphasize the value of this methodology in fostering practical design thinking. Implication for Further Research: While this study has limitations regarding sample size and contextual specificity, it provides valuable insight into the benefits of UX Journey and paves the way for further research. In addition, the study focused on specific design projects within a particular context, which might restrict the broader applicability of the results. Significant results indicate that the proposed method is as effective as the elicitation method in general, with the advantage that the developer can understand the needs and empathy of the users. UX journeys can enhance the design process and foster a deeper understanding of users' needs across multiple domains.

Analyzing Variances in User Story Characteristics: A Comparative Study of Stakeholders with Diverse Domain and Technical Knowledge in Software Requirements Elicitation

Background: In Agile software development, an essential initial stage is eliciting software requirements. This process engages stakeholders to achieve comprehensive results. However, a common issue is the variance in domain and technical knowledge among stakeholders, potentially impacting the quality of software requirements elicitation. Objective: Understanding the characteristics of user stories produced by stakeholders becomes crucial, particularly considering the differences in domain and technical knowledge. This study aims to compare the characteristics of user stories generated by stakeholders with varying backgrounds in domain and technical expertise. Methods: The initial step involves categorizing respondents into distinct stakeholder groups. Three stakeholders are involved in this study, constituting a combination of those with high and low technical and domain knowledge. Subsequently, data collection of user stories is conducted across various case studies. Finally, the acquired user stories are analyzed for further insights. Results: The analysis reveals variations in user stories generated by the three stakeholder categories across the three case studies. Stakeholders with domain knowledge tend to focus on 'what' aspects with task elements and 'why' aspects with hard-goal elements. Meanwhile, technical knowledge crafts user stories with capability elements in the 'what' aspect. Utilizing the QUS framework, it is evident that technical knowledge consistently produces a higher number of high-quality user stories across all quality categories, Conclusion: The contribution offered by this study lies in determining the distinct characteristics of user stories produced by different types of stakeholders, focusing on disparities in domain and technical knowledge. The study highlights the comparison of various characteristics of user story elements, such as hard-goals, soft-goals, tasks, or capabilities, and assesses the quality of user stories based on the user story framework. Additionally, it endorse the importance of process innovation in shaping the requirements gathering process and subsequently influencing the quality of user stories. Keywords: User story, Agile Software Development, Requirements Elicitation, Stakeholder, Domain Knowledge, Process Innovation Background: In Agile software development, an essential initial stage is eliciting software requirements. This process engages stakeholders to achieve comprehensive results. However, a common issue is the variance in domain and technical knowledge among stakeholders, potentially impacting the quality of software requirements elicitation. Objective: Understanding the characteristics of user stories produced by stakeholders becomes crucial, particularly considering the differences in domain and technical knowledge. This study aims to compare the characteristics of user stories generated by stakeholders with varying backgrounds in domain and technical expertise. Methods: The initial step involves categorizing respondents into distinct stakeholder groups. Three stakeholders are involved in this study, constituting a combination of those with high and low technical and domain knowledge. Subsequently, data collection of user stories is conducted across various case studies. Finally, the acquired user stories are analyzed for further insights. Results: The analysis reveals variations in user stories generated by the three stakeholder categories across the three case studies. Stakeholders with domain knowledge tend to focus on 'what' aspects with task elements and 'why' aspects with hard-goal elements. Meanwhile, technical knowledge crafts user stories with capability elements in the 'what' aspect. Utilizing the QUS framework, it is evident that technical knowledge consistently produces a higher number of high-quality user stories across all quality categories, Conclusion: The contribution offered by this study lies in determining the distinct characteristics of user stories produced by different types of stakeholders, focusing on disparities in domain and technical knowledge. The study highlights the comparison of various characteristics of user story elements, such as hard-goals, soft-goals, tasks, or capabilities, and assesses the quality of user stories based on the user story framework. Additionally, it endorse the importance of process innovation in shaping the requirements gathering process and subsequently influencing the quality of user stories. Keywords: User story, Agile Software Development, Requirements Elicitation, Stakeholder, Domain Knowledge, Process Innovation

Using Design Thinking to break social barriers: An experience report with former inmates

AbstractDesign Thinking techniques have been widely used in software requirements elicitation to understand the necessities of stakeholders and end‐users. However, there is a lack of evidence of their effectiveness when applied to guide the development process of a system targeting vulnerable populations. What are the implications of using Design Thinking techniques to elicit requirements in a community of former inmates—and what would be the benefits of and challenges in this deployment? In this paper, we report our experience of using Design Thinking for requirements elicitation of a mobile application customized for the former inmates of the Brazilian prison system and their families. We applied techniques such as Brainstorming, Stakeholder Mapping, Personas Creation, Rapid Ethnography, and Interviews to obtain relevant data and create several prototypes. These techniques contribute to the development of an uncommon application that aims to help the reintegration process of former inmates into society. Our results validate the initial hypothesis that such techniques, when applied to a sensitive context, assist product development that meets the end‐users' needs by creating a higher quality product. The main limitation of the research was the lack of access to low‐literacy end‐users and/or former inmates without previous experience using mobile devices.

Use of Journey Maps and Personas in Software Requirements Elicitation

Requirements elicitation is a fundamental step in a software development process since it is at this stage that the software begins to be designed. In some situations, the problems related to the failure of the software development project are due to an incomplete requirements elicitation, resulting in solutions that do not understand all the necessary functionalities or do not incorporate innovation. Despite the various techniques offered by Requirements Engineering, situations such as the growing application market and the need for innovation further increase the importance of understanding the user’s different needs. In this paper, we investigated how the journey map and personas techniques are being used in requirements elicitation in both the literature and the industry, along with the advantages, disadvantages and challenges of using these techniques. We conducted systematic literature review to identify the personas and journey map techniques used in requirements elicitation in the literature and industry. In addition, we conducted a survey with 52 practitioners (software developers, users and managers) to investigate their perceptions of the use of journey maps and personas techniques in the requirements elicitation phase. Twenty-four primary studies were identified that address journey map and personas techniques in software requirements elicitation. In addition, most respondents stated that using these techniques facilitates understanding the requirements, providing better integration, collaboration and leveling of knowledge among the members of the software development teams. Our findings allow us to conclude that most of the software developers, users and managers that participated in the survey consider that the journey map and personas techniques are effective in helping understand the software requirements to be developed by the development teams.

Generating large dataset for software requirements prioritization and selection under fuzzy environment

Requirements elicitation is a key sub-process of requirements engineering in which various types of software requirements such as functional and non-functional requirements, testing requirements etc., are identified according to the needs of the stakeholders. After the completion of the requirements elicitation process, there may be a large set of requirements and practically it is not possible to implement all requirements due to budget, time and other constraints of an organization. Under this situation, software developers select the highest ranked software requirements from the list of the elicited software requirements for different releases of software so that a successful software product can be developed. The selection of software requirements for different releases is a difficult task because it requires the participation of various stakeholders. In the field of science and engineering, datasets play an important role during experimental work. Based on our review, we found that in the literature of software engineering less attention is given on the generation of the datasets particularly in the domain of software requirements prioritization and selection (SRPS). Therefore, to address this issue, in this paper we present a four-step method for generating the dataset for SRPS research, i.e. (a) identification of stakeholders, (b) elicitation of software requirements using the goal-oriented concept, (c) formation of decision maker committee and (d) evaluation of the functional requirements and non-functional requirements by decision makers under fuzzy environment. The proposed method has been applied to generate the dataset for the requirements of an institute examination system.

An Approach towards Goal-Oriented Requirements Ontology: Consistency and Completeness Based Requirements Analysis

The paper presents a new approach to managing software requirement elicitation techniques with a high level of analyses based on domain ontology techniques, where we established a mapping between user scenario, structured requirement, and domain ontology techniques to improve many attributes such as requirement consistency, completeness and eliminating duplicate requirements to reduce risk of overrun time and budgets. One of the main targets of requirement engineering is to develop a requirement document with high quality. So, we proposed a user interface to collect all vital information about the project directly from the regular user and requirement engineering; After that, the proposal will generate an ontology based on semantic relations and rules. Requirements Engineering tries to keep requirements throughout a project’s life cycle consistent necessities clear, and up to date. This prototype allows mapping requirement scenarios into ontology elements for semantically interrupted. The general points of our prototype are to guarantee the identification requirements and improved nature of the Software Requirements Specification (SRS) by solving incomplete and conflicting information in the requirements specification.

GoEliTool for Software Requirements Elicitation using Goal-Oriented Approach

Requirements engineering (RE) is an essential initial stage in software engineering. The RE process begins with the elicitation stage. This stage collects all user requirements that must be fulfilled by the system which will be developed. A goal-oriented approach is an effective approach used to automate the RE process. The development of goal-oriented input document standards is one of the important issues that has not been widely studied. Therefore, this study developed a goal-oriented input document standard for the requirements elicitation process. A tool is developed based on the form of the input document that has been generated. The development of standard forms of input documents begins with literature study and data collection, analysis, design of standard forms of documents, tool design, tool development, and testing. At the analysis stage, a logical framework and element structure is formulated in a goal-oriented approach. Furthermore, the standard form of input documents is developed. The standard form of the document becomes a guideline for developing tools to process data requirements from elicitation results. Tool testing is carried out using black-box testing. The test results show that the tool can work according to the planned function. The trial of the use of the tools was carried out using five requirements datasets. The results of testing and using the tool through the requirements dataset show that GoEliTools can be used to record data on the requirements of several users for the development of an information system.

Measuring and improving software requirements elicitation in a small-sized software organization: a lightweight implementation of ISO/IEC/IEEE 15939:2017—systems and software engineering—measurement process

Measuring and improving software requirements elicitation in a small-sized software organization: a lightweight implementation of ISO/IEC/IEEE 15939:2017—systems and software engineering—measurement process

Role of Human Aspects on the process of Software Requirement Elicitation

Role of Human Aspects on the process of Software Requirement Elicitation

Teknik Elisitasi Kebutuhan Perangkat Lunak: Literatur Review

The selection of software requirements elicitation techniques is very important for organizations as the first step in the software development process. This study is motivated by the existence of problems, where the organization does not understand the type of software being developed, so it is difficult to determine the right need elicitation technique. In this study, a literature review was used by collecting existing studies. Used 17 studies related to the discussion of elicitation techniques used. This study aims to review previous studies so as to produce recommendations for software requirements elicitation techniques. Based on the study, it can be concluded that interview, prototyping and JAD are most often used in software projects. In addition, for the small-medium scale software projects, more use of interviews, JAD, and ERD-based specifications. Meanwhile, the large-scale software projects involve more stakeholders with elicitation techniques such as group discussions, interviews, and parallel discussions to find joint solutions.

Retraction Note to: An integrated approach towards automated software requirements elicitation from unstructured documents

Retraction Note to: An integrated approach towards automated software requirements elicitation from unstructured documents

User Story Extraction from Online News with FeatureBased and Maximum Entropy Method for Software Requirements Elicitation

Software requirements query is the frst stage in software requirements engineering. Elicitation is the process of identifying software requirements from various sources such as interviews with resource persons, questionnaires, document analysis, etc. The user story is easy to adapt according to changing system requirements. The user story is a semi-structured language because the compilation of user stories must follow the syntax as a standard for writing features in agile software development methods. In addition, user story also easily understood by end-users who do not have an information technology background because they contain descriptions of system requirements in natural language. In making user stories, there are three aspects, namely the who aspect (actor), what aspect (activity), and the why aspect (reason). This study proposes the extraction of user stories consisting of who and what aspects of online news sites using feature extraction and maximum entropy as a classifcation method. The systems analyst can use the actual information related to the lessons obtained in the online news to get the required software requirements. The expected result of the extraction method in this research is to produce user stories relevant to the software requirements to assist systems analysts in generating requirements. This proposed method shows that the average precision and recall are 98.21% and 95.16% for the who aspect; 87,14% and 87,50% for what aspects; 81.21% and 78.60% for user stories. Thus, this result suggests that the proposed method generates user stories relevant to functional software.

Using Social Network and Fuzzy Set Theory for Elicitation and Prioritization of Software Requirements

Using Social Network and Fuzzy Set Theory for Elicitation and Prioritization of Software Requirements

A Tacit-Knowledge-Based Requirements Elicitation Model Supporting COVID-19 Context

Effective software requirements elicitation plays a vital role in the success or failure of a project. However, ambiguity in the requirement’s statements indicate the presence of a tacit knowledge, which ultimately act as a root cause of critical complications in later stages of software development as user’s needs might remain hidden. Additionally, the existence of numerous stakeholders escalates the problem as their perceptions may contrast mainly due to their experiences and roles in a specific application domain. Hence, witlessness of relevant stakeholder(s) and ambiguous requirements cause the compromise for a product quality. Eventually, it paves the way towards the failure of a project. Furthermore, COVID-19 has affected all walks of life, more specifically requirements elicitation process as it heavily depends on human-to-human interaction. Motivated by this, current study aims at identifying the requirements elicitation techniques and challenges through a systematic literature review protocol. Furthermore, we have performed an exploratory study to identify the traditional elicitation techniques that can be used specifically for eliciting the tacit requirements. Additionally, we validate the top 15 critical challenges in a normal and pandemic scenario. To validate the result’s authenticity and legitimacy, appropriate statistical tests have been applied on the obtained results. Based on the attained results, it is observed that transfer of tacit knowledge remains a most crucial challenge. To effectively handle the tacit knowledge challenge, we propose a novel conceptual model supporting COVID-19 context. Similarly, we employ expert-validation mechanism for empirically evaluation of the proposed conceptual model. Moreover, the current study provides the guidelines for the practitioners to mitigate the highlighted effects on the requirements elicitation process during current pandemic time. Finally, we believe that proposed conceptual model supports the practitioners in effectively gathering the tacit-knowledge based requirements in the COVID-19 context.

Gamification and Gaming Elements for Software Requirements Elicitation: A Systematic Literature Review

Gamification and Gaming Elements for Software Requirements Elicitation: A Systematic Literature Review

Requirements Engineering for Software Systems: A Systematic Literature Review

This article contains a systematic literature review of requirements engineering for software systems. The literature published within last 5 years was included into the review. A research question was defined as requirements development process of large scale software system (with thousands of requirements) and an interaction problem during this process (communication, coordination and control). The problem is caused by the fact that large-scale software system requirements process is a cross-disciplinary task and it involves multiple parties — stakeholders, domain experts, and suppliers with own goals and constrains, and thus, the interaction between them seriously slows down the overall requirements development process than writing the requirements specification itself. The research papers were classified by several research directions: Natural Language Processing for Requirements Engineering (NLP4RE), Requirement Prioritization, Requirements Traceability, Quality of Software Requirements, Non-functional Requirements and Requirements Elicitation. Motivation and intensity of each direction was described. Each direction was structured and represented with the key references. A contribution of each research direction into the research question was analyzed and summarized including potential further steps. It was identified that some researchers had met a part of the described problem in different forms during their researches. At the end, other researches were described additionally in a short overview. To approach the research question further potential direction was described.

Development of framework to support software requirement elicitation using a domain ontology

One of the main goals of Software Requirements Engineering is to understand customers' needs and to put their customer needs in requirement. The requirement engineering has several processes one of them are requirement elicitation the requirement elicitation considered as one process of requirement engineering and also considered as important process so the process of elicit the requirement has difficult, due to the incompleteness problem, ontology has player important rule to helps the requirement elicitation by adding more information about the words. in this paper implementing framework by using domain ontology, the frame work implement using java and ontology using protégé, the framework evaluated using requirement in in banking domain, and show the results helps the software developer to choose the requirement.

Development of framework to support software requirement elicitation using a domain ontology

One of the main goals of Software Requirements Engineering is to understand customers' needs and to put their customer needs in requirement. The requirement engineering has several processes one of them are requirement elicitation the requirement elicitation considered as one process of requirement engineering and also considered as important process so the process of elicit the requirement has difficult, due to the incompleteness problem, ontology has player important rule to helps the requirement elicitation by adding more information about the words. in this paper implementing framework by using domain ontology, the framework implements using java and ontology using protégé, the framework evaluated using requirement in in banking domain, and show the results helps the software developer to choose the requirement.

The patterns of user experience for sticky-note diagrams in software requirements workshops

Software requirements elicitation workshops often make use of a widely used and, on the surface, highly informal, notational medium: the sticky note. Often, in such workshops, facilitators and participants collaborate to construct “diagrams” made up of sticky notes. Methodologies have been developed that prescribe the way that diagram construction can uncover and document software requirements. Because they constitute a collaborative diagrammatic notation, such sticky-note diagrams lend themselves to an evaluation underpinned by theories of visual notation. In this paper we apply an analytic framework, the Patterns of User Experience (PUX), to sticky-note diagrams from two workshop methodologies, “Big Picture Event Storming” (BPES) by Alberto Brandolini and “User Story Mapping” (USM) by Jeff Patton. Our evaluation considers the sticky-note diagrams and the collaborative social processes surrounding them.