Dealing with Completeness in Requirements Engineering

Dealing with Completeness in Requirements Engineering

Graciela D. S. Hadad (FITI, Universidad de Belgrano, Argentina & DIIT, Universidad Nacional de La Matanza, Argentina), Claudia S. Litvak (FITI, Universidad de Belgrano, Argentina & DIIT, Universidad Nacional de La Matanza, Argentina), Jorge H. Doorn (INTIA, Universidad Nacional del Centro de la Provincia de Buenos Aires, Argentina & DIIT, Universidad Nacional de La Matanza, Argentina) and Marcela Ridao (INTIA, Universidad Nacional del Centro de la Provincia de Buenos Aires, Argentina)
Copyright: © 2015 |Pages: 10
DOI: 10.4018/978-1-4666-5888-2.ch279
OnDemand PDF Download:
$30.00
List Price: $37.50

Chapter Preview

Top

Introduction

The Requirements Engineering (RE) goal is to systematize the process of requirements construction and management (Maculay, 1993; Reubenstein & Waters, 1991; Maté & Silva, 2005) along with the creation of a compromise among clients and users with developers, since both human groups must participate and collaborate together. To accomplish such tasks, the requirements engineers should understand and participate in the definition of the context of use for the software system to be developed. The requirements engineers usually ignore totally or partially both, the current and the foreseen future context of use. The latter must be conceived having as a resource the new tool: the system software itself. Frequently, nobody knows in detail such future context of use. To be able to participate in the definition of the future business process, the requirements engineers must understand the current business process in advance. Therefore, the Requirements Engineering process involves, as the first step, elicitation and modeling of the current business process and later, definition and modeling of the future business process. Both models have different purposes. The first one is used as a help for understanding the current business process and as a tool to validate with clients and users such understanding. The second one is used as a help for the planning of the future business process, to validate such plans with the clients and users, to specify the software requirements and to give an environment reference for software designers.

The Requirements Engineering process consists of three main activities: elicitation, modeling, and analysis of the application domain (Kotonya & Sommerville, 1998; Sommerville & Sawyer, 1997). Analysis includes the sub-activities of verification, validation and negotiation. The difficulties that requirements engineers must face to understand and elicit the clients and users’ necessities are widely known. The more complex the application domain, the more difficult the definition or construction of software requirements becomes. Many times, requirements engineers must become themselves problem domain experts during the acquisition of knowledge about the application domain. Concurrently, Requirements Management deals with the changes in the existent requirements and the irruption of new ones (Kotonya & Sommerville, 1998; Sawyer & Kotonya, 2004).

RE provides methods, techniques and tools to help requirements engineers elicit and specify software requirements, ensuring their highest quality and completeness. However, the problem of completeness is a certain menace to requirements quality and it casts serious doubt on the whole Requirements Engineering process. Completeness is an unreachable goal and to estimate the degree of completeness obtained at a certain step in the software development process is also very difficult (Doorn & Ridao, 2008). The requirements engineer faces a Universe of Discourse (UofD) that seems she / he will hardly ever fully know. This situation is not unique during the whole software development process; something similar happens while testing.

The use of statistical models, based on capture and recapture methods (Otis, Burnham, White, & Anderson, 1978) to predict the number of defects in a code artifact, was successfully introduced some time ago (Petersson, Thelin, Runeson, & Wohlin, 2003) and later, these models have been used to discover defects in requirements documents (Walia & Carver, 2008). In this article, the use of capture and recapture information is applied in the RE field in order to make an estimation of the number of non-discovered requirements after a requirements elicitation process.

The following section analyses the validation problem in RE. Then, a section describing the use of the Language Extended Lexicon (LEL) and Scenarios in RE is included. After that, the problem of estimating closed population is studied. Later, the use of capture and recapture in RE domain is introduced; finally, some future work and conclusions are presented.

Key Terms in this Chapter

Elicitation: The activity of acquiring specific knowledge during the requirements engineering process.

Requirements Management: The activity of following up the evolution of the software system requirements set, dealing with the allocation of requirements to specific pieces of the software and with the changes in the requirements along time.

Scenarios: A semi-formal model describing observable situations in the current UofD or expected situations that would take place when the software system is put into operation.

Verification: The activity of checking different parts of a model or different models among them. It should answer the question: Are we creating the model right?

Validation: The activity of contrasting a model with the actual world. It should answer the question: Are we creating the right model?

Capture and Recapture: A method to estimate the abundance of members of a given class in a closed environment. Specimens are captured, marked and released.

Requirements Completeness: A quality demanded to the set of software requirements and to each requirement itself, in order to ensure that there is no information left aside.

Requirements Engineering: An area of the Software Engineering which is responsible for the systematization of acquiring and defining the capabilities of the software system.

Language Extended Lexicon: A semi-formal model holding the most relevant words or phrases of the application domain vocabulary carrying a special meaning.

Complete Chapter List

Search this Book:
Reset