Empirical Results on Modelling Early Requirements

Empirical Results on Modelling Early Requirements

P. LOUCOPOULOS

Department of Computation

University of Manchester Institute of Science & Technology (UMIST)

P.O. Box 88, Manchester, M60 1QD, U.K.

Abstract: - 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 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. The S3 approach advocates the use of a modelling process expressed in terms of strategy-service-support dimensions, augmented by appropriate simulation techniques that enable experimentation with different scenarios. The aim of this paper is to provide insights from a large project in which the author played an active and interventionist part, on the utility of the S3 approach in facilitating stakeholder engagement in early requirements specification. The action research for this project involved the design of venue operations for the Athens 2004 Olympic Games. Many tens of stakeholders from a wide spectrum of professional expertise participated in the definition of business support systems for 21 competition venues over a period of 2 years. This project had the almost distinct characteristic of trying out three types of technique: group facilitation, qualitative modelling and the S3 approach. The paper offers insights on all three approaches, insights that reflect on the problem of early requirements in general and on the validation of the effectiveness of the S3 approach in particular.

Key-Words: -Strategic Requirements, Systems Analysis, Case study.

1Introduction

Many design situations involve multiple stakeholders from different participating organisations, subcontractors, divisions etc who may have a diversity of expertise, come from different organisational cultures and often have competing goals. Traditional Requirements Engineering (RE) techniques focus on support systems and consequently there is little attention on ways to facilitate communication between stakeholders.

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 non-functional properties of the intended system.

