requirements elaboration for system co-development

Requirements Elaboration for System Co-development

Joy Garfield1 and Pericles Loucopoulos2

1Manchester Business School, University of Manchester, Manchester, M13 9PL, United Kingdom

[email protected] 2The Business School, Loughborough University, Loughborough,

LE11 3TU, United Kingdom [email protected]

Abstract. System co-development provides a mechanism for aligning business processes and technical systems. Whether a business wishes to exploit advances in technology to achieve new strategic objectives or to organise work in innovative ways, the process of Requirements Engineering could and should present opportunities for modelling and evaluating the potential impact that technology can bring about to an enterprise through a process of co-development. Co-development offers opportunities to change both the business and its underlying technical systems, in a synergistic manner. This paper considers the case of adopting a designing stance during requirements analysis so that typical challenges which arise during co-development projects can be taken into consideration. These 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. Stakeholders are faced with many different alternative future ‘worlds’ each one demanding a possibly different development strategy. A conceptual framework for designing the enterprise strategy and system requirements during system co-development is put forward. The framework comprises of four main components, namely, System Dynamics modelling, ontology modelling, scenario modelling and rationale modelling. System Dynamics modelling is used as a central focus for designing, in which the behaviour of an enterprise system is defined. Invariant components of the physical and social world within the enterprise domain are formally defined within the ontology model. Scenario modelling is used to identify critical variables and by quantitatively analysing the effects of these variables through simulation to better understand the dynamic behaviour of the possible future structures. Rationale modelling is used to assist collaborative discussions when considering either ontology models or scenarios for change. A case study of electricity liberalization in the European Union is used to illustrate the workings of the framework.

Keywords: Requirements, designing, co-development, negotiation, enterprise strategy, modelling.

2 Joy Garfield and Pericles Loucopoulos

1. Introduction

There is an increasing realisation and consensus amongst information systems researchers and practitioners that the development of systems is not solely a technical activity, in which functional and non-functional requirements are considered [1-6]. Organisational factors also very often have a profound effect on both the delivered system and the design process. In particular it is important that systems development takes the rapidly changing business environment and economy into consideration. An economy which has become global, knowledge-based and networked in nature, with increased speed and complexity of decision-making, an acceleration of technological change, together with a rapid acceptance of computer and electronic communications [7]. More specifically Loucopoulos and Garfield (2009) [8] note that organisational challenges stem from the exponential growth in information processing [9] and enterprise transformation [10]. Indeed global competiveness has forced companies to find ways to do things better, faster and cheaper [11]. The growth in information processing and enterprise transformation accentuate the intertwining of enterprise and systems [8] in a process of co-development during early phased systems development. This process enables alignment between business processes and support technical systems [8], [12], and is seen as a mechanism for meeting the challenges that arise within 21st century business activities. A number of approaches have been put forward for co-development, e.g. [12], [13], [14] and [15]. However although these methods guide development there tends to be a lack of additional support to accommodate challenges that arise during co-development activities [8].

Co-development can be viewed as a designing process, in which both the enterprise and system requirements are designed. Designing involves devising courses of action aimed at changing existing situations into preferred ones [16]. Through design thinking transformative innovation can be realized. Design thinking enables the creation of ideas that better meet customers’ needs and desires rather than making an already developed idea more attractive [17].

Typically during designing, multiple stakeholders are involved with different experiences, backgrounds and goals for the system. It is therefore inevitable that stakeholders’ goals and aims are conflicting [18]. Furthermore stakeholders’ views of requirements tend to be vague as they are unsure of what they want, frequently changing their mind (e.g. [19, 20]). Stakeholder needs together with their grievances in terms of conflicts have a large bearing on the successful outcome of the requirements specification and end product and can cause high financial and time losses. Requirements also evolve “as one wrestles with the problem one’s requirements change” [21]. Designing therefore needs to be flexible and take into consideration differing viewpoints in order to meet the needs of stakeholders and ascertain the best possible outcome.

Although challenging it is essential that discrepancies are resolved through negotiations in order to determine stakeholder needs. Negotiation was defined by Easterbrook (1991) [22] as a collaborative approach to resolving conflict by exploring a range of possibilities. Negotiation involves two or more parties that are in a conflict of interest situation but are prepared to ‘talk’ because they feel that they can exercise some influence [23]. Negotiation starts when participants begin communicating their goals, and ends (successfully) when all agree to a specified contract [24]. It involves

Requirements Elaboration for System Co-development 3

information interchange, discussion and resolution of disagreements [25]. If, on the other hand, stakeholders do not negotiate, there is little chance the resulting system will accommodate their needs, and the project will often fail [26]. Furthermore the negotiation task must ensure that the ‘right’ decisions are made, i.e. that are based on known argumentations and the best alternative is always chosen [18]. However many negotiations are undertaken in dynamic settings, including organisational, hierarchical and functional differences and in both formal and informal settings [27]. If this is not taken into consideration this can lead to communication problems that can have a large impact on the quality of the elicited requirements [28].

