Non Functional Requirements (Nfrs) Traceability Metamodel for Agile Development

Abstract

Agile methodologies are well known for early and frequent releases. Besides, these methodologies also handle requirement changes well without causing delays. However, it has been noticed that the functional requirements changes can affect the non-functional requirements (NFRs) such as security and performance. It is also possible that the agile team is not even aware of these effects causing dysfunctional system. This issue could be addressed by offering traceability mechanism that helps to trace the effect of functional requirement changes on the non-functional requirements. Unfortunately, a few researchers have conducted studies regarding this issue. Thus, this study attempts to present a Traceability Process Model (TPM) to tackle the issue of tracing NFR especially security and performance. However, to materialize a full scale TPM, a metamodel is necessary. Therefore in this paper, we present a metamodel by integrating two existing metamodels. Then we validate the newly built metamodel with precision and recall methods. Lastly, we also develop a traceability tool that is based on the proposed metamodel.

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

“…Late testing and late QRs can cause rework [27,28]. Changes in Functional Requirements (FRs) affect QRs [29] and QRs are rarely implemented in a single piece of code [27]. Requirements from different stakeholders could conflict [30] that lead to poor QRs.…”

“…Solution 6 (S6) Maintain requirements traceability. Firdaus et al [29] propose a model to trace security and performance QRs. Urbieta et al [67] propose an approach using Language Extended Lexicon to organise user stories and assist with traceability.…”

“…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] …”