A Bayesian Network for Predicting the Need for a Requirements Review

Abstract

One of the major problems when developing complex software systems is that of Requirement Engineering. The methodologies usually propose iterations in which requirements are to be reviewed and re-written until the final version is obtained. This chapter focuses on the construction of “Requisites”, a Bayesian network designed to be used as a predictor that tells us whether a requirements specification has enough quality to be considered as a baseline. Requisites have been defined using several information sources, such as standards and reports, and through interaction with experts, in order to structure and quantify the final model. This Bayesian network reflects the knowledge needed when assessing a requirements specification. The authors show how Requisites can be used through the study of some use cases. After the propagation over the network of information collected about the certainty of a subset of variables, the value predicted will determine if the requirements specification has to be revised.

Bayesian networks for enhancement of requirements engineering: a literature review

“…and ''Map'' (i.e., mapping) in Table 9 collate which method was used in each study. Nevertheless, all the studies included in this review have more or less followed, the previously defined steps, with only a few papers including the specific way in which they tackled each one [16] in S2, S3 and S6. The selection of the variables and the relations between them (i.e., VI and QS steps) have been carried out using three different paths: mapping requirement artifacts as variables in the networks, defining relevant variables from experts (i.e., requirements engineers) or applying machine learning techniques in databases.…”

“…Several domain experts must be consulted, and the knowledge engineer finds out what the valid structures are that represent the knowledge domain. Due to the human nature of this communication-intensive task, the authors usually need to use linguistic terms S1, or, otherwise, they use a negotiated VI and QS starting point (e.g., standards on software engineering) [16] in S2 and S3.…”

“…The iterative nature of requirements is discussed in S9 and [16] in S2. These studies evaluate the accuracy of the elicited and specified requirements in order to assist developers in deciding when to start the next stage of the development process.…”

“…A BN can provide the theoretical foundation to incorporate accumulated evidence such as this in a unique inference process [28] in S8 and S17. So, for example, researchers obtained predictors that indicate the healthiness of a software project S1, the goodness of the software requirements specification [16] in S2, the software quality S3, software safety integrity S14, if the software is good to release S16, the risk of requirements S18, S19, or an early quality prediction (especially in market-driven development) S11. The predictor core in all these works is a BN.…”

“…[50] . A model of agile release planning S2 [16,17] . REQUISITE, this BN assess goodness of the software requirement specification (SRS)…”