It therefore seems prudent to adopt a ‘designing stance’ during the co-development of systems. The term ‘designing stance’ means that the designing process should involve reflection, exploration, negotiation, compromise and revision [8]. These are the activities in which top class designers tend to engage when considering complex projects in uncertain situations [29], helping them to work through the problem they are trying to solve [30]. This also emphasises the notion that communication amongst stakeholders is crucial to the entire design process [31]. In contrast poor facilitation of communication is a major barrier to the realisation of stakeholder’s ideas and opinions.

The motivational background for this paper is one in which a designing approach is taken to the co-development of systems, to enable the engagement of multiple stakeholders with differing experiences, backgrounds and goals. Understanding early on in the development process the impact of different requirements choices on the enterprise itself is much more likely to actively engage stakeholders, to highlight the strategic options open to them and thus, ultimately deliver useful and sustainable systems that are aligned to enterprise strategy and offer opportunities for influencing this strategy [8].

In adopting a designing stance to requirements, the following is a set of objectives espoused by the approach discussed in this paper:

• to encourage the use of multiple models as a way of inventing and proposing alternatives,

• to use different model perspectives to determine whether improvement in one area of the enterprise maybe achieved at the expense of another,

• to exploit invariant structures (e.g. standards, legislation etc) which can act as an anchor to alternative models,

• to engage stakeholders in developing scenarios of alternative futures under different conditions, and

• to submit the reasoning used in model building and in the development of scenarios to critiquing by stakeholders.

Through these objectives, we aim to provide a conceptual framework within which

stakeholders can consider the multitude of issues that can impact on different enterprise strategies when taking a designing stance to co-development. A set of well established techniques and support tools are utilized in the framework to enable it to be a practical proposition.


2. A Conceptual Framework for Designing Enterprise Strategy and Requirements

The conceptual framework presented in Fig. 1 is aimed at meeting the challenges and objectives presented in section 1.

Fig. 1 A conceptual framework [8]

Requirements definition involves the identification of (a) business objectives, (b)

strategic requirements, (c) functional requirements and (d) non-functional requirements. Strategic objectives direct the definition of strategic requirements, providing the overall business vision together with a fundamental basis for information system requirements. System functional and non-functional requirements are defined for each strategic requirement, in order to determine what needs to be provided for each business function. Following execution of the requirements


elaboration part of the framework, strategic requirements can inform strategic objectives. It is considered that there are many methods, techniques and tools that deal extensively with requirements definitions. This paper therefore focuses on requirements elaboration as a way of designing enterprise strategy and requirements.

The development of a model that describes the dynamics of the enterprise and its interaction to the proposed system is central to the elaboration process. This is shown in Fig. 1 as the System Dynamics model. The model is built by from strategic requirements and is informed by the ontology model. It is intended to describe the feedback between various system components. It is also intended to be constructed in such a way so as to be used for testing key system parameters under different conditions and observing the behaviour of the entire system under these conditions. This implies that the model needs to be constructed in such a way so as to permit multiple interpretations of it, in which case differing system functional and non-functional requirements would be relevant. System Dynamics [32-34] is used as the underlying theoretical baseline in order to meet these requirements.

The modelling of behaviour in the System Dynamics model can greatly assist in understanding how the system changes over time together with ascertaining the location and reasons of potential system problems. This means that areas for improvement can be identified, new ideas tested and most importantly an understanding of how a system works without taking any significant risks can be gained. The use of a dynamic agent for design and the ability to handle change is supported by Gero (2007) [35], as a means for coping with the exploration of complexity that characterizes design. Moreover Boland (2004) [36] states that by “using models of a design problem and the working ideas for its solution can bring out different aspects of the design problem, different difficulties to be overcome, and a different sense of what a good solution might be – all of which constitute to a high quality solution”. The System Dynamics approach is also pertinent to the engagement of multiple stakeholders due to its iterative nature and the enablement of the consideration of problems and causes within the system context. More specifically it assists in reducing biases, uncertainties and conflicts amongst stakeholders together with forming a foundation for the development of scenarios.

The approach encourages the development of four model viewpoints namely, customer, financial, business processes and learning and growth, as suggested by the Balanced Scorecard [37]. This reflects the fact that any business strategy is likely to be influenced by different perspectives. The Balanced Scorecard provides a framework for translating an organisation’s vision and mission into performance indicators. Financial measures of past performance are complemented with measures of the drivers of future performance, through the inclusion of customer, internal business processes and learning and growth perspectives. The Balanced Scorecard therefore enables senior managers to visualize whether improvement in one area may be achieved at the expense of another. The use of System Dynamics, which focuses exclusively on feedback structures, provides an excellent vehicle for evaluating such interrelations.

System Dynamics modelling is complimented by a quantitative dimension, which enables stakeholders to subject the model to simulation. Simulation imposes rigorous testing that removes ambiguity, exposes alternatives to stakeholders and effectively removes any affectation towards the models driven by personal biases or political


factors. Experience has shown that stakeholders experience difficulties in comprehending qualitative models and even more significantly, have difficulties in extrapolating from the model to the potential behaviour of the system according to different design options available to them [38]. The absence of parameters, inputs, initial conditions and generally of factors that are needed for testing qualitative models, greatly diminishes their value as tools for understanding phenomena of the world. Furthermore the observation, walking through, and debating of model contents does not enable the comprehension of the implications of models. Nor is it always feasible to test them through observations from experimentation in the real world. In comparison the rigorous testing offered by simulation has proved to be of indispensable value [39-41]. However testing qualitative models through simulation has been approached with some caution by some authors (c.f. [42]). Furthermore, Lang shows that qualitative and quantitative properties are not mutually exclusive and both facets are required to support business scenario analysis [43].

