How Business Departments Manage the Requirements Engineering Process in Information Systems Projects in Small and Medium Enterprises
Rudiger Weibbach · Issues in Informing Science and Information Technology · 2013
Introduction In literature on Requirements Engineering [RE], the RE process in information system projects is typically presented as a process conducted by requirement engineers, system engineers or similar skilled persons on the developer's site. In RE literature the participation of the future users or other stakeholders is seen as more passive: They are respondents in the process of RE elicitation. These scenarios are different to the author's experience and they leave unanswered questions: How will be the RE process conducted in projects without an explicit role for a requirements engineer? Especially small and medium enterprises [SMEs] are working without an explicit requirements engineer, sometimes even without qualified IT staff.- And how will the RE process be conducted in continuous improvement and in line management? To get a more differentiated view on the RE reality in SMEs the author started a research project in 2009, Departments in the Process of Requirements Engineering in Information Systems Projects, in German translation Fachabteilungen im Prozess der Anforderungsanalyse [FaPrAa] . Due to the lack of research to this topic the scope of this project is a pilot study. The objective of this project is to analyze: * in which scope, * in which function and * with which methodological base staff is involved in the RE process. The term business departments means departments, whose main mission is not the technological development of information systems. (This does not exclude End-User Development [EUD], see below, Related Work) We have to regard that the members of the could neither be seen stringently as internal clients in the meaning of paying or sponsoring the project nor as future users. The members of the are stakeholders in the meaning of being affected of a project. One assumption behind this research question is, that RE is an area of expertise, not only an organizational role. Area of expertise means a set of methods, knowledge and skills that enables a person to produce results of a certain type (Fahney et al., 2007). The remainder of this paper is structured as follows: The next chapter presents the relevance of the topic and the related work. The paper progresses with methodological information, followed by the findings, the discussion of them and proposals to further work. This paper finishes with the conclusions. Background Relevance of the Topic The relevance of requirements for the success or the failure of projects is noted in literature (e.g. Engel & Holm, 2007; Standish Group, 2001). Requirements are elicited and managed in the Requirements Engineering [RE] process. The RE process in information system projects is typically presented--for example in lecture books (e.g. Ebert, 2012; Pohl & Rupp, 2011; Robertson & Robertson, 2006)--as a process conducted by well-qualified requirement engineers, system analysts or similar skilled persons on the developer's site, who elicit the requirements from the users. In these models the users and the managers of the are involved as stakeholders, but not as acting people in the process. Own experience shows a different situation: Business define their requirements itself for information systems and they manage contracts with external IT companies. But this had not been an established research topic (see for example the overview of RE related research in Cheng & Atlee, 2007; Davey & Cope, 2008) and was not seriously discussed in lecture books (e.g. Ebert, 2012; Pohl & Rupp, 2011; Robertson & Robertson, 2006). This insufficient consideration in research leads to some problems: 1. The complexity of current real-world processes will not be understood. Especially the situation in SMEs will not be represented in its diversity. …