Engaging Stakeholders in Defining Early Requirements

Abstract

Dealing with organisational change and information systems development is about two sides of the same coin – designing for the future. Developing business strategies, designing business processes and implementing support systems are interrelated activities that need to be considered at a systemic level in order to deliver high quality results. From a Systems Engineering perspective it is no longer appropriate to focus exclusively on functional and non-functional aspects of the intended system. It is also crucially important to understand the trade-off of requirements against all stakeholders’ parameters. As a field of intellectual endeavour and industrial practice, Requirements Engineering has traditionally been concerned with goals for, functions of and constraints on software intensive systems. The need for a greater understanding of the interdependencies between enterprise functions and information systems functions challenges this view and forces us to consider a broader perspective, one that enables us to analyse alternatives to realising different strategic options available to (re)design of systems. A key challenge in the development of systems is the engagement of domain experts in their articulation, agreement, and validation of requirements. This challenge is particularly pronounced at the so-called early requirements phase when multiple stakeholders from different divisions and often different organisations need to reach agreement about the intended systems. Decisions taken at this stage have a profound effect on the technical and economic feasibility of the project. It is no longer appropriate for information systems professionals to focus only on functional and non-functional aspects of the intended system and somehow assume that organisational context and needs are outside their remit. What distinguishes early requirements from late (or support system) requirements, is the degree of involvement of client stakeholders. Early requirements are almost exclusively driven by client stakeholders’ communication. Issues of early requirements include: (a) the customer profiles of a business process, (b) the likely demand for product or service made by each type of customer, (c) the level of desirable service that the business process should strive to achieve, (d) the resources that are required in order to achieve these levels of service and (e) the trade-off between levels of service and requisite resource between all client stakeholders of a business process. Only when these issues have been resolved can one then begin to develop specifications of requirements for support systems. The analyst will need to know how the support system interacts with other systems, what kind of levels of service it must achieve and so on before engaging into further analysis on functional and nonfunctional properties of the intended system. These issues of early requirements are specifically tackled by the strategy-service-support (referred to as S) modelling approach (Loucopoulos, 2003). It is based on the premise that informal (c.f. (Galliers, 1993; Leymann et al., 1994), semi-formal (c.f. (Kavakli et al., 1999; Ould, 1995) or formal approaches (c.f. (Fuxman et al., 2003; Fuxman et al., 2001) to business process modelling do not fully address the issues relating to early requirements. The S modelling approach advocates a process cycle of hypothesis formulation, testing, and re-formulation until stakeholders have enough confidence about the efficiency of the proposed design. Essentially, one is developing theories, externalised as conceptual models, about the Universe of Discourse and tests these theories for their validity. These models are subsequently subjected to scenario generation in consensusbuilding stakeholder workshops.