The ontology model is incorporated into the conceptual framework to assist the development of a System Dynamics model. In particular an ontology is considered an appropriate way of representing and structuring knowledge due to its knowledge management capabilities and encouragement of the standardisation of terms used to represent knowledge about the domain [44]. It provides a strategic context for requirements; structures a complex application domain and clarifies semantics and standards. It can also be particularly informative to stakeholders, as their knowledge is not uniform and different meanings can be attached to the same concept. Overall the ontology assists in supporting decision-making and the articulation and negotiation of concepts in the System Dynamics model. It also increases the possibility that the relevant knowledge will be used when modelling. It is difficult to carry out meaningful designing activities during model development if the domain is unclear. If knowledge is not formally structured to inform decisions during RE, it is easy to overlook important details and leave modelling more prone to conflicts, misunderstandings and incompleteness.

The ontology model is structured according to the four perspectives of the Balanced Scorecard. It consists of concepts in the form of superclass-subclass hierarchies of invariant components related to the domain. Classes are comprised of object and/or data type properties and individuals otherwise known as instances. Assertions (e.g. restrictions/constraints) and rules assist in determining relationships between concepts. The System Dynamics model is informed by the ontology model and through its relationship to strategic requirements, it can provide feedback on concepts such as legislative, financial, resource etc that would be of value to the analysis of these requirements and by extension to business objectives.

The scenarios model is used to enable stakeholders to visualize and reflect on the effects of different possible futures on the business and societal environment and also determine which requirement option would be the most strategically viable. A good design solution is one that is more satisfying in more ways than any feasible alternative [36]. The System Dynamics model is used as the structure upon which alternative scenarios can be generated. Scenarios enable ‘what if’ questions to be asked in terms of business needs and its aspirations with regards to strategic objectives. The number of scenarios that can be proposed is not restricted, as designing is about creating multiple options. Indeed lots of ideas need to be generated


in which bad, dumb and/or wild ideas can be suggested [36]. Critical variables are defined and behaviour tested according to different values of these variables. Scenarios support and enhance the solution-first strategy in which a provisional design solution is used as a method for identifying requirements. The term ‘solution-first strategy’ has been defined as “…a strategy that involves generating a provisional design solution as a method of identifying requirements” [45]. The simulation of scenarios is invaluable in experimenting with alternative solutions and encouraging co-operative design in multiple workshops sessions [46].

Although scenarios serve as a means for discussing alternative solutions, grounding discussions and negotiations on real examples, and supporting trade-offs among design alternatives [47], a record of reasoning and decisions regarding scenarios is often not present. This results in a lack of traceability. The lack of tools for tracing scenarios can be a hindrance to the process of evaluating alternative futures by stakeholders when they are faced with a large number of scenarios to analyse and evaluate [47]. The negotiation task must ensure that the ‘right’ decisions are made, i.e. that are based on known argumentations and the best alternative is always chosen [18]. In order to ameliorate this situation, the conceptual framework uses rationale modelling. Rationale provides a way of documenting decisions together with underlying arguments, promoting critical reflection, negotiation and location of inconsistencies. It is used to assist collaborative discussions when considering either ontology models or scenarios for change.

Scenario rationale guides scenario simulation and provides a rationale for scenario decisions. Prior to simulation a set of alternative scenarios, on the way that the delivery of the requirements may take place, are derived from the System Dynamics model, and documented in the scenario rationale. Following simulation results for acceptance or rejection are documented for each scenario in the scenario rationale. Coupled to this, is the ontology rationale component, whose aim is to support negotiations by recording the modelling assumptions when structuring domain and application knowledge. As a number of stakeholders with differing roles, backgrounds and experiences are involved in constructing the scenarios model and ontology model, it seems pertinent that a rationale for construction is documented throughout these modelling processes. Overall rationale provides a means for multiple stakeholders to deliberate and negotiate.

The rationale adopted takes the form of collaborative visualised argumentation, based on the principles of Rittel and Webber [48]. This consists of the problems and issues that arise in the course of a design, along with pros and cons for each alternative [49]. Rationale is captured using Compendium [50]. The graphical nature of Compendium assists in facilitating communication amongst stakeholders and enables arguments to be made explicit. Furthermore the real-time aspects enable collaborative discussions to be captured and shared in distributed environments, which accommodates the dynamic settings in which negotiations frequently take place.


3. Case Study Example: Electricity Liberalisation

3.1 Overview

The case study example used to demonstrate the conceptual framework presented in section 2, focuses on electricity liberalisation in the European Union. The overall goal of electricity liberalisation was to enter the competition market whilst responding promptly and competently to customer needs and changing market conditions ([51] and [52]). The case study example centres on the Distribution Business Unit. Distribution is defined as the transport of electricity on medium-voltage and low-voltage distribution systems with a view to its delivery to customers (which include installations) [51].