These issues of early requirements are specifically tackled by the strategy-service-support (referred to as S3) modelling approach [1]. It is based on the premise that informal (c.f. [2, 3], semi-formal (c.f. [4, 5] or formal approaches (c.f. [6, 7] to requirements specification do not fully address the issues relating to early requirements. The S3 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. In terms of the 6 classes of requirements elicitation techniques identified in [8] (i.e. traditional, group, prototyping, model-driven, cognitive and contextual), the contribution of S3 is in the model-driven and group classes. In S3 models are used to establish the structural aspects of a business process. These models are subsequently subjected to scenario generation in consensus-building stakeholder workshops.

The aim of this paper is to report on experiences from a large project, experiences that arguably support the claims made regarding the current state of the art on early requirements modelling and to validate the S3 approach. The paper is organised as follows. Section 2 gives an explanation of the problem domain. Section 3 introduces the S3 approach and gives synoptic examples of its use from the problem domain. Section 4 focuses on a discussion on the use of different approaches to early requirements elicitation as experienced by the author in the reported project. Section 5 concludes the paper.

2The Problem Domain

All the issues with early requirements, outlined in section 1, were present in a project regarding the design of systems supporting venue operations for the Athens 2004 Olympic Games. The action research on which this paper is based was carried out at the Organising Committee for the Athens 2004 Olympic Games (ATHOC). The project underwent 3 phases during a period of 2 years and involved 175 person months of effort. Initially, elicitation of early requirements was attempted using informal stakeholder facilitation. This was followed by the use of a traditional business process modelling approach which in turn gave way to the S3 approach that eventually became the main vehicle for eliciting early requirements for 21 applications.

In preparing towards the staging of the Games, ATHOC planed, coordinated and designed for systems most of which were delivered by external contractors. The problem domain is one of process integration the characteristics of which may be summarised as follows:

• There are many different co-operating agents (systems, ATHOC functional areas, sub-contractors, personnel and procedures). For example, the distribution of results involves the co-ordination of systems concerned with timing, information structuring, information communication, reprographics, and physical distribution.
• Different stakeholders have distinct goals and expectations of systems. For example, transportation is solely concerned with safe and timely arrival and departure of spectators whereas catering is concerned with meeting demand during the operation of a venue.
• Although different stakeholders have their own distinct concerns, from a total venue perspective all these need to be considered holistically. For example, the demand on catering is influenced by the behaviour of spectators in terms of their arrival and departure, their attendance of sports events etc.

The effect of these characteristics is the transformation that every Games Organising Committee needs to undertake. An Organising Committee is established a few years prior to the staging of the Games. Functional areas such as transportation, security, logistics, marketing etc. are established approximately 5-6 years prior to the staging of the Games, in order to organise and develop the necessary human, information and physical resources for the Games. Whilst at the outset the structure of an Organising Committee is hierarchical and function-oriented, this needs to gradually get transformed, as the Games approach, to a venue-based processorientation in order to shift emphasis away from internal organisational efficiency towards venue operation efficiency.

The term ‘venue operations’ concerns the systems, actors and procedures that will be implemented in a venue (be it a competition venue or a support venue) within spatial and temporal constraints, for different types of service e.g. security control, crowd management, catering etc. The design of systems supporting venue operations needs to address both their functional requirements (the resources and procedures for their management) and their non-functional requirements (the quality of service provision).

A central issue is the interaction and coordination of domain experts from 27 different functional areas in order to design systems that interact properly and are fully co-ordinated. For example, transportation needs to be co-ordinated with crowd queuing control which in turn need to co-ordinate with security etc. Typically, the stakeholders involved are experts from the Organising Committee, technical suppliers and subcontractors.

The complexity of venue operations increases as the variability of demands increases according to different ‘customer’ demands. For example, coordinating the processes concerned with spectator services involves many stakeholders from the 27 functional areas of ATHOC and for large venues there are in excess of 100 factors that influence the behaviour of the system.

The problem is graphically illustrated inFigure 1. In a generalised abstract sense, the problem associated with venue operations can be expressed as follows: “Given the temporal and spatial distribution of demand generated by the needs of the various customer groups to participate in a variety of sessions (temporal dimension of demand), that take place at various venues (spatial dimension of demand) provide the necessary system infrastructure in order to achieve a desirable level of service”. During each Games’ day up to 14 different customer groups participate in different sessions, that take place at any of the 36 different venues. Functional areas, up to 27 of them, need to design the systems and provide for the resource that will satisfy some expected demand for each session at each venue during each day of the Games.

Figure 1: Abstract View of Problem Domain

Co-development of business processes and support systems for this problem led to a number of complex decision making activities during early requirements. The following are few examples of frequently faced, typical questions:

• What are the appropriate types and level of resources that will be needed by each functional area for each venue?
• What are the interrelationships and interdependencies of the various functional areas in providing the required services to the various customer groups?
• What is the trade-off between the desired service level and the resource allocation / requirements for each activity involved in a process?
• What is the optimal operational smoothing / resource levelling for the overall process pertaining to a given customer group?

Ultimately, ATHOC had to specify the physical infrastructure (e.g. building works, public transportation etc), support systems (e.g. security systems, reporting systems, catering systems, ATMs etc) and procedures (e.g. protocols for dissemination of results, crowd control etc) in such a way so as to satisfy both the individual requirements of each functional area and the systemic requirements that arise from the process-oriented view of venue operations. It was therefore, profoundly important to reach agreement between stakeholders from all 27 functional areas on the way that their interdependent requirements were to be dealt in the most transparent, quantifiable and effective way possible.

The process of specifying early requirements involved venue operations stakeholders, modellers and facilitators of workshop sessions. The distribution of effort is shown inFigure 2.

Figure 2: Effort in specifying early requirements

3The S3 Approach

3.1Overview

In terms of methodology the S3 approach supports a reasoning cycle of hypothesis formulation, testing, and re-formulation. Within this reasoning cycle, S3 deals with strategic, service and support issues.

1. Strategic issues are organisational and stakeholder goals for improving the organisation’s performance.
2. Service issues are the levels of improvement considered by the organisation.
3. Support issues are the resources policies and actions required to reach the desired service levels.

The S3 approach is motivated by four ‘principles: (a) Systems thinking considers independent components that form a unified whole [9, 10]; for example the business process spectator services involves arrival handling, security checking, crowd management, services etc and the behaviour of each component affects all others, potentially in a profound manner. (b) Abstract thinking implies that one moves away from the physical manifestation of processes [11]. (c) Operational thinking considers the dynamics of a business process and in particular its behaviour over time [12, 13]. (d) Solution-first thinking implies that in attempting to identify requirements one generates a provisional design whose purpose is to highlight potential functionality [14].

On the basis of these four fundamental principles, three types of model are developed: (a) domain ontologies [15] that scope the problem space and define the key business objects that participate in a business process; (b) stakeholder goals [16] that determine the high-level intentions of each class of stakeholder; (c) processes [17] that fall into the two subcategories of customer-oriented processes and support-oriented processes where the former provides the basis for defining the level of service and the latter the manner in which this will be met.

In terms of processes involved there are essentially two activities: (a) model building and critiquing[18, 19]and (b) simulation and group deliberation[20, 21]. Models are mainly built by analysts with input from domain experts but are critiqued and revised by stakeholders. Analysts also facilitate simulation sessions where model parameters are instantiated by stakeholders. Consensus building stakeholder workshops develop scenarios that facilitate deliberation of alternative future realizations.

3.2An Example from Using the S3Approach

A fully described example is beyond the scope of this paper. The purpose therefore, of this section is to highlight some of the approach’s salient points in order to make subsequent discussion of insights more transparent.

One of the 21 application areas examined in the venue operations project was that of the Uniform Distribution and Accreditation Centre (UAC). A ‘customer’ in this application was considered anyone that required to wear a uniform and to obtain selective accreditation in order to get access to a venue, typically sub-contractors and volunteers. ATHOC were interested in designing a business process with appropriate support systems that would deal with uniform distribution and accreditation in the months leading to the staging of the Olympic Games.

From a customer perspective there is a natural flow of customer being in different states from arrival at the UAC, security checking, fitting of uniform, collection of accreditation pass and so on. Given that 175,000 staff will need to participate in this process, ATHOC were interested in defining an optimum way of managing the process. This required the participation of all functional areas that had a stake in this business process in order to understand their requirements and importantly to understand the interrelationships between these requirements, these being Transportation, Security, Accreditation and Uniforms.

A fragment of the customer process model is shown in Figure 3. For readability reasons this figure omits much detail that is present in the full model. Five different functional areas are involved in this process and they participated in the model building activity.

Figure 3: A Simplified View of a Customer Process

Initial working tools of the stakeholders (architectural designs, spreadsheets etc.) were provided as input. The model gradually evolved by mapping the information that was already present in these documents, and by incorporating the knowledge which was implicit or formed during the modelling process. Group workshops were organised with participants from each one of the five functional areas in order to critique and revise the model. Using a common language it was possible to arrive, reasonably efficiently, to an agreed position regarding the structureof the business process. Stakeholders started to realise the interdependencies between different functional areas and the interface points between them.

This structural view of a business process was subsequently analysed into micro processes which essentially detailed all the possible and anticipated stages in volunteers’ behaviour. These micro processes ere interrelated and controlled by parameters that involve spatial, temporal, throughput, service levels etc, so that the dynamic behaviour of the model was determined through the structure of the system itself. This gives a quantifiable dimension to the modelling which yields an operational model.

An example is shown in Figure 4. The example focuses on the transition of volunteers from the Awaiting Uniform Distribution stage to the Uniform Received stage of the process. This transition clearly depends on the number of employees working for this particular activity and the average time it takes each employee to service a customer. These two parameters are attached to the transition, hence controlling the pace by which customers move from the first stage of the model to the second one.

Once the model was enhanced with quantitative information it was subjected to the formulation of various hypotheses concerning the parameters of the model, the combination of these hypotheses in one or more scenarios and simulation of the model so as to view the results of each scenario. By altering any of the parameters, it was possible to obtain alternative requirements.

Figure 4: Quantifying the Model

An example of a single system component demonstrating its behaviour over time is shown in Figure 5. Whilst this result pertains to the security part of the system at the same time all other parts are also highlighted since the entire system and the interdependencies between all of its components are considered as a whole. This has the effect that each stakeholder understands clearly the relationships between all system parts.

Figure 5: Process Node Behaviour over Time

4Reflections on Early Requirements Approaches at ATHOC

4.1Project Overview

The project of specifying early requirements at ATHOC underwent 3 phases of evolution:

Phase 1 – the traditional peer-to-peer knowledge transfer through structured stakeholder workshops. This was the typical approach towards the design of venue operations adopted in previous Olympiads. This approach was adopted early on in the project with the view to developing a ‘prototypical design’ for a chosen venue. The outcome was voluminous documentation expressed in a textual and tabular manner. This effort consumed substantial resources (2600 person/days) and this was just for one of the 36 venues. Participants in this phase were exclusively stakeholders and consultants from previous Olympiads who acted as facilitators in workshops.