Implicit Thinking Knowledge Injection Framework for Agile Requirements Engineering

Abstract

Agile has become commonly used as a software development methodology and its success depends on face-to-face communication of software developers and the faster software product delivery. Implicit thinking knowledge has considered as a very significant for organization self-learning. The main goal of paying attention to managing the implicit thinking knowledge is to retrieve valuable information of how the software is developed. However, requirements documentation is a challenging task for Agile software engineers. The current Agile requirements documentation does not incorporate the implicit thinking knowledge with the values it intends to achieve in the software project.This research addresses this issue and introduce a framework assists to inject the implicit thinking knowledge in Agile requirements engineering. An experiment used a survey questionnaire and case study of real project implemented for the framework evaluation. The results show that the framework enables software engineers to share and document their implicit thinking knowledge during Agile requirements documentation.

Agile Software Requirements Engineering Challenges-Solutions—A Conceptual Framework from Systematic Literature Review

“…Challenge 7 (C7)-Customer unavailable or low availability. Customer involvement and interactions with the development team are challenging [24,27,53], particularly with offshore development where the customer is located on a different site [21]. The challenge also refers to customers lacking authority to make decisions, surrogate customers not conveying real requirements [54], a weak relationship [38], and the low availability of customers for negotiation, clarification, and feedback [27,40].…”

“…Literature sources for each challenge. C1 QRs are neglected[6,10,12,17,20,21,[23][24][25][26][27][28][29]37,38,40,46,53,54,63,64,74-82] 30 C2 Minimal documentation [6,10,17,21,23,24,27,28,31-34,37,41,46,47,51,53-56,64,65,77,82] 25 C3 Inappropriate prioritisation method [10,20,21,23,25,27,30,34-37,39,40,46,47,54,59,60,62,74,77,83,84] 23 C4 Managing change [20,21,23,24,28,34,35,38-43,47,53,65,82-86] 21 C5 Poorly written requirements [20,21,27,28,34,37,38,40,44-47,54,55,59,61,71,74,78,87,88] 21 C6 Inaccurate effort estimation [10,20,21,23,24,27,31,40,43,46,48-54,62,89] 19 C7 Customer unavailable or low availability [10,20,21,23,24,27,28,34,38,40,47,53-55,59,65,74,77] 18 C8 Customer knowledge[21,23,24,31,38,46,47,[54][55][56]76,77,90] …”

“…Literature sources for each solution. S1 Provide the requirement information needed[13,17,23,24,27,28,42,[45][46][47]53,[59][60][61]71,74,83,91,92] 19…”