Under liberalisation, there have been lower electricity prices, reduced costs and margins, improvement in labour productivity but also an increase in unemployment [53]. However, due to the current economic downturn and rising fuel costs, the cost of electricity continues to rise. For example a 40% rise in fuel costs was predicted for the UK before the end of 2008 [54]. Levinson and Odlyzko (2007) note that as fuel prices rise and there is intense public opposition to building more power plants and transmission systems as well as concerns about pollution, climate change and fuel depletion, attention is paid to methods that either reduce electricity consumption, or at least shift it away from periods of high loads [55].

In conjunction with this, several clauses in recent European Union Directives refer to requirements for the improvement of the Distribution Business Unit, putting pressure on action with reference to the metering of electricity. Article 5 of Directive 2005/89/EC [56] encourages the adoption of real-time demand management technologies such as advanced metering systems together with energy conservation measures. Article 13, Directive 2006/32/EC [57] states that customers including new customers and those needing replacement of existing meters, are to be provided with competitively priced meters that accurately reflect the customer’s actual energy consumption and that provide information on the actual time of use. However this is only to be carried out if it is technically possible, financially reasonable and proportionate to potential energy savings.

3.2 Business Strategic Objectives and Requirements

Five business strategic objectives have been identified (


Table 1) from Directive 2005/89/EC [56] and Directive 2006/32/EC [57].


Table 1 Business strategic objectives

Business Strategic

Objective No. Business Strategic Objective Description

SO1 To increase the number of customers SO2 To increase customer satisfaction SO3 To increase profits SO4 To decrease the time for business processes SO5 To decrease CO2 emissions

The predominant type of enterprise strategy is competitive advantage. Increasing

customer numbers can enable the generation of a higher level of revenue and subsequently profit. Customer satisfaction is dependent on the level of customer service. Increasing profits can enable not only sustainable capital but also funds for investments in innovation. Increasing the speed of business processes can enable the achievement of a higher level of productivity. Decreasing CO2 emissions realised through higher productivity rates would enable higher levels of environmental conservation.

Table 2 shows three high level strategic requirements [58] that indicate stakeholder needs regarding the process of metering in order to achieve efficiency within the Distribution Business Unit and successfully fulfil the business strategic objectives in


Table 1. Metering is important, as electricity consumption data is required to calculate customer bills.

Table 2 Strategic requirements

Strategic Requirement

No. Strategic Requirement Description

SR1 Improve metering procedures SR2 Minimise period to calculate customer charges SR3 Develop computerised mechanisms for energy metering

As a way of fulfilling strategic requirements SR1, SR2 and SR3, automation of electricity metering is considered in comparison to traditional electro-mechanical accumulation electricity meters. Traditional meter reading requires a meter reader to travel to each customer’s premises every three months in order to manually read the electricity meter, record the data output and submit the readings to the data processing department. This requires large numbers of staff to manually read electricity meters, with some premises being in difficult to access locations e.g. rural and agricultural. Traditional meter readings are also not easily accessible for consumers, as they are displayed in KWh, often shown as a cumulative total, with no facility for the consumer to access historical, or even instantaneous information [59]. Moreover, the maximum accurate reads in the UK can only be four per year even if meters were read accurately every quarter [59]. The current meter reading process is also prone to delay. Consequently customers are paying for electricity consumed many months previously. Furthermore traditional meter reading methods have resulted in increased maintenance costs due to outdated equipment. In conjunction with increased rises in electricity costs the likelihood that electricity meters will be tampered with increases enabling electricity theft and the production of further business losses.

The proposal to introduce new metering technologies would entail the introduction of automatic meter readings (AMR), the technology used for automatically collecting data from electricity metering devices and transferring it to a central database for analysis and billing. AMR technologies are available in various forms, such as handheld, mobile and fixed network technologies and are based on different platforms such as telephony (wired and wireless), radio frequency, powerline or advanced transmission. Benefits depend upon the underlying transportation and communication technology, while costs depend on the cost structure of the revenue collection technology and on the burden it imposes on users [55]. For the purposes of this case study example handheld and fixed network technologies operating on a radio frequency platform are focused on.

To realise handheld automation or fixed network automation a number of different system functional and non-functional requirements would need to be considered to support such automation. For example handheld automation would require a meter reader to use a receiver/transceiver to collect meter readings from an AMR capable meter every three months. In contrast fixed network metering devices would be able to be read remotely each month or on-demand.


It needs to be determined whether the introduction of new metering devices to fulfill strategic requirements SR1, SR2 and SR3 would be strategically advantageous with reference to the business and societal environment. In summary options to be considered for electricity metering are as follows:

1. Continue with the as_is situation, in which meters are read by traditional means.

2. Introduce handheld automation. 3. Introduce fixed network automation.

3.3 Electricity Metering: Ontology, Scenarios and Rationale

A part of the internal business process perspective ontology class hierarchy is shown in Fig. 2. The meter reading class forms a subclass of the internal business process perspective class. Traditional and automated meter reading classes form subclasses of the meter reading class.

Fig. 2 Ontology classes for meter reading process [8]

Class relations, object and data type properties and assertions were stated for each

class. An example of three data type property assertions for the traditional meter reading class are as follows:

� hasTravelTime has 0.6 � hasReadingTime has 4.0 � hasUploadReadingTime has 0.2 These figures represent a best practice of the time involved to travel, read and

