Representation: Formal Development and Computational Recognition of Localized Requirement Change Types

Abstract

Requirement change propagation, the process in which a change to one requirement results in additional requirement changes when otherwise this change would not have been needed, occurs frequently and must be managed. Multiple approaches exist, and have been readily published, for predicting requirement change propagation, analyzing change how a change to one requirement may propagate forward to other, related requirements (global level). However, the type of change encountered within a single requirement (localized level) has not been thoroughly studied and could be used to assist in the global analysis of requirement change propagation. This paper seeks to begin to fill this gap by identifying types of change requirements may encounter. By surveying research performed in the realm of requirement change, a taxonomy of change types is developed. To computationally analyze the changes, the localized requirement changes are represented through syntactical elements to identify which requirements’ parts of speech is affected. Using part of speech language rules, the identification of requirement change type is automatically identified. Further, the automatic identification of requirement change type is used to assist in predicting change propagation, a process currently automated. This bridges the gap between localized and global requirement change in an automated, systematic manner.

Requirements change: Understanding the type of changes in the requirements document of novice designers

“…To that end, first, requirements in the initial week and final week were parsed into the components: system (subject), necessity (modal), behavior/characteristic (main verb), object and condition (complement or adjunct). 29,30 These changes are highlighted in the rows as system, necessity, and condition. A comparison was made between initial week and final week components to identify which of the components changed.…”

“…29,30 This accounts for changes in the system, necessity, behavior/characteristics, object, or condition of a requirement. Figure 3 illustrates the overview of the changes in the natural language requirements elements.…”

“…If there was a change to the requirement, then the aspects of change are recorded, such as the introduction of a new system or a change in importance. These change types are based on the work of Morkos et al 29 Thus, the number of addition, deletions, change, and no change were counted and recorded in a summary table as shown in Table 2.…”

“…Table 4 provides explanation of change types identified by examining the requirements for this study based on the types proposed in literature. [27][28][29] A requirement pair can have multiple change types, as seen in the changes for requirement 7(I) to 7(F) with changes in the introduction of a new system, the definition of an importance for the requirement, and a change in the specificity of the requirement (Figure 1). The change types for all requirement pairs for all teams are The change types for all requirement pairs for all teams were identified in this manner, and a summary table was created by counting the number of each change type for each team as shown in Table 5.…”

Corporate Requirement Culture in Development of a Large Scale Medical System: A Case Study

“…However, a gap exists within the electromechanical field, as its design requirement tools do not adequately address the effects of change on development time and cost (Becerril et al, 2016). Requirement change must therefore be understood to enable the development of such a tool as often those provided by software engineering do not cover the needs of the mechanical design community (Morkos et al, 2012a). The broad research objective is to examine the evolution of engineering requirements with a focus on the effects of change across requirements revisions to enhance the usability and value added by requirements.…”