Data Quality-Based Requirements Elicitation for Decision Support Systems

Introduction

It is a well-known fact that, among the phases of the software development process, analysis and specification of functional and nonfunctional requirements is a crucial one. The lack of good requirements specification is a major cause of failure in software development (Thayer, 2002). The software engineering community has developed many useful tools for requirements analysis in transactional systems. These kinds of systems deal with the day-to-day operation of an organization. Decision support systems (DSS) are of a completely different kind: they are focused on integrating data and models in order to improve the decision-making process. The data that feed a DSS generally reside in a data warehouse. The software development cycle of DSS has particularities that require applying methodologies different than the ones used for operational systems. The reason for this is twofold: on the one hand, traditional methodologies have been thought and designed with transactional systems in mind; on the other hand, specific methodologies applicable to DSS arose as ad-hoc answers to practical needs, and most of them are just mere enumerations of activities that must take place in order to implement the system, focusing on populating the data repository while ignoring important issues like the impact of changes in the operational data sources, or worse, if these data sources satisfy the users’ information requirements. New sources of failure are present in DSS: correctness and trustworthiness of the information are the basis of the decision-making process. We do not only need to understand the user’s information needs, but also account for keeping the data repository up-to-date according to user specifications. Also, update processes and their frequency must be considered, as well as the analysis of the quality and completeness of the data sources.

It follows that there is a need for techniques that, besides accounting for the software process cycle and functional requirements, also consider the quality of the information the system will deliver. There are several reasons for this. For instance, most of the time, people developing information systems do not consider the impact of low quality data (Kimball, Reeves, Ross, & Thornthwaite, 1998). Low data quality is more a rule than an exception. Just to give an example, it has been detected in the U.S., that approximately 50 to 80% of the computerized criminal records are inaccurate, incomplete, or ambiguous (Strong, Yang, & Wang, 1997). So far, the contribution of software engineering for addressing the problems stated has been limited, although many techniques have been proposed in order to analyze and measure a data quality requirement. Some examples of these techniques are GQM (goal question metric) (Basili, Caldiera, & Rombach, 1992) and QFD (quality function deployment) (Akao,1997).

In summary, traditional software development methodologies do not apply to DSS, and focus on software correctness, paying little attention to the problem of data quality and completeness, given that, in general, this is not considered an issue in the requirement analysis phase of the software development cycle for operational systems. Based on these points, we propose a methodology called DSS-METRIQ that integrates concepts of requirements engineering and data quality, in order to provide a comprehensive solution to the requirements elicitation process specifically oriented to DSS.