upload a customer’s meter reading using traditional means, expressed in minutes.


These figures contrast to those for handheld automation data type property assertions which are as follows: � hasTravelTime has 0.3 � hasReadingTime has 0 � hasUploadReadingTime has 0.05

It is estimated that the travel time would be halved and the meter reading time,

zero, as meter readers would ‘walk-by’ customer’s premises using a handheld device to read the meter. The meter readings would be automatically uploaded rather than manually entered into the computer system. The figures for fixed network automation, provide a further contrast to traditionally read meters and also handheld automation:

� hasTravelTime has 0 � hasReadingTime has 0 � hasUploadReadingTime has 0.0001 Although the time for the fixed network automation metering process is less than

traditional automation and handheld automation it may not meet the most strategic objectives. Therefore feedback between different business perspectives needs consideration. Fig. 3 shows a screenshot of the ontology in Protégé for the traditional meter reading class. The data type property assertion values are shown in the centre of the figure and the ontology class structure on the left.

Fig. 3 Screenshot of Protégé ontology - traditional meter reading class [8]

The meter reading classes and properties from the ontology (Fig. 3) are used to

compile the System Dynamics model. A small part of which is shown in Fig. 4 for traditional meter reading.


Fig. 4 System Dynamics model for traditional meter reading [8]

Use of the ontology model enables the System Dynamics model to reflect greater

realism and best practice standards. The ontology also enables semantics to be transferred to the System Dynamics model (e.g. though classes, property names and descriptions) together with relationships. This assists in reducing concept misunderstandings.

Fig. 5 shows an illustration in Compendium of the ontology rationale for traditional meter reading. Each model component is reasoned about and documented in a similar way during model development.


Fig. 5 Compendium diagram of ontology rationale for traditional meter reading [8]

Traditional meter reading and traditional meter reader travel time are both

accepted as components. The inclusion of ‘indication of kilowatts’, was not included as it is not required for the calculation of meter reading time.

Installation of the infrastructure and meters for automation would take place during the first five years. The implementation of new technologies is reflected in the results over the preceding five years. It is assumed that the Distribution Business Unit has the following starting figures: 8 million customers, 1500 meter readers and 250 billing processing staff. The level of current customers together with those lost to competitors and disconnection is simulated in the customer perspective of the System Dynamics model. The learning and growth perspective keeps a record of staffing levels including members of staff that have been lost through redundancy. The CO2 emissions take vehicle and office energy emissions into consideration. For example vehicle emissions are calculated from the average meter reader mileage against the CO2 emissions per mile traveled. Investment costs for automation within the financial perspective submodel are as follows: handheld automation - €40 per meter and fixed network automation - €80 per meter [60]. These figures include: hardware, software, installation, integration with billing, training and vendor deployment support. Other costing figures include the following: salaries, redundancy payout, meter reader injury compensation, reconnection, disconnection, electricity and electricity theft, maintenance, vehicles, resources and payment method commission.

The degree to which metering automation is introduced would need to be determined. A complete change from traditional meter reading to automation may not be suitable to overall enterprise success. In conjunction with this the following five scenarios were simulated and the behaviour of the system over a 10-year period observed:

Scenario B1.1 – 100% traditionally read meters Scenario B1.2 – Introduce handheld automation at 50%


Scenario B1.3 – Introduce handheld automation at 100% Scenario B1.4 – Introduce fixed network automation at 50% Scenario B1.5 – Introduce fixed network automation at 100%

From the customer perspective installation of an AMR could cause initial disruptions and annoyances as access to premises for new meter installations would be required. This could reduce customer attraction and retention. Customer benefits would be realised later, with no access required to properties for meter readings and no need for customers to submit their own meter readings. Consumers would be able to monitor real-time energy consumption in cash terms rather than watts of electricity [61]. Many observers think that once the consumer can see the changes in their energy use instantaneously they are much more likely to act to reduce that consumption [59]. Improved electricity conservation would in turn produce cost savings for the consumer, benefit the natural environment but potentially losses in business revenue. Customer complaints and damage claims resulting from regular visits to customer sites could be reduced [62]. If linked to an automatic metering management network, the automatic meter can provide the quick reporting of tampered meters so that appropriate action can be taken to both investigate and correct the situation.

From a financial perspective benefits could be realised in the form of overall operational cost reductions. For example there would be an overall decrease in staff salaries particularly for fixed network AMR, but an increase in redundancy payouts. However, initial investments would be required for installation and setup. There would be a greater initial setup cost for fixed network AMR in comparison to handheld AMR. There have however been shifts within this paradigm. Electricity Today (2007) highlights that the Tantalus wireless system in the US, which uses public spectrum over a private network for transmission of meter data, provides the performance of two-way telemetry but with a significantly lower cost structure [62]. Increases in profits would reflect the rise in customers attracted by a more efficient service.

From an internal business process perspective, automation would be less prone to human error. However there would need to be a number of logistical considerations for the installation of the infrastructure. For example as automated meters can take readings as often as twice a minute, power companies could have to deal with large amounts of data from millions of customers [63]. IT systems would need to be updated to cope with the huge increases in data generated by the meters, and this information would have to be cross-referenced with existing systems and stored for up to three years to meet data regulations [61]. Automation would also enable the remote connection and disconnection of electricity. Billing complaint calls could be handled more quickly due to availability of more frequent meter readings following the installation of AMR [62]. Decreases in CO2 emissions would be experienced, reflecting the natural improvement in vehicle efficiency and decreased vehicle usage due to reduced staffing levels, resulting from increased speed of meter reading.

From a learning and growth perspective there would be an increase in specialised staff to install the automated infrastructure. Overall meter reader staffing levels would reduce. This would be particularly marked for fixed network automation, as electricity consumption is transferred automatically from the automated meter to a


central computer system, negating the need for meter readers. Handheld AMR would still require a meter reader to ‘walk-by’ customer’s premises, carrying a handheld computer to collect meter readings. Such staff may also need a small amount of training in the use of new handheld meter reading devices and new office systems. However handheld metering staff numbers would see a reduction as more readings could be taken as access to premises is not required. There would be fewer employee injuries, especially in areas with fenced yards, dogs and landscaping [62], reducing the amount paid in compensation. This would be more pronounced in the case of a fixed network AMR.

The results from scenarios B1.1 to B1.5 are documented in the scenario rationale in Fig. 6. Pro nodes (+) denote results that are an improvement on the as_is situation, whereas con nodes (-) depict results that do not improve the as_is situation.

Fig. 6 Scenario rationale for meter reading [8]

100% fixed network automation shows the largest increase in customer numbers

and decrease in billing hours and CO2 emissions. However 100% fixed network automation does not see the largest increase in profits, due to the large infrastructure investments needed. Instead the largest profit increases are seen for 100% handheld automation. Billing hours reduce significantly for handheld automation, reflecting the increased efficiency in using this type of metering. The scenario with the most pro nodes is accepted (scenario B1.3 – 100% handheld automation). This scenario fulfills the most strategic objectives. In summary strategic requirements SR1, SR2 and SR3 are viable in terms of the enterprise strategic objectives, through 100% handheld automation.


The conceptual framework provides a number of benefits during system co-development. Prior to modelling the ontology provides a strategic context for requirements and enables the structuring of a complex Universe of Discourse, clarifying semantics and standards of components relevant to the requirements. During System Dynamics modelling ontology modelling provides a knowledge base to inform modelling decisions, potentially reducing misunderstandings and conflicts. Ontology rationale facilities discussion about model components and keeps a record of reasoning regarding model construction, taking multiple stakeholders needs into consideration. Ontology modelling and ontology rationale working together provide knowledge and reasoning to support the modelling of requirements in the System Dynamics model. Following modelling, the scenarios model enables simulation of requirements alternatives allowing the testing of strategic viability. Scenario rationale enhances this by documenting decision-making regarding different alternatives.

4. Conclusion

Requirements Engineering is considered by many as the most critical of all development activities for socio-technical systems. The sensitive area of early requirements is only recently beginning to be addressed in a methodological sense. In early requirements, when there is a great deal of vagueness and uncertainty about system goals that are often set against a background of social, organizational and political turbulence, the need for a systematic and systemic way of dealing with all co-development aspects seems to be of paramount importance.

In particular considerable effort is required to bridge the semantic islands that are often formed between different communities of client stakeholders, designers, regulators, etc. Promotion of an effective communication process with users leads to the achievement of a more thorough understanding of the requirements, whereas conflict arising particularly from misunderstandings grow with poor communication [64]. Qualitative-based conceptual modelling approaches seem to be an improvement on purely linguistic-based approaches. However they fail to bridge the communication gap between client stakeholders and analysts. The issue of analyst-client relationship has been highlighted by many authors [65, 66]. Adopting a designing approach to co-development offers a mechanism for dealing with such issues. The conceptual framework presented in this paper provides a set of techniques for designing both the enterprise strategy and information system requirements.

References

1. COMPUTER, Special Issue on Requirements Engineering. IEEE Computer,

1985. 2. Davis, A., P. Hsia, and D. Kung, Status Report on Requirements

Engineering. IEEE Software, 1993(November): p. 75-79. 3. IEEE-Std.'830', Ieee Guide to Software Requirements Specifications. 1984,

The Institute of Electrical and Electronics Engineers, New York.


4. Loucopoulos, P. and V. Karakostas, System Requirements Engineering. 1st ed. International Series in Software Engineering, ed. D. Ince. 1995, London: McGraw Hill. 160.

5. TSE, Special Issue on Requirements Engineering. IEEE Transactions on Software Engineering, 1977.

6. Nuseibeh, B. and S. Easterbrook, Requirements Engineering : A Roadmap, in The Future of Software Engineering, A. Finkelstein, Editor. 2000, ACM Press.

7. Leibold, M., G. Probst, and M. Gibbert, Strategic Management in the Knowledge Economy. New Approaches and Business Applications. 2002, Erlangen, Germany: Publicis Corporate Publishing and Wiley-VCH-Verlag GmbH & Co KGaA.

8. Loucopoulos, P. and J. Garfield, The Intertwining of Enterprise Strategy and Requirements, in Design Requirements Engineering - a Ten Year Perspective, K. Lyytinen, et al., Editors. 2009, Springer-Verlag: Berlin.

