Natural Language Processing: An Inevitable Step in Requirements Engineering

Natural Language Processing: An Inevitable Step in Requirements Engineering

A. Egemen Yilmaz
DOI: 10.4018/ijssoe.2014010105
(Individual Articles)
No Current Special Offers


Requirement analysis is the very first and crucial step in the software development processes. On the other hand, as previously addressed by other researchers, it is the Achilles' heel of the whole process since the requirements lie on the problem space, whereas other software artifacts are on the solution space. Stating the requirements in a clear manner eases the following steps in the process as well as reducing the number of potential errors. In this paper, techniques for the improvement of the requirements expressed in the natural language are revisited. These techniques try to check the requirement quality attributes via lexical and syntactic analysis methods sometimes with generic, and sometimes domain and application specific knowledge bases.
Article Preview


System/software requirement quality is one of the most important drivers for the success of a final system/software related product. But ironically, as stated by Kof (2005), in practice “requirements engineering is the Achilles’ heel of the whole software development process”, because requirements documents are usually inconsistent and incomplete. Cheng and Atlee (2007) identify the main reason for this as follows: “… because requirements reside primarily in the problem space[;] whereas[,] other software artifacts reside primarily in the solution space”.

A study showed that the user involvement is the most important factor for the success of the software development projects (Standish Group, 1995). Moreover, even in the cases where the user involvement is sufficient, the success is dependent on clear statement of the requirements, which appears as the third most important factor on the list. In addition, other studies showed that the underlying reason for 60 to 85% of the software errors during a system’s life time is nothing but the requirement defects (Davis, 1990; Schach, 1992; Young, 2001). On the other hand, if such defects could not be fixed at the early phases of the projects, the cost of fixing the error would dramatically increases at each phase of the development life cycle as seen in Table 1 (Young, 2001). Defects detected during requirement analysis and design phases could reduce the rework effort between 40% and 50% (Boehm, 1981; Boehm & Basili, 2001; Gause & Weinberg, 1989).

Table 1.
Relative cost of fixing an error (Young, 2001)
Phase in which the Error is FoundRelative Cost
Requirements Analysis1
Coding & Unit Test10
Development Testing15-40
Acceptance Testing30-70

All the above studies support that, effective customer interaction and defect-free requirement engineering processes are the key factors for successful system/software development.

Pohl’s requirement engineering process model (Pohl, 1994), depicted in Figure 1, might be considered as a reference for the improvement the software requirement quality. Pohl’s model suggests focusing on the three dimensions seen in Figure 1. Stakeholders of the requirement engineering process should perform a progress on the specification, representation and agreement dimensions. Hence, tools supporting progress in any of those three dimensions would increase the success rates of software development projects.

Figure 1.

Pohl’s requirement engineering model (Adapted from (Pohl, 1994))


Complete Article List

Search this Journal:
Volume 13: 1 Issue (2023): Forthcoming, Available for Pre-Order
Volume 12: 2 Issues (2022): 1 Released, 1 Forthcoming
Volume 11: 2 Issues (2021)
Volume 10: 2 Issues (2020)
Volume 9: 2 Issues (2019)
Volume 8: 4 Issues (2018)
Volume 7: 4 Issues (2017)
Volume 6: 4 Issues (2016)
Volume 5: 4 Issues (2015)
Volume 4: 4 Issues (2014)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing