Improving User Participation in Requirement Elicitation and Analysis by Applying Gamification Using Architect’s Use Case Diagram
01 Jan 2016-pp 471-482
TL;DR: The research result shows that gaming using AUCD improves user participation in requirement elicitation, which helps the analyst to capture more architecturally significant requirements.
Abstract: Customer involvement and lack of expressive communication mechanism are the major problems in capturing Architecturally Significant Requirements (ASR) in requirement elicitation and analysis stage in the software development. In our earlier work we have introduced Architect Use Case Diagram (AUCD) an enhanced version of use case diagram, which is useful to specify functional and quality attribute requirements in one diagram. Gamification is an emerging technique used in the software industry to improve the user’s commitment, inspiration and performance. In this paper we proposed gamification using AUCD, a new methodology for requirement elicitation and analysis. The combination of gamification and AUCD motivates the users to participate in the requirement elicitation and analysis actively, which helps the analyst to capture more architecturally significant requirements. The proposed gamification using AUCD method is applied in different projects for validating the effectiveness. The research result shows that gaming using AUCD improves user participation in requirement elicitation.
Citations
More filters
TL;DR: The question about benefits of gamification usage is answered: whether gamification in the project leads to the desired results and increases the employee productivity and motivation.
Abstract: Gamification is one of the many ways to motivate employees and introduce more fun in daily activities. The aim of the paper is to analyse the impact of gamification method on the software development projects. The paper contains results of a literature review about application areas of gamification, methods, positive and negative effects on projects. The paper also presents an overview of the gamification tools used in software development projects and attempts to answer the question about benefits of gamification usage: whether gamification in the project leads to the desired results and increases the employee productivity and motivation.
13 citations
Cites background from "Improving User Participation in Req..."
...All participants of research described in [6], [9], [18], [22], and [24] mentioned the best motivation to work, the opportunity to track work progress, better communication among team members, the consolidation of the team and the ability to view their and colleagues’ achievements through the use of certain game components, for example, leaderboards, badges or point tables....
[...]
...At the stage of defining the requirements, there are improvements such as an increase in the number of ideas, an increase in motivation, an improvement in the quality of claims, and an increase in creativity, which contribute to the improvement of this process [22]....
[...]
...The requirements are documented for further transfer to the development [10], [22]....
[...]
01 Aug 2020
TL;DR: Gamification, a game-based context will be used in non-gaming context for user involvement in fun ways and a gamification tool with a focus to elicit unambiguous requirements by ensuring users’ participation and maintaining interest is developed.
Abstract: The overall quality and success of software highly depends on the involvement of stakeholders. Requirements elicitation supports RE analyst to gather requirements from the stakeholders based on their needs. There are multiple elicitation techniques present in literature and used by the practitioners. Some of them are questionnaires, interviews, prototyping, and user stories etc. However, these techniques are based on textual representation of requirements. These techniques are quite common among the requirement engineers yet problems of ambiguity, inconsistency, incompleteness still exist mostly due to their textual nature and lack of stakeholder involvement. Lack of clarity about the system increases the ambiguity of what exactly are the system requirements. Since elicitation is carried at an early stage of development the users are not sure of what they want, as requirements tend to evolve with the help of discussions and interactions among various stakeholders and technical team. Furthermore, the conventional elicitation methods are limited when it comes to stakeholders’ participation and involvement, thus leaving a space for more ambiguous and incomplete requirements. In this work, Gamification, a game-based context will be used in non-gaming context for user involvement in fun ways. During elicitation, gamification would help to involve and interact with the stakeholders, with an intention to develop their interest in eliciting and finalizing system requirements. The goal of this paper is to reduce ambiguity during requirements elicitation. This would help in reducing the cost and time of development. Furthermore, we will elicit software requirements using gamification by developing a gamification tool with a focus to elicit unambiguous requirements by ensuring users’ participation and maintaining interest. The validation of tool would be done using multiple confirmatory case studies from software industry.
8 citations
Cites methods from "Improving User Participation in Req..."
...For elicitation, requirements visualization is considered as a good approach to attract stakeholders, such as Architect Use Case Diagram (AUCD) [40]....
[...]
...AUCD was a UML based model that doesn’t support NLP [40]....
[...]
...In AUCD, images are used as communication media and requirements’ representation is in visuals....
[...]
...To involve more customers and facilitate expressive communication for capturing architecturally significant requirements, gamification using AUCD was proposed for requirements elicitation and analysis....
[...]
...AUCD uses use case diagram to manage functional and quality attributes in one diagram, hence it doesn’t support natural language requirements....
[...]
13 Jun 2018
TL;DR: This analysis highlights the increase in the number of studies that use gamification as an improvement strategy for software project management processes areas, and proposes a systematic mapping as a research method that facilitates the identification of primary studies to analyze information and classify it based on established research criteria.
Abstract: Throughout history, software project management issues have been known to negatively affect the software quality and the success of this type of projects. Faced with such issues, some research have proposed solutions to improve the results in software project management in order to contribute significantly to its success. The objective of this paper is to carry out a study of the context of software project management, identifying the management areas that have been intervened with gamification strategies for software process improvement. To this end, this work proposes a systematic mapping as a research method that facilitates the identification of primary studies to analyze information and classify it based on established research criteria. We found 55 primary studies published between 2011 and 2017, on which we performed an information analysis. This analysis highlights the increase in the number of studies that use gamification as an improvement strategy for software project management processes areas. We classified the selected studies by analyzing the type of research method and the type of publication. This analysis shows that it is still an area of research in development and that it is necessary to continue working on the improvement of software project management processes with the aim of contributing to the success of its results.
8 citations
Additional excerpts
...Alcance [32][54][29] [30][31][33][26][2 5][27][28] 0 0 0 10...
[...]
...Alcance [25] [26][27][28] [29] [30][31][32 ][33] 9 Programación 0 0 0 0 0 Costos 0 0 0 0 0 Calidad 0 [34] 0 0 1...
[...]
30 Mar 2021
TL;DR: In this paper, a set of gamification strategies characterized according to their contribution to stakeholders' collaboration, communication, and participation in the requirements elicitation process were collected via a systematic literature review process In this process, a selection of strategies was made Such strategies were analyzed and characterized Results showed that software tools are one of the most frequently used strategies.
Abstract: Requirements elicitation is an important process for software product development This process involves detecting and understanding clients’ and users’ needs From this process is possible to provide clarity about the definition of the requirements to be used in the next stages of the software development Although important, stakeholders’ collaboration in the elicitation process is scarce In this regard, providing supporting strategies to foster collaboration in this type of process has become a motivating and challenging study area for researchers This paper intends to define a set of gamification strategies characterized according to their contribution to stakeholders’ collaboration, communication, and participation in the requirements elicitation process These strategies were collected via a systematic literature review process In this process, a selection of strategies was made Such strategies were analyzed and characterized Results showed that software tools are one of the strategies being the most frequently used Future work may include descriptive statistics to improve the analysis and characterization of the strategies
3 citations
23 Sep 2019
TL;DR: A systematic literature review (SLR) to identify, gather and analyze strategies for UCM is presented, which can help teachers in the adoption of the most appropriate UCM strategies for their students.
Abstract: A major challenge in teaching use-case modeling (UCM) is to mitigate the difficulties of students that prevent them from producing use-case models with quality. The strategies for UCM are scattered in the literature in several areas, and may not be known to the students, who therefore fail to receive the benefits that would mitigate their difficulties. This paper aims to present a systematic literature review (SLR) to identify, gather and analyze strategies for UCM. During the SLR, two thousand two hundred sixty-six studies published between 2008 and 2018 were returned from 6 bases (ACM, IEEE, Scopus, Science Direct, SpringerLink and Engineering Village), which resulted in the selection of 39 primary studies. These were classified, following the coding procedures of Grounded Theory, into 13 categories of different strategies for UCM. The results can help teachers in the adoption of the most appropriate UCM strategies for their students. Besides, they provide a quick reference for teachers and researchers interested in conducting additional studies on teaching strategies for UCM.
2 citations
References
More filters
Book•
01 Jan 1999
TL;DR: In The Unified Modeling Language User Guide, the original developers of the UML provide a tutorial to the core aspects of the language in a two-color format designed to facilitate learning.
Abstract: In The Unified Modeling Language User Guide, the original developers of the UML--Grady Booch, James Rumbaugh, and Ivar Jacobson--provide a tutorial to the core aspects of the language in a two-color format designed to facilitate learning. Starting with a conceptual model of the UML, the book progressively applies the UML to a series of increasingly complex modeling problems across a variety of application domains. This example-driven approach helps readers quickly understand and apply the UML. For more advanced developers, the book includes a learning track focused on applying the UML to advanced modeling problems.With The Unified Modeling Language User Guide, readers will:Understand what the UML is, what it is not, and why it is relevant to the development of software-intensive systemsMaster the vocabulary, rules, and idioms of the UML in order to "speak" the language effectivelyLearn how to apply the UML to a number of common modeling problemsSee illustrations of the UML's use interspersed with use cases for specific UML features, andGain insight into the UML from the original creators of the UML.
6,634 citations
01 Aug 2005
TL;DR: This paper presents an analysis of Empirical Requirements Survey Data and some of the lessons learned can be applied to the management of Quality Software Systems in the Public Sector.
Abstract: 1) Requirements Engineering: Setting the Context Part-1: State-of-the-Art Surveys of Requirements Engineering Process Research 2) Requirements Elicitation 3) Specification of Requirements Models 4) Requirements Prioritization 5) Requirements Interdependencies 6) Impact Analysis 7) Requirements Negotiation 8) Quality Assurance in Requirements Engineering Part-2: The Next Practice in Requirements Engineering 9) Modeling Goals and Reasoning with Them 10) Managing Large Repositories of Natural Language Requirements 11) Understanding Ambiguity in Requirements Engineering 12) Decision Support in Requirements Engineering 13) Market-Driven Requirements Engineering for Software Products 14) Requirements Engineering for Agile Methods 15) Requirements Engineering for Web-Based Information Systems Part-3: Studies and Industrial Experience 16) Requirements Engineering: A Case of Developing and Managing Quality Software Systems in the Public Sector 17) Good Quality Requirements in Unified Process 18) Requirements Experience in Practice: Studies of Six Companies 19) An Analysis of Empirical Requirements Survey Data 20) Requirements Engineering: Solutions and Trends
433 citations
TL;DR: A systematic mapping of the field of gamification in software engineering is carried out in an attempt to characterize the state of the art of this field identifying gaps and opportunities for further research.
Abstract: Context Gamification seeks for improvement of the user’s engagement, motivation, and performance when carrying out a certain task, by means of incorporating game mechanics and elements, thus making that task more attractive Much research work has studied the application of gamification in software engineering for increasing the engagement and results of developers Objective The objective of this paper is to carry out a systematic mapping of the field of gamification in software engineering in an attempt to characterize the state of the art of this field identifying gaps and opportunities for further research Method We carried out a systematic mapping with a view to finding the primary studies in the existing literature, which were later classified and analyzed according to four criteria: the software process area addressed, the gamification elements used, the type of research method followed, and the type of forum in which they were published A subjective evaluation of the studies was also carried out to evaluate them in terms of methodology, empirical evidence, integration with the organization, and replicability Results As a result of the systematic mapping we found 29 primary studies, published between January 2011 and June 2014 Most of them focus on software development, and to a lesser extent, requirements, project management, and other support areas In the main, they consider very simple gamification mechanics such as points and badges, and few provide empirical evidence of the impact of gamification Conclusions Existing research in the field is quite preliminary, and more research effort analyzing the impact of gamification in SE would be needed Future research work should look at other game mechanics in addition to the basic ones and should tackle software process areas that have not been fully studied, such as requirements, project management, maintenance, or testing Most studies share a lack of methodological support that would make their proposals replicable in other settings The integration of gamification with an organization’s existing tools is also an important challenge that needs to be taken up in this field
312 citations
Book•
[...]
20 Aug 2002
TL;DR: This book discusses the basic building blocks of a Use-Case Modeling, and the role of Stakeholders and Stakeholder Representatives in the Project, as well as finding Actors and Use Cases and identifying the Primary Actors.
Abstract: (NOTE: Each chapter concludes with a Summary.) Foreword. Preface: Why Bother with Use Cases? What Are "Use Cases" All About? Who Should Be Interested in Use Cases? How to Read This Book. I. GETTING STARTED WITH USE CASE-MODELING. 1. A Brief Introduction to Use-Case Modeling. Actors and Use Cases. Use-Case Diagrams. The Relationship Between Use Cases and Requirements. Types of Requirements. Functional and Nonfunctional Requirements. The Role of Use Cases. Use Cases Place Software Requirements in Context. To "Use Case" or not to "Use Case". When Are Use Cases Useful? Use Cases Provide a Conceptual Model of the System. Use Cases Describe How the System Is Used and What It Does for Its Stakeholders. Does Everything the System Does Have to Be Described in a Use Case? General Principles of Use-Case Modeling. Use Cases Do Not Exist In Isolation. Use Cases Are a Synthetic Rather Than an Analytic Technique. Rules of Thumb. 2. Fundamentals of Use Case Modeling. The Use-Case Model. The Basic Building Blocks of a Use-Case Model. Actors. Use Cases. Connecting Actors and Use cases. Use-Case Diagrams. Brief Descriptions. Use-Case Descriptions. Supporting Artifacts. The Glossary and/or the Domain Model. Supplementary Specifications. Declarative and Special Requirements. 3. Establishing the Vision. Introducing Stakeholders and Users. What Are Stakeholders? The Role of Stakeholders and Stakeholder Representatives. Users: A Very Important Class of Stakeholder. Stakeholders and Use-Case Modeling. Involving Stakeholders and Users In Your Project. Step 1: Identify Stakeholder and User Types. Step 2: Identify and Recruit the Stakeholder Representatives. Step 3: Involve the Stakeholder Representatives in the Project. Creating a Shared Vision. Analyze the Problem. Understand the Key Stakeholder and User Needs. Describe the Features and Other High-Level Product Requirements. Provide an Overview of the Product. Bringing It All Together: The Vision Document. Do You Really Need To Do All Of This? 4. Finding Actors and Use Cases. Finding Actors. Start by Identifying the Primary Actors. Work from the Specific to the General. Don't Forget the Supporting Actors. Consider All Existing Requirements Information. Remember That Actors Are Not Always People. Focus on the System Boundary. Identify the information sources. Don't Preempt the Design. Don't Confuse the Actors with the Devices They Use. When you Can't Find the Actors, Start with the Use Cases. Focus First on the Familiar. Evolve the Set of Actors Alongside the Set of Use Cases. Documenting Actors. How to Name Actors. Don't Confuse Actors with Organizational Roles or Job Titles. Don't Overgeneralize. Give Every Actor a Brief Description. Characterize the Actors. Trace the Actors to the User Types, Stakeholders, and Stakeholder Roles. Finding Use Cases. Start by Identifying the Actor Goals. Consider the Information Needs of the System and Its Users. Don't Worry About Commonality (at least at first). Don't Confuse Use Cases with "Functions". Focus on Value. Derive the Use Cases from the System's Vision. Don't Forget the Supporting and Operational Use Cases. Evolve the Set of Use Cases Alongside the Set of Actors and the Supplementary Specification. Documenting Use Cases. Associate the Use Cases to their Actors. Name the Use Cases. Give every Use Case a Brief Description. Outline the Use Cases. Trace the Use Cases to Stakeholders and Stakeholder Roles. Trace the Use Cases to the Features and Constraints. 5. Getting Started With A Use Case Modeling Workshop. Reasons for Having a Workshop. To Transfer Expertise. To Build a Team. To Create Shared Understanding. To Tap into the Creative Power of a Group. Preparing for the Workshop. Train the Participants. Understand the Vision. Keep the Group Small and Involved. Vary the Composition of the Group. Select a Facilitator. Set Objectives for the Workshop. Schedule the Workshop and Organize the Facilities. Finding a Mentor. Find an Effective Communicator. Find a Skilled Motivator and Manager. Find a Mentor with Full Lifecycle Experience. Don't Use the Mentor as a Crutch. Structuring the Workshop. Define the Ground Rules for the workshop. Understand the Problem. Define the Boundary of the System. Identify Actors. Identify Use Cases. Consolidate the Model and Validate the Results. Wrap Up the Workshop and Plan the Next Steps. Supporting Activities. Capture Terminology in a Glossary. Capture Nonfunctional Requirements. Capture Issues, Risks and Assumptions. Handling Common Problems. Avoid Functional Decomposition and Dataflow Modeling. Maintain Focus. Synthesize, Don't Analyze. Don't Describe What Happens Outside the System. Don't Just Draw Pictures. Don't Mix Business Use Cases and System Use Cases. 6. The Lifecycle of a Use Case. The Software Development Life Cycle. The Authoring Life Cycle. State 1: Discovered. State 2: Briefly Described. State 3: Bulleted Outline. State 4: Essential Outline. State 5: Detailed Description. State 6: Fully Described. Team Working. The Use-Case Modeling Process. Establish the Vision. Produce an Overview of the System. Reach Agreement on System Scope. Package the Use-Case Model. Address Areas of Instability and Author Stable Use Cases and Supplementary Specifications. Consolidate and Review the Use-Case Model. II. WRITING AND REVIEWING USE-CASE DESCRIPTIONS. 7. The Structure and Contents of a Use Case. Use Cases and System State. The System and External Events. The System State: More about Preconditions and Postconditions. How Use Cases Interact. The SideEffects of Using PreConditions. The Nature of the Flow of Events. The Structure of the Flow of Events. Managing Scope Using Alternative Flows. The Complexity of the Use-Case Model Versus the Complexity of the Design. Visualizing the Flow of Events. What Is a Scenario? What Is a Use-Case Realization? 8. Writing Use-Case Descriptions: An Overview. Who Writes Use-Case Descriptions? Programmers Write Poor Descriptions. The Characteristics of a Good Use-Case Author. How Long Does It Take to Write a Use Case? Getting Started. Use a Style Guide. Write Simply, Directly and Deliberately. Treat the Use Case Like a Story. Make a Conscious Decision about the Depth of Detail Required. Describe What Happens When the Actors and the System Interact. Don't Rely on Just Text. Prototype the User Interface. Managing Detail. Good Use-Case Models Have No "Levels". Adapt the Description to Your Intended Audience. Use the Glossary and Domain Model to Capture Definitions. Capture Business Rules in a Domain Model. Use Subflows to Simplify Complex Descriptions. Use Alternative Flows to Capture Unusual or Complex Behavior. Don't Fill Your Use Cases with CRUD. Don't Be Afraid of Capturing the Detail. 9. Writing Use-Case Descriptions: Revisited. How Much Detail Is Enough? Describing Preconditions. Deciding Whether a Precondition Is Needed. Describing Preconditions. Describing Postconditions. Deciding Whether Post Conditions Are Needed. Describing Postconditions. Writing The Flow of Events. Writing the Basic Flow of Events. Pay Attention to What's Behind the Screen. Using the Glossary and the Domain Model. Writing "Named" Subflows. Writing Optional, Alternate and Exception Flows. Identifying Alternative Flows. Representing Alternative Flows in Separate Sections. Naming Alternative Flows. Using Extension Points to Target Alternative Behavior. Describing Alternative Flows That Can Occur Anywhere in the Use Case. Resuming the Use Case After the Alternative Flow Completes. Alternative Flows for Alternative Flows and Named Subflows. Writing Special and Supplementary Specifications. Capturing Use-Case Scenarios. 10. Here There Be Dragons. Using Named Subflows and Alternate Flows to Structure Text. Defining Relationships Between Use Cases. Using the Include Relationship. Common Errors Using the Include Relationship. Using the Extends Relationship. Extension Points, Revisited. Evaluating the Resulting Use-Case Model. Using Generalization between Use Cases. Defining Relationships Between Actors. 11. Reviewing Use Cases. Why Focus on Presenting and Reviewing Use Cases? Types of Reviews. Informal Reviews. Formal Reviews. What to Review, and When to Review it. Who Should Review the Use Cases. Understanding the Audience. Setting Expectations. Preparing for the Review. Running the Review Meeting. Handling Issues. What to Look For When Reviewing. Reviewing Diagrams. Reviewing Brief Descriptions. Reviewing Use-Case Descriptions. Reviewing Preconditions and Postconditions. Reviewing the Glossary and Domain Model. The Role of Prototypes and Storyboards in Use-Case Reviews. 12. Wrapping-Up. Use Cases and the Project Team. Developers and Use Cases. Testers and Use Cases. Use Cases and the User Experience. Use Cases and Documentation. Managers, Use Cases and Planning. Use Cases Across the Lifecycle. Use Cases and Iterative Development. Use Cases in the Inception Phase. Use Cases in the Elaboration Phase. Use Cases in the Construction and Transition Phases. Use Cases after Product Release. Traceability, Completeness and Coverage. What's Next? Appendix. Glossary. Bibliography. Index. 0201709139T08062002
293 citations
TL;DR: The results have revealed that UI does contribute positively to system success, but it is a double edged sword and if not managed carefully it may cause more problems than benefits.
Abstract: Context For more than four decades it has been intuitively accepted that user involvement (UI) during system development lifecycle leads to system success. However when the researchers have evaluated the user involvement and system success (UI-SS) relationship empirically, the results were not always positive. Objective Our objective was to explore the UI-SS relationship by synthesizing the results of all the studies that have empirically investigated this complex phenomenon. Method We performed a Systematic Literature Review (SLR) following the steps provided in the guidelines of Evidence Based Software Engineering. From the resulting studies we extracted data to answer our 9 research questions related to the UI-SS relationship, identification of users, perspectives of UI, benefits, problems and challenges of UI, degree and level of UI, relevance of stages of software development lifecycle (SDLC) and the research method employed on the UI-SS relationship. Results Our systematic review resulted in selecting 87 empirical studies published during the period 1980–2012. Among 87 studies reviewed, 52 reported that UI positively contributes to system success, 12 suggested a negative contribution and 23 were uncertain. The UI-SS relationship is neither direct nor binary, and there are various confounding factors that play their role. The identification of users, their degree/level of involvement, stage of SDLC for UI, and choice of research method have been claimed to have impact on the UI-SS relationship. However, there is not sufficient empirical evidence available to support these claims. Conclusion Our results have revealed that UI does contribute positively to system success. But it is a double edged sword and if not managed carefully it may cause more problems than benefits. Based on the analysis of 87 studies, we were able to identify factors for effective management of UI alluding to the causes for inconsistency in the results of published literature.
230 citations