9. Gantz, J.F., et al., The Diverse and Exploding Digital Universe. 2008, IDC. 10. Rouse, W.B., A Theory of Enterprise Transformation. Systems Engineering,

2005. 8(4): p. 279-295. 11. Jessup, L.M. and J.S. Valacich, Information Systems Today. 2006, Pearson

Education Inc.: New Jersey. 12. Loucopoulos, P., System Co-Development through Requirements

Specification, in Information Systems Development: Advances in Theory, Practice and Education, O. Vasilecas, et al., Editors. 2005, Springer US. p. 1-13.

13. Nuseibeh, B., Weaving Together Requirements and Architectures. IEEE Computer, 2001. 34(3): p. 115-117.

14. Pohl, K. and E. Sikora, The Co-Development of System Requirements and Functional Architecture, in Conceptual Modelling in Information Systems Engineering, J. Krogstie, A.L. Opdahl, and S. Brinkkemper, Editors. 2007b, Springer: Berlin Heidelberg. p. 229-246.

15. Bleistein, S.J., et al., Strategy-Oriented Alignment in Requirements Engineering: Linking Business Strategy to Requirements of E-Business Systems Using the Soare Approach. Journal of Research and Practice in Information Technology, 2004. 36(4): p. 259-276.

16. Simon, H.A., The Sciences of the Artificial. 1969, Cambridge, MA: MIT Press.

17. Brown, T., Design Thinking. Harvard Business Review, 2008. June 2008: p. 1-9.

18. Pohl, K., Process-Centred Requirements Engineering. Advanced Software Development. Series 5. 1996, Taunton, UK: Research Studies Press.

19. Ambler, S.W. Overcoming Requirements Modelling Challenges. Agile Modelling. 2006 [cited 02/08/06]; Available from: http://www.ambysoft.com/onlinewritings.html.

20. Pohl, K., The Three Dimensions of Requirements Engineering: A Framework and Its Applications. Information Systems, 1994. 19(3): p. 243-258.

21. Schon, D.A., The Reflective Practitioner: How Professionals Think in Action. 2nd ed. ed. 1983, New York: Basic Books.


22. Easterbrook, S., Handling Conflict between Domain Descriptions with Computer-Supported Negotiation. Knowledge Acquisition: An International Journal, 1991. 3(3): p. 255-289.

23. Lewicki, R.J., D.M. Saunders, and J.W. Minton, Negotiation. 3rd ed. 1999, Boston, MA: McGraw-Hill.

24. Robinson, W.N. and V. Volkov, Supporting the Negotiation Life Cycle. Communication of the ACM, 1998. 41(5): p. 95-102.

25. Kotonya, G. and I. Sommerville, Requirements Engineering. Processes and Techniques. 1998, Chichester: John Wiley and Sons, Inc.

26. Gruenbacher, P. and R.O. Briggs. Surfacing Tacit Knowledge in Requirements Negotiation: Experiences Using Easywinwin. in Proceedings of the 34th Hawaii international conference on system sciences. 2001. Maui, Hawaii.

27. Berglund, F. Towards a Theory of Requirements Negotiation. in Proceedings of the 3rd annual conference on systems engineering research. 2005. Stevens Institute of Technology, Hoboken, New Jersey.

28. Alexander, I., Stakeholders - Who Is Your System For? Computing and Control Engineering, 2003. 14(1): p. 22-26.

29. Gehry, F.O., Reflections on Designing and Architectural Practice, in Managing as Designing, R.J. Boland and F. Collopy, Editors. 2004, Stanford University Press: Stanford, California.

30. Brown, T., Strategy by Design. 2005, Fast Company.com. 31. Curtis, B., H. Krasner, and N. Iscoe. A Field Study of the Software Design

Process for Large Systems. Meta Models for Requirements Engineering. Nature Team. 1988 [cited; Available from: http://ksi.cp.sc.ucalgary.ca/KAW/KAW96/jarke/Jarke.html.

32. Forrester, J.W., Designing the Future. 1998, Universidad de Sevilla: Sevilla, Spain.

33. Sterman, J., Business Dynamics : Systems Thinking and Modeling for a Complex World. 2000, Boston: Irwin/McGraw-Hill. xxvi, 982.

34. Morecroft, J., Strategic Modelling and Business Dynamics. 2007, Chichester, UK: John Wiley & Sons Ltd.

35. Gero, J.S. and G.J. Smith. A Cognitive and Computational Basis for Designing. in International Conference on Engineering Design, ICED'07. 2007. Paris.

36. Boland, R.J. and F. Collopy, Managing as Designing, in Design Matters for Management, R.J. Boland and F. Collopy, Editors. 2004, Stanford Business Books: Stanford, USA. p. 3-18.

37. Kaplan, R.S. and D.P. Norton, The Balanced Scorecard - Measures That Drive Performance. Harvard Business Review, 1992. 70(1): p. 71-79.

38. Loucopoulos, P., K. Zografos, and N. Prekas. Requirements Elicitation for the Design of Venue Operations for the Athens 2004 Olympic Games. in Proceedings of the 11th IEEE International Conference on Requirements Engineering. 2003. Monterey Bay, California.

39. Homer, J.B., Why We Iterate: Scientific Modeling in Theory and Practice. System Dynamic Review, 1996. 12(1): p. 1-19.


40. Barlas, Y. and K. Kanar. Structure-Oriented Behavior Tests in Model Validation. in 18th International Conference of the System Dynamics Society. 2000. Bergen, Norway: System Dynamics Society.

41. Eddins, W.R., R.L. Crosslin, and D.E. Sutherland, Using Modelling and Simulation in the Analysis and Design of Information Systems, in Dynamic Modelling of Information Systems, H.G.a.K.M. vanHee, Editor. 1991, Elsevier: Amsterdam. p. 89-119.

42. Lane, D.C., With a Little Help from Our Friends: How System Dynamics and Soft or Can Learn from Each Other. System Dynamics Review, 1994. 10(2/3): p. 101-134.

43. Lang, K. Simulation of Qualitiative Models to Support Business Scenario Analysis. in 18th International Conference of the System Dynamics Society. 2000. Bergen, Norway: System Dynamics Society.

44. Chandrasekaran, B., J.R. Josephson, and V.R. Benjamins, What Are Ontologies, and Why Do We Need Them? IEEE Intelligent Systems, 1999. 14(1): p. 20-26.

45. Carroll, J.M. Scenarios and Design Cognition. in IEEE Joint International Conference on Requirements Engineering (RE'02). 2002. Essen, Germany: IEEE Computer Society.

46. Loucopoulos, P. and N. Prekas. A Framework for Requirements Engineering Using System Dynamics. in Proceedings of the 21st international conference of the System Dynamics Society. 2003. New York City.

47. Weidenhaupt, K., et al., Scenario Usage in System Development: A Report on Current Practice. IEEE Software, 1998. 15(2): p. 34-45.

48. Rittel, H.W.J. and M. Webber, Dilemmas in the General Theory of Planning. Policy Science, 1973. 4(2): p. 155-169.

49. Shipman, F.M. and R.J. McCall, Integrating Different Perspectives on Design Rationale: Supporting the Emergence of Design Rationale from Design Communication. Artificial Intelligence for Engineering Design Analysis and Manufacturing, 1997. 11(2): p. 141-154.

50. Compendium-Institute. Compendium Institute. 2008 [cited 01/08/08]; Available from: http://www.compendiuminstitute.org.

51. EU, Directive 96/92/Ec of the European Parliament and of the Council of 19 December 1996 Concerning Common Rules for the Internal Market in Electricity. Official Journal of the European Union, 30/01/1997. L027: p. 20-29.

52. EU, Directive 2003/54/Ec of the European Parliament and of the Council of 26 June 2003 Concerning Common Rules for the Internal Market in Electricity and Repealing Directive 96/92/Ec. Official Journal of the European Union, 15/07/2003. L176: p. P. 0037 – 0056.

53. Ernst-&-Young, Research Project for the Department of Trade and Industry On "The Case for Liberalisation". 2006: London.

54. Pagnamenta, R. and S. Kennedy, Consumers Face up to 40% Rise in Energy Bills as Gas Price Soars, in The Times. 2008: London.

55. Levinson, D. and A. Odlyzko. Too Expensive to Meter: The Influence of Transaction Costs in Transportation and Communication. in Royal Society discussion meeting on networks: modelling and control. 2007. London.


56. EU, Directive 2005/89/Ec of the European Parliament and of the Council of 18 January 2006 Concerning Measures to Safeguard Security of Electricity Supply and Infrastructure Investment. Official Journal of the European Union, 04/02/2006. L033: p. 22-27.

57. EU, Directive 2006/32/Ec of the European Parliament and of the Council of 5 April 2006 on Energy End-Use Efficiency and Energy Services and Repealing Council Directive 93/76/Eec. Official Journal of the European Union, 27/04/2006. L114: p. 64-85.

58. ELEKTRA-Consortium, Elektra Electrical Enterprise Knowledge for Transforming Applications, Demetra: System Design Specification for Ppc, in Project No. 22927, ESPRIT Programme 7.1 Technologies for business processes best practice pilots., E. Kavakli, et al., Editors. 1998.

59. Porter, H. Smart Metering - the Real Energy Benefits. in International energy efficiency in domestic appliances and lighting conference '06 (EEDAL'06). 2006. London.

60. Plexus-Research, Deciding On "Smart" Meters: The Technology Implications of Section 1252 of the Energy Policy Act of 2005., in Prepared for Edison Electric Institute, US. 2006.

61. Brown, J., Utilities Query Smart Meter Plan, in Computing. 2006b. 62. Electricity-Today, Evolving Technologies in AMR.. Electricity Today, 2007.

September 2007(7): p. 24-26. 63. Brown, J., Can Smart Meters Add Up?, in Computing. 2006a. 64. Beyer, H.R. and K. Holzblatt, Apprenticing with the Customer.

Communication of the ACM,, 1995. 38(5): p. 45-52. 65. Kennedy, S., Why Users Hate Your Attitude. Informatics, 1994(February): p.

29-32. 66. Bashein, B. and M.I. Markus, A Credibility Equation for It Specialists. Sloan

Management Review, 1997. 38(4): p. 35-44.

requirements elaboration for system co-development

Documents