Requirements Engineering for Sociotechnical Systems

i

��

��

��

��

José Luis MatéUniversidad Politécnica de Madrid (UPM), Spain

Andrés SilvaUniversidad Politécnica de Madrid (UPM), Spain

Hershey • London • Melbourne • Singapore

��

ii

Acquisition Editor: Mehdi Khosrow-PourSenior Managing Editor: Jan TraversManaging Editor: Amanda AppicelloDevelopment Editor: Michele RossiCopy Editor: Toni FitzgeraldTypesetter: Sara ReedCover Design: Lisa TosheffPrinted at: Yurchak Printing Inc.

Published in the United States of America byInformation Science Publishing (an imprint of Idea Group Inc.)701 E. Chocolate Avenue, Suite 200Hershey PA 17033Tel: 717-533-8845Fax: 717-533-8661E-mail: [email protected] site: http://www.idea-group.com

and in the United Kingdom byInformation Science Publishing (an imprint of Idea Group Inc.)3 Henrietta StreetCovent GardenLondon WC2E 8LUTel: 44 20 7240 0856Fax: 44 20 7379 3313Web site: http://www.eurospan.co.uk

Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may bereproduced in any form or by any means, electronic or mechanical, including photocopy-ing, without written permission from the publisher.

Library of Congress Cataloging-in-Publication Data

Requirements engineering for sociotechnical systems / Jose Luis Mate and Andres Silva,editors. p. cm. Includes bibliographical references and index. ISBN 1-59140-506-8 (h/c) -- ISBN 1-59140-507-6 (s/c) -- ISBN 1-59140-508-4 (ebook) 1. Software engineering. I. Mate, Jose Luis. II. Silva, Andres. QA76.758.R455 2004 005.1--dc22 2004022149

British Cataloguing in Publication DataA Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The viewsexpressed in this book are those of the authors, but not necessarily of the publisher.

iii

��

��

��

Foreword ....................................................................................................................... viiBashar Nuseibeh, The Open University

Preface ........................................................................................................................viiiJosé Luis Maté, Universidad Politécnica de Madrid (UPM), SpainAndrés Silva, Universidad Politécnica de Madrid (UPM), Spain

Section I: Basics

Chapter I. Requirements Engineering: Dealing with the Complexity ofSociotechnical Systems Development ............................................................................1

Päivi Parviainen, VTT Technical Research Centre of Finland, VTT Electronics, FinlandMaarit Tihinen, VTT Technical Research Centre of Finland, VTT Electronics, FinlandMarco Lormans, Delft University of Technology, The NetherlandsRini van Solingen, LogicaCMG Technical Software Engineering (RTSE1), The Netherlands

Chapter II. Challenges in Requirements Engineering for Embedded Systems ......... 21Eman Nasr, Cairo University, Egypt

Chapter III. Requirements Elicitation for Complex Systems: Theory and Practice . 37Chad Coulin, University of Technology Sydney, AustraliaDidar Zowghi, University of Technology Sydney, Australia

Chapter IV. Conceptual Modeling in Requirements Engineering: Weaknesses andAlternatives ................................................................................................................. 53

Javier Andrade Garda, University of A Coruña, SpainJuan Ares Casal, University of A Coruña, SpainRafael García Vázquez, University of A Coruña, SpainSantiago Rodríguez Yáñez, University of A Coruña, Spain

iv

Chapter V. Combining Requirements Engineering and Agents ............................... 68Ricardo Imbert, Universidad Politécnica de Madrid, SpainAngélica de Antonio, Universidad Politécnica de Madrid, Spain

Chapter VI. Maturing Requirements Engineering Process Maturity Models ......... 84Pete Sawyer, Lancaster University, UK

Chapter VII. Requirements Prioritisation for Incremental and IterativeDevelopment .............................................................................................................. 100

D. Greer, Queens University Belfast, UK

Chapter VIII. A Quality Model for Requirements Management Tools .................... 119Juan Pablo Carvallo, Universitat Politècnica de Catalunya (UPC), SpainXavier Franch, Universitat Politècnica de Catalunya (UPC), SpainCarme Quer, Universitat Politècnica de Catalunya (UPC), Spain

Section II: Challenges

Chapter IX. Composing Systems of Systems: Requirements for the Integration ofAutonomous Computer Systems ............................................................................... 139

Panayiotis Periorellis, University of Newcastle upon Tyne, UK

Chapter X. Requirements Engineering for Technical Products: IntegratingSpecification, Validation and Change Management ................................................. 153

Barbara Paech, University of Heidelberg, GermanyChristian Denger, Fraunhofer Institute for Experimental Software Engineering, GermanyDaniel Kerkow, Fraunhofer Institute for Experimental Software Engineering, GermanyAntje von Knethen, Fraunhofer Institute for Experimental Software Engineering, Germany

Chapter XI. Requirements Engineering for Courseware Development .................. 170Ines Grützner, Fraunhofer Institute for Experimental Software Engineering, GermanyBarbara Paech, University of Heidelberg, Germany

Chapter XII. Collaborative Requirements Definition Processes in Open SourceSoftware Development ............................................................................................... 189

Stefan Dietze, Fraunhofer Institute for Software and Systems Engineering (ISST), Germany

v

Chapter XIII. Requirements Engineering for Value Webs ..................................... 209Jaap Gordijn, Free University Amsterdam, The Netherlands

Chapter XIV. Requirements Engineering in Cooperative Systems ........................ 226J.L. Garrido, University of Granada, SpainM. Gea, University of Granada, SpainM.L. Rodríguez, University of Granada, Spain

Section III: Approaches

Chapter XV. RESCUE: An Integrated Method for Specifying Requirements forComplex Sociotechnical Systems ............................................................................. 245

Sara Jones, City University, UKNeil Maiden, City University, UK

Chapter XVI. Using Scenarios and Drama Improvisation for Identifying andAnalysing Requirements for Mobile Electronic Patient Records ............................ 266

Inger Dybdahl Sørby, Norwegian University of Science and Technology, NorwayLine Melby, Norwegian University of Science and Technology, NorwayGry Seland, Norwegian University of Science and Technology, Norway

Chapter XVII. Elicitation and Documentation of Non-Functional Requirements forSociotechnical Systems ............................................................................................ 284

Daniel Kerkow, Fraunhofer Institute for Experimental Software Engineering, GermanyJörg Dörr, Fraunhofer Institute for Experimental Software Engineering, GermanyBarbara Paech, University of Heidelberg, GermanyThomas Olsson, Fraunhofer Institute for Experimental Software Engineering, GermanyTom Koenig, Fraunhofer Institute for Experimental Software Engineering, Germany

Chapter XVIII. Capture of Software Requirements and Rationale throughCollaborative Software Development ......................................................................... 303

Raymond McCall, University of Colorado, USAIvan Mistrik, Fraunhofer Institut für Integrierte Publikations - und Informationssysteme, Germany

Chapter XIX. Problem Frames for Sociotechnical Systems ................................... 318Jon G. Hall, The Open University, UKLucia Rapanotti, The Open University, UK

vi

Chapter XX. Communication Analysis as Perspective and Method forRequirements Engineering ....................................................................................... 340

Stefan Cronholm, Linköping University, SwedenGöran Goldkuhl, Linköping University, Sweden

About the Editors ....................................................................................................... 359

About the Authors ..................................................................................................... 360

Index ........................................................................................................................ 370

vii

��

Requirements engineering (RE) lies at the heart of systems development, bridging thegap between stakeholder goals and constraints, and their realization in systems thatinevitably combine technology and human processes, embedded in a changing organi-zational or social context. RE is therefore multi-disciplinary in both its outlook and itsdeployment of techniques for elicitation, specification, analysis, and management ofrequirements.This is an important book because it recognizes the multi-disciplinary dimensions of REand because its contributions seek to strengthen the bridging role of RE. It is all tooeasy for technologists and engineers to ignore the social context in which their tech-nology will be deployed, and all too easy for humans and organizations to be unawareof the opportunities and difficulties that technology brings.The contributions in this book, written by a diverse group of researchers and scholars,have been thoughtfully organized and edited to appeal to different audiences: thestudent learning about the area, the researcher seeking challenges to investigate, andthe practitioner looking for practical techniques to apply. A single book cannot beeverything to everybody, but this edited volume is a tremendously valuable introduc-tion to the many facets of requirements engineering for sociotechnical systems.

Bashar NuseibehThe Open University, May 2004

viii

The Concept of Sociotechnical Systems:History and Definition

The term “Sociotechnical System” comes from the field of organizational development.The goal of this field is to improve the performance and effectiveness of human organi-zations. The term was introduced by Emery and Trist (1960), organizational develop-ment researchers at the Tavistock Institute of Human Relations in London(www.tavinstitute.org). By coining the term “sociotechnical system” they were chal-lenging the conventional position at the time, which was based on technological deter-minism. Technology determinism postulated that:

• Technology is autonomous.• The individual and social conditions of human work must follow the technical

structures (Ropohl, 1999).• Training is a process that adapts humans to machines, so humans can be quickly

replaced (if need be).

The organization of labor known as Taylorism can be seen as a natural consequence oftechnological determinism, and Henry Ford’s synchronized mass production methodsare its most prominent example. This is the way of thinking that Charlie Chaplin’s filmModern Times and many similar dystopias narrated in 20th century literature criticize. Bycontrast, Emery and Trist thought that there is, or there should be, an interdependentand reciprocal relationship between humans and technology. Hence, from the point ofview of work design, both the social and the technological aspects of work need to bein harmony to increase effectiveness and “humanize” the workplace. This would beachieved mainly by user participation in the design of the systems and devices thatusers are to operate at the workplace.From this discussion, it can be seen that the term “sociotechnical” comes from theanalysis of labor relations in the industrial era. This new view of the interdependencyof the technical and the social also emerged in high-tech industries. For instance, afteran in-depth analysis of the development process of a defense-related aircraft, Law and

��

ix

Callon (1988) found that engineers “are not just people who sit in drawing offices anddesign machines;” they are also “social activists who design societies or social institu-tions to fit those machines.”The introduction of computers at the workplace soon led to new views and extensionsof this work. Research into labor relations and work design became more and moreconcerned with the use of computing systems (Scacchi, 2004). An outstanding contri-bution came from the so-called “Scandinavian School.” This school advocates that, atdesign time, apart from user participation, there is also a need to address the politics oflabor and democratize the workplace (Scacchi, 2004). This position had a heavy bearingon software and systems engineering, so much so that Friedman and Kahn (1994) lateraffirmed, in a purely computing context such as the “Communications of the ACM”,that “computer technologies are a medium for intensely social activity” and “systemdesign –though technical as an enterprise — involves social activity and shapes thesocial infrastructure of the larger society.”It is also important to note that, at the same time, the field of computer ethics wasdeveloping in response to the risks inherent to computing systems, and the ACM“Code of Ethics” was published in 1992. The term “sociotechnical” is widely embracedby people interested in computer ethics, and it is from this field that we have borrowed,slightly modified, what we believe to be the most complete definition: A sociotechnicalsystem is a complex inter-relationship of people and technology, including hardware,software, data, physical surroundings, people, procedures, laws and regulations(www.computingcases.com, 2004).Soon the software engineering community realized that systems are dynamic, as theorganizational and social context in which they are embedded is also dynamic (Truex,1999). Projects became more and more socially self-conscious, or, in other words, moreaware that their objectives are to alter both the technical and the social (Blum, 1996).Accordingly the term “sociotechnical” started to be adopted in software engineeringand systems engineering. Two main points can be made as to the use of the term: (i) theterm normally applies to the product, not the process, because the process is tacitlyrecognized as sociotechnical by the software engineering community; (ii) the term isnormally used in an attempt to emphasize the socially self-conscious feature, as de-fined above, and underline opposition to technological determinism.

Sociotechnical Systems andRequirements Engineering

In no other field is the need to attach just as much importance to the system as to thepeople so clear as in software and systems engineering. This is because, due to itsinherent flexibility (at least theoretically), software can be configured by the designer/developers to fit any particular situation and to achieve almost any purpose. In prac-tice, however, this flexibility comes at a price, because the number of different software+ hardware + people configurations is so high that it is extremely difficult to find outexactly which is the best one at a particular point in time to satisfy the stakeholders’

x

goals. This has been less of a problem in “traditional” engineering, like mechanical orcivil engineering, at least until now. But nowadays, in the so-called Information Soci-ety, traditional engineering is not free from this problem. Software is now an essentialpart of products and services offered by industries traditionally unrelated to software,like the automotive industry, photography, telephony, medicine, and so forth (for in-stance, as Paech, Denger, Kerkow, and von Knethen say in this book, a modern carcontains more executable code than the first Apollo that flew to the moon). At the sametime, software is an essential instrument for the designers of these new products andservices.But a software system is of no help unless it is built according to its requirements.Requirements engineering (RE) provides the methods, tools, and techniques to buildthe roadmaps that designers and developers of complex software/people systems shouldfollow, as it is the discipline concerned with the real-world goals for, functions of, andconstraints on those systems (Zave, 1997). It is the discipline that most helps to achievesuccess in system development and, in particular, in sociotechnical system develop-ment.The RE discipline plays an important role in raising the socially self-conscious factorsrelated to complex system development. Additionally, success in RE essentially de-pends on it being founded on a sociotechnical position. The goal of this book, writtenby practitioners and researchers, is to promote the sociotechnical aspects that perme-ate RE. The book adds to existing literature revealing that the RE field (both in researchand in practice) is immensely mature as regards accepting and dealing with themultidisciplinary issues required to properly build sociotechnical systems, even thoughthere is still a lot of ground to be covered.In this book, we present 20 contributions from different authors, divided into threesections: (I) Basics, (II) Challenges, and (III) Approaches.

Section I: Basics

Section I presents eight chapters that introduce important topics in the RE area, alwaysfrom a sociotechnical perspective. These chapters are, however, not confined to a meredescription of the topics. Instead the authors criticize some of the existing approachesand move into new territory.In Chapter I Parviainen, Tihinen, Lormans, and van Solingen introduce RE forsociotechnical systems. The authors describe the terminology and the process in de-tail. Nasr, in Chapter II, introduces the topic of RE for embedded systems, in whichsoftware is just a part of a complex system. An important topic closely related to thesociotechnical side of RE is that of elicitation. In Chapter III Coulin and Zowghi reviewthe topic and propose some future directions. The problems related to, and the alterna-tives to, conceptual modelling in RE are the topic of Chapter IV by Andrade Garda, AresCasal, García Vázquez, and Rodríguez Yáñez. In Chapter V de Antonio and Imbert clarifythe use of the term “agent” in RE and in agent-oriented software, and conclude that thedifferent uses of “agent” are not unrelated as they may appear. Sawyer, in Chapter VI,reviews the topic of software process improvement from a sociotechnical perspective

xi

and considers lessons learned from industrial pilot studies. Chapter VII, by Greer, dis-cusses the topic of requirements prioritization for incremental and iterative projectsand proposes a method for optimally assigning requirements to product releases. Thetopic of requirements management tools is considered by Carvallo, Franch, and Quer inChapter VIII, in which a method is presented for building quality models for require-ments management tools.


The six chapters included in Section II introduce some important and difficult topicsthat requirements engineers and system developers have to deal with to build genuinesociotechnical systems.In Chapter IX Periorellis explains the problems and opportunities related to the compo-sition of existing systems in order to build new systems, even transcending organiza-tional boundaries. The complexity of modern technical products that incorporate soft-ware is the subject of Chapter X, with a focus on the automotive industry. In thischapter Paech, Denger, Kerkow, and von Knethen present the QUASAR process thatfaces some of the challenges posed by those systems. Grützner and Paech, in ChapterXI, introduce the challenges and possible solutions for courseware development, clearlya kind of system with a strong sociotechnical component. The Open Source softwaredevelopment offers a new playground for RE, based on a collaborative, feedback-basedprocess. Chapter XII, by Dietze, presents some insight into this process. Themultidisciplinary task of creating value webs, and a methodology for their develop-ment, is the topic of Chapter XIII by Gordijn. Technology is opening many possibilitiesfor workgroups. In Chapter XIV Garrido, Gea, and Rodríguez review the topic of RE forcooperative systems and propose a methodology based on behavior and task models.


Finally, Section III proposes some methods and techniques that can help practitionersto solve the complex problems involved in sociotechnical system development.In Chapter XV Jones and Maiden present RESCUE, a method for requirements specifi-cation that has been applied to complex Sociotechnical Systems like air traffic control.Hospital information systems have a clear sociotechnical nature. Chapter XVI, by Sørby,Melby, and Seland, proposes observational studies and drama improvisation as a meansto identify and analyze requirements for those systems. An approach to elicit the some-times subjective and elusive non-functional requirements is described in Chapter XVII,by Kerkow, Dörr, Paech, Olsson, and Koenig. McCall and Mistrik, in Chapter XVIII,propose to use a lightweight natural language processing approach for discoveringrequirements from transcripts of participatory design sessions. In Chapter XIX Halland Rapanotti bring one of the most innovative topics in RE, namely, problem frames,closer to the topic of sociotechnical systems. Finally, in Chapter XX, Cronholm and

xii

Goldkuhl present a method based on the perception that the main purpose of informa-tion systems is to support communications between different actors.

References

Blum, B. (1996). Beyond programming: To a new era of design. Oxford UniversityPress.

Computing Cases (2004). Site devoted to computer ethics. Retrieved fromwww.computingcases.org.

Emery, F. E., & Trist, E. L. (1960). Sociotechnical systems. In C. W. Churchman & M.Verhulst (Eds.), Management sciences: Models and techniques (Vol. 2, pp. 83-97).Pergamon Press.

Friedman, B., & Kahn, P. H. (1994). Educating computer scientists: linking the socialand the technical. Communications of the ACM, 37(1), 64-70.

Law, J., & Callon, M. (1988). Engineering and sociology in a military aircraft project: Anetwork of analysis of technological change. Social Problems, 35, 284-297.

Ropohl, G. (1999). Philosophy of sociotechnical systems. Society for Philosophy andTechnology Vol. 4, No 3. Retrieved http://scholar.lib.vt.edu/ejournals/SPT/v4n3/.

Scacchi, W. (2004). Sociotechnical design. In W. S. Bainbridge (Ed.), The Encyclopediaof Human-Computer Interaction. Berkshire Publishing Group.

Truex, D. P., Baskerville, R., & Klein, H. (1999). Growing systems in emergent organiza-tions. Communications of the ACM, 42(8), 117-123.

Zave, P. (1997). Classification of research efforts in requirements engineering. ACMComputing Surveys, XXIX(4), 315-321.

xiii

��

The editors would like to acknowledge the help of all our colleagues and friendsat the Universidad Politécnica de Madrid. In particular we are very grateful toJuan Pazos and Salomé García for their help. Thanks to Rachel Elliot for herhelp with the technical translation.

Thanks for their interest in the book to all the authors, who also acted asreferees, providing constructive reviews to other chapters. Their effort led to atrue collaborative work.

Finally, we would like to thank our family and friends. We are also very gratefulto Luis Muñoz and Leopoldo Cuadra for their support during the process.

J.L. Maté and A. Silva

xiv

Section I: Basics

Requirements Engineering: Sociotechnical Systems Development 1

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Chapter I

RequirementsEngineering:

Dealing with theComplexity of

Sociotechnical SystemsDevelopment

Päivi Parviainen,VTT Technical Research Centre of Finland, VTT Electronics, Finland

Maarit Tihinen,VTT Technical Research Centre of Finland, VTT Electronics, Finland

Marco Lormans, Delft University of Technology, The Netherlands

Rini van Solingen,LogicaCMG Technical Software Engineering (RTSE1), The Netherlands

Abstract

This chapter introduces requirements engineering for sociotechnical systems.Requirements engineering for sociotechnical systems is a complex process that considersproduct demands from a vast number of viewpoints, roles, responsibilities, andobjectives. This chapter explains the requirements engineering terminology anddescribes the requirements engineering process in detail, with examples of availablemethods for the main process activities. The main activities described include systemrequirements development, requirements allocation and flow-down, software

2 Parviainen, Tihinen, Lormans and van Solingen


requirements development, and continuous activities, including requirementsdocumentation, requirements validation and verification, and requirementsmanagement. As requirements engineering is the process with the largest impact on theend product, it is recommended to invest more effort in both industrial application aswell as research to increase understanding and deployment of the concepts presentedin this chapter.

Introduction1

The concept of sociotechnical systems was established to stress the reciprocal interre-lationship between humans and machines and to foster the program of shaping boththeoretical and social conditions of work (Ropohl, 1999). A sociotechnical system canbe regarded as a theoretical construct for describing and explaining technology gener-ally. This chapter helps to describe a multidisciplinary role of requirements engineeringas well as the concept of workflow and patterns for social interaction within thesociotechnical systems research area.Requirements engineering is generally accepted as the most critical and complex processwithin the development of sociotechnical systems (Juristo, Moreno, & Silva, 2002; Komi-Sirviö & Tihinen, 2003; Siddiqi, 1996). The main reason is that the requirementsengineering process has the most dominant impact on the capabilities of the resultingproduct. Furthermore requirements engineering is the process in which the most diverseset of product demands from the most diverse set of stakeholders is being considered.These two reasons make requirements engineering complex as well as critical.This chapter first introduces background information related to requirements engineer-ing, including the terminology used and the requirements engineering process in general.Next a detailed description of the requirements engineering process, including the mainphases and activities within these phases, is presented. Each phase will be discussed indetail, with examples of useful methods and techniques.

Background

A requirement is a condition or capability that must be met or possessed by a system orsystem component to satisfy a contract, standard, specification, or other formallyimposed documents (IEEE Std 610.12, 1990). A well-formed requirement is a statement ofsystem functionality (a capability) that must be met or possessed by a system to satisfya customer’s need or to achieve a customer’s objective, and that is qualified bymeasurable conditions and bounded by constraints (IEEE Std 1233, 1998).



Requirements are commonly classified as (IEEE Std 830, 1998):

• Functional: A requirement that specifies an action that a system must be able toperform, without considering physical constraints; a requirement that specifiesinput/output behavior of a system.

• Non-functional: A requirement that specifies system properties, such as environ-mental and implementation constraints, performance, platform dependencies,maintainability, extensibility, and reliability. Non-functional requirements areoften classified into the following categories:

• Performance requirements: A requirement that specifies performance character-istics that a system or system component must possess, for example, max. CPU-usage, max. memory footprint.

• External interface requirements: A requirement that specifies hardware, software,or database elements with which a system or system component must interface orthat sets forth constraints on formats, timing, or other factors caused by such aninterface.

• Design constraints: A requirement that affects or constrains the design of a systemor system component, for example, language requirements, physical hardwarerequirements, software development standards, and software quality assurancestandards.

• Quality attributes: A requirement that specifies the degree to which a systempossesses attributes that affect quality, for example, correctness, reliability,maintainability, portability.

Requirements engineering contains a set of activities for discovering, analyzing, docu-menting, validating, and maintaining a set of requirements for a system (Sommerville &Sawyer, 1997). Requirements engineering is divided into two main groups of activities,requirements development and requirements management. Requirement developmentincludes activities related to discovering, analyzing, documenting, and validatingrequirements, where as requirement management includes activities related to mainte-nance, namely identification, traceability, and change management of requirements.Requirements validation consists of activities that try to confirm that the behaviour ofa developed system meets its user needs. Requirements verification consists of thoseactivities that try to confirm that the product of a system development process meets itstechnical specifications (Stevens, Brook, Jackson, & Arnold, 1998). Verification andvalidation include:

• Defining the verification and validation requirements, that is, principles on how thesystem will be tested.

• Planning the verification and validation.• Capturing the verification and validation criteria (during requirements definition).



• Planning of test methods and tools.• Planning and conducting reviews.• Implementing and performing the tests and managing the results.• Maintaining traceability.• Auditing.

In sociotechnical systems software is understood as a part of the final product. Systemrequirements are captured to identify the functioning of the system, from which softwarerequirements are derived. Deciding which functionality is implemented where, and bywhich means (software, hardware, mechanics, and so forth) is merely a technical decisionprocess in which feasibility, dependability, and economics play a role. A well-structuredand technically sound requirements engineering process is, therefore, of utmost impor-tance.

Requirements Engineering Process

Figure 1 describes a requirements engineering process where the main processes ofsystem and software requirements engineering are depicted. Requirements engineeringactivities cover the entire system and software development lifecycle. On the other handthe requirements engineering process is iterative and will go into more detail in eachiteration. In addition the figure indicates how requirements management (RM) is under-stood as a part of the requirements engineering process. The process is based onKotonya and Sommerville (1998), Sailor (1990), Thayer and Royce (1990).The process describes requirements engineering for sociotechnical systems, wheresoftware requirements engineering is a part of the process. Traditionally requirementsengineering is performed in the beginning of the system development lifecycle (Royce,1970). However, in large and complex systems development, developing an accurate setof requirements that would remain stable throughout the months or years of developmenthas been realized to be impossible in practice (Dorfman, 1990). Therefore requirementsengineering is an incremental and iterative process, performed in parallel with othersystem development activities such as design.The main high-level activities included in the requirements engineering process are:

1) System requirements development, including requirements gathering/elicitationfrom various sources (Figure 1 shows the different sources for requirements),requirements analysis, negotiation, priorisation and agreement of raw require-ments, and system requirements documentation and validation.

2) Requirements allocation and flow-down, including allocating the captured re-quirements to system components and defining, documenting, and validatingdetailed system requirements.



RequirementsManagement

RM Planning

Traceability

Allocation

Detailed System Requirements

Traceability

Identification

Changecontrol

Requirementsdocumentation

Validation andverification

Flow-down

System requirementsspecification

IEEE Std 1233-1998

Software requirementsspecification

IEEE Std 830-1998

Validation:- user requirements

- customer requirements

Verification:- implementation (code)

-architecture-design

Traceability

Constraints

Business requirements Customer requirements

User requirements

Other SW development phases

Standards

HW Req.

Software Req.

HW Req.

Software Req.

HW Req.

Software Req.

Mechanics

HW Req.

Software Req.

In house inventions

High-level analysis

Detailed analysis

GatheringSystemRequirementsdevelopment Traceability

Traceability

3) Software requirements development, including analyzing, modeling and validat-ing both the functional and quality aspects of a software system, and defining,documenting, and validating the contents of software subsystems.

4) Continuous activities, including requirements documentation, requirements vali-dation and verification, and requirements management.

Each of these high-level activities will be further detailed in the following sections.

System Requirements Development

The main purpose of the system requirements development phase is to examine andgather desired objectives for the system from different viewpoints (for example, cus-tomer, users, system’s operating environment, trade, and marketing). These objectivesare identified as a set of functional and non-functional requirements of the system. Figure2 shows the context for developing system requirements specification (SyRS).

1. Requirements Gathering/Elicitation from Various Sources

Requirements gathering starts with identifying the stakeholders of the system andcollecting (that is, eliciting) raw requirements. Raw requirements are requirements that

Figure 1. System and software requirements engineering (Parviainen, Hulkko,Kääriäinen, Takalo, & Tihinen, 2003)



have not been analyzed and have not yet been written down in a well-formed requirementnotation. Business requirements, customer requirements, user requirements, constraints,in-house ideas and standards are the different viewpoints to cover. Typically specifyingsystem requirements starts with observing and interviewing people (Ambler, 1998). Thisis not a straightforward task, because users may not possess the overview on feasibilitiesand opportunities for automated support. Furthermore user requirements are oftenmisunderstood because the requirements collector misinterprets the users’ words. Inaddition to gathering requirements from users, standards and constraints (for example,the legacy systems) also play an important role in systems development.

2. Requirements Analysis and Documentation

After the raw requirements from stakeholders are gathered, they need to be analyzedwithin the context of business requirements (management perspective) such as cost-effectiveness, organizational, and political requirements. Also, the requirements rela-tions, that is, dependencies, conflicts, overlaps, omissions, and inconsistencies, needto be examined and documented. Finally the environment of the system, such as externalsystems and technical constraints, need to be examined and explicated.The gathering of requirements often reveals a large set of raw requirements that, due tocost and time constraints, cannot entirely be implemented in the system. Also theidentified raw requirements may be conflicting. Therefore, negotiation, agreement,communication, and priorisation of the raw requirements are also an important part of therequirements analysis process.The analyzed requirements need to be documented to enable communication withstakeholders and future maintenance of the requirements and the system. Requirementsdocumentation also includes describing the relations between requirements. Duringrequirements analysis it gives added value to record the rationale behind the decisionsmade to ease future change management and decision making.

Figure 2. Context for developing SyRS (IEEE Std 1233, 1998)

CUSTOMER

ENVIRONMENTTECHNICALCOMMUNITY

DEVELOPSYSTEMS

REQUIREMENTSCOLLECTION

TECHNICAL FEEDBACK

CONSTRAINT/ INFLUENCE

TECHNICALREPRESENTATION

CUSTOMER REPRESENTATION

CUSTOMERFEEDBACK

RAW REQUIREMENT



3. System Requirements Validation and Verification

In system requirements development, validation and verification activities includevalidating the system requirements against raw requirements and verifying the correct-ness of system requirements documentation. Common techniques for validating require-ments are requirements reviews with the stakeholders and prototyping.Table 1 contains examples of requirements engineering methods and techniques usedduring the system requirements development phase. The detailed descriptions of themethods have been published in Parviainen et al. (2003).Several methods for gathering, eliciting, and analyzing requirements from users and otherstakeholders can be used. Table 1 includes several observing methods (for example,

Table 1. System requirements development methodsActivity Example methods Description Gathering requirements

Ethnography (Suchman, 1983) Protocol Analysis (Ericsson & Simon, 1993)

Observing methods use techniques that may help to understand the thoughts and needs of the users, even when they cannot describe these needs or they do not exactly know what they want.

Focus groups (Maguire, 1998) JAD (Joint Application Development) (Ambler, 1998)

Meeting techniques cover separate techniques for meetings and workshops for gathering and developing requirements from different stakeholders.

Volere (Robertson & Robertson, 1999) Provides a generic process for gathering requirements, ways to elicit them from users, as well as a process for verifying them.

Requirements analysis

QFD (Quality Function Deployment) (Revelle, Moran, Cox, & Moran, 1998)

Identifying customer needs, expectations, and requirements, and linking them into the company's products.

SCRAM (Scenario-based Requirements Engineering) (Sutcliffe, 1998)

Develop requirements (whole RE) using scenarios. The scenarios are created to represent paths of possible behavior through use cases, and these are then investigated to develop requirements.

SSADM (Structured System Analysis and Design Methodology) (Ashworth & Goodland, 1990)

Can be used in the analysis and design stages of systems development. It specifies in advance the modules, stages, and tasks that have to be carried out, the deliverables to be produced, and the techniques used to produce those deliverables.

Negotiation and priorisation

CORE (Controlled Requirements Expression) (Mullery, 1979) WinWin approach (Bose, 1995)

The purpose of viewpoint-oriented methods is to produce or analyze requirements from multiple viewpoints. They can be used while resolving conflicts or documenting system and software requirements.

System requirements documentation

IEEE Std 1233-1998 Standards define the contents of a SyRS.

VDM (Vienna Development Model) (Björner & Jones, 1978) Specification language Z (Sheppard, 1995)

In formal methods, requirements are written in a statement language or in a formal -- mathematical -- way.

HPM (Hatley-Pirbhai Methodology) (Hatley & Pirbhai, 1987)

Gives support for documenting and managing of system requirements.

VORD (Viewpoint-Oriented Requirements Definition) (Kotonya & Sommerville, 1996)

Helps to identify and prioritize requirements and also can be utilized when documenting system and software requirements.



ethnography), meeting techniques (for example, focus groups) and analyzing techniques(for example, QFD) that can be used to gather requirements and avoid misunderstandingsof users needs. The methods help in identifying needs of individuals and converting theminto requirements of a desired product. At the same time social actions and workflows,safety-critical aspects, or technical constraints have to be taken into consideration. Theresults of the system requirements development phase are captured as top-level systemrequirements that are used as input for the allocation and flow-down phase.

Allocation and Flow-Down

The requirements allocation and flow-down process’ purpose is to make sure that allsystem requirements are fulfilled by a subsystem or by a set of subsystems collaboratingtogether. Top-level system requirements need to be organized hierarchically, helping toview and manage information at different levels of abstraction. The requirements aredecomposed down to the level at which the requirement can be designed and tested; thus,allocation and flow-down may be done for several hierarchy levels. The level of detailincreases as the work proceeds down in the hierarchy. That is, system-level requirementsare general in nature, while requirements at low levels in the hierarchy are very specific(Leffingwell & Widrig, 2000; Stevens et al., 1998).The top-level system requirements defined in the system requirements developmentphase (see previous subsection) are the main input for the requirements allocation andflow-down phase. In practice, system requirements development and allocation andflow-down are iterating; as the system level requirements are being developed, theelements that should be defined in the hierarchy should also be considered. By the timea draft of the system requirements is complete, a tentative definition of at least one andpossibly two levels of system hierarchy should be available (Dorfman, 1990).

1. Requirements Allocation

Allocation is architectural work carried out in order to design the structure of the systemand to issue the top-level system requirements to subsystems. Architectural modelsprovide the context for defining how applications and subsystems interact with oneanother to meet the requirements of the system. The goal of architectural modeling, alsocommonly referred to as high-level modeling or global modeling, is to define a robustframework within which applications and component subsystems may be developed(Ambler, 1998).Each system level requirement is allocated to one or more elements at the next level (thatis, it is determined which elements will participate in meeting the requirement). Allocationalso includes allocating the non-functional requirements to system elements. Eachsystem element will need an apportionment of the non-functional requirements (forexample, performance requirement). However, not all requirements are allocable; non-allocable requirements are items such as environments, operational life, and designstandards, which apply unchanged across all elements of the system or its segments. The



allocation process is iterative; in performing the allocation, needs to change the systemrequirements (additions, deletions, and corrections) and/or the definitions of the ele-ments can be found (Dorfman, 1990; Nelsen, 1990; Pressman, 1992; Sailor, 1990).The overall process of the evaluation of alternative system configurations (allocations)includes:

• Definition of alternative approaches.• Evaluation of alternatives.• Selection of evaluation criteria; performance, effectiveness, life-cycle cost factors.• Application of analytical techniques (for example, models).• Data generation.• Evaluation of results.• Sensitivity analysis.• Definition of risk and uncertainty.• Selection of the configuration (Blanchard & Fabrycky, 1981; Pressman, 1992).

Once the functionality and the non-functional requirements of the system have beenallocated, the system engineer can create a model that represents the interrelationshipbetween system elements and sets a foundation for later requirements analysis anddesign steps. The decomposition is done right when:

• Distribution and partitioning of functionality are optimized to achieve the overallfunctionality of the system with minimal costs and maximum flexibility.

• Each subsystem can be defined, designed, and built by a small or at least modest-sized team.

• Each subsystem can be manufactured within the physical constraints and tech-nologies of the available manufacturing processes.

• Each subsystem can be reliably tested as a subsystem subject to the availabilityof suitable fixtures and harnesses that simulate the interfaces to the other system.

• Appropriate regard is given to the physical domain – the size, weight, location, anddistribution of the subsystems – that has been optimized in the overall systemcontext (Leffingwell & Widrig, 2000).

2. Requirements Flow-Down

Flow-down consists of writing requirements for the lower-level elements in response tothe allocation. When a system requirement is allocated to a subsystem, the subsystemmust have at least one requirement that responds to the allocation. Usually more thanone requirement will be written. The lower-level requirement(s) may closely resemble thehigher-level one or may be very different if the system engineers recognize a capability



that the lower-level element must have to meet the higher-level requirements. In the lattercase, the lower-level requirements are often referred to as “derived” (Dorfman, 1990).Derived requirements are requirements that must be imposed on the subsystem(s). Theserequirements are derived from the system decomposition process. As such alternativedecompositions would have created alternative derived requirements. Typically thereare two subclasses of derived requirements:

• Subsystem requirements that must be imposed on the subsystems themselves butdo not necessarily provide a direct benefit to the end user.

• Interface requirements that arise when the subsystems need to communicate withone another to accomplish an overall result. They will need to share data or poweror a useful computing algorithm (Leffingwell & Widrig, 2000).

In the allocation and flow-down phase, requirements identification and traceability haveto be ensured both to higher-level requirements as well as between requirements on thesame level. Also the rationale behind design decisions should be recorded in order toensure that there is enough information for verification and validation of the next phases’work products and change management.The flowing down of the top-level system requirements through the lower levels of thehierarchy until the hardware and software component levels are reached in theoryproduces a system in which all elements are completely balanced, or “optimized.” In thereal world, complete balance is seldom achieved due to fiscal, schedule, and technologi-cal constraints (Sailor, 1990; Nelsen, 1990).Table 2 includes few examples of methods available for the allocation and flow-down.The results of allocation and flow-down are detailed system-level requirements and the“architectural design” or “top-level design” of the system. Again needs to change thesystem requirements (additions, deletions, and corrections) and/or the definitions of the

Table 2. Allocation and flow-down methods

Activity Example methods Description Allocation SRA (System Requirements Allocation

Methodology) (Hadel & Lakey, 1995) A customer-oriented systems engineering approach for allocating top-level quantitative system requirements. It aims at creating optimized design alternatives, which correspond to the customer requirements using measurable parameters.

ATAM (Architecture Trade-off Analysis Method) (Kazman, Klein, Barbacci, Longstaff, Lipson, & Carriere, 1998)

Helps for performing trade-off analysis and managing non-functional requirements during allocation.

HPM (Hatley-Pirbhai Methodology) (Hatley & Pirbhai, 1987)

Verifies requirements allocation and manages changes during allocation phase.

QADA (Matinlassi & Niemelä, 2002) FAST (Weiss & Lai, 1999)

Methods for architecture design and analysis. See more from Dobrica & Niemelä, 2002.

Flow-down ATAM (Architecture Trade-off Analysis Method) (Kazman et al., 1998) HPM (Hatley & Pirbhai, 1987)

Facilitates communication between stakeholders for gaining a rationale of requirements flow-down.



system elements may be found. These are then fed back to the system requirementsdevelopment process. Allocation and flow-down starts as a multi-disciplinary activity,that is, subsystems may contain hardware, software, and mechanics. Initially they areconsidered as one subsystem; in later iterations the different disciplines are consideredseparately. Software requirements development will be described in detail in the nextsection.

Software Requirements Development

The software requirements development process is the activity determining whichfunctionality of the system will be performed by software. Documenting this function-ality together with the non-functional requirements in a software requirements specifi-cation is part of this phase. Through the system mechanism of flow-down, allocation, andderivation, a software requirements specification will be established for each softwaresubsystem, software configuration item, or component (Thayer & Royce, 1990).

1. Software Requirements Analysis

Software requirements analysis is a software engineering task that bridges the gapbetween system-level software allocation and software design. Requirements analysisenables the specification of software functions and performance, an indication of thesoftware interfaces with other system elements, and the establishment of designconstraints that the software must meet. Requirements analysis also refines the softwareallocation and builds models of the process, data, and behavioral domains that will betreated by software. Prioritizing the software requirements is also part of softwarerequirements analysis. To support requirements analysis, the software system may bemodelled, covering both functional and quality aspects.

2. Software Requirements Documentation

In order to be able to communicate software requirements and to make changes to them,they need to be documented in a software requirements specification (SRS). An SRScontains a complete description of the external behavior of the software system. It ispossible to complete the entire requirements analysis before starting to write the SRS.However it is more likely that as the analysis process yields aspects of the problem thatare well understood, the corresponding section of the SRS is written.

3. Software Requirements Validation and Verification

Software requirements need to be validated against system-level requirements, and theSRS needs to be verified. Verification of SRS includes, for example, correctness,consistency, unambiguousness, and understandability (IEEE Std 830, 1998).



A requirements traceability mechanism to generate an audit trail between the softwarerequirements and final tested code should be established. Traceability should bemaintained to system-level requirements, between software requirements, and to laterphases, for example, architectural work products.

Table 3. Software requirements development methods

Activity Example methods Description Software requirements analysis

OMT (Object Modeling Technique) (Bourdeau & Cheng, 1995) Shlaer-Mellor Object-Oriented Analysis Method (Shlaer & Mellor, 1988) UML (Unified Modeling Language) (Booch, Jacobson, & Rumbaugh, 1998)

Object-oriented methods model systems in an object-oriented way or support object-oriented development in the analysis and design phases.

SADT (Structured Analysis and Design Technique) (Schoman & Ross, 1977) SASS (Structured Analysis and System Specification) (Davis, 1990)

Structured methods analyze systems from process and data perspective by structuring a project into small, well-defined activities and specifying the sequence and interaction of these activities. Typically diagrammatic and other modeling techniques are used during analysis work.

B-methods (Schneider, 2001) Petri Nets (Girault & Valk, 2002; Petri, 1962)

Formal methods are often used for safety-critical systems.

XP (Extreme Programming) (Beck, 1999) Agile methods are not specially focused on RE, but they have an integral point of view where RE is one of the activities of the whole cycle. See more from Abrahamsson et al., 2002.

CARE (COTS-Aware Requirements Engineering) (Chung, Cooper, & Huynh,, 2001) OTSO (Off-the-Shelf Option) (Kontio, 1995)

Specific methods for RE when using COTS (Commercial off-the-shelf). COTS is a ready-made software product that is supplied by a vendor and has specific functionality as part of a system.

Planguage (Gilb, 2003) Consists of a software systems engineering language for communicating systems engineering and management specifications, and a set of methods providing advice on best practices.

Requirements documentation

IEEE Std 830-1998 IEEE defines contents of an SRS. The standard doesn't describe sequential steps to be followed but defines the characteristics of a good SRS and provides a structure template for the SRS. This template can be used in documenting the requirements and also as a checklist in other phases of the requirements engineering process.

Requirements validation

Volere (Robertson & Robertson, 1999)

Provides process for gathering/eliciting and validating both system and software requirements.

Storyboard Prototyping (Andriole, 1989) Sequences of computer-generated displays, called storyboards, are used to simulate the functions of the formally implemented system beforehand. This supports the communication of system functions to the user and makes the trade-offs non-functional and functional requirements visible, traceable and analyzable.

Also several other methods, such as object-oriented methods, provide some support for validation and verification



The outcome of the software requirements development phase is a formal documentincluding a baseline of the agreed software requirements. According to SPICE (1998), asa result of successful implementation of the process:

• The requirements allocated to software components of the system and theirinterfaces will be defined to match the customer’s stated needs.

• Analyzed, correct, and testable software requirements will be developed.• The impact of software requirements on the operating environment will be under-

stood.• A software release strategy will be developed that defines the priority for imple-

menting software requirements.• The software requirements will be approved and updated as needed.• Consistency will be established between software requirements and software

designs.• The software requirements will be communicated to affected parties.

Table 3 gives examples of methods or techniques available for software requirementsdevelopment.

Continuous Activities

Documentation, validation, and verification of the continuous activities are included inthe main process phase where the activity is mentioned the first time. Only requirementsmanagement viewpoints (identification, traceability, and change management) are dis-cussed in this section. Requirements management controls and tracks changes of agreed requirements, rela-tionships between requirements, and dependencies between the requirements docu-ments and other documents produced during the systems and software engineeringprocess (Kotonya & Sommerville, 1998). Requirements management is a continuous andcross-section process that begins from requirements management planning and contin-ues via activities of identification, traceability, and change control during and afterrequirements development process phases. Requirements management continues alsoafter development during maintenance, because the requirements continue to change(Kotonya & Sommerville, 1998; Lauesen, 2002). Each of the requirements managementactivities is introduced in the following.

1. Requirements Identification

Requirements identification practices focus on the assignment of a unique identifier foreach requirement (Sommerville & Sawyer, 1997). These unique identifiers are used to refer



to requirements during product development and management. Requirements’ identifi-cation support can be divided into the three classes (Berlack, 1992; Sommerville &Sawyer, 1997):

1. Basic numbering systems• Significant numbering• Non-significant numbering

2. Identification schemes• Tagging• Structure-based identification• Symbolic identification

3. Techniques to support and automate the management of items• Dynamic renumbering• Database record identification• Baselining requirements

2. Requirements Traceability

Requirements traceability refers to the ability to describe and follow the life of arequirement and its relations with other development artefacts in both forward andbackward direction (Gotel, 1995). This is especially important for trade-off analysis,impact analysis, and verification and validation activities. If traceability is not present,it is very difficult to identify what the effects of proposed changes are and whetheraccepted changes are indeed taken care of.

3. Requirements Change Management

Requirements change management refers to the ability to manage changes to require-ments throughout the development lifecycle. Change management, in general, includesidentifying, analyzing, deciding on whether a change will be implemented, implementingand validating change requests. Change management is sometimes said to be the mostcomplex requirements engineering process (Hull, Jackson, & Dick, 2002). A change canhave a large impact on the system, and estimating this impact is very hard. Requirementstraceability helps making this impact explicit by using downward and upward traceability.For every change, the costs and redevelopment work have to be considered beforeapproving the change. Change management has a strong relationship with baselining.After requirements’ baselining, changes to the requirements need to be incorporated byusing change control procedures (Hooks & Farry, 2001). Examples of requirementsmanagement methods, techniques, or approaches have been listed in Table 4.



Requirements management tools have been developed because of the problems ofmanaging unstable requirements and the large amount of data collected during require-ments engineering process. A large set of tools – both commercial and non-commercial)– is available; for examples, see Parviainen et al, 2003. Requirements management toolscollect together the system requirements in a database or repository and provide a rangeof facilities to access the information about the requirements (Kotonya & Sommerville,1998). According to Lang & Duggan (2001), software requirements management toolsmust be able to:

• Maintain unique identifiable description of all requirements.• Classify requirements into logical user-defined groups.• Specify requirements with textual, graphical, and model-based description.• Define traceable associations between requirements.• Verify the assignments of user requirements to technical design specifications.• Maintain an audit trail of changes, archive baseline versions, and engage a

mechanism to authenticate and approve change requests.• Support secure, concurrent co-operative work between members of a

multidisciplinary development team.• Support standard systems modeling techniques and notations.• Maintain a comprehensive data dictionary of all project components and require-

ments in a shared repository.

Table 4. Requirements management methods

Activity Example methods Description Requirements traceability

Cross reference, traceability matrices, automated traceability links (Sommerville & Sawyer, 1997)

Techniques can be used for presenting and managing requirements as separate entities and describing and maintaining links between them, for example, during allocation, implementation, or verification.

IBIS derivatives (Pinheiro, 2000) Document -centred models Database guided models (Pinheiro, 2000) RADIX (Yu, 1994) QFD (West, 1991)

Methods present traces and provide information to capture design rationale, for example, by providing automated support for discussion and negotiation of design issues.

Languages, for example, ALBERT (Dubois, Du Bois, & Petit, 1994) or RML (Requirements Modeling Language) (Greenspan, Mylopoulos, & Borgida, 1994)

Traceability can be supported by using languages or notations.

Change management

Olsen’s ChM model (Olsen, 1993) V-like model (Harjani & Queille, 1992) Ince's ChM model (Ince, 1994)

Change management process models and approaches.



• Generate predefined and ad-hoc reports.• Generate documents that comply with standard industrial templates.• Connect seamlessly with other tools and systems.

Conclusion

Requirements engineering for sociotechnical systems is a complex process that consid-ers product demands from a vast number of viewpoints, roles, responsibilities, andobjectives. In this chapter we have explained the activities of requirements engineeringand their relations to the available methods. A large set of methods is available, each withtheir specific strengths and weaknesses. The methods’ feasibility and applicability do,however, vary between phases or activities. Method descriptions also often lack theinformation of the methods’ suitability to different environments and problem situations,thus making the selection of an applicable method or combination of methods to be usedin a particular real-life situation complicated.Requirements engineering deserves stronger attention from practice, as the possibilitiesof available methods are largely overlooked by industrial practice (Graaf, Lormans, &Toetenel, 2003). As requirements engineering is the process with the largest impact onthe end product, it is recommended to invest more effort in industrial application as wellas research to increase understanding and deployment of the concepts presented in thischapter.This chapter has only listed a few examples of methods. For a more comprehensive listingof methods see Parviainen et al. (2003).

References

Abrahamsson, P., Salo, O., Ronkainen, J. & Warsta, J. (2002). Agile software developmentmethods: Review and analysis. Espoo: Technical Research Centre of Finland, VTTPublications.

Ambler, S. W. (1998). Process patterns. building large-scale systems using objecttechnology. Cambridge University Press.

Andriole, S. (1989). Storyboard prototyping for systems design: A new approach to userrequirements analysis. Q E D Pub Co.

Ashworth, C., & Goodland, M. (1990). SSADM: A practical approach. McGraw-Hill.Beck, K. (1999). Extreme programming explained: Embrace change. Reading, MA:

Addison-Wesley.Berlack, H. (1992). Software configuration management. John Wiley & Sons.



Björner, D., & Jones, C.B. (Eds.). (1978). The Vienna development method: The meta-language: volume 61 of lecture notes in computer science. Springer-Verlag.

Blanchard, B.S., & Fabrycky, W.J. (1981). Systems engineering and analysis. Prentice-Hall.

Booch, G., Jacobson, I., & Rumbaugh, J. (1998). The unified modeling language userguide. Addison-Wesley.

Bose, P. (1995). A model for decision maintenance in the winwin collaboration framework.Proceedings of the 10th Conference on Knowledge-Based Software Engineering,105-113.

Bourdeau, R.H., & Cheng, B.H.C. (1995). A formal semantics for object model diagrams.IEEE Transactions on Software Engineering, 21(10), 799–821.

Chung, L., Cooper, K., & Huynh, D.T. (2001). COTS-aware requirements engineeringTechnique. Proceedings of the 2001 Workshop on Embedded Software Technol-ogy (WEST’01).

Davis, A. M. (1990). Software requirements: Analysis and specification. Prentice Hall.Dobrica, L., & Niemelä, E. (2002). A survey on software architecture analysis methods.

IEEE Transactions on Software Engineering, 28(7), 638-653.Dorfman, M. (1990). System and software requirements engineering. In R.H. Thayer &

M. Dorfman (Eds.) IEEE system and software requirements engineering, IEEEsoftware computer society press tutorial. Los Alamos, CA: IEEE Software SocietyPress.

Dubois, E., Du Bois, P., & Petit, M. (1994). ALBERT: An agent-oriented language forbuilding and eliciting requirements for real-time systems. Vol. IV: Informationsystems: Collaboration technology organizational systems and technology. Pro-ceedings of the Twenty-Seventh Hawaii International Conference on SystemSciences, 713 -722.

Ericsson, K.A., & Simon, H. A. (1993). Protocol analysis - revised edition. MIT Press.Gilb, T. (2003). Competitive Engineering. Addison-Wesley.Girault, C., & Valk, R. (2002). Petri nets for system engineering: A guide to modeling,

verification and applications. Springer-Verlag.Gotel, O. (1995). Contribution structures for requirements traceability. PhD thesis,

Imperial College of Science, Technology and Medicine, University of London.Graaf , B.S., Lormans, M., & Toetenel, W.J. (2003). Embedded software engineering: state

of the practice [Special issue]. IEEE Software magazine, 20(6), 61-69.Greenspan, S., Mylopoulos, J., & Borgida, A. (1994). On formal requirements modelling

languages: RML revisited. Proceedings of ICSE-16, 16th International Confer-ence on Software Engineering, 135-147.

Hadel, J.J., & Lakey, P.B. (1995). A customer-oriented approach for optimising reliability-allocation within a set of weapon-system requirements. Proceedings of the AnnualSymposium on Reliability and Maintainability, 96-101.



Harjani, D.R., & Queille, J.P. (1992). A process model for the maintenance of large spacesystems software. Proceedings of Conference on Software Maintenance, LosAlamitos: IEE Computer, 127-136.

Hatley, D.J., & Pirbhai, I.A. (1987). Strategies for real-time system specification. DorsetHouse.

Hooks, I., & Farry, K. (2001). Customer-centred products. Amacom.Hull, M.E.C., Jackson, K., & Dick, A.J.J. (2002). Requirements Engineering. Berlin:

Springer-Verlag.HUSAT Reasearch Institute. (1998). User centred-requirements handbook (Version 3.2).

[Handbook]. Loughborough, Leicestestershire, UK: Maguire.Ince, D. (1994). Introduction to software quality assurance and its implementation.

McGraw-Hill.Institute of Electrical and Electronics Engineering, Inc. (1990). IEEE Standard Glossary

of Software Engineering Terminology (IEEE Std 610.12).Institute of Electrical and Electronics Engineering, Inc. (1998). IEEE Guide for Developing

System Requirements Specifications (IEEE Std 1233).Institute of Electrical and Electronics Engineering, Inc. (1998). IEEE Recommended

Practice for Software Requirements Specifications (IEEE Std 830).International Organisation for Standardisation. (Ed.). (1998). Information technology

software process assessment part 2: A reference model for processes and processcapability. (SPICE: ISO/IEC TR 15504-2). Geneva, Switzerland: ISO.

Juristo, N., Moreno A.M., & Silva, A. (2002). Is the European industry moving towardsolving requirements engineering problems? IEEE Software, 19(6), 70-77.

Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H., & Carriere, J. (1998). Thearchitecture tradeoff method. Proceedings of the fourth IEEE InternationalConference on Engineering of Complex Computer Systems, 68-78.

Komi-Sirviö, S., & Tihinen M. (2003, July 1-3). Great challenges and opportunities ofdistributed software development - an industrial survey. Proceedings of FifteenthInternational Conference on Software Engineering and Knowledge Engineer-ing, SEKE2003, San Francisco.

Kontio, J. (1995). OTSO: a systematic process for reusable software component selec-tion, version 1.0. The Hughes Information Technology Corporation and the EOSProgram.

Kotonya, G., & Sommerville, I. (1996). Requirements engineering with viewpoints.Software Engineering Journal, 11(1), 5-11.

Kotonya, G., & Sommerville, I. (1998). Requirements engineering: process and tech-niques. John Wiley & Sons.

Lang, M., & Duggan, J. (2001). A tool to support collaborative software requirementsmanagement. Requirements Engineering, 6(3), 161–172.

Lauesen, S. (2002). Software requirements: styles and techniques. Addison-Wesley.Leffingwell, D., & Widrig, D. (2000). Managing software requirements - a unified

approach. Addison-Wesley.



Matinlassi, M. & Niemelä, E. (2002). Quality-driven architecture design method. Inter-national Conference of Software and Systems Engineering and their Applications(ICSSEA 2002), Paris, France.

Mullery, G.P. (1979). CORE – A method for controlled requirement specification. Pro-ceedings of IEEE Fourth International Conference on Software Engineering.

Nelsen, E. D. (1990). System engineering and requirement allocation. In R.H. Thayer &M. Dorfman, IEEE system and software requirements engineering, IEEE softwarecomputer society press tutorial. Los Alamos, CA: IEEE Software Society Press.

Olsen, N. (1993). The software rush hour. IEEE Software Magazine, 29-37.Parviainen, P., Hulkko, H., Kääriäinen, J., Takalo, J., & Tihinen, M. (2003). Requirements

Engineering. Inventory of Technologies. Espoo: VTT Publications.Petri, C.A. (1962). Kommunikation mit Automaten. Bonn Institut für Instrumentelle

Mathematik. Schriften des IIM Nr. 2.Pinheiro, F. (2000). Formal and informal aspects of requirements tracing. Proceedings of

III Workshop on Requirements Engineering, Rio de Janeiro, Brazil.Pressman, R. S. (1992). Software engineering, a practitioner’s approach, third edition.

McGraw-Hill Inc.Revelle, J.B., Moran, J.B., Cox, C.A., & Moran, J.M. (1998). The QFD handbook. John

Wiley & Sons.Robertson, S., & Robertson, J. (1999). Mastering the requirements process. Addison-

Wesley.Ropohl, G. (1999). Philosophy of sociotechnical systems. Society for Philosophy and

Technology 4(3). Retrieved May 5, 2004, from http://scholar.lib.vt.edu/ejournals/SPT/v4_n3pdf/ROPOHL.PDF.

Royce, W. W. (1970). Managing the development of large software systems. Proceed-ings of IEEE Wescon, August 1970. Reprinted in Proceedings of 9th Int’l ConferenceSoftware Engineering 1987, 328-338, Los Alamitos: CA.

Sailor, J. D. (1990). System engineering: an introduction. In R.H. Thayer & M. Dorfman,IEEE system and software requirements engineering, IEEE software computersociety press tutorial. IEEE Software Society Press.

Schneider, S. (2001). The B-method: an introduction. Palgrave.Schoman, K., & Ross, D.T. (1977). Structured analysis for requirements definition. IEEE

Transactions on Software Engineering 6–15.Sheppard, D. (1995). An introduction to formal specification with Z and VDM. McGraw-

Hill.Shlaer, S., & Mellor, S. (1988). Object-oriented system analysis: modeling the world in

data (Yourdon Press computing series). Prentice-Hall.Siddiqi, J. (1996). Requirement engineering: the emerging wisdom. IEEE Software, 13(2),

15-19.Sommerville, I., & Sawyer, P. (1997). Requirements engineering: A good practise guide.

John Wiley & Sons.



Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering - Copingwith complexity. London: Prentice Hall.

Suchman, L. (1983). Office procedures as practical action. ACM Transactions on OfficeInformation Systems, 320-328.

Sutcliffe, A. (1998). Scenario-based requirement analysis. Requirements EngineeringJournal, 3(1), 48-65.

Thayer, R. H., & Royce, W. W. (1990). Software systems engineering. In R.H. Thayer &M. Dorfman, M. (Eds.), IEEE system and software requirements engineering, IEEEsoftware computer society press tutorial. Los Alamos, CA: IEEE Software SocietyPress.

Weiss, D., & Lai, C. (1999). Software product-line engineering: A family-based softwaredevelopment process. Reading, MA: Addison-Wesley.

West, M. (1991, May 1-7). Quality function deployment in software development.Proceedings of IEEE Colloquium on Tools and Techniques for MaintainingTraceability During Design.

Yu, W. D. (1994). Verifying software requirements: a requirement tracing methodologyand its software tool-RADIX. IEEE Journal on Selected Areas in Communica-tions, 12(2), 234 -240.

Endnote

1 This chapter describes the requirements engineering process based on work donein the MOOSE (Software engineering methodologies for embedded systems)project (ITEA 01002). The authors would like to thank the partners in the MOOSEproject (http://www.mooseproject.org/), as well as the support from ITEA and thenational public authorities.

Challenges in Requirements Engineering for Embedded Systems 21


Chapter II

Challenges inRequirements

Engineering forEmbedded Systems

Eman Nasr, Cairo University, Egypt

Abstract

In this chapter we are particularly interested in requirements engineering of softwarewhere the software is part of a complex engineered system; that is, embedded software.Embedded software is the software that runs on a computer system that is integral toa larger system whose primary purpose is not computational. Embedded softwaresystems are of rising significance in the industry, and they are found in a wide rangeof industries in the modern world, including medical, nuclear, chemical, rail networks,aerospace, and automotive industries. The RE of this category of software is challengingbecause of its special properties that add to its complexity and make it more expensiveand error-prone as compared with other software categories, for example, businessapplications. In this chapter we identify the special properties of embedded softwaresystems to help in better understanding of such domain, discuss the special REchallenges that the special properties introduce, and introduce the main current REapproaches for the domain.

22 Nasr


Introduction

Modern computer-based systems are becoming increasingly complex ensembles ofhardware and software, thus adding more challenges to the software requirementsengineering process. Requirements engineering (RE) is usually known as the branch ofsoftware engineering that deals with the early phase of software development. Althoughthere is no single definition for RE, because the field of research is still maturing, a well-accepted definition is (Zave, 1995):

“Requirements engineering is the branch of software engineering concerned with thereal-world goals for functions of, and constraints on, software systems.”

RE deals with activities that attempt to understand the exact needs for a software-intensive system and to translate such needs into unambiguous requirements that willbe used in the development and testing of the software system. RE is considered acombination of mainly three interacting activities: eliciting requirements related to aproblem domain, specifying the requirements in an unambiguous way, and ensuring thevalidity of such requirements (Loucopoulos & Karakostas, 1995). It is one of the mostimportant activities in software development because errors made in requirementsbecome increasingly costly to repair later in development and extremely costly to repairafter delivery (Brooks, 1987; Heitmeyer, 1997; Hofmann, 1993; Wieringa, 1996). Theproduct of RE is a requirements specification, which forms a foundation for the wholesubsequent/concurrent development. Among the important properties of a good re-quirements specification are: completeness, lack of ambiguity, good structure, and easeof understanding by all of the stakeholders involved in the software system. A goodrequirements specification should seek to bridge the communication gap betweendomain experts and software experts. It is widely accepted that a good RE method iscrucial for any successful large-scale software system development. It is also widelyrecognised that the most serious embedded software failures can be traced back todefective specification of requirements (Knight, 2002; Leveson, 1995; Lutz, 1993).In this chapter we are particularly interested in RE of software where the software is partof a complex engineered system, that is, embedded software. Embedded software is thesoftware that runs on a computer system that is integral to a larger system whose primarypurpose is not computational (Lutz, 1993). An embedded software system usuallyprovides at least partial control over the hardware system in which it is embedded. Anembedded software system is usually highly reactive, as it responds to various sensorinputs, interrupts, or alarm conditions from its environment. Embedded software systemsare of rising significance in the industry, and they are found in a wide range of industriesin the modern world, including medical, nuclear, chemical, rail networks, aerospace, andautomotive industries. Embedded software systems have proliferated almost every-where over the past few years, from household appliances, like toasters and washingmachines, to cars to aircraft and spacecraft. Of course the software embedded in theseproducts varies in complexity as widely as the style of the products.



The RE of this category of software is challenging because of its special properties.Among the major properties that characterise this special category of software are: theembedded software’s context, the consideration of the software requirements at a laterstage in the whole system development life cycle, the broad range of stakeholders, andthe periodicity of most of the software’s functions. These special properties of anembedded software system add to its complexity and make it more expensive and error-prone as compared to other software categories, for example, business applications. Inthis chapter we identify the special properties of embedded software systems to help inbetter understanding of such domain, discuss the special RE challenges that the specialproperties introduce, and introduce the main current RE approaches for the domain.

Special Properties of EmbeddedSoftware Systems

This section defines and discusses some of the fundamental characteristics of embeddedsoftware systems. Each of the special characteristics is defined and discussed in one ofthe following subsections.

Context of Embedded Software Systems

By definition, an embedded software system is part of a broader engineered hardwaresystem and usually provides at least partial control over the hardware system in whichit is embedded (Heimdahl & Leveson, 1996). Embedded software is usually deeplyembedded in engineered systems, which range from simple appliances, for example,toasters, to highly complex machines, for example, spacecrafts. Because of the contextof embedded software systems, they are usually tightly coupled to their physicalenvironment through sensors and actuators. This type of software is often reactive. Itmust react or respond to environmental conditions as reflected in the inputs arriving tothe software. An embedded software system interfaces most of the time with hardwarecomponents, or other external hardware and software systems (in complex engineeredsystems), rather than with human operators. For example, in modern aircraft thatincorporate embedded software control systems, the so called fly-by-wire (FBW), theembedded software is responsible for controlling subsystems developed by a range ofother engineering disciplines. The embedded software receives its inputs from theaircraft’s sensors and other control elements (for example, pedals) and results in electricaloutput signals to the actuators that move the control surfaces of the aircraft. Such acontext of embedded software systems adds to their complexity and makes them difficultto comprehend.

24 Nasr


The Embedded Software Requirements Phase Comes ata Later Stage in the System Development Life Cycle

Because of the context of an embedded software system, the development activities areusually part of a bigger hybrid (hardware and software) project that is underway. Firstthe requirements of the system as a whole are considered, followed by design for thesystem, after which the embedded software requirements are considered. Figure 1 (Davis,1990) gives a simplified diagram of the initial sequence of development phases for ahybrid system.The figure illustrates in a simplified way how the requirements phase for an embeddedsoftware system comes at a later stage of the development life cycle. During the systemdesign activity most decisions regarding the software vs. hardware breakdown aresettled. When the system design is complete, and all major external interfaces of majorcomponents are defined, only then software requirements can be elaborated (Davis,1990). This is considered the current popular conventional wisdom, but since it isexpected in the future that software will be gaining more ground, considering softwarerequirements from the very beginning will be crucial. This current conventional wisdomusually results in producing poor software requirements, as they are usually written bythe hardware specialists without involving the software engineers; in addition, thiscontributes to the lack of mutual understanding and appreciation of each other’s pointsof view. Although specifying the components of an engineered system is essentialbecause different suppliers provide them, experience in automotive development (Weber

Figure 1. Conventional wisdom about hybrid (software and hardware) system project’sinitial sequence of development phases

system requirements

hardware requirements

system design

software requirements

hardware design

software design

• • •

• • •



& Weisbrod, 2003) has proved that separating software from hardware makes thingsharder, and it was reported that a single component must be specified as two interactive“problems” — a hardware problem and a software problem.

Broad Range of Stakeholders

The stakeholders of a system are the people and organisations that have a stake in theoperation of the system (Chonoles & Quatrani, 1996). Because of the context ofembedded software systems, the stakeholders cover a very wide range of people andorganisations. An example of some stakeholders could be hardware designers, softwareanalysts, domain specialists, customers (usually companies or governments in the caseof large engineered systems), subcontractors, regulatory organisations, and standardsgroups. The stakeholders do not necessarily include end users, as in the informationsoftware systems domain, because in engineering industries, such as aerospace, cus-tomer organisations tend to concentrate on engineering aspects of the requirements andneglect the user’s view (Lubars, Potts, & Richter, 1993). Large complex engineeredsystems are customer specific rather than user specific; for example, the requirements ofan aerospace are dictated by the customer (organisation or government agency) and donot directly represent the interests of a pilot. One of the major problems of this broadnessof the range of stakeholders for large complex embedded systems is getting agreementbetween stakeholders.

Periodicity of Most of the Embedded Software Functions

In engineered projects, most of the functions (which are also referred to as tasks or jobsor processes) performed by embedded software systems are periodic or cyclic. Theyexecute regularly and repetitively, sometimes at a high frequency as in aircraft applica-tions, for example, monitoring the speed, altitude, and attitude of an aircraft every 100ms.Sensor information is used by periodic functions that move the control surfaces of theaircraft (for example, rudder and engine thrusts) in order to maintain stability and otherdesired characteristics (Krishna & Shin, 1997). Periodic software functions could beconsidered autonomous, that is, activated regularly by the system. Indeed this does notpreclude the existence of periodic embedded software functions that are initiateddepending on the state of the controlled process or on the operating environment or ona command from the operator’s input panel (Krishna & Shin, 1997). Therefore it is not onlysufficient to specify the functional requirements of large complex embedded systems butalso a reflection on the initiator of a function and on timing requirements is essential.

Criticality of Embedded Software

Large embedded software systems that provide control activities, for example, control-ling an aircraft engine, have a critical need to meet time deadlines under all foreseeablecircumstances. These systems are often referred to as safety-critical real-time or hard

26 Nasr


real-time systems. This is because of consequences of the functions not being executedon time are catastrophic, for example, killing people or causing major damage to theenvironment. Safety-critical systems are found in a wide range of industries, includingthe nuclear, chemical, and automotive industries. Embedded control software is highlyreactive to its environment. It has to react to various sensor inputs, interrupts, or alarmconditions from the environment within severe imposed time limits. For systems oper-ating under severe timing constraints, a thorough understanding of what goes on at whattime is required (Hruschka, 1992). Thus there are significant safety issues and temporalrequirements that must be considered.

Use of Redundancy

Because of the safety-critical nature of large embedded software systems, redundancyis used as a technique for providing reliability (or fault tolerance). Redundancy providesfor multiple implementations of a function, for example, by the use of more than oneprocessing channel (Hruschka, 1992). The use of redundancy is a result of a designdecision that is based on the assumption that a given set of faults with the same systemeffect will not occur simultaneously in two or more independent elements (Society ofAutomotive Engineers, 1994). For example, the Boeing 777 primary flight control systemuses three separate channels for redundancy; each channel is implemented with threeseparate lanes, each of which uses different processors and different compilers (Knight,2002). The understanding of this property adds to the understanding of the domain, asit is usually reflected in the embedded software requirements.

Lots of Sources for the Embedded SoftwareRequirements Phase

There are lots of input sources for the software RE phase of embedded systems. Figure2 gives a simple diagram to show the five basic sources of embedded software require-ments: system requirements specification document(s), current system designdocument(s), previous designs, software safety requirements specification document(s),and stakeholders.The initial software needs for embedded software systems are usually distributed across(and within) lots of documents. The section above observed that the software require-ments phase comes at a later stage in the development life cycle of the system, after boththe identification of the system requirements and the system design activity, hence theinputs from the system requirements specification and current design documents inFigure 2. Previous designs also provide input to the embedded software requirementsphase, as shown in Figure 2. This is because engineered systems, in most cases, are notdeveloped from scratch. They are the result of upgrades and enhancements over manyyears. For example, in the automotive domain (Weber & Weisbrod, 2003) systems aretypically built in increments; a new car series inherits most functionality from existingones, with various adaptations, extensions, or innovations.



Earlier we highlighted safety as a major issue for safety-critical systems. Although it isusually classified as a non-functional requirement that is considered at the systemrequirements phase, many standards demand that safety requirements be separatelyidentified. Therefore, hazard analysis for a system takes place first, before the softwarerequirements phase, and produces some software safety specifications, which have tobe taken into account during specification of the embedded software system. Thus theinput of software safety requirements specification to the embedded software RE phaseis shown in Figure 2.The section above gave a general definition for stakeholders that includes domainspecialists. Although most of the requirements of the stakeholders are reflected in thefour types of documents mentioned above, domain specialists always continue to be avery important source of requirements for the embedded software because of thecontinuous need for elaborating the issues related to the complex system hardwaredesign. Therefore stakeholders are also shown as an input source for embedded softwarerequirements in Figure 2.Having lots of, and diverse, input sources for the initial needs of the embedded softwaremake the elicitation of the requirements difficult. One of the problems is that the initialneeds are distributed across (and within) the four types of documents mentioned above,and the more complex the system is, the more distributed the initial software needs are.This results in challenges such as finding all of the requirements, reconciling them toensure consistency, and ensuring completeness.

RE Challenges for the Domain ofEmbedded Software Systems

As could be seen from the previous section, the intrinsic properties of embeddedsoftware systems introduce challenges and problems that exceed those of other software

Figure 2: Inputs to RE phase for large complex embedded software systems

Previous Current Design

Documents

System Requirements Specification

Software Safety Requirements Specification

Embedded Software Requirements Phase Stakeholders

28 Nasr


categories. This, in general, makes embedded software development more expensive anderror prone, and in particular makes RE more difficult. Some of the extra RE challengesresulting from the properties of the domain are:

• Complexity. This is the most obvious challenge. It mainly emerges from thecomplexity of the context of embedded software systems discussed earlier. Com-plexity is a direct barrier to understanding, and therefore is a major concern.Sommerville and Sawyer (1997) state that problems of requirements increaseexponentially with the size of the system, as a requirements document could beorganised into several volumes with thousands of individual requirements.

• Requirements redundancy. Redundancy in information in the requirements speci-fications may lead to inconsistencies and double work. In large projects, such asautomotive system development, engineers create several lengthy specificationsand related documents under tight deadlines, which typically contain redundantinformation (Weber & Weisbrod, 2003).

• Specifiability. There are many eventualities that embedded software systems needto consider. In addition, because of the complexity of large systems, there is usuallysignificant difficulty in eliciting requirements for embedded software systems andproducing appropriate, adequate, and effective specifications (McDermid, 1993).The difficulty of eliciting requirements emerges also from having lots of inputsources for the software requirements phase, discussed earlier.

• Continuously changing requirements. Requirements of embedded systems un-dergo constant maintenance and enhancements during the development lifetime,and therefore they must be extensible. One of the possible reasons for the constantmaintenance of the requirements of embedded software systems is gaining betterunderstanding, which is a problem caused by, for example, having a broad rangeof stakeholders, discussed earlier. A lot of assumptions are usually made early inthe development of a project, which are then resolved as the system matures(Weber & Weisbrod, 2003).

Coming up with solutions to the RE challenges and problems of the embedded softwaresystems domain could be quite challenging. Two basic properties should always beavailable in any RE method for handling embedded software systems: simplicity andstructure. Simplicity is the only real way to ensure understandability of the systems beingproduced, understanding the system, its environment, its workings, etc. (McDermid,1993). Furthermore, for large embedded software systems, the requirements specifica-tions need to be structured at several layers of abstraction to help in better understandingand allow for requirements reuse (Weber & Weisbrod, 2003).



Current RE Approaches for EmbeddedSoftware Systems

This section highlights the main approaches of RE for embedded software systemsavailable in the literature. Macaulay (1996) generally identifies nine different groups inthe community with a principal interest in the problem of requirements. The nine groupsare (Macaulay, 1996):

1. Marketing. The marketing group is interested in the relationship between require-ments and the success of a product in the market place.

2. Psychology and Sociology. The psychology and sociology group is interested inthe relationship between requirements and the needs of people as intelligent andsocial beings.

3. Structured Analysis (SA). The SA group is interested in the relationship betweenrequirements and the software process, starting from a process and data perspec-tive.

4. Object-Oriented Analysis (OOA). The OOA group is interested in the relationshipbetween requirements and the software development process starting from a real-world object perspective.

5. Participative Design. The participative group is interested in requirements as partof the process empowering users by actively involving them in the design ofsystems that affect their own work.

6. Human Factors and Human-Computer Interaction. The human factors and human-computer interaction group is interested in the acceptability of systems to people,the usability of systems and the relationship between requirements and evaluationof the system in use.

7. Soft Systems. The soft systems group is interested in the relationship betweenrequirements and how people work as part of an organisational system.

8. Quality. The quality group is interested in the relationship between requirementsand the quality of a product, in relation to process improvements that lead tocustomer satisfaction.

9. Formal Computer Science. The formal computer science group is interested in therelationship between requirements and software engineering’s need for precision.

Each of the nine groups advocates the use of specific techniques, but only three of thegroups are interested in the relation between requirements and the software process, and,hence, are of relevance to RE of embedded software systems. They are SA, OOA, andFormal Computer Science groups. The rest of this section discusses briefly the threerelevant approaches to RE of embedded software systems; it is not meant to be exhaustive

30 Nasr


in covering all of the RE methods for embedded software systems available in theliterature. The RE methods for embedded software systems available in the literaturecould be mainly categorised into SA methods, OO methods, or formal methods.

Structured Analysis Methods for Embedded Systems

SA was originally developed in the 1970s following on from structured programming andstructured design. The central principle of this movement is that software systemsshould be modular, that is, partitioned into components with close cohesion and loosecoupling (Wieringa, 1998). SA approaches evolved from work on management informa-tion systems (MIS) and are concerned with the relationship between requirements andthe software process, starting from a process and data perspective. A typical SA startswith a context diagram, which shows the software system and all the external entities,terminators, that interact with it. The requirements are then defined by decomposing thesoftware system into a number of processes (also known as functions or transformations)and defining the inputs and outputs of each process. Processes exchange data either withother processes, data stores, or sources/destinations, terminators, outside the bound-ary of the software system. The notation used for modeling is referred to as the data flowdiagram (DFD), which provides a graphic representation of the movement of datathrough the system and the transformations on the data. The processes in turn are thenbroken down to other DFDs, describing the processing the node does to transform theincoming data items to the outgoing data items, until elementary processes are reached.When an elementary process is reached, it is then defined in a MiniSpec. Data dictionariesare used to support the DFDs by providing a repository for the definitions anddescriptions of each data item on the DFDs.For some time, developers of large embedded software systems used SA as the bestavailable method to capture their requirements, but they shared a feeling that it was notadequate, as it did not take into account the specific problems of this type of softwaresystem category (Hruschka, 1992), like concurrency, for example. Between 1982 and 1987Ward and Mellor (Ward & Mellor, 1985) and Hatley and Pirbhai (Hatley & Pirbhai, 1987)adapted and extended the ideas of SA methods to cope with the specific complexitiesarising from large complex embedded systems. Ward and Mellor were the first to publishtheir techniques for the analysis of real-time, embedded software systems in StructuredDevelopment for Real-Time Systems (Ward & Mellor, 1985). They made extensions to SAto adapt the method to the needs of embedded software control systems mainly by addingnew control constructs, which are analogous to the data constructs, to capture controlbehaviour (Svoboda, 1997). Their process model is visualised by means of a transforma-tion schema that contains the traditional DFD constructs in addition to control con-structs. On the DFD the interactions of both those processes that transform data andthose that react to events in the environment and exercise control over other processescould be shown. Data processes explode to lower-level transformation schemas, whichcan also contain both data and control constructs. However, the explosion of controlprocesses contributes to the control model of the system under development only.Hatley and Pirbhai published their technique in Strategies for Real-Time SystemSpecification (Hatley & Pirbhai, 1987) in 1987. Like Ward and Mellor’s approach, the real-



time extensions developed by Hatley and Pirbhai take care of the control aspects. Theyintroduced the same control constructs as Ward and Mellor, but they used themdifferently. Hatley and Pirbhai used the control constructs to create control flowdiagrams (CFD) parallel to the DFDs with control nodes having the same names as thedata process nodes. Similar to the MiniSpec, which they call instead a process specifi-cation (PSPEC), they introduced control specifications (CSPECS), which capture anyinteraction between the DFDs and CFDs.Although the above real-time SA methods are in widespread use for large embeddedsoftware systems, especially in the avionics industry, there are a number of commoncriticisms. These are (Faulk, 1995; Hall, 1997; Wieringa, 1998):

• SA is not an RE method. Apart from the context diagram, SA does not addressrequirements; it is more of a system design method. This might be attributed to thefact that SA methods are concerned with the whole of the system developmentlifecycle and not only requirements. This tends to make the division betweenrequirements analysis and design difficult.

• Insufficient process guidance. There are no explicit process steps. Not enoughguidance is given on which part of the problem to model as a control process, whatto model as a data transformation process, and what to model as data. Practitionersalso find it difficult to know when to stop process decomposition and addition ofdetail. Particularly in the hands of less experienced practitioners, data flow modelscontinue to incorporate a variety of detail that more properly belongs to design orimplementation, and the diagrams themselves become unmanageably complex.

• Separation between data and control is often confusing. SA separates data flowsand data processes from events flows and control processes. This distinctionbetween data and control is often detrimental to the clarity of the model.

• Inappropriateness of separation of memory from processing. The bulk of memoryof the software in SA resides in data stores. This notion of separating data fromprocessing is implementation dependent; therefore it is inappropriate if we needto abstract from implementation technology in the RE phase to offer more flexibility.

Object-Oriented Methods for Embedded Systems

OOA is a relatively new approach to requirements analysis; it became the focus of interestin the 1990s. Like SA, OOA has its roots in programming (starting with Simula 67 and thenwith Smalltalk 80), and design. OO programming, which is also modular, was seen as apromising approach to the industrialisation of the software development process. As OOprogramming languages have become more popular, this has justified switching to OOdesign and analysis in order to avoid having to switch from one paradigm to the otherwithin the development process for a single system. Bailin (1989), for example, createdan OO requirements specification method to be used during the requirements analysisphase to avoid the laborious process of recasting dataflow diagrams.SA and OOA are considered to be fundamentally incompatible. OOA differs from SA inthe primary perspective adopted in the models developed, taking objects rather than

32 Nasr


processes as the fundamental modeling unit. In SA functions are grouped together if theyare constituent steps in the execution of a higher-level function; the constituent stepsmay operate on entirely different data. While in OOA functions are grouped together ifthey operate on the same data. According to Davis (1993), the primary motivation forobject-orientation is that, as a software system evolves, its functions tend to change butits objects remain unchanged. Thus a system built using OO techniques may beinherently more maintainable than one built using more conventional functional ap-proaches (Macaulay, 1996). The literature contains lots of commercial success storiesabout the use of OO methods (Graham, 1995; Jacobson, 1996).A lot of SA methodologists, including Ward (Selic, Gullekson, & Ward, 1994; Ward, 1989)and Mellor (Shlaer & Mellor, 1988), who are among the inventors of Real-Time SAmethods, have made a paradigm shift to object-orientation. Like SA, the way most of theOOA methods handle requirements could not be considered an RE process. For example,most OOA methods do not address developing a good requirements specification; theyfocus on problem analysis and produce a static object model. It was not until theintroduction of use cases by Jacobson (Jacobson, Christerson, Jonsson, & Oevergaard,1992) that OO methodologists started to consider the behavioural aspects early inrequirements modeling, which resulted in the incorporation of use cases, in one form oranother, as a front end to the different OOA methods. Now the use case notations arepart of the OO standard Unified Modeling Language (UML) (Rational Software Corpo-ration, 1999). Although the use case technique is gaining in popularity for handlingrequirements within OO methods, its use for handling the requirements of embeddedsoftware systems still is immature. Several limitations have been identified for the usecase notations and their pragmatics in the literature. Research is going on to provideviable solutions to minimise practical confusion by, for example, enhancing the defini-tions of the use case technique’s constructs and introducing necessary new concepts,especially for the domain of embedded software systems (Nasr et al., 2002).

Formal Methods for Embedded Systems

Formal methods are often proposed for RE of embedded software systems to attempt toproduce precise, complete, unambiguous, and consistent requirements specifications(Macaulay, 1996). Most of the RE formal methods found in the literature are actuallyspecification languages rather than complete RE processes, for example Soft CostReduction (SCR) (Heitmeyer, Kirby, & Labaw, 1998; Heninger, 1980), Albert II (Du-Bois,Dubois, & Zeippen, 1997), and Requirements State Machine Language (RSML) (Leveson,Heimdahl, Hilldreth, & Reese, 1994). Although it is thought that producing formalrequirements specifications forces the stakeholders, especially the Requirements Engi-neer, to think more carefully about the nature of the system being defined and how exactlyit will operate, it cannot guarantee complete requirements. There will still exist some tacit(unstated) requirements.The use of formal specification techniques are steadily increasing because they areusually complemented by a wide variety of analysis tools for model checking, verifica-tion, and animation. Despite that there are several challenges for the use of current formal



methods for requirements, which include (Gray & Thayer, 1991; Hall, 1997; Hsia, Davis,& Kung, 1993; Krishna & Shin, 1997):

• Communication. Not all stakeholders find it easy to follow or understand formalnotations. That’s why in some formal requirements specification methods, forexample, Albert II (Du-Bois et al., 1997), and Hard Real-Time Hierarchical Object-Oriented Requirements Analysis (HRT-HOORA) (Piveropoulos, 2000), the formalnotations specifying a requirement have to be accompanied by the natural lan-guage requirement to achieve better communication with the stakeholders andquicker requirements validation. This adds to the volume of the requirementsspecification documents, especially for large complex systems.

• Expressiveness. Most if not all of the current formal notations are incapable ofexpressing all aspects of the domain, for example, NFRs such as reliability, safety,performance, and human factors.

Conclusion

Developing large, complex embedded software systems requires a deep understandingof their essential properties. In this chapter we attempted to promote a deeper under-standing of this special category of software systems by presenting some of their specialcharacteristics. Then we discussed the main challenges that these special propertiespose for RE of this special type of software systems. Finally we highlighted the maincurrent RE approaches for the domain and some of their current weaknesses. We believethat the many issues we raised in this chapter are crucial for understanding RE for thedomain of embedded software systems, which is important for improving RE of embeddedsoftware systems in the future.

References

Bailin, S.C. (1989). An object-oriented requirements specification method. Communica-tions of the ACM, 32(5), 608-623.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering.IEEE Computer, 20(4), 10-19.

Chonoles, M.J., & Quatrani, T. (1996). Succeeding with the booch and OMT methods:A practical approach. Addison-Wesley.

Davis, A. (1993). Software requirements: Objects, functions and states. NJ: Prentice-Hall.

Davis, A.M. (1990). Software requirements: Analysis and specification. Prentice-Hall.

34 Nasr


Du-Bois, P., Dubois, E., & Zeippen, J.M. (1997). On the use of a formal RE language.Proceedings of the Third IEEE International Symposium on Requirements Engi-neering, January, 128-137.

Faulk, S.R. (1995). Software requirements: A tutorial. (MR 7775). Washington, DC: NavalResearch Laboratory.

Graham, I. (1995). Migrating to object technology. Addison-Wesley.Gray, E.M., & Thayer, R.H. (1991). Requirements. In C. Anderson & M. Dorfman (Eds.),

aerospace software engineering: A collection of concepts. (pp. 89-122). TheAmerican Institute of Aeronautics and Astronautics.

Hall, A. (1997). What’s the use of requirements engineering? Proceedings of The ThirdIEEE International Symposium on Requirements Engineering, January, 2-3.

Hatley, D.J., & Pirbhai, I. A. (1987). Strategies for real-time system specification. NewYork: Dorest House.

Heimdahl, M.P.E., & Leveson, N. G. (1996). Completeness and consistency in hierarchicalstate-based requirements. IEEE Transactions on Software Engineering, 22(6),363-75.

Heitmeyer, C. (1997). Welcome from the general chair. Proceedings of The Third IEEEInternational Symposium on Requirements Engineering, January, vii-ix.

Heitmeyer, C., Kirby, J., & Labaw, B. (1998). Applying the SCR requirements method toa weapons control panel: An experience report. Proceedings of Formal Methodsin Software Practice.

Heninger, K.L. (1980). Specifying Software Requirements for Complex Systems: NewTechniques and Their Application. IEEE Transactions on Software Engineering,6(1), 2-12.

Hofmann, H.F. (1993). Requirements engineering: A survey of methods and tools. (Tech.Rep. No. 93.05). Institute fur Informatik der Universitat Zurich.

Hruschka, P. (1992). Requirements engineering for real-time and embedded systems. InM. Schiebe & S. Pferrer (Eds.), Real-Time Systems: Engineering and Applications.Kluwer Academic Publishers.

Hsia, P., Davis, A., & Kung, D. (1993). Status report: Requirements engineering. IEEESoftware, 10(6), 75-79.

Jacobson, I. (1996, May). Succeeding with objects: A large commercial success storybased on objects. Object Magazine, 8.

Jacobson, I., Christerson, M., Jonsson, P., & Oevergaard, G. (1992). Object orientedsoftware engineering: A use case driven approach. Addison-Wesley.

Knight, J.C. (2002). Safety-critical systems: challenges and directions, invited mini-tutorial. Proceedings of ICSE’2002: 24th International Conference on SoftwareEngineering, 547-550.

Krishna, C.M., & Shin, K.G. (1997). Real-time systems. McGraw-Hill.Leveson, N.G. (1995). Safeware: System safety and computers. Addison-Wesley.Leveson, N.G., Heimdahl, M. P. E., Hilldreth, H., & Reese, J.D. (1994). Requirements

specification for process-control systems. IEEE Transactions on Software Engi-



neering, 20(9).Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering. McGraw

Hill.Lubars, M., Potts, C., & Richter, C. (1993). A review of the state of the practice in

requirements modeling. Proceedings of The First IEEE International Symposiumon Requirements Engineering, January, 2-14.

Lutz, R.R. (1993). Analyzing software requirements errors in safety-critical, embeddedsystems. Proceedings of The First IEEE International Symposium on Require-ments Engineering, January, 126-133.

Macaulay, L.A. (1996). Requirements engineering. Springer Verlag.McDermid, J. (1993). Issues in the development of safety-critical systems. In F.J. Redmill

& T. Anderson (Eds.), Safety-critical systems: Current issues, techniques andstandards. Chapman & Hall.

Nasr, E. et al. (2002). Eliciting and specifying requirements with use cases for embeddedsystems. Proceedings of the Seventh IEEE International Workshop on Object-oriented Real-time Dependable Systems (WORDS).

Piveropoulos, M. (2000). Requirements engineering for hard real-time systems. D.Phil,University of York.

Rational Software Corporation. (1999, March). Unified modeling language specifica-tion. (vol. 1.3). Rational Software Corporation. Available: http://www.rational.com/uml.

Selic, B., Gullekson, G., & Ward, P.T. (1994). Real-time object-oriented modeling. JohnWiley & Sons.

Shlaer, S., & Mellor, S. J. (1988). Object-oriented systems analysis: Modeling the worldin data. New Jersey: Prentice-Hall.

Society of Automotive Engineers. (1994). Certification considerations for highly-integrated or complex aircraft systems. (ARP 4754). Society of AutomotiveEngineers.

Sommerville, I., & Sawyer, P. (1997). Requirements engineering: A good practice guide.John Wiley & Sons.

Svoboda, C.P. (1997). Structured analysis. In R.H. Thayer & M. Dorfman (Eds.), Softwarerequirements engineering (pp. 303-22). IEEE Computer Society.

Ward, P.T. (1989). How to integrate object-orientation with structured analysis anddesign. IEEE Software, 6, 74-82.

Ward, P.T., & Mellor, S.J. (1985). Structured development for real-time systems Vol. 1:Introduction & tools. Prentice-Hall.

Weber, M., & Weisbrod, J. (2003). Requirements engineering in automotive develop-ment: experiences and challenges. IEEE Software, (January/February), 16-24.

Wieringa, R.J. (1996). Requirements engineering: Frameworks for understanding.Springer Verlag.

Wieringa, R.J. (1998). Advanced structured and object-oriented requirements specifica-tion methods. Proceedings of Third IEEE International Conference on Require-

36 Nasr


ments Engineering - Tutorial Notes.Zave, P. (1995). Classification of research efforts in requirements engineering. Proceed-

ings of The Second IEEE International Symposium on Requirements Engineering,March, 214-6.

Requirements Elicitation for Complex Systems: Theory and Practice 37


Chapter III

RequirementsElicitation for

Complex Systems:Theory and Practice

Chad Coulin, University of Technology Sydney, Australia

Didar Zowghi, University of Technology Sydney, Australia

Abstract

This chapter examines requirements elicitation for complex systems from a theoreticaland practical perspective. System stakeholders, requirements sources, and the qualityof requirements are presented with respect to the process, including an investigationinto the roles of requirements engineers during elicitation. The main focus of thechapter is a review of existing requirements elicitation techniques and a survey ofcurrent trends and challenges. It is concluded with some views on the future directionof requirements elicitation in terms of research, practice and education. It is theintention of the authors that readers of this chapter will be sufficiently informed on theconcepts, techniques, trends, and challenges of requirements elicitation to then applythis knowledge to system development projects in both industrial and academicenvironments.

38 Coulin and Zowghi


Introduction

If elicitation is considered the initial phase in requirements engineering, then it can alsobe regarded as the first stage of system development. It is at this point in the processwhere the needs of the users and the goals for the system are determined. Despite itsobvious importance to the development of systems, requirements elicitation has onlyreceived significant attention in research and practice over the past decade or so.Although seen as a fundamental part of the system development process, requirementselicitation is often considered a major problem area in projects for computer-basedsystems. Eliciting requirements for complex systems is a difficult and expensive process,and consequently a key issue in software and systems engineering. As part of essentiallya social activity, the issues and challenges associated with requirements elicitationcannot be addressed by technical solutions alone. It is for these reasons that a structuredand rigorous approach must be employed for this activity.In practice requirements elicitation is a multifaceted, incremental, and iterative processthat relies heavily on the capabilities of requirements engineers, and the commitment andcooperation of stakeholders. The type of system to be developed and its intendedpurpose will have a significant effect on the way in which this task is conducted. Thespecific techniques used to elicit requirements during a project will often depend on anumber of additional factors, including time, cost, and the availability of resources.In this chapter we will examine requirements elicitation for complex systems from atheoretical and practical perspective. It is intended, through a review of existing theoryand an assessment of current practice, readers will be sufficiently informed of thetechniques, approaches, trends, and challenges in requirement elicitation to then be ableto apply this knowledge to system development projects in industrial or academicenvironments.

Background

The elicitation of requirements can be broadly defined as the acquisition of goals,constraints, and features for a proposed system by means of investigation and analysis.Furthermore it is generally understood that requirements are elicited rather than capturedor collected (Goguen, 1996). This implies both a discovery and development element tothe process.Requirements can be elicited from a variety of sources using a range of differenttechniques and approaches. Invariably the system should be defined in terms of theoperations it must perform, referred to as functional requirements, and the non-functionalaspects of the system, such as performance and maintainability. In all projects it isimportant that during this process both the problem and solution domains are thoroughlyexamined (Jackson, 1995). By this it is meant that the goals for the system must beinvestigated as well as the options available to satisfy them.



Although in this chapter we are primarily concerned with the development of sociotechnicalsystems, in practice the role of the requirements engineer during elicitation, also knowas the analyst, can be performed in a number of different project settings (Hickey & Davis,2003) including:

• The development of customised systems for specific customers• The development of commercial off-the-shelf (COTS) products• The evaluation and selection of alternative systems• The implementation of large and complex systems

Target System Stakeholders

The elicitation of requirements is based around the process of describing a future ortarget system. All parties involved and affected, directly or indirectly, by the develop-ment and implementation of the target system are known as stakeholders. Typicallystakeholders include groups and individuals internal and external to the organization.The needs of these stakeholders will be different, as will be the way in which they expressthem. It is critical for successful requirements elicitation that all the target systemstakeholders are involved in the process from an early stage.The customer, and more specifically the project sponsor, is usually the most apparentstakeholder of the system. In some cases, however, the actual users of the system maybe the most important. Managers of departments containing users must also be consid-ered stakeholders, even if they are not directly users of the system themselves. Otherparties whose sphere of interest may extend to some part of the target system operations,such as those responsible for work process standards, customers, and partners, shouldalso be regarded as stakeholders if affected. An often-forgotten group of stakeholdersin system development projects are the developers themselves, including designers,programmers, testers, and implementation consultants.

Sources of Requirements

With any system development project there is a number of possible sources forrequirements. Stakeholders represent the most obvious source of determining require-ments for the target system. Subject matter experts are used to supply detailed informa-tion about the problem and solution domains. Active systems and processes representanother source for eliciting requirements, particularly when the project involves replac-ing an existing legacy system. Documentation on the current systems, processes,organization, and environment can provide a detailed foundation of requirements andsupporting rationale.



Quality of Requirements

The success of a system is heavily dependent on the quality of the requirements usedfor its development. This can be expressed in terms of the correctness, completeness,consistency, and clarity of the elicited requirements (Davis, 1994). Other commonly usedquality attributes for requirements include their relevance to the scope of the project, theextent to which they are feasible given the constraints of the project, and the ability totrace their source and rationale. It is also important that requirements are stated in sucha way as they can be tested or measured to determine their quality and if they have beenfulfilled (Lauesen, 2002).

The Requirements Elicitation Process

It is important to remember at this point that the process of system development, andtherefore requirements elicitation, does not occur in a vacuum. It is strongly related tothe context in which it is conducted and specific characteristics of the project, organi-zation, and environment (Christel & Kang, 1992). In practice the budget and schedule ofthe project have a significant effect on the process and the way in which it is performed.The structure and maturity of the organization will determine how requirements areelicited, as will the way in which the target system will interact with users and othersystems. The level of volatility within a project must also be considered, as this will affectdirectly the quality of requirements and the elicitation process itself.Typically the process begins with an informal and incomplete high-level missionstatement for the project. This may be represented as a set of fundamental goals,functions, and constraints for the target system, or as an explanation of the problems tobe solved. In order to develop this description, stakeholders and other sources ofrequirements are identified and used for elicitation. These preliminary results form thebasis of further investigation and refinement of requirements.Over the years a number of process models have been proposed for requirementselicitation (Constantine & Lockwood, 1999; Kotonya & Sommerville, 1998; Sommerville& Sawyer, 1997). For the most part these models provide only a generic roadmap of theprocess with sufficient flexibility to accommodate the basic contextual differences ofindividual projects. The inability of these models to provide definitive guidelines is aresult of the wide range of activities that may be performed during requirementselicitation, and the sequence of those activities depending on specific project circum-stances. The variety of issues that may be faced, and the number of techniques availableto use, only adds to this complexity.In most cases the process of requirements elicitation is performed incrementally overmultiple sessions, iteratively to increasing levels of detail, and at least partially in parallelwith other system development activities such as modeling and analysis. In reality itsconclusion is often determined as a result of time and cost constraints rather thanachieving the required level of quality for the requirements. Typically the result of thisprocess is a detailed set of requirements in natural language text and simple diagrammaticrepresentations describing the sources, priorities, and rationales.



Requirements Elicitation Techniques

The following section details some of the more widely used requirements elicitationtechniques for the development of sociotechnical systems. This selection is by no meanscomplete; however it is representative of the range of available techniques described inthe literature and performed in practice. It is generally accepted that no one techniqueis suitable for all projects. The choice of techniques to be employed is dependent on thespecific context of the project and is often a critical factor in the success of the elicitationprocess (Nuseibah & Easterbrook, 2000).

Questionnaires

Questionnaires are mainly used during the early stages of requirements elicitation. Forthem to be effective, the terms, concepts, and boundaries of the domain must be wellestablished and understood by the participants and questionnaire designer. Questionsmust be focused to avoid gathering large amounts of redundant and irrelevant informa-tion. They provide an efficient way to collect information from multiple stakeholdersquickly but are limited in the depth of knowledge they are able to elicit. Questionnaireslack the opportunity to delve further on a topic or expand on new ideas. In the same way,they provide no mechanism for the participants to request clarification or correctmisunderstandings. Generally questionnaires are considered more useful as informalchecklists to ensure fundamental elements are addressed early on and to establish thefoundation for subsequent elicitation activities.

Interviews

Interviews are probably the most traditional and commonly used technique for require-ments elicitation. Because interviews are essentially human-based social activities, theyare inherently informal and their effectiveness depends greatly on the interactionbetween the participants. There are fundamentally two types of interviews: unstructuredand structured.Unstructured interviews are conversational in nature where the interviewer enforcesonly limited control over the direction of discussions. Because they do not follow apredetermined agenda or list of questions, there is the risk that some topics may becompletely neglected. It is also a common problem with unstructured interviews to focusin too much detail on some areas and not enough in others (Maiden & Rugg, 1996). Thistype of interview is best applied when there is a limited understanding of the domain oras a precursor to more focused and detailed structured interviews.Structured interviews are conducted using a predetermined set of questions to gatherspecific information. The success of structured interviews depends on knowing the rightquestions to ask, when should they be asked, and who should answer them. Templatesthat provide guidance on structured interviews for requirements elicitation such asVolere (Robertson & Robertson, 1999) can be used to support this technique. Although



structured interviews tend to limit the investigation of new ideas, they are generallyconsidered to be rigorous and effective.Like questionnaires, interviews provide an efficient way to collect large amounts of dataquickly. The results, however, can vary significantly depending on the skill of theinterviewer and consequently the usefulness of the information gathered (Goguen &Linde, 1993).

Group Work

Group work is a well-established and often-used technique in requirements elicitation.The most common forms of this technique include brainstorming and Joint ApplicationDevelopment (JAD) as described below.Brainstorming involves participants from different stakeholder groups engaging ininformal discussion to rapidly generate as many ideas as possible without focusing onany one in particular. It is important when conducting this type of group work to avoidexploring or critiquing ideas in great detail. It is not usually the intended purpose ofbrainstorming sessions to resolve major issues or make key decisions. This techniqueis often used to develop the preliminary mission statement for the project and targetsystem. One of the advantages in using brainstorming is that it promotes freethinkingand expression, and allows the discovery of new and innovative solutions to existingproblems.JAD (Wood & Silver, 1995) involves all the available stakeholders investigating throughgeneral discussion both the problems to be solved and the available solutions to thoseproblems. With all parties represented, decisions can be made rapidly and issuesresolved quickly. A major difference between JAD and brainstorming is that typically themain goals of the system have already been established before the stakeholdersparticipate in JAD sessions.Group work is often performed using support materials such as documents, diagrams, andprototypes to promote discussion and feedback. This technique encourages stakehold-ers to resolve conflicts and develop solutions themselves, rather than relying on theanalyst to drive the process. Group work sessions can be difficult to organize due to thelarge number of different stakeholders who may be involved in the project. Managingthese sessions effectively requires both expertise and experience to ensure that indi-vidual personalities do not dominate the discussions. A key factor in the success ofgroup work is the makeup of participants. Stakeholders must feel comfortable andconfident in speaking openly and honestly. It is for this reason that group work is lesseffective in highly political situations.

Card Sorting

Card sorting requires the stakeholders to sort a series of cards containing the names ofdomain entities into groups according to their own understanding. Furthermore thestakeholder is required to explain the rationale for the way in which the cards are sorted.



It is important for effective card sorting that all entities are included in the process. Thisis possible only if the domain is sufficiently understood by both the analyst and theparticipants. If the domain is not well established, then group work can be used to identifysystem entities. This technique is typically used more for the categorization andclarification of requirements. Class Responsibility Collaboration (CRC) cards (Beck &Cunningham, 1989) are a derivative of card sorting that is also used to determine programclasses in software code. In this technique cards are used to assign responsibilities tousers and components of the system. Because entities represent such a high level ofsystem abstraction, the information obtained from this technique is limited in its detail.

Laddering

When using laddering (Hinkle, 1965) stakeholders are asked a series of short promptingquestions, known as probes, and required to arrange the resultant information into anorganized hierarchical structure. For this technique to be effective, stakeholders must beable to express their understanding of the domain and arrange that knowledge in a logicalway. Like card sorting, laddering is mainly used as a way to clarify requirements andcategorize domain entities.

Repertory Grids

Repertory grids (Kelly, 1955) involve asking stakeholders to develop attributes andassign values to a set of domain entities. As a result the system is modeled in the formof a matrix by categorizing the elements of the system, detailing the instances of thosecategories, and assigning variables with corresponding values to each one. The aim isto identify and represent the similarities and differences between the different domainentities. These represent a level of abstraction unfamiliar to most users. As a result thistechnique is typically used when eliciting requirements from domain experts. Althoughmore detailed than card sorting, and to a lesser degree laddering, repertory grids aresomewhat limited in their ability to express specific characteristics of complex require-ments.

Task Analysis, Scenarios and Use Cases

Task analysis, scenarios, and use cases are alike in that they all describe to some degreethe series of actions and events the system and users perform during operation; however,they are different in their focus and usage. Unlike scenarios and use cases, task analysisemploys a top-down approach where high-level tasks are decomposed into subtasksuntil all actions and events are detailed. In particular the diagrammatic and tabularrepresentations of use cases (Cockburn, 2001) make them easy to understand and flexibleenough to accommodate context-specific information. Use cases can be reused later inthe development process to determine components and classes during system designand when creating test cases. These techniques are especially effective in projects where



there is a high level of uncertainty or when the analyst is not an expert in that particulardomain. A disadvantage of using task analysis, scenarios, and use cases is the amountof effort and detail required to define the steps and sequences for all possible processcombinations.

Protocol Analysis

Protocol analysis is where participants perform an activity or task while talking it throughaloud, describing the actions being conducted and the thought process behind them.This technique can provide the analyst with specific information on the actual processesthe target system must support (McGraw & Harbison-Briggs, 1989). In most cases,however, talking through an operation is not the normal way of performing the task andas a result may not necessarily represent the true process completely or correctly.Likewise minor steps performed frequently and repetitively are often taken for grantedby the users and may not be explained and subsequently recorded as part of the process.

Ethnography

Ethnography involves the analyst overtly or covertly participating in the normalactivities of the users over an extended period of time whilst collecting information onthe operations being performed. Observation is one of the more widely used ethno-graphic techniques. As the name suggests, the analyst observes the actual execution ofexisting processes by the users without direct interference. This technique is often usedin conjunction with others such as interviews and task analysis. As a general ruleethnographic techniques are very expensive to perform and require significant skill andeffort on the part of the analyst to interpret and understand the actions being performed.The effectiveness of observation and other ethnographic techniques can vary as usershave a tendency to adjust the way they perform tasks when knowingly being watched.Despite this, these techniques are especially useful when addressing contextual factorssuch as usability and when investigating collaborative work settings where the under-standing of interactions between different users with the system is paramount. Inpractice ethnography is particularly effective when the need for a new system is a resultof existing problems with processes and procedures.

Prototyping

Providing stakeholders with prototypes of the system to support the investigation ofpossible solutions is an effective way to gather detailed information and relevantfeedback. Prototypes are typically developed using preliminary requirements or existingexamples of similar systems. This technique is particularly useful when developinghuman-computer interfaces or when the stakeholders are unfamiliar with the availablesolutions. There are a number of different methods for prototyping systems with varyinglevels of effort required. In many cases they are expensive to produce in terms of time



and cost. An advantage of using prototypes is that they encourage stakeholders, andmore specifically the users, to play an active role in developing the requirements.Prototypes are extremely helpful when developing new systems for entirely new appli-cations.

Roles of the Requirements Engineer

In this section the various roles that may be required of analysts performing requirementselicitation for complex systems are examined. It is important to note that analysts may notnecessarily carry out all these roles within all projects. The responsibilities are dependenton the project and the context in which it is conducted.

Manager

A fundamental part of requirements engineering is related to project management.Analysts must manage the process of requirements elicitation and communicate iteffectively to the system stakeholders. This activity involves more than the obviousdecision-making and prioritization tasks. Analysts are often required to initiate meetingswith stakeholders, produce status reports, and remind stakeholders of their responsibili-ties. In many cases the analyst is the primary contact for questions from stakeholdersrelating to the project, the process, and the target system.

Analyst

A large part of elicitation involves analyzing not just the processes that the target systemmust support but also the requirements themselves. Analyst must translate and interpretthe needs of stakeholders in order to make them understandable to the other stakehold-ers. Requirements are then organized in relation to each other and given meaning withrespect to the target system. Often analysts are required to use a certain amount ofintrospection when eliciting requirements, especially when stakeholders are not able toexpress their needs clearly or are unfamiliar with the available solutions.

Facilitator

When eliciting requirements by conducting interviews or group work sessions, theanalyst is not only required to ask questions and record the answers but must guide andassist the participants in addressing the relevant issues in order to obtain correct andcomplete information. The analyst is also responsible for ensuring that participants feelcomfortable and confident with the process and are given sufficient opportunity tocontribute. It is important for the analyst to encourage stakeholders to express their



needs in terms of requirements that can be validated and verified and understood by otherstakeholders.

Mediator

During elicitation conflicts between requirements and stakeholders are inevitable. Inmany cases the prioritization of requirements from different stakeholders groups is asource of much debate and dispute. When these situations occur the analyst is oftenresponsible for finding a suitable resolution through negotiation and compromise. It isimportant that the analyst is sensitive to all the political and organizational aspects ofthe project when mediating discussions related to the target system.

Developer

Analysts are often required to assume the various roles of the developer communityduring requirements elicitation. This includes system architects, designers, program-mers, testers, quality assurance personnel, implementation consultants, and systemmaintenance administrators. Mainly this is a result of these stakeholders not yet beinginvolved in the project at the requirements elicitation stage. Despite this, decisions madeduring this phase of the project will affect significantly these stakeholders and thesubsequent phases of system development.

Documenter

More often than not the analyst is responsible for the output of the elicitation process.Typically this takes the form of a requirements document or detailed system model. Thisrole is particularly important, as it represents the results of the elicitation process andforms the foundation for the subsequent project phases. Evaluation of the elicitationprocess and the work performed by the analyst is based on these resultant artifacts,which in some cases may form the basis of contractual agreements.

Validator

All the requirements elicited must be validated and verified against each other, thencompared with previously established goals for the system. By this it is meant that therequirements describe the desired features of the system appropriately and that thoserequirements will provide the necessary functions in order to fulfill the specifiedobjectives of the target system. This process typically involves all the identifiedstakeholder groups and results in further elicitation activities.



Challenges of Requirements Elicitation

The process of eliciting requirements is critical to system development but oftenoverlooked or only partially addressed. This may be a result of it being one of the mostdifficult and least understood activities. Below are some of the more commonly experi-enced issues, challenges, and pitfalls of requirements elicitation:

• The initial scope of the project is not sufficiently defined and as such is open tointerpretations and assumptions.

• Stakeholders do not know what their real needs are and are therefore limited in theirability to support the investigation of the solution domain.

• Stakeholders are not able to adequately communicate their needs. This does notnecessarily mean that the stakeholders do not know what they want.

• Stakeholders do not understand or appreciate the needs of other stakeholders.Users may only be concerned with those factors that affect them directly.

• Stakeholders understand the problem domain but are unfamiliar with the availablesolutions and the way in which their needs could be met.

• Stakeholders often assume and therefore overlook those things that are trivial intheir daily lives. These may not be apparent to the analyst and other stakeholders.

• The analyst is unfamiliar with the problem or solution domains and does notunderstand the needs of the users and the processes to be addressed.

• The analysts and stakeholders do not share a common understanding of theconcepts and terms in the domain.

• Conflicts between stakeholders and requirements are common. For example theneeds of the users may not be consistent with the goals of the project sponsors.

• Stakeholders exhibit varying levels of cooperation and commitment to the project.Partial participation compromises the quality of requirements. This may be as aresult of resistance to change that a new system may introduce.

• Because the process of elicitation is very informal by nature, requirements may beincorrect, incomplete, inconsistent, and not clear to all stakeholders.

• Requirements generated by stakeholders can be vague, lacking specifics, and notrepresented in such a way as can be measured or tested.

• Analysts are not equipped with sufficient expertise and experience to performeffective requirements elicitation. Novice analysts may overlook a source ofrequirements or fail to identify and involve all the necessary stakeholders.

• Only very limited guidelines and tool support exist for the process of requirementselicitation.

• Requirements and the context in which they are elicited are inherently volatile. Asthe project develops and stakeholders become more familiar with the problem andsolution domains, the goals and needs of the target system are susceptible tochange. In this way the volatility is actually a result of the elicitation process itself.



Additional social and technical issues may be found when developing extremely largeand complex systems where the number of stakeholders and the volume of requirementscan become unmanageable.

Trends for Requirements Elicitation

In reality the number of different factors that must be taken into consideration whenperforming requirements elicitation prohibits a definitive technique or method for allprojects. The experience and expertise of the analyst, time and cost constraints, volatilityof the scope, and the context in which the project is conducted all have significantinfluence on the way in which the process is performed. Despite this obvious complexity,some approaches have proved effective in overcoming many of the issues oftenassociated with requirements elicitation.

Viewpoints

Viewpoint approaches aim to model the domain from different perspectives in order todevelop a complete and correlated description of the target system. For example a systemcan be described in terms of its operation, implementation and interfaces. In the same waysolutions can be modeled from the standpoints of different users or from the position ofrelated systems. These types of approaches are particularly effective for projects wherethe system entities have detailed and complicated relationships with each other. Onecommon criticism of viewpoint approaches is that they do not enable non-functionalrequirements to be represented easily and are expensive to use in terms of the effortrequired.Most viewpoint approaches (Nuseibeh, Finkelstein, & Kramer, 1996; Sommerville,Sawyer, & Viller, 1998) provide a flexible multi-perspective model for systems, usingdifferent viewpoints to elicit and arrange requirements from a number of sources. Usingthese approaches, analysts and stakeholders are able to organize the process and derivedetailed requirements for a complete system from multiple project-specific viewpoints.

Goal Based

Goal-based approaches for requirements elicitation have become increasingly popularin both research and practice environments. The fundamental premise of these ap-proaches is that high-level goals that represent objectives for the target system aredecomposed into sub goals and then further refined in such a way that individualrequirements are developed. The result of this process is significantly more complicatedand complete than the traditional method of representing system goals using treestructure diagrams. These approaches are able to represent detailed relationshipsbetween system entities and requirements. One of the risks when using goal-based



approaches and goal decomposition in general is that errors in the high-level goals ofthe system made early on in the process can have a major and detrimental follow on effect.In recent times significant effort has been devoted to developing these types ofapproaches for requirements elicitation (Dardenne, van Lamsweerde & Fickas, 1993; Yu,1997). The use of goals in conjunction with scenarios to elicit requirements has alsoattracted considerable attention (Haumer, Pohl, & Weidenhaupt, 1998; Potts, Takahashi,& Anton, 1994). In practice, these approaches have been particularly useful in situationswhere only the high-level needs for the system are well known and there exists a generallack of understanding about the specific details of the problems to be solved and theirpossible solutions.

Domain Based

Domain knowledge in the form of guidelines and examples play an important part in theprocess of requirements elicitation. Approaches based on this type of information areoften used in conjunction with other elicitation techniques. Analysts use previousexperience in similar domains as a template for group work and interviews. Analogies andabstractions of existing problem domains can be used as baselines to acquire detailedinformation, identify and model possible solution systems, and assist in creating acommon understanding between the analyst and stakeholders. These approaches alsoprovide the opportunity to reuse specifications and validate new requirements againstother domain instances (Sutcliffe & Maiden, 1998).

Combinational Approaches

It is widely accepted that by using a combination of complimentary elicitation techniquesmany of the issues commonly associated with this process can be avoided or at leastminimized. In practice the selection of techniques used during a project is more oftendetermined by the experience and expertise of the analyst rather than their appropriate-ness to the specific situation. Consideration should be given to the types of stakeholdersinvolved in the process, the information that needs to be elicited, and the stage ofelicitation efforts in the project. Along these lines attempts have been made to developand validate a set of tentative relationships between the characteristics of a project andthe methods to be used as a guideline for selecting technique combinations (Hickey &Davis, 2003; Maiden & Rugg, 1996).One approach of combining techniques suggests that the process can begin with anethnographic study to discovery fundamental aspects of existing patterns and behavior,followed by structured interviews to gain deeper insight into the needs of the stakehold-ers and the priorities of requirements (Goguen & Linde, 1993). Furthermore it is proposedthat the more expensive requirements elicitation techniques are used to examine in greaterdetail those needs deemed important.



Future Directions

Research

So far relatively little research has been devoted to the process of requirements elicitationfor complex systems. More work is needed to establish guidelines for the application oftechniques and provide tool support for the various tasks that make up the process.Comprehensive empirical research, detailed case studies, and in-depth experiencereports are required to supply the necessary historical information in order to producethese outcomes. Additional efforts also should be directed toward developing graphicalapproaches and integration of the traditional aspects of requirements elicitation withthose methods used during validation and verification.

Practice

As a result of shorter schedules and tighter budgets, analysts in industry are being askedto do substantially more with significantly less. The increasing complexity of systemstoday, and the speed at which new technologies are introduced to the market, onlycompound this situation. Organizations are placing greater demands on these newsystems than at any other time. Consequently analysts are in need of practical techniquesthat are easy to use and provide them with quality requirements in less time at a reducedcost. Agile methods related to system specification have recently received considerableattention and approval in response to this demand. Furthermore approaches that allowrequirements to be reused in multiple projects and for other phases in the developmentprocess are attractive for the same reasons. As stakeholders become familiar withcomplex systems through their everyday lives, their ability to express requirements fornew systems will improve, and the expectations on those systems will continue toincrease.

Education

Experience is often the major difference between novice and expert requirementsengineers. Given this, it is appropriate that the education of future analysts should placea stronger emphasis on gaining practical experience in real-world situations. Role-playing activities and industrial placement can provide the required learning environ-ment for analysts to prepare for industry and develop the social skills necessary toconduct requirements elicitation for complex systems.



Conclusion

It is obvious that requirements elicitation is a complex process. This is made certain bythe numerous activities that make up the process and the variety of ways those activitiescan be performed. The tasks required and the issues faced are dependent on a wide rangeof potentially changing contextual factors specific to the situation. As a result theconditions under which requirements elicitation is performed are never exactly the same.Effective elicitation of requirements is largely dependent on the expertise of the analyst,the utilization of techniques, and the support of the stakeholders. Analysts are requiredto apply a wide range of skills, knowledge, and experience throughout the process. Theselection and execution of techniques needs to be complementary and customized to thespecific project. Stakeholders must work together with the analyst to address the socialand technical aspects of the system.To this day requirements elicitation represents one of the most poorly executed activitiesand major challenges in system development. Consequently it is important for thesuccess of future projects that new and innovative ways of conducting this process, andsupporting the participants, continue to be investigated and examined.

References

Beck, K., & Cunningham, W. (1989). A laboratory for teaching object-oriented thinking.Proceedings of OOPSLA ’89, New Orleans, LA.

Christel, M.G., & Kang, K.C. (1992). Issues in requirements elicitation. Pittsburgh, PA:Carnegie Mellon University.

Cockburn, A. (2001). Writing effective use cases. Reading, MA: Addison-Wesley.Constantine, L., & Lockwood, L.A.D. (1999). Software for use: A practical guide to the

models and methods of usage-centered design. Reading, MA: Addison-Wesley.Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirements

acquisition. Science of Computer Programming, 20.Davis, A. M. (1994). Software requirements: Analysis and specification. NJ: Prentice-

Hall.Goguen, J.A. (1996). Formality and informality in requirements engineering. Proceedings

of the IEEE International Conference on Requirements Engineering, ColoradoSprings, CO.

Goguen, J.A., & Linde, C. (1993). Techniques for requirements elicitation. Proceedingsof the IEEE International Symposium on Requirements Engineering, San Diego,CA.

Haumer, P., Pohl, K., & Weidenhaupt, K. (1998). Requirements elicitation and validationwith real world scenes. IEEE Transactions on Software Engineering, 24(12).



Hickey, A.M., & Davis, A.M. (2003). Elicitation technique selection: How do experts doit? Proceedings of the IEEE International Requirements Engineering Confer-ence, Monterey Bay, CA.

Hinkle, D. (1965). The change of personal constructs from the viewpoint of a theory ofimplications. (Doctoral dissertation, Ohio State University, 1965).

Jackson, M. (1995). Software requirements and specifications: A lexicon of practice,principles and prejudices. Great Britain: Addison-Wesley.

Jirotka, M., & Goguen, J. (Eds.) (1994). Requirements engineering: Social and technicalissues. London: Academic Press.

Kelly, G. (1955). The psychology of personal constructs. New York: Norton.Kotonya, G., & Sommerville, I. (1998). Requirements engineering: Processes and

techniques. Great Britain: John Wiley & Sons.Lauesen, S. (2002). Software requirements: Styles and techniques. Great Britain: Addison-

Wesley.Maiden, N.A.M., & Rugg, G. (1996). ACRE: Selecting methods for requirements acqui-

sition. Software Engineering Journal, 11(3).McGraw, K.L., & Harbison-Briggs, K. (1989). Knowledge acquisition: Principles and

guidelines. New Jersey: Prentice-Hall.Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: A roadmap. Proceed-

ings of the conference on The Future of Software Engineering, Limerick, Ireland.Nuseibeh, B., Finkelstein, A., & Kramer, J. (1996). Method engineering for multi-

perspective software development. Information and Software Technology Jour-nal, 38(4).

Potts, C., Takahashi, K., & Anton, A.I. (1994). Inquiry-based requirements analysis.IEEE Software, 11(2).

Robertson, S., & Robertson, J. (1999). Mastering the requirements process. Great Britain:Addison-Wesley.

Sommerville, I., & Sawyer, P. (1997). Requirements engineering: a good practice guide.Great Britain: John Wiley & Sons.

Sommerville, I., Sawyer, P., & Viller, S. (1998). Viewpoints for requirements elicitation: apractical approach. Proceedings of the IEEE International Conference on Re-quirements Engineering, Colorado Springs, CO.

Sutcliffe, A., & Maiden, N. (1998). The domain theory for requirements engineering. IEEETransactions on Software Engineering, 24(3).

Wood, J., & Silver, D. (1995). Joint application development. New York: John Wiley &Sons.

Yu, E.S.K. (1997). Towards modeling and reasoning support for early-phase require-ments engineering. Proceedings of the IEEE International Symposium on Re-quirements Engineering, Washington, D.C.

Conceptual Modeling in Requirements Engineering 53


Chapter IV

Conceptual Modelingin Requirements

Engineering:Weaknesses and

AlternativesJavier Andrade Garda, University of A Coruña, Spain

Juan Ares Casal, University of A Coruña, Spain

Rafael García Vázquez, University of A Coruña, Spain

Santiago Rodríguez Yáñez, University of A Coruña, Spain

Abstract

This chapter focuses on software engineering conceptual modeling, its currentweaknesses, and the alternatives to overcome them. It is clear that software quality hasits genesis in the conceptual model and depends on how well this model matches theproblem in question. However, this chapter presents a representative study of theanalysis approaches that highlights that (i) they have traditionally focused onimplementation and have paid little or no attention to the problem domain and (ii) theyhave omitted the various stakeholders (viewpoints) generally involved in any problem.The proposed alternatives are based on those aspects that are related to a genericconceptualisation, independent of the implementation paradigms.

54 Andrade Garda, Ares Casal, García Vázquez and Rodríguez Yáñez


Introduction

The purpose of requirements engineering (RE) is to reach a thorough understanding ofthe needs of individuals involved in the problem to be solved. Because of this goal andits impact on subsequent phases, RE is an extremely relevant step in the software process.RE covers the requirements analysis activity, with conceptual modeling of the individu-als’ problem as one of its most remarkable tasks. In this activity, the problem to be solvedis understood through conceptual models.This chapter focuses on the conceptual modeling task within software engineering (SE),exposes its present weaknesses, and proposes a series of possible alternatives. The nextsection presents the basic and general aspects of conceptualisation regardless of SE.The following section tackles the relevance and orientation of conceptualisation in SE,and the two sections after that consider SE conceptualisation techniques and methods.The sections on alternatives and weaknesses list the weaknesses that result from thisstudy and propose ways to avoid them based on the points of the section on understand-ing and conceptualising a problem. Finally the last section presents the most relevantconclusions.

Understanding and Conceptualising aProblem

Humans usually start solving non-trivial problems by gaining an understanding of theseproblems. This involves two basic activities:

1. Acquisition. All the possible information related to the problem is gathered fromavailable sources. In general, initial acquisition is neither complete nor correct,because it is extremely difficult to gather all the information at once, and thegathered information is subject to inconsistencies. These inconveniences aregradually overcome by acquiring more information and by refining the informationthat is already available.

2. Conceptualisation. The gathered information is organised or modelled to form ameaningful whole: the conceptual model of the problem. If we define a concept asa mental structure that derives from the acquired information and is able to clarifyor even solve a problem when applied to it, conceptualisation can be defined as theuse of concepts and relationships to deal with and solve problems. Accordinglyconceptual models are abstractions of the universe of discourse of the problem, aswell as possible models of possible conceptual solutions to the problem.

Owing to the above-mentioned problem of acquisition, the timing of these activities isneither sequential nor clear; numerous overlaps and feedbacks occur that constitute aninherent evolutionary process, as befits any modeling process.



Any possible conceptualisation of a problem should consider (Gómez, Moreno, Pazos,& Sierra, 2000), as strictly as possible, the four rules proposed by Descartes (1969) in hisCartesian method: the rule of evidence, the rule of analysis, the rule of synthesis and therule of proof. The conceptualisation process thus ruled entails two basic activities,analysis (rule of analysis) and synthesis (rule of synthesis), which should be precededby a cautioning activity (rule of evidence) and followed by a confirmative activity (ruleof proof).It should be noted here that a model does not necessarily have to be a copy of the system,element, or phenomenon it models. That is, we are not looking for a relationship ofisomorphism between both elements. The most productive models are those that havea relationship of homomorphism (Ares & Pazos, 1998), which means that there is noinjective mapping between the real system and the model. Although this unquestionablysimplifies the understanding of the real system, it also has a price: a solution in the modeldoes not necessarily represent a solution in the real system. In the conceptualisationprocess it is therefore essential to validate models before they are applied (rule of proof).Formally, any conceptualisation can be defined as a triplet of the form (Concepts,Relationships, Functions) (Ares & Pazos, 1998). This definition includes, respectively,the concepts presumed or hypothesised to exist in the world, the relationships (in theformal sense) between concepts, and the functions (also in the formal sense) defined onthe concepts.Concepts are the primary elements. Since Plato (1997), the nature of concepts has stoodout as one of the most complicated and oldest questions of philosophy. Some hypoth-eses, however, have been established about concepts. Although they do not defineconcepts, these hypotheses can be used to quite effectively delimit what they are andhow they can be detected and used. These are the five hypotheses of conceptualisation(Díez & Moulines, 1997):

• HC1. Abstract entities. Concepts are in principle identifiable abstract entities, towhich human beings, as epistemic subjects, have access. These elements provideknowledge and guidance about the real world.

• HC2. Contraposition of a system of concepts with the real world. Real objects canbe identified and recognised thanks, among other things, to the available concepts.Several (real) objects are subsumed within one and the same (abstract) concept.

• HC3. Connection between a system of concepts and a system of language. Therelationship of expression establishes a connection between concepts and words(expressions in general), and these (physical entities) can be used to identifyconcepts (abstract entities).

• HC4. Expression of concepts by non-syncategorematic terms. Practically all non-syncategorematic terms introduced by an expert in a domain express a concept.

• HC5. Need for set theory. For many purposes, the actual concepts should besubstituted by the extensions of these concepts (sets of subsumed objects) towhich set theory principles and operations can be applied.



Problem Conceptualisation in SE

The software crisis was “officially” certified in 1967 when the NATO Science Committeeset up a study group in computer science. Its mission was to evaluate the entire field ofcomputer science. As a consequence of this initiative, in 1969 a congress was held inRome. The main point on the agenda of this congress was to make a detailed analysis ofthe technical problems that plagued software development, setting aside managementaspects. This congress stressed the need for rigorously defining software specifica-tions, improving quality, raising flexibility, and adapting education for the practitionerswho built software.In order to achieve these aims, work started on the different elements involved in softwaredevelopment, generally known as the three P’s: Product, Process, and Person (Reifer,1993). Initially emphasis was placed on the Product, and methodologies, formal specifi-cations, and metrics were developed. Later the interest switched to the Process, and theISO 9000-3, SPICE and CMM process models were created. As the “good process impliesgood product” equation was much criticised and the hopes placed on process improve-ment were not realised, attention turned to the Person element: “anything that improvesthe person aspect will redound to better software development practice” (Ares & Pazos,1998).However little or no emphasis was placed on what appears to be the heart of goodsoftware development: the Problem — fourth P — its understanding, and conceptualisation(Gómez et al., 2000; Jackson, 2001b). This was because it was assumed that a goodpractitioner should be capable of understanding and conceptualising any problem andthat a good process would already have considered this aspect.So the first and primary issue in the software process is still to conceptualise the problemraised and to then be able to develop suitable software for solving it. Indeed the mostcritical factor in software systems development is to properly understand and representthe requirements that the system under development has to satisfy (Jackson, Embley, &Woodfield, 1995).In this process, the information gathered in the problem domain cannot be directlytranslated into the computer domain; it needs to be transformed (Blum, 1996):

1. Construction of a conceptual model in the problem domain. This model serves togain an understanding of the problem and represents the problem-oriented momentin the software process.

2. Construction of the formal model in the computer domain, on the basis of the above-mentioned conceptual model. This model is computer-readable and would merelyhave to be introduced into the computer (implementation) to output the softwaresystem. It represents the computer-oriented moment of the software process.

Therefore software system quality has its genesis in the conceptual model and dependson how well this matches the problem in question.



Conceptual modeling has come to take an important place in the software process overthe last few decades, because its underlying philosophy is the most advanced for dealingwith problems (Ares & Pazos, 1998) and undertaking software development (Blum, 1996;Jackson & Rinard, 2000). The reason is that it is considered one of the main approachesfor the description of reality (problem), possibly as powerful as natural language itself(Chen, Thalheim, & Wong, 1999).

Conceptual Modeling Techniques

This section relates how SE conceptualisation techniques have progressively tried toavoid the obstacles that hindered an appropriate conceptualisation of the problem. It alsoindicates the remaining obstacles. These aspects are key points when addressing thefollowing sections.The representation capacity of a conceptualisation technique is defined by the set ofconcept types within the problem domain that this technique can represent. Accordingto this, we can distinguish three types of techniques:

• Solution-sensitive techniques. Their capacity is very restricted: they represent afew concepts concerning the problem domain, with a clear software-developmentorientation. Examples of these types of techniques are Data Flow Diagrams (DFD)and Object Diagrams.

• Solution-sensitive techniques with enhanced capacity. By searching for a widercapacity, detached from the development concepts, they aim at modeling conceptssuch as strategies and goals. Examples of these types of techniques are TELOS,Knowledge Acquisition in autOmated Specification (KAOS) and Enterprise Mod-eling (EM).

• Problem-sensitive techniques. Their capacity is oriented toward problems ratherthan to the development of software solutions. Problem Frames is the pioneertechnique of this type.

Solution-Sensitive Techniques

According to the orientation of their representation capacity, and following the ideasuggested by Davis (1993), these techniques can be classified as follows:

• State-oriented. They describe configurations, changes caused in configurations,and the subsequent actions. The treated concepts are states, events, and actions.

• Function-oriented. They describe data transformations through the process con-cept, which receives input data and generates output data.



• Data-oriented. They describe data and their relations. Even though Davis consid-ers them to belong to the next group, we esteem that the resulting classificationwould not be sufficiently strict.

• Object-oriented. These techniques describe objects (Object Diagrams) or objectclasses (Class Diagrams) and their relationships.

This classification illustrates the first problem: each technique can show only a partialvision of the problem, since its capacity only considers certain aspects (concepts). Thisentails the development of several conceptual models through various techniques inorder to have a complete description of the problem.Besides, these techniques (together with the resulting models) are biased by computa-tional aspects from the implementation domain, which is the opposite of the desiredorientation. In this regard, criticisms refer mainly to two aspects:

1. Computational-solution sensitivity. As opposed to the problem-sensitivity prin-ciple (Jackson, 1995), these techniques are oriented toward achieving a computa-tional solution to the problem, not toward facilitating its understanding. This is dueto the fact that the concepts dealt with include or are closely related to implemen-tation concepts (Bonfatti & Monari, 1994; Høydalsvik & Sindre, 1993; Jackson,1995).

2. Link to particular development approaches. Due to the aforementioned obstacle,a conceptual model restricts the possible implementation options only to those inline with the technique used to produce it (Davis, 1993; Henderson-Sellers &Edwards, 1990; Jalote, 1991). Skater’s principle, also called raw material principle(Paradela, 2001), states that everything must be built with well-chosen raw mate-rials. However, once a given technique has been used, it is extremely difficult tochange the implementation paradigm without needing to carry out a newconceptualisation; that is, the raw material used for conceptualising is not appro-priate.

As a consequence of the previous points, the understanding that has been achieved ispartial and too much oriented toward the computational solution. This means thatdecisions for the development of a software solution are made when the problem to besolved is still in the comprehension phase, which has implications for the quality of thefinal software product (Davis, Jordan, & Nakajima, 1997).

Solution-Sensitive Techniques with Enhanced Capacity

These techniques aim at achieving more representation capacity and less dependencyon the implementation domain through some of the following approaches:



1. Capacity enlargement. This is the most widely used approach. For example, it wasapplied in control processes and control flows incorporation in DFD. When thisapproach is applied, the new concepts that are to be introduced must be definedwith their semantics and notation.

2. Explicit definition of a metamodel. This approach explicitly contemplates a metalevel,a domain level in which concepts are used according to the metalevel’s guidelinesfor a particular problem (that is, the conceptual model), and an instantiation level,which is the lowest abstraction level for the exemplifying of situations (Boman,Bubenko, Johannesson, & Wangler, 1997). Examples are EM and KAOS, whichincorporate concepts related to static and dynamic aspects into their metamodel.

3. Definition of a non-rigid capacity. The aforementioned techniques provide aspecific capacity that is standardised and not apt for all domains; that is, a “rigid”one. Their weakness lies in the fact that they cannot provide a thorough coverageof any problem/domain. It is sometimes necessary to model a problem/domain withthe eventual loss of relevant aspects in the assimilation process. To solve thisproblem, this third strategy allows the definition of “customised” techniques, inwhich each modeling process “creates” a new technique adapted to the corre-sponding domain. An example would be TELOS, whose main concept is class(bearing the same connotation as in object-orientation).

Despite the progress made by these approaches, the technological solution has not yetbeen fully removed:

1. The enlargement of the capacity does not entail a distantiation from implementa-tion. Looking at the previous case of control processes in DFD, we still observean obvious closeness to software development.

2. The explicit definition of a metamodel does not exclude concepts that are close tosoftware development. In fact the KAOS metamodel considers concepts such asactions, events, and objects, which are obviously related to software development.

3. The definition of a non-rigid capacity does not entail its remoteness from thesoftware development. In fact any conceptualisation technique can be defined bymeans of this type of mechanism, which clearly indicates the possibility of its usagebeing hindered by the aforementioned obstacles.

Problem-Sensitive Techniques

Problem Frames technique (Jackson, 2001a) is the first technique that clearly focuses ontackling the problem and allowing reuse at a conceptual level. Even though it shares thephilosophy that underlies design patterns, it focuses on the problem instead of ontechnical solutions. The Problem Frames technique is based on (i) the identification ofthe simplest subproblems in the global problem, (ii) the identification of the frame —pattern — that best fits each subproblem, and (iii) their subsequent integration.



Each frame is independent from any kind of software development paradigm and adjustedto a particular type of problem. For each type there exists a simple and systematicresolution method: the solution task (first frame component). This method can be easilyapplied because it is expressed in terms of the principal parts (second frame components).Once the modellers have identified a problem frame, they know which elements must beconceptualised - principal parts and solution task - but they do not know which processto follow. Although this modeling process is more restricted and guided, it is stillnecessary to fill out the “template” as expressed by the frame and, consequently, to havea guiding methodological framework. Nevertheless, this proposal does not constitute aconceptualisation framework because it does not explicitly define a process; it merelyentails the three aforementioned activities. In fact, this proposal does not indicate howto conceptualise a subproblem if this does not fit any frame, nor does it detail whichtechniques or activities must be tackled in order to establish a new frame.Just as the design patterns did not avoid the need for a design, Problem Frames does noteliminate the need for a conceptualisation of the problem and, therefore, the need for amethodological framework for problem-sensitive conceptual modeling. This frameworkshould consider two well-known obstacles: the simplification of the integration, thanksto a uniform specification of conceptualisations (Jackson & Jackson, 1996), and theconsideration of the possible discrepancies that derive from dealing with each subprob-lem separately (Jackson, 2001b), given the fact that each subproblem stands for aviewpoint of the global problem.

Conceptual Modeling Methods

Even though throughout their evolution conceptualisation techniques have tried tofocus on the problem as such, one specific technique cannot be held responsible for theconceptualisation of a problem. This is because, apart from the above problems, atechnique does not indicate how to conceptualise. There should be an element that,without considering any implementation aspects, tells the modeller what steps must betaken in the conceptualisation process, what the output is, and what technique(s) is (are)to be applied. It is in this context that the conceptualisation — or analysis — phases ofdevelopment methodologies/methods/processes have put forward certain methods forthe elaboration of conceptual models.As mentioned before, these conceptual modeling methods usually handle severaltechniques to express various perspectives of the same problem. This complicates theintegration of all the information and the tackling of the process. As a result, the methodsend up aiming exclusively at the coordination of the applied techniques instead offocusing on their real objective.This section shows that conceptual modeling methods in SE are not oriented toward theconceptualisation of the problem within its domain, because of the following reasons:



1. Historically, they have adopted the concepts that arose from programming,fostering their usage at the problem level. This is the main reason why bothconceptualisation methods and techniques are so close to software development.

2. They are closely linked to the solution-sensitive techniques that they deal with andon which they are based. As a result they inherit the already-mentioned orientationto software development, and their steps, rather than guiding the conceptualisationprocess, focus on the coordination of the used techniques.

What follows is a brief study of a representative sample of the analysis methods. Thepurpose is not to carry out an exhaustive study of each method but to check the previouspoints.

Structured Methods

The most relevant structured methods are widely known approaches, such as StructuredSystems Analysis and Design Method (SSADM), Méthode d’Etude et de RéalisationInformatique pour les Systèmes d’Entreprise (MERISE), MÉTRICA, and InformationEngineering.For our purpose the study of one specific method is sufficiently representative, sincethey all share the same philosophy and do not present any significant differences. Weshall therefore focus on MÉTRICA (Spanish Ministry of Public Administrations [MAP],2001), an approach that allows structured and object-oriented developments.In its Information Systems Analysis (ASI) process, MÉTRICA deals with data andprocess models (such as normalised logical data models, process models, and process/geographical location matrixes), specifying all the interfaces between system and user.Once the models are completed, a consistency analysis based on verifications andvalidations considers all the achieved elements.MÉTRICA is a good example of the aforementioned obstacles: it presents closeness tothe development paradigms, as can be seen in the obtained products, and activities(MAP, 2001) that are totally oriented toward the coordination/integration of the appliedtechniques. Moreover before tackling the analysis (that is, before understanding theproblem), the modellers must choose between the structured approach and the object-oriented approach. At that moment, and as opposed to the conceptualisation orientation,this decision is only based on the way the software is going to be developed.

Object-Oriented Methods

The study of object-oriented methods is characterised by that of the Unified Process(Jacobson, Booch & Rumbaugh, 1999), since it is the result of a mixture of the mostrelevant and remarkable methods in this field.In Unified Process, the analysis workflow considers the identified use-cases andreformulates them as objects in order to achieve a better understanding of the require-



ments and prepare for the system’s design and implementation (Jacobson et al., 1999).Hence concepts like attributes, methods, control classes, state diagrams, and so forthare handled in the analysis model.This approach is also close to the implementation domain. In fact, the analysis model ispresented as a detailed specification for requirements understanding at the implemen-tation level. Its authors (Jacobson et al., 1999) have said that the level of detailcontemplated in this model does not usually concern the client. However, if it had theorientation of a truly conceptual model, that would be precisely the most important aspectfor the client.

Agent-Oriented Methods

Because of the similarities between both paradigms (Bond & Gasser, 1988), it is very usualto expand the object-oriented approaches and make them consider the aspects thatbelong to the agents’ domain.MESSAGE (European Institute for Research and Strategic Studies in Telecommunica-tions [EURESCOM], 2001) is the agent-oriented analysis and design methodology thatwe consider representative, because of the following reasons:

• It is the newest methodology.• It is based on Unified Process, which entails an updated vision.• It achieves remarkable goals through the integration of various fields (e.g., Agent

UML).

On the one hand the five views defined by MESSAGE for the analysis model deal withaspects such as agents, aggregations, states, events, and trigger conditions. On theother hand the defined analysis process consists of repeated enhancements that resultin different levels, which consider the previous views.Once again we can observe how conceptualisation depends on computational concepts(agents). We must also remember that the integration of the views within the MESSAGEanalysis process has not been studied in depth (EURESCOM, 2001) and remains thereforean incompletely defined process.

Current Weaknesses in SE ConceptualModeling

The preceding sections allow the extraction of the common problems shared by currentconceptual modeling methods:



1. The methods focus on the technological solution instead of on the problem domain:computational model vs. conceptual model.

2. Rather than leading the conceptualisation process in a clear way, the currentapproaches are limited to the coordination and integration of the (implementation-oriented) techniques they consider.

3. With regard to the verification and validation of the elaborated model, thesemethods establish a consistency analysis (not always explicitly) that only consid-ers development concepts. There is no actual evaluation with regard to the model’sability to tackle the problem, because that model is expressed in technological termsthat are very difficult or even impossible to understand by the person who facesthe problem and evaluates the model.

4. More often than not, it is group of people rather than a single individual who facethe problem (Ares & Pazos, 1998). This means that the conceptualisation processmust take into account various individuals, each of whom possibly have differentviewpoints on the matter. These different ways of perceiving the problem can leadto discrepancies that should be managed to build a single conceptual model of theproblem in accordance with all the viewpoints involved. However the finding of theprevious study is that generally no guidelines are given to deal with theselegitimate situations. That is to say, from the very outset, current conceptualmodeling strives to build a single model in which different perceptions and,therefore, discrepancies have no place. Few works in viewpoint-based require-ments engineering consider these aspects when conceptualising a problem. Themost relevant works are Viewpoint Resolution (Leite & Freeman, 1991) andReconciliation (Spanoudakis & Finkelstein, 1997). The former deals withconceptualisation in a very shallow manner, since it allows very basic conceptualmodels through the Viewpoint Language - a rule-based language - without fullymanaging discrepancies (it neither establishes a strict classification of discrepan-cies nor does it indicate how to resolve these discrepancies). The latter managesexclusive concepts: object-orientation and concepts linked to the syntax of theTELOS language.

Alternatives to Overcome the IdentifiedWeaknesses

Once the weaknesses are identified, it is possible to establish the bases that a method-ological framework for conceptual modeling should take into account in order to avoidthem:

1. The need to pay attention to the information related to the problem (within thecontext of the problem). Although there exists a general and formal definition of aconceptualisation — triplet (C, R, F) — this is not practical from the point of viewof articulating a methodological framework since (i) concepts are abstract entities



(see HC1), (ii) relationships and functions are defined on the basis of concepts(which increases the afore-mentioned complexity), and (iii) the natural way ofexpression is through natural language (see HC3). Taking into account these threepoints, and HC4, we propose the articulation of a methodological framework forconceptualisation based on the information types that result from the analysis ofthe grammatical categories of natural languages. This proposal stems from the factthat there exists a parallelism between natural language structures and conceptualmodeling (Hoppenbrouwers, van der Vos, & Hoppenbrouwers, 1997). Moreoverthis procedure should not obviate the aforesaid formal definition (it should berespected), and it must consider the existing interrelationships between the varioustypes of information, which are particularly interesting when the model is evalu-ated.

2. The need to pay attention to the very close and natural interrelationships betweeninformation acquisition and conceptualisation activities. Special attention shouldbe paid to the natural interaction between both activities and to the contributionsthat take place between them in order to define a real and integrated methodologicalframework. The execution of the cycle defined by both activities will undoubtedlysuffer variations as the process itself progresses, so that an evolutionary process(typical of any modeling process) takes place.

3. The need to pay attention to the general and characteristic activities appertainingto a conceptualisation process. Since the purpose is to lead the conceptualisationprocess, apart from the aforesaid, it will be necessary to indicate which activitiesneed to be tackled and which interactions and contributions take place betweenthem. This is where the rules of the Cartesian method must be applied. The analysisof the activities related to these rules, and of their relations, should lead to our goal.Moreover the execution of the identified activities should be subject to anevolution, which is determined by the one that was previously discussed. Amongthe identified activities, model evaluation should play a key role. The recommendedprocedure consists of a holistic evaluation by means of graphic techniquesconsidering the interrelationships among the information types that were identi-fied.

4. The need to pay attention to various stakeholders who may have differentviewpoints with regard to the considered problem, which might in turn causediscrepancies. Such discrepancies should be managed in a relevant way within theprocess in order to elaborate a conceptual model that is valid for every individualinvolved (viewpoints), since they are common phenomena from which a betterunderstanding of the problem can be derived. Obviously the established activitiesand guidelines (types of discrepancies, resolution criteria, etc.) should take intoaccount the core of the single-viewpoint conceptual modeling that was establishedas a result of the previous points. Finally, the detection and resolution of thediverse discrepancy types should follow and guide the previously presentedevolution.



Conclusion

This chapter has presented an overview of the conceptual modeling in SE, which is animportant activity in RE. The study presented in the methods and techniques sectionsallows the identification of common problems shared by current SE conceptual modelingmethods. These weaknesses were enumerated, and the possible alternatives to overcomethem were outlined in the final section. The alternatives (i) take into account the generic(not development-oriented) considerations that were presented in the section onunderstanding and conceptualising a problem, (ii) are in accordance with the actualorientation the conceptual modeling activity should have in SE, and (iii) constitute thebasis of any problem-oriented conceptual modeling methodological framework.Once the identified weaknesses are set aside, research should focus on identifying thecriteria that are now needed to continue with the software development: criteria for theselection of the most suitable development paradigm(s) in software or knowledgeengineering, and criteria for the transformation of the conceptual structures to thecorresponding computational structures in selected paradigm(s).

Acknowledgments

The authors would like to thank Juan Pazos (Technical University of Madrid), for hisconstructive suggestions; University of A Coruña, for its economical support; andValérie Bruynseraede (Research Transfer Office of the University of A Coruña), for herhelp in translating the chapter into English.

References

Ares, J., & Pazos, J. (1998). Conceptual modelling: An essential pillar for quality softwaredevelopment. Knowledge-Based Systems, 11, 87-104.

Blum, B. I. (1996). Beyond programming. To a new era of design. New York: OxfordUniversity Press.

Boman, M., Bubenko Jr., J. A., Johannesson, P., & Wangler, B. (1997). Conceptualmodelling. London: Prentice-Hall Series in Computer Science.

Bond, A. H., & Gasser, L. (1988). An analysis of problems and research in DAI. In A. H.Bond & L. Gasser (Eds.), Readings in DAI (pp. 3-35). CA: Morgan KaufmannPublishers.

Bonfatti, F., & Monari, P. D. (1994). Towards a general purpose approach to object-oriented analysis. Proceedings of the International Symposium of Object-Ori-ented Methodologies and Systems, Italy, 108-122.



Chen, P. P., Thalheim, B., & Wong, L. Y. (1999). Future directions of conceptual modelling.In P. P. Chen, J. Akoka, H. Kangassalu, & B. Thalheim (Eds.), Conceptual modelling(pp. 287-301). Berlin: Springer-Verlag.

Davis, A. M. (1993). Software requirements: Objects, functions, and states. New Jersey:Prentice-Hall.

Davis, A. M., Jordan, K., & Nakajima, T. (1997). Elements underlying the specificationof requirements. Annals of Software Engineering, 3, 63-100.

Descartes, R. (1969). Oeuvres de Descartes. Paris: Librairie Philosophique J. Vrin.Díez, J. A., & Moulines, C. U. (1997). Fundamentos de filosofía de la ciencia. Barcelona:

Ariel S. A.European Institute for Research and Strategic Studies in Telecommunications (2001).

MESSAGE: Methodology for engineering systems of software agents. Methodol-ogy for agent-oriented software engineering. Retrieved on November 5, 2004 fromhttp://www.eurescom.de/public/projectresults/P900-series/907ti1.asp.

Gómez, A., Moreno, A., Pazos, J., & Sierra, A. (2000). Knowledge maps: An essentialtechnique for conceptualisation. Data & Knowledge Engineering, 33(2), 169-190.

Henderson-Sellers, B., & Edwards, J. M. (1990). The object-oriented systems life cycle.Communications of the ACM, 33(9), 142-159.

Hoppenbrouwers, J., van der Vos, B., & Hoppenbrouwers, S. (1997). NL structures andconceptual modelling: Grammalizing for KISS. Data & Knowledge Engineering,23(1), 79-92.

Høydalsvik, G. M., & Sindre, G. (1993). On the purpose of object oriented analysis.Proceedings of the Conference on Object Oriented Programming, Systems, Lan-guages and Applications, USA (240-255).

Jackson, D., & Jackson, M. (1996). Problem decomposition for reuse. Software Engineer-ing Journal, 11(1), 19-30.

Jackson, D., & Rinard, M. (2000). Software analysis: A roadmap. In A. Finkelstein (Eds.),The future of software engineering (pp. 135-146). New York: ACM Press.

Jackson, M. (1995). Software requirements and specifications. A lexicon of practice,principles and prejudices. New York: ACM Press.

Jackson, M. (2001a). Problem frames: Analysing and structuring software developmentproblems. Harlow: Addison-Wesley.

Jackson, M. (2001b). Problem analysis and structure. Proceedings of 2000 NATOSummer School, Germany (3-20).

Jackson, R., Embley, D., & Woodfield, S. (1995). Developing formal object-orientedrequirements specifications: A model, tool and technique. Information Systems,20(4), 273-289.

Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The unified software developmentprocess. Reading, MA: Addison-Wesley.

Jalote, P. (1991). An integrated approach to software engineering. New York: Springer-Verlag.



Leite, J. C. S. P., & Freeman, P. A. (1991). Requirements validation through viewpointresolution. IEEE Transactions on Software Engineering, 17(12), 1253-1269.

Paradela, L. F. (2001). Una metodología para la gestión de conocimientos. Unpublisheddoctoral dissertation, Technical University of Madrid, Madrid.

Plato. (1997). Memón, Cratilo, Fedón. Barcelona: Planeta DeAgostini S. A.Reifer, D. J. (1993). Managing the three P’s: The key to success in software management.

In D. J. Reifer (Eds.), Software management (4th ed.) (pp. 2-8). Los Alamitos: IEEEComputer Society Press.

Spanish Ministry of Public Administrations (2001). Metodología MÉTRICA v.3. Re-trieved on November 5, 2004 from http://www.csi.map.es/csi/metrica3/index.html.

Spanoudakis, G., & Finkelstein, A. (1997). Reconciling requirements: A method formanaging interference, inconsistency and conflict. Annals of Software Engineer-ing, 3, 433-457.

68 de Antonio and Imbert


Chapter V

CombiningRequirements

Engineering andAgents

Angélica de Antonio, Universidad Politécnica de Madrid, Spain

Ricardo Imbert, Universidad Politécnica de Madrid, Spain

Abstract

The concept of Agent is being used with different meanings and purposes in twoseparate fields of software engineering, namely Requirements Engineering and Agent-Oriented Software Engineering. After an introduction to Goal-Oriented RequirementsEngineering (GORE) and its evolution into Agent-Oriented Requirements Engineering(AORE), this chapter provides a review of some of the main Agent-Oriented SoftwareEngineering (AOSE) methodologies, focusing on their support for requirementsmodeling. Then the chapter analyzes how both approaches to Agents relate to eachother, what the differences are among them, and how they could benefit from each other.Problems are identified and discussed that need to be addressed for a successfulintegration of both fields, and recommendations are provided to advance in thisdirection.

Combining Requirements Engineering and Agents 69


Introduction

This chapter is devoted to the analysis of a growing tendency to combine requirementsengineering and agents. This analysis is conducted from a double perspective.On one hand agents have been recognized as an abstraction that can be useful forrequirements engineering (RE). Specifically, the concept of agent can be considered asa building block for structuring the description of an information system and theenvironment in which it will operate and with which it will interact. Agents are considereda nice abstraction since they can be used for modeling different kinds of entities, suchas software, hardware, humans, or devices. From this point of view agents are a tool thatcan be used for engineering the requirements of any software system, be it agent-basedor not. Agent-oriented requirements engineering (AORE) is considered as an evolutionof goal-oriented requirements engineering (GORE), both being social approaches torequirements engineering.On the other hand agent-oriented systems, also known as multi-agent systems (MAS),are being increasingly recognized during the last few years (from the mid-’90s) as justthe kind of software systems that need the application of software engineering practicesfor their development like any other software system, or even more if we take into accountthat MAS are complex systems and are usually applied to complex domains. That is howthe term Agent-Oriented Software Engineering (AOSE) was coined a few years ago todescribe a discipline that tries to define appropriate software engineering techniques andprocesses to be applied to these systems. The requirements of a MAS, like any othersoftware system, need to be elicited, specified, analyzed, and managed, and the questionthat naturally arises is if engineering requirements for a MAS are different from any othersoftware system.Considering the apparent dissociation between the agent concept in GORE-AORE andin AOSE, we decided to investigate to which extent it would be possible to combine bothapproaches.The second and third sections of this chapter describe the main approaches to the useof agents for requirements engineering, stating the principles underlying GORE andAORE. The fourth section analyzes how requirements engineering is currently beingperformed for agent-based systems. The last two sections show a reflection about theconclusions reached in our attempt to clarify how both approaches are related and howthey could benefit one from the other.

Goal-Oriented RequirementsEngineering (GORE)

The initial requirements statements, which express customers’ wishes about what thesystem should do, are often ambiguous, incomplete, inconsistent, and usually expressedinformally. Many requirements languages and frameworks have been proposed for the



refinement of the initial requirements statements, making them precise, complete, andconsistent.Increasingly information systems development occurs in the context of existing systemsand established organizational processes. Some authors defend the need for an earlyrequirements analysis phase with the aim to model and analyze stakeholder interests andhow they might be addressed, or compromised, by various system-and-environmentalternatives. This earlier phase of the requirements process can be just as important asthat of refining initial requirements. However most existing requirements techniques areintended mainly for the later phase. Considerably less attention has been given tosupporting the activities that precede the formulation of the initial requirements. These“early-phase” requirements engineering activities consider how the intended systemwould meet organizational goals, why the system is needed, what alternatives might exist,what the implications of the alternatives are for various stakeholders, and how thestakeholders’ interests and concerns might be addressed. Early-phase RE activities havetraditionally been done informally and without much tool support.Because early-phase RE activities have objectives and presuppositions that are differentfrom those of the late-phase, it seems appropriate to provide different modeling andreasoning support for the two phases.The introduction of goals into the ontology of requirements models represented asignificant shift toward this direction. Previously the world to be modeled consisted justof entities and activities. Goal analysis techniques have proved to be very useful,covering functional and non-functional goal analysis.Some of the most remarkable GORE approaches are EKD (Enterprise Knowledge Devel-opment) (Kavakli & Loucopoulos, 1998) and KAOS (Dardenne, van Lamsweerde, &Fickas, 1993; van Lamsweerde, Darimont, & Letier, 1998; van Lamsweerde, 2000). In orderto illustrate the relationship between agents and goals in GORE, we will describe brieflythe approach of KAOS. In KAOS a requirement for the overall system is called a goal.A requisite is a requirement on the part of the dynamics controllable by a single agentor environment component. Overall goals are explicitly modelled, and then goal refine-ment is used to decompose goals into requisites via AND/OR graphs. Assignment ofagents to roles is done using responsibility links. Therefore the KAOS goal-orientedmethod consists of eliciting goals and refining them into subgoals until the latter can beassigned as responsibilities of single agents such as humans, devices, and software.Domain properties and assumptions about the software environment are also usedduring the goal refinement process. The method supports the exploration of alternativegoal refinements and alternative responsibility assignments of goals to agents. As wecan see, goals are the core concept in GORE as they guide the process, while agents areunderstood as entities to which responsibilities about goals are assigned. The mainbenefit of GORE is the systematic derivation of requirements from goals, while goalsprovide rationale for requirements. Alternative goal refinements and agent assignmentsallow the exploration of alternative system approaches.



Agent-Oriented RequirementsEngineering (AORE)

The logical next step in RE was to go from goal-oriented RE to agent-oriented RE(AORE). Viewing organizational and system components as cooperating agents offersa way of understanding their inter-relationships and how these would or should bealtered as new systems are introduced. The main difference with GORE is that in goal-oriented approaches agents interact with each other non-intentionally, and they are notconsidered to have rich social relationships. In most goal-oriented frameworks in RE, theintentionality is assumed to be under the control of the requirements engineer. Therequirements engineer manipulates the goals and makes decisions on appropriatesolutions to these goals. This may be more appropriate for late-phase RE but not for theearly phase.As an example we will describe i* (Yu, 1997), which is one of the most significantframeworks for AORE. It is used in contexts in which there are multiple parties withstrategic interests that may be reinforcing or conflicting in relation to each other. Therationale behind i* is that understanding the organizational context and rationales (the“whys”) that led up to systems requirements can be just as important for the success ofthe system as stating what a system is supposed to do (system requirements). Withoutintentional concepts such as goals, one cannot easily deal with the “why” dimension inrequirements.The central concept in i* is that of intentional actor. Organizational actors are viewedas having intentional properties such as goals, beliefs, abilities, and commitments.Actors depend on each other for goals to be achieved, tasks to be performed, andresources to be furnished. The i* framework differs from previous goal-oriented ap-proaches in that it highlights the strategic dimension of agent relationships and de-emphasizes the operational aspects. The i* consists of two main modeling components:

• The Strategic Dependency (SD) model is used to describe the dependencyrelationships among various actors. The SD model describes the process in termsof intentional relationships among agents instead of the flow of entities amongactivities. These types of relationships cannot be expressed or distinguished in thenon-intentional models that are used in most existing requirements modelingframeworks.

• The Strategic Rationale (SR) model is used to describe stakeholder interests andconcerns, and how they might be addressed by various configurations of systemsand environments. The SR model is a graph that is used to describe how an agentaccomplishes a goal in terms of subgoals, softgoals, resources, and tasks.

The approach adopted in i* is to introduce the notion of intentional dependencies toprovide a level of abstraction that hides the internal intentional contents of an actor. Thegoals and criteria for such intentions will only be made explicit when reasoning aboutalternative configurations (in the Strategic Rationale model).



The i* modeling is implemented on top of the Telos conceptual modeling language(Mylopoulos, Borgida, Jarke, & Kourbarakis, 1990), providing an extensible, object-oriented representational framework with classification, generalization, aggregation,attribution, and time.CARE (COTS-Aware Requirements Engineering), Tropos, and other methodologieshave been later proposed adopting the i* framework. CARE is a GORE and AOREapproach that explicitly supports the use of COTS (Chung & Cooper, 2002). In the CAREapproach the goals of the agents may be functional (hardgoals) or non-functional(softgoals). CARE uses the i* framework notation for the description of goal and softgoaldependencies among agents. Tropos will be described in the next section.Another work derived from i* is the one described in (Yu, Du Bois, Dubois, & Mylopoulos,1997), where the i* framework is used to support the generation and evaluation oforganizational alternatives, while the ALBERT language (Agent-oriented Language forBuilding and Eliciting Real-Time requirements) (Dubois, Du Bois, Dubru, & Petit, 1994)is then used to produce a system requirements specification document. ALBERTsupports the modeling of functional requirements in terms of a collection (or society) ofagents interacting together to provide services necessary for the organization.We can see that agents are the core concept in AORE, while goals are used to model theintentionality of agents. The concept of agent is used with the aim of producing aspecification of system requirements.

Engineering Requirements for Agent-Oriented Software Engineering (AOSE)

As we have just seen, both in GORE and in AORE agents are abstract entities that canbe used for modeling different kinds of components, such as software, hardware,humans, or devices. When we talk about MAS, however, the concept of agent takes amuch narrower meaning, referring to just software entities.Agent-orientation is emerging as a powerful new paradigm for computing that offershigher-level software abstractions. As agent technology is maturing, attention is turningto the development of a full set of complementary models, notations, and methods tocover the entire software life cycle of agent systems. That is how the term Agent-OrientedSoftware Engineering (AOSE) was coined. It should be mentioned that MAS are mostlyimplemented with object- or component-based technology and programming languages.At a detailed level an agent is considered to be a complex object or component. ThereforeUML has been widely considered as a convenient starting point for an agent-orientedmodeling language, as it is a standard for object-oriented software engineering. Takinginto account that the object- and agent-oriented paradigms are highly compatible andthat UML is extensible, an effort is under course to define the so-called AUML (AgentUnified Modelling Language).Considering the apparent dissociation between the agent concept in GORE-AORE andin AOSE, we decided to investigate to which extent it would be possible to combine both



approaches. A first step in this direction was an analysis of how AOSE methodologiescurrently approach RE. In this section we will summarize our review of some of the mainAOSE methodologies, focusing our attention on their support for requirements model-ing.

Tropos

Tropos (Mylopoulos, Castro, & Kolp, 2000) is an agent-oriented software developmentmethodology founded on i* and GRL (Goal-oriented Requirements Language), which isa successor of i*. Agent orientation is assumed throughout all the development stages.Tropos deals with modeling needs and intentional aspects of the agent system, from earlyrequirements analysis to late design. It focuses particularly on BDI agent architectures.The modeling elements in Tropos are: Actor, Goal, Plan, Resource, Dependency,Contribution, Decomposition, Capability, and Belief. There are two main analysisdiagrams:

• Actor diagram: describes the actors, their goals and the network of dependencyrelationships among actors (a kind of goal-based requirements business model).

• Goal diagram: shows the internal structure of an actor (goals, plans, resources,and relationships among them).

Capability, Plan, and Agent interaction diagrams are used for detailed design, adoptedfrom other modeling languages without changes (UML activity diagrams and AUMLsequence diagrams). Tropos is a good example of how concepts coming from AORE arestarting to be introduced into the AOSE world.

Gaia

Gaia (Wooldridge, Jennings, & Kinny, 2000) is an agent-oriented methodology thatintends to be neutral with respect to the application domain and the agent architecture.However Gaia imposes strong limitations to the kind of systems to be described anddeveloped with it related to the system organizational structure, inter-agent relation-ships, agent’s abilities, and services. One of its strengths is that it combines a dual viewof the system, both at the micro-level (roles first and then agents) and at the macro-level(as a society of agents).Although Gaia presupposes a requirements statement phase previous to the applicationof the methodology, it proposes a system specification activity in the analysis phase.Gaia proposes first the identification of the system roles in terms of their permissions(resources exploited by the role) and their responsibilities (functionalities aimed by therole). This perspective of the system goals is reflected in a Role Model.Then the Interaction Model is identified to capture the interactions between roles in acoarse-grained sense. Its aim is not to describe any kind of message exchange between



roles, but the identification of the required protocols of interaction. Both Role Model andInteraction Model are then refined by consecutive iterations.Gaia methodology is very well considered in the AOSE community, despite the scarcedocumentation and examples that it provides hitherto.

MaSE

MaSE, the Multiagent Systems Engineering methodology, views agents merely as aconvenient abstraction — intelligent or not — to build complex, distributed, and possiblydynamic systems (DeLoach, Wood, & Sparkman, 2001). This means that the systemrequirements analysis phase of the MaSE methodology concentrates on identifyingsimple software processes that interact with each other to meet cooperatively an overallsystem goal, forgetting the typical Artificial Intelligence perspective of agents in whichthey are required to be autonomous, proactive, reactive, and social (Wooldridge &Jennings, 1995).The process proposed by this methodology to understand the multiagent system beginswith capturing system goals from detailed technical documents, user stories, or formal-ized specifications. Goals — always considered at system-level — are first identified andstructured through a Goal Hierarchy Diagram. Then the analyst translates goals intoroles and associated tasks by drawing first Use Cases and then restructuring them intoSequence Diagrams. Finally each identified goal is associated with one specific role(although multiple goals may be mapped to a single role for convenience or efficiency).Roles are structured into a Kendall-style Role Model (Kendall, 1998) identifying proto-cols among them. Tasks concurrency is depicted using a kind of finite state automatadenominated Concurrent Task Diagrams.The process and notations are supported by a CASE tool called agentTool (DeLoach,2001).

Prometheus

System specification is a key phase for the Prometheus agent-oriented methodology(Padgham & Winikoff, 2002a). The methodology proposes an iterative lifecycle in whichdetermining the system’s environment and determining its goals and functionalities iscrucial in the earlier iterations. Prometheus encompasses concepts, notations, artefacts,and a commented process to produce the system requirements.Starting from data arisen from discussions with clients, managers, and other stakehold-ers, Prometheus determines how the system is going to interact with the environment —usually a changing and dynamic environment. That means identifying “percepts” (rawdata available to the agent system) and “actions” (mechanisms for affecting theenvironment). The system’s environment definition is completed by identifying anyimportant shared data sources.In parallel with the environment specification, Prometheus starts with the description ofthe goals and functionalities, in a broad sense, of the future agent system as a way of



reaching a first understanding of the system. Then the goals identified originally andcontinuously refined are associated to narrow functionalities (the ones called “roles” byother methodologies), linking each functionality to some system goal. Each goal shouldresult in one or more functionalities (Padgham & Winikoff, 2002b). A textual structureis proposed to describe functionalities and their associated goals, percepts, actions, dataused, and so forth.Finally, enfacing the particular system perspective of the functionalities, Prometheusproposes the definition of some scenarios, very similar to use cases, to give a moreholistic view of system processing.The multiagent system engineering process proposed by Prometheus is supported bytwo different tools, the JACK Development Environment (JDE) and the PrometheusDesign Tool (PDT). Unfortunately neither of them covers the system specification phase.

Cassiopeia

Cassiopeia defines itself as an agent-oriented, role-based multiagent systems designmethodology (Collinot, Drogoul, & Benhamou, 1996). It is neither targeted at a specifictype of application nor does it require a given architecture of agents, although it has beenmostly applied to the robot soccer teams domain (Drogoul & Zucker, 1998). In fact it isparticularly suitable if the designer aims to make agents behave cooperatively.Cassiopeia proposes a development process based on iterative refinement. The same fivesteps are executed in each iteration until the system is finally constructed. Therefore, thesystem specification is not directly related to a specific phase of the methodology butrather to the activities carried out through the first iterations of the development.Basically the first step concentrates on the identification of the individual behaviorsof the system, represented as roles of the system (both the function that an agent isachieving at a given time and the position that it occupies at the same time in the groupof agents). Cassiopeia does not specify any particular technique and points out thatapproaches from functional or object-oriented methods or methodologies could beadopted in this stage.Steps two and three consist of analyzing the structure of the organization based on thedependencies between the individual roles being considered. Among the kind ofdependencies to be identified may be coordination, simultaneous or sequential facilita-tion, or conditioning, and so forth.Finally, steps four and five define, on one hand, the potential groups that may arise inthe system and, on the other hand, the organizational roles that will enable the agentsto manage the formation and dissolution of the defined groups.

MESSAGE/UML

MESSAGE/UML (Caire, Leal, Chainho, Evans, Garijo, Gomez, Pavon, Kearney, Stark, &Massonet, 2000) is an AOSE methodology that covers MAS analysis and design. It



contributes some concepts at the agent knowledge level and diagrams that extend UMLclass and activity diagrams. It proposes the following diagrams: Organization diagram,Goal diagram, Task diagram, Delegation diagram, Workflow diagram, Interactiondiagram, and Domain diagram. All of them are defined as extensions of the class diagramexcept the Task diagram that extends the activity diagram. Concepts are also textuallydescribed by schemas.The internal architecture of an agent is assumed to be based on one of the models derivedfrom cognitive psychology. MESSAGE is almost independent of the internal agentarchitecture.The analysis model includes several views, or sub-sets:

• Organization view: shows Agents, Organizations, Roles, and Resources andcoarse-grained relationships among them.

• Goal/task view: shows goals, tasks, situations, and dependencies among them.• Agent/role view: for each agent.• Interaction view: for each interaction.• Domain view: domain-specific concepts and relations.

The analysis process is conducted by stepwise refinement. The Organization and Goal/task views are created first, and they act as inputs to create the Agent/role and Domainviews. Finally the Interaction view is based on the previous ones. Level 0 focuses onentities and their relationships. The internal structure and behavior of the entities arerefined in the next levels of development.

AUML

The Agent Unified Modelling Language – AUML (Bauer, Müller, & Odell, 2001) is anotation for multiagent systems development. AUML aims to become a de facto standardfor specifying this kind of systems. Its authors argue that UML provides an insufficientbasis for modeling agents and agent-based systems, since UML does not cover theproactive and social agent dimensions.AUML intends to support the whole software engineering process, including planningand analysis. With this aim, when possible, AUML reuses notations coming from UML,such as interaction, state, and activity diagrams, or use cases, but it also adds new ones,covering issues such as multiagent and single agents modeling, goals and soft goalsspecification, modeling of social aspects, identification of temporal constraints, orenvironment modeling.AUML is a promising notation for agent and multiagent systems specification anddevelopment, and an interesting effort is been carried out to propose a methodologysupported by this language.



MAS-CommonKADS

MAS-CommonKADS (Iglesias, Garijo, González, & Velasco, 1998) is an agent-orientedmethodology that extends the knowledge engineering methodology CommonKADS withtechniques from object-oriented and protocol engineering methodologies. The method-ology proposes the development of seven models:

• Agent Model, describes the characteristics of each agent;• Task Model, describes the tasks that the agents carry out;• Expertise Model, describes the knowledge needed by the agents to achieve their

goals;• Organization Model, describes the structural relationships between agents (soft-

ware agents and/or human agents);• Coordination Model, describes the dynamic relationships between software

agents;• Communication Model, describes the dynamic relationships between human

agents and their respective personal assistant software agents; and• Design Model, refines the previous models and determines the most suitable agent

architecture for each agent and the requirements of the agent network.

The analysis models are comprehensive, but the method lacks a unifying semanticframework and notation.

Discussion

Our study about GORE and AORE on one hand and AOSE methodologies on the otherhand has revealed some fundamental problems that need to be addressed first if we wantto combine both approaches successfully.

Different Meanings for Agent

The first conclusion of our survey is that researchers in AORE and researchers in AOSEcome from different backgrounds and use different terminologies and concepts. Themost remarkable distinction is in the meaning of the word agent. The former consideragents-in-the-world, that is people, organizations, existing systems, and other actorswho may be involved in or affected by the system under development. The latter onlyconsider agents-as-software, that is, rather complex software components. While agents-as-software and agents-in-the-world share conceptual features, their respective abstrac-tions are introduced for different reasons and with different purposes. This ambiguity



in the terminology can be very confusing. It would be better if the word actor was usedfor real-world things and the word agent for software things.

Different Meanings for Requirement

Another significant example of the misunderstandings between both fields is related tothe concept of requirement. Many of the authors of AOSE methodologies state that theirfocus is mainly on the analysis and design stages, assuming that requirements are givenat least informally as an input. Some seem not to be concerned at all with requirements.Only the methodologies that derive from the goal-oriented RE tradition seem to recognizethat the analysis of the system is mainly a requirements analysis task.We agree with several authors that it is necessary to differentiate among MAS require-ments and agent requirements. The problem is what it is understood by MAS and agentrequirements. Current AOSE methodologies consider that, at the level of the MAS,requirements concern the dynamics of interaction and cooperation patterns among theroles. The main drawback of this approach is that the identification of roles is the firststep, and it is not realistic to assume that roles can be identified without knowing whatis required from the system. Using this strategy, agents will probably derive more or lessdirectly from real world concepts, and this may be not the optimal solution. In our opinionthe choice of a certain set of roles (agents) should be considered as a design decisionat the system level, once the requirements for the MAS have been established.Then, at the level of individual agents, requirements should be concerned with agentbehavior. The existing AOSE methodologies mainly deal with the specification ofrequirements for the system as a whole and pay less attention to the specification ofrequirements for each individual agent. One could argue that specifying the agent’srequirements is like specifying requirements for each object in an object-oriented system.That does not seem to make much sense, but why does it make sense for agents? Webelieve that the reason is that an object is a relatively simple software abstraction whilean agent is a quite complex one. The main difference is in the complexity degree. The nextsubsection goes deeper into this discussion.

The Need for Specific Agent Requirements

An object has just attributes and methods, implying that it knows things and it is ableto perform tasks on demand. An agent also knows things and is able to perform tasks,so where is the difference?A first difference is that an attribute is a very simple knowledge representation mecha-nism. An agent, however, can make use of much more complex knowledge representa-tions. Object methods, on the other hand, usually have a reduced size. The specificationof the internal design of each object’s methods is usually ignored by OO methodologies.Interaction diagrams, which are the most classical OO design technique, show theinteraction among objects but hide the details of method execution. One could use theclassical techniques of structured design for this, like control flow diagrams or pseudo-



code. The tasks that an agent can perform, however, are much more complex and cannotbe specified with a simple control flow diagram. Moreover, agents have autonomy overtheir behavior; that is, they may decide to attend a request or not (“objects do it for free;agents do it for money” (Jennings, Sycara, & Wooldridge, 1998)).An additional difference between objects and agents is that an object has no perceptualcapabilities. We could say that objects are not “situated,” since they are not able toperceive their environment. Agents need to perceive their environment, and they alsoneed to decide upon the best task to be performed at a given time, or they can even decidenot to act at all. An agent is a rational system that is able to make decisions and combinereactive, proactive, and social behaviors (Wooldridge, 1997). All these additionalcapabilities of agents, together with their higher level of complexity, make it reasonableto consider the need for a specific agent requirements analysis task.We can make an analogy with the difference between system requirements and softwarerequirements in traditional software engineering. In the development of a complex systemwith hardware, software, and human components, there is a system requirementsanalysis stage that concludes with the identification of the several components that willmake up the system and the allocation of the system requirements to the differentcomponents. Then, for the software components of the system, an additional softwarerequirements analysis stage is required. AOSE methodologies are mainly focused on thefirst stage: system requirements and the allocation of system requirements to agents inthe form of responsibilities. Then each agent, as a complex software component, shouldbe subject to individualized requirements analysis and design. Agent responsibilitiesderived from MAS analysis should be complemented with other categories of require-ments. In agent-oriented research, agents have been characterized by four essentialproperties (Wooldridge & Jennings, 1995) that can be considered as high-level require-ment categories for an agent:

• Autonomy: An agent has control over its own actions and internal states. Itsbehavior is not fully predictable or controllable. An agent can act without directintervention from humans.

• Sociability: An agent can interact with other agents (artificial or humans) toaccomplish its goals, complete its tasks, and help others. This may requirecommunication, coordination, cooperation, competition, and/or conflict manage-ment capabilities.

• Reactivity: An agent perceives its environment and reacts in a convenient way tochanges in this environment.

• Proactivity: An agent can exhibit a goal-directed behaviour, taking the initiativeover its actions.

Social ability is considered to be one of the most fundamental properties of agents,because in a MAS the overall functionality and properties of the system emerge out ofthe interplay between the agents.The social level in the analysis and design of MAS is concerned with phenomena suchas cooperation, coordination, conflicts, and competition. For such phenomena it is



necessary to describe the structures and mechanisms that must be present inside theagents and the overall system to produce the desired type of behaviour.Although the social capabilities can be considered the most relevant source of require-ments for an agent, from the MAS-level perspective we should not forget the other threeessential characteristics. Moreover additional properties have been proposed by otherauthors as typical of agents, and some or all of them could be required for a given agent:

• Learning: An agent that is capable of improving its behaviour through its experi-ence.

• Mobility: An agent that is able to travel across different platforms.• Embodiment: An agent that has any kind of physical representation in a virtual

environment.• Character-Personality: An agent that is endowed with individual traits that influ-

ence its behaviors and reasoning processes.• Reflectivity: An agent that is able to reflect on its own operations.• Emotion: An agent that is able to react emotionally to external or internal stimuli.

We would like to see in the future more elaborate taxonomies, including these propertiesand possibly others, to guide the requirements engineer in the identification of theagent’s requirements.

Conclusion

In an attempt to contribute toward the objective of combining requirements engineeringand agents, we would like to conclude with a list of recommendations derived from theprevious reflections:

• It would be better if different terms were used for real-world things and softwarethings. We propose to use the word actor for the first and agent for the second.

• AOSE methodologies should recognize that the analysis of the system is mainlya requirements analysis task, forgetting about the unrealistic assumption that a listof requirements will be provided beforehand.

• Software agents do not need to derive directly from real-world concepts. Therefore,the choice of a certain set of roles (agents-as-software) should be considered asa design decision at the system level once the requirements for the MAS have beenestablished considering agents-in-the-world from the perspective of AORE.

• It is necessary to differentiate among MAS-level requirements and agent-levelrequirements. The complexity of agents justifies considering them as systemswhose requirements need to be analyzed carefully.



• AOSE methodologies should pay more attention to the specification of require-ments for each individual agent. In this respect elaborate taxonomies are neededto guide the requirements engineer in the identification of the agent’s requirements.

• The specification of the social abilities of agents and the interaction among themcan also benefit from the techniques and models proposed by AORE.

In addition, we feel that the gap between the models obtained with AOSE methodologiesand the design of a complex rational agent is still too big. Some possible architectureshave been proposed for individual agents, but the designer is left alone with the decisionof selecting the best architecture for each agent in the system. And it is obvious that thisdecision should be based on the set of requirements that those agents have to satisfy.

References

Bauer, B., Müller, J. P., & Odell, J. (2001). Agent UML: A formalism for specifyingmultiagent interaction. In P. Ciancarini & M. Wooldridge (Eds.), Agent-orientedsoftware engineering (pp. 91-103). Berlin, Germany: Springer-Verlag.

Caire, G., Leal, F., Chainho, P., Evans R., Garijo, F., Gomez, J., Pavon, J., Kearney, P., Stark,J., & Massonet, P. (2001). Agent oriented analysis using MESSAGE/UML. In M.Wooldridge, P. Ciancarini, & G. Weiss (Eds.), Second International Workshop onAgent-Oriented Software Engineering (AOSE-2001) (pp. 101-108).

Chung, L., & Cooper, K. (2002). Defining agents in a COTS-aware requirements engineer-ing approach. Proceedings of the Seventh Australian Workshop on RequirementsEngineering.

Collinot, A., Drogoul, A., & Benhamou, P. (1996). Agent oriented design of a soccer robotteam. Proceedings of the Second International Conference on Multi-AgentSystems (ICMAS’96), 41-47.

Dardenne, A., van Lamsweerde A., & Fickas, S. (1993). Goal-directed requirementsacquisition. Science of Computer Programming, 20, 3-50.

DeLoach, S. A. (2001). Analysis and design using MaSE and agentTool. Proceedings ofthe 12th Midwest Artificial Intelligence and Cognitive Science Conference(MAICS 2001).

DeLoach, S.A., Wood, M.F., & Sparkman, C.H. (2001). Multiagent systems engineering.International Journal of Software Engineering and Knowledge Engineering,11(3), 231-258.

Drogoul, A., & Zucker, J. D. (1998). Methodological issues for designing multi-agentsystems with machine learning techniques: Capitalizing experiences from theRoboCup challenge. (Tech. Rep. No. LIP6 1998/041). Laboratoire d’Informatiquede Paris 6.

Dubois, E., Du Bois, P., Dubru, F., & Petit, M. (1994). Agent-oriented requirementsengineering: A case study using the Albert language. In A. Verbraeck, H.G. Sol, &



P.W.G. Bots (Eds.), Proc. Of the Fourth International Working Conference onDynamic Modelling and Information System – DYNMOD-IV. Delft UniversityPress.

Iglesias, C. A., Garijo, M., González, J. C., & Velasco, J. R. (1998). Analysis and designof multiagent systems using MAS-CommonKADS. In M. P. Singh, A. Rao, & M.J. Wooldridge (Eds.), Intelligent Agents IV (Vol. 1365, pp. 313-326). Springer-Verlag, Berlin, Germany: Lecture Notes in Artificial Intelligence.

Jennings, N. R., Sycara, K., & Wooldridge, M. (1998). A roadmap of agent research anddevelopment. Journal of Autonomous Agents and Multiagent Systems, 1(1), 7-38.

Kavakli, V., & Loucopoulos, P. (1998). Goal driven business analysis: An applicationin electricity deregulation. CAiSE’98. Pisa, Italy.

Kendall, E. A. (1998). Agent roles and role models: New abstractions for multiagentsystem analysis and design. Proceedings of the International Workshop onIntelligent Agents in Information and Process Management, Bremen, Germany.

Mylopoulos, J., Borgida, A., Jarke, M., & Kourbarakis, M. (1990). Telos: A language forrepresenting knowledge about information systems. ACM Transactions on Infor-mation Systems, 8(4), 325-362.

Mylopoulos, J., Castro, J., & Kolp, M. (2000). Tropos: A framework for requirements-driven software development. In J. Brinkkemper & A. Solvberg (Eds.), Informationsystems engineering: state of the art and research themes (pp. 261-273). Springer-Verlag, Berlin, Germany: Lecture Notes in Computer Science.

Padgham, L., & Winikoff, M. (2002a). Prometheus: A methodology for developingintelligent agents. Proceedings of the Third International Workshop on AgentOriented Software Engineering, at AAMAS’2002, Bologna, Italy.

Padgham, L., & Winikoff, M. (2002b). Prometheus: A pragmatic methodology forengineering intelligent agents. Proceedings of the OOPSLA 2002, Seattle, WA.

van Lamsweerde, A., Darimont, R., & Letier, E. (1998). Managing conflicts in goal-drivenrequirements engineering [Special issue]. IEEE Transactions on Software Engi-neering, 24(11), 908-926.

van Lamsweerde, A. (2000). Requirements engineering in the year 00: A researchperspective. Invited paper to 22nd International Conference on Software Engi-neering ICSE’2000.

Wooldridge, M. (1997). Agent-based software engineering. IEE Proceedings SoftwareEngineering, 144(1), 26-37.

Wooldridge, M., & Jennings, N. R. (1995). Intelligent agents: Theory and practice. TheKnowledge Engineering Review, 10(2), 115-152.

Wooldridge, M., Jennings, N. R., & Kinny D. (2000). The Gaia methodology for agent-oriented analysis and design. Autonomous Agents and Multi-Agent Systems, 3(3),285-312.

Yu, E. (1997). Towards modelling and reasoning support for early-phase requirementsengineering. Proceedings of IEEE International Symposium on RequirementsEngineering RE97.



Yu, E., Du Bois, P., Dubois, E., & Mylopoulos, J. (1997). From organization models tosystem requirements: A cooperating agents approach. In M. P. Papazoglou & G.Schlageter (Eds.), Cooperative information systems: Trends and directions (pp.293-312). Academic Press.

84 Sawyer


Chapter VI

Maturing RequirementsEngineering Process

Maturity ModelsPete Sawyer, Lancaster University, UK

Abstract

The interest in Software Process Improvement (SPI) in the early 1990s stimulatedtentative work on parallel models for Requirements Engineering (RE) processimprovement in the late 1990s. This chapter examines the role of SPI and the implicationsof the exclusion of explicit support for RE in the most widely used SPI models. Thechapter describes the principal characteristics of three RE-specific improvementmodels that are in the public domain: the Requirements Engineering Good PracticeGuide (REGPG), the Requirements Engineering Process Maturity Model (REPM), andthe University of Hertfordshire model. The chapter examines the utility of these modelsand concludes by considering the lessons learned from industrial pilot studies.

Introduction

The risks posed to software development projects by weak requirements engineering(RE) practice have become widely recognized during the last decade. This has spawneda great deal of investment in RE methods, tools, and training by practitioner organizationsand in RE research by the wider software and systems engineering communities.

Maturing Requirements Engineering Process Maturity Models 85


The focusing of attention on RE during the early 1990s coincided with the deploymentof software process improvement (SPI) that was stimulated by Humphrey’s pioneeringwork in the 1980s (Humphrey, 1989). However, a European survey of organizationsengaged in SPI programs during this period (Ibanez & Rempp, 1996) confirmed that theSPI models then available offered no panacea for RE problems. Indeed the organizationsconsulted identified requirements specification and the management of customer re-quirements as the principal problem areas in software development that they faced. Evenenthusiastic adopters of SPI programs found that while SPI brought them significantbenefits, their problems with handling requirements remained stubbornly hard to solve.The Software Engineering Institute’s Capability Maturity Model for Software (SW-CMM) (Paulk, Curtis, Chrissis, & Weber, 1993), which was becoming widely deployedat this time, touched on RE practices but provided little specific guidance. To redress this,the Requirements Engineering Adaptation and IMprovement for Safety and dependabil-ity (REAIMS) project conducted the first systematic application of the principles of SPIspecifically for RE. This resulted in the publication of the Requirements EngineeringGood Practice Guide (REGPG) (Sawyer, Sommerville, & Viller, 1999; Sommerville &Sawyer, 1997) in 1997.This chapter reviews the state-of-the-art of process improvement for RE. It starts byreviewing the background to process improvement in the software and systems engineer-ing industry. It then considers the nature of RE processes and the pressures and trendsthat have merged in recent years. It argues that for sociotechnical systems, RE practiceneeds to be particularly strong. It then reviews three RE process improvement methodsand examines the extent to which they have been validated. The chapter concludes bysummarizing the options open to organizations seeking to systematically improve theirRE processes.

SPI Models and Standards

Humphrey’s pioneering work on Software Process Improvement (SPI) in the 1980s(Humphrey, 1989) led to the development of the Capability Maturity Model for Software(SW-CMM), developed at the Software Engineering Institute under the sponsorship ofthe United States Department of Defense. Humphrey’s work reflected a realization thatthe piecemeal adoption of better methods and tools would not deliver the improvementsin software quality increasingly demanded by customers. Rather the whole developmentlifecycle needed to be addressed in order to identify weak areas and focus improvementefforts. From the customer’s perspective, SPI allows software contractors to be assessedagainst a common model and provides a stimulus for contractors to increase productquality and meet cost and delivery targets. From the contractor’s perspective, SPIrepresents a strategic organizational tool for containing costs and increasing market-share.The SW-CMM does this by defining a generic model of the software developmentprocess structured around five maturity levels. Process maturity represents the degreeto which a process is defined, managed, measured, controlled, and effective (Paulk,

86 Sawyer


Level 1 Initial

Level 2 Repeatable

Level 4 Managed

Level 5 Optimizing

Level 3 Defined

Curtis, Chrissis, & Weber, 1993). The more mature a process, the more it is possible toaccurately forecast and meet targets for cost, time of delivery, and product quality. Asa process becomes more mature, the range within which results fall is narrowed. Theemphasis moves from understanding the software process through exerting control overthe process to achieving on-going improvement.The SW-CMM maturity levels range from level 1 (initial), which is an ad hoc, riskyprocess, to level 5 (optimizing), where a process is robust, adaptive, and subject tosystematic tuning using experiential data (Figure 1). Each maturity level has a focus thatis defined by a number of key process areas (KPAs). The KPAs effectively set capabilitygoals that should be met if the supporting key practices are adopted and standardized.The set of key practices prescribed for each KPA define how the KPA can be satisfiedand, since SPI is concerned with organizational maturity, institutionalized.SW-CMM level 2 (Repeatable) is interesting because its focus is on project managementand is concerned with gaining control of the process. It is also the one level to explicitlyaddress requirements engineering. It does this by defining Requirements Managementas a level 2 KPA (the others are software project planning, software project tracking andoversight, software subcontract management, software quality assurance, and softwareconfiguration management).Since achieving level 2 is the initial target of almost all SW-CMM-led improvementprograms, the SW-CMM has had the effect of greatly raising awareness of requirementsmanagement. It has stimulated the market for support tools and has made it more widely(though still far from universally) practiced. In this respect, therefore, it has beenenormously beneficial. However, implementing requirements management is hard (Fowler,Patrick, Carleton, & Merrin, 1998), in part because it exposes weaknesses elsewhere inthe requirements process. For example, one of the practices mandated for the require-ments management KPA is the allocation of requirements to software subsystems.Arriving at the stage where a set of requirements are ready for allocation (by successfullyeliciting, validating, negotiating, and prioritizing them) is itself a complex and error-proneprocess for which the SW-CMM provides no explicit help.

Figure 1. The five-level SW-CMM process maturity model

Level 1Initial

Level 2Repeatable

Level 3Defined

Level 4Managed

Level 5Optimizing



The omission of detailed advice for the systematic improvement of requirementsprocesses is true of all SW-CMMs (including the SW-CMMI (SEI, 2002)), of the draft ISO/IEC 15504 (Garcia, 1997; Konrad & Paulk, 1995) international standard for softwareprocess assessment, and of the ISO9001-3 quality standard (Paulk, 1994). However helpfor requirements processes is not entirely lacking. There are software and systemengineering standards such as ESA PSS-05 (Mazza, Fairclough, Melton, De Pablo,Scheffer, Stevens, Jones, & Alvisi, 1994), which provide valuable and explicit guidanceon requirements practice. However these do not address systematic process improve-ment. They do not provide a method for assessing the weak points in an RE process ormap out a route for the incremental adoption of their recommended practices. Feworganizations can afford to make revolutionary changes to their requirements processes,so they need help in planning and controlling evolutionary improvement so as to minimizethe risk that inevitably accompanies change. This is the great strength of SPI.

The RE Process

Perhaps the most orthodox model of the RE process is that represented by the followingthree IEEE standards (it is interesting to note that RE process is defined implicitly in termsof documents that are products of the process):

• IEEE std 1362-1998 Guide for Information Technology - System Definition -Concept of Operations (ConOps) Document (IEEE, 1998a)

• IEEE std 1233-1998 Guide for Developing System Requirements Specifications(IEEE, 1998b)

• IEEE std 830-1998 Recommended Practice for Software Requirements Specifica-tions (IEEE, 1998c)

This process begins with scoping a problem and, in very broad terms, the solution (theconcept of operations, or ConOps for short). This is followed by a process in whichrequirements are elicited from customers, validated by developers and other technicalspecialists, and constrained by factors associated with the system’s environment. Theproduct of this is a System Requirements Specification document that defines therequirements for the overall system. Following this, the system requirements areallocated to components that will be configured in a system architecture that satisfiesthe system requirements. As part of this, subsets of system requirements are allocatedto software components. For each software component, a further round of analysis isperformed in which a set of software requirements are derived from the allocated systemrequirements. These are documented in a Software Requirements Specification (SRS).This forms the definitive set of requirements that the component must satisfy and issufficiently detailed to allow development to commence.This process has evolved to deal with large custom systems comprising both hardwareand software that are developed for single customers. These are typically developed

88 Sawyer


using a supply chain of sub-contractors responsible for delivering system componentsand who are managed in a hierarchical relationship with, at its root, a main contractor.Such projects still represent a substantial proportion of the economic activity in thesoftware industry, particularly since heterogeneous systems have become increasinglysoftware-intensive. Despite this their relative significance has declined during recentdecades. This is not so much due to a decline in this sector of the industry as increaseselsewhere. These include the booming market for retail software products and thedevelopment of the Internet as a medium for business and entertainment.As the industry has changed shape, the value of orthodox RE has been increasinglycalled into question. Clearly an RE process optimized for large heterogeneous systemsis unlikely to be easily applied to, for example, small short-duration projects. Agiledevelopment methodologies, of which eXtreme Programming (XP) (Beck, 1999) isperhaps the best known, can be seen as a reaction against orthodox software engineeringand, by implication, orthodox RE.Agile methodologies deviate from orthodox RE by eschewing detailed analysis, model-ing, and documentation where a project might move straight from a concept of opera-tions-like activity to development. The promise of agile methodologies to be lightweightand reactive is a seductive one. Although they are not entirely incompatible with SPI(Paulk, 2001), they take what is essentially a programming perspective on systemdevelopment; but for many domains, this is inappropriate. For example, almost all largebusinesses are dependent on their computer systems, yet programmers are seldomequipped to find business solutions. Many systems are embedded within organizationalcontexts to support and manage business processes enacted by people and software.These sociotechnical systems are typically too critical to risk getting wrong, too sensitiveto how the actors interact (which may be dependent on, for example, tacit understandingbetween the actors) to be easily understood, and too complex to make refactoring a viableoption.Sociotechnical systems need careful appraisal of change options. They need carefulanalysis of the problem context and elicitation of user requirements. They need an overallsystem specification that documents the validated customer and user requirements anddefines the new system in terms of its function, its quality attributes, and its contextwithin its environment. They need responsibility for the satisfaction of the systemrequirements to be carefully allocated to appropriate software and human “components”(actors). And they need these components to be specified so that development work,which increasingly takes the form of selecting and integrating off-the-shelf components,can proceed. In these terms, most of the activities and products of orthodox RE processesstill have a vital role to play in ensuring that systems are developed that meet their users’real needs.However it would be naive to think that simply applying IEEE stds 1362, 1233, and 830would guarantee success. There are many practices, techniques, methods, and tools thatmay be deployed to aid RE. Although they embody much accumulated wisdom, REstandards can only set out the general principles or give detailed guidance for particularactivities or documents. They offer no aid for selecting appropriate methods (for example)or for designing an RE process optimized for a particular organization.



Recognition of this problem was the motivation for the RE process improvement workdescribed in the next section.

Process Improvement for RE

Selection of the RE process improvement models for description below has been basedon the following criteria: they should include advice on RE practice, they should presentthis advice within the framework of a maturity model, and they should provide a methodfor assessing existing processes. This set of criteria omits other valuable and pragmaticwork (see below) that can be used for RE process improvement. However the criteria havethe effect of isolating work designed specifically to help organizations integrate REprocess improvement within a general SPI program.There are currently three RE process improvement models that meet the criteria: theRequirements Engineering Good Practice Guide (REGPG), the University of Hertfordshiremodel, and the Requirements Engineering Process Maturity Model (REPM). Othersources of improvement advice exist. In particular Young (2001) and Wiegers (1999) areexcellent textbooks based around sets of recommended RE practices and includepractical advice on how organizations can use them to improve their RE processes. Theseare not reviewed further here simply because they do not include a process maturitymodel or assessment method. However they contain much wisdom and practical advicefor organizations that do not need or wish to undertake a formal, calibrated improvementprocess.The review of improvement models is mainly concerned with the improvement frameworkand assessment rather than the validity of the practices that the models recommend. Allthree models have derived the set of RE practices that they recommend from a variety ofsources, including practices widely used in industry, practices recommended or man-dated in standards, and practices learned from direct experience. However, as Wiegers(1999) warns, “not all … have been endorsed as industry best practices.”Nevertheless the developers of each model have been careful not to recommend practicesthat have not been validated in some form and shown to be practical and practicable forpractitioners.

The Requirements Engineering Good Practice Guide

The REGPG (Sommerville & Sawyer, 1997) was the first public-domain process improve-ment and assessment model for RE. Like the SW-CMM, the REGPG uses an improvementframework with several process maturity levels (Figure 2). The REGPG maturity levels aredesigned to mirror the SW-CMM levels. However, at the time of REGPG’s design, theadoption of RE practices across the industry was patchy (El Eman & Madhavji, 1995;Forsgren & Rahkonen, 1995), and there was insufficient empirical evidence for theexistence of requirements processes that could be characterized beyond defined (level3). The characteristics of highly mature RE processes were essentially unknown, so the

90 Sawyer


REGPG mirrors only the SW-CMM’s bottom three levels (initial, repeatable, anddefined).In the REGPG model:

• Level 1 - Initial level organizations have an ad-hoc requirements process. They findit hard to estimate and control costs as, for example, many requirements have to bereworked. The processes are not supported by planning and review procedures ordocumentation standards. They are dependent on the skills and experience of theindividuals who enact the process.

• Level 2 - Repeatable level organizations have defined standards for requirementsdocuments, which are more likely to be of a consistently high quality and to beproduced on schedule. They also have policies and procedures for requirementsmanagement.

• Level 3 - Defined level organizations have a defined process model based on goodpractices and defined methods. They have an active process improvement programin place and can make objective assessments of the value of new methods andtechniques.

The key to improvement is in adopting appropriate good practices, in the right order, atthe right pace, and with the required degree of strategic commitment. The REGPG distillsguidance on good practice adoption into 66 guidelines (key practices in SW-CMMterms). The practices are classified according to whether they are basic, intermediate,or advanced to reflect, for example, dependencies among the practices.The practices are organized according to process activities. These are the requirementsdocument, requirements elicitation, analysis and negotiation, describing require-ments, system modeling, requirements validation, requirements management, and REfor critical systems. Although analogous to KPAs, REGPG process activities serve onlyto classify good practices and form no part of the maturity framework.

Figure 2. The three-level REGPG process maturity model

Level 1 Initial

Level 2 Repeatable

Level 4 Managed

Level 5 Optimizing

Level 3 Defined



Unlike the SW-CMM (but like the more recent SW-CMMI and ISO/IEC 15504), the REGPGuses a continuous architecture. This means that the REGPG does not prescribe theprocess activities to be targeted at each improvement stage. Instead organizations canadopt practices across a range of process activities according to their priorities.Before improvement can be achieved, causality has to be established between theevident problems and weaknesses in the organization’s RE process. Discoveringweaknesses and identifying priorities for targeted improvement is the role of processassessment. Process assessment is based on a system of checklists designed to revealwhat practices are in use and the extent to which they are used. A checklist of the 66REGPG guidelines is used as the starting point for the assessment. The activities usedin the assessment are:

During the assessment process, each good practice is assessed as being:

• Standardized (score 3). The practice has a documented standard in the organiza-tion and is integrated into a quality management process.

• Normal use (score 2). The practice is widely followed in the organization but is notmandatory.

• Discretionary (score 1). Some project managers may have introduced the practice,but it is not universally used.

• Never (score 0). The practice is never or rarely applied.

The maturity level is calculated by summing the numerical scores for each practice used:

• Level 1 (initial) processes score fewer than 55 in the basic guidelines.

1 Prune checklist Assign a score of 0 (see below) to each practice that is already known not to be used. This is simply a pragmatic step for streamlining the assessment.

2 Select the right people to interview

Knowledge of an organisation's RE practices may reside with many people, particularly where there are different units working on different products/projects. This activity is tasked with selecting a small group of people in order to gain a representative snapshot of RE practice within the organisation.

3 Score process against checklist

The purpose of this stage is to assign scores against each practice for which a score can be confidently assigned and to flag those practices where the extent of adoption is uncertain.

4 Resolve uncertainty This stage focuses on seeking additional information (perhaps by interviewing other people, looking for documentary evidence, etc.) that allows a score to be assigned to the uncertain practices identified at stage 3.

5 Compute maturity This stage derives an overall maturity score based on the results of stages 1, 3 and 4.

92 Sawyer


• Level 2 (repeatable) processes score more than 55 in the basic guidelines but fewerthan 40 in the intermediate and advanced guidelines.

• Level 3 (defined) processes score more than 85 in the basic guidelines and morethan 40 in the intermediate and advanced guidelines.

The end result is an indicative maturity level for the organization’s RE process and a mapof whether, and to what extent, each of the 66 RE practices described in the REGPG is usedin the RE process. Subsequent improvement is based on identifying un- or under-usedpractices that:

• are likely to yield benefits that outweigh the cost of their introduction; and• can be feasibly introduced given dependencies on underpinning practices.

The practices’ classifications (basic, intermediate, advanced) give some help in select-ing an appropriate subset for introduction. The classifications are supplemented withadditional qualitative information in the good practice guidelines about benefits, how toimplement them, and associated costs and problems. At the end of an REGPG processassessment, therefore, an organization should have the basis for an RE process improve-ment agenda in terms of areas of weakness and options for improvement.The two more recent models described below both share broadly similar aims andcomprise a similar maturity framework.

The Requirements Engineering Process ImprovementModel

The Requirements Engineering Process Maturity Model (REPM) (Gorschek, Svahnberg,& Kaarina, 2003) is targeted at SMEs that, its authors observe, lack the resources to applymodels like the REGPG. Instead, REPM claims to take an approach to the RE process thatis sufficient to, “give an indication of whether a problem exists, and … where the problemareas reside” (Gorschek et al., 2003).REPM uses a six-level maturity model. It actually defines five, but since it is a stagedmodel and level one has 11 actions (analogous to SW-CMM key practices or REGPGpractices) associated with it, there is an implicit level zero that broadly corresponds tothe SW-CMM’s initial level. Each action is associated with one of the levels 1 to 5 and,additionally, is classified according to three process activities (called, in REPM, mainprocess areas, or MPAs): elicitation, analysis and negotiation, and management. Eachmaturity level has a set of actions defined for it under each of the three MPAs. Despitetheir superficial similarity, MPAs are unlike SW-CMM KPAs, which are only associatedwith a single maturity level. However MPAs are also different to process activities in theREGPG where it is not obligatory to implement practices for each process activity in orderto achieve a given maturity level.



MPAs may be further classified into sub-process areas (SPAs). For example, theElicitation MPA comprises stakeholder identification, stakeholder consulting, domainknowledge, and scenario elicitation. The authors argue that this allows the model toevolve easily since a composite action may be promoted to an SPA allowing new actionsto be derived from it.REPM is designed for project rather than organizational assessment. Like the REGPG, ituses checklist-driven interviews of key personnel in order to make an assessment.Because an REPM assessment is scoped at the project level, selection of personnel tointerview defaults to the person responsible for RE in the project under assessment. Thisobviates the need to select a range of people across an organization (c.f. step 1 in theREGPG assessment model) and minimizes the interaction between assessor and practi-tioners.The project evaluation checklist is, like that of the REGPG, a list of all 60 actions. REPMrecognizes that failing to implement an action does not necessarily fatally weaken the REprocess, provided there is a sound rationale for not doing so. Producing a user manualdraft (a level 2 action) may be meaningless for the development of an embedded system,for example. This allows checklist actions to be marked satisfied-explained. Actions inthis category carry the same weight as completed actions.As with the REGPG, the authors of REPM have selected a set of RE practices (actionsin REPM terms) and made a judgment about how fundamental they are to an RE process.Because REPM uses a staged model, each action is locked in to a particular maturity level.To achieve a maturity level n, a process needs to have completed or satisfied-explainedall of the actions associated with levels one through n.

The University of Hertfordshire Model

The RE process improvement model (Beecham, Hall, & Rainer, 2003) developed at theUniversity of Hertfordshire is a direct adaptation of the SW-CMM framework for REprocesses. This is intended to help dovetail RE process improvement with a wider SW-CMM-based software process improvement programme.The Hertfordshire model uses the 5 SW-CMM maturity levels (Figure 1) to classify REprocesses. Since it is based upon the SW-CMM, it uses a staged architecture in whicha set of 68 practices (called processes) are mandated for each maturity level. Like theREGPG and REPM, these are classified according to RE process activities, called phases.These are management, elicitation, analysis and negotiation, documentation andvalidation. Like REPM MPAs, each phase in the Hertfordshire model defines a set ofprocesses at each maturity level.As with the other RE process improvement models reviewed here, the Hertfordshiremodel draws its set of processes from analysis of RE practice in industry (including Hall,Beecham, & Rainer, 2002). However, to help integrate the model with the SW-CMM, someprocesses are drawn directly from the SW-CMM. For example, the Hertfordshire level 2process P1 below is essentially the same as the SW-CMM level 2 requirements manage-ment KPA commitment to perform key practice.

94 Sawyer


P1. Follow a written organizational policy for managing the system requirements allo-cated to the software project.Process assessment is broadly similar to that of the REGPG even to the extent that, ascurrently defined in the available documentation, it reflects a continuous rather than astaged improvement model. In order to assess the extent to which a process is satisfiedby an organization, the Hertfordshire model allocates a score to each process againstthree assessment criteria. These are:

• Approach. A measure of the organizational commitment and capability.• Deployment. A measure of the extent to which a process is implemented across the

organization.• Results. A measure of the success of a process’ implementation.

Each process is assessed against each of these criteria and given a rating of:

• Outstanding (10)• Qualified (8)• Marginally qualified (6)• Fair (4)• Weak (2)• Poor (score 0)

The average of the score for approach, deployment, and results is recorded for eachprocess. Hence if a process was marginally qualified in terms of approach, fair in termsof deployment, and weak in terms of results, it would rate an average score of fair (4). Thescores are then summed for each phase (for example, to assess the strength of require-ments management in an organization), and the sum of all five phases yields an overallscore.The Hertfordshire model is still under development. At the time of writing, the model hasnot been calibrated to map overall scores onto maturity levels, and the relationship ofthis to the staged model implied by the association of processes with maturity levels hasnot been worked through. It has undergone an initial validation phase that has focusedon the overall framework and the processes and process descriptions used for maturitylevel 2. The set of processes and process descriptions for levels 3 to 5 currently exist indraft form.



Experience of RE Process Improvement

Process improvement is a costly activity that requires substantial investment. Organiza-tions therefore require confidence in the improvement models that they use. This is notsimply confidence that the set of practices that a model embodies are proven in industry.Confidence is required that the maturity framework and assessment method will notcaricature the organization’s processes. Organizations need to know that the processweaknesses revealed by an assessment are real weaknesses that inhibit process perfor-mance. They also need to know that the remedial action proposed by process analystswill address real organizational priorities in a cost-effective way. Validation is importantfor establishing confidence in improvement models, and each of the models reviewed inthe previous section have undergone some form of validation.

REGPG

More than 10,000 copies of the REGPG have been sold and, as the longest-establishedand most widely disseminated model, REGPG has undergone the most extensive valida-tion. It has been the subject of two projects specifically intended to validate and improvethe model: Qure (Kauppinen, Aaltio, & Kujala, 2002) and Impression (Sommerville &Ransom, 2003).The Qure project conducted by the Helsinki University of Technology included an REprocess improvement theme. The REGPG was evaluated as part of this, in which the modelwas piloted in four companies working in a range of application domains. The scope ofthe analysis was to discover whether the REGPG process analysis method was accurateand usable. The question of whether a subsequent improvement cycle based upon theresults of the analysis resulted in real improvement was outside the project’s scope.Qure found that, in the case studies used, the REGPG yielded useful results and wasappropriate for organizations beginning an RE process improvement programme. A keyweakness discovered was that the selection of good practices to address revealed

Table 1. Summary of RE improvement models

Model Maturity levels CMM key process area analogues?

CMM key practice analogues?

Staged or continuous?

REGPG 3 Process activities but no direct analogy

Good practice guidelines

Continuous

REPM 6 (1-5 with an implicit level 0)

Main process areas but no direct analogy

Actions Staged

Hertfordshire model

5 Phases but no direct analogy

Processes Staged but assessment is currently continuous

96 Sawyer


process weaknesses required more guidance and that, as a result, companies tended tobe over-ambitious in the improvement programs that they undertook.This general point was echoed in the results of the Impression project, which concludedthat the assessment method was too passive. The scope of the REGPG validation inImpression was wider than that of Qure. It involved nine companies from a variety ofdomains and ran for a full improvement cycle, from initial assessment through goodpractice introduction to follow-up assessment. Like Qure assessment and improvementpiloting was performed by a third-party organization. However REGPG authors acted astrainers and consultants for the staff performing the process assessments.The passivity of the assessment method emerged when, perhaps unsurprisingly, itbecame apparent that the companies attached greater priority to actual improvement thanmere diagnostics and maturity classification. The assessment method was modified toinclude an explicit step for selecting good practices to address the revealed weaknesses.This was backed up with the development of a decision support tool that processed theanalysis data and listed those best practices likely to provide solutions most cost-effectively.Other significant results included:

• Implicit dependencies between practices (for example, that intermediate practicescannot be introduced until appropriate basic practices have been deployed) weresometimes wrong. This implies greater-than-anticipated freedom of choice in theselection of practices for introduction and is something that would be hard toaccommodate in a staged architecture.

• The maturity model was not entirely generic, and different norms of practice thatderive from different priorities across application domains were not accuratelyreflected. The REGPG evolved from the experiences of the REAIMS project’sindustrial partners, who worked in dependable systems domains. The REGPGinevitably retains some of this flavor, which fits slightly awkwardly with, forexample, sociotechnical systems.

At the end of the Impression assessment-improvement cycle, a follow-up assessmentwas performed. This established that, in terms of the REGPG maturity model, all but oneof the nine companies had improved their RE processes. Four had moved from initial torepeatable. The remaining four had all improved their score but remained at the initiallevel. The strategies that companies used to improve ranged from concentrating onfurther embedding existing practices within company standard procedures to introduc-ing large numbers of new practices (one company introduced 14).Although Impression covered a whole improvement cycle and appears to demonstratethe REGPG’s utility for improving RE processes, there was insufficient time to follow thisthrough and establish whether increased process maturity in REGPG terms was reflectedin concrete business benefits. The signs are good but unproven.



REPM

Gorschek et al. (2003) describe the evaluation of REPM using a pilot study involving fourcompanies. These were SMEs of the size for which REPM was designed. The scope ofthis pilot was more restricted than that of Qure or Impression and had a dual aim of usingREPM to discover norms of RE practice (which we ignore here) and of validating REPM.Despite the limited scope of the REPM validation, the results indicate that its lightweightassessment method yields useful results. REPM as a vehicle for improvement has notbeen demonstrated, but within the limited aims of REPM, the model appears to showpromise as an assessment tool for SMEs. REPM was explicitly designed to be lightweight,and the authors report no serious problems with applying it. However validation of themodel’s applicability does not appear to have been an explicit goal of the evaluation.

University of Hertfordshire Model

The methodology for validation of the Hertfordshire model differs from that used for theREGPG and REPM. The model’s development was in part influenced by a study of REpractice in 12 companies (Hall et al., 2002). Validation of the model itself, however, hasto date been performed by assessment by a panel of experts rather than deployment inpractitioner companies. At the time of writing, the results of this exercise were beingprocessed and will feed into maturation of the model.

Conclusion

Given the level of interest in SPI in recent years, RE process improvement has receivedsurprisingly little attention from the SPI and RE research communities or from industry.This may be because RE process improvement takes place but takes place adequatelywithout the formal framework of a CMM-like maturity model. Nevertheless RE processimprovement is an important issue, as surveys such as that reported by Ibanez & Rempp(1996) clearly demonstrate.Organizations interested in RE process improvement and that, perhaps because ofinvestment in wider SPI programs, wish to use a maturity level framework now have achoice of at least the three improvement models reviewed here.Of these, the REGPG has the benefit of being widely known. It has been validated acrossa range of domains and its strengths and weaknesses have been identified. The REPMand the Hertfordshire models currently occupy more specialized niches. REPM has beenpurposely designed as a lightweight method suitable for SMEs. It is perhaps the modelmost in tune with the current mood for agile and lightweight methodologies, althoughit has not yet completed a full validation cycle.The Hertfordshire model is a work in progress that is carefully aimed at the manycompanies that have already invested in SW-CMM based improvement programs. If

98 Sawyer


subsequent development can complete the model and integrate it within the SW-CMMframework (and track CMM developments), then it has the potential to offer substantialbenefits to companies.

References

Beck, K. (1999). Extreme programming explained: Embrace change. Boston: Addison-Wesley Longman.

Beecham, S., Hall, T., & Rainer, A. (2003). Defining a requirements process improvementmodel. (Technical Rep. No. TR379). University of Hertfordshire.

El Eman, K., & Madhavji, N. (1995). A Field Study of Requirements Engineering Practicesin Information Systems Development. Proceedings of the Second IEEE Interna-tional Symposium on Requirements Engineering (RE95) (pp. 68-80). York, UK.

Forsgren, P., & Rahkonen, T. (1995). Specification of customer and user requirements inindustrial control system procurement projects. Proceedings of 2nd IEEE Interna-tional Symposium on Requirements Engineering (RE95), 81-88.

Fowler, P., Patrick, M., Carleton, A., & Merrin, B. (1988). Transition packages: Anexperiment in the introduction of requirements management. Proceedings of ThirdInternational Conference on Requirements Engineering (ICRE’98), 138-147.

Garcia, S. (1997). Evolving improvement paradigms: Capability maturity models & ISO/IEC 15504 (PDTR). Software Process: Improvement and Practice, 3(1), 47-58.

Gorschek, T., Svahnberg, M., & Kaarina, T. (2003). Introduction and application of alightweight requirements engineering process evaluation method. Proceedings ofRequirements Engineering Foundations for Software Quality ’03 (REFSQ’03),83-92.

Hall, T., Beecham, S., & Rainer, A. (2002). Requirements problems in twelve softwarecompanies: An empirical analysis, IEE Proceedings-Software, 149(5), 153-160.

Humphrey, W. (1989). Managing the software process. Boston: Addison-WesleyLongman.

Ibanez, M., & Rempp, H. (1996). European survey analysis. (Tech. Rep.). EuropeanSoftware Institute.

IEEE Std 830-1998. (1998c). IEEE recommended practice for software requirements. NewYork: IEEE.

IEEE Std 1233-1998. (1998b). IEEE guide for developing system requirements specifica-tions. New York: IEEE.

IEEE Std 1362-1998. (1998a). IEEE guide for information technology - system definition- concept of operations (ConOps) document. New York: IEEE.

Kauppinen, M., Aaltio, T., & Kujala, S. (2002). Lessons learned from applying therequirements engineering good practice guide for process improvement. Proceed-ings of Seventh European Conference on Software Quality (QC2002), 73-81.



Konrad, M., & Paulk, M. (1995). An overview of SPICE’s model for process management.Proceedings of Fifth International Conference on Software Quality, 291-301.

Mazza, C., Fairclough, J., Melton, B., De Pablo, D., Scheffer, A., Stevens, R., Jones, M.,& Alvisi, G. (1994). Software engineering guides. London: Prentice Hall.

Paulk, M. (1994). A comparison of ISO 9001 and the capability maturity model forsoftware, CMU/SEI-94-TR-12, Software Engineering Institute.

Paulk, M. (2001). Extreme programming from a CMM perspective. IEEE Software, 18(6),19-26.

Paulk, M., Curtis, W., Chrissis, M., & Weber, C. (1993). Capability maturity model forsoftware, Version 1.1. CMU/SEI-93-TR-24. Software Engineering Institute.

Sawyer, P., Sommerville, I., & Viller, S. (1999). Capturing the benefits of requirementsengineering. IEEE Software, 16(2), 78-85.

SEI. (2002). CMMI for software engineering, version 1.1, continuous representation(CMMI-SW, V1.1, Continuous). CMU/SEI-2002-TR-028. Software EngineeringInstitute.

Sommerville, I., & Ransom, J. (2003). An industrial experiment in requirements engineer-ing process assessment and improvement. (Tech. Rep). Lancaster University.

Sommerville, I. & Sawyer, P. (1997). Requirements engineering - a good practice guide.Chichester: John Wiley.

Wiegers, K. (1999). Software requirements. Redmond, WA: Microsoft Press.Young, R. (2001). Effective requirements practices. Boston: Addison-Wesley Longman.

100 Greer


Chapter VII

RequirementsPrioritisation forIncremental and

Iterative DevelopmentD. Greer, Queens University Belfast, UK

Abstract

The problems associated with requirements prioritisation for an incremental anditerative software process are described. Existing approaches to prioritisation arethen reviewed, including the Analytic Hierarchy Process, which involves makingcomparisons between requirements and SERUM, a method that uses absolute estimationsof costs, benefits, and risks to inform the prioritisation process. In addition to these,the use of heuristic approaches is identified as a useful way to find an optimal solutionto the problem given the complex range of inputs involved. In particular geneticalgorithms are considered promising. An implementation of this, the EVOLVE method,is described using a case study. EVOLVE aims to optimally assign requirements toreleases, taking into account: (i) effort measures for each requirement and effortconstraints for each increment; (ii) risk measures for each requirement and risk limitsfor each increment; (iii) precedence constraints between requirements (where onerequirement must always be in an earlier or the same increment as another); (iv)coupling constraints between requirements (where two or more must be in the sameincrement); and (v) resource constraints (where two or more requirements may not bein the same increment due to using some limited resource). The method also handlesuncertainty in the effort inputs, which are supplied as distributions and simulated

Requirements Prioritisation for Incremental and Iterative Development 101


using Monte Carlo simulation before carrying out the genetic algorithm operations.In addition to handling uncertainty, EVOLVE offers several advantages over existingmethods since it handles a large range of factors. The overall implementation of themethod allows the inputs to be changed at each iteration, and so better fits reality whererequirements are changing all the time.

Introduction

In any given project, requirements arise from various stakeholders. These stakeholdersmay be users, developers, project managers, business managers, or other categories ofpeople affected by the system. In the case of new software applications, there aretypically a large number of requirements, some of which are essential, others desirable,and some relatively unimportant. For existing applications, there will be a backlog of newrequirements, potential fixes, and enhancements, again with differing priorities. In bothcases it is usually impractical to implement all requirements simultaneously because ofthe cost involved, staff limitations, and market or user pressures to have the softwareimplemented. Thus some form of prioritisation is necessary. The output of this processwill depend on the effort required for each requirement against the overall effort available,the value arising out of delivering certain requirements at a given time, the risks incurredby delivering or not delivering given requirements, and on dependencies betweenrequirements. In addition to this we have the preferences of business and developerstakeholders, who may be of different levels of importance and may be geographicallydispersed with different viewpoints about what should be delivered and when. For someof these stakeholders a given requirement may be essential to the success of the product;others may believe that it might even damage the success of the product. In betweenthese extremes some stakeholders may hold the view that a requirement is unimportantbut hold no objection to it being included (Davis, 2003). Overall this is a complex problem,which is very difficult to solve to the satisfaction of all concerned. Management ofrequirements including priority assignment has been identified as a key success factorfor commercial enterprises (De Gregorio, 1999). In the case of bespoke software devel-opment, there may be a small number of stakeholders, but in the case of commercial off-the-shelf software there may be hundreds or thousands of stakeholders (Regnell, Host,Natt och Dag, Beremark, & Hjelm, 2001).

Problem Discussion

In recent years there has been an increasing recognition that an incremental approachto software development is often more suitable and less risky than the traditionalwaterfall approach (Greer, Bustard, & Sunazuka, 1999a). This preference is demonstratedby the current popularity of agile methods, all of which adopt an incremental approachto delivering software rapidly (Cockburn, 2002). This shift in paradigm has been brought

102 Greer


about by many factors, not least the rapid growth of the World Wide Web, theconsequent economic need to deliver systems faster (Cusamano & Yoffie, 1998), and theneed to ensure that software better meets customer needs. Hence, we will concentrateon this process model in our problem discussion.Planning and developing software is a very complex venture. As illustrated in Figure 1stakeholder preferences, effort constraints, dependency constraints, resource con-straints, and risk constraints all contribute to the complexity.In developing computer-based systems, the inputs of all stakeholders should be takeninto account during the planning and development processes (Hart, Hogg, & Banerjee,2002). In prioritising requirements, similarly, the viewpoints of all affected stakeholdersmust be taken into account (Bubenkbo, 1995). This is already a complicated process ifthere are several stakeholders with diverging viewpoints (Jiang, Klein, & Discenza, 2002).However there are other important factors such as the available effort for a given systemor release versus the effort required. There are also likely to be dependencies betweenrequirements. This may be due to the fact that certain requirements must be in place beforeothers. It could also be that two or more requirements must be delivered together orindeed that they should not be delivered together in a certain timeframe due to someresource constraint. Other factors are the level of risk the organisation is exposed to ina given system or a given release (Charette, 1989). The nature of the software processis also relevant to the problem. In what follows we will assume that whatever the process,it will result in individual releases. This is true even of the waterfall model, where theintention is to deliver a complete system, but there will be subsequent releases in themaintenance phase to cover deferred requirements, errors, and enhancements (Rajlich& Gosavi, 2002).

Figure 1. Complexity of software release planning

Stakeholders: Need to satisfy each group of stakeholders

Resource constraints: Some requirements must not be in the same

release

Effort constraints:

limited for each release

Precedence constraints : Some requirements must be delivered before

others

Coupling constraints: Some

requirements are only valuable if

delivered together Risk Constraints: Each release must be below an acceptable

risk level

Release Planning



Stakeholders Viewpoints and Increment Planning

A software system at any stage of its life can be described by a set R1 of requirements,that is, R1= {r1,r2… rn}. Using an incremental approach, at the first stage (k=1) a set ofrequirements are planned for delivery as Inc1. At subsequent stages (k>1), new require-ments are added and others are removed and a new subset of requirements is plannedfor delivery in the next increment Inc2. This continues for all increments, Inck.Suppose there are q Stakeholders S1,S2,…,Sq who have been assigned a relative impor-tance between 0 and 1 by a project manager. Each stakeholder Sp assigns a priority, prio(ri,Sp, R

k) to each requirement ri in the set Rk at phase k. Prio() is a function: (ri, Sp, Rk) →{1,2,..,

σ }, performed by each stakeholder, Sp, where σ is the maximum priority score that canbe assigned. Using the scheme suggested in Davis (2003), one practical interpretationthis might be where σ = 5. In this scenario, prio(r1, S1, R

1)=5 means that for stakeholderS1 the first release will be useless without r1; prio(r1, S1, R

1)=4 means that the requirementshould be included in R1; prio(r1, S1, R

1)=3 means that S1 is neutral on the issue for r1 inR1; prio(r1, S1, R

1)=2 means that the requirement should be excluded from R1; prio(r1, S1,R1)=1 means that if r1 is included in R1, then the release will not be useful to S1.Thus the output from the release planning process is a definition of increments Inck,Inck+1, Inck+2, … with Inct ⊂ Rk for all t = k, k+1, k+2, … The different increments aredisjointed, that is, Incs ∩ Inct = ∅ for all s,t ∈ {k, k+1, k+2, …}. The unique function ωk

assigns each requirement ri of set Rk the number s of its increment Incs, i.e., ωk: ri ∈ Rk →ωk(ri)= s ∈ {k, k+1, k+2, …}.

Effort Constraints

Effort estimation can be described as a function assigning each pair (ri, Rk) an effort

estimate, effort() that is, effort() is a function (ri, Rk) → ℜℜℜℜℜ+ where ℜℜℜℜℜ+ is the set of positive

real numbers. These effort estimates are specific to a particular phase Rk, since effortsmay be re-estimated following any increment. It is likely that the effort available for agiven increment Inck is limited to a fixed value Sizek. Hence the sum of the effort estimatedfor all requirements in a planned increment must be within this limit. Thus Σ r(i) ∈ Inc(k)effort(ri, R

k) ≤ Sizek for all increments Inc(k).

Dependency Constraints

Any set of requirements will contain dependencies wherein one requirement must alwaysbe before or after another. Thus for all iterations k there is a partial order Ψk on the productset Rk x Rk such that (ri, rj) ∈ Ψk implies ωk(ri) ≤ ωk(rj). In an incremental approach, havinga constraint that a given requirement is before some other is also met if they are in thesame increment.Similarly, there may be certain requirements that are only valuable if delivered togetherin the same increment. Thus for all iterations k we define a binary relation xk on Rk suchthat (ri, rj) ∈ ξk implies that ωk(ri) = ωk(rj) for all phases k.

104 Greer


Additionally there are resource constraints to consider, where certain combinations ofrequirements may not be delivered in the same increment. This may be due to the fact thatthey share some limited resource. Hence resource(t) represents the resource capacity oft. In this case, there are index sets I(t) ⊂ {1,…,n} such that card({ri ∈ Rk: i ∈ I(t)}) ≤resource(t) for all releases k and for all resources t.

Risk Constraints

All development activities have associated risks, and a development team may wish tolimit the extent of exposure to risk in a given increment. We define risk as the likelihoodthat some loss will be incurred in implementing a requirement due to some event andintroduce a risk estimate for each requirement. Thus for each pair (ri,R

k) of requirementri as part of the set Rk the estimated value for implementing this effort; that is, risk is a ratioscaled function risk: (ri, R

k) → [0,1), where ‘0’ means no risk at all and ‘1’ stands for thehighest risk.This idea of limiting increment risk is based on the idea of a risk referent, in the past appliedat project level (Charette, 1989). Riskk, refers to this maximum and denotes the upperbound for the acceptable risk in Inck. This involves summing the risk scores for allrequirements in a given increment and checking the constraint Σ r(i) ∈ Inc(k) risk(ri, R

k) ≤ Riskk

for each increment k.

Problem Statement for Software Release Planning

We can now formulate our problem as follows (Greer & Ruhe, 2004):For all requirements ri ∈ Rk determine an assignment ω*: ω*(ri)= m of all requirements ri toan increment ω*(ri)= m such that

(1) Σ r(i) ∈ Inc(m) effort(ri, Rm) ≤ Sizem

for m = k,k+1,… (Effort constraints)(2) Σ r(i) ∈ Inc(m) risk(ri, R

m) ≤ Riskm

for m = k,k+1,… (Risk constraints)(3) ω*(ri) ≤ ω*(rj) for all pairs (ri. rj) ∈ Ψk (Precedence constraints)(4) ω*(ri) = ω*(rj) for all pairs (ri. rj) ∈ ξk (Coupling constraints)(5) card({ri ∈ Rk: i∈ I(t)}) ≤ resource(t)

for all releases k and all sets I(t) related to all resources t(Resource constraints)

(6) A = Σp=1…,q λp [Σr(i)∈R(k)benefit(ri,,Sp,ω*)] ⇒ L-max! with

benefit(ri,Sp,Rk,ω*)=[σ-prio(ri,Sp, R

k) +1][τ - ω*(rj,)+1] andτ = max{ω*(ri): ri ∈ Rk}



The function (6) is to maximize the weighted benefit over all the different stakeholders.For any stakeholder the benefit from the assignment of an individual requirement to anincrement is the higher, the earlier it is released, and the more important it is judged. L-max means to compute a set of L best solutions (L>1) so that the uncertainty of the inputsis taken into account and the analyst retains the decision-making power

Existing Requirements PrioritisationApproaches

The simplest approach to requirements prioritisation is where experts abstract acrosscriteria to compare requirements and assign a ranking. This can be carried out practicallyby pair-wise comparison or traditional sorting methods such as a bubble sort, minimalspanning tree, and binary search tree. There are also several well-established methodsthat have been applied such as card-sorting and laddering (for example, Maiden & Rugg,1996; Rugg & McGeorge, 1997), which typically involve grouping cards according togiven criteria and using the groups.

Prioritisation using AHP

One now well-documented technique for prioritisation is the Analytic Hierarchy Process(AHP) (Saaty, 1980). This has been applied to the real-world problem of requirementsprioritisation (Karlsson & Ryan, 1997; Karlsson, Wohlin & Regnell, 1988). To date AHPhas not been specifically applied to incremental software delivery. However, if depen-dencies between requirements were taken into account, it could easily be applicable.With AHP, the relative importance of the assessment criteria is first determined throughtheir pair-wise comparison. For example, if the criteria for assessing requirements aretaken to be cost-benefit ratio, impact on system quality, and risk-reduction, it might bedecided that impact on system quality is four times as important as cost-benefit ratio andthat risk-reduction is one-third as important as cost-benefit ratio (Table 1). The rest ofthe rows could be inferred from the first row, but more often the user enters all the rows,allowing a consistency calculation to be performed.Using these scores, a weighting for each criterion is derived. This can be achieved bycalculating the eigenvalues for each row or by using the technique of averaging overnormalized columns (Saaty, 1980). In this technique each cell is divided by the sum of its

Table 1: Recording Priorities in AHP

Cost-Benefit Impact on Quality Risk Reduction Cost-Benefit 1 4 1/3 Impact on Quality 0.25 1 1/9 Risk Reduction 3 1/4 1 Sum 4.25 5.25 1.44

106 Greer


column. The result of this for the example is shown in Table 2. The results for each roware summed and normalised by dividing by the number of criteria. In this case the relativevalues for the three criteria are 0.41, 0.11, and 0.48, respectively.A similar approach is then used to assess each candidate requirement in relation to thechosen criteria.The same scoring mechanism is used for all requirement pairs, so that each requirementobtains a preference score with respect to each decision criterion. The overall rating fora requirement is obtained by summing the preference scores and multiplying by theweighting for that criterion. This rating is then used for the prioritisation.In an incremental model context, it is then a matter of assigning these requirements toreleases using a greedy-type algorithm.

Prioritisation using Absolute Estimations

Changes can also be ordered by assessing them directly against criteria rather thanrelative to each other. This method can be classified as an absolute assessment approach(Greer, Bustard, & Sunazuka, 1999b). The use of such measurement has a number ofdistinct advantages over relative assessment. One is that fewer assessments are needed– just one for each requirement against each criterion. It also avoids the need to comparerequirements with each other, which can be difficult, especially if they are unrelated.One such approach is SERUM (Greer et al., 1999b), which uses estimations for cost,benefit, development risk, and operational risk reduction to inform the prioritisationprocess. The process as illustrated in Figure 2 starts with a business analysis from whichthe requirements have arisen. These requirements are refined by assessing risks in thecurrent system (Stage 1) and ensuring that new requirements are created or amended toreduce those risks, where appropriate. Similarly since the requirements define theproposed system, the risks associated with the proposed system are assessed and wherepossible the requirements amended or new ones created (Stage 2). The requirements forthe new system are defined in more detail in Stage 3, and cost-benefit analysis is carried

Table 2: Determination of Priorities of Criteria using AHP

Table 3: Prioritising candidate requirements using AHP

Cost-Benefit r1 r2 r3 Norm. Sum r1 1 3 2 0.63 r2 1/3 1 1/9 0.15 r3 ½ ¼ 1 0.21

Cost-Benefit Impact on Quality Risk Reduction Norm. Sum

Cost-Benefit 0.24 0.76 0.23 0.41 Impact on Quality 0.06 0.19 0.08 0.11 Risk Reduction 0.71 0.05 0.69 0.48



out in Stage 4. This is a high-level assessment using a simple scoring system. In Stage5 a risk assessment is made concerning the development of each requirement. Thus wehave the following variables for each requirement: (i) the development risk; (ii) the riskreduction in moving from the current system to the proposed system, as calculated fromStages 1 and 2; (iii) the cost of the requirement; and (iv) the benefit from the requirement.(Note that (iii) and (iv) could be combined as cost-benefit ratio.) Using these estimations,a prioritisation is determined in Stage 8. In practice Stage 8 is carried out by givingpreference to the most important criteria, but alternative viewpoints can be made,ultimately the choice of approach being up to the user. From industrial studies (Greer etal., 1999a), the favoured criteria is often the benefit accrued from the requirement,although in mission, critical systems risk reduction may be more important. The risk plansin Stages 9 and 10 are useful by-products of the process.SERUM does not at present formally handled dependencies between requirements,although this and a means to better support the final decision making process aresubjects of current research.

Figure 2: SERUM approach to prioritising requirements

1. Refine proposed system by assessing risks in the current system

2. Refine proposed system by assessing risks in the proposed system

3. Define Changes

4. Perform cost-

benefit analysis

5. Assess Development Risks for Changes

RiskscurrentSystem

RisksproposedSystem

Costs

Benefits

Risksdevelopment

6. Identify Risk Reduction

Activities

7. Determine Change Plan Change Plan

System Changes

8. Prioritise Changes

9. Create Product Risk

Control Plan for Accepted Risk

10. Create Development

Risk Control Plan for Accepted Risk

Product risk control plan

Business Analysis Models and Recommendations

108 Greer


Using Heuristics

In the combinatorial optimisation field, there are a group of techniques that have beencollectively termed “heuristics”. This grouping generally refers to techniques that try tofind “near-optimal” solutions at reasonable computational cost (Reeves, 1995). Examplesof techniques available for solving NP-hard problems (where deterministic means maynot be feasible) such as the one outlined above for Release Planning include SimulatedAnnealing, Tabu Search, and Genetic Algorithms. We have used Genetic Algorithms forreasons outlined in the next section.

Genetic Algorithms

Genetic algorithms have been derived from an analogy with the natural process ofbiological evolution (Carnahan & Simha, 2001; Holland, 1975). With genetic algorithmsan initial population is created and pairs of solutions, or chromosomes, are selectedaccording to some fitness score. In this process of selection those members of thepopulation with higher scores are given a higher probability of being chosen. Theselected parents are then mixed using an operation known as crossover. Specifically, themethod EVOLVE (Greer & Ruhe, 2004), which we will describe in the next section, makesuse of the “order method” as described in Davis (1991): the crossover operator selectstwo parents, randomly selects items in one of them, and fixes their place in the secondparent (for example, items B and D in Figure 3). These are held in position, but theremaining items from the first parent are then copied to the second parent in the sameorder as they were in originally. In this way some of the sub-orderings are maintained.The resulting offspring is a mixture of its parents. A further operation, mutation, isapplied. This is a random change to the chromosome and is intended to introduce newproperties to the population and avoid merely reaching a local optima rather than theglobal optimum. Since the values in the chromosome must remain constant, the normalapproach to mutation where one or more variables are randomly changed will not work.Hence, in the order method, mutation is effected via random swapping of items in the newoffspring. An example is shown in Figure 3 for the items A and C. The number of swapsis proportional to the mutation rate. The offspring is then added to the population so longas it represents a feasible solution. The population is normally maintained at a predeter-mined level, and so lower-ranked chromosomes are discarded. The net effect of this isa gradual movement toward an optimum solution. Termination of the algorithm can occurafter a certain number of iterations, after a set time, or when improvement has ceased tobe significant.

Figure 3: Illustration of crossover and mutation operators

Chromosome 1 A B C D E Crossover Chromosome 2 E B D C A → Offspring A B D C E

↓ mutation Offspring C B D A E



The extent of crossover and mutation is controlled by the variables crossover rate andmutation rate. The choice of “best” mutation and crossover rates is sensitive to the typeof problem and its characteristics (Haupt & Haupt, 2000).In applying this to requirements prioritisation, the chromosomes are made up of orderedrequirements. Selection involves picking two of these from a randomly created popula-tion. Crossover is then the mixing of requirements in the chosen chromosomes andmutation is a swapping of two requirements in the offspring. A check is then made to seeif the child meets all specified constraints and, if so, it is added to the population. If nota backtracking operation is carried out and the process retried. The population ismaintained at a predetermined number by culling the weakest valued chromosome. Adetailed algorithm is provided in the Appendix.

Solution Approach

In choosing an approach to solving the problems described in the Problem Discussion,the techniques described in the previous section could probably all be adapted for use.However there are two main issues to be resolved, if we are to incorporate the viewpointsof many stakeholders, to apply effort constraints, to manage risk levels, and to takeaccount of dependencies. Firstly, any method needs to be usable and scalable. In thecase of techniques that involve pair-wise comparison there is typically O(n2) compari-sons between n alternatives. For example, using AHP with 20 requirements, a total of 190(n*(n - 1)/2) pair-wise comparisons must be performed for each criterion. Secondly, givensuch a complex problem domain and such a large solution space, it is impossible toincorporate all of the constraints and find an optimum solution with any deterministicprioritisation technique. Given these factors, combinatorial optimisation techniquesseem very suitable. The choice of Genetic Algorithms is based on the work of others,where, for example, Genetic Algorithms have been found appropriate to general casessuch as the Travelling Salesman problem (Carnahan & Simha, 2001) and in softwareengineering to system test planning (Briand, Feng, & Labiche, 2002) and network routeplanning (Lin, Kwok, & Lau 2003).

Evolve Method

In EVOLVE software releases are planned as increments, but the planning process isrepeated at each iteration. At each iteration the inputs include the current set ofrequirements, the constraints as described in (1)-(3) in the section on Problem Statementfor Software Release Planning, and the stakeholder priorities. The objective function (6)in that section is applied for each solution. The purpose of the genetic algorithm is todetermine the best (most optimal) release plan.

110 Greer


At each iteration k, the next planned increment, Inck, is finalised as indicated by the solidborder in Figure 4, and all other undelivered increments, Inck+1, Inck+2, … and so forth aretentatively planned, as indicated by the dashed border.

Algorithms and Tool Support

A greedy-like procedure was applied in order to assign requirements to the increments.Original precedence (2), coupling constraints (3), and resource constraints (4) areimplemented by specific rules used to check each generated solution. This is achievedvia a table of pairs of requirements. In both cases, if any given solution is generated thatviolates either category of constraint, the solution is rejected and a backtrackingoperation is used to generate a new solution.

Description with Sample Project

In evaluation of the method, a sample software project with 20 requirements was used.We have represented this initial set, R1 of requirements by identifiers r1 to r20. Thetechnical precedence constraints in our typical project are represented by the set Y asshown below. This states that r2 must come before r3, r2 before r7, r6 before r15, and r7 beforer15.

Figure 4. EVOLVE approach to assignment of requirements to increments

Requirements

&

Constraints

&

Refined&

Extended…

E V O L V EIncrement1

…

&

Constraints

&

Refined&

Extended&

Constraints

&

Increment2

Increment3

Requirements Requirements

Priorities Priorities Priorities

Iteration 1 Iteration 2 Iteration 3

Increment2

Increment3 Increment3

… … …

Increment1

Increment2

Increment1

Requirements

&

Constraints

&

Refined&

Extended…

E V O L V EIncrement1

…

&

Constraints

&

Refined&

Extended&

Constraints

&

Increment2

Increment3

Requirements Requirements

Priorities Priorities Priorities

Iteration 1 Iteration 2 Iteration 3

Increment2

Increment3 Increment3

… … …

Increment1

Increment2

Increment1



Ψ1 = {(r2,r3), (r2,r7),(r6,r15),(r7,r15)}

Further some requirements were specified to be implemented in the same increment asrepresented by the set x. This states that r10 and r11 must be in the same release, as mustr17 and r8.

ξ1 ={(r10, r11),(r17, r8)}

Resource constraints are represented by index sets for the set of those requirementsasking for the same resource. In our sample project we have a resource T1 that has acapacity of 1 (resource(T1)=1) that is used by requirements r3 and r8. The sample projecthad resource constraints represented by the following index set.

I(T1) = {19,20}

Each requirement has an associated effort estimate in terms of a score between 1 and 10.The effort constraint was added that for each increment the effort should be less than

Table 4: Sample stakeholder-assigned priorities

Stakeholder S1 S2 S3 S4 S5

r1 1 2 3 4 5 r2 5 4 3 2 1 r3 1 1 1 1 1 r4 3 3 2 2 3 r5 4 4 4 4 5 r6 1 2 3 2 1 r7 2 1 1 2 1 r8 4 5 5 4 1 r9 3 3 3 2 4 r10 2 2 2 2 2 r11 5 5 5 4 3 r12 3 4 3 4 3 r13 2 1 1 2 3 r14 1 1 2 2 1 r15 3 5 3 5 4 r16 4 4 4 5 5 r17 5 3 3 3 3 r18 1 1 2 1 2 r19 5 5 5 5 5

Req

uire

men

t

r20 3 3 3 3 2

112 Greer


25, that is, Sizek = 25 for all releases k. Five stakeholders were used to score the 20requirements with priority scores from 1 to 5. These scores are shown in Table 4. As wecan see, different stakeholders in some cases assign more or less the same priority torequirements (as for r3). However the judgment is more conflicting in other cases (as forr1).The stakeholders, S1 to S5, were weighted using AHP pair-wise comparison from a globalproject management perspective. Using the technique of averaging over normalizedcolumns (Saaty, 1980), we obtained the vector (0.174, 0.174, 0.522, 0.043, 0.087) assigningpriorities to the five stakeholders.With regard to the genetic algorithm, we used the RiskOptimizer tool from Palisade (2001)with a default population size of 50 and an auto-mutation function that detects when asolution has stabilized and then adjusts the mutation rate. In preliminary experiments weestablished that it was not possible to consistently predict the best crossover rate. Hencewe used a range of crossover rates for each experiment, from 0.4 to 0.8 in steps of 0.1.

Uncertainty in Effort Estimates

The model used in EVOLVE allows the use of probability distributions rather thandiscrete values for effort. This reflects the real-world difficulties in estimating effort. Inthe case study, a triangular probability distribution was created as shown in Table 5 andsimulated using Latin Hypercube sampling.

Table 5. Definition of triangular probability functions for effort to deliver requirements

Effort Min Mode Max r1 9 10 11 r2 3 4 5 r3 6 7 9 r4 5 6 8 r5 7 9 11 r6 1 2 3 r7 7 9 12 r8 10 12 14 r9 8 9 10 r10 4 5 6 r11 3 4 5 r12 2 3 4 r13 4 5 6 r14 6 7 8 r15 3 5 7 r16 4 6 7 r17 3 5 8 r18 6 7 9 r19 1 3 4

Req

uire

men

t

r20 5 8 9



Table 6. Sample results for release planning under different levels of probability for notexceeding the effort capacity bound Effort = 25 (Risk Referent=1.1)

Probability Benefit (6) Risk Release Assigned Requirements 0.77 1 r2 r6 r8 r13 0.64 2 r3 r7 r12 r15 0.38 3 r10 r11 r14 r12

99% 133

0.82 4 r4 r17 r18 r19 0.98 1 r2 r6 r12 r13 r14 r19 0.44 2 r3 r7 r20 0.41 3 r1 r9 r15

95% 141

0.72 4 r4 r5 r16 0.97 1 r2 r7 r12 r13 r19 0.36 2 r3 r14 r15 r17 0.82 3 r4 r11 r18 r20

90% 144

0.68 4 r6 r9 r10 r16

Figure 5. Sample results from sample project release planning – iterations 1 and 2

…

E V O L V Er2,r6,r12,r13,r14,r19

Iteration 1 Iteration 2

…

r3,r7,r11, r24

Amend constraints & estimates as required

r2,r6,r12,r13,r14,r19

r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14,r15,r16,r17,r18,r19,r20

New requirements{r21,r22,r23,r24}

Delete {r16,r20}

r1,r3,r4,r5,r7,r8,r9,r10,r11,r14,r15,r17,r18,r21,r22,r23,r24

r3,r7,r20

r1,r9,r15

r4,r5,r16

firm

proposedr10,r17,r18, r21

r1,r4,r15, r22

Omitted:r8,r10,r11,

r17,r18

Omitted:r5,r9,r23

…

E V O L V Er2,r6,r12,r13,r14,r19

Iteration 1 Iteration 2

…

r3,r7,r11, r24

Amend constraints & estimates as required

r2,r6,r12,r13,r14,r19

r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14,r15,r16,r17,r18,r19,r20

New requirements{r21,r22,r23,r24}

Delete {r16,r20}

r1,r3,r4,r5,r7,r8,r9,r10,r11,r14,r15,r17,r18,r21,r22,r23,r24

r3,r7,r20

r1,r9,r15

r4,r5,r16

firm

proposedr10,r17,r18, r21

r1,r4,r15, r22

Omitted:r8,r10,r11,

r17,r18

Omitted:r5,r9,r23

114 Greer


This has the effect that the decision maker can plan the releases based on his or herconfidence level in the estimates. In practice there is a trade-off between this level ofconfidence and the benefit achievable, as shown in Table 6. It also means that the adoptedrelease plan has associated with it, a percentage indicating the probability that it will beadhere to its effort estimates.At each iteration for a given effort confidence level, a solution is chosen from the L-best.The first increment is then firmed for implementation, and, at this point, any changes tothe current set of requirements, their effort estimates, the stakeholder priorities, and theconstraints can be made prior to planning the next and future releases. Figure 5 illustratesthe process for our case study for the first two iterations. Suppose that the release planfor 95% confidence in Table 5 is selected to be initiated. After the first iteration, the firstincrement (r2,r6,r12,r13,r14,r19) is firm and will be implemented. After this r21,r22,r23, and r24 areadded, with r16 and r20 being deleted. At this stage the stakeholders may change theirpriorities, and the effort estimates and the constraints may be revisited. This could bein response to new information gathered from the first iteration. A second increment isthen firmed for delivery. In both iterations, future tentative increments are also given soas to provide details of the likely product evolution. In this example the number of plannedincrements has been limited to four. This means that there are some requirements that areomitted from the plan and do not contribute to the expected benefit.

Conclusion

In this chapter we have reviewed some of the techniques available for prioritisation ofrequirements for incremental and iterative development of software systems. A categorycalled relative comparison techniques can be formed. These are the methods that requirethe requirements to be compared to achieve a prioritisation. Once a prioritisation isachieved, a greedy algorithm taking into account the dependencies in the requirementscould be applied to assign requirements to increments for release planning. This methodshould work well for small numbers of requirements but is impractical with larger sets ofrequirements. A further method as illustrated by the SERUM method could be classifiedas absolute comparison method. Here estimations are made for the factors consideredimportant for prioritising requirements. Again, this could be applied to release planningfor incremental and iterative development and has the advantage in producing usefulmetrics, such as risk assessments, that can be used elsewhere. One problem is incombining these estimations, and to date no attempt has been made to do this, the methodrather depending on analyst judgement based on the information gathered.Further, a recently developed technique has been described, EVOLVE, that uses GeneticAlgorithms to optimise the prioritisation process for a number of stakeholders withdiffering priorities for requirements. The method takes into account differing stakeholderviewpoints, effort constraints, risk constraints, and dependencies between require-ments. A case study has been used to illustrate the working of the method, and its efficacyis backed up by this and from experimentation and industrial feedback (Ruhe & Greer,2003). Additional empirical work on this has confirmed the stability of the outputs and



usability of the methods (Amandeep, Ruhe, & Stanford, 2004; Ruhe & Greer, 2003).EVOLVE also allows for uncertainty in the effort estimates, allowing decision makers tochoose the level of confidence they require for effort estimates. One of the key strengthsof EVOLVE is that the iterative planning process assumes changes will occur betweenphases. This better reflects the reality of software projects. Future work will involvedeveloping the method further to take account of other possible constraints andsituations.

References

Amandeep, A., Ruhe, G., & Stanford, M. (2004). Intelligent support for software releaseplanning. In Proceedings 5th International Conference on Product FocusedSoftware Process Improvement, LNCS 3009, 248-262.

Briand, L.C., Feng, J., & Labiche, Y. (2002). Experimenting with genetic algorithm todevise optimal integration test orders. (Tech. Rep.). Department of Systems andComputer Engineering, Software Quality Engineering Laboratory Carleton Univer-sity.

Bubenkbo, J.A. Jr. (1995). Challenges in requirements engineering. Proceedings of 2ndIEEE symposium on Requirements Engineering, 160-162.

Carnahan J., & Simha, R. (2001). Natures algorithms. IEEE Potentials, 21-24.Charette, R. (1989). Software engineering risk analysis and management. New York:

McGraw-Hill.Cockburn, A. (2002). Agile software development. NJ: Pearson Education.Cusamano, M.A., & Yoffie, D.B. (1998). Competing on Internet time: Lessons from

Netscape and its battle with Microsoft. New York: The Free Press.Davis, A.M. (2003). The art of requirements triage. IEEE Computer, 42-49.Davis, L. (1991). Handbook of genetic algorithms. New York: Van Nostrand Reinhold.De Gregorio, G. (1999). Enterprise-wide requirements and decision management. Pro-

ceedings of the Ninth International Symposium of the International Council onSystem Engineering, 775-782.

Greer, D., & Ruhe, G. (2004). Software release planning: An evolutionary and iterativeapproach. Journal Information and Software Technology, 46(4), 243-253.

Greer, D., Bustard, D., & Sunazuka, T. (1999a). Effecting and measuring risk reduction insoftware development. NEC Journal of Research and Development, 40(3), 378-38.

Greer, D., Bustard, D., & Sunazuka, T. (1999b). Prioritisation of system changes usingcost-benefit and risk assessments, Proceedings of the Fourth IEEE InternationalSymposium on Requirements Engineering, 180-187.

Hart, S., Hogg, G., & Banerjee, M. (2002). An examination of primary stakeholders’opinions in CRM: Convergence and divergence? Journal of Customer Behaviour,1(2), 241-267.

116 Greer


Haupt, R.L., & Haupt, S.E. (2000). Optimum population size and mutation rate for a simplereal genetic algorithm that optimizes array factors. Applied ComputationalElectromagnetics Society Journal, 15(2), 94-102.

Holland, J.H. (1975). Adaptation in natural and artificial systems. Ann Arbor: Univer-sity of Michigan Press.

Jiang, J.J., Klein, G., & Discenza, R. (2002). Perception differences of software success:Provider and user views of system metrics. Journal of Systems and Software, 63(1)17-27.

Karlsson, K., & Ryan, K. (1997). Prioritizing requirements using a cost-value approach.IEEE Software, 14(5), 67-74.

Karlsson, J., Wohlin, C., & Regnell, B. (1988). An evaluation of methods for prioritizingsoftware requirements. Journal of Information and Software Technology, 39, 939-947.

Lin, X.H., Kwok, Y.K., & Lau ,V.K.N. (2003). A genetic algorithm based approach to routeselection and capacity flow assignment. Computer Communications, 26(9), 961-974.

Maiden, N.A.M., & Rugg, G. (1996). ACRE: Selecting methods for requirements acqui-sition. Software Engineering Journal, 11(3), 183-192.

Palisade Corporation. (2001). Guide to RISKOptimizer: Simulation optimization forMicrosoft Excel Windows version release 1.0. New York: Palisade Systems Inc.

Rajlich, V., & Gosavi, P. (2002). A case study of unanticipated incremental change.Proceedings of International Conference on Software Maintenance, 442-451.

Reeves, C. (1995). Modern Heuristic Techniques for Combinatorial Problems. NewYork: McGraw-Hill.

Regnell, B., Host, M., Natt och Dag, J., Beremark P., & Hjelm, T. (2001). An industrial casestudy on distributed prioritisation in market-driven requirements engineering forpackaged software. Requirements Engineering, 6, 51-62.

Rugg, G., & McGeorge, P. (1997). The sorting techniques: A tutorial paper on card sorts,picture sorts and item sorts. Expert Systems, 14(2), 80-93.

Ruhe, G., & Greer, D. (2003). Quantitative studies in software release planning under riskand resource constraints, Proceedings of the IEEE-ACM International Sympo-sium on Empirical Software Engineering, 262-271.

Saaty, T.L. (1980). The analytic hierarchy process. New York: McGraw Hill.



Appendix

This appendix presents a summary of the EVOLVE genetic algorithm.Input:

Sseed = initial seed solutionm = population sizecr = crossover ratemr = mutation rate

Output:The solution with the highest fitness score from the final populationVariables:

Sn =a solutionP =current population as a set of (solution, fitness score) pairs = {(S1,v1), ,(S2,v2)….(Sm,vm)}Sparent1 = first parent selected for crossoverSparent2 = second parent selected for crossoverSOffspring = result from crossover/ mutation operation

Functions:NewPopulation(Sseed,m): Sseed→P , returns a new population of size m.Evaluate(S) provides a fitness score for a given solution, S.Select(P) chooses from population P, based on fitness score, a parent for thecrossover operation.Crossover(Si,Sj,cr) performs crossover of solutions Si and Sj at crossover rate cr.Mutation(Si, mr) performs mutation on solution Si at mutation rate mr.IsValid(Si) checks validity of solution Si against the user-defined constrraints.BackTrack(Soffspring) = proprietary backtracking operation on a given solution.This backtracks toward the first parent until a valid solution is created.Cull(P) removes the (m+1)th ranked solution from the population, P.CheckTermination()a Boolean function that checks if the user’s terminatingconditions have been met. This may be when a number of optimizations havebeen completed, when there is no change in the best fitness score over a givennumber of optimizations, a given time has elapsed, or the user has interruptedthe optimization.Max(P) returns the solution in population P that has the highest fitness score.

118 Greer


Algorithm:BEGIN

P := NewPopulation(seed);TerminateFlag := FALSE;WHILE NOT (TerminateFlag)

BEGINSparent1 := Select(P);Sparent2 := Select(P/ Sparent1);SOffspring := Crossover(Sparent1, Sparent2, cr);SOffspring := Mutation(SOffspring, mr);If NOT IsValid(SOffspring) THEN BackTrack(SOffspring);IF IsValid(SOffspring)

BEGINP := P ∪ {(SOffspring, Evaluate(Soffspring)}};Cull(P);

END;TerminateFlag = CheckTermination();

END;RETURN(Max(P));

END.

A Quality Model for Requirements Management Tools 119


Chapter VIII

A Quality Model forRequirements

Management ToolsJuan Pablo Carvallo, Universitat Politècnica de Catalunya (UPC), Spain

Xavier Franch, Universitat Politècnica de Catalunya (UPC), Spain

Carme Quer, Universitat Politècnica de Catalunya (UPC), Spain

Abstract

This chapter proposes the use of quality models to describe the quality of requirementsmanagement tools. We present the COSTUME (COmposite SofTware system qUalityModel development) method aimed at building ISO/IEC 9126-1-compliant qualitymodels, and then we apply it to the case of requirements management. We emphasizethe need to use UML class diagrams to represent the knowledge about the domain priorto the quality model construction, and also use actor-based models to represent thedependencies of requirements management tools with their environment, and thencomprehend better the implications of quality factors. We show the applicability of thequality model in a real experience of selection of a requirements management tool.

120 Carvallo, Franch and Quer


Introduction

The activities embraced by the requirements engineering discipline (Kotonya &Sommerville, 1998; Robertson & Robertson, 1999), such as the capture, analysis,validation, verification, and maintenance of software systems requirements, often turnout to be very complex to carry out, especially in the case of medium- and large-scaleprojects. Among other factors, their success depends on the following abilities:

1. The ability to deal with a large number of requirements that are related in many ways.2. The ability to guarantee, to an acceptable extent, that the requirements are complete

and consistent.3. The ability to organize the requirements with respect to different criteria.4. The ability to maintain and manage several versions of requirements during the

process.

Requirements management tools (RMT) provide computer-based support to overcomethe complexities that stem from those activities. RMTs provide functionalities to supportthe abilities mentioned above, such as requirements capture and classification, traceabil-ity, version management, and generation of a requirements document.Many RMTs exist in the market nowadays (for example, Rational RequisitePro, TelelogicDOORS, Compuware Reconcile and IrQA from TCP Sistemas e Ingeniería, and so forth),usually available in the form of COTS (Commercial Off-The-Shelf) components. Theydiffer among others in the requirements capture strategies that they offer, in the way inwhich they structure and relate requirements, and in the additional components andresources that they require to operate. As it is true in other COTS domains, selecting themost appropriate RMT for an organization or even for a particular project can be difficult.For this reason an organization selecting a RMT should be aiming at defining or usinga framework in which RMTs could be evaluated with respect to its specific needs. Thisframework should embrace different kind of features that affect software evaluation, suchas managerial, political, and quality factors, which are the focus of our work.In this chapter we present a framework based on the use of quality models for describingthe quality aspects of RMTs that will act as software evaluation criteria. In the ISOstandard 14598-1, a quality model is defined as “the set of characteristics and relatedrelationships that provides the base for specifying quality requirements and evaluatingquality” (ISO, 1999). A widespread standard on quality models is the ISO/IEC 9126-1 (ISO,2001). Quality models compliant with this standard present three different kinds of qualityfactors, namely characteristics, subcharacteristics, and attributes, organized as a hier-archy. The standard itself fixes a set of six characteristics (functionality, reliability,usability, efficiency, maintainability, and portability), decomposed into a first level ofsubcharacteristics (such as security, interoperability, maturity, and so forth). To com-plete a quality model applicable in a given COTS domain, it becomes necessary to further



decompose these subcharacteristics, to define metrics for evaluating the measurablequality factors in which they will be directly or indirectly decomposed, and to definerelationships among these quality factors. The standard is not precise at some points,being necessary therefore to take some decisions about which should be the organizationof an ISO/IEC-based quality model; see Botella, Burgués, Carvallo, Franch, Grau, Marco,& Quer (2004) for details. These decisions can be reflected in a conceptual model torepresent a quality framework, as done, for instance, in Kitchenham, Hugues, & Linkman(2001).Quality models are a means to obtain exhaustive and structured descriptions of COTSdomains such as RMTs. Once built, RMTs may be evaluated with respect to the qualityfactors included therein. During the selection of an RMT, the involved company will stateits quality requirements over the tool with respect to the quality model, and the classicalrequirement negotiation process (Alves & Finkelstein, 2003) will be used to yield to thefinal selection of the most appropriate one (see Figure 1).The rest of the chapter is organized as follows. The next section introduces theCOSTUME method for developing quality models. The three sections after that aredevoted to the application of the COSTUME activities to the particular case of RMTs.Then we apply the quality model to a real RMT selection process in which we have beenrecently involved. We provide in the final section the conclusions and comparison withrelated work.

Figure 1. Using a quality model in the selection of a requirements management tool

Quality ModelKnowledge RMTsDomain

RMTs DescriptionsRMTs

Formalized Requirements

1. ------ 2. ------ ----- - 3. ----- 4. -----

Quality Requirements

Negotiationduring RMT

Selection



Costume: A Method for theConstruction of Software QualityModels

COSTUME (COmposite SofTware system qUality Model dEvelopment) is a methodspecifically suited for developing quality models for systems composed of severalinterconnected COTS. It comprises four activities (Figure 2).

• Activity 1. Analyzing the environment of the software system. The organizationalelements (that is, the environment) that surround the system are identified andmodeled as actors, and the relationships among the system and this environmentare identified. This activity helps to understand the role that the software systemplays in the target organization and makes explicit also what the system needs fromits environment. We use an actor-based model (Yu, 1997) (to be described in thenext section) to represent the results of this activity.

Figure 2. The COSTUME method

D

D

DD

System

HumanActors

OrganizationActors

HardwareActors

System

HumanActors

OrganizationActors

HardwareActors

D

D

D

D

D

D

D

D

DD

D

D

System Quality Model

C1

C2

C3C4

QM1

QM2QM4

QM3

C1

C2

C3

C4

System

1. Analysis of the environment 2. Decomposition into subsystems

3. Construction of individual quality models 4. Composition into a system quality model

D

D



• Activity 2. Decomposing the software system into actors. The system is decom-posed into individual elements, each offering well-defined services. These ele-ments are also modeled as interconnected actors. Services are identified startingfrom the results obtained in the previous activity, that is, the needs posed by theenvironment onto the system and also exploring the COTS market for discoveringwhat type of products can cover these services. One of these actors is usually thecore of the system, providing most of the services, while others provide specificsupport for some other services. We remark that COTS products available in themarket may cover the services of more than one actor at a time; see Franch & Maiden(2003) for more details. Activities 1 and 2 are run in parallel, as proposed in mostCOTS-based life cycles (Comella-Dorda, Dean, Morris, & Oberndorf, 2002; Maiden& Ncube, 1998).

• Activity 3. Building individual quality models for the actors. We build an ISO/IEC9126-1-compliant quality model for each individual actor applying the methodpresented in Franch & Carvallo (2002, 2003). The quality factors relevant for thequality model are determined with the help of the artifacts obtained in the twoprevious activities. In this activity, it becomes crucial to be aware of what thequality model is being built for. If it is intended to support just a single project, webuild throw-away quality models, in which not all the quality factors are exploredbut just those directly related with the requirements of the system; in fact, thesefactors are refined up to a level of detail that allows evaluating the requirements.On the contrary we may be interested in building reusable quality models, and inthis case we aim at including as many quality factors as found in the COTS market,but we do not intend to refine them too much, building just the upper levels of thequality model hierarchy. Reusable quality models are refined in a particular projectusing its requirements.

• Activity 4. Combining the individual quality models. We build an ISO/IEC 9126-1-compliant quality model for the whole system as the combination of the individualones, obtaining therefore a single and uniform vision of the system quality. Wehave identified some combination patterns that can be used over and over duringthis combination activity.

In the rest of the chapter we will apply the two first activities of COSTUME method toidentify the environment and actors of requirements management systems. Among theidentified actors, we will focus on RMTs, the core of such a system. We will apply activity3 to this particular actor to obtain a reusable quality model. We will not apply activity3 to the other actors nor activity 4, for the sake of brevity. Last we will use the reusablequality model in the context of a particular selection process, refining therefore some ofits quality factors.



Analyzing the Environment of theRequirements Management System

The first activity in COSTUME aims at determining the environment of the softwaresystem, in this case a Requirements Management System (RMS). Since we are using anactor-based approach, the goal of this analysis is to identify the actors that will interactwith such a type of systems. Four different types of actors may be distinguished: human,representing different types of users; organizations, providing informational or logicalresources to the system; hardware resources, as mechanical devices governed by thesystem or providing data to the system; and software, representing other softwaresystems, which provide data to or collect data from the system.The actors for an RMS are detailed in Table 1. Apart from the RMS itself, this system hasjust human actors. Other systems we have analyzed present actors of the other types(scanners in document management, mail servers in mail client tools, and so forth.).Once the actors are identified, the dependencies among them may be represented usingan actor-based model. Specifically, we use Yu’s (1997) i* approach to actor-basedmodeling, and, in particular, the Strategic Dependency (SD) model. In an SD dependencyrelationship, a depender, the actor that “wants,” depends on a dependee, the actor thathas the “ability” to give, for a dependum, the object of the dependency. There are fourtypes of dependencies: goal (represented in i* by an ellipse), soft goal (by a curly shape;they stand for non-functional requirements), resource (by a rectangle), and task (by ahexagon).

Table 1. Environmental actors of a requirements management system

Actor Abb. Type Goal

Requirements Management System RMS Software

Provides mechanisms for defining and managing requirements for software development projects.

Requirements Engineer RE Human

Defines requirements and relationships among them for a project.

Requirements Engineers Head REH Human Defines the rationale behind

requirements in a project.

Software Engineer SE Human Develops a software system from the requirements defined for a project.

Project Manager PM Human Defines and manages projects and users.



There are some methods and processes for building i* models. In our case, we proposethe following steps:

• First we identify which goals of the system’s actors depend on the system, and werepresent these relationships by goal dependencies.

• Then we identify which fundamental resources are central to these goal dependen-cies and we model them with resource dependencies. Note that resources may bephysical or informational.

• Next we analyze each goal dependency over the system with the perspective of theISO/IEC 9126-1 subcharacteristics. For each goal we include in the i* model a softgoal for every subcharacteristic considered crucial for this goal. We may even

Figure 3. SD model for the environment of a Requirements Management System. A usefulmnemonic for the dependency link is to check the direction of the half-circles of thedependency. Consider each as a letter “D” — the direction that the D faces denotes thedirection of the dependency. As the letter “D” is read, on the left is the depender andon the right is the dependee.

D

RMS

SERE

D

D

D

D

D

D

D

D

D

D

D

D

D

DD

D

D

D

Rich Variety ofRequirement and

Dependencies Types

DD

RMS: Requirement Management SystemSE: Software EngineerPM: Project ManagerRE: Requrement EngineerREH: Requirement EngineerHead

PMD

D

D

D

SystemElements

Manage Versionsof Requirements

D

D

DD

D

DD

D D

DProvide

GroupwareSupport

Quering ofSpecification / Design

of a Project

Support Traceability ofReqs . vs. System Elements

Support Export /Import

RequirementsManage Projects and

Project Versions

Manage Users/Groups per Project

Allow Remote andConcurrent Work

Flexible Structuringof Requirements

REH

D

D

Flexible Captureof Requirements

Requi-rement

Depen-dence Query

Report

Query

Report

RequirementsDocuments

RequirementsDocuments

Rich Query Processingand Report Generation

RequirementsStructuringElements

D

D

SupportRequirementsTraceability

ProvideGroupware

Support

Manage Requirementsand Dependencies

DD

D

D

D

Allow Specification /Design of System

Elements

D

D



decide to substitute the goal by this soft goal in the case that we consider thatsatisfying the goal without satisfying the soft goal is not admissible.

We tend to avoid task dependencies in the model, since they are rather prescriptive. Atask dependency represents one particular way of attaining a goal; it can be considereda detailed description of how to accomplish a goal.In Figure 3 we find the SD model for the environment of an RMS. Goals have to be withthe main functionalities that the RMS offers, namely requirements management, queryand report facilities, requirements capture, and so forth. They give light to somefundamental resources, remarkably the notion of requirement itself. Concerning softgoals, there are some: for instance, requirements capture is of interest only if it is flexibleenough; therefore it appears directly as a soft goal. We highlight that, as we are onlyinterested in the part of the environment that involves the RMS. Dependencies amongactors of the environment are not of interest; nevertheless, we use the is-a relationshipoffered by i* to relate two of them (RE and REH).

Decomposing the RequirementsManagement System into Actors

The decomposition of the system into actors is done starting from the needs posed bythe environment onto the system (identified in the i* SD environmental model), and atthe same time exploring the COTS market for discovering what type of COTS componentscan cover these (and perhaps other, unexpected) needs. This decomposition, of course,includes the RMT itself as an actor, in fact, the core one, whose attainment of goalsdepends on some of the services provided by the rest of the actors.In Table 2 we show a list of actors in which a RMS may be decomposed, grouped bycategory. We do not include the core actor of the system, the RMT itself. The third columnof the table contains the environment dependencies that point out the existence of theactors. These dependencies and the functionalities of the COTS components that couldeventually play the roles of these actors generate some dependencies from the RMT actorto the others, which may be found at the fourth column.These dependencies are modeled in i*, too (see Figure 4). For instance we can combinethe environment dependency Manage Requirements and Dependencies with the obser-vation of RMTs available in the market to deduce the need of a DBMS to ProvidePersistent Storage of Requirements and Dependency Relationships. As a differentexample, the resource dependency User is a kind of visionary one: currently RMTs arenot so tightly integrated with directory services as to import/export information aboutusers, but current trends allow predicting that in the future this will be the case. Note thatsoft goal dependencies such as Flexible Capture of Requirements have turned into goaldependencies, because the non-functional ability (flexibility in this case) is the respon-sibility of the RMT itself, not of the used tool.



Table 2. Actors inside the Requirements Management System

Figure 4. SD model for the dependencies among Requirements Management Systemactors

RMT

WPTCASE

DBMS

Persistent storage ofrequirements and

dependency relationships

D

D

D

DD

D

D

DD

D

RMT: Requirements Management ToolsCASE: CASE toolsDS: Directory ServicesDBMS: Data Base Management SystemsWPT : Word Processor ToolsWB: Web BrowserCT: Chatting Tools

D

D

CT

Definition ofSystem Elements

Traceability of changesin Requirements versus

System Elements

Persistent storage ofrequirement andproject versions

Discussion supportbetween Requirements

Engineering

Generation ofreports

Capture of Requirementsfrom an external file

DS

Authentication ofusersD

User

D

D

SystemElement

D

D

D

D D

WB

Web Interface Offered

D

D

Category Actor Environment dependencies

Inter-actor dependencies stemming from RMT

Software System Development

CASE Tools (CASE)

Allow Specification/Design of System Elements

Support Traceability of Requirements versus System Elements

Definition of System Elements Traceability of Changes in Requirements

versus System Elements System Element

Resources Directory Services (DS)

Manage Users/Groups per Project

Authentication of Users User

Data Management

Data Base Management Systems (DBMS)

Manage Requirements and Dependencies

Manage Versions of Requirements

Manage Projects and Project Versions

Persistent Storage of Requirements and Dependency Relationships

Persistent Storage of Requirement and Project Versions

Office Suites Word Processor Tools (WPT)

Rich Query Processing and Report Generation

Flexible Capture of Requirements

Generation of Reports Capture of Requirements from an

External File

Client Web Browser (WB)

Allow Remote and Concurrent Work Web Interface Offered

Groupware Chatting Tools (CT) Provide Groupware Support Discussion among Requirement

Engineers



As mentioned in the section on COSTUME, actors are not supposed to be mappeddirectly onto individual COTS components. It may be the case of a COTS componentcovering goals from more than one actor, an actor covered by two COTS componentsworking together, or even the goals of an actor covered by two COTS components at thesame time for survivability reasons. In Franch & Maiden (2003) we have explored thisissue. The fundamental thing with actors is that they are the relevant unit that the qualitymodels are to be build for.

An ISO/IEC 9126-1-Complaint QualityModel for Requirements ManagementTools

In Franch & Carvallo (2002, 2003) we have proposed a seven-step method to build ISO/IEC 9126-1-compliant software quality models. The first step is a domain-analysisactivity, which yields as a result a UML class diagram. The other six steps refine the ISO/IEC 9126-1 departing quality model by adding new quality factors (characteristics,subcharacteristics, and attributes), defining their relationships, and proposing metricsfor them.

Analyzing the Domain of Requirements ManagementTools

The main goal of this analysis is to gain more knowledge about the domain. Other benefitsof the analysis and the resulting class diagram are: on the one hand to fix the lack ofuniformity in the terminology in COTS domains; on the other hand the eventual use ofthe classes, attributes, and associations appearing in the diagram to provide somerationale for identifying the quality factors of the quality model. In the case of RMTs, dueto our previous knowledge of the domain, we have not been as confused by thedifferences in the used terminology as in previous experiences.During this analysis the knowledge acquired in the two previous COSTUME activitiesis completed with some classical tasks (literature reviewing, web page analysis, and soforth). Then the most relevant concepts and their relationships are represented in a clearway by means of a UML class diagram (Rumbaugh, Jacobson, & Booch, 1999). Finallythe class diagram may be complemented with other structured or written information.Figures 5, 6, and 7 show the UML class diagram for the RMT case. In Figure 5 note thatresources in the i* SD environmental diagram such as Requirement, Project, andDependency have become a class. Many others have been introduced. Requirements arerelated to Attributes and give Values to them. Each Requirement is of one singleRequirement Type. Requirements are related by Dependencies, which are of oneDependency Type (decomposition, refinement, conflict, synergy, and so forth). Also



Figure 5. UML class diagram for the requirements management tools domain:requirements

Figure 6. UML class diagram for the requirements management tools domain: structuringelements

Requirement Type

Project

Attribute

Requirement

PossibleValue

*

*

in-terms-of

1 *

can-take

Value

*0..1

subproject-of

0..1

*

version-of

0..1

0..1

version-of

Dependency

0..1

0..1

*

Dependency Type

System Element

Defined Element

{disjoint, complete}

1

* of-a

1

*

of-a

1*

belongs-to

Constraints-The version of a requirement belongs-to its same project.-A requirement must be expressed in-terms-of attributes that are defined-for the project which the requirementbelongs-to or that are bound-to the template from which the project has been defined-from.-A requirement may be expressed in-terms-of attributes that have sense-for-the-requirements of its requirement type.-The value of an attribute in-terms-of which a requirement is expressed, must be one of the possible values that theattribute can-take.

* * sense-for-requirements-of

Template

Predefined Requirement TypeParticular

Project

AttributeDependency Type

StructuringElement

1 * defined-from

1

*defined-for

*

*bound-to





System Elements are related by Dependencies; since system elements are defined by theCASE tools (see Figure 4), their attributes will not be defined here but in the UML diagramfor that domain (that’s why the class name is in italics). Both Requirements and SystemElements are bound to Projects. Versions of Projects and Requirements are supported.We show some representative integrity constraints of the model.In Figure 6 we distinguish among Predefined and Particular Requirement Types,Dependency Types, and Attributes; we generalize instances in these three classes asStructuring elements. Predefined structuring elements are bound to project Templates,while Particular structuring elements are bound to particular Projects, which are definedfrom Templates. Last, in Figure 7, we show that the most relevant concepts are ownedby Users; again the italics show that the concept of user is external of the RMT (weconsider it imported from the directory service).

Constructing the Quality Model for the RequirementsManagement Tools Domain

For the sake of reducing the cost in the construction of new quality models we take asa starting point not the original ISO/IEC 9126-1 hierarchy but an extended ISO/IEC 9126-1 quality model that consists of roughly 50 quality factors, organized into a three-levelhierarchy, that have appeared repeatedly in our previous quality model building expe-riences in different domains. During the construction of a quality model for a new domain,quality factors specific for this domain will be added to the departing quality model, and,if it is necessary, others will be redefined or eliminated. In order to help in theidentification of new quality factors, the artifacts obtained in previous steps will be used.In the extended ISO/IEC 9126-1 quality model, the suitability subcharacteristic, presentin the original ISO/IEC 9126-1 model, is not decomposed, because its refinement is mostlydomain-dependent. It is possible to decompose it into a set of subcharacteristicscorresponding to some of the goal and soft goal dependencies identified in the i* SDenvironment model. Table 3 presents an extract of this decomposition and Table 4 showsthe decomposition of one of the new subcharacteristics appearing in Table 3. Note thatgoal and soft goals that depend absolutely on capabilities offered by the dependee (suchas requirements capture) do not appear in these decompositions.

Figure 7. UML class diagram for the requirements management tools domain: entities

Entity

ProjectTemplate


User

RequirementType Attribute RequirementDependency

Type Dependency

* *

defined



Concerning attributes, it is clear that we cannot aim at including all of them in the qualitymodel (Dromey, 1996); however it is certainly possible to identify a set of the mostrelevant ones. Many of the attributes to be added to the quality model may be inferredfrom the UML class diagram (that is, from the classes, attributes, and associationstherein), as it contains all the relevant concepts identified in the sources consulted whenstudying the domain. Because of the iterative nature of the method, the model may berefined even during the evaluation of the products up to the point at which adding newattributes would not make a difference in COTS component assessment. The use ofderived attributes (attributes whose values depend on other attributes) at several levelsis encouraged, as it makes the model more structured and reusable. Table 5 presents an

Table 3. Decomposition of the Suitability subcharacteristic for requirementsmanagement tools

Table 4. Decomposition of Requirements Management subcharacteristic forrequirements management tools

No. Subcharacteristics Definition

1 Requirements Management Options related to the definition and management of requirements

2 Requirements Classification Options related to the structure of requirements into a project

3 Requirements Relationships Option related to the definition of relations among requirements

4 Requirements Traceability Options related to the traceability relations among requisites and with system elements

5 Concurrent Work Support Support offered by the tool to users concurrent work

6 Versioning and History Control Options related to the management of requirements and baseline versioning

7 Queries and Searches Support offered by the tool to perform basic and advanced queries and search of requisites

8 Reports and Views Option related to the generation of reports and specification documents

No. Subcharacteristics Definition

1 Requirements Input Options related to the input of requirements through the RMT itself

2 Requirements Deletion Options related to the removal of requirements

3 Requirements Edition Options related to the modification of existing requirements

4 Requirements Numbering Options related to numbering capabilities

5 Requirements attributes Options related to the definition of attributes for requirements

6 Requirements Approval and Rejection

Options related to the approval and rejection of requirements



extract of the attributes included in one of the subcharacteristics identified in Table 4,namely Requirements Attributes.Metrics for some quality attributes may be difficult to define; however it is the only wayto have an exhaustive and fully useful quality model that can be used in the evaluationof COTS components. Some metrics can be as simple as Boolean (for example, attributes1.2 and 1.3 in Table 5), numerical, or label values, while some other attributes require amore complex representation, yielding to structured metrics such as sets (for example,attributes 1.1 and 2.1 in Table 5) or functions. Metrics for basic attributes are usuallyobjective and quantitative. For derived attributes there is more diversity. For instancethe metric for attribute 1 in Table 5 is likely to be subjective and qualitative.Another important aspect when building quality models is the identification of relation-ships among attributes. The model becomes more exhaustive and, as an additionalbenefit, user requirements may get implicitly extended once they have been expressedin terms of quality attributes. Many types of relationships between attributes can bedefined; for example, collaboration, damage, dependency, and so forth. An example ofdependency relationship between attributes in the RMT domain appears between theattribute Traceability Matrix and the attributes Requirements Relationships and Re-quirements Hierarchy, because traceability matrixes cannot be built if there is no way todefine the relationships among the requirements.

A Real Case of Selection of aRequirements Management

PRISMA is an ongoing project taking place at the Universitat Politècnica de Catalunya(UPC) aiming at replacing a legacy system that supports the management of academicdata and records. GESSI (Spanish acronym of Software Engineering Group for Informa-

Table 5. Extract of the attributes for the Requirements Attributes subcharacteristic ofrequirements management tools

Attribute Definition

1 Requirements Attributes Capabilities for requirements-related attributes

1.1 Default Requirements Attributes Set of default attributes related to requirements provided by the tool

1.2 User-defined Requirements Attributes Possibility to define new requirements attributes

1.3 Linkage to Requirement Types Possibility to bind requirements attributes to requirements types

2 Types of Attributes Capabilities for types of attributes

2.1 Default Types of Attributes Set of default types of attributes provided by the tool

2.2 User-defined Types of Attributes Possibility to define new types of attributes



tion Systems), the research group we belong to, is participating in some tasks, amongwhich we mention participation in software quality assessment based on CMM level 2Key Process Areas (KPA).One of these KPAs is Requirements Management. The goals of this KPA are to controlrequirements in such way that a baseline for the software engineering and managementactivities can be established and to make sure that software plans, products, andactivities are kept consistent with requirements. As mentioned in the introduction,complex projects such as PRISMA have many requirements to deal with, therefore theneed for a tool to support its management is more than well justified. Our GESSI decided,therefore, to select an RMT; in fact, this selection has been the trigger that pulled us tobuild the RMT quality model.The process to select the tool was made of seven tasks:

1. Construction of a quality model for the domain. To complete our knowledge of thedomain we decided to build first the quality model for the prospective compositesystem using COSTUME as explained in the previous sections. We built, therefore,an SD model, a UML class diagram, and individual quality models. The individualquality models for the software actors were not very detailed (for example, metricswere not considered); just the higher levels of the hierarchy were completed. Theresulting quality model was used and further refined in the next steps.

2. Elicitation of requirements and determination of evaluation criteria. The qualitymodel was used as a guideline. As each of the sections of the quality model wasreviewed, older requirements were made clearer, and new requirements emerged ina very structured way, resulting from the understanding of the capabilities thatproducts in the domain have to offer. Also the decomposition of the RMT systeminto actors (see the section on decomposing RMS into actors) came in handy insome situations. As an example the fact that an approved requirements specifica-tion document was already available (because CMM level 2 compliance wasdecided once the project was issued) introduced a risk. The people responsible forthe elaboration of this document were uncomfortable with the idea of redoing alltheir work because of the new tool. Thus they were happy to discover that somekind of integration with external word processors to capture requirements waspossible. As a result new requirements were proposed, such as the provision ofsome sort of semi-automatic capture of requirements from most popular wordprocessors or the possibility to import from XML or RTF formats. During thiselicitation process evaluation criteria were identified and the correspondingmetrics were defined.

3. Selection of an initial set of RMTs to be evaluated. Based on the previousscreening of the members of GESSI, and also some market exploration made by thePRISMA personnel, we selected five initial candidates. The availability of localsupport and the existence of previous successful installations in Spanish compa-nies, together with coverage of some high-level suitability attributes, were used toperform this first screening.

4. Hands-on experimentation of RMTs. Demo versions of the products were installedand tested more thoroughly than before. Here again the quality model became a



cornerstone of the task. After an initial familiarization with the interface, each toolwas explored to identify the factors related to the attributes in the quality model.Products were also tested to find out the degree of coverage of the dependencieswith COTS that were already part of the PRISMA architecture.

5. Assessment of the RMTs using the quality model. Once requirements and RMTsevaluations were input into the quality model, products were compared with eachother and with respect to the requirements. Two of the candidates were discardedby non-technical reasons (mainly poor supplier support during interaction). Athird candidate was discarded because of the poor requirements capture capabili-ties. The two remaining products were successfully evaluated with respect to allof the attributes in the quality model. Their mismatches with respect to therequirements were identified and documented.

6. Conclusions and proposal of the final candidates. A final report containing asummary of the advantages and disadvantages of each of the products, and theirevaluation with respect to the quality model and to the requirements, was ad-dressed to the responsibility of the final selection. This document included aninvitation to a final demonstration of the two finalist candidates.

7. Demonstration of the final RMTs and selection of the final one. Again the qualitymodel was used as a guideline to present the benefits and disadvantages of eachRMT’s respect to the quality factors and the requirements. The final selection wasmade based on the cost/benefit relationship offered by the products.

Conclusion

Requirements management tools play an increasingly important role in requirementsengineering, especially in large software projects. It becomes necessary to know in depthwhich services these kinds of tools may offer to their users, and also which criteria maybe used to compare among different alternatives available in the market. In this chapterwe have presented COSTUME, a method aimed to represent the quality of softwaresystems as a means to attain these goals, and we have applied it to the domain of RMTs.We think that the main contributions of this chapter are:

• We have provided (an overview of) the description of RMT quality factors. Theresulting model can be used with two purposes. First to know exactly the type offunctionalities and the quality of service that RMTs can be expected to provide.Second to improve RMT selection processes, that is, to make these selectionprocesses less time-consuming and less error-prone.

• The resulting model keeps clearly separated those functionalities and quality ofservice issues that are the responsibility of the RMTs themselves and those forwhich the RMTs depend on other software tools. We have identified the mostrelevant of these other tools, namely CASE tools, directory services, word proces-sors, and databases, and we have made explicit the way in which RMTs depend on



them. From our point of view, this is a crucial difference with most other existingapproaches, which rely on the ISO/IEC 9126-1 interoperability subcharacteristicfor keeping track of these dependencies, making them obscure and difficult to trace.

• The description of quality may be used to drive selection processes, as we haveillustrated with a particular CASE study. We mention that building the qualitymodel in advance, at least up to the most important quality factors, helps in drivingthe requirements elicitation process. Also that the explicit distinction of RMTs fromother actors points out clearly which responsibilities are really inherent to thesetype of tools and which others are fulfilled by other tools. Last evaluation ofcandidate COTS components is also driven by the quality factors identified in thequality model of RMTs.

• The method presented here, COSTUME, is not bound to RMTs; it can be appliedto other software domains.

Other proposals of quality models for RMT exist. Probably the most relevant is the oneproposed by INCOSE (2003). Although some communality with our approach exists (forexample, both define a multilevel hierarchy of attributes, and both aim at having a commonframework and criteria to evaluate the products), many significant differences subsist:

• The departing catalogue. INCOSE uses an ad-hoc hierarchy; it is not based on anyexisting standard. Our approach is based on the commonly used and widespreadstandard ISO/IEC 9126-1.

• The hierarchy decomposition. INCOSE proposes a three-level taxonomy with adeparting top level with 14 attributes and their decomposition into two lower levels.Our approach further decomposes the starting ISO/IEC 9126-1 standard with twoadditional levels of subcharacteristics and up to four levels of attributes. This leadsto a very structured, easy-to-tailor, and thus reusable hierarchy. Furthermore theINCOSE approach is mostly concerned with the functional aspects of the toolsmissing other important aspects.

• The attributes. Although many attributes are common to both approaches, theattributes included in the INCOSE catalogues have been identified mostly basedon common sense. There is not a rationale (at least not provided) to identify andlater classify the attributes. In our approach we have build UML and i* models ofthe domain and its context, which have been used as the rationale to identify theattributes and their categorization into the model.

• The metrics. INCOSE proposes only a four-value leveling system. Therefore thedirect comparison of products is not possible, or at the best not fully reliable.Attributes need to be further decomposed and products explored in order to be fullyevaluated. As an example, some RMT evaluations stated that they fulfilled someattribute by themselves (for example, creation of UML models) while in the practiceadditional products are needed. In our approach basic attributes are directlymeasurable with well-defined metrics, allowing direct comparison among productsand analysis of matching with the requirements.



The construction of quality models is a time-consuming and costly activity. However,once available, they become a powerful tool that provides a general framework to getuniform descriptions of COTS in a domain. In order to facilitate the return of theinvestment in their construction, we are currently exploring the use of several artifactsto organize and reuse the knowledge available from previous experiences. One could bean evolving taxonomy of COTS categories and domains. In this taxonomy quality modelscould be associated with each category and domain. Thus domain quality models couldbe reused into new selection processes of COTS of the domain and category qualitymodels could be reused in the construction of quality models of any domain belongingto the category.

Acknowledgments

This work has been partially supported by the Spanish project TIC2001-2165. We alsothank the people from PRISMA, especially Nuria Rodríguez, for their support in this work.

References

Alves, C., & Finkelstein, A. (2003). Investigating conflicts in COTS decision-making.International Journal of Software Engineering and Knowledge Engineering,13(5), 473-493.

Botella, P., Burgués, X., Carvallo, J.P., Franch, X., Grau, G., Marco, J., & Quer, C. (2004).ISO/IEC 9126 in practice: What do we need to know? Proceedings of the 1st

Software Measurement European Forum, 297-306.Comella-Dorda, S., Dean, J.C., Morris, E., & Oberndorf, P. (2002). A process for COTS

software product evaluation. Proceedings of the 1st International Conference onCOTS-Based Software Systems, Springer-Verlag, LNCS 2255, 86-96.

Dromey, R.G. (1996). Cornering the chimera. IEEE Software, 13(1), 33-43.Franch, X., & Carvallo, J.P. (2002). A quality-model-based approach for describing and

evaluating software packages. Proceedings of 10th IEEE Joint InternationalConference on Requirements Engineering, 104-111.

Franch, X., & Carvallo, J.P. (2003). Using quality models in software package selection.IEEE Software, 20(1), 34-41.

Franch, X., & Maiden N.A.M. (2003). Modeling component dependencies to inform theirselection. Proceedings of 2nd International Conference on COTS-Based SoftwareSystems, LNCS 2580, 81-91.

INCOSE (2003). http://www.incose.org/tools/tooltax.html.ISO (1999). ISO/IEC Standard 14598-1 software product evaluation: General overview.



ISO (2001). ISO/IEC Standard 9126-1 software engineering – product quality, 1: Qualitymodel.

Kitchenham, B., Hugues, R., & Linkman, S.G. (2001). Modeling software measurementdata. IEEE Transactions on Software Engineering, 27(9), 788-804.

Kotonya, G., & Sommerville, I. (1998). Requirements engineering. Processes and tech-niques. John Wiley & Sons.

Maiden, N., & Ncube, C. (1998). Acquiring Requirements for COTS Selection. IEEESoftware, 15(2), 46-56.

Robertson, S., & Robertson, J. (1999). Mastering the requirements process. Addison-Wesley.

Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The unified modeling language userguide. Addison-Wesley.

Yu, E. (1997). Towards modeling and reasoning support for early-phase requirementsengineering. Proceedings of 3rd IEEE International Symposium on RequirementsEngineering, 226-235.




Requirements for the Integration of Autonomous Computer Systems 139


Chapter IX

ComposingSystems of Systems:

Requirements forthe Integration of

AutonomousComputer Systems

Panayiotis Periorellis, University of Newcastle upon Tyne, UK

Abstract

Information Systems in general carry or have embedded in their structure, elements thatstem from the organization’s strategic, tactical, and operational goals. Findingelements of an organization’s strategic, tactical, or operational goals embedded incomputer systems is not at all surprising, since most developers and programmers weretaught how to successfully map such goals into the Information System. We are, however,in an era where technology allows us to develop systems that are composed of smallerautonomous parts (sometimes complete systems themselves) that are integrated togetherdespite being bound by their corresponding organizational boundaries. Thereforeintegration is not only a technical challenge but an organizational one, too. In thischapter we address a number of issues, namely system composition, regulation,evolution, and dependability, using examples from the two case studies we worked onfor three years.

140 Periorellis


Introduction

Information Systems in general carry or have embedded in their structure, elements thatstem from the organization’s strategic, tactical, and operational goals. One can easily“see” the level of trust an airline system has in its clients when asking for a credit cardprior making the booking (and therefore updating the database), as opposed to anotherthat updates the database and asks the user to pay over the phone within a time limit.Finding elements of an organization’s strategic, tactical, or operational goals embeddedin computer systems is not at all surprising since most developers and programmers weretaught how to successfully map such goals into the Information System. We are,however, in an era where technology allows us to develop systems that are composedof smaller autonomous parts (sometimes complete systems themselves) that are inte-grated together despite being bound by their corresponding organizational boundaries.Many of the technical challenges have indeed been solved to allow the deployment ofpurpose-built modular pieces of code that provide some valuable service. Architecturessuch as Web services, which various organizations have started exploiting by exposingparts of their services over the Web, will reach commercial maturity or critical mass in theforthcoming years. The benefit such architectures add is that systems can be broken intosmaller pieces not only for the purpose of analyzing their complexity, but also for thepurpose of exploiting the value of the individual components. A company, for example,that runs a Web site for selling books could now “lease” its shopping cart componentwhile at the same time maintaining the component as part of the overall business.There is, however, an additional level of complexity that has not been addressed yet. Inorder to understand and consequently tackle the organizational challenges of buildingsystems, we need to distinguish between distributed processing and distributed control.Distributed processing implies distribution of a task over a number of resources, whereasdistributed control implies control of a task from a number of unrelated parties. This iswhat has not been addressed so far and where the originality of this work lies.The conclusions of this chapter have been drawn by the two case studies that wedeveloped throughout the course of our three-year project. The first case study involvesa travel agency composed of individual autonomous Web-based booking services (thatis, car rentals, hotels, airlines, insurance companies) to provide to the user via a Webfront-end the ability to book a full trip. The case study Periorellis & Dobson (2001) wasa technical one in nature. It involved the integration of autonomous booking systems ofairlines, car rental systems, and hotels to provide an integrated travel agency. At timeswe refer to it as the TA case study in the chapter. The second case study, Ferrante & Diu(2002), involves a pan-European electrical power distribution system composed ofnational electricity grids. Sometimes we refer to it as the EXAMINE case study. It wasa rather rich case study given the political, economic, and cultural diversity that has tobe reflected on the software that will carry the actual distribution. We use examples fromthese case studies to emphasize certain points throughout the chapter.The chapter raises a number of issues (which have so far been overlooked), and they allstem from one main question: “What happens when we integrate autonomous systems(that is, systems of systems) when the organizational elements embedded in them haveconflicting interests.” In a nutshell three possible outcomes can happen: good things



(added extra value), bad things (organizational failures), and unexpected things (newemerging properties).The chapter addresses these issues to reveal this “novel” problem space the newtechnologies create. Furthermore we examine the characteristics of this new problemspace and discuss how it can be addressed, and more specifically how we engineerrequirements of these new types of systems. We discuss in the chapter (and in thisparticular order) notions such as regulation, composition, transactions, evolution,dependability, and all related properties that we have found crucial in requirementsengineering.

Definitions

Let us start on the right foot by looking at some definitions of the most common termsused throughout the chapter.

• “System of Systems” is the overall system that encompasses the sum of theindividual autonomous systems. A point to note is that we want to distinguishourselves from component systems or virtual enterprises, since we are talkingabout integration of autonomous systems (controlled by a number of parties) thathave a particular customer base, a service history, a working culture, a physicalpresence. In many places the term is abbreviated to SoS.

• “Distributed Control” refers to a service whose composition, operation, andtermination is regulated by more than one organizational entity.

• “Emerging Service” is the service provided by the SoS itself and not any of theindividual autonomous systems. The attributes of the emerging service may bedifferent than the sum of attributes of the autonomous systems.

• “Dependability” (Laprie, 1992) is that property of a computer system such thatreliance can justifiably be placed on the service it delivers. The term encompassesa number of non-functional properties such as reliability and availability.

• “Organizational Failure” (Periorellis & Dobson, 2002) is an exception thrown by thebusiness logic of an SoS. In most cases it does not manifest itself as a software error,although software is the cause of it.

Background

In the next paragraphs we explore the notion of systems of systems, which implies thedeployment of autonomous systems to build larger, more complex ones while at the sametime we move from the organizational context of single control to a global domain wherecontrol is distributed. The originality of the notion of systems of systems lies in the fact

142 Periorellis


that we are not simply talking about distributed processing but, more importantly,distributed control. Let us turn our attention to a simple process model (Figure 1). Thisis a model of the kinds of process that take place in an organisation.The scooping-related processes are market-facing, dealing with questions such asdeciding on position within the market — and indeed which market — monitoring themovement of the market and deciding on appropriate responses, and — for some kindsof business — actually making the market.Resourcing processes are supplier-facing. They are concerned with acquiring sufficientresources (including, of course, human resources) to run the business, maintaining thoseresources, monitoring their quality, managing suppliers, and so on. Delivery processesare customer-facing. They are concerned with obtaining and fulfilling orders, enlargingthe customer base, obtaining feedback as a useful form of input to the scoping processes,and evaluating the resourcing processes. Again it is easy to see a number of possiblefailure modes immediately, such as inappropriate market positioning, inadequateresourcing and delivery processes, and failures in communication both within andbetween these processes. A typical failure in the travel agency case study is that ofcustomer base, or individual booking services targeting different types of customer. Onevery common way in which these processes are composed is in a supply chain or network,

Figure 1. The circles indicate distinct organisational entities while lines indicatedependencies.

market

scoping

resourcing delivery

suppliers customers

Figure 2. The circles indicate distinct organisational entities while lines indicatedependencies. The bold line indicates a supply demand channel.

scoping

resourcing delivery

scoping

resourcing delivery



in which the unit of composition is linking the resourcing and delivery processes (Figure2).We can now see additional failure modes concerned with mismatch of various kindsbetween organisations represented by the bold links (Figure 3).This is a type of data that is not accessible via the interface. The point we want to bringacross is that information passed via interfaces is largely inadequate, and a large amountof information is assumed (Periorellis & Dobson, 2001). In case of a supply chain whereone is concerned with extracting value from a market, there needs to be some agreementon the apportionment of value, and this can only occur within the scoping processes.There is also the possibility of mismatch between the scoping decisions. For example,a travel agent will normally try to match the market position of the hotel with the marketposition of the airline, preferring to fly travellers to cheap hotels using no-frills carriersor to expensive hotels using full-service carriers, and indeed may choose to specialize inone end of the market or the other.

So What Can Go Wrong?

Although the scoping/resourcing/delivery model describes an organisation in terms ofprocesses, these processes do not always (or indeed hardly ever) employ distinctmechanisms. Thus the delivery mechanism will embody aspects of the (results of the)scoping process and so on, all the way around. This means that we cannot assume thatwe can provide a failure-proof (where failure implies inability to offer the intendedservice) travel agent simply by connecting together delivery mechanisms from compo-nent suppliers. A well-known example in the travel agent domain occurred a couple ofyears ago, when customers of a well-known no-frills airline realized that although theflights were inexpensive, that was not the case for the hotels. Although the airline thatprovided the online booking had successfully connected to a hotel broker that provided

Figure 3. In autonomous systems more often than not we assume certain aspectsregarding the scope of the component (that is, the customer-base targeted) or itsquality (reliability of its resource). None of these are made explicit at the level of theinterface, hence the question mark on the dotted line.

scoping

resourcing delivery

scoping

resourcing delivery

scoping

resourcing delivery

?

144 Periorellis


rooms in well-known hotel chains, it failed to realize that the broker aimed at a differentcustomer base than the airline. Therefore although the airline tickets were within the no-frills price range, the hotels were not. Other examples of scoping mismatch includemarketing policies, operational policies (that is, cancellations), and systems with differ-ing models of trust. These policy mismatches should not be seen as mere technicalglitches to be overcome by ingenious Java programming. Rather they are policymismatches that constitute a fault that may result in a failure of the travel agent to deliveran adequate service to the customer, and recovery management needs to be addressedat that level.

Architecting an SOS to Create anEmerging Service

We have learned so far that building systems of systems is not by any means only atechnical challenge. In fact many of the major problems in the case studies we examinedstem from organizational incompatibilities. From the case studies we learned the impor-tant areas to look at in order to build requirements and how one can gain extra added valuefrom systems that move outside organizational (or, in some cases, national) boundaryand at what cost.Organizational boundaries that surround various systems can have an immediate effecton the way the system is perceived, developed, and consequently delivered. Theproperty of distributed control is what distinguishes an SoS from other component-based distributed systems. By control of course we imply authority to regulate andimpose structure and operational policy to the emerging service, initiate and terminatetransactions, as well as regulate access to the sub-systems of an SoS. By emergingservice we do not simply imply the sum of all services of the autonomous systems. Asurprising outcome of such integration is that an SoS may indeed exhibit properties thatdo not necessarily stem from any of the participating systems.Ashby (1956) illustrates this better with his example about the elastic band, where hedescribes how the property of elasticity is found only in the band and not in the individualthreads themselves that form the elastic band:

For years physical chemists searched for what made the molecule contractile. It is nowknown that the rubber molecule has no inherent contractility. Why then does rubbercontract? The point is that the molecules, when there are more than one, jostle eachother and thereby force the majority to take lengths less than their maxima. The resultis that a shortening occurs, just as if, on a crowded beach, a rope fifty feet long is drawnout straight: after a few minutes the ends will be less than fifty feet apart (p. 112).

In systems of systems one can observe similar examples of properties that were part ofthe emerging service only and not properties of the individual systems. These properties



can yield hidden treasures that all participating systems can benefit from. In the exampleof the Electrical Power Distribution case study one surprising attribute was that of wastemanagement. Waste management is not something that all systems had catered for. Thecomposition of the individual national systems into a pan-European network had thisattribute. It was a result of re-directing electrical power (that is, it stemmed from theoperation of the emerging service), but nonetheless it was not part of the individualsystems. However, before attempting to build an SoS, and before this whole new trendcan bear fruit, we need to avoid certain traps. Given that a system’s behavior can reflectpolitical, economic, or cultural interests, in particular the diversity of these can hinderthe emerging new service.So what is missing and we want to bring forward through this chapter are key issuesrelated to the integration of largely autonomous systems, the boundaries that can hinderintegration and furthermore discuss the notion of emerging system properties. Webelieve that by dealing with these issues early on in the development process of a systemwe can avoid what we call organizational failures and furthermore take advantage of theadded extra value emerging properties can offer. From our practical experience we havederived that there are basically five areas that we need to address before putting togetherrequirements, namely regulation of emerging service, composition, transactions (in theirbroader term), evolution, and dependability. Each of these reveals a number of issuesimportant in engineering requirements for integration. As many readers who work in thearea will no doubt know, there are several layers of requirements engineering rangingfrom high-level requirements that consist of strategic objectives to lower-level networkand engineering-related tasks. In our model, which is being presented from here on, weare concerned with the requirements surrounding the emerging service itself, which isin other words what the system of systems delivers.

Regulation of Emerging Service

The rationale behind this is that since we have a number of controlling organizationalentities, we also need an overall agreement for the composition, operation, and conse-quent termination of the emerging service. In the travel agent case study this manifestedas an overall agreement regarding cancellation and booking policies. In the EXAMINEcase study this manifests itself as a common economic policy. Since we have talked aboutthe need to compose the emerging service according to some rationale, we should stressthat the rationale of such a composition should stem from the regulations of the emergingservice. We identified during the development of the travel agent case study that theemerging service is more than just a front end between the consumer and the serviceproviders (autonomous systems) that manages transactions via exception handlingschemes. Similarly in the electric power distribution case study a European Wideelectrical power distribution system cannot be a network of interconnected nationalgrids. There has to be regulation regarding its operation. Regardless of the time of itsphysical existence it needs to be regulated in terms of scope and operational policies. Itis only then that intelligent composition can really take place. This is something that is

146 Periorellis


in many occasions omitted in service-oriented engineering, especially in cases where theservices are in fact small processes.The scope of the emerging service determines aspects such as the type of consumer.Immediately this enables the composition process to reason about the type of autono-mous systems that can be utilized since the consumer types would need to be similar.Also operational policies that regulate how the emerging service should be providedwould allow one not only to reason about the compositional semantics but also determinethe type of functionality the SoS would need to provide. Composing an emerging servicehas been proved not to be as easy as putting together (or even wrapping) methodsborrowed from autonomous systems. Additional consideration is needed when the SoS“adopts” a method from a component system in order to carry out a service. Althoughwrapping allows us, to an extent, to control the I/O of the method, it does not resolveproblems stemming from the mismatches between operational policies that may existbetween the SoS and the autonomous systems. An example of this can be the cancellationmethod of hotel booking systems. Although a large number of them would only requirethe booking reference number, policies regarding cancellations vary considerably. Allsorts of problems arise when these policies do not match the policies of the SoS, namelymaintaining the state, coordinating the transactions (as we shall see later), carrying outcompensation, and so forth.We therefore argue that the emerging service itself needs to be regulated. In technicalterms policies regarding scope and operations would need to be represented in datastructures that would in turn be used to reason (accept or reject) certain configurations.This need is even more apparent when one considers evolutionary aspects of autono-mous systems. We need some way of capturing those and making sure that thecomposition of the emerging service from individual autonomous systems (and thereforetheir policies) reflects what the emerging service is regulated to provide.

Composition

We view composition of the “emerging service” as the process that ensures that goalsembedded in the design and execution of individual autonomous systems do not bringthe services of the SoS into conflict. We consider this view appropriate since thecomposition of the emerging service is based on systems of diverse objectives, opera-tional policies, architectural styles, and implementation. In other cases (EXAMINE)these conflicts may take the form of political or social disputes. Having already reportedon the issues regarding the crossing of organizational boundaries and fault tolerantpolicies in SoS in Dobson & Periorellis (2002), we need to look how goals embedded intoan autonomous system can affect the composition of the SoS. In particular we want toidentify, eliminate, and reconcile conflicting goals while at the same time promotingcomplementary ones. Note here that we use the term “goal” in order to abstract from bothcase studies, since in the TA what we regard as goals maps onto organizational strategyand in the case of EXAMINE maps onto national interest. In both cases, however, it isimportant to acknowledge the need for composing emerging services according to a



rationale. Bear in mind that the purpose of a system of systems is to compose an“emerging service” by making use of existing services offered by autonomous systems,each of which has its own goals, culture, history, and so forth.It has already been discussed by Lamsweerde (2001) that goal-orientated approaches tosystem composition can increase the visibility of goal relationships that can exist. Thisis an important benefit of such a compositional approach, as such goal-relationships willbe subtly specific to the particular compositional context and require greater insight intotheir evaluation and design. However, more generally, it can be seen that three principalrelationships can exist between associated goals that may result from contributingautonomous components in an SoS. First there are complementary goal-relationshipsthat have a reinforcing effect upon each other. As an example consider integrating twosystems that target the same market base. Such relationships require little, if any,recomposing (and cannot only be readily integrated) but increase the dependability andvalue of the emergent service. One of the requirements of the European Union ElectricalPower System is a common market environment (open market) where all participatingsystems adhere to the laws of trading and competition. Secondly, in some situations,while goal relationships may not be complementary in a pre-existing sense, they may stillbe compatible in terms of being more readily reconcilable with each other throughconceiving alternative compositional approaches to achieving an emergent service.Compatible communication protocols would allow integration between components.Continuous monitoring of the performance could reveal further information regardingembedded goals. Lastly, and inevitably, there exist conflicting goal relationships. It isimportant that such relationships between autonomous components are identified earlyso that increased compositional effort can be focused on these areas to influence eitherthe appropriate selection of alternative (and more accommodating) components or toensure that such relationships have the major influence on the architecting of theenvisaged coordination system. In some situations this may involve configuration ofconflicting goals into higher or lower prioritization status.

Transactional Handling

In integrating systems to create systems of systems we are primarily concerned withmulti-party transactions that are distributed over many locations and that may requirea considerable time to complete. Each party in such a transaction has a set of pre-conditions and a set of post-conditions that must be met before the transaction is judgedto have been successful from that party’s point of view. Thus, for a transaction to bejudged to be wellformed, the evidence, embodied in a set of instruments, must reliablyreflect the intended acts of remote parties. For this to be the case, there are threecharacteristics of the instruments and the operations on them that must be assumed:

• Atomicity: Specific actions occur exactly once or not at all, and the parties are ableto confirm completion of an action.

148 Periorellis


• Persistence: Once information is generated it does not disappear; it may bechanged, but the instrument(s) must record the original and the changed informa-tion.

• Security: which, in this case, also refers to the authenticity and integrity ofinformation represented in instruments.

Our experience tells us that not all transactional problems can be solved at the machinelevel. In fact in cases where atomicity cannot be guaranteed, we need to address theproblems that arise at the business level. A structuring suggestion that has beenextensively tested is that of using Coordinated Atomic actions (Zorzo, Periorellis, &Romanovsky, 2003). It uses multiparty transactions to carry out specific functions, andwe place these within a context (which can be thought of as a box) inside which exceptionhandling occurs. We need, therefore, to recognize that with transactions that crossmultiple domains of management, notions such as persistence and atomicity cannot beassumed. There are two configurations of the relationships of a multi-party transactionat the structural level. In this discussion the term “structural” applies to the roles andresponsibilities of the actors directly participating in the SoS while “infrastructural” rolesand relationships are those associated with the deployment of reusable, generic re-sources that are exploited in the execution of structural relationships.

• A centralized transaction monitor in which each of the participants has a directrelationship with one particular participant in the role of transaction manager. Thelogical point of co-ordination is also a physical point of control.

• Distributed transaction management, in which each participant undertakes trans-action management responsibilities, and the logical point of co-ordination is, infact, replicated and distributed.

In the first approach, which is implemented by transaction monitoring functionality, alltransacting parties must have a pre-defined relationship with one particular partyresponsible for the co-ordination. “Pre-defined” here means that these relationshipswere established outside the context and infrastructure in which the transactions will beexecuted. In the second, which is implemented in distributed transaction management,each party depends on all the others and must be able to monitor and interpret their acts.These two approaches to the allocation of responsibilities in a distributed transactionresult in a different relationship between structural and infrastructural responsibilities.Atomicity of operations, persistence of information and security, and authenticity andintegrity of messages are dependabilities, or qualities of service that are delivered at thestructural level either as end-to-end or centralized mechanisms.In the case of a distributed transaction the economies of provision are quite different.Since each participant takes responsibility for components of the transaction and needsto be able to monitor remote activities and states, each needs to be able to rely on thequality of a set of service and applications, components within their own domain and ineach of those of the other participants. In this case the pre-established relationship mustbe with the infrastructural suppliers, and it is possible that the transacting parties are



establishing a new context as well as a new instance of commerce. In this case, newinstruments, which arise from the characteristics of the new context, may well be required.In the distributed approach to transaction management, and here we are concerned notmerely with distribution over time and space but, more significantly, distribution over theboundaries of different enterprises, each enterprise must have the option and capabilityof replicating all of those aspects of transaction co-ordination that are relevant to theirparticular interests. They must also be able to rely on the provider of the infrastructuralenvironment to ensure that their view of the current state of any transaction is coherentwith the views of all the other participants of that transaction. Thus atomicity, persis-tence, and security become responsibilities of the environment provider and infrastructuralin nature, and it is these qualities of service and application that dictate the character-istics of the instruments of the structural conversations.

Evolution

This paragraph discusses the possibility of the individual parts of an SoS evolvingindependently. An SoS integrates systems that might be under the control of organiza-tions totally separate from that commissioning the overall SoS. In this situation it isunrealistic to assume that all changes to the interfaces of such components will benotified. In fact, in many interesting cases, the organization responsible for the compo-nents may not be aware of (all of) the systems using its component. One of the mostchallenging problems faced by researchers and developers constructing dependablesystems of systems is, therefore, dealing with online (or unanticipated) upgrades ofcomponent systems in a way that does not interrupt the availability of the overall SoS.It is useful to contrast evolutionary (unanticipated) upgrades with the case wherechanges are programmed (anticipated). In the spirit of other work on dependable systems,the approach taken here is to catch as many changes as possible with exception handlingmechanisms. Dependable systems of systems are made up of loosely coupled, autono-mous component systems whose owners may not be aware of the fact that their systemis involved in a bigger system. The components can change without giving any warning(in some application areas, for example, Web services, this is a normal situation). Thedrivers for online software upgrading are well known: correcting bugs, improving (non-) functionality (for example, improving performance, replacing an algorithm with a fasterone), adding new features, and reacting to changes in the environment. When acomponent is upgraded without correct reconfiguration or upgrading of the enclosingsystem, problems similar to ones caused by faults occur. Changes to components canoccur at both the structural and semantic level. For example, changes of a componentsystem can result in a revision of the units in which parameters are measured (for example,from Francs to Euros), in the number of parameters expected by an operation (for example,when an airline introduces a new type of service), and in the sequence of information tobe exchanged (for example, after upgrading, a hotel booking server requires that a creditcard number is introduced before the booking starts).Although there are several existing partial approaches to these problems, they are notgenerally applicable in our context. For example, some solutions deal only with pro-

150 Periorellis


grammed change where all possible ways of upgrading are hard-wired into the design andinformation about upgrading is always passed between components. This does not workin our context, in which we deal with pre-existing component systems but still want tobe able to deal with interface upgrading in a safe and reasonable fashion. Otherapproaches that attempt to deal with unanticipated or evolutionary change in a way thatmakes dynamic reconfiguration transparent may be found in the AI field. We believe thatwe need to use fault tolerance as the paradigm for dealing with interface changes: specificchanges are clearly abnormal situations (even if the developers accept their occurrenceis inevitable), and we view them as errors of the integrated SoS in the terminologyaccepted in the dependability community. Error detection aims at earlier detection ofinterface changes to assist in protecting the whole system from the failures that they cancause. For example, it is possible that, because of an undetected change in the interface,an input parameter is misinterpreted (a year is interpreted as the number of days the clientis intending to stay in a hotel), causing serious harm. Error recovery follows errordetection and can consist of a number of levels: in the best case dynamically reconfiguringthe component/system and in the worst resulting in a safe failure notification and off-line recovery.We also believe that we need a structured approach to dealing with interface changesthat relies on exception handling, which in turn should be incorporated into an SoS. Thegeneral idea is straightforward: during SoS design or integration, the developer identifieserrors that can be detected at each level and develops handlers for them. If handling isnot possible at this level, an exception is propagated to the higher level and responsibilityfor recovery is passed to this level. In addition to this general scheme, study of someexamples suggests classifications of changes that can be used as check lists. At thisstage we would also like to acknowledge the need for communicating semantic informa-tion between component systems. Being able to communicate additional semanticinformation may resolve some of the conflicts discussed earlier but also enable betterhandling of interface upgrades. In the initial stages we found that in order to communicatesemantic information between two components we need a structured collection ofinformation (meta-data) as well as a set of inference rules that can be used to conductautomated reasoning. Traditionally knowledge engineering (Hruska & Hashimoto, 2000),as this process is often called, requires all participants to share the same definitions ofconcepts. Knowledge bases, however, and their usage does not necessarily make thesystem more flexible; quite the contrary. Requests would have to be performed understrict rules for inference and deduction. The SoS would have to process its metadata(globally shared data descriptions) in order to infer how to make a request for a particularmethod (that is, booking a flight) and furthermore infer what parameters accompany thismethod and their meaning.

Dependability

Let us finally address some dependability concerns. Change or evolution has alwaysbeen a difficult issue to deal with in technical terms, although vital in the survival ofsystems. Open systems architectures and frameworks serve well as vehicles for dealing



with this issue. The SoS, however, challenges the main assumption. Since we put togetherautonomous systems, that is, systems with existing strategic, tactical, and operationalgoals, issues such as common interest or common goals (if they exist) have to be madeexplicit. So where are these issues made explicit?From a dependability point of view we are trying to provide a framework for puttingtogether systems in a dependable manner. The notion of SoS, however, challenges thisissue. In dependability terms, an assumption we have been taking for granted is that ofa universal (or system-wide) judge, a judge that identifies faults and errors, andacknowledges deviation of intended service. This notion of judgment exists within thesame organizational boundary as the information system and is exercised by theorganization itself. When we put together systems of systems we also bring togetherthese judging systems in a network of goals mapped onto computer systems, assessedby autonomous judgment systems. Bearing in mind that we have such a diversity of goalsand “intended behavior”, who can judge the “intended behavior” of Systems of Systemsand, furthermore, who is the judge of the system of systems?Putting systems together implies a common interest reflected on what we call “emergingservice.” Deviating from the emerging service can be regarded as a failure. This, however,does not imply that the individual autonomous system failed. So we are moving fromdeviation of intended behavior to deviation of common interest. Maintaining a commoninterest would require analyzing the roles and responsibilities of all participating systemsin an effort to maintain a state of affairs. A system of systems can reveal properties thatare not found in any of the autonomous sub-systems. This can really increase the valueof the SoS and generate new revenues for the individual autonomous systems throughthe SoS interface. So in a sense maintaining the SoS by dependably maintaining theindividual systems is in the interest of the system provider. The emerging properties ofthe SoS are, in fact, the common interest. At this point in time we lack enough tools thatwould allow us to study this problem space. We need, however, to address it at theconceptual level in order to clarify the dependability requirements of the system.

Conclusion

We hope through this limited space that we managed to give an idea of the risks but atthe same time the vast potential of putting systems together. Current architectures donot address organizational issues when it comes to systems integration via technologiessuch as web services. We studied these issues for a number of years, and we firmlybelieve that it would benefit anyone to read about the organizational pros and cons ofsuch technologies as opposed to their technological advancements. We concentratedon five distinct areas that are of greatest importance during the integration process inorder to help developers understand some of the issues surrounding integration.We showed how boundaries that surround various systems can have an immediate effecton the way the system is perceived, developed, and consequently delivered. We showedone of the most important attributes to be that of control. This is what distinguishes anSoS from other component-based distributed systems. By control we mean authority to

152 Periorellis


regulate and impose structure and operational policy of the emerging service but also toforesee future behavior of a system, initiate and terminate transactions, as well as accessall components of an SoS. Given this additional dimension we believe that addressingthese issues would enable developers or regulators of an SoS to capture certain type ofnon-technical failures (organizational failures) early prior to the requirements analysisstage.We drew our conclusions and examples primarily from the TA case study and, to a lesserextent, EXAMINE. Although there is a lot of literature on architecture and design, wefelt that there is little or no work available to address SoS-specific issues. The mostimportant of those relate to the way the emerging service is composed, regulated,delivered, and how it evolves. Since there are a number of tools and methodologiesaddressing structuring techniques and design patterns, we concentrated on conceptsthat would allow us to look at this new problem space that an SoS addresses.

References

Ashby, R.W. (1956). Introduction to cybernetics. Methuen & Co.Dobson, J., & Periorellis, P. (2002) Models of organisational failure. Dependable

Systems of Systems Project (IST-1999-11585). University of Newcastle upon Tyne.UK. Online www.newcastle.research.ec.org/dsos/.

Ferrante, A., & Diu, A. (2002). Needs Expression: Revised Version. Technical Deliver-able. EXaMINE Project (IST-2000-26116).

Hruska, T., & Hashimoto, H. (Eds.) (2000). Knowledge-based software engineering. IosPress.

Lamsweerde, A. (2001, August). Goal oriented requirements engineering: A guidedtour. Proceedings of RE’01 5th IEEE international symposium on RequirementsEngineering, Toronto.

Laprie, J.C. (1992). Dependability: Basic concepts and terminology. In T. Anderson,Avizienis, & W.C. Carter (Eds.), Series: Dependable computing and fault-tolerantsystems, vol. 5. New York: Springer-Verlag.

Periorellis, P., & Dobson, J.E. (2001). Case study problem analysis. The travel agencyProblem. Dependable Systems of Systems Project (IST-1999-11585). University ofNewcastle upon Tyne, UK.

Periorellis, P., & Dobson J.E. (2002). Organisational Failures in Dependable Collabo-rative Enterprise Systems [Special issue]. Journal of Object Technology, 1(3), 107-117.

Zorzo, A.F., Periorellis, P., Romanovsky, A. (2003, January 15-17). Using coordinatedatomic actions for building complex Web applications: A learning experience.Proceedings of the 8th IEEE International Workshop on Object-oriented Real-timeDependable Systems (WORDS 2003), Guadalajara, Mexico.

Requirements Engineering for Technical Products 153


Chapter X

RequirementsEngineering for

Technical Products:Integrating Specification,

Validation and ChangeManagement

Barbara Paech, University of Heidelberg, Germany

Christian Denger,Fraunhofer Institute for Experimental Software Engineering, Germany

Daniel Kerkow,Fraunhofer Institute for Experimental Software Engineering, Germany

Antje von Knethen,Fraunhofer Institute for Experimental Software Engineering, Germany

Abstract

Over the last few years the functionality and complexity of technical products hasincreased dramatically. This is reflected in the complexity of the development process.In this chapter we discuss in detail the resulting challenges that have to be faced byrequirements engineering. We identified these challenges in interviews conducted ata German car manufacturer. The main part of this chapter presents the QUASARrequirements engineering process that faces all identified challenges. In particular, itsupports: (1) a set of views and abstraction levels tailored to the stakeholders, (2)

154 Paech, Denger, Kerkow and von Knethen


communication about these views through understandable notations, (3) efficientaccess based on tools and traces that make relationships between views explicit, (4)explicit feedback based on inspection and simulation, and (5) overall quality byintegrating a formal specification technique with informal, textual specificationtechniques as well as through guidelines, checklists and tailored reviewtechniques.

Introduction

Technical products, such as automobiles, washing machines, or video recorders, playan important role in our daily lives. Over the last few years the functionality andcomplexity of these products increased dramatically. Reasons for this are a technologypush through reduced costs for hardware but also growing shares of software. Technicalproducts are specific sociotechnical systems. Typical sociotechnical systems, forexample, service engineer support systems, are characterized by many stakeholders indifferent roles that interact with the system. To understand and design such a systemadequately, stakeholders and their relationships, as well as the influence of the systemon the usage environment, have to be analyzed in detail (Sutcliff & Minocha, 1998). Fora technical product, typically, there is only a small set of users. In addition the contextof the user is already well known because products are typically developed in series.Therefore requirements engineering (RE) can concentrate on the interaction of the userswith the new functionalities of the product. However the development process has tobe reflected during RE. Technical products are sold on the market. They integratehardware, software, and mechanics. And for complex technical products such as carsseveral suppliers are involved. Thus viewpoints of various stakeholders with differingbackgrounds have to be elicited and integrated. Typically these stakeholders aredistributed over several companies and locations and work in a fast-changing environ-ment. This induces challenges for the whole product development process, and inparticular for identifying, collecting, managing, and validating requirements (Grimm,2003). In terms of the onion model of stakeholder relationships proposed in Alexander& Robertson (2004), this means that most stakeholders are found in the outer-most layers.Roles and often even persons involved in the development process of technical productsare typically quite stable and well-known because of the series development. To reflectthis situation, the emphasis during RE of technical products is on fostering long-termrelationships based on efficient communication between the stakeholders and not somuch on identifying the stakeholders.In the following we discuss in detail the challenges that have to be faced by RE fortechnical products. We identified these challenges in interviews that we conducted ata German car manufacturer. The main part of this chapter presents a prescriptive REprocess that faces all identified challenges. This process has been developed andevaluated during the last three years and is the major result of the QUASAR projectfunded by the German ministry for research. Throughout this chapter we use an example(that is, the development of a door control unit of a car) to illustrate the challenges and



all aspects of our RE process. This example is part of a typical industrial specification fora car control unit (Houdek & Paech, 2002).

Challenges of Technical ProductDevelopment

The purpose of this section is to characterize the development context of technicalproducts, identify the challenges, and motivate the importance of an adequate REprocess. We discuss also how existing RE approaches deal with these challenges.Technical products consist of embedded systems where mechanics, hardware, andsoftware together deliver functionality. The complexity and functionality of suchsystems increased dramatically over the last years. In particular, the quality aspects ofthese systems are of ever-growing importance, since the systems enable innovativeusage of highly sophisticated technology. The automotive domain can serve as areference example for this trend. In this domain complex embedded systems, such assteer-by-wire, electronic stabilization systems, antilock braking system, or seat position-ing, are nowadays standard components of a car. Thereby they take over and enhanceactivities that seemed to be inherent to human car usage. This, of course, highlights theimportance of quality such as reliability or safety. To provide such complex functionsand high quality, an increasing number of software components are needed in theautomobiles. These components are coupled by several networks and to the outer-carworld, for example, via radio link. One example is the current Mercedes-Benz S-class,which contains more than 50 controllers and 600,000 lines of code coupled by threedifferent bus systems (Grimm, 2003). Nowadays cars contain more software than the firstApollo rocket that flew to the moon.All of this has to be developed within extremely short time and low cost frames.Furthermore, car manufacturers need to involve suppliers on all levels of mechanics,hardware, and software. As software is the basis for competitive differentiation, theyhave to maintain a delicate balance of in-house development and procurement. Thisemphasizes the importance of the RE process, where all stakeholders need to commu-nicate effectively about the system to be built. In-house experience from DaimlerChryslerhas shown that more than 40 percent of errors occurring during automotive functions areattributable to requirements errors caused by immature specifications (Grimm, 2003).Figure 1 shows the typical stakeholders involved in car software development. As thecontrol software is embedded, it directly interacts with the electronics and the mechanics.Together they deliver the functionality of a component, which again interacts with othercar components or directly with the user. In this case the main user is the driver.Sometimes also the passengers are involved. In addition car repair personnel have aspecial interface to the software. People initiating, managing, and developing such acomponent are shown in the two outermost layers. These include — either in-house orat the suppliers — on the one hand the engineers responsible for the realization, namely



hardware, software, or system engineers, and on the other hand the project roles involvedin initiating and managing the project, namely marketing, sales, requirements engineers,quality engineers, maintenance engineer, and project manager.A RE process for technical products has to take into account all characteristics sketchedabove. In the literature, one mainly can find approaches that focus on the quality andcomplexity aspects. They aim at providing comprehensive tool support for precisespecification and quality assurance, and thus focus on formal notations based on statetransition diagrams (for example, Glinz, 2002; Harel & Politi, 1998; Heitmeyer & Bharadwaj,2000; Thompson Heimdahl, & Miller, 1999). Such notations, however, are not suitable forstakeholders such as product marketing or management. Typically experts are needed tohandle these notations. This in turn complicates the involvement of small and mediumsuppliers that cannot afford such experts. On the other side of the spectrum areapproaches focusing only on textual documents such as use cases (Cockburn, 2001).This supports the communication of different stakeholders distributed over differentcompanies but does not support the precision and rigor needed to achieve high quality.Therefore in QUASAR we aimed at an approach that combines these two extremes andthus supports informal and creative communication, as well as precise specification andtool-based quality assurance.

Requirements Engineering for TechnicalProducts

In this section we motivate and present the most important facets of the QUASARrequirements process for technical products. In the first subsection we discuss detailed

Figure 1. Stakeholder in car control software development

Control software

Car eletronics

Car mechanics

Car components

Driver Passenger

Marketing Sales

HW Eng.

SW Eng.

Sys. Eng.

Inhouse

Project manager

Supplier Marketing

Sales

HW Eng.

SW Eng.

Sys. Eng.

Project manager

Car repair

Requ. Eng.

Qual. Eng.

Maint. Eng.

Requ. Eng.

Qual. Eng.

Maint. Eng.



issues in the requirements process. The second subsection presents our process, inparticular the integration of specification, change, and quality management.

Issues in the RE Phase of Technical Products

In this subsection, again, we take the example of the automotive industry to illustrate atypical RE process and its challenges. This is based on interviews conducted at a Germancar manufacturer. It details the challenges resulting from the complexity of the productand process and the high demands on quality. Then we discuss the techniques that canaddress these challenges.

A Typical RE Process

During the management and product marketing of the car, manufacturers decide oninnovative features of the next car series. These considerations are incorporated intorequirements documents and handed over to several suppliers. Typically these docu-ments capture the context of the system functions and many technical details, but nocoherent view on the functionality or required quality. In particular the user view is notexplicit. Often the documents comprise up to several hundred pages. Sometimes thesuppliers capture their understanding of the requirements into specification documentsas the basis for discussion and negotiation with the procurers. This specification alsoserves as detailed instruction for its developers. Often the suppliers use only informalnotes on the basis of the requirements document to define the functionality andcommunicate it to the developers. Both sides try to reuse as much as possible from earlierprojects to save time and effort. Of course this bears the risk of introducing inconsisten-cies and omissions into the documents. All stakeholders pursue their own interests andadhere to different constraints. This includes a product perspective as well as a human-or technology-oriented perspective. For example marketing wants to specify innovativeproducts, project managers have to cope with time restrictions, users want to havecomfortable products, and suppliers want to push their own technology. These viewsare typically implicit and scattered throughout the documents.Furthermore all documents are subject to frequent change, since often requirements arenot clear at the beginning (due to innovative features) or they evolve due to changes inthe organizational and technical project context.

Improving the Process

This process can be improved wrt. managerial challenges such as time and cost as wellas wrt. sociotechnical challenges: handling the sociotechnical complexity of the product,handling the quality of the product, and handling the communication between thestakeholders.



Obviously, to cope with the complexity of the product and to enhance the communicationbetween the stakeholders, one should make all the different views explicit in one orseveral documents and use requirements management tools to facilitate access, reuse,and change.To represent the different views different notations, different levels of abstraction, anddegrees of detail must be dealt with: for example, sales produces high-level productspecifications for the offer, which focus on business issues; usage descriptions canserve as high-level goal description from the user point of view; a software engineerneeds detailed technical requirements. In particular it is important to make the user viewexplicit. This is typically not communicated to the engineers but is essential to ensurethe sociotechnical adequacy of the product.To ensure consistency between the different views and abstraction levels it is importantto systematically and efficiently establish relationships between them. Such a relationis in particular needed to bridge the gap between the high-level user requirements andthe more detailed technical requirements. To cope with frequent changes and shortdevelopment cycles, efficient traceability throughout the whole RE process and to thelatter phases is needed. This supports change-impact analyses (that is, identificationsof entities affected by proposed changes) and efficient communication of these impactsto relevant stakeholders. Clearly traceability can only be executed efficiently throughtool support. As traceability induces new effort for the requirements engineer who hasto establish traces, it is important to take motivational factors into account.Quality can be improved by using more precise specifications techniques. Quality as wellas practicability and repeatability can be supported by constructive quality assurancein terms of guidelines and templates, and by analytic methods such as inspections andsimulation. Both enhance the communication process between the different stakehold-ers as a side effect.Of course there are several approaches for all these techniques (for example, Sommerville& Sawyer, 1997). The main challenge, however, is to integrate all of them efficiently. So,for example, documents and included notations have to be tailored to the stakeholders.Inspections, traceability guidelines, and management tools have to be adapted to thedocuments.Clearly an improvement to this process is only helpful if it gains the acceptance of allstakeholders in the RE phase and requires only minimal additional effort and trainingof them. In particular this implies that novices and experts can apply the approach andtools are used efficiently. Therefore detailed guidelines capturing the experience of theexperts have to be provided.

An Integrated RE Approach for Technical Products

In this subsection we present the QUASAR process in detail. We focus on three roles.Of course there are many activities associated with these roles. In the following we onlyconcentrate on the activities most important for the issues identified above:



• Requirements engineer: This role is representative for the issue of supporting thecommunication between the different stakeholders. In particular it needs to bridgethe gap between user requirements and technical requirements.

• Quality engineer: This role is representative for the issue of ensuring qualitycontinuously for all requirements as early as possible.

• Maintainer and project manager: These roles are representative for the need toefficiently cope with change.

While discussing these roles separately, we discuss the integration of the correspondingtechniques throughout.Figure 2 depicts the different elements of the QUASAR-RE process. In the following wedescribe the basic steps in this process.

Document creation (Step 1 and 4):The requirements document (RD) and the specification document (SD) are created by therequirements engineers of the car manufacturer and suppliers, respectively. This cre-ation step is supported by guidelines and templates. In addition, the CASE-tool“Rhapsody” (Rhapsody) and the requirements management (RM) tool “RequisitePro”(RequisitePro) are used as supporting tools. We chose “Rhapsody” over “STATEMATE”as it also supports object-oriented structuring, which greatly improves readability of thediagrams. We chose “RequisitePro” because it allows working directly with WORDdocuments. Therefore it was near to the existing working environment of the require-ments engineers. Of course it is possible to use any other requirements management tool,such as “DOORS” (Telelogic).

Figure 2. The QUASAR-RE process

specificationdocument

B

DC

A

requirementsdocument

Rhapsody-

elicit anddocument

Requisite-Pro

Creationguidelines(i.e., template

and UC guidelines)

establishRD traces

Tracingguidelines

verify RD

Inspectiontechnique

derive

establishSD traces


and SC guidelines)

Tracingguidelines

verify SD

Inspectiontechnique

�

�

�

�

�

�

QuaTrace tool

specificationdocument

BB

DC

A


DC

A


Rhapsody-

elicit anddocument

Requisite-Pro


and UC guidelines)


and UC guidelines)

establishRD tracesestablishRD traces

Tracingguidelines

Tracingguidelines

verify RD

InspectiontechniqueInspectiontechnique

derive

establishSD tracesestablishSD traces


and SC guidelines)


and SC guidelines)

Tracingguidelines

Tracingguidelines

verify SD

InspectiontechniqueInspectiontechnique

�

�

�

�

�

�

QuaTrace tool



Traceability (Step 2 and 5):Traces between documentation entities within the RD or the SD, or between entities inthe SD and the RD, need to be established to support project and change management.QUASAR provides tracing guidelines and a tool environment. In contrast to othertraceability techniques (Ramesh & Jarke, 2001) our technique gives detailed guidance onwhat traces should be established to support later impact analyses (von Knethen &Grund, 2003). Furthermore the technique defines who should establish traces when, aswell as who should analyze traces how. In addition the tool environment providesfacilities to perform (semi-) automatic impact analyses and to guide implementation ofchanges. These facilities support the maintainer and project manager.

Inspection and Simulation (Step 3 and 6):The RD and SD are inspected for defects to assure the quality of the requirementsdocuments early in the development process. We provide tailored perspective-basedinspection techniques that facilitate defect detection and emphasize knowledge andexperience transfer. This includes the use of the simulation facilities of the tool“Rhapsody.” It also includes test-case derivation as part of the tester reading scenario.

In the following sections, we show how requirements engineers, quality engineers, andmaintainers use the different QUASAR techniques and motivate our choice of notationsand tools.

Supporting Different Views

The requirements engineer of the car manufacturer creates the RD. The RD must supportcommunication between management, marketing, and user experts about the function-ality (in particular innovations). In addition the supplier must be able to understand whythe specified system functions are needed. Thus the requirements engineer captures thecontext of the functions through use cases (UC). She abstracts from detailed systembehavior, that is, system internal technical details that are not visible to the user. Thismeans she abstracts from sensors, actuators, or user interface details. Instead she usesmonitored and controlled variables to describe inputs and outputs (Parnas & Madey,1995). This abstraction in particular helps to focus on the essentials of the sociotechnicalaspects of the product. The UCs also support quality assurance, as they are a good basisfor test-case derivation.The requirements engineer at the supplier creates the SD. The SD must supportcommunication between developers about the functionality. In addition developers atthe car manufacturer need to verify that the required system functions from the RD arecovered in the SD. The requirements engineer captures the details of the systemfunctions with Statecharts (SC). SCs describe efficiently the possible events and thesystem reaction. Developers are used to this notation in the car industries. SCs are also



a good basis for quality assurance, as there are powerful tools to support theirspecification and analysis.

Document Templates

During the creation steps the requirements engineers use QUASAR templates andQUASAR creation guidelines for the RD and the SD. The document templates are anadaptation of IEEE Std.830 (IEEE 830, 1998) for the domain of automotive systems(Kamsties, von Knethen, & Paech, 2001). The template captures experience with existingdocuments. It requires detailed contents, such as scope, purpose, customers of theproduct, functionality block description, production, process, and domain constraints.This helps to ensure the completeness of the documents.

UC Creation Guidelines

To specify the UCs in the RD, the requirements engineer follows specific guidelines.These guidelines collect ideas from literature and refine them for technical products. Firstthe requirements engineer creates a UC diagram by identifying the relevant actors andtheir tasks. This diagram gives an overview of the system functionality from a user pointof view; that is, the main tasks the system shall support. Moreover the diagram helps toidentify relationships between different user tasks by means of relationships betweenUCs.Then the requirements engineer refines each UC identified in the UC diagram by a textualdescription that clarifies the general task. She fills in a UC template for each identifiedUC. Figure 3 shows the most important facets of such a template. It is an excerpt of a UCfor totally moving a window in a car (up or down). In addition to the shown facets, thename of the UC, actors involved in the UC, the goal of the actor, and quality requirementsrelated to the UC are collected. The requirements engineer takes the name and actorsdirectly from the UC diagram. Then she elaborates the name with the actor goal. Shedetails this goal with the precondition and the postcondition. Next she collects themonitored and controlled variables relevant for the UC. Controlled variables describe thesystem parts controlled in this UC as well as system data created. Monitored variablescapture the different possibilities of the actors to trigger the system reaction as well asother system data needed in the UC.Now the requirements engineer focuses on the normal course of interaction betweenactor and system and the possible exceptions. This clarifies how exactly the user taskshould be supported by the system. Here she uses the essential UCs from Constantine& Lockwood (2001). To support a compact interaction description, the requirementsengineer captures details of the system reaction in the rules facet. To address the safety-critical characteristics of technical products, she puts particular emphasis on thespecification of exceptions. Therefore she analyses four types of exceptions explainedin the guidelines:



• Exceptions resulting from actor inputs outside of the UC (for example, the actortriggers partial window movement),

• Exceptions resulting from reaching limit positions,• Exceptions resulting from system behavior outside of the UC (for example, window

positioning might be dependent on the current speed),• Exceptions resulting from technical problems in carrying out the system reaction.

These exceptions induce different system behavior. In case of a limit position, forinstance, the system reaction is stopped. Another input triggers a new use caseexecution.Finally she documents all important traceability relationships between UCs and to otherrequirements (see section on change management).

SC Creation Guidelines

The SC guidelines give detailed instructions for the derivation of SCs from UCs; that is,for the derivation of the developer’s view (formal) from the user’s view (informal) on therequirements (Denger et al., 2003a). The main characteristic of these guidelines is that theSC structure mirrors the UC structure in order to facilitate lean traceability and easyunderstandability.

Figure 3. Excerpt of the UC “Total window movement”

Description 1. Actor totally moves the window into a certain direction

2. System reacts accordingly [Exception 2.1.: Actor moves the window partially] [Exception2.2.: Technical problem] [Exception 2.3.: Safety opening]

Exceptions 2.1. Partial movement: Use case “Partial Movement” 2.2. Technical problem: System does not react

accordingly 2.3. Safety Opening: System moves the window into its

lower end position Rules The system activates the “Safety opening” in the case that

the actor moves the window upwards but no change of the window position is recognized

Mon. Variables Window_Position, Actor_Input: movement type (partially/total) and movement direction (up,down)

Cont. Variables Window_Position Precondition - Postcondition Window has new position



In the first step the requirements engineer builds a class structure of the system basedon the UC structure. She models each UC, each monitored, and each controlled variableas a class and maps relations between UCs to associations between these classes.In a second step she creates SCs for every class describing a monitored or controlledvariable. She represents the possible values of the variables as states. The transitionsbetween the states are triggered by events occurring in the environment of the system,that is, triggered by the actors of the system. She identifies such events in the facetdescription of the UC template. In a third step she builds an SC for each UC-class. Initiallythis SC contains two states (Figure 4):

1. an “idle-state” representing that the UC is not active and2. a “system-reaction-state” representing that the UC is active.

This simple structure of the SCs establishes lean traceability between the UCs and theSCs. The start of a UC is represented as a transition from the “idle-state” to the “system-reaction-state” (Figure 4, the external event “ev_Start_Total_Movement”), and the endof a UC is represented as a transition from the “system-reaction-state” to the “idle-state”(event “ev_Stop_Input”).The requirements engineer finds the events triggering these transitions in the UCtemplate facet description. The different exceptions are realized as additional transitionsfrom the “system-reaction-state” to the “idle-state” as well as guard conditions restrict-ing the transition from the “idle-state” to the “system-reaction-state.”The requirements engineer does not focus on minimality of the class structure or the SCs.Therefore it might be necessary to restructure the class diagram and the SCs during thedevelopment of the system design. During RE the direct traceability between RD and SD

Figure 4. Statechart of the Use Case “Total window movement”

s_System_Reaction

s_Idle

s_System_Reaction

s_Idle

ev_Stop_Input/ o_Stop_Window

ev_Start_Total_Movement[!( (itsWindow.isIn(upper_Limit)&& (params.pDirection == up)) || (itsWindow.isIn(lower_Limit)&& (params.pDirection == down)))]/ o_create_Interrupt(); o_Start_Window(params.p_Direction);

ev_Interrupt_Partial

ev_Limit_Position/ o_Stop_Window(); o_Notify_UC();



is more important than minimality. As shown in the next section UCs and SCs are alsoa good basis for quality assurance.

Quality Management Based onInspections and Simulation

The quality manager is responsible for early quality assurance. She uses perspective-based inspection (Basili et al., 1996; Laitenberger, 2000) to ensure that all importantstakeholders give early feedback to the documents and that each document is scrutinizedwrt. a wide variety of viewpoints. The most important stakeholders of the RD and SD aremarketing of the car manufacturer, requirements engineers, system, hardware andsoftware engineers, testers, and maintainers. Each stakeholder uses QUASAR readingscenarios that are tailored to the quality needs of each perspective (Paech & Denger,2004; Denger & Ciolkowski, 2003). A reading scenario consists of a detailed descriptionof activities an inspector should perform and a set of questions that should be answeredwhile and after performing these activities. For example, the reading scenarios of thetester describe step by step how to derive test cases from the RD or the SD. Consequentlydefects that reduce the testability of the RD or the SD are detected. As the inspectorsperform activities typical for the stakeholder roles, the created results can be used in thefollowing as sketches for the real work products. With the reading scenarios the qualitymanager can also involve novices as inspectors, as they have detailed guidance on whatto look for. Inspections also support knowledge transfer between experts and novicesas experiences about typical defects are used to enhance the scenarios. Thus novicesquickly learn about important quality aspects and typical defects. Finally novices learnabout expert knowledge in the inspection meeting where the findings of all inspectorsare collected.As part of the inspections the quality manager uses simulation. The SCs are developedwithin the tool Rhapsody, which allows the behavior of the SCs to be executed andvisualized. Thus the quality manager checks for complex defects resulting from thedynamic interaction of specified functionalities. For example, typical scenarios from theUCs are checked against the SC to detect defects in the SCs due to wrong refinement ofthe UCs. In addition the visualization gives feedback on the behavior of the UCs. Thissupports the communication about the user point of view.

Change Management Based onTraceability Guidelines andRequirements Management Tools

Change management involves various roles: the requirements engineer who has toestablish traces that can be analyzed, the project planner or project manager who has to



analyze traces in order to estimate the costs of proposed changes, and the maintainer whohas to analyze traces to implement proposed and agreed changes consistently. There areother roles that are also involved in change, such as the quality engineer who has to verifythe quality of changed documents. However these roles are not yet supported by thechange management techniques of QUASAR.The requirements engineers create the different requirements documents with supportof the QuaTrace tool (Figure 5). They apply the tracing guidelines to establish tracesbetween related requirements (von Knethen, 2001b). The QUASAR tracing guidelinesreduce the necessity for explicit link setting by using implicit links such as name tracesor relationships given by the documentation structure. This reduces the effort forestablishing traces. The requirements engineers establish traces between textual re-quirements and model elements (for example, UCs, SCs) with the help of Rhapsody-Interface (that is, the first component of our QUASAR tool environment). Rhapsody-Interface allows model elements to be exported to RequisitePro, where the requirementsengineers are now able to establish traces. As soon as all implicit and explicit traces ofa requirements document are established, the requirements engineer extracts these traces(for example, a name trace between a natural language paragraph and a use case) by usingthe Relation-Finder. Relation-Finder stores all extracted traces in a relation file.The project planner and the maintainer use the Relation-Viewer to analyze the impactof changes (semi-) automatically. The Relation-Viewer analyses and visualizes the tracesstored in the relation file. It helps rating the effort and costs of changes (there is an exportfunctionality to Excel) and to change the requirements documents consistently. Themaintainer uses tracing guidelines to update established traces and add new traces, too.The tracing guidelines and the tool environment support efficient establishing of traces.However, due to the uncertainty of upcoming changes, the requirements engineer isoften not motivated to document his or her knowledge (see also work from organizationalpsychology about the importance of experienced meaningfulness, experienced respon-sibility and the knowledge about the results of work activities (Cook & Salvendy, 1999;Peters & Peters, 1999). Therefore the project manager has to make a tradeoff betweenoverspecification and demotivation of the requirements engineer and underspecification

Figure 5: The QuaTrace tool

Relation-Finder

Rhapsody-Interface

Relation-Viewer

R

relations file

Rhapsody

RequisitePro

tool environment



and overload of the maintainer. This tradeoff decision is supported by the followingadditional QUASAR practices:

• The requirements engineers anticipate change by eliciting possible changes torequirements. They highlight these requirements and capture dependencies to andfrom these requirements.

• The requirements engineers capture the rationale of a requirement based on aSocratic dialogue by asking three times “why” (Dutoit & Paech, 2001).

Evaluation

In this section, we summarize empirical studies on the QUASAR process. The firstempirical study was an experiment to evaluate the understandability of UCs comparedto unstructured natural language documents. One group of six practitioners read anunstructured RD of the seat positioning part of the case study. A second group of sixpractitioners read the same content but specified with UCs. After reading the documentseach subject had to answer questions regarding the content of the document. In orderto compare the understandability of the two notations, we measured the time for readingthe documents, the time for answering the questions, and the number of correct answersregarding the context (see comparable experiment designs, for example, in Kamsties, vonKnethen, & Reussner, 2003). The experiment showed that there was no difference in thecorrectness of the answers, it took more time to read the UC-document, and it took lesstime to answer the question for the UC-document.We did not check the statistical significance of our results because of the low numberof participants. However we think the results support the usefulness of UCs.The guidelines for the creation of the UCs and the UC inspection process were evaluatedin a case study in a practical course at the Technical University of Kaiserslautern. In thiscase study 12 students used the guidelines to create UCs of a building automationsystem. After the completion of the UC document, the students had to answer aquestionnaire regarding the usefulness and applicability of the guidelines. The guide-lines were perceived as useful and applicable by the subjects (Denger et al., 2003b).Furthermore the students used three tailored reading scenarios to inspect the UCs. Weanalyzed the effectiveness and the efficiency by measuring the number of detecteddefects and the time needed to perform the inspection compared to another inspectionapproach (checklist-based reading). Additionally the students participated in a surveyregarding the perceived usefulness of the reading scenario. On average a higher numberof defects was found with our inspection approach but more time was needed to performthe inspection. The reading scenario advises the inspectors to perform real workactivities on the document. The results of the questionnaire indicate that the detailedguidance given in the reading scenarios are perceived as helpful to support theinspection compared to a pure checklist.Finally the guidelines to derive SCs from UCs were successfully applied in a seminar withfour students at the Technical University of Kaiserslautern. The students reported that



the clear relationship (lean traceability) between the UCs and SCs imposed by theguidelines was very helpful. They appreciated the concrete guidance to develop anexecutable SC model from the UCs.Altogether these evaluations show that the templates and guidelines for the integrationof specification and quality assurance are helpful. So far we have not evaluated thechange management techniques in QUASAR. However similar techniques for a compa-rable documentation structure were evaluated in a controlled experiment and two casestudies. These results strongly suggest that the techniques have a beneficial effect onthe efficiency of impact analyses and the quality of the resulting set of change impacts(see von Knethen, 2001a; von Knethen, 2001b). Therefore we also have the indicationthat the change management techniques are helpful. Clearly it is difficult to judge theapplicability in industry from student experiments. In our view the main obstacle towidespread use of the QUASAR process is that the detailed guidelines have to beadapted to the company context. This additional effort should be outbalanced by thebenefits on the quality of the requirements.

Future Trends

We have presented an RE approach to cope with the major sociotechnical challenges oftechnical products.Future trends concern on the one hand improved RE and on the other hand innovationsin the technical products. An example for the former is the tight integration of inspection,simulation, and test case derivation as a means to enhance the quality of requirements.This can be achieved based on a defect classification, which allows the defect detectiontechnique to be chosen that is best suited to a defect class. In addition measurement ofthe defects found can be used to focus quality assurance effort. First results in thisdirection can be found in Freimut & Denger (2003).An example for the latter is the trend to telematics and infotainment in the car. Becauseof the innovative user interfaces, this requires in particular usability engineeringtechniques tightly integrated with RE (Paech & Kohler, 2003). In addition it increases thenumber of stakeholders involved. For example, in the case of telematics many driversinteract with a central authority. For such systems, detailed analysis of the systemcontext and the stakeholders — as typical for collaborative embedded systems — needto be emphasized.

Acknowledgments

We thank our project partners at Fraunhofer FIRST and colleagues at DaimlerChryslerfor fruitful discussions. This approach was developed in the QUASAR project supportedby the BMBF under the label VFG0004A.



References

Alexander, I., & Robertson, S. (2004). Understanding project sociology by modelingstakeholders. IEEE Software, (January/February), 23-27.

Basili, V. R., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sorumgard, S., & Zelkowitz,M. (1996). The empirical investigation of perspective-based reading. EmpiricalSoftware Engineering, 1, 133–164.

Cockburn, A. (2001). Writing effective use cases. Addison Wesley.Constantine, L.L., & Lockwood, L.A.D. (2001). Structure and style in use cases for user

interface design. In M. van Harmelen (Eds.), Object-oriented user interface design(pp.1-27). Addison-Wesley.

Cook, J.R., & Salvendy, G. (1999). Job enrichment and mental workload in computer-based work: Implications for adaptive job design. International Journal of Indus-trial Ergonomics, 24(1), 13-23.

Denger, C., & Ciolkowski, M. (2003). High quality statecharts through tailored perspec-tive-based inspections. Proceedings of EuroMicro Conference (316-323).

Denger, C., Kerkow, D., von Knethen, A.,& Paech, B. (2003a). A comprehensiveapproach for creating high-quality requirements and specifications in automotiveprojects. Proceedings of International Conference on systems and softwareengineering and application.

Denger, C., Paech, B., & Benz, S. (2003b). Guidelines – Creating use cases for embeddedsystems (IESE-Report 033.03). Kaiserslautern, Germany: Fraunhofer Institute forExperimental Software Engineering.

Dutoit, A.H., & Paech, B. (2001). Rationale management in software engineering. In S.K.Chang (Eds.), Handbook of software engineering and knowledge engineering(787-815). World Scientific.

Freimut, B., & Denger, D. (2003). A defect classification scheme for the inspection ofQUASAR requirement documents (IESE report 076.03). Kaiserslautern, Germany:Fraunhofer Institute for Experimental Software Engineering.

Glinz, M. (2002). Statecharts for requirements specification – As simple as possible, asrich as needed. Proceedings of ICSE-Workshop on Scenarios and State MachineModels, Algorithms and Tools.

Grimm, K. (2003). Software technology in an automotive company – Major challenges.Proceedings of Int. Conference On Software Engineering, IEEE, 498-503.

Harel, D.,& Politi, M. (1998). Modeling reactive systems with statecharts: The statemateapproach. McGraw Hill.

Heitmeyer, C., & Bharadwaj, B. (2000). Applying the SCR requirements method to the lightcontrol case study. Journal of Universal Computer Science (JUCS), August, 650-679.

Houdek, F., & Paech, B. (2002). Das Türsteuergerät. Eine Beispielspezifikation (IESE-Report 002.02/D (in german)). Kaiserslautern, Germany: Fraunhofer Institute forExperimental Software Engineering.



IEEE Recommended Practice for Software Requirements Specification. (1998). Standard830-1998.

Kamsties, E., von Knethen, A., & Paech, B. (2001). Structure of QUASAR requirementsdocuments (IESE-Report 073.01). Kaiserslautern, Germany: Fraunhofer Institutefor Experimental Software Engineering.

Kamsties, E., von Knethen, A., & Reussner, R. (2003). A controlled experiment to evaluatehow styles affect the understandability of requirements specifications. Informa-tion and Software Technology, 45(14), 955-965.

Laitenberger, O. (2000). Cost effective detection of software defects through perspective-based inspections. (PhD Theses in Experimental Software Engineering, FraunhoferIRB Verlag).

Paech, B., & Denger, C. (2004). An integrated quality assurance approach for use casebased requirements. Modellierung 2004, Lecture notes in Informatics (45), 59-74.

Paech, B., & Kohler, K. (2003). Usability engineering integrated with RE. Proceedings ofICSE-Workshop Bridging the gap between HCI and SWE.

Parnas, D.L., & Madey, J. (1995). Functional documents for computer systems. Scienceof Computer Programming, 25, 41-61.

Peters, T.J., & Peters, T. (1999). The project 50 (reinventing work): Fifty ways totransform every “task” into a project that matters. Knopf.

Ramesh, B., & Jarke, M. (2001). Towards reference models for requirements traceability,IEEE Transactions on Software Engineering, 27(1), 58-93.

Requisitepro. Retrieved on November 11, 2004 from http://www.rational.com/products/reqpro/index.jsp.

Rhapsody. Retrieved on November 12, 2004 from http://www.ilogix.com/products/rhapsody/index.cfm.

Sommerville, I., & Sawyer, P. (1997). Requirements engineering – A good practice guide.Addison-Wesley.

Sutcliff, A., & Minocha, S. (1998). Analysing sociotechnical system requirements.CREWS_Report 98-37.

Telelogic. Retrieved on November 12, 2004 from http://www.telelogic.com.Thompson, J.M., & Heimdahl, M.P.E., & Miller, S.P. (1999). Specification-based prototyping

for embedded systems. ESEC/FSE, 163-179.von Knethen, A. (2001a). A trace model for system requirements changes on embedded

systems. Proceedings of IWPSE’01 (17-26).von Knethen, A. (2001b). Change-oriented requirements traceability. support for evo-

lution of embedded systems. (PhD Theses in Experimental Software Engineering,Fraunhofer IRB Verlag).

von Knethen, A., & Grund, M. (2003). QuaTrace: A tool environment for (semi-) automaticimpact analysis based on traces. Proceedings of Int Conf. on Software Mainte-nance, ICSM (246-255).

170 Grützner and Paech


Chapter XI


CoursewareDevelopment

Ines Grützner,Fraunhofer Institute for Experimental Software Engineering, Germany


Abstract

Technology-enabled learning using the Web and the computer and courseware, inparticular, is becoming more and more important as an addition, extension, orreplacement of traditional further education measures. This chapter introduces thechallenges and possible solutions for requirements engineering (RE) in coursewaredevelopment projects. First the state-of-the-art in courseware requirements engineeringis analyzed and confronted with the most important challenges. Then the IntViewmethodology is described as one solution for these challenges. The main features ofIntView RE are: support of all roles from all views on courseware RE; focus on theaudience supported by active involvement of audience representatives in all activities;comprehensive analysis of the sociotechnical environment of the audience and thecourseware as well as of the courseware learning context; coverage of all software REactivities; and development of an explicit requirements specification documentation.

Requirements Engineering for Courseware Development 171


Courseware: A Typical SociotechnicalSystem

Continuing professional education and life-long learning are both vital in order tomaximize competitiveness, introduce innovative technologies, and prepare for newchallenges in all branches of industries. Traditional strategies for education and trainingsuch as seminars are not able to fulfill the growing demand for further education in atopical and efficient way. Therefore technology-enabled learning using the Web and thecomputer and courseware, in particular, is becoming more and more important as anextension or a replacement of traditional further education (Levis 2002; Ochs & Pfahl,2002). We denote as courseware any instructional system delivering content or assign-ments via computers in order to support learners as well as teachers in technical andinstructional ways. In other words, from the users’ point of view, courseware may be seenas educational material (content and instructional guidelines) that is distributed via theWeb for training purposes. From the developers’ point of view, courseware can beperceived as a collection of multimedia documents interrelated by means of (perhapsrestricting) navigational structures, which is supplemented with community functionalities.Courseware is usually not developed by software companies but by content experts suchas publishing companies, universities, or companies that want to use the courseware fortheir internal further education. This is mainly due to the fact that courseware is perceivedas an instructional product, although it is definitely software. Courseware is a specialkind of software, adding an instructional dimension to the content, functional, non-functional, and user interface dimensions of traditional software. Its main goal is tosupport the learners in achieving their learning objectives in an effective and efficientway. The software and user interface features of courseware are essential in achievingthis goal but also have to fit into and support the overall instructional strategy of thecourseware. Furthermore courseware is very often integrated into a larger educationalprogram (that is, a curriculum). The courseware is used to achieve only a few of thelearning objectives of the program. The other objectives are achieved by seminars, talks,workshops, virtual communities, and so forth.Thus, courseware is one particularly complex example for a sociotechnical system thatrequires equal support for user needs and technological innovations. Requirementsengineering processes for such systems typically build on a user- and usage-centeredprocess (for example, Constantine & Lockwood, 1999). They start from task and userprofiles and gradually develop an understanding of the domain, of the technologicaloptions, and of the interactions between users and software (for example, the TOREapproach (Paech & Kohler, 2003)). The challenge for courseware development is that inaddition to the procurers, users, domain experts, and software developers, there are alsoinstructional experts as stakeholders. Thus, two levels of tasks have to be reflected: onthe one hand the learning task (interest of the instructional experts) and on the otherhand the working task, whose performance should be supported through the course(interest of the procurers, users, and domain experts). Both influence the functionality,quality, content, and presentation of the courseware. In addition they are embodied inan instructional strategy that drives the courseware.



The working tasks of the learners define which knowledge, skills, and attitudes have tobe taught in the courseware in order to enable the learners to perform these taskssuccessfully. Following a taxonomy adapted from Gagné, Briggs, & Wager (1992), thismeans that:

• Knowledge includes both declarative and procedural knowledge.• Skills demonstrate that the learners are able to perform a learning task or a working

task.• Attitudes amplify positive or negative reactions toward objects, persons, or

events/situations.

The learning tasks define how the knowledge, skills, and attitudes have to be taught inorder to enable effective and efficient learning in the sociotechnical environment of thelearners and the courseware. The sociotechnical environment consists of the placeswhere the learners learn during an educational program or work with a courseware, as wellas of the technical equipment and the environmental situation in which learning takesplace.The fact that courseware RE has to support two different types of tasks increases itscomplexity. For example, it requires the introduction of requirements elicitation andquality assurance methods from pedagogy and instructional design. Traditional soft-ware requirements elicitation and quality assurance methods like prototyping can onlybe applied to elicit or assure information regarding the learning tasks. However theycannot be used to elicit and assure that all required knowledge, skills, and attitudes aretaught and that they are taught efficiently in the specified environment and learningcontext. Therefore instructional elicitation and quality assurance methods, and evalu-ations used to measure the impact on and the gains for the audience (Reinmann-Rothmeier, Mandl, & Prenzel, 1994), have to be applied additionally in courseware RE.In the following, we focus on elicitation, analysis, and documentation of requirementsbut omit requirements management. For the latter traditional RE techniques like traceabil-ity can be used. In the next section we discuss the state-of the-art and -practice of REfor courseware development. We also introduce important terminology and identify themain challenges for courseware RE. In order to illustrate the challenges and possiblesolutions, we present how the IntView process developed at Fraunhofer IESE addressesthese challenges. We close with a short summary, lessons learned from the applicationof IntView, and a discussion of future research.



State-of-the-Art of RequirementsEngineering for CoursewareDevelopment

As of today, many approaches for courseware development have been published.However these approaches have several shortcomings regarding RE. To identify theseshortcomings we have analyzed more than 30 courseware development approachespublished in books, journals, or on Web sites, and their RE activities. Summarizing theresults of this literature review, we have identified the following five challengescourseware RE has to deal with:

1. Equal support of all stakeholder viewsTaking care of two different kinds of tasks increases not only the complexity butalso the number of roles involved in courseware RE. All roles involved can beclustered into the following four stakeholder views:• The content-instructional view dealing mainly with the content and the

instructional design of courseware, for example, Hannafin & Peck (1988), Lee& Owens (2000);

• The technical-graphical view dealing mainly with user interface design andthe technical implementation of courseware, for example, Hall (1997),McCormack & Jones (1998), Weidauer (1999);

• The managerial view dealing mainly with project management aspects, forexample, Bruns & Gajewski (1999), Schanda (1995); and

• The usage-oriented view dealing with the task aspects.2. Comprehensive RE dealing with both learning and working tasks

This challenge has to be split into two interdependent parts. First coursewaredevelopment has to support all RE activities. The categories for classifying theapproaches in the review regarding this challenge are:• Comprehensive RE including all RE activities,• Partial RE including some RE activities, and• No RE.Second courseware RE has to deal with both working and learning tasks. Thecategories for classifying the approaches in the review regarding this challenge are:• Both tasks,• Learning tasks only, and• Working tasks only.

3. Real user- and learning objective-centered RERepresentatives of the potential audience have to participate actively in the REactivities in order to enable the planned courseware to achieve its goal, namely the



support of the learners in achieving their learning objectives in an effective andefficient way.

4. Gradual development of an understanding of the domain, of the technologicaloptions, and of the sociotechnical environmentAttaining this understanding is very important, since the learning tasks of theeducational program and, eventually, its courseware have to be designed inaccordance with the sociotechnical environment in order to guarantee learningsuccess. The presence of a specific learning task, which was a major success factorof one educational program or courseware, does not result in learning successwhen applied in a new sociotechnical environment. To make matters worse, itspresence could even be counter-productive (for example, to work through anima-tions with spoken explanations works well when learners work in a single-personoffice but not in an open-plan office). For the literature review we distinguishbetween the following three options:• Comprehensive,• Partial, or• No incrementality.

5. Development of a comprehensive, explicit requirements specification documenta-tionA comprehensive, explicit requirements specification documentation is an impor-tant prerequisite for complete processing of the analysis results and, therefore, fora common understanding of the courseware requirements as a basis for the design.Of course common understanding could also be reached by intensive communica-tion among representatives of the roles. However, in courseware RE, there are moredifferent roles involved than in RE for “traditional” software. Furthermore theseroles speak very different languages. Therefore it is almost impossible to achievea common understanding only by communication. In addition, if there is norequirements specification documentation, the decisions made on the basis of theanalysis results will not be documented. Then it is almost impossible to change thecourseware when new requirements arise or the sociotechnical environmentchanges.The categories of documentation identified in the literature review are:• Specification required,• Documentation of the results of the requirements activities, and• No documentation required.Table 1 provides an overview of how current courseware development approachesas well as the IntView RE methodology meet the challenges identified. This enablesa comparison of the IntView courseware RE solutions to current state-of-the-art.



Table 1. Overview of typical courseware development approaches and of IntView

App

roac

h Ch

allen

ge

Han

nafin

&

Peck

, 198

8 Le

e & O

wens

, 20

00

McC

orm

ack

&

Jone

s, 19

98

Hall

, 199

7 W

eidau

er,

1999

Sc

hand

a, 19

95

Brun

s &

Gaje

wski

, 19

99

IntV

iew

1 M

ainly

Con

tent-

instr

uctio

nal

view

Main

ly C

onten

t-in

struc

tiona

l vi

ew

Main

ly

Tech

nica

l-gr

aphi

cal v

iew

Main

ly

Tech

nica

l-gr

aphi

cal v

iew

Main

ly

Tech

nica

l-gr

aphi

cal v

iew

Main

ly

Man

ager

ial

view

Main

ly

Man

ager

ial

view

Supp

ort o

f all

roles

from

all v

iews

on co

urse

war

e RE

2 Pa

rtial

RE

deal

ing

with

bo

th ta

sks

Parti

al RE

de

alin

g wi

th b

oth

task

s

Parti

al RE

de

alin

g w

ith

lear

ning

task

s on

ly

Parti

al RE

de

alin

g wi

th

lear

ning

task

s on

ly

Com

preh

en-

sive R

E de

alin

g wi

th

lear

ning

task

s on

ly

No

RE

Parti

al RE

de

alin

g wi

th

lear

ning

task

s on

ly

Cove

rs al

l sof

twar

e RE

activ

ities

A

s und

erly

ing

softw

are R

E ap

proa

ch, t

he ta

sk-d

riven

RE

appr

oach

(TO

RE) b

y Pa

ech

&

Koh

ler (

2003

) was

chos

en.

3 N

o N

o N

o N

o N

o N

o N

o Fo

cus o

n th

e aud

ience

supp

orted

by

activ

e inv

olve

men

t of a

udien

ce

repr

esen

tativ

es in

all a

ctiv

ities

4

Parti

al an

alysis

Pa

rtial

analy

sis

Parti

al an

alysis

Pa

rtial

anal

ysis

Parti

al an

alysis

No

anal

ysis

Parti

al an

alysis

Co

mpr

ehen

sive a

naly

sis o

f the

so

cio-te

chni

cal e

nviro

nmen

t of t

he

audi

ence

and

the c

ourse

war

e as

well

as o

f the

cour

sew

are l

earn

ing

cont

ext

5 D

ocum

entat

ion

of th

e res

ults

of

the r

equi

rem

ents

activ

ities

Doc

umen

tatio

n of

the r

esul

ts of

th

e req

uire

men

ts ac

tiviti

es

No

docu

men

tatio

n re

quire

d

Doc

umen

tatio

n of

the r

esul

ts of

th

e req

uire

men

ts ac

tiviti

es

Expl

icit

requ

irem

ents

spec

ifica

tion

No

docu

men

tatio

n re

quire

d

No

docu

men

tatio

n re

quire

d (D

evel

opm

ent

of a

spec

ifica

tion

optio

nal)

Dev

elopm

ent o

f an

expl

icit

requ

irem

ents

spec

ifica

tion

docu

men

tatio

n



Courseware Requirements Engineeringwith the IntView Methodology

The IntView courseware engineering methodology was developed by Fraunhofer IESEin order to address the challenges identified in the previous section. As a comprehensivedevelopment methodology, IntView integrates all of the important views of high-qualitycourseware development.IntViews integrates best practices of courseware development approaches with softwareengineering approaches (for example, Endres & Rombach, 2003; Kruchten, 1998) in orderto meet the challenges identified in the previous section. For example, the lifecycle-encompassing quality assurance methodology is adapted from software engineering. Ona high abstract level the resulting IntView courseware methodology can be described asa V-Model-like, product-centered life-cycle model (Grützner, Pfahl, & Ruhe, 2002).The RE activities are part of the second IntView phase, which produces the coursewarerequirements specification. The courseware requirements specification, which refinesthe problem statement, consists of several dependent elements. In addition the projectteam and the plans for both the RE activities and the whole courseware development areestablished in order to perform IntView RE successfully. An overview of the productsof the IntView RE activities is given in Figure 1. The elements of the requirementsspecification follow the TORE approach (Paech & Kohler, 2003). The task level servesto identify the user roles and their tasks. On the domain level the tasks are analyzed todetermine the to-be-activities and data of the user roles and the support of the software.The support is detailed on the interaction level by devising a logical user interfacestructure, use cases, interaction data, and system functions. On the system level, thearchitecture and internal details of the functions are specified.

Figure 1. The products of the IntView RE activities and their dependencies

Courseware requirements specification

Task level: Analysis resultsTask level:

Analysis results

Interaction level: Interaction specification


Requirements engineeringproject team


System level: Courseware architecture


Requirements engineeringplans


Courseware developmentplans


Test casesTest cases

Domain level: Instructional specification


Courseware developmentproject team


Courseware requirements specification

Task level: Analysis resultsTask level:

Analysis results











Test casesTest cases







The products are explained in the following subsections. To illustrate the products, weuse examples from a courseware development project we have performed at FraunhoferIESE. The goal of this project was to develop courseware that teaches how to developtechnical documentation. The project is performed together with a local educationorganization acting as the customer. The customer also provides working task expertsthat are, in addition, the subject matter experts in the project team. Furthermore partici-pants of a current further education program in the field of technical documentation runby this education organization participated in the project as audience representatives.The courseware is to be used in programs that the education organization will organizefor the further education of professionals as well as for unemployed people.

RE and Courseware Project Structure and Plans

First the plans (that is, a project plan, a quality assurance plan, and a risk managementplan) and the project team for the RE activities have to be established.The project team consists of people representing roles from the four views, for example:

• Project manager and quality manager as managerial roles;• Subject matter expert, instructional courseware designer, courseware author and

editor, teachers/tutors, and human factors expert as content and instructionalroles;

• Graphic designer and artist, multimedia developer, programmer, and coursewareprogrammer as technical and graphical roles; and

• Members of the potential audience, representatives of the customer (for instance,the responsible project manager from the customer or a steering manager), andworking task experts as roles representing the usage-oriented view.

The roles representing the usage-oriented view participate in the project team in orderto involve the audience actively in the RE and to assure strict learner orientation. Similarlythese roles ensure that all the required knowledge, skills, and attitudes are taught andthat the sociotechnical environment of the learners and the courseware is specifiedcorrectly.These plans have to be consolidated at the end of the courseware RE, because therequirements and the architecture of the courseware have a great impact on thedevelopment process and the structure of the project team.

Analysis Results

In order to take the strong learner orientation into account, IntView RE starts with ananalysis of the audience and its educational needs. The main goals of these analyses areto learn more about the potential learners and their learning and working tasks, as well



as to specify the knowledge, skills, and attitudes required to perform the working taskssuccessfully. The results of both intertwined analyses are documented in an analysisresults documentation consisting of the elements depicted in Figure 2.The focus of the audience analysis and the resulting audience characterization is on thelearning tasks on the task level. In detail the audience characterization provides insightsinto the characteristics of the potential learners and into their prerequisites for perform-ing learning tasks, especially for performing learning tasks with new educational media.One of the most important characteristics is the expectation of the audience regardingthe educational program, since this reveals a lot about the hopes and fears of theaudience, which should, in turn, be dealt with in the following specifications (realizehopes, remove fears).Table 2 shows a section of the audience characterization from the example project. Theseaudience characteristics are elicited with questionnaires or in interviews from bothpotential learners and customer representatives.The educational needs analysis and its resulting documentation provide a detailedoverview of the working tasks of the audience. It starts with the definition and, ifnecessary, the refinement of all working tasks that should be supported by the educa-tional program (see Table 3).In the next step, those knowledge, skills, and attitudes are specified that are required forperforming each of the defined working tasks successfully from the working task expertpoint of view. They are collected in the required educational profile (see Table 4). Thisrequired educational profile represents the objective educational need of the potentiallearners.

Figure 2. The elements of the analysis results documentation and their dependencies

Analysis results documentation

Working task definitionWorking task definition

Target educational profileTarget educational profile

Audience characterizationAudience characterization

Educational needsEducational needs

Requested educationalprofile


As-is educational profileAs-is educational profile

Required educationalprofile


Related to the audience Related to the educational needs

Analysis results documentation

Working task definitionWorking task definition

Target educational profileTarget educational profile

Audience characterizationAudience characterization

Educational needsEducational needs



As-is educational profileAs-is educational profile



Related to the audience Related to the educational needs



Potential sources for eliciting this profile are the representatives of the customer and ofthe working task experts, written job descriptions, or artifacts used, modified, ordeveloped during the working tasks. Example methods for elicitation are: observationsof experts while performing the working tasks (especially for elicitation of required skills);interviews or other kinds of questionings of customer and working task experts (espe-cially for elicitation of knowledge and attitudes); or analysis of documents (especiallyfor elicitation of knowledge and skills).The required educational profile has to be supplemented by the subjective educationalneeds of the audience, that is, by the set of knowledge, skills, and attitudes the learnersthink they have to possess in order to perform their working tasks (requested educationalprofile, see Table 5). This is a measure of active learner participation in the RE. Theexample shows that the potential learners raise additional educational needs.Potential sources for eliciting this profile are the representatives of the potentialaudience, who are interviewed or asked to fill in questionnaires. Therefore it is a goodchoice to do this elicitation together with the audience analysis.Together with the requested educational profile, the “as-is” educational profile of thepotential learners is elicited, which represents the set of knowledge, skills, and attitudesthat the learners have already acquired (see Table 6).The target educational profile is specified by merging the required and the requestededucational profile in one table. If there are opposing required and requested needs, the

Table 2. Audience characterization in the area “Technical documentation”

Table 3. Section of the working task definition from the area “Technical documentation”

Working task 1 Evaluation of software to be documented Refined working tasks (optional)

1.1 Evaluation of software functions, processes, and structures 1.2 Evaluation of the graphical user interface 1.3 Evaluation of the terminology used in the software

Target group: Participants of further education measures Demographical data

• Mix of male and female learners (15 up to 20 in each measure) • Age: 25 – 55 • Mainly university graduates from all fields / but also college dropouts (!!) or persons

with good writing skills • …

Motivation • Career opportunities (intrinsic) • Professional reorientation because of unemployment (intrinsic/extrinsic) • …

Professional experiences

• Almost no knowledge or experiences in writing technical documentations

Learning experience

• Experiences with traditional education from school and university • Experiences with self-directed learning from university • …

Computer and Internet skills

• Good command of word processors • Rudimentary Internet skills (know how to surf the net and how to write e-mails) • …

Expectations • A good interactive multimedia presentation that has an added value compared to books • …



Table 4. Section of required educational profile from the area “Technicaldocumentation”

Table 5. Section of the requested educational profile from the area “Technicaldocumentation”

Table 6. Section of the “as-is” educational profile from the area “Technicaldocumentation”

Table 7. Section of the educational needs from the area “Technical documentation”with the marked needs (underlined) that have to be taught

Refined working task “1.1 Evaluation of software functions, processes, and structures” Knowledge

Required • Procedures to run the evaluation • Scenarios when to use which procedure • Structure of bug reports • Structure of terminology lists

Skills Required • Analytical skills • …

Attitudes Required • “Communication is helpful” • …

Refined task “1.1 Evaluation of software functions, processes, and structures” Knowledge Requested • Problems from practice and their solution Skills Requested • Applying a systematic methodology to evaluate software Attitudes Requested • None

Refined task “1.1 Evaluation of software functions, processes, and structures” Knowledge “As-is” • Some procedures to run the evaluation

• Structure of bug reports Skills “As-is” • Analytical skills

• Applying a systematic methodology in general Attitudes “As-is” • None

Refined task “1.1 Evaluation of software functions, processes, and structures” Knowledge • Additional procedures to run the evaluation

• Scenarios when to use which procedure • Structure of terminology lists • Problems from practice and their solution

Skills • Applying systematic methodologies, especially in software evaluations • …

Attitudes • “Communication is helpful” • …



conflict has to be solved by negotiations between the working task experts and therepresentatives of the audience. Then it is compared to the “as-is” educational profile.The result of this gap analysis is the set of knowledge, skills, and attitudes that shouldbe taught by the educational program (the educational need, see Table 7). Typically theeducational program cannot teach all of them because of time restrictions. Therefore aselection has to be made (underlined elements).The analysis result documentation is verified by a perspective-based inspection(Laitenberger & DeBaud, 2000). Besides providing the proof of completeness andcorrectness of the elicited information, the main goal of this inspection is informationdissemination among all team members.

Instructional Specification

The decisions dealt with during the instructional specification are part of the domainlevel. Their goal is to specify the sociotechnical environment of the educational programand its courseware as well as the rough design of the educational program itself in acomprehensive way. The results will be documented in the elements of the instructionalspecification, which are shown in Figure 3.The instructional specification contains the rough design of the learning tasks.First the social part of the courseware is specified, which defines the constraints for thedefinition of the technical part of the courseware, including the development of theinteraction specification documentation.

Figure 3. The elements of the instructional specification and their dependencies

Instructional specification

Instructional strategyInstructional strategyMain learning objectiveMain learning objective

Subjects to be taughtSubjects to be taught

Description of socio-technical environmentDescription of socio-technical environment

Definition of phases

Specification of phases

Definition of learning places

Description of learning places













Definition of learning places

Description of learning places



The first result of the instructional specification activities is the main learning objectiveof the educational program. This specifies the main results the learner has to achieve ina testable way (Wambsganß, Eckert, Latzina & Schulz, 1997). Taxonomies that can beapplied in specifying learning objectives are presented in Engelhart, Bloom, & Krathwohl(1971) and Krathwohl, Bloom, & Masia (1971) as well as in Gagné et al., (1992). In Table8 an adaptation of the latter taxonomy is applied to the educational needs defined in Table7. However the main learning objective of an educational program does not deal withlearning objectives on the level of detail presented in Table 8, but subsumes all of themin one single goal on a much more general level. As an example the main learning objectiveof the educational program in the area of technical documentation is, “The learners areable to write high-quality technical software documentations on their own in a user-oriented, systematic way.”The following specification of the educational program content refines the educationalneeds to be satisfied in compliance with the main learning objective of the educationalprogram (see Table 9).Besides the specification of the content of the educational program, the sociotechnicalenvironment of the educational program is analyzed in detail. The goal of this analysisis to identify constraints that the sociotechnical environment imposes on the program.Therefore the analysis identifies the places where the potential learners will learn duringtheir participation in the educational program and describes the technical equipment atthese places, the motivation of the learners to learn at these places, and the environmentalsituation at the places while the learners are learning (see Table 10).

Table 8. Learning objectives in the area “Technical documentation”

Table 9. Section of the educational program content in the area “Technicaldocumentation”

Declarative The learners can state the structure of a terminology list. …

Knowledge

Procedural The learners know all of the suitable procedures to perform a software evaluation.

Working task The learners are able to apply systematic methodologies in a software evaluation on their own.

Skills

Learning task The learners use the button “Additional information” to get more detailed information on a topic.

Attitudes - The learners choose to communicate with other technical writers when writing their documentation.

Refined task “1.1 Evaluation of software functions, processes, and structures” Knowledge • Additional procedures to run the evaluation

• What are alternative procedures to evaluate software (in addition to the already known procedures)?

• What steps are to be followed when applying them? • Which procedure should be applied in which context? • …



Table 10. Section of the sociotechnical environment description for the area “Technicaldocumentation”

Table 11. Section of the instructional strategy in the area “Technical documentation”

Learning place 1: Computer classroom Technical equipment

PC with • Pentium II 333MHz • 256 MB RAM • …

Environmental situation

• Learners will sit next to each other in one room without any partition. • Open for learning during the office hours, but learning mainly takes place during the

lessons • Timetable for the lessons: • Possible factors of disturbance

~ Chatting neighbors ~ …

• Goals of learning ~ Acquisition of new knowledge and skills ~ Training of new skills ~ ...

• Kinds of learning ~ Following pre-defined learning paths (learning step-by-step) ~ Looking up information ~ …

Motivation for learning (Why do the learners learn at this place?)

• Scheduled lessons • Performing learning tasks upon request by the teacher/tutor • Information acquisition while performing working tasks that have to be performed upon

request by the teacher/tutor Learning place 2: workplace … • …

Phase 1 of the educational program: Learning and Training I Learning place Computer classroom Learning objective

The learners know how to evaluate software to be documented. …

Content Procedure to perform an evaluation and the context for their application …

Teaching methods

• Traditional instruction with its different methods and with courseware as special learning material

• Courseware for explorative, self-directed, step-by-step learning of knowledge (guided tour required) ~ …

Duration 2 months Learner support concept

Face-to-face support by teachers/tutors who are present in the computer classroom

Communication concept

Face-to-face communication between teachers/tutors and learners as well as between learners

Collaboration concept

Not required

Phase 2 of the educational program: Project I … …



The instructional strategy combines these inputs and specifies how the performance ofthe learning tasks will be supported by the program and its courseware (see Table 11).The instructional specification is also verified by a perspective-based inspection.Besides providing the proof of completeness and correctness of the documentation, thegoal of this verification is to reach a broad consensus among the project team members,especially the representatives of the customer and those of the working task experts, forthe specification and to get their final commitment that the instructional specification isfeasible (that is, this verification establishes a consolidated basis for the followingspecification of the requirements).

Interaction Specification

Starting with the interaction specification, IntView RE only deals with the coursewarethat is part of the educational program. Functional and non-functional requirementsspecify which courseware functionalities and characteristics are required in order toenable efficient performance of the learning tasks specified in the instructional specifi-cation. Experience from projects shows that this is more efficient when one or twoexperienced team members develop an initial draft of this specification. This initial draftshould later on be discussed and consolidated in the team.The courseware interaction specification mainly deals with the learning tasks as theywere specified in the instructional specification. The functional requirements specify, forexample, navigational functionalities, functionalities for orientation in the coursewarespace, and functionalities for support of cooperation and collaboration, including arough dialog and user interface design. As representation IntView proposes the use ofa structured, clearly written natural language complemented with use cases and flowcharts.Besides the functional requirements, well-known non-functional requirements fields likeperformance and usability have to be covered. In addition, these well-known require-ments fields have to be extended by courseware-specific fields such as:

• Data requirements, which are mainly requirements regarding the content of thecourseware (for example, the topics that have to be covered by the courseware andcharacteristics of these topics, that is, completeness, up-to-date-ness, and consis-tency);

• Data requirements, which specify how the content has to be modularized andorganized (for example, the number of modules to be developed, the maximum onlinelearning time a module is allowed to comprise, or sequences of content that haveto be realized in the courseware);

• Implementation requirements, which deal with restrictions of the media usage in thecourseware and of the parameters of the media types (for example, audio sequencesare not allowed because the audience will learn in open-plan offices); and



• Instructional requirements, which refine the instructional specification (for ex-ample, writing, language, and presentation styles, usage of examples, as well asexercises and their feedback mechanisms).

Table 12 presents example requirements for each of these requirements categories as wellas for each of the functional requirements.The methods for verifying the courseware requirements are inspections or reviews as wellas prototyping. The goal, aside from assuring the quality of the requirements, is to gainthe commitment of every project team member that he/she agrees with the requirements.In addition the specification of acceptance test and system test cases is used as a qualityassurance measure. However these test cases cannot cover all elements of the coursewarethat have to be validated in the tests because there are non-testable items, for example,media parameters. Therefore a checklist for such non-testable items has to be developed,which is applied together with the test cases.

Table 12. Section of the interaction specification for the courseware in the area“Technical documentation”

Functional requirements F 1 Step-by-step forward guidance of the learner through all pages of the courseware (guided tour

forward) … … F A Provide a message board enabling teachers/tutors to make asynchronous announcements … … Data requirements NF 1 Topics to be covered by the courseware

1) Evaluation of the software to be documented 2) …

NF 2 Structure of the courseware to be followed 1) Knowledge presentation 2) Exercises to test how much of the knowledge has been learned 3) …

… … Data requirements NF X Number of modules to be developed: 13 NF X+1 Maximum length of a module: 30 minutes without exercises … … Implementation requirements NF Y Use of audio sequences only if there is no other way to teach a topic NF Y+1 If audio sequences have to be used, they have to be supplemented by a written version of the

spoken text in order to allow to switch off audio. … … Instructional requirements NF Z Use of a gender-independent writing and visualization style NF Z+1 Use of a single example with a practical background in all modules … …



Courseware Architecture

The decisions made during the architecture specification are part of the system-leveldecisions. The goal of the courseware architecture specification activity is the specifi-cation of how the courseware interacts with components required to run thecourseware.Examples of such components are a learning management system (LMS), or, if no LMSis used, a user management component, a chat system, and a content managementsystem. It also supports the selection of suitable hardware to run the courseware. Thearchitecture documentation contains a specification of the architecture components(hardware and software), the functionalities they provide or support, and their interfaces.It is verified by an inspection or a review in order to assure that the architecture can beimplemented and that it is able to fulfill the functional as well as the non-functionalrequirements in an efficient way.

Conclusions, Experiences, and FutureResearch

This chapter introduced the IntView courseware RE activities. These systematic activi-ties are designed to meet the challenges of courseware RE.IntView courseware RE activities have been applied in several projects. Experienceshows that the methodology fulfills its promises and facilitates fast, efficient RE forcourseware. Findings from the projects show, for example:

• A good way to specify the educational program content is asking questions asshown in Table 9 that have to be answered in the educational program in order toachieve the overall learning objective. Doing it that way allows for verification ofthe content later on in the development project because it can be verified whetherall questions have been answered or not.

• A good way to develop the instructional specification is a workshop with allmembers of the project team. During such a workshop the team members candiscuss their viewpoints face to face and decide on a joint instructional specifica-tion instead of doing this in a time-consuming and often-drawn-out off-lineprocess.

• The discussion and verification of the different elements of the coursewarerequirements specification leads to a stable requirements specification. In additionit creates a broad consensus in the project team, which is an important prerequisitefor an efficient design phase.

IntView RE will be applied and improved in future projects. In addition it will be adaptedto meet challenges arising from new approaches to courseware development like thesemi-automatical, on-demand assembly of courseware from already existing courseware



fragments. For example the RE activities have to be performed much faster and moreefficiently to create courseware just in time. In addition, the requirements specificationhas to be made by a single person, that is, by the person who will create the coursewareby applying a tool. Unfortunately, in most cases, this person will not be able to fill all theroles of courseware RE. Therefore requirements scenarios have to be specified inadvance by a project team. While running the semi-automatic assembling system, theresponsible person can use these scenarios to establish the requirements for her/hiscourseware. IntView RE activities will have to be adapted in order to meet such newchallenges.

Acknowledgments

The development of the IntView lifecycle model and IntView RE was partly funded by the“e-Qualification Framework (e-QF)” project under grant 01AK908A of the GermanFederal Ministry of Education and Research (BMBF). The comprehensive example of andexperiences in applying the IntView RE are taken from the project “Entwicklung undErprobung modularisierter Lerneinheiten zum Profil ‚IT Technical Writer’” funded undergrant 01NM244A of the German Federal Ministry of Education and Research (BMBF).

References

Bruns, B., & Gajewski, P. (1999). Multimediales Lernen im Netz: Leitfaden für Entscheiderund Planer. Berlin, Heidelberg, New York: Springer (in German).

Constantine, L., & Lockwood, L. (1999). Software for use. Addison Wesley.Endres, A., & Rombach, H.D. (2003). A handbook of software and systems engineering:

Empirical observations, laws and theories. New York: Addison-Wesley.Engelhart, M.D., Bloom, B.S., & Krathwohl, D.R. (1971). Taxonomy of educational

objectives, vol. 1, “Cognitive domain,” 16th print. New York: MacKay.Gagné, R.M., Briggs, L.J., & Wager, W.W. (1992). Principles of instructional design (4th

ed.). New York: Holt, Rinehart and Winston.Grützner, I., Pfahl, D., & Ruhe, G. (2002, May). Systematic courseware development using

an integrated engineering style method. Proceedings of the World Congress“Networked Learning in a Global Environment: Challenges and Solutions forVirtual Education.”

Hall, B. (1997). Web-based training cookbook. New York: Wiley & Sons.Hannafin, M.J., & Peck, K.L. (1988). The design, development, and evaluation of

instructional software. New York: Macmillan.Krathwohl, D.R., Bloom, B.S., & Masia, B.B. (1971). Taxonomy of educational objectives,

vol. 2, “Affective domain,” (1st ed., reprint). New York: MacKay.



Kruchten, P. (1998). The rational unified process: An introduction. Reading, MA:Addison-Wesley.

Laitenberger, O., & DeBaud, J.M. (2000). An encompassing life-cycle centric survey ofsoftware inspection. Journal of Systems and Software, 50(1), 5-31.

Lee, W.W., & Owens, D.L. (2000). Multimedia-based instructional design: Computer-based training, Web-based training, distance broadcast training. San Francisco:Jossey-Bass/Pfeiffer.

Levis, K. (2002). The Business of (e)learning: A revolution in training and educationmarkets (Extract). Screen Digest. Retrieved July 11, 2003, from http://www.screendigest.com/content/R.E-LEARN_12_2002-more.html/view.

McCormack, C., & Jones, D. (1998). Building a Web-based education system. New York:Wiley & Sons.

Ochs, M., & Pfahl, D. (2002) eLearning market potential in the German IT sector: Anexplorative study. Kaiserslautern, Germany: Fraunhofer IESE. Retrieved November2, 2003, from http://www.iese.fhg.de/market_survey.

Paech, B., & Kohler, K. (2003). Task-driven requirements in object-oriented Develop-ment. In Leite, & J. Doorn (Eds.), Perspectives on RE. Kluwer Academic Publishers.

Reinmann-Rothmeier, G., Mandl, H., & Prenzel, M. (1994). ComputerunterstützteLernumgebungen: Planung, Gestaltung und Bewertung. Erlangen: Publicis-MCD-Verlag (in German).

Schanda, F. (1995). Computer-Lernprogramme: Wie damit gelernt wird; wie sie entwickeltwerden; was sie im Unternehmen leisten. Weinheim, Basel: Beltz. (In German)

Wambsganß, M., Eckert, S., Latzina, M., & Schulz, W. K. (1997). Planung vonWeiterbildung mit multimedialen Lernumgebungen. In H.F. Friedrich, G. Eigler, H.Mandl, W. Schnotz, F. Schott, & N.M. Seel, (Eds.), Multimediale Lernumgebungenin der betrieblichen Weiterbildung: Gestaltung, Lernstrategien undQualitätssicherung. Neuwied, Kriftel, Berlin: Luchterhand (in German).

Weidauer, C. (1999). Ein Vorgehensmodell für die industrielle Entwicklung multimedialerLehr- und Lernsysteme. Forschungsgruppe SofTec NRW. SoftwaretechnischeAnforderungen an multimediale Lehr- und Lernsysteme. Retrieved December 13,2000, from http://www.uvm.nrw.de/News/AktuellesFS (in German).

Collaborative Requirements Definition Processes 189


Chapter XII

CollaborativeRequirements

Definition Processesin Open Source

Software DevelopmentStefan Dietze,

Fraunhofer Institute for Software and Systems Engineering (ISST), Germany

Abstract

This chapter discusses typical collaborative requirements definition processes as theyare performed in open source software development (OSSD) projects. In the beginning,some important aspects of the entire OSSD approach are introduced in order to enablean understanding of the subsequent description of the feedback-based requirementsdefinition processes. Since the OSSD model seems to represent a successful way ofdealing with the significant distribution and heterogeneity of its actors, someopportunities to adapt this approach also in other (software) industries are discussed.Nevertheless the entire OSSD model still exhibits several improvement opportunitiesthat also are addressed in this chapter. In order to overcome possible weaknesses,several approaches to improve the described requirements definition approach areintroduced. These improvements help to assure a higher level of efficiency and qualityassurance for both processes and the developed artifacts, and furthermore also enablethe consideration and acceptance of this approach in other domains and industries.

190 Dietze


Introduction

Open Source Software (OSS) has reached a remarkably high popularity in many differentapplication domains throughout the last years. The success of famous OSS products likethe Linux Kernel or the Apache HTTPD Web Server leads to the suggestion that thedevelopment processes in general and especially the requirements definition processesare well suited to the demands of the users and the developers of OSS. Since theheterogeneous communities of established OSS projects typically consist of a largenumber of globally distributed actors who collaborate almost exclusively through theInternet, OSS projects should be perceived as complex sociotechnical systems. Whereastypical requirements engineering (RE) processes often are not designed to deal with anincreasing level of complexity, heterogeneity and distribution of their organizationalstructures (Herlea, 1998), the collaborative OSS development methodologies seem tohave overcome these issues. This suggests the hypothesis that the underlying OSSdevelopment model, which obviously has the ability to produce successful softwareproducts, should be considered as a reliable and viable approach in the areas of softwareengineering (SE) and of cooperative work in general.Despite the growing popularity of OSS, this new paradigm of software development hasnot been researched much yet in contrast to proprietary SE processes. Therefore thesepractices, including the deployed software support of the identified RE processes,should be analyzed in detail in order to determine whether the advantages of thesemethods can contribute to non-SW-related industries as well.This chapter outlines and interprets some results of a comparative case study of OSSdevelopment processes within the Apache HTTPD1, the Linux Kernel2, and the Mozillaproject3. These research activities were aimed at the identification and formalizedspecification of a descriptive process model for OSS development based on case studiesthat were performed by participating in the projects, analyzing the projects’ informationsources, doing interviews, and literature review. The research was focused on theprocesses, roles, artifacts, and the deployed software infrastructure, which is used tosupport the whole development approach and especially the requirements engineeringpractices presented in this chapter. The identification and formal presentation of adescriptive process model enable the further improvement of the identified processesand its software infrastructure, and furthermore open the opportunity to consider theintegration of these practices into traditional software development approaches.The following describes the results of this approach and focuses on the requirementsdefinition processes in typical OSS environments. Section two provides backgroundinformation about collaborative RE, and typical characteristics of OSS and OSS devel-opment (OSSD) processes, whereas the third section introduces some important aspectsof the identified OSSD process model. Section four focuses especially on the require-ments definition approach in OSS projects and section five discusses its adaptability toother industries, which is the basis for the description of possible improvement oppor-tunities in section six. Finally the core results of the chapter are summarized in sectionseven.



Background

This section provides a brief overview of collaborative requirements definition pro-cesses and the open source software domain.

Collaborative Requirements Definition

As Herbsleb & Kuwana (1998) state, the social and organizational environment is animportant factor for successful software development projects. In general the require-ments for software systems are constructed and negotiated in a complex, iterative, andco-operative requirements definition process (Loucopoulos & Karakostas, 1995). In-volving the users and all the stakeholders of a system early in the development processensures that the product can satisfy all involved actors. Therefore requirements defini-tion processes are typically performed by different stakeholders like users, customers,domain experts, project managers, and developers (Boehm, Grünbacher, & Briggs, 2001),who often have different perspectives and backgrounds (Mehandjiev, Gaskell, &Gardler, 2003). According to Herlea (1998) it is a considerable problem of RE processesthat the involved actors often work in globally distributed environments and overorganizational boundaries. Thus the requirements definition process can be perceivedas highly collaborative and interactive. Since an increasing number of projects in thesoftware industry and also in other businesses are performed in distributed andheterogeneous environments, these are characteristics of RE in general.This led to the development of different approaches to handle the increasing distributionof RE actors, for example, groupware-based methods (Boehm et al., 2001; Herlea, 1998)or the more comprehensive model in Mehandjiev et al. (2003). Since the OSS communityseems to have found a way to deal with its significantly high level of heterogeneity anddistribution, the analysis of the OSS approach for requirements definition could contrib-ute to the whole software development industry and perhaps other industries.

Open Source Software

An appropriate explanation of the open source term is provided by the Open SourceInitiative (OSI), which has developed the Open Source Definition (OSD). This definitioncontains a set of criteria that have to be considered in the software license models usedfor OSS in accordance with the OSD (Open Source Initiative, 2002):

• Free distribution and redistribution• Publicly available source code• Possibility of source code modification and redistribution• No discrimination of certain users/groups or employment domains

192 Dietze


All license models that follow the criteria defined in the OSD can be considered to becompatible to the understanding of OSS as defined by the OSI. In addition the OSIprovides a list of all certified software licenses (Open Source Initiative, 2003). Thesecharacteristics have significantly determined the evolution of the entire OSS develop-ment model and especially the requirements definition processes.

Open Source Software Development

Although many existing OSS projects have successfully developed individual practicesand specific processes, it is possible to define some common characteristics that can beidentified in most of the OSS development projects (Cubranic, 2002; Fogel & Bar, 2002;Gacek, Lawrie, & Arief, 2002; Scacchi, 2001; Vixie, 1999):

• Collaborative development• Globally distributed actors• Voluntariness of participation• High diversity of capabilities and qualifications of all actors• Interaction exclusively through web-based technologies• Individual development activities executed in parallel• Dynamic publication of new software releases• No central management authority• Truly independent, community-based peer review• “Bug driven” development

According to Raymond (2001) these characteristics lead to the metaphor of a “bazaar”that represents the characteristics of the OSS development practices in contrast to a“cathedral” representing the centralized and strictly controlled traditional softwaredevelopment.The OSS development processes are often characterized as “bug-driven.” This resultsfrom the typical practice that every software modification is based on a specific bugreport or more generally on a change request that represents the central requirementsartifact within the OSSD approach. This characteristic also clarifies the importance of therequirements definition processes within OSSD projects.

Identified OSSD Process Model

This section summarizes some of the key aspects of the process model, which wasidentified during the preliminary research activities.



Key Processes and Roles

The initial release of the OSS prototype can be perceived as the starting point of the OSSDprocess as a gradual process of software improvement. The OSS approach can be dividedin the following key processes:

• Management Processes• Environment Processes• Development Processes

Whereas the development processes describe the collaborative and highly distributedactivities to improve the source code and to develop all projects artifacts, particularlythe RE artifacts, the management and environment processes support the developmentactivities from a central position. These main development processes are executed inparallel and mainly independent from each other.Figure 1 represents these core process categories and the roles involved in this modelin an UML-based use case view:All collaborative development activities are performed by distributed actors who can beaggregated to the following roles:

• User• Contributor

Figure 1. Identified key processes and roles

194 Dietze


• Developer• Reviewer• Committer

These roles are not usually defined explicitly but describe a certain set of actors who fulfilla defined set of functions and tasks. A common set of characteristics can also be defined,for example, user privileges that all actors fulfilling a certain role are associated with.Usually an actor is associated with more than one role. For example, the development ofa source code as a developer implies the use of the OSS as a passive user, and thesubmission of patches makes a developer also become a contributor.

Maintainers and Core Developers

The maintenance processes for maintaining the infrastructure and to support andcoordinate all development activities are typically performed by a central maintainer ora maintenance committee. In fact the initiator of the project is in most cases the sameperson as the primary maintainer. The maintenance actors provide central services thatcannot be provided by distributed and global actors, for example, a common softwareinfrastructure that provides central access to all shared resources.In many OSS projects a group of core developers could be identified (Dietze, 2003). Theseactors are typically responsible for the majority of source code modifications and interactvery closely with the maintainer(s) of a project. Furthermore the core developers are oftenresponsible for activities that require enhanced qualifications, skills, privileges, orknowledge of the source code, for example, the commit of source code (Mockus, Fielding,& Herbsleb, 2000; Reis & Pontin de Mattos Fortes, 2002).

Overall Process Model

The overall process model at its highest level of abstraction is represented in Figure 2.The above figure contains the key processes of the OSSD process model and is presentedfor informal purposes in order to provide a brief overview on the central processes andtheir relations.After the initial development and release of the prototype, first, environmental andmanagement activities have to be accomplished in order to establish a project communityand to setup an initial rudimentary software infrastructure, for example, a Web site, acentral source code repository (CVS), and a bug tracking system. These environmentaland management processes are primarily executed by the maintainers of an OSS projectand are necessary to enable the collaborative RE processes and all further developmentprocesses by a distributed project community.For means of simplification, only the requirements definition and the patch developmentprocesses are visualized as explicit development processes, since both represent theprimary activities of OSS development. A very important aspect of the distributed



activities within the development processes is the fact that most processes are performedcontinuously, in parallel, and mainly independent from each other by autonomous anddistributed actors. This separates the OSSD approach from any traditional SE approachand typical development practices within commercial environments.For example, a developer who is going to develop and submit a patch acts absolutelyindependently from other developers and also from contributors who are contributingcode change requests. The only relation between these two processes is the fact that thedatabase of change requests is the starting point for every patch development cycle.


The typical process of requirements engineering in OSSD projects is based on thecollaborative and iterative development of requirements artifacts within the process ofgradual software improvement. These requirements artifacts (“Change Requests”) areused to capture the requirements for all further development activities.Scope of the OSSD requirements definition processesAs is shown in Figure 2 the requirements definition processes are part of the process ofgradual software improvement and always refer to an existing software version. The

Figure 2. Overall process model of the OSSD approach

Re-Engineering

Environment and Management Processes (central)

Development Processes (distributed)

Collaborative Patch Development Cycles

Change Requests

Patches / Source Code

Initi

al P

roty

pede

velo

pmen

t and

-rel

ease


Release Processes

Software Releases

Gradual Software Improvement

t

Process Input/

Output

Individual Deve-

lopment Activity

196 Dietze


typical OSSD processes start after the release of a software prototype as OSS and are justaimed to improve and maintain this prototype. Thus an already-existing softwareprototype seems to be a prerequisite for the requirements definition processes thattypically occur in OSSD projects. This indicates that these requirements artifacts are, ingeneral, not appropriate to describe the requirements of entire new software productsexhaustively.The requests that are developed in the RE processes by contributors of the distributedcommunity are aimed to describe requirements for improvement of the OSS, that is, toremove bugs (“Corrective Maintenance”) or to add new features to the software(“Perfective Maintenance”). Therefore the requirements artifacts can be divided into twocategories:

• Bug Reports• Enhancement Requests

Whereas a bug report describes an observed software bug, an enhancement requestdefines the extension of the OSS in terms of functionality or system compatibility.

Figure 3. Use case view of requirements definition process



Figure 4. Activity view of requirements definition process

198 Dietze


Process of Contributing Requirements

The process of contributing requirements is performed by all actors of the communityof an OSS-Project, who then turn into the role of active “Contributors.” The followingfigure represents this process in an UML-based use case view.Change requests are typically managed by a central bug tracking system that representsa central repository for all change requests and enables their structured descriptionbased on metadata. A popular bug tracking system is Bugzilla, which was developed bythe Mozilla community and is now used, for example, for the management of changerequests in the Linux Kernel4 as well as in the Mozilla5 and the Apache6 projects.RE processes in OSSD projects are performed autonomously and independently fromother processes. This is another big difference to traditional RE processes as they canbe identified in proprietary (software) industries besides the aspect that the RE processin OSSD is aimed at the gradual improvement of an already-released software product.Figure 4 presents the activities of the requirements definition process in an UML-basedactivity view.After the identification of a certain software modification need, this software misbehaviorhas to be verified by the user. This is generally done by ensuring that the latest releaseof the OSS was installed and by subsequently trying to reproduce the modificationrequirement in this software version. If the bug can be reproduced or if a need for a generalsoftware enhancement can be identified, the actor reviews the existing change requestrepository in order to verify that the request has not already been submitted. Afterensuring the novelty of the requirement, the contributor can optionally communicate therequest via a dedicated mailing list to the community of the project. This enables thewhole community to review and discuss the request and is aimed at ensuring that themisbehavior is not specific to the system or software installation of one single actor andthat no developer is already working on the implementation of this requirement. Aftercompleting this process, the contributor creates an entry in the bug tracking system anddescribes the change request based on structured metadata.In most projects this process is described in a guideline document, which is typicallycalled the “Bug Reporting Guideline” and defines the process of developing andsubmitting a change request. This document ensures a common understanding of thisprocess and is used by the community as a prescriptive guide to the process, thussupporting a higher level of quality assurance by creating a consensus about how thewhole requirements definition process has to be performed and which information shouldbe provided.

Metadata of a Change Request

As mentioned above, the change requests are captured in a bug tracking system anddescribed using certain attributes — the metadata of a requirements artifact. Thismetadata information may be specific for each OSS project but contains some general-izable attributes that exemplarily are listed below:



• Summary• Description• Keywords• Status• Affected Software Version• Attachments• Comments• Owner• Severity• Priority

The Status attribute is of special importance because it is used to document the currentstate of the change request, thus controlling the progress of the patch developmentactivities. The severity attribute is typically used to separate enhancement requests frombug reports by assigning the value “Enhancement.”

Collaborative Requirements Review

Processes for reviewing existing change requests supplement the requirements defini-tion processes and are mostly executed independently from the process of requirementsdefinition.In some OSS projects these processes are also known as “Bug Triage” (Mockus et al.,2000; Reis & Pontin de Mattos Fortes, 2002). They are aimed at ensuring a consistent,redundancy-free, and always up-to-date repository of change requests. During thesereview activities new and unconfirmed change requests are validated, and validatedchange requests that are currently not in development by a specific developer areassigned. If a change request is assigned to a developer or selected for implementationby a developer himself, an individual patch development cycle, aimed at implementingthe described requirement, is started.Figure 5 represents the requirements review process and its activities.It is important to emphasize that these review processes are implicit processes performedvoluntarily by the distributed actors, as most typical OSSD processes are. Thus theintensity these processes are performed with is not centrally planned and a defined levelof quality assurance regarding the repository of requirements cannot be guaranteed foreach point of time.

Lifecycle of a Change Request

The attribute “Status” is used to document the current state of an individual request.Every actor performing an activity that is related to a particular change request can make

200 Dietze


this information available to the whole community by setting the Status attribute of thechange request to a certain value that describes what he is going to do. Thus this attributeprovides a very important functionality for the documentation and coordination of thepatch development cycle.

Figure 5. Activity view of requirements review



Figure 6. Typical lifecycle of a change request

Figure 5 describes the typical states of a change request and therefore illustrates thelifecycle of this artifact, which is directly related to the lifecycle of the patch thatimplements this request.This information can be supplemented by setting additional attributes (Attachments,Comments) that can contain supplementary information about ongoing developmentactivities.

202 Dietze


Adaptability and Issues of the OSSDApproach

Today most software development projects, also proprietary ones, are based on thecollaboration of a more or less distributed developer and user community. Thereforecertain elements of the OSSD process model could be considered as an appropriateapproach for distributed (software) development in general. But a lot of open questionsarise in this context. In this section the adaptability of the described RE approach to otherdomains is discussed and several issues are outlined, which should be considered whenestablishing elements of the OSSD approach.

Adaptability to Other Businesses

The OSSD-based approach for gradual software improvement based on collaborativerequirements engineering can be perceived as a promising and valuable process forsoftware development that has been developed by users and developers of OSS in anevolutionary process throughout the previous evolution of OSSD practices. It seems tobe well suited to detect the requirements of globally distributed users of a software, oncea software prototype has been released. Thus the described requirements definitionprocess, which has already proven its ability to produce successful products, possiblyhas the potential to be adopted to traditional software development projects aimed atproducing proprietary, closed source software and maybe also to other industries.Involving all stakeholders of a product as early as possible in the RE process ensuresthat the developed products are suitable for all actors. Therefore similar RE approachesbased on user feedback are already in use in the software industry and also in otherbusinesses. For example, user service and support hotlines are often used to collectcustomer feedback on specific products. Furthermore several Web-based approaches toenable customers to provide feedback or request product changes are popular in differentdomains and should be perceived as informal RE methods. Often these methods are lessstructured than the OSSD approach and do not comprehensively consider the REprocesses or further implementation activities, as is done in the OSSD model. Thereforeit seems possible to improve these approaches by establishing a request tracking methodand requirements artifact lifecycle similar to the OSSD model.But regardless of this fact, the OSSD approach is aimed at the improvement of an existingproduct and it is not suited to thoroughly develop and define the requirements for entirelynew (software) products. Since a software prototype is always released at the beginningof a typical OSSD project, this seems to be a prerequisite for most of the OSSD processes,as they can all be perceived as part of a gradual process of software improvement.Therefore this requirements definition approach could not completely replace an entireRE methodology, but it seems to be appropriate to enhance or replace traditional productmaintenance processes. For example, software maintenance processes could be sup-ported by the OSSD approach of requirements definition by providing all users anddevelopers of the proprietary software product with access to a central request trackingsystem and encouraging them to submit change requests and discuss existing requests.



This could enable the appropriate elicitation of the demands of all stakeholders for furtherproduct improvement activities and could reduce the barrier between developers andusers, which is a typical issue in many industries.For a successful integration of such practices into existing business processes it isimportant to establish effective processes and to provide all actors with an appropriateinfrastructure. Since the OSSD model still exhibits several issues, these should beconsidered before establishing elements of this approach.

Issues of the Identified Approach

The analysis of the requirements definition processes that can be observed within theOSSD approach led to the identification of some issues and weaknesses of this process:

• Varying intensity of requirements review• No implementation of dedicated user privileges• Inappropriate implementation of RE artifact lifecycle• No integrated artifact management

As the process of requirements definition is usually performed by a huge community ofdistributed actors with varying skills, it is supported by prescriptive bug reportingguidelines to ensure the accomplishment of the most necessary activities. But since theobservance of these process guidelines cannot be enforced by the maintainers of theproject, the activities for reviewing and updating the change requests are important forensuring the consistency and correctness of all information within the requirementsartifact repository. Because of the voluntariness of these processes, the intensity withwhich these activities are performed cannot be ensured. Thus the quality and relevanceof all artifacts within the bug tracking system cannot be guaranteed on a defined levelat each point of time.In most OSSD projects no dedicated user privileges regarding the request artifacts areimplemented, and thus all actors can modify existing change requests independent oftheir current state. This also leads to the issue that the correctness of the metadata ofRE artifacts cannot be ensured. That is especially problematic with the Status attribute.Consequently it is possible that the Status attribute does not represent the actual stateof the artifact.As another issue the inappropriateness of the identified artifact states can be mentioned.The values of the state attribute of a change request as shown in Figure 6 enable thedescription of certain states within its lifecycle but they are not appropriate to exhaus-tively document every relevant state of a change request and the resulting patch.Therefore the whole process could be supported and implemented by improved artifactmetadata.Furthermore the artifacts that could be identified within the OSSD model are managed bydifferent, heterogeneous systems. Currently in typical OSSD software infrastructures no

204 Dietze


integrated management of all artifacts is deployed. This leads to the issue of redundantartifacts and the concern that the linkage of artifacts that are related to each other is notpossible. For example, a developer who is going to fix a bug in the development sourcecode typically has to review information in different information objects, which areorganized independently in different repositories — for example the bug tracking system,the source code repository, or mailing list archives.

Improvement Approaches

Besides the many advantages of the described RE approach some improvement oppor-tunities could be identified. In this section some possible approaches for resolving theissues described above are introduced. These are especially important when consideringthe OSSD model in commercial development environments.

Dedicated Request Review Processes

Enhancing the process model by establishing additional roles and processes can beperceived as an improvement approach for many issues regarding the OSSD model(Dietze, 2003) because an immanent tendency of OSS developers to focus on implemen-tation tasks has been observed. This leads to the problem that certain activities, forexample, documentation development, software test, or user support, are often notaccomplished sufficiently by the OSS community and therefore should be supplementedby the core developers or the maintainers of a project. Thus additional and supportiveprocesses and roles could be defined, which should not replace but supplement thealready-described RE processes.As described above, the sufficient accomplishment of the requirements review activitiesat each point of time cannot be guaranteed within OSSD projects. Therefore periodicrequest review activities could be assigned to a specific actor to ensure the appropriate-ness of all request artifacts. This actor is then assigned with the supplementary role ofa dedicated “Request Reviewer” and should be granted all privileges necessary to create,modify, or delete requirements artifacts. This creates the necessity that such an actorshould be familiar with all aspects of the software, its architecture, and the past evolutionof the source code database. Nevertheless this actor should be part of the already-mentioned group of core developers. Since the core developers typically interact veryclosely with the maintainers of a project, coordination of tasks and their schedulabilityis much easier and will find a higher level of acceptance within this group compared tothe heterogeneous community of “ordinary” actors.

Improved and Role-Based Artifact Lifecycles

As already mentioned in “Issues of the identified approach” the implemented lifecycleof RE artifacts does not seem appropriate to support and document every state of the



requirements definition and patch development process. Therefore appropriate metadata,especially the assignable values for the Status attribute, should be defined in order toenable the exhaustive representation of the entire lifecycles of a change request and theresulting patch. This would enable the appropriate documentation of the progress of allongoing implementation processes. To achieve these goals the processes for develop-ment and review of change requests were analyzed in the context of the subsequentlyperformed patch development and patch review processes that enabled the definition ofthe following, more appropriate states:

• New: Unconfirmed change request• Verified: Request verified by request reviewer• Not Verified: Request could not be verified• Assigned: Developer is implementing a patch• Patch Review: Patch submitted for review• Patch Approved: Patch approved by reviewer

Figure 7. Suggested lifecycle of a change request

206 Dietze


• Patch committed: Patch committed into development source code repository• Patch released: Patch released (as part of a software release or self-contained)

Figure 7 represents an improved lifecycle in an UML-based state view.Preventing incorrect state modifications could enforce a higher level of quality assur-ance. Therefore, every state was associated with a certain role that should be assignedthe privilege to promote the state of the artifact to the next value. Also the permissionto modify other artifact metadata should be dependent on the role of the specific actor.

Appropriate Software Support

The primary software development functionalities identified in OSSD projects areprovided by source code control and bug tracking systems (Dietze, 2003). Defining anappropriate software infrastructure that integrates all necessary functionalities tosupport the entire process model and to partly automate some of the core developmentprocesses can significantly enhance these functionalities. In general, an appropriatesoftware infrastructure should provide transparent and central access to all artifacts andinformation sources relevant for the involved actors. This information should beorganized consistently and without redundancies to enable the collaborative usage ofcommon information resources and artifacts. Furthermore, adequate communicationchannels are a prerequisite for distributed software development processes.In the context of the requirements definition processes, the software infrastructure hasto implement the improved artifact metadata and the entire artifact lifecycle, which hasbeen described above. This leads to the need of implementing role-based user privilegesrelated to request artifacts, in order to enforce a role based lifecycle model. By implement-ing well-defined user rights within such an infrastructure, an appropriate role conceptcould be enforced and implemented. In addition, routing of artifacts to appropriate actorsbased on the current state of the artifact lifecycle or automated e-mail-notification ofcertain roles triggered by defined events can be used to implement workflow functionalitiesand to partly automate the development processes.Furthermore, an integrated artifact management of all artifacts, which are created duringOSSD projects, provides a benefit to all actors and avoids redundancy (Dietze, 2003). Thelogical or physical organization of all artifacts in one unique repository enables thelinkage of related artifacts. Besides that, the structured description of all artifacts basedon appropriate metadata could support such an overall artifact management and theintegrated linkage of all artifacts that feature semantic relationships. This could increasetransparency and significantly reduce the necessary effort for obtaining information.

Conclusion

This chapter has presented certain aspects of the OSSD model and explained analternative approach of requirements definition than can be observed in typical OSSD



projects. In addition, it has discussed opportunities to improve this approach and toadopt it in traditional industries and also in other businesses to supplement their existingRE methods.Besides the advantages of the OSSD approach for defining requirements, this method-ology still exhibits several weak points and issues. Before implementing OSSD REpractices in conventional SW development projects, these weaknesses should beconsidered and minimated, e.g. by applying the improvement strategies outlined in theprevious sections. Therefore, a higher level of quality regarding the entire OSSD processmodel should be approached, which could open the opportunity to utilize general OSSDmethodologies and especially the described requirements definition practices in com-mercial software development domains as well as in other industries. Thus, some possibleproceedings for achieving an improved RE process were presented which could lead toa higher level of efficiency and quality for both, the processes and the developed artifactsand products.This could be achieved by the assignment of supplementary roles and tasks to coredevelopers of an OSSD project aimed at the introduction of formal quality assuranceprocesses into the described requirements definition approach and to make it a reliablestarting point for further implementation activities. The implementation of an appropriatesoftware infrastructure that supports these distributed processes in all of their facetscould enable process automation and a high level of process autonomy and parallelism.Thus, this could provide a big benefit to further OSSD projects and could support orsupplement distributed organizational structures in general.

References

Boehm, B., Grünbacher P., & Briggs, R. O. (2001). Developing groupware for requirementsnegotiation: Lessons learned. IEEE Software, 18(3).

Cubranic, D. (2002). Open source software development. Retrieved March 26, 2002, fromht tp: / / sern .ucalgary .ca/~maurer / ICSE99WS/Submiss ions/Cubranic /Cubranic.html.

Dietze, S. (2003). Improvement opportunities for the open source software developmentapproach and how to utilize them. Proceedings of the NetObjectDays 2003. NODeTransit GmbH.

Fogel, K., & Bar, M. (2002). Open source-projekte mit CVS. MITP.Gacek, C., Lawrie, T., & Arief, B. (2002). The many meanings of Open Source. Retrieved

May 28, 2002 from the World Wide Web: http://citeseer.nj.nec.com/485228.html.Herbsleb, J.D., & Kuwana, E. (1998). An empirical study of information needs in

collaborative software design. Information Processing Society of Japan Journal,39(10).

Herlea, D. (1998). Computer supported collaborative requirements negotiation. RetrievedOctober 10, 2003, from http://ksi.cpsc.ucalgary.ca/KAW/KAW98/herlea/.

208 Dietze


Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering. McGraw-Hill.

Mehandjiev, N., Gaskell, C., & Gardler, R. (2003). Live multi-perspective models forcollaborative requirements engineering. Retrieved October 23, 2003, from http://www.co.umist.ac.uk/~ndm/Papers/MehAWRE.pdf.

Mockus, A., Fielding, R., & Herbsleb J. (2000). A case study of open source softwaredevelopment: The Apache server. Proceedings of the 22nd International Confer-ence on Software Engineering.

Open Source Initiative. (2002). Open source definition. Retrieved December 12, 2003,http://opensource.org/docs/definition.php.

Open Source Initiative. (2003). OSI certified software licenses. Retrieved January 15,2003, http://opensource.org/licenses/index.php.

Raymond, E. S. (2001) The cathedral and the bazar. UK: O’Reilly.Reis, C. R., & Pontin de Mattos Fortes, R. (2002). An overview of the software engineering

process and tools in the Mozilla project. Retrieved May 17, 2002, from http://www.async.com.br/~kiko/papers/mozse.pdf.

Scacchi W. (2001, May 15). Software development practices in open software develop-ment communities: A comparative case study. Position paper for the First Work-shop on Open Source Software Engineering at the 23rd International Conferenceon Software Engineering (ICSE 2001).

Vixie, P. (1999). Software engineering. In C. Dibona, S. Ockman & M. Stone (Eds.), Opensources – Voices from the open source revolution. O’Reilly & Associates.

Endnotes

1 http://httpd.apache.org/2 http://www.kernel.org3 http://www.mozilla.org4 http://bugzilla.kernel.org/5 http://bugzilla.mozilla.org/6 http://nagoya.apache.org/bugzilla/

Requirements Engineering for Value Webs 209


Chapter XIII


Value WebsJaap Gordijn, Free University Amsterdam, The Netherlands

Abstract

Value webs are cooperating, networked enterprises and end-consumers that create,distribute, and consume things of economic value. The task of creating, designing, andanalyzing such webs is a prototypical example of a multi-disciplinary task. Business-oriented stakeholders are involved because the way an enterprise creates economicvalue is discussed. But also representatives responsible for business processes (manyinnovative value webs require changes in processes) and inter-organizationalinformation systems (enabling value webs from a technical point of view) play a keyrole, as well as end-consumers. To facilitate exploration and analysis of such valuewebs, we propose an approach called e3value that utilizes terminology from businesssciences, marketing, and axiology but is founded on methodology seen in requirementsengineering such as semi-formal, lightweight graphical conceptual modeling, multipleviewpoints, and scenario techniques. We have developed and tested this methodologyin a series of e-business consultancy projects. In this chapter we will present lessonslearned in developing value webs, which stem from our consultancy experience. Thenwe present the e3value methodology, with a focus on modeling and understanding whatparties offer each other of economic value. Analysing value webs from such an economicvalue perspective is the main contribution of our approach; business science approachescontain the right terminology but are far too sloppy to be usable in practice, whereasrequirements engineering and conceptual modeling approaches are sufficientlyrigorous but do not provide adequate terminology. For educational purposes, weillustrate the methodology with an easy-to-understand, inline example. Finally wediscuss related approaches and conclusions.

210 Gordijn


Introduction

Over the past few years many innovative e-business ideas have been considered.Innovative ideas are characterized by one or more new economic value propositions yetunknown to the market. A value proposition is something offered by a party forconsideration or acceptance by another party.In the recent past, industry clearly showed that is not easy to understand and analyzesuch e-business ideas (Shama, 2001). Many initiatives have been falling apart. One of theproblems with e-business development is that so many stakeholders from differentbackgrounds (CxO, business development, ICT) representing different enterprises areinvolved, not understanding each other too well and having different and sometimesconflicting concerns.To enhance a shared understanding of the e-business idea at stake, requirementsengineering (RE) and, more specifically, conceptual modeling (CM) approaches can beof use. Such approaches offer support in defining aspects of a world (in our case e-business ideas) around us with the aim to understand and to analyze it. Although RE/CM is strongly developed in the realm of information systems, there is to our knowledgeno such approach focusing on exploration of an e-business idea.In this chapter we combine a RE/CM way of working, with a business science terminologyto understand a network of enterprises creating, exchanging, and consuming objects ofeconomic value — in short a model representing an e-business idea. Our methodologyis called e-value, reflecting that it is important to understand an e-business idea from aneconomic value perspective before thinking over business process and informationsystems consequences.This chapter is structured as follows. The next section introduces e-business develop-ment and the role RE/CM plays in more detail. Then we present the description techniquesoffered by the e-value methodology, and thereafter we provide guidelines for how tomake these descriptions. Additionally these sections contain an educational case study(for real-life projects, see Gordijn & Akkermans (2003)). A series of other, sometimesontological-founded approaches are discussed. Finally we present our conclusions.

A RE-Approach for Value Webs

Over the past few years we have learned a number of lessons while doing a series ofprojects on innovative e-business case development in the realm of banking, insurance,telecom, Internet service provisioning, news, music, and electricity supply and distribu-tion (Gordijn & Akkermans 2003). The most important lesson is that in such projects,initially exploring a business model from an economic value perspective is crucial. Abusiness model explains why an e-business idea is potentially profitable for theenterprises involved. Because we assume the business model under consideration isinnovative and thus hardly known, such a model initially can only be articulated vaguely,resulting in misunderstandings between participating enterprises. Additionally a vaguely



articulated business model is an insufficient starting point for a requirements engineeringtrack with a focus on information system requirements (in e-business cases such systemsalways play an important enabling role). In sum the business model should be betterunderstood.Developing a business model in more detail involves many different stakeholders, havingvarying concerns and representing different enterprises. Typically stakeholders areCxOs, marketers, responsible for business processes, and ICT experts. Additionallystakeholders represent different enterprises with potentially different interests; e-business initiatives are characterized by a web of enterprises offering a proposition ratherthan a single enterprise. We have experienced that such a group of stakeholders has nota shared interpretation of a value proposition at all. Additionally industry itself hasdemonstrated clearly that proper analysis of e-business models has not been done(Shama, 2001), especially before the dot.com bubble exploded.To facilitate a shared understanding of an e-business model as well as to design and toevaluate it, we propose to use a conceptual modeling and requirements engineering wayof working combined with domain terminology from economic and business sciences.Since a conceptual modeling approach comprises the activity of formally definingaspects of the physical and social world around us for the purpose of understanding andcommunication (Mylopoulos, 1992), it is likely to contribute to a shared understandingof a business model. Requirements engineering is the process of developing require-ments through an iterative co-operative process of analyzing the problem, documentingthe resulting observations in a variety of representation formats, and checking theaccuracy of the understanding gained (Loucopoulos & Karakostas, 1995) and can be ofhelp during elicitation, design, and assessment of e-business models.What makes our approach new is the application of a CM/RE way of thinking in aneconomic value-driven business development process. Consequently the e3value meth-odology cannot be compared to the UML, because the UML assumes an entirely differentdomain terminology allowing different kinds of requirement statements. From a businessperspective the UML is mainly of practical use to model business processes (usingactivity diagrams). In contrast our approach models who exchanges what of economicvalue with whom and requests what in return, which are not statements about businessprocesses but rather are expressions that can be used to derive processes from.A RE approach typically consists of a number of description techniques and guidelineson how to work with these. The e3value methodology consists of three such CM-liketechniques for modeling value hierarchies, value, and profitability sheets.

The e3value Description Techniques

The e3value methodology utilizes three related description techniques. First a valuehierarchy presents a consumer need and how such a need can be fulfilled by obtainingobjects (things) of economic value. Second we introduce value webs, representing whocreates, distributes, and consumes such objects. Finally we create profitability sheetsthat show the financial effects of the e-business idea at hand.

212 Gordijn


Value Hierarchy

One of the lessons learned from our consultancy experiences is that easily understand-able description techniques are needed for the exploration of an e-business idea. Personsare involved with no background knowledge in conceptual modeling techniques at alland with no time nor inclination to learn these techniques. Hence all our notations aresimple.We start elaborating an e-business idea with the elicitation of a value hierarchy. Figure1 shows a value hierarchy for an illustrative case. A consumer need for transportationcan be satisfied by either an air flight or a train trip but always requires a taxi trip and somefood.In general a value hierarchy is a rooted a-cyclic directed graph whose root represents aconsumer need. Children of a node represent value objects used to satisfy this need. Avalue object is a good or service of economic value to some actor.The edges of a value hierarchy represent a contributes-to relationship. The reverserelationship is called consists-of. An AND-node represents the fact that all children areneeded for the higher-level one and an OR-node represents that fact that only one of thechildren is needed.The leaves (in Figure 1 indicated by “…”) of the value hierarchy are the boundary of ourvalue descriptions. We assume that one or more actors can produce these leaf objectsagainst known expenses, and can do so in a profitable way, so in order to elaborate thee-business idea, we do not need to decompose these leaf objects further.Value hierarchies are similar to goal hierarchies known from RE (Antón 1997; Dardenne,van Lamsweerde, & Fickas, 1993; Yu & Mylopoulos ,1998). Both are means-end hierar-chies. The difference is that the nodes in a value hierarchy represent value objects to beproduced or to be exchanged between business actors, whereas the nodes in a goal

Figure 1. A need for transportation can be satisfied by a train trip or airplane flight,a taxi trip, and some food (legend in grayed boxes is not part of the notation).

T ransp ortationfrom A m sterdam to Paris

T ax i trip

T rain tripA ir fligh t

… …

L ong d istance trip Food…

Leg endC onsum er

need /S tart

stimulus

O RA N D

V alueobject

n am e

C onsists-o f



hierarchy represent goals to be achieved. Often goal hierarchies are developed for singlebusiness actors, whereas value hierarchies are always developed for multiple businessactors. Finally a value hierarchy always starts with a consumer need, whereas a goalhierarchy typically starts with a business mission.

Value Webs

A value web shows which actors are involved in the creation and exchange of the valueobjects shown in the value hierarchy. Figure 2 shows a value web for our running exampleand contains the following constructs.An actor (for example, Railway) is an entity perceived by itself and by its environmentas an independent economic (and often also legal) entity. An actor makes a profit orincreases its utility by performing activities. In a sound, sustainable value web each actorshould be capable of making a profit. Actors are represented by rectangles with sharpcorners. Sets of actors with similar properties, called market segments (for example,Traveler), are represented by stacked rectangles.

Figure 2. A value web showing the value objects exchanged by actors, includingeconomic reciprocal value objects (the numbers marked with “#” and the legend arenot part of the notation).

A ir lin eA ir lin e...

A ir lin eA ir lin e

T raveler

R ailw ay

T axi

L eg en d

V a lu eE x ch a n g e

V a lu ep o r t

V a lu ein ter fa ce

V a lu eo b jec t

C o n su m ern eed /S ta r t

s tim u lu s

O R d ep .e lem en t

A irlin e

A ir lin eA ir lin e...

A N D d ep .e lem en t

M a rketseg m en t

T ran s p or ta t io n T ra n sp o r ta tio nfro m A m s terd a m to P a r is

F ly in g

A irtrip m o n ey

F o o d

“ T ra inin g ” C a te r in g

T ra intrip m o n ey F o o d m o n ey

. .. . . . . . . . . .

D r iv ing

T a x itrip

m o n ey

V a lu ea ctiv ity

.. . .. .

A ir lin eA ir lin e...A ir lin eA ir lin e...

. . . . . . . . . . . .

.. . .. .

# 1# 2# 3 # 4

# 5

# 6 # 7

# 8 # 9

# 1 0 # 1 1C o n n ec tio n

elem en t

A c to r n am e

n am e

n am e

n am en am e

E n ds tim u lu s

214 Gordijn


To satisfy a consumer need, or to produce a value object for others, an actor shouldperform a value activity for which it may be necessary to exchange value objects withother actors. A value activity (for example, Flying) is an operation that can be performedin an economically profitable way by at least one actor. It is depicted by a roundedrectangle. An important design decision represented by a value web is the decisionwhether a value object is to be obtained from other actors by means of a value exchangeor to be produced by means of a value activity by the actor itself.A value exchange, depicted by an arrow, shows that actors are willing to exchangeobjects of value with each other. Value exchanges are between actors or between valueactivities performed by actors. So in the example a train trip is exchanged between arailway company and a traveler.Each value web expresses economic reciprocity. That means we assume that our actorsare rational economic entities that are only willing to offer a value object if they acquireanother value object in return that is of reciprocal value. Reciprocity is shown by valueinterfaces and value ports. A value port is a willingness of an economically rational actorto acquire or provide a value object. A value interface is a collection of value ports ofan actor that is atomic. By this we mean that an actor is willing to acquire or provide avalue object through one port of a value interface if and only if it is willing to acquire orprovide values through all ports of the interface. In other words in case of a value interfacewith an out-going and in-going port, it is not possible to obtain an object via a port’sinterface without offering another, reciprocal object via the other port. For example,Figure 2 shows that a traveler is willing to offer money, but wants in return for that a traintrip.Note that the requirement of reciprocity causes us to introduce value objects notmentioned in the value hierarchy. The reason that these reciprocal objects are notmentioned in the value hierarchy is that their introduction is a design choice. Differentelaborations of the value hierarchy contain different choices.In most cases value interfaces of actors are identical to value interfaces of activitiesperformed by the actors; they exchange the same objects. For these cases we only showthe value interfaces of the activities and not of the actors.Apart from modeling economic reciprocity, the value interface construct serves also thepurpose of modeling mixed bundling. The value interface of the airliner in Figure 2 showsthat an air trip and food are sold as a bundle. In other words it is not possible for thetraveler to buy the air trip and the food served during the trip separately (a reminder thata value interface expresses atomicity with respect to objects it offers and requests; eitherall ports in an interface exchange objects, or none at all). Note that in real life this bundlingdecision does not hold for every airliner, but it is exactly these decisions that we wantto model with value webs.Finally we have the dependency element and connection element constructs jointlyforming a dependency path (derived from Buhr (1998)). If an actor exchanges objects ofvalue via one of its value interfaces, that same actor may need to exchange value objectsvia one of its other value interface. Considering Figure 2, a Railway company thatprovides food to its customers (value interface marked #9) needs to obtain the food fromsomeone else (value interface marked #11) or has to provide to food itself. Such internalrelationships between interfaces of an actor are shown by a dependency elements and



connection elements. Connection elements connect dependency elements. We distin-guish various forms of dependency elements: the start stimulus modeling a consumerneed that triggers the exchange of value objects, the end-stimulus representing that wedo not consider any more value exchanges, the AND fork/join showing that a depen-dency path continues in multiple sub-paths, and the OR fork/join representing that aselection has to be made out of a set of paths for continuation.

Profitability Sheets

Profitability sheets have the purpose to assess whether an e-business idea is likely tobe profitable. Because we assume that for a successful e-business idea each participatingactor should be capable of making a profit, we construct a profitability sheet for each actorinvolved.Such a sheet shows for a particular actor the in-coming and out-going value objects. Inaddition a profitability sheet presents how that actor assigns economic value to anobtained or delivered object using valuation functions. Such functions calculate a feebased on some properties. For instance a fee of train-trip may be calculated as a fixed startfee plus a kilometer-dependent fee. If we then know the number of objects exchangedduring a timeframe (expressed by quantity, depending on the number of start stimuli andthe fractions associated with OR-forks), we can calculate the Net Flow (in monetary unitssuch as Euros) for each value interface and the Total Net Flow for each actor. This TotalNet Flow should be positive for each actor. Note that a positive Total Net Flow does notdirectly imply that an actor is able to make profit (for that, we need to have potentialinvestments and other expenses too), but a negative value for the Total Net Flowindicates that the actor will not be able to make profit.

How to Create e3value Descriptions ofan E-Business Idea

Making e3value descriptions of an e-business idea is a far from trivial task. Therefore wepresent in this chapter suggestions how to do so. It is based on Gordijn & Akkermans

Table 1. Profitability sheet for the “Railway” actor

Actor Railway Start stimulus

Transportation from Amsterdam to Paris

Value objects

Quantity Out-going In-going Net Flow Value interface

#8 100 (Train trip) Money=start-fee+kilometer-fee×kilometers

100× (In-going-Out-going)

#9 100 (Food) Money=… 100× (In-going-Out-going) #10 100 … … … #11 100 … … … Total Net Flow ? Net Flow

216 Gordijn


(2003) and Kartseva, Soetendal, & Gordijn (2003) (here we have developed a domain-specific approach for the power/electricity sector).A starting point for making e3value descriptions is a promising e-business idea. Thee3value methodology contains no guidelines for finding such ideas themselves. Ratherthe scope of the e3value methodology is more modest: exploring, understanding, andanalyzing such ideas once stated such as idea.The following sections present guidelines for exploring a (often vaguely) stated e-business idea consisting of the following steps: (1) construction of value hierarchies, (2)construction of value webs, (3) finding new webs by reconstruction of earlier foundwebs, and (4) construction and evaluation of profitability sheets. For reason of brevitywe only discuss steps one, two, and four; for step three please refer to Gordijn &Akkermans (2001).

Constructing Value Hierarchies

To understand how to construct a value hierarchy, it is first important to state which kindof design choices we make during construction of a value hierarchy. A value hierarchypresents three design choices:

1. Which consumer needs do exist? By asking stakeholders to formulate a consumerneed they plan to satisfy, we increase the chance that products and services arereally wanted by consumers. It is our experience that many stakeholders haveproducts or services in mind they want themselves, rather than those wanted bytheir customer. A similar approach is also suggested by Tapscott, Ticoll, & Lowy(2000).

2. Which (alternative) value objects satisfy a need, and which (alternative) valueobjects contribute to creation of another value object? Value objects are goods orservices that can be produced by an enterprise or by a collaboration of enterprises.An important upcoming design choice is who in going to produce and consume avalue object. Consequently a first step is to identify those objects that can beproduced and consumed independently from other objects by an actor.

3. What is the scope of the e-business idea; which value objects to include and whichnot? In a value object hierarchy, leaves indicate the scope of the collaborationunder study; we call such objects contextual value objects. The value objects thatare leaves are assumed to be available already and not part of the e-business ideaexploration study. As a consequence value objects needed to produce the leafobjects are also not in the scope of hierarchy.

We use a number of guidelines to make these design choices. We indicate designguidelines with a tick (√ ) symbol.



√ Use well-defined criteria for value object identification. If a consumer need hasbeen textually stated, value object(s) must be found. Value objects should contrib-ute to satisfaction of a need or should allow production of another object, shouldbe of economic value to someone, and may be possessed, rented, granted, or areexperienced.We show the satisfaction of a consumer need by a value object by relating the needand object by a contributes-to relationship.

√ Find fine-grained value object by deconstructing coarse-grained objects. Valueobjects can be split up into smaller objects that still satisfy the above criteria.Finding such smaller objects is of interest because these objects might be producedby different enterprises, thus resulting in different value webs. Consequently, tofind smaller objects, we ask ourselves the question whether the candidate smallerobjects can be supplied and/or consumed by different actors.

√ Stop with value object deconstruction if the object under consideration fallsoutside the scope of analysis.A value object needs not be deconstructed further if we reasonably can assumethat at least one actor can produce that object, and/or we are not interested inanalyzing which other value objects are needed to produce the value object underconsideration. Alternatively it is possible that a given value object cannot bedeconstructed because no finer-grained objects can be found that comply withaforementioned criteria for value object identification.

Note that the development of a value hierarchy and a related value web is a process ofstep-wise refinement. It is common to start with a more course-grained hierarchy, whichresults in a value web with a few actors and value activities.

Constructing Value Webs

As was the case for the value hierarchy, a value web shows a number of design choices:

1. Who offers/requests which value object to/from its environment? Each valueobject, taken from the value hierarchy, potentially can be offered by differentactors. By assigning a value object to an out-going or in-going port of actor, wedecide which actor offers or requests such an object.

2. What are the value activities? An actor offering value objects must performactivities to obtain these objects, for instance, by manufacturing objects or bytrading these. Since these activities generate profit, it is important to decide on theperforming actor.

3. What are the economic reciprocal value objects? A value hierarchy only stateswhich objects satisfy a need, not how someone who is offering such an object is

218 Gordijn


compensated for that. We call such objects economic reciprocal objects. Eco-nomic reciprocity is shown by the value interface construct.

4. Is there (un)bundling of value objects? Apart from economic reciprocity, the valueinterface may also show bundling decisions. For instance an actor may offer two(different) value objects as one offering to its environment. An actor may do sobecause he believes that he will generate more revenue by selling objects as apackage deal rather than selling them separately.

5. Which partnerships exist? To offer a specific coarse-grained value object, actorsmay decide to bundle more fine-grained objects. The important design decisionhere is that from a customer perspective, the coarse-grained object is offered byone (virtual) enterprise and that the virtual enterprise companies are invisible tothe customer.

The following guidelines may contribute to answering the above design questions:

√ The consists-of/contributes-to relationships between value objects/start stimuliin the hierarchy indicate value activities. A value object with consists-of relationsto other value objects/start stimuli indicate a value activity. Such a value activityshould produce a value object, using the value objects related by consists-of asinputs.

√ Leaves in the value object hierarchy indicate contextual value activities. We havestated before that the leaves in the value object hierarchy correspond to contextualvalue objects; we are not interested in how these objects are created and consumednor in profitable ways to do so. We assume that they are available. To be able todraw value networks, and more specifically value transfers, we need, however,contextual value activities (and actors) that produce the contextual value objects.So contextual value objects result in contextual value activities.

√ Value objects/start-stimuli related by consists-of/contributes-to relationshipseach are assigned to a separate value interface of a same actor/value activity. Thisfollows from the logic of value activities and interfaces.

√ Each offered/requested value object has a reciprocal requested/offered valueobject. Value interfaces model economic rational behaviour: “one good turndeserves another.” So an interface contains at least one requested (in-going) andone offered (out-going) value object. For each value object, one asks what thereciprocal value object is.

√ If value objects are related in the hierarchy, they are related in the value web bymeans of dependency paths. In a value network we show the consists-of/contrib-utes-to relationship stated in the value object hierarchy by a dependency path. Thisallows us to do profitability assessments. If we know the number of consumer needsper timeframe, we can calculate the total amount of objects leaving and entering anactor for that timeframe.

√ Bundle objects if it is likely that they generate more profit in combination thansold separately. The value interface construct can be used to express the notion



of bundling by showing two or more offered value objects into one value interface(or two or more requested value objects). By doing so we may represent that anactor believes that by selling two objects as one package, he will create morerevenue than selling both objects separately (known as mixed bundling (Choi, Dale,& Whinston, 1997)), or if an actor only assigns value to having two objects incombination rather than having them separately.

Construction and Analysis of Profitability Sheets

The aim of profitability sheets is to determine, on a per-actor basis, whether the e-business idea seems to be profitable. Construction and analysis of profitability sheetsconsists of the following steps: (1) construction of a base-line sheet consisting of theamount of value objects flowing into and out of an actor, (2) quantification of theeconomic value of value objects in monetary units, (3) quantification of other variablessuch as the number of start-stimuli, (4) calculation of profitability sheets, and (5)sensitivity analysis. The steps are concisely presented below.

1. Construction of a base-line sheet consisting of the amount of value objects flowinginto and out of an actor. A base-line profitability sheet (for each actor one) isconstructed by following the dependency path, starting at the start-stimulus.Table 1 presents a profitability sheet for the value web (actor Railway) in Figure 2,and is constructed as follows. Start at the start stimulus and walk down the scenariopath. The AND fork (marked #1) splits the path into two sub-paths, which are bothexecuted. For brevity, we only continue the path into the left direction (marked #4)of the OR Fork (marked #2), but for a complete picture all possible paths have tobe explored. Suppose that 50% of the paths take this direction and the other 50%continues along the other path (marked #3). Now we see a next AND fork (marked#5) on your path, and thereafter we cross two value interfaces (marked #6 and #7).If we cross a value interface, we update the profitability sheet of the actor theinterface belongs to: in-going objects are captured under the column “In-going,”whereas out-going objects are presented under the column “Out-going.” Then wetraverse over the value exchanges and update the profitability sheet of the Railwayactor accordingly (because we cross-value interfaces marked #8, #9, #10, and #11).

2. Quantification of the economic value of value objects in monetary units. Table 1shows only the sheet in terms of in-going and out-going objects. A next step is toassess the number of times objects are exchanged (based on an estimate of thenumber of start-stimuli for a given timeframe). Thereafter we calculate the profit-ability. For enterprise-actors we only take into account objects, which directlyrepresent money (for example, fees). This is cf. investment theory (Horngren &Foster, 1987). In short we assume that all non-money objects flow into and out ofan actor, and consequently are not relevant for profitability analysis (these objectsare shown between parantheses). If we consider end-consumers (for example,private persons), we also include non-money objects. In brief actors are asked toassign economic value cf. utility theory and Holbrook’s consumer value framework(Holbrook, 1999).

220 Gordijn


3. Quantification of other variables, such as the number of start-stimuli. All othervariables in the profitability sheets that are still un-assigned need to have a value.A difficult decision is to determine the number of start stimuli or consumer needs.This models the expected need for the products delivered by the e-business ideato the end-consumer. It is not uncommon to use alternative numbers, for example,to model an increasing and decreasing need for the product during its lifetime. Alsomodels of diffusion of innovation (Rogers, 1995) can be used to make estimates onhow the number of consumer needs evolve (recall that the e-business ideas weconsider are about innovative products, otherwise it would not be necessary to dosuch an extensive exploration track).

4. Calculation of profitability sheets. If we have assumptions on all the numbers,calculation of the sheets themselves is a trivial task. Finally we are interested in totalNet Flow per actor. If this flow is negative, we have for that actor an unsustainablee-business idea. On the other hand if it is a positive number, it should be sufficientto cover other (for example, operational) expenses of that actor plus requiredinvestments to put the idea into operation.

5. Sensitivity analysis. It is our experience that numbers on profitability themselvesare not very useful for stakeholders involved because it is not possible to predictprofitability numbers for innovative e-business ideas accurately. Results of ex-ploiting such innovative ideas are unknown by definition, which makes it verydifficult, if not impossible, to estimate important numbers to determine profitability,for example, the number of start-stimuli per timeframe. What is important forstakeholders, however, is to reason about profitability and to do a sensitivityanalysis. This contributes to a better understanding of the e-business idea, in thiscase from a profitability perspective. To reason about profitability, we employevolutionary scenarios. In contrast to operational scenarios, which describebehavioral aspects, evolutionary scenarios describe events that are expected topossibly occur in the future. As such, effects of events underlying risks andstructural uncertainties are analysed, as well as effects of wrong estimations.

Related Approaches

There exist a series of related approaches to aid e-business development. We firstdiscuss ontological business approaches that tend to focus on single enterprise, andmore recent ontologies that take into to account a multi-enterprise perspective. Finallywe briefly review some non-ontological-founded approaches known from BusinessSciences.



Business Ontologies: AIAI Enterprise Ontology & TOVEOntology

The AIAI enterprise ontology (Uschold, King, Moralee, & Zorgios, 1998) defines acollection of terms and definitions relevant to business enterprises. Two enterpriseontology concepts relate to our ontology but have a different interpretation: (1) activityand (2) sale. In the enterprise ontology activity is the notion of actually doing something,the how. Our related definition, value activity, abstracts from the internal process andin contrast stresses the externally visible outcome in terms of created value, independentfrom the nature of the operational process. The enterprise ontology further defines a saleas an agreement between two legal entities to exchange one good for another good. Inour ontology, the concept of sale roughly corresponds to a set of reciprocal valueexchanges.The TOVE ontology (Fox & Gruninger, 1998) identifies concepts for the design of an agileenterprise. An agile company integrates his or her structure, behaviour, and information.The TOVE ontology currently spans knowledge of activity, time and causality, re-sources, cost, quality, organization structure, product, and agility. However the inter-faces an enterprise has to its environment are lacking in TOVE. Generally the notion ofthe creation, distribution, and consumption of value in a stakeholder network is notpresent in the TOVE ontology. Hence the TOVE ontology concentrates on the internalworkflow of a company, whereas our ontology captures the outside value exchangenetwork.

Recent E-Business Ontologies: REA Ontology andOsterwalder’s Ontology

The Resource Event Agent (REA) ontology (Geerts & McCarthy, 1999) shows from anontological perspective many similarities to the e3-value ontology. REA calls actorsagents. Agents are offering or requesting resources (in e3-value called value objects) byeconomic events. The latter can be compared to value ports in e3-value. REA relateseconomic events of different actors by exchanges that correspond to e3-value valueexchanges. Finally economic events of an agent are related by a duality relation. Thismodels economic reciprocity, which is handled in e3-value by the notion of valueinterface. From an ontological perspective e3-value and REA differ with respect to thenotion of value activity. This concept lacks in REA, but it is important to discussalternative assignments of such activities to actors.From a methodological point of view, REA is not an approach for business development,whereas e3-value provides a methodology for doing so, for example, by value modelconstruction and reconstruction, and by profitability-based sensitivity analysis.Osterwalder proposes an ontology for business models consisting of four pillars: (1)product innovation, (2) customer relationship, (3) infrastructure management, and (4)financial aspects (Osterwalder & Pigneur, 2002). Ontologically Osterwalder’s ontologyis rather comprehensive but not sufficiently lightweight. The latter is, for instance,

222 Gordijn


important for having a tractable instrument in workshops. Taking a methodologicalviewpoint, the ontology currently lacks a convenient way for visualizing businessmodels, which is important for using the ontology in a practical way. Additionally theontology seems not so much intended for designing business models themselves but ismore biased toward ontologically stating what a business model actually is.

Value Chains (Porter) and Value Constellations(Tapscott)

Value chain/system analysis (Porter, 1985; Porter, 2001) and the more recently valueconstellation analysis (Normann & Ramírez, 1994) can be viewed from a conceptualmodeling perspective, although these approaches have not developed with that perspec-tive in mind. Value chains can be graphically depicted. A main drawback of value chainsis that they do not precisely represent what is needed for proper business developments:they do not show who is doing business with whom but rather show the physical tracka products travels. Additionally value objects and exchanges are not shown, andconsequently economic reciprocity is not modeled.Tapscott’s value constellations (Tapscott et al., 2000) do not follow the physicaltransportation of goods but mix various concerns to be modeled, for instance, products,knowledge, and sometimes information to carry out business processes. To our experi-ence, choosing a too-broad range of concerns may hamper the development of a businessmodel due to a unfocussed stakeholder group. Additionally Tapscott’s value constel-lations do not provide facilities to model economic reciprocity and bundling.

Conclusion

The e-value methodology is about the economic value-aware exploration of innovativee-business ideas, which utilizes principles from both requirements engineering andconceptual modeling and focuses on the exploration of an IT-intensive value proposi-tion. We call such an exploration track value-based requirements engineering.Based on observations made during e-business idea exploration tracks, we motivate theneed for an e-business model, rather than a vaguely described idea. Development of sucha model serves two goals: (1) enhancing agreement and a common understanding of ane-business idea amongst a wide group of stakeholders and (2) enabling validation of thee-business idea in terms of evaluating economic feasibility. Although the developmentof an e-business model focuses on business requirements in general and potentialprofitability of the idea in particular, the model can also be used as a starting point fora more software-oriented requirements engineering process. A business model thencontributes to a better understanding of the e-business idea by system architects andsoftware developers and thereby frames the software requirements engineering process.To represent and analyze an e-business model, we have developed three descriptiontechniques, which can be used to represent a multi-actor network exchanging objects of



value. Operational scenarios are used to analyze the model for profitability in conjunctionwith evolutionary scenarios to do a sensitivity analysis on expected profits. Thereby werecognize that for innovative e-business ideas it is nearly impossible to predict profit-ability; rather we aim at the more modest goal to reason about factors influencing thisprofitability.Finally, tool support is needed for drawing and checking models (for example, forcompliance with the e-value ontology), as well as to evaluate value models. Tool supportis currently developed (a value modeling case tool) in the EC-IST project OBELIX (Obelix,2001). The latest version can be downloaded from http://www.cs.vu.nl/~gordijn.

Acknowledgment

This work has been partly sponsored by the Stichting voor Technische Wetenschappen(STW), project VWI.4949, EU-IST project IST-2001-33144 Obelix, and EU-EESD projectNNE5-2001-00256 BusMod.

References

Antón, A I. (1997). Goal identification and refinement in the specification of informa-tion systems. Unpublished doctoral dissertation, Georgia Institute of Technology,Raleigh, NC.

Buhr, R.J.A. (1998). Use case maps as architectural entities for complex systems. IEEETransactions on Software Engineering, 24(12), 1131-1155.

Choi, S.Y., & Dale O.S, & Whinston, A.B. (1997). The economics of doing business inthe electronic marketplace. Indianapolis, IN: MACMillan Technical Publishing.

Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirementsacquisition. Science of Computer Programming, 20, 3-50.

Fowler, M. (1997). Analysis patterns. Reading, MA: Addison Wesley Longmann.Fox, M.S., & Gruninger, M. (1998). Enterprise modelling. AI Magazine, 19(3), 109-121.Geerts, G., & McCarthy, W.E. (1999). An accounting object infrastructure for knowledge-

based enterprise models. IEEE Intelligent Systems and Their Applications, 89–94.Gordijn, J., & Akkermans, J.M. (2001). Ontology-based operators for e-business model

de- and re-construction. Proceedings of the First International Conference onKnowledge Capture, 60-67.

Gordijn, J., & Akkermans, J.M. (2003). Value based requirements engineering: Exploringinnovative e-commerce idea. Requirements Engineering, 8(2), 14-134.

Holbrook, M.B. (1999). Consumer value: A framework for analysis and research. NewYork: Routledge.

224 Gordijn


Horngren C.T., & Foster. G. Cost accounting: A managerial emphasis, 6th ed. EnglewoodCliffs, NJ: Prentice-Hall.

Kartseva, V., Soetendal, J., & Gordijn, J. (2003). Distributed generation business mod-eling. Deliverable D 3.1 BusMod consortium. EC-EESD funded project.

Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering. Berkshire,UK: McGraw-Hill.

Mylopoulos, J. (1992). Conceptual Modeling and Telos. In Conceptual modelling,databases and CASE: An integrated view of information systems development (pp.49-68). New York: Wiley.

Normann, R., & Ramírez, R. (1994). Designing interactive strategy - from value chain tovalue constellation. Chichester, UK: John Wiley & Sons Inc.

Obelix consortium. Obelix Project IST-2001-33144: Ontology-based ELectronic Integra-tion of CompleX Products and Value Chains: Annex I - Description of Work. 2001.See also http://obelix.e3value.com.

Osterwalder, A., & Pigneur, Y. (2002). An e-business model ontology for modeling e-business. Proceedings of the 15th Bled Electronic Commerce Conference 2002,Slovenia.

Porter, M.E. (1985). Competitive advantage - creating and sustaining superior perfor-mance. New York: Free Press.

Porter, M.E. (2001). Strategy and the Internet. Harvard Business Review, 63-78.Rogers, E.M. (1995). Diffusion of innovations. New York: Free Press.Shama, A. (2001). Dot-coms’ coma. The Journal of Systems and Software, 56(1), 101-104.Tapscott, D., Ticoll, D., & Lowy, A. (2000). Digital capital - harnessing the power of

business webs. London: Nicholas Brealy Publishing.Uschold, M., King, M., Moralee, S., & Zorgios, Y. (1998). The enterprise ontology. The

Knowledge Engineering Review, 13(1), 31-89.Yu, E.S.K., & Mylopoulos, J. (1998). Why goal-oriented requirements engineering. In

E. Dubois, A. L. Opdahl, and K. Pohl, (Eds.), Proceedings of the 4th internationalworkshop on requirements engineering: Foundation for software quality (RESFQ1998). Namur, B: Presses Universitaires de Namur.




226 Garrido, Gea and Rodríguez


Chapter XIV

RequirementsEngineering in

Cooperative SystemsJ.L. Garrido, University of Granada, Spain

M. Gea, University of Granada, Spain

M.L. Rodríguez, University of Granada, Spain

Abstract

Technology is increasing the possibilities for working in groups and even changingthe way in which traditionally this has been performed. This chapter reviews modelsand techniques for obtaining and describing requirements in cooperative systems.Features and diversity of this kind of system imply an inherent complexity in studyingand developing. Therefore methodologies and techniques aimed at enhancingrequirements and software engineering processes should be applied. The chapter alsopresents a new methodology (called AMENITIES) based on behaviour and task models,specifically intended to study and develop these systems. The focus is on the part of themethodology that is concerned with the requirements engineering discipline. Severalmodels are assembled under new conceptual and methodological frameworks in orderto allow a more complete requirements elicitation, description, and negotiation.

Requirements Engineering in Cooperative Systems 227


Introduction

New technological challenges provoke continuous improvements in society, thuschanging the conception of the world around us. Nowadays communication andcollaboration activities play an important role in the modern work organisation. Technol-ogy is increasing the possibilities for working in groups (McGrath, 1993) and evenchanging the way in which traditionally this has been performed. In this context severalusers can cooperate to perform their tasks in order to achieve better productivity andperformance. Thus users are part of a shared environment where distributed systems(called groupware) support and promote human-human interaction, where social issuesacquire more relevance (Dix, Finlay, Abowd, & Beale, 1998).A cooperative system can be defined as “a combination of technology, people andorganisations that facilitates the communication and coordination necessary for a groupto effectively work together in the pursuit of a shared goal, and to achieve gain for allits members” (Ramage, 1999). The discipline called CSCW (Computer Supported Coop-erative Work) (Greenberg, 1991; Greif, 1988) studies and analyses coordination mecha-nisms for effective human communication and collaboration as well as the systemssupporting them. Groupware has been defined as “a computer-based system thatsupports groups of people engaged in a common task (or goal) and that provides aninterface to a shared environment” (Ellis, Gibbs, & Rein, 1991, p. 40). To date groupwarehas constituted various systems: Workflow Management Systems (WfMS), computer-mediated communication (CMC) (for example, e-mail), shared artefacts and applications(for example, shared whiteboards, collaborative writing systems), meeting systems, andso forth.From the groupware definition, the notions of common task and shared environment arealso crucial for the understanding of such systems. Thus groupware systems exhibit andsupport the following features (Ellis et al., 1991, p. 40):

• Communication. This activity emphasizes the exchange of information betweenremote agents by using the available media (text, graphics, voice, and so forth).

• Collaboration. It is an inherent activity in groups. An effective collaborationdemands that people share information. The information content is shared in thegroup context.

• Coordination. The effectiveness of a communication/collaboration is based on co-ordination. It is related to the integration and the harmonious adjustment ofindividual work effort toward the accomplishment of a greater goal. It is an activityin itself influenced by technological and social protocols.

One well-known classification for groupware systems is the time-place matrix (Johansen,1988). Time dimension varies from the same time (synchronous) to different time(asynchronous) for cooperative work. On the other dimension it distinguishes sameplace (participants are located in the same location) from different place cooperative work(geographically distributed). Other requirements are faced with the sociotechnical model



in which users are involved (social roles, responsibilities, organisation rules, and soforth) when they are collaborating.These features and diversity of groupware systems imply an inherent complexity toextract requirements. Development of groupware systems is more difficult than that ofa single-user application because requirements, related to social aspects and groupactivities, must be taken into account for a successful design (Grudin, 1993). Thereforemethodologies and techniques aimed at enhancing group interaction activities shouldbe applied.Requirements engineering (RE) is defined as “a systematic process of developingrequirements through and interactive cooperative process of analyzing the problem,documenting the resulting observations in a variety of representation formats, andchecking the accuracy of the understanding gained” (Pohl, 1993). The problem has to beunderstood completely by means of its analysis. Certain stages of the process, such asanalysis, viability, and modeling, should provide a full description of requirements,including functional and non-functional requirements to be satisfied.The chapter is organized as follows. Briefly, the background section presents a reviewof methods and techniques used to specify and analyze cooperative systems. In themotivations section we describe the main motivations in providing a new proposal. Thenext section introduces the methodology AMENITIES (Garrido, Gea, Padilla, Cañas, &Waern, 2002), providing a general description of the used notation (UML), conceptualmodel, and specific models and stages involved. The emphasis is placed on the processof requirements engineering. Then we introduce a case study in order to show how themethodology addresses the RE process. Finally the main contributions are summarized.

Background

RE is concerned with capturing and describing information, identifying what should bedesigned (Macaulay, 1996). Techniques such as interviewing, brainstorming, and soforth have been widely used to obtain requirements in many kinds of systems. However,due to the specific nature of cooperative systems, the more relevant techniques appliedto this kind of system are: applied ethnography, participatory design, and scenarios.Ethnographic techniques (for example, video recording) allow specialists to understandand document functional and non-functional requirements (Ehrlich, 1999). Ethnogra-phers are more objective than stakeholders in finding out circumstances that provokedynamic changes in the system (for example, a new incoming actor in the system mustassume some work previously assigned to others). Ethnography covers non-functionalrequirements that are related to socio-cultural issues, domain constraints, work prac-tices, group dynamics, and organisations. These requirements can be used for designspecifications as well as to evaluate existing techniques. The focus is on the collabora-tive assembly of work in interaction, which leads ethnographers to speak of the socialorganisation of work, or more simply, of cooperative work (Crabtree, 2003).



Participatory design (Muller & Kuhn, 1993) is a complementary method in whichstakeholders and developers are involved in the design process of the system. It is a formof understanding users’ needs and reflecting this better understanding in the design(Newman & Lamming, 1998).Scenarios-based design is other well-known technique widely used in cooperativesystems (Carroll, 1995). A scenario is a concrete description of activities that usersengage in when performing specific tasks. Such a detailed description is also used as arequirement specification to infer different design aspects.On the other hand RE also embraces the development of abstract system models (like partof a detailed system specification). To date several approaches address the analysis andconstruction of abstract models for cooperative systems: task analysis (Dix et al., 1998)and task modeling (Nardi, 1995; van der Veer, van Vliet, & Lenting, 1995).Task-based approaches study cooperative systems from the more convenient level,user’s point of view. They describe the user’s cognitive skills to be acquired for a correctuse; the specification is focused on representing and modeling user’s tasks (Markopoulos,Johnson, & Rowson, 1997). In these approaches the system specification is a collectionof user goals where each one is defined by the sequence of tasks that allow us to achievea desired objective. Several notations have been proposed that can be used for differentpurposes. For example:

• GOMS and NGOMSL (John & Kieras, 1996) measure system performance, and theyare suitable to express the user’s knowledge.

• GTA (Groupware Task Analysis) (van der Veer & van Welie, 2000) is a method forspecifying groups. It proposes an ontology-based system study for task worldmodels, that is, a framework in which participants (agents and users’ roles),artefacts (objects), and situations (goals, events) take place. Moreover relation-ships between these elements are clearly identified (uses, performed-by, play, andso forth).

• CTT (ConcurTaskTrees) (Paternò, 2000) provides a hierarchical graphical notationto describe concurrent tasks and allows us to specify cooperation by adding ahierarchical specification with temporal constraints for each cooperative task. Thisextension and others aim to establish common tasks for several users and therelationships between them.

Motivations

Methods and techniques in the previous section are considered a correct way forcapturing and describing requirements in cooperative system. Nevertheless they alsopresent some disadvantages:



Ethnography and scenarios are an extensive, informal system description with too manydetails to be managed efficiently.Task-based approaches have a common foundation but different level of abstraction andnotations. Usually each task-based technique only addresses a few objectives (userperformance, skills, task allocation, and so forth), and the translation from one model toanother in order to study different aspects of the same system is difficult.In some cases task-based models cannot describe certain information about the coordi-nation of work. Usually coordination is based on the knowledge of what the members ofthe group are doing (presence, actions, and so forth). The term group awareness(Dourish & Bellotti, 1992) is used to define this situation. These requirements allow usto identify mechanisms that should be implemented to support coordination.In general non-functional requirements (Wilson, 1991) such as organisations, groupdynamics, workload, and so forth escape to task-based models, or at least they cannotbe represented in a suitable way within the same model. For example, the user’s role maychange throughout real situations (for example, a change of responsibilities in an officedepartment) and the ways in which the objectives are achieved (for example, a newcommercial strategy or different work organisation).In order to create software for group support, it is necessary to know the way in whicha group works. The main feature of a group is the interaction amongst its members. Agroup is a social aggregate that involves mutual awareness and potential interactions.The group performance can be affected, from a social point of view, by the human factorsregarding:

• Different interpretations of a given aspect.• Suitability of concrete tasks.• Tasks to be carried out by groups.• Relationships amongst individuals.• Properties of the environment in which they work.• New models establishing effective work scenarios.

In addition, groupware should preserve social protocols that are present in the groupcontext (and the surrounding social context). It should manage social relationshipswithin the group (social roles, constraints, and so forth). Therefore different proposalsare required to develop this kind of system. Thus the main motivations in devising a newproposal are the following:

1. It is important to describe requirements in an appropriate way, for example, the samelanguage is used for describing all requirements in order to facilitate their commu-nication.

2. Processes to study and develop CSCW systems require a unified conceptualframework including the more relevant concepts and their relationships.



3. A methodological framework should combine techniques and methods used in thebest way.

4. More complete system models specifically devised for this kind of system arerequired.

AMENITIES

From the motivations presented in the previous section, this section presents a method-ological proposal to be applied to cooperative systems. The first subsection describesthe main ideas behind this proposal. The next subsection defines a conceptual frameworkthat is the basis for it. And the last subsection, from the point of view of RE, presentsa general description of the methodology.

Introduction

The proposal states a system engineering process in which the requirements engineeringhas a specific weight (as is shown). It adopts the standard UML language (OMG, 2001)for requirements specification, system modeling and software development (see Figure1 for comparing with traditional detached approaches described in the two previoussections).UML can be defined as a general-purpose visual modeling language to specify, visualize,construct, and document the artefacts of a software system. The strengths of UML weare interested in are summarized as follows:

• The language is a standard that includes semantic concepts, notation, andguidelines.

• It has dynamic, environmental, and organizational parts.• It is supported by visual modeling tools that usually include code generators.• It is not intended to be a complete development method.• It allows a graphical specification for aspects that can be better stated in this way.• Specification at different levels of abstraction is possible.• One model may be translated into others automatically to achieve a more suitable

representation (for example, activity and state diagrams are isomorphic).

UML provides a technological focus for system development. However we are especiallyinterested in requirements description and system modeling, so the UML notation is usedas follows:



1. UML use case diagrams model the functionality of the system as perceived byoutside users. A use case is a coherent unit of functionality expressed as atransaction between the user and the system. Sometimes in the literature a use casehas been considered equivalent to a set of scenarios. Thus UML use case diagramsallow us to elicit and describe functional requirements.

2. The more abstract kind of UML diagrams (activity and state) are used to build anabstract system model. These diagrams are combined with text notation in order tosimplify the specification and increase its expressiveness.

Moreover the system engineering process will be supported on the basis of a uniqueconceptual framework (defined in the following subsection).

Conceptual Framework

Cognitive frameworks and theories, such as the activity theory (Fjeld, Lauche Bichsel,Voorhorst, Krueger, & Rauterberg, 2002; Vygotsky, 1979) and distributed cognition(Rogers & Ellis, 1994), analyze concepts within cooperative systems. We define thefollowing conceptual framework (shown in Figure 2 by means of a UML class diagram)in order to gather and connect most of these concepts. Thus the framework gives a highercommon abstraction level for cooperative systems to be described in terms of generalconcepts and the relationships between them.According to this conceptual framework, an action is an atomic unit of work. Its event-driven execution may require/modify/generate explicit information. A subactivity is a setof related subactivities and/or actions. A task is a set of subactivities intended to achievecertain goals. A role is a designator for a set of related tasks to carry out. An actor isa user, program, or entity with certain acquired capabilities (skills, category, and so

Figure 1. Engineering process for cooperative systems



forth) that can play a role in the execution (using artefacts) of or responsibility for actions.A group performs certain subactivities depending on interaction protocols. A coopera-tive task is one that must be carried out by more than one actor, playing either the sameor different roles. A group is a set of actors playing roles and organized around one ormore cooperative tasks. A group may be composed, that is, formed from, relatedsubgroups. A law is a limitation or constraint imposed by the system that allows it toadjust the set of possible behaviors dynamically. An organisation consists of a set ofrelated roles. Finally a cooperative system consists of organisations, groups, laws,events, and artefacts.The two key concepts defined above are task and group. We use the notion of task tostructure and describe the work that must be performed by the group. This provides theway to translate work, that is, something that is tacit and implicit into something that isconcrete and explicit. Nonetheless tasks are also considered at a very abstract level as

Figure 2. Conceptual framework

��

��

��

��

��

��

��

��

��

��

��

!��

"��!

�!��

��

��

��

��

��

�

��

�

�

�

��

��

�

��

��

�

�

�

�

�

�

�

��

�

� �

�

��

�

�

��

�

�

�

�

��

��

��

� �

�

��#��

��

�

�

�

��

��

��

��

��

��

��

��

��

��

��

��

!��

"��!

�!��

��

��

��

��

��

�

��

�

�

�

��

��

�

��

��

�

�

�

�

�

�

�

��

�

� �

�

��

�

�

��

�

�

�

�

��

��

��

� �

�

��#��

��

�

�

�

��



noted above. On the other hand a group can be more or less explicit. Sometimesorganizational aspects determine the way people work, but in other cases personal and/or operational aspects are the basis for organizing people in order to perform an activity.The notion of role, in any case, allows us both to specify groups as needed and toestablish dynamic relations between actors and tasks.

Methodology

AMENITIES (acronym for A MEthodology for aNalysis and desIgn of cooperaTIvesystEmS) is a methodology based on the integration of behaviour and task models for theanalysis and design of generic cooperative systems (Garrido & Gea, 2001). In Figure 3a general scheme of the methodology (main models and stages involved) is shown. Theset of behaviour and task models is a system model. This model specifies functional andnon-functional requirements collected using ethnographical techniques and repre-sented semi-formally by using UML use case diagrams. This cooperative model allowsus to carry out the system validation and property verification (Garrido & Gea, 2002) bymeans of the Coloured Petri Net (CPN) formalism (Jensen, 1996), as well as the develop-ment of the software subsystem. The methodology is based on the conceptual framework

Figure 3. General scheme of AMENITIES



described in the previous subsection. It provides a simple process that embraces phasesand models.The main stages of this process are (see dashed lines in Figure 3): (1) requirementscompilation and elicitation, and analysis of the system by means of ethnographictechniques and UML case use diagrams; (2) construction of the abstract system model(called Cooperative Model) for requirements description and negotiation; (3) propertiesverification and system validation by using a formal model derived from the systemmodel; (4) system design by introducing new elements and changes into the systemmodel, probably as a result of the previous analysis; and (5) software developmentfulfilling requirements.Just like most methodologies, AMENITIES follows a simple iterative process allowingus to refine and review these models on the basis of requirements elicitation, negotiation,and analysis. In the following subsections we describe in detail the main objectives ofthe models and stages directly involved in RE.

Requirements Models

Benefits can be obtained from combining ethnography and UML use cases. Somerequirements obtained and elicited by means of ethnography (especially functionalrequirements and social roles that users play) can be structured and specified in anabstract way by using the UML use case diagrams. Thus these diagrams:

• define stable characteristics (for example, services provided by the system), or atleast those that are maintained for long periods, and

• identify and classify social roles that users play in the system.

In this context, the more interesting advantages of using UML use case notation are:

1. use cases can be described at different levels of detail,2. they can be factored and described in terms of other, simpler use cases on the basis

of include and extend relationships, and3. roles can be classified by means of generalization/specialization relationship.

Cooperative Model

The objective of developing groupware systems is to support processes based oninteractions between users. As part of requirements elicitation, these processes shouldbe described by using, for example, workflows and/or role models. In addition require-ments described in the above stage should be discussed and negotiated with stakehold-ers. To address these issues the methodology proposes a system model structured in ahierarchical way.



This system model allows us to represent and connect instances of all concepts definedin the conceptual framework according to requirements for each specific system. It isformed by a set of behavioral and task models that are useful for specifying a CSCWsystem from the point of view of its structure and behaviour. The cooperative modeldescribes the system (especially on the basis of coordination, collaboration, andcommunication) irrespective of its implementation. Thus it provides a better understand-ing of the problem domain.To build the cooperative model, a structured method (that consists of four stages) isproposed: specification of the organisation, role definition, task definition, and speci-fication of interaction protocols. This method has been specifically devised for makingeasier connections between all concepts according to the conceptual framework definedpreviously. The notation proposed, called COMO-UML (Garrido, 2003), is based on UMLstate and activity diagrams. Hence it is basically a graphical notation that integrates smalldeclarative and operational sections. Its expressiveness power (promoting participatorydesign) makes it easy for stakeholders to be involved in the requirements negotiationprocess.

Formal Model

An operational, formal semantics, using the Coloured Petri Net formalism (CPN) (Jensen,1996), is provided in Garrido & Gea (2002) for the notation COMO-UML proposed forbuilding the cooperative model.The derived Petri Net from the cooperative model allows us to analyze the system,validate certain properties (consistency, completeness, and so forth) and evaluateusability (in terms of tasks) by means of automatic and/or guided executions. Thesesimulation techniques can also carry out performance analysis by calculating transactionthroughputs and so forth. Moreover, applying other analysis techniques (reachabilitygraphs, algebra), it is possible to verify security and liveness properties in order toprovide the complement to the simulation. In the problem domain, for instance, it ispossible to demonstrate that specified tasks can be performed by means of existinghuman resources. Therefore requirements can be negotiated in detail.

Software Development Models

The cooperative model of AMENITIES provides most requirements that groupwaresystem development needs (namely functionality, behaviour, and deployment). Inparticular requirements related to design of the interactive system and usability can bederived and analyzed, respectively, from the cooperative model in a similar way in Paternò(2000).The development models must satisfy for each system specific requirements collectedin previous stages and the following general requirements/objectives in the softwareengineering field:



• To simplify system development, splitting the whole system into components(called subsystems).

• To satisfy functional and behavioural requirements, by the orderly mapping ofservices onto subsystems.

• To fulfil certain software engineering objectives, such as reusability, portability,interoperativity and maintenance.

• To facilitate the application of new technologies (Java, objects, Web services, andso forth) making use of distributed platforms (that is, middlewares such as RMI,CORBA, etc.) for the system implementation.

Case Study

This section shows how AMENITIES addresses the main RE aspects, namely require-ments elicitation, description, and negotiation, by means of an example: the EmergencyCoordination Centre (ECC) in Sweden (Artman & Waern, 1999). This system wasdesigned and implemented fulfilling control requirements of extreme situations. TheCentre distributes tasks and is responsible, in the case of large-scale accidents, for thecoordination of the organisations involved (police, fire brigade, and medical help), untilall units have arrived at the scene of the accident. The main goal is to assign and manageresources as fast as possible, as well as to assess the particular conditions of eachemergency.

Requirements Models

Ethnography allows us to identify crucial requirements for the cooperative system. Withregard to the actors, ethnography can determine current and future roles they play andthe dynamic changes between them, on the basis of capabilities or laws. Moreover inrelation to work, it is possible to identify real practices to be carried out by members ofthe group. For example, it is possible to determine whether the work finishes when anemergency call is made and then rejected, or whether the system waits for the new user’sreactions in order to reconsider the previous decision.A typical scenario is the reception of an emergency call, which is dealt with by anoperator. This main operator receives information, evaluates the situation, and identifiesthe citizen while another operator (the assistant) dispatches the required resources. Athird operator (the resource responsible) coordinates the available resources for eachaccident. From other scenarios like this it is possible to describe functional requirementsand identify roles as is shown in Figure 4 by using a UML use case diagram.This diagram allows us to describe in semi-formal notation the basic relationshipsbetween tasks (include, extend ...), roles/actors (generalization, specialization ...) and thetask in which each role is involved. This is the preliminary step of the group task analysis.



Cooperative Model

The structured method for the construction of the system model aims to representrequirements gathered in the previous stage. These requirements can be negotiated withstakeholders during this construction. Some requirements, such as maintainability (thatis, expected changes in the computer-based system), might be derived from this modelbut not showed explicitly in it. In order to build this model the method proposes thefollowing four stages (Garrido & Gea, 2001).

Specification of the Organisation

The information obtained from ethnography is relevant to system modeling because itimposes organizational constraints on group behaviour. The organisation is describedby using COMO-UML organisation diagrams (based on UML statecharts) as is shownin Figure 5.Internal structure of the group based on social roles is identified. Relevant relationshipsbetween roles are identified on the basis of social and cognitive constraints. That is,capabilities (identified as <capability>?) state skills that actors can acquire and laws

Figure 4. UML use case diagram for the ECC

Citizen

EmergencyCoordination Centre

Ask forInformation

ResolveEmergency

MainOperator

AssistantOperator

ResourceResponsible

OperatorServerHelp

Interview

Converse

Ask forAssistance

IdentifyCitizen

MonitorResources

ListenConversation

RegisterInformation

DecideRescue

DispatchResources

DecideResources

“include”

“include”

“include”

“include”

“include”

“include”

“include” “include”

“include”“include”

RegisterCall

Server Information

“include”

Citizen

EmergencyCoordination Centre

Ask forInformation

ResolveEmergency

MainOperator

AssistantOperator

ResourceResponsible

OperatorServerHelp

Interview

Converse

Ask forAssistance

IdentifyCitizen

MonitorResources

ListenConversation

RegisterInformation

DecideRescue

DispatchResources

DecideResources

“include”

“include”

“include”

“include”

“include”

“include”

“include” “include”

“include”“include”

RegisterCall

Server Information

“include”



(identified as [<law>]) represent general constraints that the organisation imposes tocontrol role changes. Both concepts are very helpful to define and analyze possiblestrategies in group organizations (for example, behaviour protocols) and group dynamics(representing the evolution of the group).The example is comprised of only one group with three members. They play the rolesOperator, AssistantOperator, and ResourceOperator. Initially laws checking capabili-ties (for example, [Operator?]) determine the role that is played by each actor accordingto his/her professional category, specialization, and so forth. In the future actors maychange roles that they play as a result of various circumstances. An example oforganizational requirement is the following: the social organization imposes laws suchas [FreeOperators = 0], that is, an actor playing the role ResourceResponsible canbecome an Operator (or AssistantOperator) if no operators are available to resolve a newemergency call.

Role Definition

Each group divides the workload among actors, whereas each role establishes aconnection between these actors and tasks. Actors’ knowledge is described by the rolebeing played at a given time. Thus the next step is to define each previous role by theset of tasks that can/must be performed (see Figure 6). Tasks involved are specified takinginto account relevant requirements that might affect participants’ behaviour. For in-stance, relevant information would be the event that interrupts an activity (denoting taskpriorities) or triggers a task. A task can be defined as individual or cooperative.Figure 6 describes the roles Operator and AssistantOperator by using COMO-UML rolediagrams. The common task they are both involved in is the cooperative taskResolveEmergency (previously identified in the above use case diagram). This form ofspecification allows us to associate different context elements (events, actions) for each

Figure 5. COMO-UML organisation diagram

role ResourceResponsible

groupCentreStaff

role Operator role AssistantOperator

[FreeOperators = 0]

[ResourceResponsible?]

[Operator?]

[FreeOperators = 0]

capabilitylaw

role ResourceResponsible

groupCentreStaff

role Operator role AssistantOperator

[FreeOperators = 0]

[ResourceResponsible?]

[Operator?]

[FreeOperators = 0]

capabilitylaw



role involved in the task. For example, events triggering this task are EmergencyCall (forthe role Operator) and AssistanceCall (for the role AssistantOperator). Moreover, forthe role AssistantOperator, the task being performed can be interrupted (sectioninterruptible-tasks) if there is a new emergency. To fulfil this coordination requirement,the actor will behave as operator for responding to the new emergency.

Task Definition

Tasks define goals of individuals or groups. In this step each task specified previouslyis broken down into related subactivities and actions required to achieve the objective.In this case COMO-UML task diagrams (based on UML activity diagrams) are used todefine individual/group tasks. They describe cognitive capabilities that participantsneed to accomplish work.Figure 7 defines task ResolveEmergency. This is a cooperative task because more thanone participant is required to accomplish it; therefore, it specifies a collaborationrequirement to be satisfied. The notation allows us to specify temporal-ordered con-straints of subactivities by means of sequential (arrows) and concurrent (thick bars)constructions. Bifurcations (labelled with a diamond) denote a context-based decisionin the organization whereas triggering and receiving events are included as in/outrectangles. This notation assigns roles to subactivities. It is a clearer alternative to theUML swimlanes notation because it avoids more complicated diagrams.A subactivity is a composed state that can be described in greater detail. Each subactivity/action includes the specification of those responsible and optional roles needed toaccomplish it. Optional roles are shown between brackets, and the symbol ‘|’ specifiesan inclusive-or relationship. This information is relevant to specify structural andpolitical requirements of the group. Note that this task definition includes relevantinformation about user tasks, coordination mechanisms, and organisation politics(decision making, protocols, workload, and so forth).

Figure 6. COMO-UML role diagrams for Operator and AssistantOperator

role O pe ra tor

cooperative-task R e so lveE m ergency


E m erge ncyC all F reeO perato rs --

/

A ssis ten ceC a ll F ree O pe ra tors --

/

/ F reeO pe rators + +


role in terruptib le -tasks

by

A ssis tan tO pera to r

R esolveE m e rgency O p era to r.R e so lveE m ergency

event

actions

role O pe ra tor



E m erge ncyC all F reeO perato rs --

/

A ssis ten ceC a ll F ree O pe ra tors --

/



role in terruptib le -tasks

by

A ssis tan tO pera to r

R esolveE m e rgency O p era to r.R e so lveE m ergency

event

actions



Specification of Interaction Protocols

In this last stage the interaction protocols in the above task definition are described (seeFigure 7). In each collaborative activity the type of protocols used to accomplish thisobjective between participants is explicitly specified. For instance, the subactivityInterviewCaller in Figure 7 specifies the type of protocol Request-Reply that should beused to accomplish this, as well as the participants involved. On the other hand, theactivity DecideRescueUnits specifies a conversational protocol, that is, participants canparticipate in this activity in any order and with the same degree of responsibility. Theidentification of such protocols is very helpful because they identify non-functionalsystem requirements such as type of communications required (synchronous or asyn-chronous) and type of communication channel (link, mailbox, and so forth) for supportingcollaboration.In this case applied ethnography allows identification of the interaction betweenparticipants. For instance, decision-making is done by both operators (a negotiationprotocol) while in other organisations the task allocation is clearly separated (the firstoperator registers the information while the second one decides the rescue resources).These differences can also be identified in the way people interact in the scenario. Shared

Figure 7. COMO-UML task diagram for ResolveEmergency



decisions require two combined contexts: one for the input channel between citizen andoperator (which is shared with the assistant operator) and another channel (based onvoice and gestures) for internal communications between operators so that they candiscuss and decide the best solution.

Conclusion

The importance of CSCW systems is growing in recent years because of its presence indifferent types of scenario (collaborative e-learning, shared knowledge, workflow,mobile computing, and so forth). In this way, as methodological proposal, AMENITIESaims to address main activities in the field of requirements and software engineering forCSCW systems: the collaboration process itself and the dynamic context in which it isinvolved. In relation to RE, the aim is to obtain, document, and maintain functional andnon-functional requirements. With this objective in mind, the methodology combinesrequirements techniques and models on the basis of a conceptual framework. Significantquestions are whether collaboration (between actors) in the environment is necessary(compulsory) or recommended, how this should be done, and so forth. Requirementsconcerning the appropriate artefacts to guarantee the correctness of the work undertakenare also taken into account. This knowledge, therefore, is obtained from an in-depthstudy of group organisation and the rules that govern its behaviour. The notation usedalong with the process is based on the standard language UML.Current research is focused on the development of tools to support the engineeringprocess presented: guided construction of the cooperative model, execution of thismodel for simulations, and automatic translation to software models for groupwaredevelopment. In addition the used notation is being extended to cope with other relevantaspects related to requirements: information objects, new concepts to be added (forexample, job), task scheduling, and so forth. Finally AMENTIES is being applied toseveral real systems in which technology plays an important role (ubiquitous comput-ing).

References

Artman, H., & Waern, Y. (1999). Distributed cognition in an emergency co-ordinationcenter. Technology and Work, 1, 237-246.

Carroll, J.M. (1995). Scenario-based design. John Wiley & Sons.Crabtree, A. (2003). Designing collaborative systems – A practical guide to ethnogra-

phy. Springer.Dix, A., Finlay, J., Abowd, G., & Beale, R. (1998). Human computer interaction (2nd ed.).

Prentice Hall.



Dourish, P. & Bellotti, V. (1992). Awareness and coordination in shared workspaces.Proceedings of ACM CSCW’92 Conference on Computer Supported CooperativeWork, 107-114.

Ehrlich, K. (1999). Designing groupware applications: A work-centered design approach.In M. Beaudouin-Lafon (Eds.), Computer supported cooperative work (pp. 1-28).Wiley.

Ellis, C.A., Gibbs, S.J., & Rein, G.L. (1991). Groupware: Some issues and experiences.Communications of the ACM, 34(1), 38-58.

Fjeld, M., Lauche K., Bichsel, M., Voorhorst, F., Krueger, H., & Rauterberg, M. (2002).Physical and virtual tools: Activity theory applied to the design of groupware.Computer Supported Cooperative Work 11, 153–180.

Garrido, J.L. (2003). Especificación de la notación COMO-UML. (Tech. Rep. No. LSI-2003-2). Granada, Spain: University of Granada, Departamento de Lenguajes ySistemas Informáticos.

Garrido, J.L., & Gea, M. (2001). Modelling dynamic group behaviours. In C. Johnson(Eds.), Interactive systems - design, specification and verification (pp. 128-143).Revised papers. Lecture Notes in Computer Science No.2220. Springer.

Garrido, J.L., & Gea, M. (2002). A coloured petri net formalisation for a UML-basednotation applied to cooperative system modelling. In P. Forbrig, et al. (Eds.),Interactive systems - design, specification and verification (pp. 16-28). Revisedpapers. Lecture Notes in Computer Science No.2545. Springer.

Garrido, J.L., Gea, M., Padilla, N., Cañas, J.J., & Waern, Y. (2002). AMENITIES: Modeladode entornos cooperativos. In I. Aedo, P. Díaz, & C. Fernández (Eds.), Actas del IIICongreso Internacional interacción persona-ordenador 2002 (Interacción’02),(pp. 97-104). Madrid, Spain.

Greenberg, S. (1991). Computer-supported cooperative work and groupware. London:Academic Press Ltd.

Greif, I. (Ed.) (1988). Computer supported cooperative work: A book of readings. SanMateo: Morgan Kaufmann Publishers.

Grudin, J. (1993). Groupware and cooperative work: Problems and prospects. In R.M.Baecker (Eds.), Readings in groupware and computer supported cooperativework (pp.97-105). San Mateo, CA: Morgan Kaufmann Publishers. (Reprinted from)

Jensen, K. (1996). Coloured petri nets - Basic concepts, analysis methods and practicaluse (2nd ed.). Springer.

Johansen, R. (1988). Current user approaches to groupware. In R. Johansen (ed.):Groupware: Computer support for business teams (pp. 12-44). New York: FreePress.

John, B.E., & Kieras, D.E. (1996). The GOMS family of user interface analysis techniques:Comparison and contrast. ACM Transactions on Human-Computer Interaction,3(4).

Macaulay, L.A. (1996). Requirements Engineering. Springer.



Markopoulos, P., Johnson, P., & Rowson, J. (1997). Formal aspects of task based design.In design, specification and verification of interactive system (DSV-IS’97).Springer Computer Science.

McGrath, J. (1993). Time, interaction and performance: A theory of groups. In R. Baecker(Eds.), Readings in groupware and computer-supported cooperative work. SanMateo, CA: Morgan Kaufmann Publishers.

Muller, M., & Kuhn, S. (Eds.) (1993). Special issue on participatory design. CACM 36(4).Nardi, B. (Ed.) (1995). Context and consciousness: Activity theory and human computer

interaction. Cambridge MA: MIT Press.Newman, W., & Lamming, M. (1998). Interactive system design. Reading, MA: Addison

Wesley.Object Management Group. (2001). Unified modelling language specification. Online

http://www.omg.org.Paternò, F. (2000). Model-based design and evaluation of interactive applications.

Springer-Verlag.Pohl, K. (1993). The three dimensions of requirements engineering. Proceedings of 5th

International Conference of Advanced Information Systems Engineering 1993,275-292.

Ramage, M. (1999). Evaluation of cooperative systems. PhD Thesis. Lancaster Univer-sity, UK. Online http://www.dur.ac.uk/~dcs1mr/thesis/.

Rogers, Y., & Ellis J. (1994). Distributed cognition: An alternative framework for analysingand explaining collaborative working. Journal of Information Technology, 9, 119–128.

van der Veer, G.C., & van Welie, M. (2000). Task based groupware design: Putting theoryinto practice. Proceedings of Symposium on Designing Interactive Systems (DIS2000), 326-337.

van der Veer, G.C., van Vliet, J.C., & Lenting, B.F. (1995). Designing complex systems -A structured activity. In G.M. Olson & S. Schuon, (Eds.), Symposium on designinginteractive systems (DIS’95) (pp. 207-217). New York: ACM Press.

Vygotsky, L.S. (1979). Mind in society: The development of higher psychologicalprocesses. Cambridge, MA: Harvard University Press.

Wilson, P. (1991). Computer supported cooperative work: An introduction. Oxford, UK:HardboundKluwer Academic Publishers, Dordrecht Co-publication with IntellectLtd.

Specifying Requirements for Complex Sociotechnical Systems 245


Chapter XV

RESCUE:An Integrated Method forSpecifying Requirements

for ComplexSociotechnical Systems

Sara Jones, City University, UK

Neil Maiden, City University, UK

Abstract

This chapter describes RESCUE (Requirements Engineering with Scenarios for a User-centred Environment), a method for specifying requirements for complex sociotechnicalsystems that integrates human activity modeling, creative design workshops, systemgoal modeling using the i* notation, systematic scenario walkthroughs, and bestpractice in requirements management. This method has been, and is being applied in,specifying requirements for three separate systems in the domain of air traffic control.In this chapter we present examples showing how the method can be applied in thecontext of a case study involving the specification of requirements for Countdown, asystem to provide bus passengers with information about expected bus arrival times.While this system shares some important similarities with systems used in air trafficcontrol, we hope it is small and familiar enough to readers to provide meaningfulinsights into the application of the RESCUE process.

246 Jones and Maiden


Introduction

Despite recent advances in software engineering we still lack systematic and scalablerequirements engineering processes for complex sociotechnical systems. The domain ofparticular interest in this chapter is that of air traffic control, in which human air trafficcontrollers and technical, software-intensive systems are both integral parts of what canbe seen as a complex sociotechnical system controlling the movement of air traffic. Oneproblem is that established requirements techniques have emerged from single disci-plines – use cases from software engineering and task analysis from human-computerinteraction are two obvious examples. Safety-critical sociotechnical systems such asthose used in air traffic control demand rigorous analyses of controller work, softwaresystems that support this controller work, and the complex interactions between thecontrollers, the air traffic, and the software systems. To do this we need new hybridprocesses that integrate best practices from the relevant disciplines.The RESCUE (Requirements Engineering with Scenarios for a User-centred Environ-ment) process has been developed to address this need in the domain of air traffic control.Academic researchers have worked with staff at Eurocontrol (the European Organisationfor the Safety of Air Navigation) to design and implement an innovative process todetermine stakeholder requirements, which is specifically targeted toward the needs ofthat domain. Thus RESCUE focuses on specification of requirements for critical systems,where development of new systems is evolutionary rather than revolutionary and wherethe emphasis is on getting requirements right, rather than speed to market.The RESCUE process was initially developed to specify requirements for a system calledCORA-2 (“CORA” stands for Conflict Resolution Assistant). CORA-2 is a system thatwill provide computerised assistance to air traffic controllers to resolve potentialconflicts between aircraft. CORA-2 is part of a complex sociotechnical system in whichcontrollers and computers depend on each other to bring about the desired effect ofavoiding collisions between aircraft in the sky. The RESCUE process is now being appliedin the specification of requirements for two further systems in the domain of air trafficcontrol: DMAN (Departure Manager), which is a system to support controllers inmanaging the departure of aircraft from major European airports, and MSP (Multi-SectorPlanning), which is for scheduling aircrafts from gate to gate across multiple, multi-national sectors.This chapter will provide a description of the RESCUE process, together with examplestaken from the application of RESCUE to a small case study. We then provide a briefreview of related literature. Each of the major components of the RESCUE process willbe explained, with references to the literature on which it has been based. Examples ofartefacts, or models, generated during the course of the process will be given withreference to a small case study. The chapter ends with a brief consideration of futuretrends, as well as some overall conclusions.



Background

There has recently been a trend in requirements engineering toward combining tech-niques in order to complement the deficiencies of one with the strengths of another. Forexample, Leveson, de Villepin, Srinivasan, Daouk, Neogi, Bachelder, Bellingham, Pilon,and Flynn (2001) describe a safety and human-centred approach to developing ATMtools that integrates human factors and systems engineering work. Several authors havecombined use cases with other techniques for this reason. For example, Rolland,Souveyet, and Ben Achour (1998) explored the possibilities of linking goal modeling andscenario authoring, and Santander and Castro (2002) presented guidelines for using i*organisational models in the development of use cases. RESCUE is a process thatcontinues this tradition and combines use cases with a number of different techniquesin a concurrent engineering approach in an effort to increase coverage of use cases andprovide some validation of use case models through the use of other models that can bechecked against them.Use cases have been argued to provide a good basis for developing sociotechnicalsystems as they enable inter-disciplinary learning of the kind that may be necessary whendevelopment team members are drawn from the somewhat disparate disciplines of, forexample, ethnography, human-computer interaction, and software engineering(Wiedenhaupt, Pohl, Jarke, & Haumer, 1998). They are acknowledged to provide anintuitive “middle-ground abstraction” that encourages stakeholder participation (Jarkeand Kurki-Suonio, 1998) and are currently used in requirements elicitation by around halfof all organisations included in a recent survey (Neill and Laplante, 2003). However a number of difficulties have been identified for those working with use casesalone. For example:

• We cannot specify a new system to support work without understanding how thatwork is currently done (for example, Haumer, Heymans, Jarke, & Pohl, 1999) — inRESCUE we use human activity modeling to build this understanding;

• We cannot write detailed use cases without establishing the system boundaries— in RESCUE these are explored through the development of context and i* models(Yu, 1997);

• We cannot write use cases without knowing about dependencies between actorsdescribed in the use cases — in RESCUE these dependencies are thoroughlyexplored using i* models;

• We cannot write use cases without making at least some high-level designdecisions — in RESCUE we use creativity workshops to do this;

• We cannot write testable requirements without knowing the context in which thoserequirements arise (Robertson & Robertson, 1999) — in RESCUE we provide thiscontext by linking requirements to scenarios and use cases.

Thus RESCUE aims to complement the deficiencies of use cases with a range of differenttechniques in order to better support the development of large sociotechnical systems



where confidence in the correctness and completeness of use cases, and hence require-ments, is important.

The Rescue Process

The RESCUE process consists of a number of sub-processes, organised into fourongoing streams. These streams run in parallel throughout the requirements specifica-tion stage of a project, and are mutually supportive. The streams focus on the areas of:

• Analysis of the current work domain using human activity modeling (based onwork described in Diaper, 1989; Schraagen, Ruisseau, Graff, Annett, Strub, Sheppard,Chipman, Shalin, & Shute, 2000; Vicente, 1999);

• System goal modeling using the i* goal modeling approach (Yu, 1997);• Use case modeling and specification, followed by systematic scenario walkthroughs

and scenario-driven impact analyses using the CREWS-SAVRE and CREWS-ECRITOIRE approaches (Sutcliffe, Maiden, Minocha, & Manuel,, 1998); and

• Requirements management using VOLERE (Robertson & Robertson, 1999) imple-mented in Rational’s requirements management tool RequisitePro in current rolloutsof RESCUE.

In addition to these four streams, the RESCUE process uses the ACRE framework to selecttechniques for requirements acquisition (Maiden & Rugg, 1996), and creative designworkshops, based on models of creative and innovative design (Maiden & Gizikis, 2001),to discover candidate designs for the future system, and to analyse these designs for fitwith the future system’s requirements. Both ACRE and the creative design workshopshave implications for all streams. ACRE is used to support the selection of methods forrequirements acquisition at any point in the RESCUE process where there is a need forfurther requirements information. The creative design workshops use inputs from allstreams as a baseline for creative thinking and provide outputs that inform the develop-ment of i* and use case models, as well as the identification of requirements for the futuresystem.Consistency between the various artefacts and deliverables produced at different stagesin the RESCUE process is checked at five different points during the process. These five“synchronisation points” provide the project team with different perspectives fromwhich to analyse system boundaries, goals, and scenarios, as follows:

• At the first point — the boundaries point — the team establishes first-cut systemboundaries and undertakes creative thinking to investigate these boundaries;

• At the second point — work allocation — the team allocates functions betweenactors (human and technical) according to boundaries and describes interactionand dependencies between these actors;



• At the generation point, required actor goals, tasks, and resources are elaboratedand modeled, and scenarios are generated;

• At the completeness point, stakeholders have walked through scenarios andexpress all requirements so that they are testable; and

• At the consequences point, stakeholders have undertaken walkthroughs of thescenarios and system models to explore impacts of implementing the system asspecified on its environment.

An overview of the process is provided in Figure 1.The rest of this section provides a “stream by stream” view of activities carried out inthe RESCUE process. These activities will be illustrated by reference to the Countdownsystem, and a short overview of this system is given.

Countdown System Overview

Countdown is the system currently used by London Buses to provide bus arrival timeson indicators at bus stops all over London. While sharing some important similarities with

Figure 1. Overview of the RESCUE process



systems used in air traffic control, this system is small and familiar enough to readers toprovide meaningful insights into the application of the RESCUE process.An example of the format used on current bus stop indicators is shown in Figure 2.Countdown carries a number of pieces of information to waiting passengers in a clear,easy-to-understand form:

• The order in which buses will arrive at the stop;• The number of each bus;• The destination of each bus – this information originates from the driver who keys

a two-digit code into the system at the start of the journey;• The time until the bus arrives – based on how long the central computer estimates

it will take the bus to reach the bus stop from where it currently is; and• Base-line messages – the base line of the Countdown display can scroll messages

across the screen from left to right every 90 seconds – messages convey generalinformation on matters such as night buses and congestion.

Drivers are directed to start or sometimes curtail their journeys by route controllers, whomonitor the position of all buses on a number of different routes on the central computersystem. The location of the bus is currently calculated by the automatic vehicle location(AVL) system using information from roadside beacons placed at intervals along the busroute. However, this system has some disadvantages – for example, when a bus isdiverted (maybe because of road works or an accident) onto a different route where thereare no beacons, information held on the AVL system and displayed on bus stopindicators quickly becomes out of date and incorrect. To overcome this a new system isplanned that will use GPS technology to more accurately locate the position of buses atall times. An additional enhancement planned in the new system is that bus arrivalinformation should be made available to potential passengers in a number of differentformats and on a number of different devices such as mobile phones and PDAs. This willenable passengers to plan their travel wherever they are – they will no longer need to beat the bus stop in order to know when the next bus is due.

Human Activity Modeling1

In this RESCUE stream (shown as “Activity Modeling” in Figure 1) the project teamdevelops an understanding of the current sociotechnical system to inform specification

Figure 2. A simple depiction of a bus stop indicator

1 207 ACTON MKTPL 1 min2 83 GOLDERS GREEN 3 mins3 207 SHEPHERDS BUSH 4 mins ...Delays due to London Mayor’s Show



of a future system. Human activity modeling focuses on the human users of the technicalsystem, aiming to build understanding of the controllers’ current work – its individualcognitive and non-cognitive components and social and co-operative elements, as wellas the environment in which it takes place – in order to specify a technical system thatcan better support that work. It draws on the literature of task analysis (for example,Diaper, 1989), cognitive task analysis (for example, Schraagen et al, 2000) and cognitivework analysis (for example, Vicente, 1999). The stream consists of two sub-processes –data gathering and human activity modeling.During the first sub-process (shown as “gather data on human processes” in Figure 1)data about all components of the activity model is gathered and recorded. Techniquesto gather this data include observation of current system use; informal scenariowalkthroughs, using scenarios representative of how the current system is used;interviews with representative human users; analysis of verbal protocols or recordingsof users talking through scenarios or tasks; and ethnographic techniques.In the second sub-process (shown as “model human activity” in Figure 1) the project teamcreates a “human activity model” by generating a number of “human activity descrip-tions” corresponding to each of the major types of activity in the current system. Anactivity model is a repository of information about various aspects of the current system,including:

• Goals: desired states of the system• Human actors: people involved in the work of the system• Resources: means that are available to actors to achieve their goals• Resource management strategies: how actors achieve their goals with the re-

sources available• Constraints: environmental properties that affect decisions• Actions: undertaken by actors to solve problems or achieve goals, and• Contextual features: situational factors that influence decision-making.

Further information may be found in Maiden and Jones (2004a). Extracts from a humanactivity description relating to the passenger activity of making travel decisions in thecurrent Countdown system are shown in Figure 3.As can be seen from the figure, the human activity description template providesplaceholders for each of the types of information identified above. It has been designedin a similar way to our use case description template (shown in Figure 8) in which wedescribe the desired behaviour of the future system so that information about how thecurrent system supports the work of human actors can be used quite easily to helpdevelop and check proposals for the future system. Note that actions in the normal courseof the human activity description are broken down into their physical, cognitive, andcommunicative components. This information is used in generating scenarios to walkthrough as described later in the chapter.Activity models developed in this way provide important sources of data for thedevelopment of use case models and use case authoring, as well as data for fit criteria



for system requirements. In writing these activity descriptions, the team also obtains abetter understanding of the work and application domains, which is essential for effectiverequirements acquisition.

System Modeling

In this RESCUE stream (shown as “system goal modeling” in Figure 1) the project teammodels the future system’s actors (human and otherwise), dependencies between theseactors and how these actors achieve their goals, to explore the boundaries, architecture,and most important goals of the sociotechnical system. RESCUE adopts the establishedi* approach (Yu, 1997) but extends it to model complex technical and social systems,establish different types of system boundaries, and derive requirements.The system modeling stream requires three analyses to produce three models. The firstmodel, generated in the first sub-process of this stream (“determine system boundaries”in Figure 1) is a context model, similar to that used in the REVEAL and VOLERE processes(see Hall, 2001; Robertson & Robertson, 1999) but extended to show different candidateboundaries for:

Figure 3. Extracts from a human activity description for the Countdown system

Make travel decisions Author …… Date …… Source ….. Actors Passenger Precis Passengers at the bus stop want to know when buses will arrive. Goals Passenger gets to destination.

……. Semantic knowledge Passengers know:

• which route will take them closest to their destination • ……

Triggering event Passenger seeks bus information from the Countdown indicator. Preconditions Passenger is at bus stop.

…… Assumptions Passenger has normal eyesight. Normal Course 1. The passenger seeks bus information from the Countdown indicator. Resources --- Countdown indicator Physical actions --- passenger looks at Countdown indicator Communication actions --- passenger reads Countdown indicator Cognitive actions --- passenger recognises which route number(s) will take them

closest to their destinations; - passenger remembers expected arrival time(s) for bus(es) on route(s) of interest

Resource management strategies --- passenger checks information on the indicator every few minutes while waiting at the bus stop

2. The Countdown indicator shows the bus information for the relevant route(s). …… Differences due to variations 1. For passengers with mobility restrictions, passenger recognises which route

number(s) has mobility buses ……

Differences due to contextual features

4. If wet weather, then passenger may decide not to use a bus if expected waiting time is too long

…… Constraints N/A



• The technical systems, expressed in terms of software and hardware actors withinthe inner boundary (in the case of the Countdown system shown in Figure 4, thetechnical system is made up of two sub-systems);

• The redesigned work system, expressed primarily in terms of human actors, withinthe middle boundary (in Figure 4 there are two human actors who interact directlywith technical sub-systems and one technical actor, which also receives datadirectly from one of the technical sub-systems);

• Other actors that are strongly influenced by the redesign of the new system,although they do not interact directly with it, are shown within the outer boundary(in Figure 4 the only actors of this kind are passengers); and

• Systems that interact with elements of the new sociotechnical system but are notstrongly influenced by its redesign are shown outside the outer boundary (inFigure 4 this includes the GPS system, which provides data about bus locations,the communication system used in communications between drivers and routecontrollers, and the London Transport central computer system).

A completed example of a context model for the Countdown system is shown in Figure 4.The second model is the i* Strategic Dependency (SD) model, which describes a networkof dependency relationships among actors identified in the context model. A first cut ofthis model is produced in the second sub-process of the system goal modeling stream(“determine system dependencies, goals and rationale” in Figure 1) and then refined inthe third sub-process (“refine system dependencies, goals and rationale”). In an SD

Figure 4. Context model for the Countdown system



Figure 5. The Countdown Strategic Dependency Model

Pass

enge

rD

river

AVL

Syst

em

Rou

teC

ontro

ller

Cou

ntdo

wn

Dis

play

On-

Boar

dBu

s S

yste

m

GPS

Be E

asy

to U

seOpe

rate

With

out E

rror

GPS

Rec

eive

r

Bus

Loca

ted

Man

age

Rou

tes

Effe

ctiv

ely

Info

rmat

ion

beAc

cura

te

Info

rmat

ion

beR

elia

ble

Bus

Loca

tions

be U

p-to

-dat

e

Buse

s Lo

cate

d

Cal

cula

teAr

rival

Tim

es

Bus

Info

rmat

ion

Info

rmat

ion

beR

elia

ble

Info

rmat

ion

beU

p-to

-dat

e

Bus

Arri

val

Info

rmat

ion

Info

rmat

ion

beR

elia

bleIn

form

atio

n be

Accu

rateMak

e Tr

avel

Dec

isio

nsR

oute

Cha

nges

be R

ecei

ved

Cur

rent

Bus

Info

rmat

ion

Rec

eive

d

Dis

play

Bus

Info

rmat

ion

Lond

onTr

ansp

ort

Bus

Info

rmat

ion

Mon

itore

d

Tim

e C

ard

Des

tinat

ion

and

Use

r ID

be

Inpu

t

Dis

play

be

Rea

dabl

e

Res

pons

eR

ecei

ved

Qui

ckly

Bus

Loca

tion

Mon

itore

d

Eme r

g en c

yR

epor

ted

Com

mun

icat

ion

does

n't c

ause

Dan

ger

Get

tode

stin

atio

n

Traf

ficIn

form

atio

n be

Upd

ated

Rou

te C

hang

esD

ecid

ed

Com

ms

Syst

em

Driv

erC

onta

cted

Syst

em B

eAv

aila

ble

Com

mun

icat

ion

beU

nder

stan

dabl

e



model, a depender can depend upon a dependee to achieve a goal, undertake a task,obtain or use a resource, and achieve a soft goal in a particular way. For furtherexplanation of the i* notation see Yu (1997). An SD model showing the main dependen-cies between actors relevant to the Countdown system is shown in Figure 5.The third model is the i* Strategic Rationale (SR) model, which provides an intentionaldescription of how each actor achieves its own goals and soft goals. First cut and refinedversions of this model are developed in the second and third sub-processes of the systemgoal modeling stream as described above. The SR model includes goals, tasks, resources,and soft goals from the SD model, as well as task decomposition links, means-end links,and contributes-to-soft goal links that provide a more detailed view of each individualactor’s behaviour (Yu, 1997). An SR model for the Countdown system is shown inFigure 6.To support i* modeling, we have developed REDEPEND, a graphical modeling tooldeveloped as a plug-in to Microsoft Visio that enables the team to construct and analysei* SD and SR models (Maiden, Pavan, Gizikis, Clause, Kim, & Zhu, 2002).This stream provides key inputs to use case modeling. Context and i* models define thesystem boundaries that enable use case modeling and authoring. Furthermore the i* SRmodels provide a basis for validating use case descriptions prior to scenario walkthroughs.

Creativity Workshops

In this RESCUE process the team carries out some high-level creative design activitiesin parallel with on-going requirements work. This process, which takes inputs from, andprovides outputs to, sub-processes in each of the RESCUE streams, is shown as ‘creativedesign workshops’ in figure 1. Further information about how creativity workshops arerun can be found in Maiden and Jones (2004a) and Maiden Manning, Robertson, andGreenwood, (2004). A brief summary is provided below.Workshop activities were designed based on three reported models of creativity fromcognitive and social psychology. First we design each workshop to support thedivergence and convergence of ideas described in the CPS model (Daupert, 2002). Assuch each workshop period, which typically lasts half a day, starts from an agreed currentsystem model, diverges, then converges toward a revised agreed model that incorporatesnew ideas at the end of the session. Second we design each workshop period toencourage one of three basic types of creativity identified by Boden (1990) – exploratory,combinatorial, and transformational creativity. Third we design each period to encouragefour essential creative processes reported in Poincare (1982): preparation, incubation,illumination, and verification.Exploratory creativity is encouraged by asking stakeholders to reason about the futuresystem using analogies from different domains such as textile design and musicalcomposition, and combinatorial creativity is triggered by random idea generation andparallels with, for example, fusion cooking. The use case model and descriptions are usedas essential inputs and structuring mechanisms for all new requirements and designideas. Throughout a workshop each use case is displayed on a separate pin board. Thefacilitators instruct participants that all new requirements and other ideas generated



during the workshop should be related to one or more use cases, indicated by the postingof the requirement or idea on the relevant board. After each half-day session, the usecases, requirements, and ideas are reviewed, leading to some rewriting of the use casesprior to the next session. As such the outputs from the workshop are better structuredto enable a RESCUE project team to write detailed use case descriptions more effectively.This concurrent design process benefits the requirements process in two ways. First thecandidate design space reduces the number of requirements to consider by rejectingrequirements that cannot be met by current technologies. Second high-level decisionsabout a system’s boundaries enable the team to write more precise use cases and generatemore precise scenarios that, in turn, enable more effective requirements acquisition andspecification.

Scenario-Driven Walkthroughs

In this RESCUE stream (shown as “use case modeling” in Figure 1) the team developsa use case model, writes use case descriptions, then generates and walks throughscenarios to discover and acquire stakeholder requirements. We have applied resultsfrom the European Union-funded CREWS project (Sutcliffe et al., 1998) to provide methodguidance for use case authoring, software tools for scenario generation and walkthroughs,and rich traceability to link and contextualise requirements in scenarios. There are fivesub-processes.The first sub-process (“develop use case model” in Figure 1) employs inputs from thecontext model (developed in the system modeling stream), to investigate different systemboundaries. The outcome is a use case diagram with use cases and short descriptionsthat are input into use case authoring. An example of a use case diagram for the case studyis shown in Figure 7.In the second sub-process (“describe use cases” in Figure 1), the team writes detaileduse case descriptions using a structured template derived from use case best-practice(for example, Cockburn, 2000). Use cases are described as in UML, but remembering thatthey should define interactions between human and other actors at levels two, three, andfour of the context diagram, as well as interactions with the technical system. Extractsfrom a completed use case description relating to the Countdown system are shown inFigure 8. Authoring is guided using use case style and content guidelines from theCREWS-ECRITOIRE method (Ben Achour, Rolland, Maiden, & Souveyet, 1999), tempo-ral semantics expressed as action-ordering rules, and, for our air traffic management(ATM) projects, an extensive lexicon of ATM nouns and verbs elicited from controllers.To write each description the team draws on outputs from the other streams – humanactivity models, i* strategic dependency and rationale models, stakeholder require-ments, and innovative design ideas from the creativity workshops.Once each use case description is complete and agreed, the team produces a parameteriseduse case specification from it (this is the “specify use cases” sub-process in Figure 1)to generate scenarios automatically using the CREWS-SAVRE software tool (Sutcliffeet al., 1998). Different types of action in the normal course of the use case lead to the



Figure 6. The Countdown Strategic Rationale Model

Cur

tail

Bus

Rou

teBe

Eas

y to

Use

Ent

erD

estin

atio

nIn

for m

atio

n

Rou

teIn

form

atio

nO

pera

teW

ithou

t Err

or

Rou

te C

hang

esbe

Rec

eive

d

Tim

e C

ard

Des

tinat

ion

and

Use

r ID

be

Inpu

t

Res

pons

eR

ecei

ved

Qui

ckly

Em

erge

ncy

Rep

orte

dC

omm

unic

ate

Safe

ly

Trai

ning

be

Min

imal

Com

mun

icat

ew

ith R

oute

Con

trolle

rB

us S

cedu

leAd

here

d to

Rou

teK

now

ledg

e

Driv

e Bu

s

Be R

elia

ble

Pro

ceed

on

new

rout

eA

ct o

n ro

ute

chan

geim

med

iate

ly

Con

tact

Rou

teC

ontro

ller

Driv

e r

Com

ms

Syst

em

GPS

Tran

smit

Loca

tion

Tran

smit

Sig

nal

Info

rmat

ion

beR

elia

ble

Info

rmat

ion

beA

ccur

ate

GP

SR

ecei

ver

Bus

Loca

ted

Info

rmat

ion

on th

e N

ext

Stop

Sate

llite

Sig

nal

Rec

eive

dD

river

&ro

ute

info

Loca

te B

us

Rad

ioC

ontro

ller

Tras

nmit

Info

rmat

ion

toA

VL

Nex

t Sto

pIn

fo G

iven

Ent

er In

fo o

nsy

ster

m

On-

Boar

dBu

s Sy

stem

AVL

Sys

tem

Info

rmat

ion

beA

ccur

ate

Bus

Loc

atio

nsbe

Up-

to-d

ate

Bus

es L

ocat

ed

Cal

cula

teA

rriva

l Tim

es

Poll

syst

emre

gula

rlyD

river

info

accu

rate

Bus

timet

able

s

Exp

ecte

djo

urne

ytim

esU

pdat

e sy

stem

with

cur

rent

loca

tion

Sys

tem

be

relia

ble

Upd

ate

syst

emdi

spla

ys

Cou

ntdo

wn

Dis

play

Bus

Info

rmat

ion

Info

rmat

ion

beR

elia

ble

Info

rmat

ion

beU

p-to

-dat

e

Info

rmat

ion

beAc

cura

te

Dis

play

Bus

Info

rmat

ion

Dis

play

be

Rea

dabl

e

Rec

ieve

Bus

Info

rmat

ion

Dis

play

on

Indi

cato

r

Dis

play

on

Web

site

Dis

play

on

PDA

Dis

play

on

Mob

ile P

hone

Info

rmat

ion

beC

onve

nien

t

Indi

cato

rId

entif

icat

ion

Indi

cato

r be

wor

king

Lond

onTr

ansp

ort

Tran

spor

tSi

tuat

ion

Mon

itore

d

Req

uest

Upd

ates

Bus

Info

rmat

ion

Con

tact

Rou

teC

ontro

llers

Che

ck A

VLS

yste

m

Traf

fic U

pdat

ebe

Rec

eive

d

Rou

teC

ontro

ller

Man

age

Rou

tes

Effe

ctiv

ely

Info

rmat

ion

beA

ccur

ate

Info

rmat

ion

beR

elia

ble

Cur

rent

Bus

Info

rmat

ion

Rec

eive

d

Bus

Loc

atio

nM

onito

red

Sys

tem

Be

Ava

ilabl

e

Com

mun

icat

ion

beU

nder

stan

dabl

e

Driv

erco

ntac

ted

Cal

l driv

er o

nco

mm

s sy

stem

Driv

ernu

mbe

r

Upd

ate

Ldn

Tran

spor

t with

Traf

fic n

ews

Man

age

bus

rout

es

Viie

w b

ussy

tem

dis

play

Com

mun

icat

ew

ith d

river

Pass

enge

r

Bus

Arr

ival

Info

rmat

ion

Info

rmat

ion

beR

elia

ble

Info

rmat

ion

beA

ccur

ate

Mak

e Tr

avel

Dec

isio

ns

Get

toD

estin

atio

n

Com

plet

eJo

urne

y Q

uick

lyD

ispl

ay b

eR

eada

ble

Dec

ide

whi

chbu

s to

cat

ch

Purc

hase

Tick

et o

n Bu

s

Sta

ndar

d Lo

ok&

Feel

Tim

etab

lean

d ro

ute

map

Kno

wle

dge

of B

usR

oute

sVi

iew

bus

syte

m d

ispl

ay

Boar

d B

us

Rou

te c

hang

esde

cide

d

Bus

loca

tion

disp

laye

d

Pur

chas

e tic

ket

befo

re b

oard

ing



Figure 7. Use case diagram for the Countdown system

Operator sign-on

Driver

Alert controller to emergency

London Transport

Receive current traffic information

Send route information

Monitor bus location

Display

Provide information for travel decisions

GPS

Determine bus location and arrival times

<<include>>

<<include>>

Route controll

generation of different alternative courses, which will be used to guide the stakeholdersto consider how the future system should respond in the event of, for example, cognitiveslips or communication errors as described below. A more detailed description of howthis is done in the ATM domain is given in Mavin and Maiden (2003).The fourth sub-process (“walkthrough scenarios” in Figure 1), is pivotal to RESCUE andinvolves walking through each generated scenario with stakeholders using bespokesoftware tool support. Each scenario may be delivered for walkthrough in two forms –either through the Web-based Scenario Presenter tool shown in Figure 9 or as aninteractive MicroSoft Excel spreadsheet that can be downloaded by the session facili-tator. Facilitators walk through the scenario with relevant stakeholders, guided by theScenario Presenter, to consider each normal course event and each alternative courselinked to that normal course event in turn. The same scenario may be considered in anumber of different “walkthrough contexts” in which stakeholders are asked to makedifferent assumptions about the human or environmental context in which it takes place;for example, considering how passengers may act differently at night or in bad weather.A scribe uses the tool to document all requirements and comments relating to each event.For example, when considering the event “The passenger looks at the Countdowndisplay” and the alternative “What if passenger has some unusual physical character-istics that affect his/her behaviour during this action?” the scribe is asked to add a newfunctional requirement that “The Countdown system shall provide an audio facility,” asshown in Figure 9. Further guidance on how to conduct a scenario walkthrough can befound in Maiden and Jones (2004a) and Maiden (2004).



The final sub-process (“impact analysis” in Figure 1) uses a sample of these scenariosin order to investigate how the system, as specified, will impact key social and environ-mental factors such as job security, actor roles and responsibilities, and access toinformation. This is done in a series of impact inspection meetings using ‘readingtechniques’ such as those identified in Travassos et al. (2002). Questions about thepotential impact of the proposed future system have been identified based on work byHeath, Jirotka, Luff, & Hindmarsh (1993), Hughes, O’Brien, Rodden, & Rouncefield (1997)and Viller and Sommerville (1999).The main outcome of this stream is a set of more complete requirements that can be tracedto the originating scenario, and hence use case, and specified in context to removeambiguity and make them more testable.

Figure 8. Extracts from a use case description for the Countdown system

Provide information for travel decisions Use Case ID UC5 Author ….. Date ….. Source ….. Actors Passenger, Countdown display, AVL system Problem statement (now) Arrival information is only available at bus stops, which means that some travel

decisions can only be made at that time. Precis The passengers will be able to use various different types of Countdown displays to

find out the arrival times of buses Functional Requirements FR23: All types of Countdown display shall provide the passenger with bus arrival

information …..

Non-functional Requirements

AR4: All types of Countdown display shall be available at all times …..

Added Value Passengers will be able to access bus arrival times from various locations, not just at bus stops.

Justification Passengers will be more likely to use buses if they are able to access bus arrival information from a range of locations.

Triggering event The passenger seeks bus information from the Countdown display Preconditions The Countdown display is functioning correctly Assumptions Passenger has normal eyesight Successful end states The use case is successful if the passenger receives the required bus information Unsuccessful end states The use case is unsuccessful if the passenger does not receive the required bus

information Different walkthrough contexts

Wet weather …..

Normal Course 1. The passenger looks at the Countdown display 2. The Countdown display shows the bus information for the relevant route(s) 3. The passenger reads the bus information from the Countdown display ….. Variations • If the Passenger uses a PDA or mobile phone to access the Countdown display,

then 3.1. The Passenger enters the start and destination locations of his or her

desired journey 3.2. The Countdown system validates the locations 3.3. The Countdown system identifies the relevant routes 3.4. The Countdown system displays the relevant bus routes and the arrival

times for buses due within the next hour Alternatives N/A



Managing Requirements

In this fourth RESCUE stream (“requirements management” in Figure 1) the project teamdocuments, manages, and analyses requirements generated from the other three streams.Each requirement is documented using a modified version of the VOLERE shell (Robertson& Robertson, 1999), a requirement-attribute structure that guides the team to make eachrequirement testable according to its type. Use cases and scenarios are essential tomaking requirements testable. Each new requirement is specified either for the wholesystem, one or more use cases of that system, or one or more actions in a use case. ThisRESCUE requirement structure links requirements to use cases and use case actions andplaces them in context, thus making it much easier to write a measurable fit criterion foreach requirement.This use case-driven requirement structure carries over into the requirements documentitself, to improve both the readability of the document and the understandability of eachrequirement statement. The document is divided into a series of use case descriptionsusing the RESCUE use case template, with requirement statements inserted into normaland alternative course descriptions next to the relevant use case and use case actions,as shown in Figure 10.

Figure 9. Screen from the Scenario Presenter tool



In ATM projects carried out to date, RESCUE requirements have been documented usingRational’s RequisitePro. Outputs from other streams, such as use case, context, and i*models are all included in the document. The team also applies the VOLERE QualityGateway (Robertson & Robertson, 1999) to all requirements to be entered into thedocument. One member of the team is allocated to play the Gatekeeper role, asking anumber of questions of each requirement to ensure that only complete and correctrequirements enter the document. Questions seek to establish whether the requirementis testable, viable, solution-independent, and of value to stakeholders.

Managing the RESCUE Process

RESCUE is a complex process and depends crucially on managing the activity carried outin different streams to ensure consistency between the different artefacts shown aboveand to ensure that work in each stream can draw on the others as needed. Central to thisare the checks carried out at the five synchronization points identified at the beginningof this section and shown in Figure 1. In overview these checks are as follows. Furtherinformation and examples can be found in Maiden and Jones (2004b).At the end of stage one, data about human activities and the context model are used tocheck the completeness and correctness of the use case model. System-level require-ments are used to check use case summaries.Most cross checking is done at stage two in order to bring the human activity and first-cut i* models to bear on the development of correct and complete use case descriptions.Components of the human activity descriptions are checked against the i* models anduse case descriptions, with particular attention being paid to areas where the futuresystem will be different from the existing one. The i* models and use case descriptionsare checked against each other, and a first set of requirements is derived from both thei* models and the use case descriptions.At the end of stage 3, use case specifications are checked using the i* models, and therefined i* models are used to check the requirements database.Checks carried out at the end of stage four and five relate solely to the internal structureof the requirements database, as no new artefacts are generated during these stages.

Figure 10. Extracts from the Countdown requirements document

1. The passenger looks at the Countdown display FR28 The Countdown system shall provide an audio facility

2. The Countdown display shows the bus arrival information for the relevant route(s) FR3 The Countdown system shall display the order in which the next three buses

will arrive at the journey starting point, the number of each bus, the destination of each bus, and the estimated time until the arrival of each bus

RR2 95% of estimated bus arrival times shall be correct to within 30 seconds



Future Trends

To identify requirements for future sociotechnical systems we need integrated require-ments processes that draw on human- as well as techno-centric disciplines. This hasimplications both for the teams of people carrying out the work as well as the tools,techniques, and artefacts that are a part of the processes used. Teams must be drawn froma variety of disciplines such as human-computer interaction, ethnography, cognitivetask analysis, and software engineering (see, for example, Viller & Sommerville, 1999).Tools, techniques, and artefacts must enable the intertwining of inputs from each of thesedisciplines. We believe that our scenarios provide a valuable tool for capturing insightsregarding current work practices as well as detailed knowledge about human-computerinteraction and integrating them into a framework that is now familiar to most softwareengineers. To further explore the application of these techniques in new contexts we haverecently developed a version of our scenario walkthrough tool for Personal DigitalAssistants (PDAs), so that scenario walkthroughs can be done in the work context,thereby linking contextual inquiry and structured walkthrough techniques for require-ments discovery (Seyff, Grunbacher, Maiden, & Tosar, In press).

Conclusion

In this chapter we have presented RESCUE, a concurrent engineering approach torequirements specification that combines use cases with a number of different tech-niques from both software engineering and other disciplines. We have learned from ourexperience with RESCUE that use cases, when complemented by other techniques – i*modeling, creativity workshops, CREWS-SAVRE scenario walkthroughs, and so forth –do indeed provide a solid foundation for the specification of requirements for complexsociotechnical systems. We do not attempt to capture all of the information derivedthrough this process using any single formalism, but rather see the strength of ourapproach as its use of multiple, integrated representations, which support a systematic,analytic, yet creative approach to the development of a final requirements document. Onthe strength of our experience to date we argue that RESCUE focuses more attention onhuman elements of a sociotechnical system, provides better support for identification ofsociotechnical system boundaries, and embodies a more systematic approach to thediscovery of requirements through scenario walkthroughs than other mainstream ap-proaches based on use cases alone.RESCUE has already been successfully applied in specifying requirements for the CORA-2 system introduced earlier (see Maiden, Jones, & Flynn, 2003a; Maiden, Jones, & Flynn,2003b), and at the time of writing, we have almost completed the application of RESCUEto the specification of requirements for Eurocontrol’s future DMAN Departure Manage-ment system, working together with the U.K. National Air Traffic Service. Applying theRESCUE process in CORA-2 led to the generation of an operational requirementsdocument that had the confidence of stakeholders and passed reviews carried out bystaff who were outside of the CORA-2 requirements team. The requirements document



for CORA-2 contained approximately 400 requirements, structured using 22 use cases.Numbers for DMAN are likely to be similar. However such an approach is not cheap. Forboth CORA-2 and DMAN, considerable training was required before the process couldbe applied. In each case, the requirements phase of the project has taken around ninemonths, with two full-time requirements engineers as well as additional effort fromstakeholders and domain experts. However the process has worked, and investment intraining is now yielding a good return as RESCUE is rolled out to two other projects inthe ATM domain. We look forward to reporting fully on our experiences in these twoprojects in due course.

References

Ben Achour, C., Rolland, C., Maiden, N.A.M., & Souveyet, C. (1999). Natural languagestudies on use case authoring. Proceedings of 4th IEEE Symposium on Require-ments Engineering, 36-43.

Boden, M.A. (1990). The creative mind. London: Abacus.Cockburn, A. (2001). Writing effective use cases. Addison-Wesley.Daupert, D. (2002). The Osborn-Parnes creative problem solving manual. Retrieved from

www.ideastream.com/create.Diaper, D. (Eds.) (1989). Task analysis for human-computer interaction. Ellis Horwood.Hall, A. (2001). A unified approach to systems and software requirements. Proceedings

5th IEEE International Symposium on Requirements Engineering, 267.Haumer, P., Heymans, P., Jarke, M., & Pohl, K. (1999). Bridging the gap between past and

future in RE: A scenario-based approach. Proceedings of 4th IEEE Symposium onRequirements Engineering, 66-73.

Heath, C., Jirotka, M., Luff, P., & Hindmarsh, J. (1993). Unpacking collaboration: Theinteractional organisation of trading in a city dealing room. Proceedings of theThird European Conference on Computer-Supported Cooperative Work, Kluwer.

Hughes, J., O’Brien, J., Rodden, T., & Rouncefield, M. (1997). Designing with ethnog-raphy: Making work visible. Proceedings of DIS’97, 147-159.

Jarke, M., & Kurki-Suonio, R. (1998). Guest editorial: Introduction to the special issue onscenario management. IEEE Transactions on Software Engineering, 24(12) 1033-1035.

Leveson, N., de Villepin, M., Srinivasan, J., Daouk, M., Neogi, N., Bachelder, E.,Bellingham, J., Pilon, N., & Flynn, G. (2001). A safety and human-Centred approachto developing new air traffic management tools. Proceedings Fourth USA/EuropeAir Traffic Management R&D Seminar.

Maiden, N.A.M. (2004). Systematic scenario walkthroughs with ART-SCENE. In I.Alexander & N.A.M. Maiden (Eds), Scenarios in practice. John Wiley.

Maiden, N.A.M., & Gizikis, A. (2001). Where do requirements come from? IEEE Software18(4), 10-12.



Maiden, N.A.M., & Jones, S. (2004a). An integrated user-centred requirements engineer-ing process, Version 4.1. RESCUE process project document.

Maiden, N.A.M., & Jones, S. (2004b). RESCUE Process: Examples, Version 2.1. RESCUEprocess project document.

Maiden, N.A.M., & Rugg, G. (1996). ACRE: Selecting methods For requirements acqui-sition. Software Engineering Journal, 11(3), 183-192.

Maiden, N.A.M., Jones, S., & Flynn, M. (2003a, June 23-27). Innovative requirementsengineering applied to ATM. Proceedings of ATM 2003, 5th USA/Europe R&DSeminar, Budapest.

Maiden, N.A.M., Jones, S., & Flynn, M. (2003b, September 8-12). Integrating RE methodsto support use case based requirements specification. Proceedings 11th Interna-tional Requirements Engineering Conference, Monterey.

Maiden, N.A.M., Manning, S., Robertson, S., & Greenwood, J. (2004). Integratingcreativity workshops into structured requirements processes. To appear in Pro-ceedings of DIS2004.

Maiden, N.A.M., Pavan, P., Gizikis, A., Clause, O., Kim, H., & Zhu, X. (2002, September).Making decisions with requirements: Integrating i* goal modelling and the AHP.Proceedings REFSQ’2002 Workshop, 9-10, Essen, Germany.

Mavin, A., & Maiden, N.A.M. (2003). Determining sociotechnical systems requirements:Experiences with generating and walking through scenarios. Proceedings 11th

International Conference on Requirements Engineering.Neill, C., & Laplante, P. (2003). Requirements engineering: The state of the practice. IEEE

Software, 20(6), 40-45.Poincare, H. (1982). The foundations of science: Science and hypothesis, the value of

science, science and method. University Press of America.Robertson, S., & Robertson, J. (1999). Mastering the requirements process. Addison-

Wesley-Longman.Rolland, C., Souveyet, C., & Ben Achour, C. (1998). Guiding goal modeling using

scenarios. IEEE Transactions on Software Engineering, 24(12), 1055-1071.Santander, V., & Castro, J. (2002). Deriving use cases from organisational modeling.

Proceedings IEEE Joint International Conference on Requirements Engineer-ing, 32-39.

Schraagen, S., Ruisseau, J., Graff, N., Annett, J., Strub, M., Sheppard, C., Chipman, S.,Shalin, V., & Shute, V. (2000). Cognitive task analysis. (Tech. Rep. No. 24). NorthAtlantic Treaty Organisation, Research and Technology Organisation.

Seyff, N., Grunbacher, P., Maiden, N.A.M., & Tosar, A. (In press). Requirementsengineering tools go mobile, submitted for publication.

Sutcliffe, A.G., Maiden, N.A.M., Minocha, S., & Manuel, D. (1998). Supporting scenario-based requirements engineering. IEEE Transactions on Software Engineering,24(12), 1072-1088.

Vicente, K. (1999). Cognitive work analysis. Mahwah, NJ: Lawrence Erlbaum Associ-ates.



Viller, S., & Sommerville, I. (1999). Social analysis in the requirements engineeringprocess: From ethnography to method. Proceedings of 4th IEEE InternationalSymposium on Requirements Engineering, 6-13.

Weidenhaupt, K., Pohl, K., Jarke, M., & Haumer, P. (1998). Scenario usage in systemsdevelopment: A report on current practice. IEEE Software, 15(2), 34-45.

Yu, E. (1997). Towards Modelling and Reasoning Support for Early-Phase RequirementsEngineering. Proceedings of the Third IEEE International Symposium on Re-quirements Engineering, Jan. 6-8, Washington D.C., USA. IEEE Computer SocietyPress, 226-235.

Endnote

1 Note that the term “human activity modeling” (or sometimes “activity modeling”for short) as used here is distinct from the term “activity modeling” as used by theHCI community in relation to design reasoning.

266 Sørby, Melby and Seland


Chapter XVI

Using Scenarios andDrama Improvisation

for Identifying andAnalysing

Requirements forMobile ElectronicPatient Records

Inger Dybdahl Sørby, Norwegian University of Science and Technology, Norway

Line Melby, Norwegian University of Science and Technology, Norway

Gry Seland, Norwegian University of Science and Technology, Norway

Abstract

This chapter presents two different techniques for elicitation and analysis of requirementsfor a mobile electronic patient record (EPR) to be used in hospital wards. Bothtechniques are based on human-centred and participatory design principles. The firsttechnique uses observational studies as a basis for identifying and analysingrequirements for a mobile EPR. The observations are structured and systematisedthrough a framework. The second technique is named “Creative system developmentthrough drama improvisation”, and it enables users (in this case healthcare

Identifying and Analysing Requirements for Mobile Electronic Patient Records 267


professionals) to contribute to the requirements engineering (RE) process by actingout everyday work situations in one-day workshops. Both techniques presented in thischapter focus on user requirements elicitation, and we believe that they are promisingand complementary contributions to more traditional requirements elicitation andanalysis methods, not only for hospital information systems but for a wide variety ofcomplex, sociotechnical systems.

Introduction

Advanced clinical information systems have great potential for systematising andstructuring the large amounts of information that exist in modern hospitals. At the sametime these systems may also simplify and coordinate the endless streams of communi-cation that take place. A well-designed system has to be intuitive, effective, and flexibleenough to meet the specific information and communication needs of a wide range ofhealthcare professionals. However, the high information intensity and the complexity ofthe organisation make the system design process particularly challenging. Both thesocial features of current work practice and the technical features of the system have tobe considered when performing requirements gathering and analysis (Reddy, Pratt,Dourish, & Shabot, 2003). One approach to such sociotechnical requirements analysisis to involve users more actively in the design process through methods such asparticipatory design.In this chapter we introduce and discuss two different techniques for elicitation andanalysis of requirements for a mobile electronic patient record (EPR) to be used inhospital wards. Both techniques are based on human-centred and participatory designprinciples, and they have been developed and used as parts of the MOBEL1 (MobileElectronic Patient Record) project at the Norwegian University of Science and Technol-ogy (NTNU). An EPR is a computer system designed to support clinicians by providingaccessibility to complete and accurate patient data. It may also include alerts, reminders,clinical decision support systems, links to medical knowledge, and other aids (Coiera,2003; Dick, Steen, & Detmer, 1997). Numerous EPR systems exist, most of them developedfor stationary computers, but also for various other devices such as handheld computers.The first of the techniques presented in this chapter uses observational studies as a basisfor identifying and analysing requirements for a mobile EPR. Observational studies arefrequently used within the social sciences, and during the last decades computer scienceresearchers have also acknowledged such methods as useful for understanding thecomplexity of organisations and the various information needs of different users. Yetsystem developers may not always be able to transform rich observations to require-ments and design decisions. In this chapter we present a framework for structuring andformalising scenarios obtained from observational studies at a hospital ward. Furtherwe discuss how the outcome of characterising these scenarios may be used for producingrequirements to a mobile electronic patient record.The second technique, Creative system development through drama improvisation, hasbeen introduced by product designers and software engineers as a method for develop-



ing and testing ideas for functionality. However, most of them have only reported resultsof the method without providing any detail on how the drama sessions were actuallyperformed. We have developed and tested a procedure for how healthcare professionalscan contribute to the requirements engineering (RE) process by acting out everyday worksituations at a hospital ward. The procedure description is accompanied by a presenta-tion of the findings, including the advantages and limitations of the technique.The next section of this chapter focuses on the hospital as a complex organisation andhence a challenging site for introducing new information and communication systems.We briefly address how traditional RE methods fall short in integrating social processesand work practices in the system development. Furthermore we discuss the tradition ofuser-centred design and some approaches to requirements elicitation methods forsystem development in complex organisations such as hospitals. This is followed by apresentation of the two different techniques used in the MOBEL project and a discussionof the advantages and disadvantages of both techniques. Finally we suggest how thesemethods may be used as a supplement to traditional requirements elicitation methodswhen developing complex sociotechnical systems.

Background

“Traditional” RE methods have previously focused on system functionality, based onthe assumptions that the application domain is stable, that information is fully availableand known, and that most work consists of formal, routine processes (Reddy et al., 2003).This view is about to change, as system designers are more aware of the importance ofincluding social and organisational processes if they want their systems to be success-fully adopted into complex organisations. Air traffic control, underground subwaycontrol systems, and financial systems are examples of areas where sociotechnicalapproaches to requirements analysis have been used successfully (Reddy et al., 2003).Nonetheless traditional requirements analysis is still predominant in the area of clinicalhealthcare. A great number of costly clinical systems and projects have failed (see, forexample, Heath & Luff, 2000; Heath, Luff, & Svensson, 2003; Sicotte, Denis, & Lehoux,1998), one of the most common reasons being the lack of sufficient requirements analysis.This implies the need for a more thorough requirements analysis and elicitation phase,taking into account both sociological and organisational aspects of clinical work. So faronly a few researchers have reported using sociotechnical requirements analysis in thisapplication area (Berg, 1999; Berg, Langenberg, v.d. Berg, & Kwakkernaat, 1998; Heath& Luff, 1996).

The Hospital as a Complex Organisation

Today’s hospitals are highly specialised and differentiated organisations. Dedicateddepartments and services have required an expansion of physical facilities, reallocationof workers, and the integration of new skilled personnel into a continuously changing



division of labour. This has in turn led to the establishment of complex relationshipsamong a multiplicity of hospital services and departments (Strauss, Fagerhaug, Suczek,& Wiener, 1997). This puts strong demands on coordination and collaboration betweendifferent specialist departments and also between the different professions in thehospital.Scheduling, coordination, and communication in hospitals take place through a widearray of sources: electronic, paper-based, and oral. Even in “paperless” hospitals, theEPR is often supplemented by paper-based systems, and such a mixture of systems maycause several problems. A major problem with paper-based systems is that there is oftenonly one copy of each document, and consequently it can only be used at one place andfor one purpose at a time. Paper-based systems are not synchronised with the EPR, whichmight lead to errors and omissions. Furthermore different groups of healthcare workershave their own documentation systems, which imply that important information is storedin different places. Providing this information to all groups of health personnel, byimproving accessibility, is an important task.Replacing paper-based systems by computer systems might solve the problem ofunavailability and unsynchronised information and also enhance the quality of care byproviding healthcare personnel more quickly with information they currently collect fromdifferent sources.However, designing such systems brings about at least two important challenges:

1. How to decide what kind of information health personnel need and consequentlywhat to include in the system. Health personnel have multiple and diverseinformation needs, and to be able to design a functional system, it is vital tounderstand their information needs in relation to different tasks and contexts.

2. How to present the information. Health personnel are mobile workers, and theytherefore need mobile information systems. Mobile devices such as handheldcomputers offer information access at the point of care, but the limited screen sizeand poor input facilities place strong demands on the presentation and navigationof the information. The lack of good user interfaces has also been identified byseveral other researchers as a major impediment to the acceptance and routine useof many types of computing systems in healthcare (see, for example, Patel &Kushniruk, 1997).

Human-Centred Design

To face the challenges of designing and developing user-friendly and efficient computerapplications for healthcare organisations, it is necessary to know and understand thecontext of use. This is one of the main activities in human-centred design, an approachto interactive system development that focuses specifically on making systems usable(EN ISO 13407, 1999). Figure 1 shows the main components of the human-centred systemdevelopment cycle.



One of the principles of human-centred design is “the active involvement of users anda clear understanding of user and task environments” (EN ISO 13407, 1999, p. 2). Thisdesire to increase and improve user participation by making users more active throughacting out everyday situations is the rationale for using drama improvisation as a partof the system development process. Through establishing a common ground, or a “thirdspace”, for communication (Muller, 2002) we consider this approach useful for improvingcommunication between system developers and prospective users of the system. Thisapproach follows the tradition of several research projects in the Scandinavian countries,where role-play and games have been used to create common spaces between softwaredevelopers and users from the early efforts in participatory design (Ehn, 1988), to morerecent years (Buur & Bagger, 1999). However, few of these methods have been deployedwhen developing systems for such complex organisations as hospitals.The drama improvisation method relates mainly to activities three, four, and five of thehuman-centred design approach (see Figure 1). To be able to gain a thorough insight andspecify the context of use (activity 2), it may be crucial to perform ethnographic orobservational studies. These studies are valuable for exploring the nature of a particularphenomenon and gaining detailed insight into an environment (Atkinson & Hammersley,1994). Anthropologists and sociologists extensively use these techniques (Coiera &Tombs, 1998; Heath & Luff, 2000; Hughes, Randall, & Shapiro, 1993). There exist a greatnumber of ethnographic studies of healthcare organisations in general and of informationneeds and communication behaviour among healthcare workers (see, for example, Berg,1999; Berg et al., 1998; Forsythe, Buchanan, Osheroff, & Miller, 1992; Schneider &Wagner, 1993; Symon, Long, & Ellis, 1996). Nevertheless, a remaining challenging taskis how to utilise this sociological insight in informing design.One technique for bridging some of the gap from ethnographic studies to designdecisions is by building narrow or rich scenario descriptions of current work practice

Figure 1. Human-centred design activities (from EN ISO 13407, 1999)

2. Understand and specify the context of use

3. Specify the user and

organisational requirements

4. Produce design solutions

5. Evaluate designs against

requirements

1. Identify need for human-

centred design

6. System satisfies specified user and

organisational requirements



situations in order to perform requirements analysis. This has been one of several rolesof scenarios in the system development lifecycle (Carroll, 1995; see also Bødker &Christiansen, 1997). A scenario is a description of a process or a sequence of acts innarrative form (Kuutti, 1995). The next section gives an example of how to structure andcharacterise scenarios obtained from observational studies at a hospital ward.

Observational Studies: Creating aFramework for Structuring andAnalysing Scenarios

To be able to produce requirements for a mobile, electronic patient record, our firstchallenge was to understand how both paper-based and electronic information systemswere currently used on the hospital wards. Hence observational studies of physicians’and nurses’ daily work in three wards at the University Hospital of Trondheim wereconducted. One week was spent observing at two of the wards, while a more extensiveobservational study of four months was conducted in one ward. The observations weresupplemented with informal interviews with the health personnel.

Analysis

Iteration

Iteration Iteration

Obser-vations

Example scenarios

Characteri-zation framework

ExSc #n

Figure 2. Elements of the framework development process



Framework Outline

One of the main purposes for conducting the field studies was to identify scenarios thatwould improve, change, or even become superfluous by introducing the mobile EPR. Aspreparation for the observational studies, a set of preliminary attributes that wereconsidered important for structuring and formalising the observations was defined. Wealso defined a set of values corresponding to the attributes. Next the observationalstudies were conducted, and based on the observations a number of example wardscenarios were extracted. Subsequently the example scenarios were characterised byapplying the framework. The framework has been developed iteratively as new observa-tions, scenarios, and characterisations brought the need for changing attributes andoutcome values. Figure 2 illustrates the framework development process.The attributes were prearranged into three main parts: process attributes, input at-tributes, and outcomes. The process attributes were aimed at depicting the structure ofthe scenario, for example, if the composition of the scenario was predetermined and if thescenario was decomposable. Other process attributes involve the number of actors androles in the scenario, dependencies and preconditions, formality level (that is, informal/semiformal/formal), information flow, location, and temporal nature of the scenario.

Process attributes:Below are some examples of process attributes with corresponding values and explana-tion:Number of participants (1, 2-4, >=5)States the number of participants involved in the scenario. The value “2-4” typicallyrepresents a patient care team, while “>=5” represents the ward physicians, nurses, orthe entire ward staff.Number of roles (One, Two, Several)Number of roles represented in the scenario (for example, physician, nurse, enrollednurse, and so forth.).Scenario nature (Informal, Semiformal, Formal)Denotes the formality level of the scenario.Regularity (Shift, Daily, Occasionally)Indicates if the scenario takes place every shift, every (week-) day, or sporadically.Scheduling (On the spot, In advance, Well in advance)States to what degree the scenario is planned and scheduled in advance (“Well inadvance” indicates more than one day in advance).

Input and Outcome Attributes

Attributes related to input information and outcome include type (for example, whetherthe information is constructive, for coordination, or motivation), variance, error, excep-



tions, medium/modality, time, and validity (for example, novelty, longevity, and delaytolerance).

Examples of input information attributes:Recorded (Personal notes, Informal local practice, Forms, Patient record, Not)Denotes how/if the source(s) of the input information is recorded, such as in personalnotes, forms, varying due to informal local practice, and/or in the patient records.Longevity (None, Short term, Long term)Denotes the lifetime of the recorded input information used in the scenario. ‘None’ isrelated to oral input information, ‘Short term’ is related to personal notes or otherinformal practices, ‘Long term’ indicates permanent storage in the patient record.Medium/mode (Speech, Text, Picture, Other)Denotes the form of the information brought into the scenario.Example of outcome attribute:Type of produced information (Constructive, Cooperation, Coordination, Socialisation,Negotiation, Motivation)Constructive: The information is used as a decision basis or leads to some performedaction; Cooperation: Used as a basis for care team work; Coordination*: The practice ofencouragement of working relationships between differentiable groups and/or individu-als; Socialisation*: The introduction, reinforcement or modification of an organisation’sculture or sub-culture; Motivation*: The increasing of the expenditure of effort, energy,and enthusiasm by members of a group; Negotiation*: A collaboration between two ormore parties representing particular interests in specific outcomes where the purpose isostensibly to achieve these outcomes through a process of discussion and compromise.*Values from (Horrocks, Rahmati, & Robbins-Jones, 1998)

All the attributes and the corresponding values are described in (Sørby, Melby, & Nytrø,in press).As previously mentioned, work activities in hospital wards are characterised by acomplex mixture of formal procedures and informal practices, cyclicity, and mobility, andthe proposed framework tries to capture all these aspects. The selected attributes wereinspired by and related to work in traditional requirements engineering, computer-supported collaborative work (CSCW), human-computer interaction, and sociology (forexample, Horrocks et al., 1998; Sørensen, Wang, Le, Ramampiaro, Nygård, & Conradi,2002).

Characterising Scenarios by Means of the Framework

In Figures 3a, 3b, and 3c three example ward scenarios are presented. An instance of ascenario is here defined as a time-limited process (for an individual patient) in which the



Figure 3a. Example scenario 1

Figure 3b. Example scenario 2

Figure 3c. Example scenario 3

S1: Pre-rounds conference per patient The pre-rounds conference is held every weekday prior to the ward rounds. One or more physicians and nurses (typically the head physician, one assistant physician, and the team leader nurse) from the care team discuss the care plans of the patients based on the patient chart, possible new test and/or examination results, and supplementary information from the nurse documentation or undocumented information from the participants of the conference. The nurse has a notebook called “ward rounds book” in which he or she registers the tasks of the ward secretaries and the nurses; for instance, if there has been a change in the medications of a patient or if a patient is to be discharged or moved to another ward.

S2: Ward rounds incident: Seeking new test results One of the patients wants to know his haemoglobin percentage. The nurse returns to the office to check the latest laboratory answers, but due to a mistake the test was not ordered in the morning. The consequence is that the patient has to take an additional blood sample, and the physician has to remember to check the result of the test when it becomes available.

S3: Medication - per patient One of the nurses in the patient care team uses information from the patient chart to put today’s medications for the ward patients onto a medicine tray. Later the nurse in charge inspects the medicine tray to ensure that the medicines correspond to the recorded information on the patient chart.

cast (people filling roles) does not change and that has an identifiable start, precondi-tions, end, and outcome.Based on observable scenario attributes and subjective participant statements, eachscenario has been characterised by applying the framework presented earlier in thissection.Table 1 shows the result of applying the framework to the example scenarios S1-S3. “N/A” (not applicable) indicates that the attribute is irrelevant to the scenario in general oras a consequence of the value(s) of previous attributes. For some of the scenarios,several valid values apply to a number of the attributes.

Findings: The Scenario Approach

The presented framework is mainly intended for structuring and sorting observationsand scenarios from current work situations and establishing a vocabulary for



Table 1. Examples of applying the framework to ward scenarios

Attribute S1 S2 S3 Number of participants 2-4 2-4 2-4 Number of roles Several Several Two Number of role levels Several Several Two Composition Predetermined Ad-hoc Predetermined Decomposition No No Yes Scenario nature Semi-formal Informal Formal Regularity Daily Occasionally Daily Scheduling Well in advance On the spot On the spot Variance of required information A lot No Somewhat

Location(s) Predetermined, varying Multiple Predetermined,

fixed Spatiality One place Two places One place Temporality Synchronous Asynchronous Asynchronous Information exchange Many-to-many One-to-many One-to-many

Initiation On demand On demand On demand Precondition

Proc

ess

Delay tolerance of scenario start None None None

Novelty To some To all To some

Recorded Personal notes Patient record forms

Patient record Patient record

Longevity Short & long term Long term Short term

Medium/mode Speech & text Text Text

Scope All Some All

Info

rmat

ion

inpu

t

Delay tolerance of input information None None None

Explicit Yes Yes Yes Shared Yes Yes Yes Novelty To some To all To some

Recorded All types Patient record Personal notes Patient record

Longevity Short & long term Long term Long term

Type of produced information

Constructive Cooperative Coordinating

Constructive Cooperative Constructive

Medium/mode Speech & Text Speech & Text Text

Scope Patient care team members

Patient care team members

Patient care team members

Delegation of responsibility Predefined On the spot Predefined

Delegation of tasks Predefined On the spot Predefined Delay tolerance Unknown None None

Out

com

es/p

rodu

ced

outp

ut

Outcome type known in advance Yes No Yes



characterising them. To identify system requirements by means of scenarios, it isnecessary to perform thorough clustering analysis of the resulting characterisation ofexample scenarios. Various methods exist for this purpose. Contextual design is oneexample of an approach that adapts ethnographic methods of understanding humanbehaviour in context (for example, the workplace) and extends these methods to functionwithin traditional software and usability engineering practices (Carroll, 1995).In this study the manual analysis of applying the framework to a few scenarios indicatesthat a mobile EPR is beneficial in certain situations, for instance, when the documenteddecisions and plans are direct results of consulting formalised information from the EPR.Similarly the mobile EPR seems superfluous in other situations — for example, when aprocess outcome is short-term operational knowledge. Other findings suggest that evenif the overall information needs and communication patterns in the different wards aresimilar, the use of the patient record varies greatly depending on the individual user, thatis, how experienced the user is, how long he or she has been working in the particularward, and how well-known the patients are. This confirmed our assumption that themobile EPR has to be dynamic and adaptable to various situations and users.When applying the framework to the example scenarios, we faced several challenges.Since a scenario is an abstraction of many underlying narratives, there is considerablevariance from observation to observation, and it is therefore important to try to captureand describe this variance as part of a scenario narrative. Seemingly unfinished orinconclusive processes are common, as are deviations from plans or from normalscenarios. These aspects are important for the system design but difficult to capture inthe proposed framework. Despite these challenges when modeling the framework, webelieve that the final framework may serve as a constructive tool both before and duringsystem design.

Creative System Development throughDrama Improvisation

The following sections are based on three one-day drama workshops organised at NTNU(Svanæs & Seland, 2004). The main goal of the workshops was to develop a method thatinvolves end-users actively in designing a mobile health information system throughscenario building, drama improvisation, and low-fidelity prototyping. The method alsoenables system developers to gain a better understanding of the users’ domain byobserving how healthcare workers stage and act out current and future use scenarios.

Workshop Structure and Contents

The workshops were held in a full-sized model of a future hospital ward. The modelcontained several partly furnished patient rooms where most of the acting took place.Two groups of three healthcare workers (physicians and nurses) participated in eachworkshop. Besides the organisers and a few observers, two graduate students in



computer science taking roles as system developers also participated in the workshops.In addition a drama teacher was hired as a facilitator in the first workshop. The systemdevelopers were neither involved in the scenario selection nor allowed to suggest designsolutions, but during the rehearsal of the scenarios they briefly discussed the scenariosand design solutions with the healthcare workers.After a brief introduction of the participants, the organisers gave a general introductionto system development processes, to user-centred methods specifically, and the ratio-nale behind using drama improvisation as a method. After the introduction the partici-pants were introduced to simple warm-up exercises before they were split in two teams.Both teams performed a brainstorming session on communication- and information-richsituations from their hospital ward to identify scenarios to be dramatised later on.Example scenarios were written on Post-it notes and placed on a wall, clustering similarsituations (Figure 4). After deciding which situation they would prefer to present, theydecided upon details such as the exact number of participants and the time and locationof the event.The teams rehearsed their scenarios before presenting them to the other participants.Each scenario was presented twice, first as the team had rehearsed it and next withinterruptions from the other team. An example of an interruption is that the physician’spager beeps, and he or she has to leave the room to check the message. The reason forintroducing interruptions was to make the participants more used to improvising andchanging their well-rehearsed scenario, in addition to obtaining realistic and morediverse situations.After a short break the organisers presented a brief overview of various mobile techno-logical solutions. The healthcare workers were handed low-fidelity prototypes (foammodels) that could be used in the next variants of the scenarios. In the first workshopthe participants discussed how they could incorporate this technology into their chosensituations, and they sketched “screen shots” on Post-it notes. In the second and thirdworkshops the participants “developed” their systems as they acted. When seeing aneed for some information, they stopped acting and sketched their solutions on Post-it notes attached to the prototypes. Again the teams acted out their scenarios in frontof the other team but this time with “technology” incorporated as a part of the scenario.Figure 5 shows two nurses improvising new work practices using the low-fidelityprototypes. As in the former performances, the groups acted their scenarios both withand without interruptions. At this stage of the workshop, the interruptions wereintroduced to test the reliability of the suggested solutions.A plenary gathering where all participants discussed and summarised the workshopconcluded the day. Topics that were discussed were the realism of the chosen scenarios,experiences from acting out the scenarios, and various considerations about theproposed technological solutions.

Findings: Drama Improvisation as Input into the REProcess

To evaluate the drama improvisation method, questionnaires were completed by theparticipants at the end of each workshop. These questionnaires were supplemented with



Figure 4. Nurses brainstorming work situations

Figure 5. Nurses acting out future scenario



interviews and discussions with the system developers and the healthcare personnel.In addition the system developers wrote preliminary reports from the workshops andsubsequent requirements specifications.The following sections discuss some important findings from the evaluation of the dramaimprovisation method.

System Developers’ Understanding of the Domain and theTechnological Needs of the Users

One of the most striking features of drama improvisation as a method is its ability to letsystem developers get a thorough insight into the domain without requiring their actualpresence at the work site. The system developers in our workshops found it much easierto understand the domain through the health personnel’s acting than by simplyquestioning health personnel or otherwise reading or listening to descriptions of worksituations. “Watching health personnel ‘working together’, even though fictitious,makes you think about things you previously haven’t considered” (interview with thesystem developers, 23 May, 2003). The workshops helped in detecting health personnel’sinformation needs that the system developers were previously unaware of or thoughtwere already being met. Likewise the opposite was also the case: in situations where thesystem developers predicted a need for formal and written information, the healthpersonnel solved their information needs informally, asking each other.Another issue considered important was the significance of health personnel talkingtogether while acting out the scenario. Through their talking they explained and clarifiedfor the system developers what was happening in the scenario.The system developers were positive and quite impressed by the technological solutionssuggested by the health personnel: “I feel that they came up with some pretty cleversolutions. And what’s positive is that they came up with it themselves, and then it is morelikely that they actually will use it” (interview with the system developers, 23 May,2003). The users’ suggestions were perceived as a healthy corrective to the systemdevelopers’ visions. System developers sometimes tend to design a more sophisticatedand advanced system than users really require and want, thus neglecting the users’actual needs.

Communication between System Developers and Healthcare Workers

Good communication between system developers and future users is of great importancein user-centred design approaches. In our opinion, drama improvisation is a suitablemethod for facilitating communication and obtaining a common understanding of asystem design project. It establishes a common ground, a third space, for both systemdevelopers and future users. Since the users are the domain experts and their knowledgeand creativity are actively used in the design process, they may feel more conversant withthe future system and therefore more willingly accept it.When nurses and physicians work together with system developers, it is important tocreate a common language they all understand. “Telling by showing”, as is the case when



work situations are dramatised, is a natural way to describe everyday work and is easyand intuitive to understand. Thus drama becomes a common language of the systemdevelopers and the healthcare personnel.Another important point is that simply bringing system developers and future end users,in this case health personnel, together and providing them with time to talk and ask eachother questions within an informal atmosphere proved helpful in the process of identi-fying requirements. Because the participants acted scenes out rather than merelyanalysing or describing them, a playful atmosphere was created. This resulted indiscussions and a lot of interesting information being shared in the breaks between theformal schedules. As the acting sessions took place outside the hospital, the systemdevelopers were also able to “freeze” the situations and ask clarifying questions withoutfear of disturbing real patients.

Creating Requirements Specifications Based on the Workshops

Based on the last two workshops, two preliminary requirements specifications werecreated. These specifications demonstrate one of the main limitations of the method:Some functional requirements were described in detail, while others were missing due tothe specific focus in the workshops. This implies that the method has to be supplementedby other RE methods to explore the remaining functional and non-functional require-ments of the system.Another important issue for the outcome of the workshop is the participants’ personalopinions and technological skills. As some participants had strong opinions regardingsolutions, they tried to take a leading position in defining the technological needs. Theorganisers therefore had to make sure that every participant’s opinion was heard.Likewise the different participants did not always agree on what solution would be thebest in their daily work. This led to healthy discussions about advantages and disadvan-tages of the different solutions, but it also complicated the resulting requirementsspecification, as the various solutions had to be considered.

Discussion

The techniques presented in this chapter are both based on human-centred systemdevelopment, but they contribute in different phases of the human-centred systemdevelopment cycle. One main difference is that the drama improvisation method is moreinteractive and the users are directly involved in specifying the requirements of thesystem, even if this is not explicitly stated. The framework approach, on the other hand,puts strong demands on researchers to “translate” observations into examples ofrepresentative scenarios, characterise them via the framework, and then deploy theresults in the system design.In a real hospital setting a wide range of real-life situations can be observed, in contrastto drama improvisation where a one-day workshop typically includes only two (fictional)



situations. Furthermore the outcome of the workshops depends very much on theindividual participants. It is therefore crucial to try and find representative, “average”users. During observational studies all groups of employees can be watched in their dailywork. This gives a more complete picture and a better understanding of the context ofuse. However, it is impossible to “freeze” situations when conducting field studies, andthe observers might hold back questions in order to interrupt as little as possible in a busyenvironment. In the workshops freezing situations and asking questions were perceivedas very useful by the system developers.We believe that both methods presented in this chapter are promising and complemen-tary contributions to requirements elicitation and analysis, not only for hospital infor-mation systems but also for a wide variety of complex, sociotechnical systems. Obser-vational studies are particularly useful for gaining knowledge of the domain while dramaworkshops seem especially important in the introductory phase of a project, in order tocreate a common ground for the system developers and some of the end users of thesystem. The drama improvisation approach has also proven advantageous when systemdevelopers have little or no knowledge of the domain and when it is inconvenient toperform field studies; for instance, when a project involves a large group of systemdevelopers. When combining the methods, field studies can be used to identifysituations of interest prior to the drama workshops and to validate situations that havebeen developed during the workshops, and as such they may reinforce each other’spotential.Both techniques presented in this chapter focus on user requirements elicitation and arenot sufficient for producing complete requirements specifications. As previously dis-cussed, the methods are particularly useful for gaining knowledge of the domain in theintroductory phase of a system development project, but they must be supplemented byother, traditional, methods for requirements gathering and analysis (for example, ques-tionnaires, surveys, interviews, analysis of existing documentation, prototyping, and soforth).

Acknowledgments

We would like to thank the staff at the University Hospital of Trondheim for theircooperation both during the observational studies and by participating in the work-shops. Thanks also to Ann Rudinow Sætnan, Øystein Nytrø, and Dag Svanæs forvaluable comments and contributions.This research was financed by NTNU Innovation Fund for Business and Industry andAllforsk Research.



References

Atkinson, P., & Hammersley, M. (1994). Ethnography and participant observation. InN.K. Denzin & Y.S. Lincoln (Eds.), Handbook of qualitative research (pp. 248-261).Thousand Oaks: SAGE.

Berg, M. (1999). Patient care information systems and health care work: A sociotechnicalapproach. International Journal of Medical Informatics, 55(2), 87-101.

Berg, M., Langenberg, C., v.d. Berg, I., & Kwakkernaat, J. (1998). Considerations forsociotechnical design: Experiences with an electronic patient record in a clinicalcontext. International Journal of Medical Informatics, 52, 243-251.

Buur, J., & Bagger, K. (1999). Replacing usability testing with user dialogue. Communi-cation of the ACM, 42, 63-66.

Bødker, S., & Christiansen, E. (1997). Scenarios as springboards in cscw design. In G.Bowker, S.L. Star, B. Turner & L. Gasser (Eds.), Social science, technical systems,and cooperative work. Beyond the great divide (pp. 217-233). Lawrence ErlbaumAssociates.

Carroll, J.M. (Ed.) (1995). Scenario-based design: Envisioning work and technology insystem development. John Wiley & Sons, Inc.

Coiera, E. (2003). Guide to health informatics (2nd ed.). London: Arnold.Coiera, E., & Tombs, V. (1998). Communication behaviours in a hospital setting: An

observational study. BMJ, 316(7132), 673-676.Dick, R.S., Steen, E.B., & Detmer, D.E. (Eds.) (1997). The computer-based patient record:

An essential technology for health care (Revised ed.). Washington D.C.: NationalAcademy Press.

Ehn, P. (1988). Work oriented design of computer artifacts. Stockholm: Arbetslivscentrum(Swedish Center for Working Life).

EN ISO 13407:1999. London: British Standards Institution.Forsythe, D.E., Buchanan, B.G., Osheroff, J.A., & Miller, R.A. (1992). Expanding the

concept of medical information: An observational study of physicians’ informationneeds. Computers and Biomedical Research, 25, 181-200.

Heath, C., & Luff, P. (1996). Documents and professional practice, ‘bad’ organisationalreasons for ‘good’ clinical records. Proceedings of the ACM Conference onComputer-Supported Cooperative Work.

Heath, C., & Luff, P. (2000). Technology in action. Cambridge: Cambridge UniversityPress.

Heath, C., Luff, P., & Svensson, M. S. (2003). Technology and medical practice [Specialissue]. Sociology of Health & Illness, 25, 75-96.

Horrocks, S., Rahmati, N., & Robbins-Jones, T. (1998). The development and use of aframework for categorising acts of collaborative work. Proceedings of the 32ndHawaii International Conference on System Sciences.



Hughes, J.A., Randall, D., & Shapiro, D. (1993). From ethnographic record to systemdesign. Some experiences from the field. Computer Supported Cooperative Work(CSCW), 1(3), 123- 141.

Kuutti, K. (1995). Work processes: Scenarios as a preliminary vocabulary. In J.M. Carroll(Ed.), Scenario-based design: Envisioning work and technology in system devel-opment (pp. 19-36). John Wiley & Son, Inc.

Muller, M. J. (2002). Participatory design: The third space in HCI. In J.A. Jacko & A. Sears(Eds.), The human-computer interaction handbook: Fundamentals, evolvingtechnologies and emerging applications. Lawrence Erlbaum Associates.

Patel, V.L., & Kushniruk, A.W. (1997). Human-computer interaction in health care. In J.H.v. Bemmel & M.A. Musen (Eds.), Handbook of medical informatics. Heidelberg:Springer-Verlag.

Reddy, M., Pratt, W., Dourish, P., & Shabot, M.M. (2003). Sociotechnical requirementsanalysis for clinical systems. Methods of Information in Medicine, 42(4), 437-444.

Schneider, K., & Wagner, I. (1993). Constructing the ‘dossier représentatif’. Computer-based information-sharing in French hospitals. Computer Supported CooperativeWork (CSCW), 1, 229-253.

Sicotte, C., Denis, J.L., & Lehoux, P. (1998). The computer based patient record: Astrategic issue in process innovation. Journal of Medical Systems, 22(6), 431-443.

Strauss, A.L., Fagerhaug, S., Suczek, B., & Wiener, C. (1997). Social organization ofmedical work. New Brunswick: Transaction Publishers.

Svanæs, D., & Seland, G. (2004). Putting the users center stage: Role playing and low-fi prototyping enable end users to design mobile systems. Paper presented at theConference on Human Factors in Computing Systems, Vienna, Austria.

Symon, G., Long, K., & Ellis, J. (1996). The coordination of work activities: Cooperationand conflict in a hospital context. Computer Supported Cooperative Work (CSCW),5(1), 1-31.

Sørby, I. D., Melby, L., & Nytrø, Ø. (In press). Characterizing cooperation in the ward:A framework for producing requirements to mobile electronic healthcare records.International Journal of Health Care Technology and Management.

Sørensen, C.F., Wang, A. I., Le, H.N., Ramampiaro, H., Nygård, M., & Conradi, R. (2002).The MOWAHS Characterisation framework for mobile work. Proceedings of theIASTED International Conference on Applied Informatics, Innsbruck, Austria.

Endnote

1 The project includes members from Department of Computer and InformationScience, Department of Sociology and Political Science, Department of Telecom-munications, Department of Linguistics, and the Faculty of Medicine at NTNU.MOBEL was initiated in 1999 and since 2003 has been part of the Norwegian Centrefor Electronic Patient Records (NSEP) in Trondheim.

284 Kerkow, Dörr, Paech, Olsson and Koenig


Chapter XVII

Elicitation andDocumentation ofNon-Functional

Requirements forSociotechnical SystemsDaniel Kerkow, Fraunhofer Institute for Experimental Software Engineering, Germany

Jörg Dörr, Fraunhofer Institute for Experimental Software Engineering, Germany


Thomas Olsson, Fraunhofer Institute for Experimental Software Engineering, Germany

Tom Koenig, Fraunhofer Institute for Experimental Software Engineering, Germany

Abstract

This chapter describes how non-functional requirements (NFR) can be elicited anddocumented in the context of sociotechnical systems. An approach is presented basedon use cases and on quality models derived from ISO 9126, as well as general problemsand challenges when working with NFR. Requirements in general and NFR inparticular are subjective, have many stakeholders and are often conflicting. Theapproach presented includes processes for prioritizing quality attributes that areimportant to a specific context, eliciting NFR, and identification and analysis of

Non-Functional Requirements for Sociotechnical Systems 285


dependencies among the NFR. The aim is to provide an experience-based approachthat facilitates efficient and effective elicitation and documentation of NFR. Having astructured method that aims at providing measurable, traceable, and focusedrequirements rather than having ad-hoc and ambiguous ones achieves this. Theapproach uses use cases as the main technique, though the general principle of havinga structured and experience-based process is applicable to other techniques as well.

Introduction

Technology and the interfaces between technical devices and the persons using themare becoming a natural part of our life. The only time they are consciously thought aboutis when they fail to meet our expectations, for example, a person wants to send amultimedia message via a cell phone, but it takes too long and there is a time-out on theconnection. The time it takes to send the multimedia message confronts the user withefficiency issues. The number of selections required to find a function confronts userswith usability issues, and the need to install updates to get a new dictionary confrontsthem with maintainability issues. All these issues must live up to the users’ goals andexpectations. If these expectations are not fulfilled, the users will be unsatisfied with theproduct, perhaps making it useless or even dangerous for them. While some issues onlyhave an impact on the users’ perception of comfort, there are issues that have a moresevere impact on the users or on their environment. A financial transaction, for example,is very sensitive to security issues.The term “sociotechnical” refers, in the examples above, to the interaction of humans (theusers) with a technical device during the usage of a system. This has, of course, an impacton the system development process as well as on the processes in which the softwareis being used. During development there are many decisions to be made with respect tothe environment of the software, the software itself, and the software developmentprocess. These decisions not only depend on the users’ expectations but also on theinterests of other stakeholders, such as developers or procurers. Thus it is very importantfor the requirements engineering activities that these expectations and interests areelicited thoroughly. In this chapter we discuss issues in the elicitation and documenta-tion of so called Non-functional Requirements (NFR), which essentially cover allconstraints on how a system should achieve its functionality (Kitchenham & Pfleeger,1996, Menasce, 2001). The ISO Standard 9126 (2001) proposes the following taxonomy:

• Efficiency: The capability of the software product to provide appropriate perfor-mance, relative to the amount of resources used, under stated conditions.

• Portability: The capability of the software product to be transferred from oneenvironment to another.

• Maintainability: The capability of the software product to be modified. Modifica-tions may include corrections, improvements, or adaptations of the softwareproducts to changes in environment and in functional specifications.



• Functionality1: The capability of a software product to provide functions that meetstated and implied needs when the software is used under specified conditions.

• Usability: The capability of the software product to be understood, learned, used,and to be attractive to the user when used under specified conditions.

• Reliability: The capability of the software product to maintain a specified level ofperformance when used under specified conditions.

There exist several different definitions for NFR. Chung, Nixon, Yu, & Mylopoulos (2000)define an NFR as: “... in software system engineering, a software requirement thatdescribes not what the software will do, but how the software will do it, for example,software performance requirements, software external interface requirements, softwaredesign constraints, and software quality attributes. NFR are difficult to test; therefore,they are usually evaluated subjectively.” This definition is quite fuzzy. It mainly givesexamples of types of NFR but fails to classify of them. Loucopoulos & Karakostas (1995)present one possible classification of NFR. They distinguish between process, product,and external requirements. Product requirements specify the desired characteristics interms of quality attributes such as performance and security. Process requirements areconstraints on the development process. External requirements are requirements thatarise from external sources, either within the company or outside. While working withvarious kinds of NFR, we experienced that this classification is not sufficient, in particularfor products requirements. The ISO Standard 9126 (2001) gives a detailed classificationon product requirements (see section below on basic concepts). However it does not givespecific guidelines on how to specify or elicit the different NFR.The rest of the chapter is structured as follows: In section 2, we introduce basicterminology and discuss related work with respect to NFR. The challenges of require-ments engineering for NFR are discussed in the next section. Our method and itsapplication in a case study are presented in the section on eliciting and documentingNFR. In the following section we present lessons learned from applying the techniques.We end with some ideas on future research and a conclusion.

Basic Concepts

Figure 1 shows a meta-model in which all the concepts of a method that meet thechallenges of elaborating NFR are described.Requirements can be functional, architectural, or non-functional. Functional require-ments are concerned with tasks performed by the user or by the system. Architecturalrequirements constrain the system (or more precisely, the architecture of the system).NFRs concern the organization or tasks of two types: user tasks and system tasks. Usertasks are tasks a certain user performs. They are supported by the system (for example,“monitoring of certain machines”) and include user involvement. System tasks are tasksthe system performs. In contrast to user tasks, these tasks do not involve the user. Taskscan be refined into sub-tasks. Organization refers to what Loucopoulos & Karakostas



(1995) call external- and process-related NFR. Optimizing software engineering pro-cesses or adhering to external standards, for example, can improve the quality of asoftware product. This does not directly affect software artifacts but has to be elicitedduring the requirements engineering process.To support continuous and experience-based reuse, we distinguish quality attributesfrom NFR. A quality attribute (QA) is an abstract and reusable non-functional charac-teristic. The distinction between different types of quality attributes is important for ourelicitation process. Each type of quality attribute is elicited differently. QA can be refinedinto further QA. In addition they can have positive or negative influences on each other.An NFR describes a certain value (or value domain) for a QA that should be achievedin a specific project. To ensure measurable NFR it is necessary to determine a value fora metric associated with the QA. For example, the NFR “The database of our new systemshall handle 1,000 queries per second ” constrains the QA “workload of database.” Thevalue is determined based on an associated metric “Number of jobs per time unit.” Foreach NFR a rationale states reasons for its existence.A means is a solution-oriented pattern to achieve a certain set of NFR. In many cases ameans describes an architectural option for the system to achieve a certain QA (forexample, “load balancing” is used to achieve a set of NFR concerning the QA “workloaddistribution”). However a means can also be process-related (for example, “automatictest case generation” can be used to fulfil (NFR with respect to reliability).

Figure 1. The Meta-model

Requirement

Functional Requirement

Non-functional Requirement

Architectural Requirement

Organization

Task

System

Quality Attribute

OrganizationQuality Attribute

SystemQuality Attribute

User TaskQuality Attribute

Means

ValueMetric Rationale

User Task System Task

SystemTaskQuality Attribute

1

*

1

*

1

*

1

*

1

1..*

describes

1

2..*

refined into

1..*

1..*

justifies

*

*

constrains

1 *

constrains

1

*

measured by

1 1..*

determines

1

1..*

* *

achieved by

*

*has influence on1

*

refined into*

*

influences

1*

refined into



Problems and Challenges

A typical challenge in dealing with NFR is that users perceive the quality of a productdifferently and that they have different expectations. These expectations are subjectiveand often expressed through NFR.Besides the user of a system, there are more stakeholders, like customers, suppliers,developers, and marketing. Requirements elicited from different sources are often inconflict with each other. For example, domain experts for various types of NFR frequentlyidentify problems in the realization of requirements phrased by a naïve user. Gross & Yu(2001) particularly support the customer with their method to relate business goals toarchitecture. Chung et al. (2000) developed the first comprehensive framework thatdescribes relationships between NFR in the ’90s. The NFR framework, including the soft-goal notation, provides detailed guidance on how to refine NFR (called soft-goals) andhow to denote relationships between the NFR. As the focus is on refinement, no detailedelicitation support or support for documenting NFR as part of a requirements documentis given.The intertwined nature of NFR is what makes them special. Considering the impact of NFRon FR and Architectural decisions (AD) as early as possible without forcing early designdecisions, and finding the right point in time and a suitable way to treat all three of themtogether, is an important issue. Abowd, Bass, Clements, Kazman, Northrop, & Zaremski(1997); Barbacci, Klein, & Weinstock (1997); Bass, Clements, & Kazman (1998); and Shaw& Garlan (1996) discuss various approaches to coping with architectural issues in detail.Approaches exist that consider the dependencies between NFR and FR (Alexander, 2001;Firesmith, 2003; Petriu & Woodside, 2002; Sindre & Opdahl, 2000; Sutcliffe & Minocha,1998) and between FR and architecture (Clements, Bass, Kazman, & Abowd, 1995; Egyed,Grünbacher, & Medvidovic, 2001; In, Kazman, & Olsson, 2001; Liu & Yu, 2001),respectively. Cysneiros & Leite (2001) describe an approach that combines NFR and usecases (Cockburn, 2001). Use cases and NFR are elicited separately and are then combinedto make sure that the use cases satisfy the NFR.Methods such as the Software Architecture Analysis Method (SAAM) (Bass et al., 1998;Clements et al., 1995) and the Architecture Trade-off Analysis Method (ATAM) (Kazman,Klein, & Clements, 1999) combine NFR with AD. Both are scenario-based methods forarchitecture analysis. The goal of SAAM is to identify whether a software architecturesatisfies its modifiability requirements expressed through scenarios. The outcome ofATAM is the risk that results from conflicting requirements and from requirements thathave not been addressed in the architecture. Experiences with SAAM in case studies arepresented in Kazman, Bass, Abowd, & Webb (1994) and Kazman, Abowd, Bass, &Clements (1996). Neither method helps to elicit measurable NFR in an early phase, butboth are based on a set of scenarios. However, in practice, the elicitation of NFR, FR,and AD has to be intertwined (Moreira Brito, & Araújo, 2002; Paech, Dutoit, Kerkow, &von Knethen, 2002; Paech, von Knethen, Doerr, Bayer, Kerkow, Kolb, Trendowicz,Punter, & Dutoit, 2003).NFR are not only related to AD and FR, they also have internal dependencies (forexample, performance and maintainability) that have to be detected and handled. It is a



challenging issue to find all these dependencies as well as solutions to overcomeconflicts.NFR are very project-specific and hardly reusable as such. Thus specific measures areneeded to support experience transfer between different projects. This becomes evenharder due to the fact that NFR are often expressed vaguely and not in a quantitative way.This often gives rise to misunderstandings. For the importance of experience manage-ment, consult Basili & Rombach (1988) and Basili (1992). Klein & Kazman (1999) providea framework for organizing the existing knowledge about quality attributes and about theeffects of architectural design decisions on the quality attributes of a software system.Similar to the approaches above and to many other approaches (for example, Gross & Yu,2001; Liu & Yu, 2001), we use goal graphs for dependencies and refinement. However weuse goal graphs for capturing the relationships between categories of NFR such asefficiency and maintainability but not for the actual NFR. The actual NFR are capturedas part of requirements documents intertwined with FR and AD. This avoids the need todevelop complicated dependencies in each project anew. Furthermore it supportscoherent documentation of NFR, FR, and AD.Another challenge that is underrepresented in the literature is the effort spent on NFR:Typically, there are not enough resources to elicit all NFR equally well.In general one can say that current approaches for dealing with NFR provide a frameworkfor thinking about NFR, but they are no help for many practical problems emerging duringsoftware development. In the following we elaborate on these practical issues and showhow to alleviate these problems through general principles such as checklists andtemplates or iterative development.

Eliciting and Documenting NFR

In this section we present methods and techniques to tackle the issues identified in theprevious section. First we discuss how the concepts presented in the section on basicconcepts help to deal with the challenges of the problems and challenges section. Wealso give an overview of the main artefacts. Then we discuss in detail the activities foreliciting and documenting NFR.

Addressing the Challenges

Based on the concepts of the meta-model presented in the basic concepts section we canaddress the above-mentioned challenges:

• Quality is a subjective concept. To elicit and communicate the latter, we integrateall stakeholders in elicitation workshops. Furthermore our distinction into organi-zation, user task, system task, and system QA helps to clarify different views (forexample, users rather think of user task requirements while developers think of



system task requirements). Artefacts such as checklists, templates, and experi-ence-based quality models support an interactive and structured way of commu-nication. (IEEE Std. 830, 1998)

• To enable stakeholders to identify the most important NFR in a specific context,we use a standardized questionnaire to prioritise NFR.

• In order to be able to consider the impact of NFR as early as possible, we apply ourmethod on artefacts available in an early stage of the requirements engineeringprocess.

• In order to be able to manage NFR in a generic and reusable way, we create qualitymodels based on QA and phrase instances of the QA (the NFR) within therequirements document.

• We capture general dependencies in an experienced-based quality model and in therationale of the NFR. This helps to systematically identify and avoid conflictingrequirements (compare Dutoit & Paech, 2001).

• To cope with the challenge that NFR are intertwined with FR and AD, we proposeto stick to common practices such as iterative development. We present a methodthat integrates several artefacts into a refinement process that iteratively adds moreand more information and results in a complete collection of NFR.

• To prevent stakeholders from providing vague NFR, we require the usage ofmetrics. The metrics to be used are also captured in the quality model.

Overview of the Artefacts.

Figure 2 shows the main artefacts used and produced in our method. A (prioritisation)questionnaire is used to focus the elicitation and documentation process. This question-naire asks questions about goals and context of the current project and recommends themost important QA. Reference (quality) models, checklists, and templates are used as astarting point. These are then tailored to specific project contexts. The reference (quality)model represents the refinement of each of the QA mentioned in the introduction. It isbased on the definitions from ISO 9126 and captures the semantic knowledge about theconstruct of a high-level QA.To create the tailored, project-specific artefacts quality model, template, and checklist,the following steps are necessary:

1. Select QMs: QA should be prioritised. Therefore a prioritisation questionnaire isused. The result is a prioritised selection of the most critical quality models for theproject.

2. Tailor Quality Model: Starting with the most important QA, a common definitionamong the stakeholders has to be found. Therefore, the process prescribes a focusgroup workshop in which representatives from all stakeholder groups participate.As an input for the discussion, the participants use the reference model. Every QAof the reference model has to be defined and the relevance for the current product,



project, or organization has to be discussed. The result is a set of tailored qualitymodels. An example for a tailored quality model is given in Figure 3.

3. Identify Dependencies: There exist dependencies between QA. These dependen-cies have been elicited and collected through literature studies and projectexperience, and they are represented in the reference QM. If the participants of theworkshop foresee further dependencies, especially for those QA added during theworkshop, they add these to the QM. Dependencies between QA of different QMshould also be captured. The result is a dependency list.

4. Derive checklists/templates: To facilitate further activities in the process, check-lists and templates are created based on the information captured in the QM. QAalways have to be refined keeping the project and the usage context in mind.Therefore average and worst-case scenarios as well as further assumptions (forexample, about the system architecture) serve as input for the checklist.

The process described above makes it possible to build a common understanding of therequired quality of a system and prepares the elicitation and documentation activities.The latter again foresee a focus group workshop with the stakeholders of the futuresystem involved, which is described in detail the next section.

Figure 2. Overview of the artefacts involved in the process

Qualitymodel

Identifydependencies

R eference model

Checklist

Derivecheck lists/ template

T ailorQualityModel

T emplate

Questionnaire

S electQMs

Reference template

R eference check lists

T ailored, project-specific artifacts

Experience-based artifacts

Improved withproject experience

Qualitymodel

Identifydependencies

R eference model

Checklist

Derivecheck lists/ template

T ailorQualityModel

T emplate

Questionnaire

S electQMs

Reference template

R eference check lists

T ailored, project-specific artifacts

Experience-based artifacts

Improved withproject experience



Elicitation and Documentation of NFR

In the following we describe the activities to be performed within the elicitation anddocumentation process. We use examples from a case study of a wireless framework formobile services called CMWE. The application enables up to eight users to monitorproduction activities, manage physical resources, and access information within amanufacturing plant. The user can receive state data from the plant on his or her mobiledevice, send control data from the mobile device to the plant components, position themaintenance engineer, and get guidance on fixing errors on machines.The elicitation process uses the available project documentation. These are typically:

• the system functionality (behaviour), preferably described by use cases (UC),• the physical architecture and further implementation constraints (for example,

constrained hardware resources or constraints derived from the operating sys-tems),

Figure 3. Example for a tailored quality model (efficiency)

Usage Time

Efficiency Compliance Time Behaviour

Throughput (network) Response Time

Resource Utilisation

Capacity

Workload Distribution Type and position

of devices Boot / Start Time Workload

Locality Parallelism

Load Balancing

Mbit /sec. #jobs / time unit

% of resource consumption

Cost / unit

Experience Required Documentation

Efficiency

Quality Attribute

Quality Attribute

Quality Attribute

System Quality Attribute

System Task Quality Attribute

User Task Quality Attribute

Quality Attribute Developer View

Metric Means

Quality Attribute Customer View

Quality Attribute Organization Quality Attribute

Usage Time

Efficiency Compliance Time Behaviour

Throughput (network) Response Time

Resource Utilisation

Capacity

Workload Distribution Type and position

of devices Boot / Start Time Workload

Locality Parallelism

Load Balancing

Mbit /sec. #jobs / time unit

% of resource consumption

Cost / unit

Experience Required Documentation

Efficiency

Quality Attribute

Quality Attribute

Quality Attribute





Metric Means



Quality Attribute

Quality Attribute

Quality Attribute





Metric Means





• assumptions about the average and worst-case usage scenarios of the system, and• a user model.

We distinguish between different elicitation activities: organizational NFR elicitation,user task NFR elicitation, system task NFR elicitation, and system NFR elicitation.A checklist that is derived from the quality model guides each activity.Figure 4 shows the activity that elicits NFR that constrain QA of the organization. Thechecklist suggests thinking about domain experience, size, structure or age of thesupplier organization, as well as required standards (e.g., RUP), activities (for example,inspections), documents, or notations (for example, statecharts). In the case study someof the requirements expressed were:

• “The supplier needs at least three years of experience in the domain of mobiledevices.“

• “The supplier has to create a specification document.”

To avoid premature requirements, the stakeholders are instructed to scrutinize the NFRagain, just like Socrates would try to get to the bottom of statements over and over. Thisform of Socratic dialogue serves to uncover the rationale behind that NFR and preventsthe customer from constraining the system unnecessarily. NFR are reformulated untilthey reflect the rationale.In the “elicit user task NFR” activity (see Figure 5), NFR for user task QA are documentedfor each use case included in the use case diagram, because each use case representsa user task. In order to support the specific needs of the users of the system a user modelis needed that describes the potential users and their characteristics. As shown in Figure6 NFR are added to use cases with the help of notices. In our case study the requirement“the use case shall be performed within 30 min.” was attached to the use case “handlealarm.” Again a justification as described above is performed to prevent prematuredesign decisions. The resulting rationale “breakdown of plant longer than 30 min is tooexpensive” is documented in parenthesis behind the NFR. The elicitation of NFR related to system task QA (see Figure 7) is based on the detailedinteraction sequence (also called flow of events) documented in the use case (see Figure

Figure 4. Activity “Elicit organizational NFR”



Figure 5. Activity “Elicit user task NFR”

Figure 6. Use Cases with attached user task NFR

8) and specific characteristics of potential users, described in a user model. For thisactivity maximum and average usage scenarios are needed. With these scenarios in mindevery step and every exception described by the use case description is checked.Figure 8 shows the textual description of the use case “handle alarm.” It describes thatthe system indicates an alarm and the location where it was produced. As reaction to thisthe user acknowledges the alarm, so other users know he or she is taking care of it. TheNFR “at least in 5 sec.” was attached to the use case step two “System shows alarm andwhere the alarm was produced,” and the NFR “just one click” was attached to the user’sreaction described in use case step three. Both requirements were documented in the NFRfield within the textual description of the use case, after being justified by the customerin the Socratic dialogue. The rationale led to the statement that the NFR elicited were only



Figure 7. Activity “Elicit system task NFR”

Figure 8. UC steps with attached system task NFR

estimated times and could be changed, if necessary. As shown in Figure 8, the rationalewas documented in parenthesis.In the “elicit system NFR” activity (see Figure 9) NFR are elicited that constrain QA ofthe system and subsystems. In this activity maximum and average usage scenarios areneeded again. Additionally a user model and the architecture of the physical subsystemsare used, if available. The subsystems and architecture constraints on our case study areshown in Figure 10.



As Figure 11 shows, the NFR field of the use case description is segmented into NFRrelated to every physical subsystem. In the use case “handle alarm” NFR for the QA“capacity” could only be phrased for the physical subsystem “PDA.” The subsystemshall have a maximum capacity of 64 MB and shall be able to handle up to 50 alarms atthe same time. The rationale for this NFR is the need for usage of standard componentsavailable on the consumer market. This rationale is documented as well. The QA“throughput” does only apply to the subsystem “Network” by definition. Our experienceshows that some QA are related to only one subset of subsystems. This relationship isdocumented in the quality model.The elicited NFR for single subsystems are documented within the textual use casedescription as well as in the section “use case overspanning textual description of NFR.”This is done in order to be able to consolidate the requirements across several use cases.Finally the NFR are analysed for conflicts. This activity includes two sub-activities. Inthe first NFR for one physical subsystem are analysed across all use cases. The checklistgives hints on how to identify conflicts and how to solve them. It has to be checked, forexample, whether NFR can be achieved if use cases are executed in parallel. In the secondsub-activity NFR that constrain different QA are validated taking into consideration thedependencies documented within the quality model.

Figure 9. Activity “Elicit system NFR”

Figure 10. Constraints on system architecture

Constraints on overall architecture:

W indows CE OS at PDAsStandard PDAs (replace ab le)Standard Network Components (replaceable)Throughput: WLAN 11MBit/secServer: Windows 2000Secondary Database -> PDAs: Wireless Network requiredDownloading and Monitoring at the same time is not possible



In the case study this activity discovered an important conflict between the determinedthroughput requirements and the defined hardware constraints. As shown in Figure 11,one of the throughput requirements stated:“The network between secondary database and PDA shall be able to deal in the worstcase with 8 people that download 1 doc (size of 8 docs constrained to <55Mbit) / personwithin 5-10 seconds.”The restriction of the total size of 8 documents to 55 Mbits was added because thehardware constraints shown in Figure 10 constrained the network to an 11Mbit/secWLAN. The additional requirement would not have been found without the consolida-tion activity.

Experiences

So far we have used this approach in a case study with a large German company in thedomain of embedded systems and in an industrial workshop with 10 practitioners fromvarious enterprises. In the case study the domain expert (customer) filled out theprioritisation questionnaire to find out the three most important high-level qualityattributes to spend the effort on. Then we spent half a day with the customer in discussingand tailoring the default quality model to the case study project and half a day in elicitingthe NFR. In the industrial workshop we spent one hour explaining our method and then,within another two hours, we interactively went through the checklists and filled thetemplate with NFR.

Prioritisation Questionnaire

The prioritisation questionnaire was used in the case study. Only the quality attributesmaintainability, efficiency, reliability, and usability are currently supported by the

Figure 11. Excerpt of a UC with attached system NFR

Throughput requirements:Network between secondary database and PDA:•Shall be able to deal in average case with 2 alarms every 10 minutes with 16 machines (assumed average numbers of alarms)•Shall be able to deal with maximal 8 (1/PDA)*60 alarms at the same time assumed maximal number of alarms)•Shall be able to deal with maximal 8 people that download 1 doc (size of 8 docs constrained to: <55MBit)/person within 5-10 secs (assumed maximal number of downloads)

Capacity requirements:PDA:•Shall have a maximum capacity of 64 MB (standard components shall be used to reduce costs)•Shall be able to handle up to 60 alarms at the same time (assumed maximal number of alarms)

Workload requirements:PDA:•Shall allow 5 programs to be opened at the same time (assumed maximal number of programs that will be opened by the user)



questionnaire. This was due to the fact that these were the quality attributes of interestfor the case study.The prioritisation questionnaire performed very well. The order of prioritisation of thehigh-level quality attributes conformed to the expert judgement from experienceddevelopers of the manufacturing plant in our case study. Nevertheless the validity of theprioritisation questionnaire has to be strengthened by more case studies. Other qualityattributes (for example, portability) should be integrated for future use.

Workshop for Tailoring the Quality Models

The goal of the moderated workshop was to come up with quality models for the mostimportant quality attributes. During the workshop quality models for the quality at-tributes efficiency, maintainability, and reliability were developed based on the referencequality models, taking into account the specific characteristics of the project andenterprise. As a first step the reference quality models were evaluated with respect totheir appropriateness for the given project context. Then they were iteratively refined andadapted. To direct the discussions the architecture and functional requirements (in theshape of Use Cases) were used. The results of the workshop were consolidated offlineand finally documented.It was shown that the moderated workshop worked very well for developing project-specific quality models. The decision to start from an existing reference quality model hasproven to be more efficient than starting from scratch. However the workshop containedphases where information retrieval took quite long or where too much information cameat one time. The former was due to the fact that it is not easy for a domain expert to thinkof all important quality attributes, especially if ISO 9126 and the initial quality model werenot sufficiently detailed. In the latter case the domain expert has a good grasp on aparticular quality attribute and offers a lot of information, which makes it difficult tomaintain a hold on all of it. In addition to the resulting quality models the moderatedworkshop also created a common ground for the NFR elicitation, as the workshopparticipants (customer and workshop moderator) created a common understanding of thequality attributes’ meaning. The workshop resulted in quality models of good quality.The hypothesis that there is no general-purpose quality model but that the quality modelis dependent on the actual project and its characteristics, was confirmed.

Workshop for Elicitation of NFR

The elicitation of NFR for the three most important quality attributes took place with theexpert of the customer company. We used the different types of checklists derived fromthe quality models to guide him through the elicitation process.The elicitation of NFR in the workshop was successful. New NFR, which were notincluded in the original specification, were elicited. These new NFR were judged by thedomain expert to be necessary for the development of the system. Furthermore thedomain expert acknowledged that the time for elicitation was worthwhile. Also capturing



the rationale behind the NFR proved to be useful for a better understanding of the NFRduring later discussions on the NFR. Unfortunately rationales were only captured for afew NFR because of a lack of time in the workshops. Furthermore some NFR were notexpressed measurably. This was mostly not due to imprecise questions in the question-naire but rather to inconsequent usage of the questionnaire, for example, the moderatorshould have asked for a more precise statement from the customer.

Overall Impression

Concerning the case study the customer acknowledged that the time was very worthwhileas he discovered many new NFR he had not been aware of before. Also it helped him tospecify them more precisely. In the industrial workshop the feedback was also verypositive, as the participants acknowledged that this was the first systematic method theyhad seen to elicit efficiency NFR. They particularly liked the idea of the quality model,checklists, and template to capture experience on NFR. In addition they liked the use ofuse cases and the architecture to ensure completeness and facilitate traceability. Theyalso pointed out the need for capturing the rationale and a supporting tool environment.

Summary and Future Work

The presented approach deploys an intertwined refinement of NFR and Use Cases. UseCases are a standard notation to specify functionality, but there are also many enterprisesthat do not employ use cases. Therefore it is worth investigating how the approach canbe used with different functional specifications, like plain and structured text or graphicalnotations such as sequence diagrams.Especially for enterprises using the approach in several projects, it would be inefficientto execute the complete preparation phase for each project. Therefore the preparationphase should be designed in a way to satisfy a multi-project context. It is a challenge tofind the commonalities and variabilities for the various sociotechnical systems, statedby the variety of involved stakeholders, to come to a valid quality model.Concerning the moderation of the workshops to tailor the quality models and to elicit theNFR, it would be worthwhile to analyse the suitability of tools to support an onlinediscussion of distributed stakeholders or offline negotiation via groupware (compare Inet al., 2001).The presented approach gives a comprehensive method on how to elicit NFR on ameasurable level. Interesting research will be in the field of detailing the experience-basedreference quality models for the various quality attributes. Their maturity is a key factorfor having a set of NFR that is as complete as possible.Eliciting the expectations on a software system is a difficult task. This becomes even moredifficult when the NFR are taken into account. A method for eliciting and specifying NFRwas presented in this chapter. It has several important characteristics: Eliciting is a



human-intense activity – we take this into account by providing support for requirementsengineers in the form of checklists and reference models. These artefacts help therequirements engineer to elicit a complete set of NFR. Of course completeness and costare always subject to a compromise – this compromise is dealt with through havingexplicit prioritisation of QA.Another important issue we had to consider is that every situation is different – eventhough we provide reference models, tailoring these to specific situations and environ-ments is indispensable.Experience is important but often forgotten. In our quality models, we capture theexperience from the community at large. By tailoring the quality models, a company cancapture its experience in adaptations of the models. Experience capture is of specialimportance when software systems are large, complex, and contain many dependencies.By providing a comprehensive meta-model, we support documentation, traceability, andchange management, that is, activities that become difficult when the system underdevelopment grows.

Acknowledgments

This project has been funded by the German BMBF in the context of the ITEA projectEmpress. We thank all our project partners and, in particular, the case study participantsfor valuable discussion and feedback.

References

Abowd, G., Bass, L., Clements, P., Kazman, R., Northrop, L., & Zaremski, A. (1997).Recommended best industrial practice for software architecture evaluation.(CMU/SEI-96-TR-025). Pittsburgh, PA: Carnegie Mellon University, SoftwareEngineering Institute.

Alexander, I. (2001). Misuse case help to elicit nonfunctional requirements. IEE CCEJ.Barbacci, M.R., Klein, M.H., & Weinstock, C.B. (1997). Principles for evaluating the

quality attributes of a software architecture. (CMU/SEI-96-TR-036). Pittsburgh,PA: Carnegie Mellon University, Software Engineering Institute.

Basili, V.R. (1992). Software modeling and measurement. The goal/question/metricparadigm. Computer Science Technical Report Series NR: CS-TR-2956 / NR:UMIACS-TR-92-96.

Basili, V.R., & Rombach, H.D. (1988). The TAME project: Towards improvement-orientedsoftware environments. IEEE Transactions on Software Engineering, 14(6), 758-773.



Bass, L., Clements, P., & Kazman, R. (1998). Software architecture in practice. Addison-Wesley.

Chung, L., Nixon, B.A., Yu, E., & Mylopoulos, J. (2000). Non-functional requirementsin software engineering. Kluwer Academic Publishers.

Clements, P., Bass, L., Kazman, R., & Abowd, G. (1995). Predicting software Quality byarchitecture-level evaluation. Proceedings of the Fifth International Conferenceon Software Quality.

Cockburn A. (2001). Writing effective use cases. Addison Wesley.Cysneiros, L.N., & Leite, J.C.S.P. (2001). Driving non-functional requirements to Use

cases and scenarios. Proceedings of XV Brazilian Symposium on SoftwareEngineering.

Dutoit, A.H., & Paech, B. (2001). Rationale management in software engineering. In S.K.Chang (Eds.), Handbook of software engineering and knowledge engineering.World Scientific.

Egyed, A., Grünbacher, P., & Medvidovic, N. (2001). Refinement and evolution issuesin bridging requirements and architecture – the CBSP approach. Proceedings ofInternational Conference on Software Engineering-Workshop STRAW.

Firesmith, D. (2003). Security use cases. Journal of Object Technology, 2(3), 53-64.Gross, F., & Yu, E. (2001). Evolving system architecture to meet changing business goals:

An agent and goal-oriented approach. Proceedings of International Conferenceon Software Engineering-Workshop STRAW.

IEEE Recommended Practice for Software Requirements Specifications, IEEE Std. 830-1998.

In, H., Boehm, B.W., Rodgers, T., & Deutsch, W. (2001). Applying winwin to qualityrequirements: A case study. International Conference on Software Engineering,555-564.

In, H., Kazman, R., & Olson, D. (2001). From requirements negotiation to softwarearchitectural decisions. Proceedings of International Conference on SoftwareEngineering-Workshop STRAW.

ISO/IEC 9126-1. (2001). Software Engineering - Product Quality - Part 1: Quality Model.Kazman, R., Abowd, G., Bass, L., & Clements, P. (1996). Scenario-based analysis of

software architecture. IEEE Software, 13(6), 47-55.Kazman, R., Bass, L., Abowd, G., & Webb, M. (1994). SAAM: A method for analyzing

the properties of software architectures. Proceedings of the 16th InternationalConference on Software Engineering, 81-90.

Kazman, R., Klein, M., & Clements, P. (1999). ATAM: Method for architecture evaluation.(CMU/SEI-2000-TR-004). Pittsburgh, PA: Carnegie Mellon University, SoftwareEngineering Institute.

Kitchenham B., & Pfleeger S.L. (1996). Software quality: The elusive target. IEEESoftware, 12-21.

Klein, M., & Kazman, R. (1999). Attribute-based architectural styles. (CMU/SEI-99-TR-022). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute



Liu, L., & Yu, E. (2001). From requirements to architectural design – Using goals andscenarios. Proceedings of International Conference on Software Engineering-Workshop STRAW.

Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering. McGraw-Hill.

Menasce, D.A. (2002). Software, performance or engineering. Proceedings of Workshopon Software and Performance, 239-242.

Moreira, A., Brito, I., & Araújo, J. (2002). A requirements model for quality attributes,early aspects: Aspect-oriented requirements engineering and architecture design.Proceedings of International Conference on Aspect-Oriented Software Develop-ment, Enschede, Holland.

Paech, B., Dutoit, A., Kerkow, D., & von Knethen, A. (2002). Functional requirements,non-functional requirements and architecture specification cannot be separated –A position paper. Proceedings of International workshop on RequirementsEngineering for Software Quality.

Paech, B., von Knethen, A., Doerr, J., Bayer, J., Kerkow, D., Kolb, R., Trendowicz, A.,Punter, T., & Dutoit, A. (2003). An experience based approach for integratingarchitecture and requirements engineering. Proceedings of International Confer-ence on Software Engineering-Workshop STRAW.

Petriu, D., & Woodside, M. (2002). Analysing software requirements specifications forperformance. Proceedings of Workshop on Software and Performance, 1-9.

Shaw, M., & Garlan, D. (1996). Software architecture – Perspectives on an emergingdiscipline. Prentice Hall.

Sindre, G., & Opdahl, A. (2000). Eliciting security requirements by misuse cases.Proceedings of TOOLS Pacific 2000, 120-131.

Sutcliffe, A., & Minocha, S. (1998). Scenario-based analysis of non-functional require-ments. Proceedings of Workshop on Requirements Engineering For SoftwareQuality.

Endnote

1 Functionality is, in fact, the label of a set of NFR in the ISO standard. It is definedby the sub-quality aspects accuracy, compliance, interoperability, suitability, andsecurity.

Software Requirements and Rationale 303


Chapter XVIII

Capture of SoftwareRequirements andRationale through

Collaborative SoftwareDevelopmentRaymond McCall, University of Colorado, USA

Ivan Mistrik,Fraunhofer Institut für Integrierte Publikations - und Informationssysteme, Germany

Abstract

This chapter explains how natural language processing (NLP) and participatorydesign can aid in identifying system requirements. It argues that getting a complete listof requirements is often an iterative process in which some requirements are elicitedonly when users react to the system’s design. Costs of iterative requirements identificationcan be reduced by discovering new requirements during the design process, beforeimplementation begins. This is facilitated when users participate in design, reactingto features as they are proposed. As users evaluate proposals, they often mentionrequirements not previously documented. Transcripts of participatory design sessionsthus provide a rich source of new requirements for developers. The chapter explainshow semantic grammars can be used to simplify the extraction of requirements from such

304 McCall and Mistrik


transcripts. The authors hope that an understanding of the value of participatorydesign and NLP will aid in the creation of better tools for support of softwaredevelopment.

Introduction

One of the main reasons that contemporary software projects are so difficult is that, bythemselves, software developers do not have all the knowledge they need to createeffective systems. The so-called “thin spread of application knowledge,” that is,developers’ poor knowledge of application domains, continues to plague the softwareindustry more than 15 years after it was first described by Curtis, Iscoe, & Krassner (1988).Much of the knowledge that developers need is in the heads of the users of the proposedsystem (Rittel, 1972). Users have expert knowledge of use situations. Unfortunately theirexpertise is often in the form of tacit knowledge rather than explicit knowledge, and theyonly have access to much of it in the context of system use (Schon, 1983). As aconsequence users typically cannot fully identify all their requirements before designof a system begins. Getting a full and accurate list of software requirements is thus nota simple, one-shot process. We argue that it is an iterative process in which some crucialrequirements are not elicited until users can react to decisions about the system’s design.Developers’ need to elicit requirements from users implies that successful projectsdepend on extensive collaboration with users. If, as we claim, some requirements can onlybe elicited when users react to design decisions, the question is then how to discoverthese requirements as soon as possible, so as to minimize the amount of work that needsto be redone. Above all, we want to identify new requirements before the system is inoperation — when implementing new requirements is most expensive by far (Grady,1999). Our conclusion is that the best approach is to get users’ reactions to the systemas it is being designed. During this sort of collaboration – which is called “participatorydesign” (Schuler & Namioka, 1993) – users typically make comments that imply newrequirements. We have devised tools that help developers identify and extract suchrequirements from user commentary.

Iteration in the Elicitation ofRequirements

Iterative Software Development

In recent years there has been a substantial movement toward iterative approaches tosoftware development in general and requirements identification in particular. The mostfull-blown set of approaches is known as “agile software development” (Highsmith,2004; Martin 2002), though variations on this are known as “evolutionary” and “adap-



tive” development (Highsmith & Orr, 2000; Larman, 2004). We will use the term iterativedevelopment as an “umbrella term” under which to group all such approaches that rejectthe waterfall model in favor of an iterative development process (except for well-definedproblem domains and strict contractual procedures).Iterative development emerged primarily from the experiences of developers working on“bleeding edge” real-world projects – for example, large-scale Internet-related applica-tions. This movement has, however, gotten backing from academic studies that indicatethat non-iterative, waterfall-based approaches produce higher rates of project failure anduser dissatisfaction (Johnson, 2002; Taylor, 2000).One common feature of iterative development is evolutionary requirements analysis,meaning that instead of restricting requirements definition to a single initial phase,requirements can be discovered and changed at later stages of development as well(Larman, 2004). We will not attempt here to restate the arguments for iterative develop-ment and evolutionary requirements analysis. Instead we will explain (1) how iterativerequirements elicitation happens, (2) how user participation promotes requirementselicitation, and (3) how natural language processing can support this process. Toaccomplish these things we will first present a model of software development as a multi-level process.

A Multi-Level Model of Software Development

A Simple, Multi-Level Model

We can define the term software specification as an explicitly stated set of goals, eachof which designates some desired program behavior. A software implementation we canthen define as that which results in achievement of the specification. The top-levelspecification is the set of software requirements and includes both desired functionalityand software quality attributes.Implementing any given goal in a specification may be either a one-step or two-stepprocess. In a one-step process code is directly written that achieves the specifiedbehavior. In a two-step process the first step is to determine what needs to be done toimplement the goal. In other words the first step is to make a more detailed softwarespecification. The second step is then to implement this new specification. Thisimplementation will in turn be either a one-step or two-step process. This recursionresults in a structure containing multiple, and increasingly specific, levels of specifica-tion and implementation. The structure terminates in the writing of code.So far there is nothing new here. We have merely described a standard means-endhierarchy generated by a process sometimes called “problem reduction.” But this is byno means the end of the story. This structure, by itself, fails to account for the elicitationof new requirements. We will therefore extend this structure to show how such elicitationoccurs.



Extending the Simple, Multi-Level Model

The model described above is simplistic in that it does not take into account the largercontext of goals of the organization to which users belong. In fact, software requirementsconstitute only a small subset of the total set of goals of an organization. Some of thesegoals are actually the reasons for the stated requirements – that is, the larger goals thatthe software requirements are meant to help achieve. Other organizational goals areexternal — or “exogenous” — to the stated set of software requirements.The larger goal context of the organization is the source both of new requirements andthe iterative process of eliciting them. To understand why, there are two crucial pointsto consider. One is that the completeness of software requirements depends on whetherthey are sufficient to achieve the higher-level goals of the organization. The othercrucial point is that it is not safe to assume that the implementation of softwarerequirements has no impact on the exogenous goals in the organization. In fact suchimpacts can result in the incorporation of previously exogenous goals as new require-ments for the software. We will explain and illustrate these points with examples from ourempirical studies of user reactions to developers’ design decisions. In particular we willuse examples of interactions between developers and users in a project aimed at thecreation of software to support collaborative design by architects (building designers)and their clients.

Completeness of Requirements

New requirements can get elicited when it turns out that the original set of requirementsis incomplete for accomplishing a work task. In designing the collaborative designsoftware for architects the developers had originally identified a set of requirements fora group of people in different locations to draw collaboratively while communicatingverbally. These requirements were correct but incomplete in several crucial ways. Forexample, in reacting to a proposed system design, a user informed the developers thattheir software would not adequately support productive design collaboration. To dothat, he said, the system would also need to support the sequential presentation of theverbal and graphical information that constituted a design proposal. In other wordswhat was required was something like the slide-show capability of PowerPoint. Accord-ing to the user this was needed because collaborative design discussions typically beginwith someone presenting their work in a pre-prepared sequence of annotated graphics.Despite the fundamental nature of this requirement, the user was only able to articulateit once he had imagined trying using the proposed system in the sort of design meetingshe was familiar with. We might be tempted to dismiss this late discovery of such afundamental requirement as due to negligence by the developers in the initial require-ments elicitation phase, but such omissions are not uncommon in software development.Requirements get discovered late because the only definitive test of the completenessof requirements is system use.



Impacts of Design Decisions on Exogenous Goals

New requirements are often elicited when design decisions have significant impacts onexogenous goals of the organization. There are at least three ways in which this happens:through negative side effects, positive side effects, and what has been called affordances.

Negative Side Effects

We often find that the means for implementing a requirement have important — thoughunintended — consequences for goals not originally included in the requirements. Oneway this can happen is that the means for implementing a given requirement can haveunintended side effects that interfere with the satisfaction of certain exogenous goals.Consider the following example from the project to develop software for collaborativearchitectural design. The developers originally proposed that the system facilitatecollaboration between architects and clients by using voice communication. A user (anarchitectural illustrator) working with the developers pointed out that this would beproblematic because architects’ offices in the U.S.A. typically have “open plan” layoutswith no acoustic shielding between the people in the office. Having people in the officeengaged in lengthy voice chat sessions during the workday would be unacceptablydisruptive. As a consequence of this user feedback a new requirement was added,namely that collaborative communication should not disrupt other people’s work in theoffice.

Positive Side Effects

Not all unintended side effects are negative. Some help to achieve goals not originallylisted as requirements. For example, one feature of the proposed collaborative softwaredescribed above was that it provided an exact record of what had been agreed to betweenclient and designer – something not provided by the users’ present, non-computer-based process. One user realized that this would be extremely useful for settlingcontractual disputes with clients. This legal consideration then became an importantrequirement and resulted in several new system features.

Affordances

The situation with affordances is similar to that for positive side effects. Affordances arepotential new types of useful functionality that existing features of a design might makeeasier to implement. The affordances that elicit new requirements are ones that facilitatethe achievement of exogenous goals.For example, in the collaborative architecture project it was originally decided not toinclude any requirements for designing buildings from scratch. Instead the system onlyhad requirements for supporting design review sessions, that is, sessions in which



existing designs are critiqued and revised. But after the set of needed drawing tools forsuch review sessions had been decided on, one user realized that with very little extrafunctionality the system would be minimally adequate for designing things from scratch.It was then decided to include the requirement for designing from scratch – at least inthis minimal form.

Participatory Design

Using Participatory Design to Identify NewRequirements

The best user feedback about the completeness and correctness of requirementsnaturally comes from actual use of a fully designed and implemented system. Unfortu-nately this feedback comes at precisely the time when it is most costly to modify thesystem so as to satisfy newly discovered requirements. To minimize the cost of creatinga high-quality system, developers need to make the discovery of new requirementshappen as early as possible in the development process – ideally during design of thesystem. We suggest that the best way to do this is to have users work collaborativelywith developers during design of the system, reacting to proposals for design featuresas soon as possible after these proposals are made. Such a participatory design strategywould seem to offer the promise of greatly reducing the cost of implementing newlydiscovered requirements.In fact the examples given above for the elicitation of new requirements were taken fromexactly such a session of participatory design in which a representative of the usercommunity for a collaborative design tool for architects worked with a software devel-oper during design of the system. Our studies of such sessions have shown that theyalmost invariably lead to the elicitation of new requirements before any implementationof the system has begun. While there is some cost for re-design, there is no cost of re-implementation.The best way to minimize the costs of redesign seems to be to have users work withdevelopers while they are designing the system. This enables users to react to designproposals as they arise. New requirements are typically elicited exactly when theevaluation of design proposals begins. More specifically, new requirements appear inevaluative comments that users make about the pros and cons of proposed systemfeatures. This makes it possible for software designers to discover new requirements asthey arise and to adjust the design accordingly.

Obtaining Transcripts of Participatory Design Sessions

It is not enough for a software developer to learn about to new requirements as they arise.A complex software development project is almost invariably done by a team, and it is



crucial that all members of the team be able to learn about the new requirements. And itis crucial to have a list of all known requirements whenever a system or part of the systemis redesigned. Furthermore it is essential to keep a record of the rationale for allrequirements. In other words new requirements and their rationale need to be systemati-cally identified and documented as they arise and then made available to all relevantparticipants in the development project.A crucial difficulty confronts us here, because extracting the new requirements and theirrationale from the participatory design sessions requires solution of a problem that haslong appeared to be intractable: the problem of design rationale capture. Requirementsand their rationale constitute a subset of the total design rationale (DR) for a project. Morethan 30 years of efforts at developing DR capture systems has produced a flurry of papersand a variety of clever software concepts (Moran & Carroll, 1996). Unfortunately it hasnot so far resulted in systems that software developers are willing to use in practice(Fischer, Lemke, McCall, & Morch, 1991).We maintain, however, that there is good reason to believe that the collaboration foundin development of complex system provides the opportunity for a breakthrough in DRcapture.We argue that there has been a two-fold obstacle to effective to design rationale capture.The first part of this obstacle has been the insistence in every major DR method thatsystem designers write up the rationale for what they do. The second part of the obstaclehas been the insistence that this write up be in a semi-formal structure according to somepre-specified schema. For example, in the IBIS (Issue-Based Information Systems) (Kunz& Rittel, 1970) method for capturing design rationale, designers are to write up theirrationale in the form of questions – called issues – and proposed answers to the questionsand arguments for and against the proposed answers and/or the other arguments. Thevarious issue-based discussions are then to be linked together using pre-specifiedrelationships. Each of the DR methods proposed has a different schema, but all requirethat DR be captured in a schema.The problem is that writing up rationale is typically a great deal of work over and aboveall the design work itself – especially since all approaches to DR capture have requireda great deal of editorial work to put the rationale in a specific schema. This work is tedious,requires a great deal of skill, and seldom has any immediate payoff for the person whodoes it. While many pilot projects claim to have shown the benefits of differentapproaches, in practice designers have almost invariably refused to do this extra work.Thus apparently promising software systems developed to facilitate DR capture haveinvariably fallen into disuse.The breakthrough for DR capture in collaborative design comes from the fact thatcollaboration in design is made possible by communication in which the rationale fordecisions is discussed. Simply recording this communication in a machine-readable formproduces an extensive – if not complete – record of project rationale. If this communi-cation can be put into textual form, you get a searchable record of project rationale – thatis, one from which new requirements can be located and extracted.Over the past year we have gotten excellent transcripts of collaborative design sessionsby having university students use off-the-shelf collaboration tools, such as the Groovepeer-to-peer software for collaboration. This technique, however, currently seems



restricted to users under the age of 25 – the so-called “digital natives,” that is, peoplefor whom digital communication is part of their “native language.” For users in the over-25 crowd of “digital immigrants” this technique has, unfortunately, turned out to be notat all promising.We did a year’s worth of generation and analysis of transcripts by student designers whocommunicated with each other by text-based online “chat” sessions. These studies wereuseful to start with, but did not tell us enough about real-world projects. We wanted tolook at what professionals would do: both professional software developers and userswho are professionals in their respective problem domains. We wanted to study thedesign of actual software products rather than mere academic prototypes.The professional users we worked with were significantly older than the students (theyoungest professional user was 35 years old) and were not at all comfortable with text-based chat as a means of collaboration. We therefore used face-to-face meetings, whichwe videotaped. The audio from these tapes was then transcribed by hand. This techniqueis not practical for real-world development, but it enabled us to see what might be practicalin the not-too-distant future, when highly accurate transcripts of design sessions canbe generated automatically using speech recognition – something that is not reallyfeasible with today’s commercial speech recognition software. One of these transcribedsessions is the source of the examples in this article.

Extracting New Requirements from ParticipatoryDesign Transcripts

Transcripts of participatory design sessions can provide a rich source of informationabout new requirements and their rationale. Unfortunately this information is notstructured in any of the various edited and schematized forms that have been proposedfor capturing and indexing DR. Instead it is merely in the form of an unstructuredconversation that typically goes on for several hours. As a consequence, locating newrequirements in these transcripts is labor-intensive, tedious, and error-prone.Conventional information retrieval techniques are unlikely to be adequate for the needsof future designers looking for requirements and their rationale in transcripts. The reasonfor this is the fact that almost all information retrieval strategies rely on what is knownas content-based retrieval. In this strategy information is located using descriptions ofits content – for example, keywords or freetext terms. The problem, however, in searchingfor requirements is that we almost invariably have no idea what the content of newrequirements statements is. If we did know the content, we would not need to look forthem. Our task is actually to discover their content by first discovering the requirementsstatements themselves and then analyzing them. By definition content-based retrievalcannot help us to do this.What is needed is some way of discovering requirements statements without first havingto know their content. We have recently devised a method for doing this using a simpletype of natural language analysis based on semantic grammars – that is, grammars inwhich the rules of replacement are based on semantic rather than syntactic relationships(Jurafsky & Martin, 2000). We use this technique to identify requirements-related



rationale and structure it in a form closely related to the IBIS schema for DR. While ourtechnique is still in its early stages of testing, it offers the possibility of making DR capturepractical by having the computer rather than humans do the lion’s share of the work ofstructuring transcripts. And since producing the transcripts of the rationale requires nowork beyond that needed for the communication that occurs naturally in a collaborativeproject, designers can with little or no effort produce searchable records of requirements-related rationale for projects.

Using Semantic Grammars to CaptureRequirements and their Rationale

The scope of this paper does not allow us to provide full description of our techniquefor identifying requirements and their rationale, but in the following paragraphs we givean overview of our approach.

Our Approach to Use of Natural Language Processing

To date NLP has had only limited success in producing machine understanding ofordinary human discourse, so it might seem odd that we are looking to a very simple NLPtechnique – namely, semantic grammars – to find requirements and their rationale in thediscourse of participatory design. But our approach is made practical in part by the limitednature of what we are attempting to do. First and most basically we are not attemptingto have the computer “understand” requirements. We are instead attempting to helphumans find requirements within transcripts of design sessions in which very little of thediscourse deals with requirements. Thus it is sufficient if we can significantly reduce thenumber of utterances that a human analyst needs to look at in a transcript to find newrequirements.Another factor that suggests the practicality of our approach is the particular circum-stances under which new requirements are elicited. They are almost invariably found inusers’ responses to proposed features of a system. More specifically requirements aretypically found in arguments – to use the IBIS term – about the pros or cons of proposedfeatures. This means that we can narrow the search for requirements by identifying thoseplaces in a participatory design transcript where system features are proposed. As itturns out user arguments on such proposals are found in the texts immediately followingthe statement of the proposal. In addition there is a friendly principle at work here, foronly a very small subset of English is employed in stating proposals. And our studiessuggest that this subset can be described using a relatively small semantic grammar.



Design Proposals

Design proposals generally fit into a few basic types. Some proposals suggest thatsomething is a good means for accomplishing some desired functionality. Some suggestthat one or more properties should be given to an object. Others suggest that an objectwith certain properties be created. Still others suggest that one object be put in a specificrelationship with another object. The objects, properties, and relationships used in suchproposals tend to be drawn from a list that characterizes a particular domain – such asthe design of human/computer interaction for the architectural design domain.In addition most of the proposals made in design projects are preceded by introductorywording that is only used in making proposals. Some examples of such wording includethe following: “We were thinking that we could …,” “What if we …,” “Why don’t we …,”“The best solution would probably be to …” The list of such introductory word stringsis large, but we have found that a semantic grammar can be constructed to detect themin design utterances.An example of a proposal in the project for design of the collaborative architecturalsoftware would be, “We were thinking that it would be best to use Voice over IP to letarchitects and clients communicate.” In this statement the introductory wording, “Wethink it would be best to use…” is the first evidence that we are dealing with a proposal.The terms “Voice over IP,” “communication,” “architects,” and “clients” are character-istic of the computer-support design domain. The phrase “Voice over IP” describes ameans to accomplish the goal described by the phrase “to let architects and clientscommunicate.” The words “would be best” imply that the means described is the bestof the ways available to accomplish the stated goal. This structure is typical of onecommon type of proposal, and we have created a semantic grammar that can reliablydetect such structures. Figure 1 shows in “outline” form the parse tree produced by oursemantic grammar for this proposal statement.

Requirements in Arguments on Proposals

Once proposals have been identified the next task is to find where users state argumentsin reaction to them. First of all we can restrict our search to the users’ utterances, thuseliminating roughly half of the utterances that follow the proposal in the transcript.Arguments about proposals often have introductory wording only found in arguments.The simplest examples are “Yes, because …” and “No, because …” In fact somearguments have introductory wording found only in arguments about proposals.Examples include the following: “That’s not going to work, because …,” “Yeah, I thinkthat’s good idea, because …,” “I like that idea. It will …,” and “The problem with that is…”A crucial point here is that the negative evaluation of voice-based communication usesa criterion variable not found in any of the previously listed requirements: degree ofnoise. This is a crucial clue that a new requirement has surfaced. As it turns out, this isconfirmed by the very next utterance by the user: “OK, so we have an issue: talking. OK?



Figure 1. The parse tree for the sentence, “We were thinking that it would be best touse Voice Over IP to let architects and clients communicate.”

PROPOSAL-STATEMENT SUBJECT-THOUGHT

SUBJECT we THINK were thinking

INTENTIONAL-CONJUNCT that GOOD-IF it would be best to

THING-PROPOSED EMPLOY use

MEANS Voice over IP TO-ACHIEVE to let GOAL USER architects CONJUNCT and USER clients BEHAVIORAL-VP

communicate

Figure 2. The parse tree for the sentence, “The problem with that is that you are goingto have all these people in the office talking simultaneously and it becomes acacophony.”

ARGUMENT NEGATIVE-ARGUMENT-ON-PROPOSAL

ARGUMENT-INTRO NEGATIVE-ARGUMENT-ON-PROPOSAL-INTRO

the problem with that is INTENTIONAL-CONJUNCT that

NEGATIVE-EFFECT-OF-PROPOSAL PREDICTION-INTRO you are going to have NEGATIVE-PREDICTION USER-BEHAVIOR USER

all these people in the office BEHAVIOR

talking simultaneously CONJUNCT and NEGATIVE-CONSEQUENCE EXISTS it becomes NEGATIVE-PERFORMANCE

a cacophony



Noise pollution.” What the user is calling an “issue” here implies a new requirement forthe system. Semantic grammars can be used to detect all of these facts.

Related Work

We are by no means the first to explore the use of formal NLP techniques in requirementsengineering (RE). In fact the field is more than 15 years old. In 1988 Maarek and Berryproposed the use of NLP techniques for requirements extraction (Maarek & Berry, 1988).In 1992 Rolland and Proix argued for the development of CASE tools for RE based on NLP(Rolland & Proix, 1992). By the early 1990s there was enough optimism about theprospects for use of NLP in RE that Ryan felt it necessary to issue a cautionary note(Ryan, 1993) about the limits on using NLP for automating RE. We, like most others,accept the notion that the proper goal for NLP is not the automation of RE processesbut rather easing the burden on human requirements engineers. But some researchers,most notably those involved with the Circe project (for example, Gervasi & Nuseibeh,2002), remain optimistic about the possibility and value of automation.Roughly speaking there seem to be three major NLP approaches being used in RE. Oneis template matching, another is rule-based parsing, yet another is probabilistic analysis.These approaches are sometimes used in combination, and sometimes the borderbetween template matching and rule-based parsing is blurred. Thus the REVERE project(Rayson, Garside, & Sawyer, 2000; Sawyer, Rayson, & Garside, 2002) is primarily orientedtowards probabilistic analysis, yet it employs some rule-based parsing as well, at leastin the sense of identifying parts of speech. The Circe project (Ambriola & Gervasi, 1997)is based on template matching but uses rules of replacement in a manner reminiscent ofa grammar. The semantic grammar approach that we have described is strictly a rule-basedparsing approach, but one that differs from syntactic parsing in the inclusion of semanticinformation in the parse rules. This has the distinct advantage of avoiding having to dealwith many of the apparent ambiguities that do not turn out to represent real ambiguitiesin meaning.There is, however, an important argument raised by the participants in the REVEREproject that presents a challenge to our purely rule-based approach. These authors pointout that rule-based systems are inherently brittle and limited to a subset of naturallanguage. One exception to the rules is all it takes for a rule-based system to break down.The REVERE researchers use this as an argument for a probabilistic approach to NLP.(It is interesting to note that the Circe project mitigates this difficulty by using fuzzycriteria for template matching.)We acknowledge the legitimacy of these arguments and the fact that probabilisticapproaches to NLP have in fact proved to be highly successful. There is, nevertheless,reason to pursue the use of rule-based approaches in addition to and as a complementto probabilistic approaches. The reason is that rule-based approaches that includesemantics do a better job at identifying the full meaning of many sentences thanprobabilistic techniques can. What we recommend is that semantically informed, rule-based techniques – such as semantic grammars – be used to extract as much information



as possible from natural language transcripts and other documents. Where suchtechniques fail, probabilistic techniques should be brought in as a backup. This willprovide a graceful degradation strategy that will enable the extraction of the mostinformation from such documents.

Conclusion and Future Work

Future Work

The examples we have given of our semantic grammar approach only suggest itsplausibility. We are still engaged in testing our approach. Preliminary results with a half-dozen design transcripts appear encouraging, but testing is needed with more develop-ers and users in a wider range of projects to confirm these results.Semantic grammars may not be the only viable approach for capturing requirements.Fundamentally different approaches might work as well or better. This topic needs muchresearch. In addition there may be room for a wide range of tools supporting variousaspects of iterative elicitation of requirements throughout the software life cycle. Theseinclude tools for eliciting, modeling, analyzing, specifying, validating, evolving, andintegrating requirements.One thing we have not really dealt with here is the fact that user participation in designwill inevitably produce many new problems for managing the development process.These managerial problems are closely intertwined with the process aspects, andadequate tools will be needed to deal with them. In fact a number of large software firms– including Microsoft and Macromedia – are investing significant resources in develop-ing such tools. In addition research-oriented communities in academia and industry arealso working on tools for managing collaboration – for example, SnipSnap, a contentmanagement system based on Wiki and Weblog technologies (www.snipsnap.org).

Conclusion

In this paper we have attempted to show the importance of collaboration betweendevelopers and future users of software systems for determining system requirements.While this interaction complicates the development process, it also offers the possibilityof increasing software quality. By encouraging this collaboration as early as possible indesign, the benefits can be increased while the costs are minimized.While we have focused on collaboration between developers and users, many othertypes of collaboration play a crucial role in software development, such as collaborationwithin development teams and collaboration amongst users. These types of collabora-tion also constitute a potential source of much of the information needed for successfulsoftware projects. The techniques we have described here might also be usefullyextended to support these other kinds of collaboration. There is much that remains to be



done to understand and deal with collaboration in software development, but there aregood reasons for optimism about the potential benefits of research in this field.

References

Ambriola, V., & Gervasi, V. (1997). An environment for cooperative construction ofnatural-language requirement bases. Proceedings of the Eighth Conference onSoftware Engineering Environments, 124-130.

Curtis, B., Iscoe, N., & Krasner, H. (1988). A field study of the software design processfor large systems. Communications of the ACM, 31(11), 1268-1287.

Fischer, G., Lemke, A.C., McCall, R., & Morch, A.I. (1991). Making argumentation servedesign. Human Computer Interaction, 6(3), 393-419.

Gervasi, V., & Nuseibeh, B. (2002). Lightweight validation of natural language require-ments. Software – Practice and Experience, 32(2), 113-133.

Grady, R.B. (1999). An economic release decision model: Insights into software projectmanagement. Proceedings of the Applications of Software Measurement Confer-ence, Orange Park, FL.

Highsmith, J. (2004). Agile software development ecosystems. New York: Addison-Wesley.

Highsmith, J.A., & Orr, K. (2000). Adaptive software development: A collaborativeapproach to managing complex systems. New York: Dorset House.

Johnson, J. (2002). Keynote speech, XP 2002 conference, Sardinia, Italy.Jurafsky, D., & Martin, J. H. (2000). Speech and language processing: An introduction

to natural language processing, computational linguistics and speech recogni-tion. Englewood Cliffs, NJ: Prentice Hall.

Kunz, W., & Rittel, H.W. J. (1970). Issues as elements of information systems. (WorkingPaper No. 131). Stuttgart, Germany: Institut für Grundlagen der Planung, UniversitätStuttgart.

Larman, C. (2004). Agile and iterative development: A manager’s guide. New York,Addison-Wesley.

Maarek, Y., & Berry, D. M. (1988). The use of lexical affinities in requirements extraction.(Technical Rep.). Haifa, Israel: Technion, Faculty of Computer Science.

Martin, R.C. (2002). Agile software development, principles, patterns, and practices.Englewood Cliffs, NJ: Prentice Hall.

Moran, T., & Carroll, J, (Eds.) (1996). Design rationale: Concepts, techniques and use.Mahwah, NJ: Lawrence Erlbaum Associates.

Rayson, P., Garside, R., & Sawyer, P. (2000, April 12-14). Assisting requirementsengineering with semantic document analysis. Proceedings of RIAO 2000 (Re-cherche d’Informations Assistie par Ordinateur, Computer-Assisted InformationRetrieval) International Conference, Paris.



Rittel, H.W.J. (1972). On the planning crisis: Systems analysis of the first and secondgenerations, Bedriftokonomen, 8, 390-396.

Rolland, C., & Proix, C. (1992). A natural language approach for requirements engineer-ing. Lecture Notes in Computer Science, Vol. 593.

Ryan, K. (1993). The role of natural language in requirements engineering. Proceedingsof IEEE International Symposium on Requirements Engineering, 240-242.

Sawyer, P., Rayson, P., & Garside, R. (2002). REVERE: Support for requirements synthesisfrom documents. Information Systems Frontiers, 4(3), 343-353.

Schon, D.A. (1983). The reflective practitioner: How professionals think in action. NewYork: Basic Books.

Schuler, D, & Namioka, A. (Eds.). (1993). Participatory design: Principles and prac-tices. Mahwah, NJ: Lawrence Erlbaum Associates.

Taylor, A. (2000). IT projects: Sink or swim? The Computer Bulletin, January 2000,British Computer Society.

318 Hall and Rapanotti


Chapter XIX

Problem Frames forSociotechnical Systems

Jon G. Hall, The Open University, UK

Lucia Rapanotti, The Open University, UK

Abstract

This chapter introduces Problem Frames as a framework for the analysis of sociotechnicalproblems. It summarizes the Problem Frames approach, its techniques and foundations,and demonstrates, through theory and examples, how it can be applied to simplesociotechnical systems. The chapter continues with the description of an extendedProblem Frame framework that allows the treatment of more general sociotechnicalproblems. This extension covers social components of a system — individuals, groupsor organisations — bringing them within the remit of the design activity. The aim of thechapter is to make the Problem Frames framework more accessible to the softwarepractitioner, especially those involved in the analysis of sociotechnical problems, asthese problems have so far received only scant coverage in the Problem Framesliterature.

Problem Frames for Sociotechnical Systems 319


Introduction

By sociotechnical system we mean a collection of interacting components in which someof the components are people and some are technological. In this chapter we focus onthe requirements analysis of sociotechnical systems in which some of the technologicalsubsystems are computer-based, these systems forming the largest part of modernsoftware design problems.More precisely, there are two (not necessarily disjoint) sub-classes of sociotechnicalsystems that we will treat in this chapter. The first sub-class contains those systems inwhich existing components or sub-systems (that is, domains) are to be allowed, throughsoftware, to interact. An example from this first class might be the problem of designingsoftware for the operator of heavy machinery. The larger second class contains thosesystems for which software, a user interface, and user instruction are to be designed toenable a new process or service. An example of this second class might be thedevelopment of a new customer call centre.The use of Problem Frames (PFs) underpins our requirements analysis process. Asdescribed in Jackson (1998), PFs are a concretization of the ideas of Michael Jackson andothers in the separation of machine and its environment’s descriptions. This separationis generally accepted as being a useful principle for requirements analysis. We will havecause, later in the chapter, in dealing with a more general class of sociotechnicalproblems, to further detail this separation, but nothing we do compromises its fundamen-tal status.The usual representation of the separation of machine and environment descriptions isas the “two ellipse” model, illustrated in Figure 1. In that figure world knowledge W is adescription of the relevant environment; R is the statement of requirements; S is thespecification that mediates between environment and machine; M is the description ofthe machine; and P is the program that, on machine M, implements the specification S.The role of W is to bridge the gap between specification S and requirements R. Moreformally (Gunter, Gunter, Jackson, & Zave, 2000; Hall & Rapanotti, 2003; Zave & Jackson,1997), W,S |-R.One of the aims of the PF framework is to identify basic classes of problems that recurthroughout software development. Each such class should be captured by a problemframe that provides a characterization for the problem class. Sociotechnical systems are

Figure 1. The requirements analysis model



an important class of problems and so should be representable within the PF framework,possibly with their own (collection of) problem frame(s).In a fundamental sense, of course, the PF framework already deals with sociotechnicalsystems: problem frames are an attempt to allow customer and developer to come togetherto match real-world problems and technological solutions. There are many examples inJackson (2001) as to how this relationship can be facilitated using problem frames.We observe, however, that the application of problem frames to particular sociotechnicalproblems remains under-explored. Currently some discussion of HCI appears in Jackson(2001), and some analysis appears in Jackson (1998), but otherwise there is little in-depthcoverage of how to apply problem frames in this context. In this chapter we show, in somedetail, how problem frames can be applied to sociotechnical systems.Our development is threefold. We first show how the problem of representing interactionwith (and not just control of) technology can be represented within the PF framework.To do this we introduce two new basic problem frames, the User Interaction Frame andthe User Commanded Behaviour Frame, each dealing with the class of user-interactionproblems.Secondly we show how architectural artifacts can be used to guide the analysis ofsociotechnical problems. To do this we discuss the notion of an Architectural Frame(AFrame for short), a new PF artifact that can be used to guide problem decompositionin the light of particular solution expertise as might, for instance, exist in a softwaredevelopment company. As an exemplar of AFrames and their use, we define and applyan AFrame corresponding to the Model View Controller (MVC) architectural style (Bass,Clements, & Kazman, 1998).Lastly we adapt the PF framework to meet the needs of representing the problems of morecomplex sociotechnical systems, including those in which, as well as user-machineinteraction, user training needs to be addressed. This causes us to consider a reificationof the two-ellipse model into three ellipses to represent machine, environment, and userdescriptions. Consequently, by interpreting this third ellipse in the PF framework, wediscover a new type of PF domain – the knowledge domain – to represent a user’sknowledge and their “instruction” needs, and argue that this leads to a more general PFframework for sociotechnical systems.

Chapter Overview

In the major part of this chapter we will use a well-known chemical reactor problem (Dieste& Silva, 2000; Leveson, 1986) as an example for illustration of techniques. Later we brieflydescribe the design of a “cold-calling” system. The chemical reactor is a sociotechnicalsystem and is representative of the class of operator-controlled safety- (and mission-)critical systems. A schematic for the chemical reactor hardware appears in Figure 2.A statement of the problem is as follows:

A computer system is required to control the safe and efficient operation of the catalystunit and cooling system of a chemical reactor. The system should allow an operator to



issue commands for activating or deactivating the catalyst unit, and to monitor outputs.Based on the operator’s commands, the system should instruct the unit accordingly andregulate the flow of cooling water. Attached to the system is a gearbox: whenever theoil level in the gearbox is low, the system should alert the operator and halt execution.

The chapter is organized as follows. The next section develops the problem framerepresentation of the chemical reactor problem and uses this to recall the basis of problemrepresentation in the PF framework. The section on problem classification provides asmall taxonomy of problem classes, including those of relevance to sociotechnicalsystems. The next section addresses problem decomposition, both in the classical PFframework and through AFrames. The section on requirements analysis models forsociotechnical systems details our separation into three of the various domain descrip-tions and uses this to motivate a new type of PF domain, the knowledge domain. The finalsection concludes the chapter.

Problem Representation

We first consider the PF representation of the chemical reactor problem. Within the PFframework problems are represented through problem diagrams. A problem diagramdefines the shape of a problem: it records the characteristic descriptions and intercon-nections of the parts (or domains) of the world the problem affects; it places therequirements in proper relationship to the problem components; it allows a record ofconcerns and difficulties that may arise in finding its solution.For the chemical reactor, there are a number of domains, including those that appear inthe schematic of Figure 2. Also the operator will play an important role in issuingcommands to control the catalyst and cooling systems. Placing all of these domains intheir correct relationship to each other leads to the problem diagram shown in Figure 3.The components are:

• Operation machine: The machine domain, that is, the software system and itsunderlying hardware. The focus of the problem is to build the Operation machine.

Figure 2. The chemical reactor schematic (adapted from Dieste & Silva, 2000)



• Other boxes (Cooling System, Catalyst, and so forth): Given domains representingparts of the world that are relevant to the problem.

• Shared phenomena: The ways that domains communicate. These can includeevents, entities, operations, and state information. In Figure 3, for example, theconnection between the Operation machine and the Cooling System is annotatedby a set e, containing the events increase_water and decrease_water, and a setf, containing the phenomenon water_level. Phenomena in e are controlled by theOperation machine; this is indicated by an abbreviation of the domain namefollowed by !, that is, OM!. Similarly the phenomenon in f is controlled by theCooling System, indicated by the CS!.

• The dotted oval Safe and efficient operation: The requirement, that is, what hasto be true of the world for the (operation) machine to be a solution to the problem.

• In the connections between the requirement and the domains, a dotted lineindicates that the phenomena are referenced by (that is, an object of) the require-ment, while a dotted arrow indicates that the phenomena are constrained (that is,a subject for the requirement). In Figure 3, for instance, the oil level in the gear boxis referenced while the cooling system’s water level is constrained.

• Phenomena at the requirement interface (for example, those of sets f or d) can be,and usually are, distinct from those at the machine domain interface (for example,

Figure 3. The chemical reactor problem diagram

a: {open_catalyst, close_catalyst} f: {water_level} b: {catalyst_status, water_level} g: {oil_level} c: {open_catalyst, close_catalyst} d: {is_open, is_closed} e: {increase_water, decrease_water}



those of sets c and e). The former are called requirement phenomena; the latter,specification phenomena. The intuition behind this distinction is that the require-ment is expressed in terms of elements of the problem, while the specification (thatis, what describes a machine domain) is expressed in terms of elements of thesolution.

Other artifacts that are not represented on the problem diagram but are related to it aredomain and requirement descriptions. Such descriptions are essential to the analysisof a problem and address relevant characteristics and behaviours of all given domains,the machine domain, and the requirement.An important distinction in the PF framework is that of separating two types ofdescriptions: indicative and optative. Indicative descriptions are those that describehow things are; optative descriptions describe how things should be. In this sense, ina problem diagram, given domain descriptions are indicative, while requirement andmachine descriptions are optative. In other words things that have to do with the problemdomain are given, while things that have to do with the solution domain can be chosen.For instance, in the chemical reaction problem indicative descriptions of the Catalyst,Cooling System, and Gear Box should include characteristics of the domains that are ofinterest in the specification of the machine, say, the mechanics of opening the catalyst,or of changing the water level in the cooling system, or the oil level in the gear box. Onthe other hand the requirement should express some constraints on the status andoperations of those domains that, when satisfied, result in their safe and efficientoperation. Finally the machine specification should describe how we would like thecontrol system to behave and interact with the given domains so that the requirementsare met.Indeed not all domains share the same characteristics. There is a clear difference betweena cooling system and an operator. In a cooling system there exist some predictable causalrelationships among its phenomena. For instance, it could be described as a statemachine, with a set of clearly identified states and predictable transitions between them.A domain with such characteristics is known as a causal domain. On the other hand, anoperator’s phenomena lack such predictable causal relationships. We can describe theactions an operator should be allowed to do but cannot guarantee that they will beexecuted in any particular order, or not at all, or that some other (unpredicted) actionswill not be executed instead. A domain with such characteristics is known as biddable.The distinction between causal and biddable domains is an important one, as it hasramifications for the type of descriptions we can provide and the assumptions we canmake in discharging proof obligations during the analysis of a problem, as we will seein the following sections.Of course there exist other types of domains, each with its own characteristics. Anexhaustive domain classification is beyond the scope of this chapter and can be foundin, for example, Jackson (1995), Jackson (1998) and Jackson (2001).



Problem Classification

One of the intentions of the PF framework is to classify problems. An initial problemclassification is given in Jackson (2001). Therein are identified five basic problem frames.They are basic because they represent relatively simple, recurrent problems in softwaredevelopment. In describing the basis of problem frames, the intention is not to beexhaustive in its classification of problems. Indeed there are other frames by Jackson(see, for example, Jackson, 1998) that do not make it into that classification.In this section we present a simple taxonomic development, beginning with the simplestof all problem frames and adding domain types (modulo topology). As each type hasdifferent characteristics, the resulting problem frames represent different classes ofproblems. In doing so we introduce a new basic problem frame, the User InteractionFrame, which is novel in the problem class it represents within the PF framework (but not,of course, within software engineering). The taxonomy is summarized in Figure 4.

Programs

The simplest form of problem representable in problem frames is that of producing aprogram from a given specification. This is illustrated in Figure 5. Although this is a sub-problem of all software engineering problems, it is not a very interesting problem classto be analyzed using problem frames: nothing exists outside the machine. Othertechniques, such as JSD (Jackson, 1997) or design patterns (Gamma, Helm, Johnson, &Vlissides, 1995), are probably more appropriate to tackle this problem class. Indeed thePF framework does not include a problem frame for this class of problems.

Figure 4. Simple problem frame taxonomy: adding domain types

Figure 5. Writing programs



Embedded Controllers

For a problem class to be purposefully analyzed in PFs, some given domain(s) of interestmust exist outside the machine. An interesting problem class is identified in Jackson(2001) by introducing a single causal domain. The problem frame is known as theRequired Behaviour Frame, and its characterizing problem is that of building a machinethat controls the behaviour of some part of the physical world so that it satisfies certainconditions. Some software engineers may find it easy to identify this problem with thatof building an embedded controller (although it does apply also to more general softwareproblems).The Required Behaviour Frame is illustrated in Figure 6. The frame has a topology thatis captured by a frame diagram (that of the illustration).The frame diagram resembles a problem diagram, but it also includes some furtherannotation. This provides an indication of the characteristics of the domains andphenomena involved in problems of the class. For the Required Behaviour Frame:

• The Controlled domain is causal (the C annotation in the figure). Its phenomenaare also causal (indicated by C on the arcs) — they are directly caused or controlledby a domain and may cause other phenomena in turn.

• The Control machine has access to causal phenomena of the Controlled domain(in C2) and controls another set of phenomena, which are also shared with theControlled domain (in C1). Intuitively phenomena in C1 are used by the machineto control the domain, while phenomena in C2 are used to obtain information andfeedback on the functioning and state of the domain.

• The requirement, Required behaviour, is expressed in terms of a set (C3) of causalphenomena of the Controlled domain.

When a problem of a particular class is identified, it can be analyzed through theinstantiation of the corresponding frame diagram. The instantiation is a process ofmatching problem and frame’s domains and their types, as well as problem and frame’sphenomena types. The result of the instantiation is a problem diagram, which has thesame topology of the frame diagram but with domains and phenomena grounded in theparticular problem.Let us return to the chemical reactor problem and consider the problem of regulating thewater level in isolation. This can be regarded as a required behaviour problem (Figure 7)with some safety requirement on the water level.

Figure 6. Required Behaviour Frame



For a problem to be fully analyzed, the instantiation of a problem frame is only the firststep of the process. Suitable domain and requirement descriptions (see the section onproblem representation) need to be provided and the frame concern needs to beaddressed. The frame concern is an overall correctness argument, common to all theproblems of the class. It is the argument that must convince you, and your customer, thatthe specified machine will produce the required behaviour once combined with theproperties of the given domains. Each problem frame comes with a particular concernwhose structure depends on the nature of the class problem. For the Required BehaviourFrame, the argument is outlined in Figure 8.

User Interaction

Another interesting class of problems can be obtained by including a single biddabledomain outside the machine, which represents the user of the system. We call theresulting problem frame the User Interaction Frame, and its characterizing problem isthat of building a machine that enforces some rule-based interaction with the user. Theframe diagram for the User Interaction Frame is given in Figure 9.

Figure 7. Regulating the water level in the cooling system as a required behaviourproblem

Figure 8. Frame concern for the Required Behaviour Frame

1 We will build a machine that behaves like this, so that... 2 knowing that the controlled domain works like this... 3 we can be sure that its behaviour will be this.

e:{increase_water,decrease_water}f:{water_level}



Figure 9. User Interaction Frame

Figure 10. Operator/system interaction as an instance of the User Interaction Frame

a: {open_catalyst, close_catalyst} b: {catalyst_status, water_level}

Figure 11. Frame concern for the User Interaction Frame

The Interaction machine is the machine to be built. The User is a biddable domainrepresenting the user who wants to interact with the machine. The requirement gives therules that establish legal user/machine interactions.The manifestation of the user/machine interaction is through exchanges of causalphenomena (in C1) controlled by the user and symbolic phenomena (in Y1) controlled bythe machine. Intuitively the user issues commands in C1 and the machine providesfeedback through Y1. The interaction rules specify the legal correspondence of user andmachine phenomena.

1 Given this set of machine phenomena, when the user causes this phenomena (it may or may not be sensible or viable)... 2 if sensible or viable the machine will accept it... 3 resulting in this set of machine phenomena... 4 thus achieving the required interaction in every case.



In the chemical reactor problem we can isolate the operator/machine interaction as a userinteraction problem as illustrated in Figure 10, where the requirement establishes somerules on the relationship between operator’s commands and system feedback, say, thatan open_catalyst command cannot be issued when the water_level value is below a setthreshold. Note that this would be the perspective of a User Interface (UI) designer,whose main concern is the user interacting with a black box system. Indeed, in the widerproblem analysis of the chemical reactor problem, machine responses to user commandsdepend on a faithful representation of the internal state of, say, the catalyst or the coolingsystem.Figure 11 illustrates the frame concern for the User Interaction Frame.

User Commanded Behaviour

The Required Behaviour and the User Interaction Frames are representative of relativelysimple problems, albeit often recurring in software development. It is possible, andindeed likely, that other interesting problem classes could be identified by consideringsingle given domains of some other type (see discussion at the end of the section onproblem representation). However we do not pursue this any further here. We look,instead, at what happens when there are two given domains outside the machine.As for the single domain case, other interesting classes of problems emerge. In fact theremaining four basic problem frames introduced in Jackson (2001) are all of this form.If we add a biddable domain to the Requirement Behaviour Frame, we obtain a UserCommanded Behaviour Frame, which is illustrated in Figure 12. Its characterizingproblem is that of building a machine that will accept the user’s commands, imposecontrol on some part of the physical world accordingly, and provide suitable feedbackto the user. Jackson (2001) introduces a subclass of this frame, the CommandedBehaviour Frame, which does not require the user to receive any feedback.In the chemical reactor problem, we can apply the User Commanded Behaviour Frame toanalyze how the catalyst is controlled by the operator. The corresponding problemdiagram is given in Figure 13.A possible description of the interaction rules could be as follows. The machine shallallow the user to control the catalyst under the following constraints:

Figure 12. User Commanded Behaviour Frame



Figure 13. Controlling the catalyst as an instance of a user commanded behaviourproblem

Figure 14. State machine model for the catalyst

a: {open_catalyst, close_catalyst} b: {catalyst_status} c: {open_catalyst, close_catalyst} d: {is_open, is_closed}

1 catalyst_status is a faithful representation of the state of the catalyst2 the initial state of the catalyst is catalyst_closed3 possible user commands are open_catalyst or close_catalyst4 state transitions are represented in Figure 14.

The frame concern for the User Commanded Behaviour Frame is given in Figure 15. Fromthe figure you will notice that the argument has two parts: satisfying the requiredbehaviour of the domain (from 1 to 4) and providing suitable feedback to the user (5 and6).



Problem Decomposition

Most real problems are too complex to fit basic problem frames. They require, rather, thestructuring of the problem as a collection of (interacting) sub-problems. In this sectionwe discuss two ways of decomposing problems within the PF framework. The first,classical decomposition, proceeds through sub-problem identification and problemframe instantiation. The second, our novel approach, combines sub-problem identifica-tion with guided architectural decomposition using AFrames.

Classical Decomposition

In classical PF decomposition a problem is decomposed into simpler constituent sub-problems that can then be analysed separately. If necessary each sub-problem can bedecomposed further, and so forth, until only very simple sub-problems remain. Decom-position proceeds through the identification of sub-problems that fit a recognisedproblem class and the instantiation of the corresponding problem frame. We illustrate theprocess on the chemical reactor problem.

Figure 15. The frame concern for the User Commanded Behaviour Frame

1 Given a choice of commands in the current state, when the user issues this command (it may or may not be sensible). 2 if sensible or viable, the machine will cause these events... 3 resulting in this state or behaviour... 4 which satisfies the requirement... 5 and which the machine will relate to the user... 6 thus satisfying the requirement in every case.



There are three sub-problems:

1. a user-commanded behaviour problem, for the operator to control the catalyst;2. a required behaviour problem, for regulating the water flow in the cooling system;

and3. a sub-problem to issue a warning (and halt the system) when there is an oil leak in

the gearbox.

Addressing sub-problems 1 and 2 means instantiating the corresponding problem framesto derive problem diagrams for each sub-problem. These were depicted in Figures 13 and7, respectively.The third sub-problem has no standard problem frame to represent it. The closest fitwould be the Information Display Frame (Jackson, 2001), but this requires a decision on

Figure 16. Raising the alarm as an instance of the information display problem

Figure 17. Further decomposition of the user Commanded Behaviour sub-problem

h:{ring_bell} i:{bell_ringing} g:{oil_level}




how the alarm will be raised. Here we have made an arbitrary choice of introducing a Belldomain, and assume that it will ring when the oil level in the gearbox is below a certainthreshold. The resulting sub-problem diagram is shown in Figure 16.Finally we already know from the simple taxonomy in the third section that sub-problemone can be decomposed further, resulting in a required behaviour and a user interactionsub-problem. These are shown in Figure 17.

AFrames

AFrame decomposition complements classical decomposition in providing guidance anddecomposition and recomposition rules. The rational behind AFrames is the recognitionthat solution structures can be usefully employed to inform problem analysis.AFrames characterise the combination of a problem class and an architectural class. AnAFrame should be regarded as a problem frame for which a “standard” sub-problemdecomposition (that implied by an architecture or architectural style) exists. AFrames area practical tool for sub-problem decomposition that allow the PF practitioner to separateand address, in a systematic fashion, the concerns arising from the intertwining ofproblems and solutions, as has been observed to take place in industrial softwaredevelopment (Nuseibeh, 2001). Further motivation for, and other examples of, AFramescan be found in Rapanotti, Hall, Jackson, & Nuseibeh (2004).The MVC (short for Model-View-Controller) (see, for example, Bass et al., 1998) is a wayof structuring a software solution into three parts – a model, a view, and a controller –to separate and handle concerns related, respectively, to the modeling of a domain ofinterest, the visual feedback to the user, and the user input. The controller interprets userinputs and maps them into commands to the model to effect the appropriate change. Themodel manages one or more data elements, responds to queries about its state, andresponds to instructions to change state. The view is responsible for feedback on themodel’s state to the user. Standard communication patterns (for example, the Observerpattern (Gamma et al., 1995)) apply between the MVC parts.Here we introduce the MVC AFrame as applied to the User Commanded Behaviour Frame.This represents the class of user commanded behaviour problems for which an MVCsolution is to be provided.

Figure 18. MVC annotation of the User Commanded Behaviour Frame



The intention of using the MVC in the solution space is recorded through an annotationof the machine as illustrated in Figure 18. Guidance on decomposition is in the form ofdecomposition templates, which are applied to obtain sub-problem diagrams. Thedecomposition templates for the MVC AFrame are given in Figure 19. It can be seen fromthe figure that the original problem is decomposable into two sub-problems, whosemachine domains are the View and Controller machines (in the MVC sense). Also a Modeldomain is introduced that represents an abstraction of the real-world domain to becontrolled. This is a designed domain (Jackson, 2001), that is, one that we have thefreedom to design, as it will reside inside the solution machine. The resulting sub-problems are then: that of building a View machine to display the Model’s representationof the state of the controlled domain and that of building a Controller machine that actson the Model, which will pass on the commands to the controlled domain. In PF termsthe Model acts as a connection domain between the real-world domain and presentationand control subsystems.The application of the MVC AFrame to the sub-problem of controlling the catalyst (seeFigure 13) results in the decomposition of Figure 20.We see at least two strengths of AFrames. The first is that they suggest how a problemwould need to be restructured for a particular solution form. For instance, in the MVCcase, that an abstract model of the catalyst needs to be produced (or, for that matter, aconnection domain between Operator and Gearbox — a Bell — would be needed).The second is that they help the recomposition of sub-problem solutions into the originalproblem. Recomposition is facilitated by the fact that AFrame decomposition is regular-ized through the application of the AFrame templates. For the MVC this is through the

Figure 19. Decomposition templates for the MVC AFrame



Figure 20. MVC decomposition of the user commanded behaviour sub-problem

Figure 21. MVC recomposition


e: {open, closed}

identification of the links among its architectural elements. The recomposition diagramfor the MVC AFrame is illustrated in Figure 21 and its frame concern in Figure 22. In Figure21 the recomposition of the model, view, and controller domains follows the MVCarchitectural rules.



A Requirements Analysis Model forSociotechnical Systems

The consideration of more sophisticated human-machine relationships is our nextconcern. To be specific we now wish to look at users’ behaviour as being the subject ofrequirements statements, admitting that users are the source of much of the flexibility insociotechnical systems. In short we wish to allow the design of human instruction to bethe subject of the requirements engineering process addressed through problem framesalongside that of the program.Paraphrasing this we might say that the human, as well as the machine, is to be the subjectof optative descriptions. Foundationally this means the separation of the description ofthe world from that of the human who is the subject of the design. This leads to the

Figure 22. Discharging the correctness argument in MVC recomposition

1 Given a choice of commands in the current state, when the user issues this command (it may or may not be sensible)...

2 if sensible or viable, the machine will cause these events...

3 resulting in this state or behaviour... 4 which satisfies the requirement... 5 and which the machine will relate to the user... 6 thus satisfying the requirement in every case.



reification of the original ellipse model shown in Figure 23. In it we have three ellipses– that for the Human H with knowledge K, that for the Machine M with program P, andthat for the remaining Environment W with requirements R. Of course, just as machinesoutside the design process have indicative descriptions in W, so do humans.With the introduction of the human H, we identify and separate two new areas of interest,which now form explicit foci for design:

• the specification UI, anonymous in the S region in the original model, whichdetermines the Human-Machine interface; and

• the specification I, missing from the original model, which determines the knowl-edge and behaviour that is expected of the human as a component of thesociotechnical system.

As in the original model the description W has the role of bridging the gaps between therequirement R and the specification S, in our extension W has the role of bridging the gapsbetween the requirement R and the instruction I, human-machine interface UI andspecification S together. More precisely we assert that S, I, UI, and W must be sufficientto guarantee that the requirements of the sociotechnical system are satisfied. Moreformally:

W,S,I,UI |- R

A Problem Frame Interpretation

In the PFs framework the machine domain represents the machine for which thespecification S must be designed. By analogy a new domain type will be required torepresent the human for which the instruction I has to be designed. To this end weintroduce into the PF framework the notion of a knowledge domain to represent thatdomain. In a problem diagram a knowledge domain should be represented as a domainbox with a double bar on the right-hand side (to distinguish it from the machine domain).

Figure 23. The extended requirements analysis model



The most general form of a sociotechnical problem, as a problem diagram, is shown inFigure 24. In the figure both Knowledge and Machine domains are subjects of design,as are their shared user interface phenomena.An example of how a real-world sociotechnical problem could be treated in the new modelis that of designing a “cold-calling” system to allow an interviewee to be telephoned andfor their responses to certain questions, asked by an interviewer, to be recorded in adatabase for future analysis. The problem is to design both the technical subsystem (themachine domain) and the instructions that guide the interaction of the interviewer (theknowledge domain) with the interviewee. The interviewee sits firmly in the environment(as a biddable, indicative domain). The interaction with the database is a machine task.The outcome of the design process, in addition to the specification for the technicalsubsystem, might be a script for the interviewer and the human-machine interface as usedby the interviewer. The problem diagram for this example is outlined in Figure 25.

Figure 24. The general “sociotechnical problem” diagram

Figure 25. Outline problem diagram for the cold-calling system



Conclusion

In their classical form problem frames happily represent interactions between a user anda machine, as might be characteristic of simple sociotechnical systems. In this chapterwe have presented an enrichment of the PF framework to allow the representation andanalysis of more complex sociotechnical systems. To do this we have introduced two newproblem frames, the User Interaction and User Commanded Behaviour Frames. Althoughnot exhaustive in their treatment of socio-technological interaction problems, theyhopefully will provide a sound basis for a richer taxonomy of user interaction within thePF framework.One of the as-yet under-developed areas within the PF framework is the treatment ofproblem decomposition, in particular from the perspective of how to do it in practice. Weare currently exploring the development and use of AFrames. An AFrame offers guidancein problem decomposition on the basis of solution space structures. In this chapter wehave shown how basic sociotechnical interaction problems can be decomposed when thetarget architecture is to be the MVC style.Although both these enrichments are new in the PF framework, they do not move outsideof its original conceptual basis in the two-ellipse model of requirements analysis. Incontrast we have seen in this chapter that the development of general sociotechnicalsystems raises challenges for the PF framework. We have suggested solutions to thesechallenges in the reification of the two-ellipse model to a three-ellipse version, in whichsocial sub-systems – individuals, groups, and organisations – can also be consideredas the focus of the design process. With the introduction of the knowledge domain, themanifestation of this extension in problem frames, we aim to bring the sociotechnicalsystem problems under the design remit of the PF framework.

Acknowledgments

We acknowledge the kind support of our colleagues, especially Michael Jackson andBashar Nuseibeh in the Department of Computing at the Open University.

References

Bass, L., Clements, P., & Kazman, R. (1998). Software architecture in practice. SEI Seriesin Software Engineering. Addison Wesley.

Dieste, O., & Silva, A. (2000). Requirements: Closing the gap between domain andcomputing knowledge. Proceedings of SCI2000, II.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns. Addison-Wesley.



Gunter, C., Gunter, E., Jackson, M., & Zave, P. (2000). A reference model for requirementsand specifications. IEEE Software, 3(17), 37-43.

Hall, J. G., & Rapanotti, L. (2003). A reference model for requirements engineering.Proceedings of the 11th International Conference of Requirements Engineering,181-187.

Jackson, M. (1995). Software requirements & specifications: A lexicon of practice,principles, and prejudices. Addison-Wesley.

Jackson, M. (1997). Principles of program design. Academic Press.Jackson, M. (2001). Problem frames. Addison-Wesley.Jackson, M. A. (1998). Problem analysis using small problem frames [Special issue].

South African Computer Journal, 22, 47-60.Leveson, N. (1986). Software safety: What, why and how. ACM Computing Surveys,

18(2), 125-163.Nuseibeh, B. (2001). Weaving together requirements and architectures. IEEE Computer,

34(3), 115-117.Rapanotti, L., Hall, J. G., Jackson, M., & Nuseibeh, B. (2004). Architecture-driven problem

decomposition. Proceedings of the 12th International Conference of Require-ments Engineering.

Zave, P., & Jackson, M. (1997). Four dark corners of requirements engineering. ACMTransactions on Software Engineering and Methodology, 6(1), 1-30.

340 Cronholm and Goldkuhl


Chapter XX

CommunicationAnalysis as Perspective

and Method forRequirementsEngineering

Stefan Cronholm, Linköping University, Sweden

Göran Goldkuhl, Linköping University, Sweden

Abstract

In this chapter we challenge the view of perceiving information systems as systems forstoring, retrieving, and organizing large amounts of data. We claim that the mainpurpose of information systems is to support the communication that takes placebetween different actors in a work practice. We describe a communication perspectiveon information systems and its consequences for performing requirements engineering.In this perspective business documents play a prominent role. The perspective isoperationalized into a method and an example from a case study is used in order todescribe the method.

Communication Analysis as Perspective and Method for RE 341


Introduction

Traditionally information systems (IS) are viewed as systems for storing, retrieving, andorganizing large amounts of data. The aim of implementing IS has often been to achieveincreased efficiency in business administration processes. This old view of IS can bechallenged since IS nowadays are an integrated part of the daily work when performingdifferent work activities. We believe that IS are more than a support for storing andretrieving data and claim that one of the main purposes of an IS is to support thecommunication that takes place between different actors in a work practice.The purpose of this chapter is to describe a communication perspective of IS and itsconsequences for performing requirements engineering (RE). The communication per-spective is operationalized into parts of an RE-method. The proposed method is not acomprehensive method for RE. The aim is to cover some aspects of the RE process thatunfortunately are too often disregarded.A case study is used to illustrate the perspective and method. The case study concernsdevelopment of an IS to support home care service for elderly people. The conclusionsare based on both existing theory and empirical findings. After this introductory sectionthe communication perspective is discussed in the next section. In the next section theconcept of document is defined. In the section following that we present communicationanalysis (CA) as a strategy for RE. The next section informs about how to perform CA.In the final section we end up with conclusions.

The Communication Perspective

We will argue for viewing IS as work practice communication. The theoretical bases forthis view are social action theory (for example, Weber, 1978) and language action theory(Goldkuhl & Lyytinen, 1982; Habermas, 1984; Searle, 1969; Winograd & Flores, 1986) andconversation analysis (Goldkuhl, 2003; Linell, 1998; Sacks, 1992). One of the main pointsin Weber’s theory of social action is that such action is intentional and performed takinginto account the behaviour of other persons. Social actions are performed with socialgrounds and with social purposes. Using a social action perspective means that it is notacceptable to view IS as a black box with some social and organizational consequences(Dietz, 2001). IS should be perceived as systems for action.The language action theory conceives communication as one type of action. Communi-cation is not restricted to a mere transfer of information. To communicate is to establishinterpersonal relationships between the sender and the receiver. Language actiontheories (for example, Searle, 1969) distinguish often between the propositional contents(what is talked about) and the communicative function (what kind of interpersonalrelationship is established) of a message. Such communicative relationships involveexpectations and commitments between the communicators.In this language action perspective, IS are viewed as sociotechnical systems for action.This view differs from strict representational views of information. A representational



view of information means that designers try to create an “image” of the reality in orderto have the analysed piece of reality properly represented in the system’s database. Thisstrict representational view can be challenged from a language action perspective (forexample, Goldkuhl & Lyytinen, 1982; Winograd & Flores, 1986). In a language actionperspective, IS are not considered as “containers of facts” or “instruments for informa-tion transmission” (Goldkuhl & Ågerfalk, 2001). This perspective emphasises what usersdo while communicating through an IS (Goldkuhl & Ågerfalk, 2001). IS are sociotechnicalsystems for action in work practices, and such actions are the means by which workpractice relations are created.Conversation analysis is an approach for studying the organisation of communication,that is, how utterances are related to each other. There are utterances that are closelylinked to each other. Adjacency pairs (Sacks, 1992) consist of a first utterance followedby a second. The first functions as an initiative for the second, which functions as aresponse (Linell, 1998). Such a second utterance may be dialogically multifunctional. Itmay not only be a response; it may also function as an initiative for following utterances.From these theoretical bases we propose a communication perspective. People inorganisations communicate with each other through oral and written messages. Commu-nication in organisations is performed in order to transfer knowledge and establishcommitments and other relations between people (Cronholm & Goldkuhl, 2002a; Goldkuhl& Röstlinger, 2002). This need for communication can be supported by IS. A communi-cation perspective means that information systems are regarded as systems for technol-ogy-mediated work practice communication. From this perspective IS are seen asvehicles for people to communicate with each other. An IS is a social and a technicalsystem. It is a social system since it is a system for communication between organisationalactors. At the same time it is a technical system using computer hardware and software.This sociotechnical perspective is founded on the concept of IS actability. Actability isdefined as an IS’s ability to perform actions and to permit, promote, and facilitate usersto perform their actions both through the system and based on messages from the system,in some work practice context (for example, Cronholm & Goldkuhl, 2002b; Goldkuhl &Ågerfalk, 2001; Ågerfalk, 2003).

Documents as CommunicationInstruments

Documents are information sources and are, for example, used for commitments, agree-ments, planning, and as reminders. A document could be a sheet of a more formal andstructured character. It could also be an informal piece of paper containing hand-writteninformation. Documents can also be computerised. Any form on a user interface can beseen as a document.Documents play an important role in work practices. Documents are something that isproduced, used, and changed. To create a document (or parts of it) is to be seen asperforming a communicative act. An actor in the work practice not only representssomething in a document. He or she also creates certain relationships (commitments,



expectations, and so forth) with other persons when writing something in a document.This is in accordance with language action theory and how it has been adopted in theIS area (see the section on communication perspective).Documents have important characteristics that distinguish them from oral utterances.Documents have persistence. People can read them and save them and read them again.Documents can also be changed. A person can add something to an existing documentor change something in it. This means that documents can be results of severalcommunicative acts, which also can be performed by different people. Documents (formsand so forth) in a work practice play important roles when used as communicationinstruments for performing the work practice. Such documents represent important actsin the work practice, and they are also used to externalise work knowledge, thus beinga collective external memory for the work practice.The documents are also carriers of the work language of the practice. Being representa-tions of actions, knowledge, and language in the work practice, documents are not onlyinstruments for performing the work practice, they are also instruments for constitutingthe practice. Because of these fundamental characteristics, we assert that work practicedocuments are important means for studying and understanding a work practice (Goldkuhl& Röstlinger, 2002).

Requirements Engineering as MetaCommunication

The aim of this section is to describe CA as an RE strategy. We describe in the next sub-section an overview and motivate the importance of analysing documents. In the secondsub-section a set of questions is proposed. The aim of these questions is to support theanalysis of the documents. The questions are structured into a communication modelconsisting of three related communicative categories: conditions, actions, and conse-quences.

RE Strategy

RE is a process of creating, eliciting, and stating requirements for future IS. Followingthe perspective of IS as a sociotechnical system for work practice communication, thisimplies that RE can be seen as meta communication. RE is communication (throughanalysis and design) about current and future work practice communication.In order to capture and analyse work practice communication we propose an examinationof existing documents. There are many reasons for choosing existing documents as astarting point in an RE process:



• work practices usually have a large number of documents• a major part of the language/concepts used in the organisation may be represented

in the documents• the documents function as result of action and as conditions for subsequent

actions• the language/concepts in the work practice documents is familiar to the users

The last point is important in relation to the strategy for RE. In order to establish aparticipative RE process with high involvement of the users there is a need to createappropriate conditions for such participation. We start working with what is known andfamiliar to the users. The documents used in the work practice are usually well known tothe users. A study of such documents will reveal the action and communication logic ofthe work practice. This will be done in ways that are comprehensible to both users andanalysts.Interviews are recommended as a complementary eliciting technique. Interviews mayhave several purposes. One purpose is to gather initial information about the workpractice studied. Such an introductory understanding and overview of the work practicesupport the analysis of existing documents. Interviews can also be used as a support forin-depth studies of documents. Such interviews can be used to explicate what seemsunclear or ambiguous from studying the documents.From such an understanding of current practice it is possible to move on to articulatingthe requirements for a new system. A new system will probably mean a development ofthe work practice documents, and this may also entail a shift of media. Such a change ofmedia will imply the introduction of IT-based (information technology-based) screendocuments (user-interfaces) in the new system. The design of future documents will, ofcourse, be more abstract to the users than examining the current documents. It isimportant that this document design does not become too abstract and incomprehensiblefor the users. An active use of prototypes (Ehn, 1988) can assist in making the futuredesign more concrete. A retroactive link back to the existing documents (and theircontents and functions) may support the accountability and comprehensibility of thenew documents to all actors involved in the RE process (Cronholm & Goldkuhl, 2002a).The RE process that we propose is divided into three iterative phases: describe – examine– redesign.

Communication Analysis of Documents

Important parts of the RE process will consist of a communicative analysis of documentswithin the work practice. This means to analyse existing documents as well as future IT-based documents. This analysis of documents and concepts is supported by a set ofquestions and some modeling techniques. Due to limited space we point out referencesto where the modeling techniques used are thoroughly explained. The formulations ofthe questions are derived from the theory discussed in the section on communicationperspective and also inspired from qualitative analysis (Strauss & Corbin, 1998). As can



be seen below some of the questions overlap. This is a kind of triangulation, and thereforewe view it as a strength (Denzin, 1978). The purpose of asking these questions is toimprove the communication in the work practice. We have structured the questions ina communication model consisting of three related communicative categories: condi-tions, actions, and consequences (see Figure 1).Each of these categories is divided into sub-categories, and each sub-category consists ofseveral questions to be asked. Below we present the proposed questions for each (sub-)category. The questions are generic in the way that they should be asked during theanalysis of existing documents as well as for future IT-based documents.

Communicative Conditions

Creation:• When is the information created?• What are the circumstances for creating the information?• Why is the information communicated?• What is needed in order to create information in the document?• What kinds of work practice rules govern the creation and use of the document?

Sender:• Who is the communicator?• Is there anyone mediating (transferring) the information/document?

Figure 1. Communication model

Creation

Communicative functions

Content

Media Consequential actions

Communicative actions

Communicative conditions

Sender

Communicative consequences

Receiver



Communicative Actions

Content:• What is communicated? What is the content of the document?• What are the meanings of different concepts?• Is the terminology comprehensible and well known?

Communicative functions:• What communicative functions does the document carry?• What kind of communicative relations are created between sender and receiver?• Are communicative functions expressed explicitly?• Is the document a response to preceding actions (initiatives) within the work

practice?

Media:• What kind of media is used for the document?• How is the document stored, accessed, retrieved, used, and changed?

Communicative Consequences

Consequential actions:• What actions are taken based on the information in the document?• Is there a clear initiative-response relation between the document and its conse-

quential actions?• For what purposes is this information used?• Might there be any possible side effects of the document utilisation?

Receiver:• To whom is the information in the document addressed?• Are there actors updating (changing) the document?• What kind of knowledge of the receiver is presupposed in the communication?



How to Perform CommunicationAnalysis

The aim of this section is to illustrate CA. The illustrations used are from a case abouthome care service. First we briefly present the case study. Second we describe onerepresentative document from the home care service and the communicative situationswhere this document is used. Third we present how we have examined this document withCA. Fourth we give an example of how the document could be redesigned in a future IT-based solution. Finally we reflect upon some of the experiences achieved from using CA.

Briefly About the Case

The studied case is a home care unit. The home care unit helps elderly people in their dailylife. The major tasks of the home care are to help the elderly with daily hygiene, minormedical tasks, cleaning, doing laundry, and so forth. In order to communicate informationand structure their work, the home care assistants use a number of self-made as well aspre-printed documents (for example, journals, diaries, note pads, schedules, and soforth). These self-made documents are used for planning and carrying out tasks. Thedocuments are also used for transferring knowledge between the assistants. Each clienthas individual needs, and therefore the tasks that will be performed vary. A work practicegoal is that a maximal individualisation of care should be given. The personnel consistof two directors and a number of assistants. The case study was performed in a medium-sized Swedish local authority. Researchers, assistants, and directors participated ac-tively in the case study.Clearly there is a lot of communication going on in the home care unit. There iscommunication between different roles, such as between planners and performers,between directors and assistants, and between assistants and clients. There is alsocommunication between the actors of same role (assistant to assistant, director todirector). For example, the assistants work in shifts. This means that the day shift has tohand over information about clients to the night shift and vice versa. The goal that amaximal individualisation of care should be given for each client demands a highcommunication quality. We consider this work practice as a complex sociotechnicalsystem. The personnel can be classified as computer novices. They have little experienceof interacting with computers. The participants in the ISD process from the home careunit can be classified as novices. It was their first participation in an RE-project.

Describing the Document “Morning Tasks” and ItsCommunicative Situations

The document that we have chosen for illustration is labelled “Morning task” (see Figure2). The reason for choosing this document is that it is frequently used in the assistant’sdaily work with clients. The document consists of four columns: 1) the apartment number



that informs the assistant about the client’s address, 2) a time that informs them whento visit the client, 3) a name that informs who to visit and 4) a task description that informsthem what to do. The tasks can be viewed as agreed commitments to the clients.First, we have identified three communicative situations where the document is used (seeFigure 3):

• Planning tasks• Choosing tasks• Resetting the document

In order to understand each situation, we have used a diagram. In the diagram we havefor each situation modeled how the sender, the receiver, and the actions are related tothe document. The diagram also shows how the three situations are related to each other.In the first communicative situation a scheduler plans the tasks. New or changed tasksare manually added (hand-written) to the document. The scheduler informs the perform-ers when there are new or changed tasks by manually adding them to the document. Thedocument is placed in a plastic folder. The procedure for choosing a task is the following.The home care assistant reads the document in order to locate the next appropriate task.Before the home care assistant visits the client she simply draws a line with a marker penon the plastic folder over the actual task. The aim of drawing this mark is to inform otherassistants that this task is being performed. After the marking the home care assistantperforms the task. When the home care assistant returns from the visit, she reads thedocument in order to locate the next appropriate task. The next day the administrator rubsout all the markings. The administrator is “resetting” the document so it can be re-usedfrom one day to another.As you can see in Figure 3, there are different communicative situations consisting ofdifferent roles communicating with each other. The document has also different commu-nicative functions depending on the situation. In the “planning-situation” the commu-nicative function is to inform performers about the tasks that should be carried out. Inthe “choosing task-situation” the communicative function is to inform performers of

Figure 2. Morning tasks

Morning tasks

Apartment

number

Time Name Task

1414 07:15 Roy Visiting the bathroom Monday - Wednesday - Friday

1406 07:30 Fanny Dressing, visiting the bathroom Tuesday - Thursday

203 07:30 Douglas Make the bed, medicine

108 07:30 Elisabeth Hygiene, dressing

204 07:45 Ada Eye drops, change socks

... ... ... ...



which tasks are performed and which are not. In the “resetting-situation” the communi-cative function is to inform performers about the tasks for the next day.

Examine the Situation of Choosing a Task

In the following examination we have chosen the communicative situation “choosing atask.” The reason for choosing this situation is that it is a limited but rich example forillustrating how we have used CA. In the examination we follow the communication modelpresented above (see section on communication analysis of documents). The sectionends with a summing up of identified problems.

Examination

Communicative Conditions

Creation:• What is needed in order to create information in the document?

Needed information for choosing a task is planned tasks and information aboutwhich tasks already have been performed. Based on this information the assistantscreate new information. The assistants choose an unperformed task and mark thetask as performed.

Figure 3. Document Activity Diagram: current work practice communication

New and changedtasks

PerformerScheduler

Document: Morning tasks

Media: Paper in plastic folder

Add, change

Read

Administrator

Reset

Chose

Read

Performer Client

Performingtask

Resetting situation

Choosing situation

Planning situation



• When is the information created?The marking of a chosen task is done just before the assistant leaves the office tovisit the client. However this marking is not dated. The reason for not using a dateis that the same document is used every day. One problem identified with thisroutine is that there is no way to track which tasks actually have been carried out.This means that there is a problem of quality assurance. There is no possibility totrace what actually has been done or not for the clients.

• Why is the information communicated?The information (the marking) is communicated in order to inform other performersabout which tasks have been carried out and should therefore not be chosen byother assistants.

• What are the circumstances for creating the information?The marking takes place when the assistants are on their way to a client, not whenthe task is carried out. Sometimes the assistants are interrupted by other duties, andthis interruption means a risk for an inconsistency between the aim of the markingand tasks that actually have been carried out. This problem means that there is aneed for identifying the status of each task. Possible statuses are not performed,started, and performed.

• What kinds of work practice rules are governing the creation and usage of thedocument?Each client has individual needs, and therefore the tasks that will be performed foreach client varies. A work practice goal, derived from the Social Welfare Law, is thata maximal individualization of care could be given.

Sender/Communicator:• Who is the communicator?

Who the communicator is could not be read from the document. In this case thecommunicator is the performer of a task. The performer is not visible in thedocument, and the fact that all the markings are rubbed out from one day to anothermakes it hard to follow up who was responsible for performing the task. In otherwords, the possibility to trace “who has said what” could not be read from thedocument.In order to vary tasks over time among the assistants, they plan for rotation.However this rotation is not always followed. Sometimes the planned performer isthe actual performer and sometimes not. This makes it even harder to trace the actualperformer. One reason that the communicator should be written in the documentis if there are any complaints from the clients or from the relatives of the clients.Omitting the communicator means that the home care unit has a problem withidentifying who has done what.

• Is there anyone mediating (transferring) the information/document?No.



Communicative Actions

Content:• What is communicated? What is the content of the document?

The information that is communicated consists of apartment number, time, firstname, and the task. However some concepts are missing. Sometimes the tasks arenot carried out, since the client could be in hospital or visiting relatives. This meansthat there is need for a column that informs about why a task need not be performed.There is also a need for identifying the status of a task (see question “What are thecircumstances for creating the information?”). The concept of status is needed.Other missing concepts are performer and planned performer (see question“Sender”).

• What are the meanings of different concepts?The apartment number is present in order to be able to locate the client. The timeinforms the home care assistant when to visit the client. The task column informsthe home care assistant what to do. When studying the document closer, you couldsee that there also are weekdays noted in the task column. This extra informationinforms the assistants about which weekdays the actual task should be carried out.In order to understand the meaning of occurring concepts and how they relate toeach other, we have modeled the concepts in the class diagram (for example,Kruchten, 1999). This model is, however, not illustrated in the chapter.

• Is the terminology comprehensible and well known?The terminology for the document is consistent and comprehensible apart from thatweekdays occur in the task column. This need of writing weekdays in the taskcolumn is a sign of a weak conceptual modeling. Since the tasks vary amongweekdays, it is not adequate to inform about hours and minutes in the time column.There are specific efforts that vary among the weekdays. These specific andvarying efforts are hard to manage, since there is not enough space in thedocument.

Communicative functions:• What communicative functions does the document carry?

The document has several functions. One function is a planning (directive)function. This means that the document should inform the assistants about whichtasks should be performed. Another function is a reporting function. This meansthat the assistants report which tasks have been carried out.

• Are communicative functions expressed explicitly?The planning function could be expressed more explicitly (see question “Is theterminology comprehensible and well known?”). The reporting function is not clearsince the task is marked when the assistant is on her way to a client. The receiverinterprets the marking as if the task is performed.



• What kind of communicative relations are created between sender and receiver?When the home care assistant draws a line with a marker pen, she commits herselfto the performance of the task. At same time she informs other assistants that theyshould not perform this task. This means that there is a relation created betweena sender and a receiver. But the sender is not made explicit (you cannot read thesender from the document) and therefore not visible. Sometimes there is a need tobe more informed about a specific client. This information can be achieved byasking colleagues. The omission of the sender makes it harder to identify thecolleague who has the specific information about a specific client. In Figure 2 wehave modeled the actual communicative situation. That means that the relationbetween the sender and the receiver is made explicit (see Figure 2).

• Is the document a response to preceding actions within the work practice?The document is a response to the preceding action of planning tasks. In order toidentify the order between different communicative situations and actions, we haveused action diagrams (Goldkuhl & Röstlinger, 2003) that are not included in thischapter.

Media:• What kind of media is used for the document?

A paper document in a plastic folder is used. Changes in the document are writtenby hand. The problem with hand-written changes is that they could be hard to read.They could also be hard to understand due to lack of formality.

• How is the document stored, accessed, retrieved, used, and changed?The document is placed on the assistants’ desk. Data is accessed and used byreading the document. Data is changed and added by hand. The data aboutperformed tasks is not stored.

Communicative Consequences

Consequential actions:• What actions are taken based on the information in the document?

The receiver identifies which tasks are not performed, chooses one unmarked task,and performs the chosen task.

• Is there a clear initiative-response relation between the document and its conse-quential actions?Yes, the assistant responded by performing the task.

• For what purposes is this information used?In order to identify which task has been carried out and which has not.

• Might there be any possible side effects of the document utilisation?If something unusual has happened to the client, a note is made in the client’sjournal.



Receiver:• To whom is the information in the document addressed?

The information is addressed to other assistants.• Are there actors updating (changing) the document?

It is important to understand that the assistant alternates between the roles ofsender and receiver. In the current situation the assistant in the role of receiverreads information from the document, and in the role of sender the assistantupdates the document (marking a task).

• What kind of knowledge of the receiver is presupposed in the communication?The receiver must understand the meaning of the marking. As discussed above themarking means only an intention to visit a client. Sometimes the home care assistantis interrupted by other duties on her way to a client, and she may not fulfil herintention, at least not immediately.

Summing up the Identified Problems

In order to present a summary of the identified problems, we use a problem list. Whena lot of problems occur, a problem diagram can be used that shows how the problems arerelated to each other (Goldkuhl & Röstlinger, 2003).

P1 The information created in the document is not dated (hard to follow up)P2 A risk for an inconsistency between the markings and tasks that have been carried

out.P3 The communicator (the scheduler) is not visible.P4 The receiver (a possible performer) cannot read the sender (an actual performer)

from the document.P5 The performer of a task is not visible.P6 Changes in the document are written by hand (hard to read, lack of formality, hard

to manage tasks that are occasional).P7 Reasons for not performing a task are omitted.P8 Weekdays occur in the task column.P9 The communicative function is not clear since the task is marked when the home

care assistant is on her way to a client. The receiver interprets the marking as if thetask has been performed.



Redesign: A Future IT-Based Document “Choice ofTasks”

Based on the problems identified from the examination of the document “Morning task”we have proposed a redesign. This origin paper-based document is divided into threeIT-based documents that correspond to the communicative situations (see Figure 4).

• Plan tasks• Plan performer• Choose and report task

In this chapter we illustrated the situation of choosing and reporting tasks (see Figure5). Since the aim of this chapter is to present a communication perspective on IS, we willjust briefly point out the improvements made to the document examined.

• A date stamp is added in the upper left corner that relates to each task (P1).• Three different statuses are added for a task: not done, started, and done. The

assistants register the status for each task by clicking on the button “Register taskas…” (P2, P9).

• The communicator has been made easily accessible. In the lower left corner thereis a button labelled “Open plan tasks.” A click on this button opens a new documentfrom where the scheduler of a task could be read (P3).

Figure 4. Document Activity Diagram: Future work practice communication

New and changed tasks

Scheduler

Document: Task schedule

Media: IT-form

Add, change

Read

AssistantRead

Client

Performingtask

Situation: Choosing

Situation: Planning tasks

Document: Planning tasks

Media: IT-form

Add, change

Read

Situation: Planning performers

Document: Planning performer

Media: IT-form

Scheduler

Mark

Read

Mark

Assistant

Assistant

Situation: Reporting



• The columns planned performer and (actual) performer are added. The default valuefor the actual performer is the planned performer. This actual performer can bechanged (P4, P5). This means that the performers are visible and that all performedtasks are related to a specific performer.

• An IT-based solution eliminates the problem of hand-written information. It alsoreduces the problem of limited space. This means that information that supportsmaximal individualisation of care can be added. It also supports accessing of storeddata. The upper part of the document consists of possibilities to access differentsubsets of tasks. For example, changing the date means that another selection oftasks will be presented. Changing the time from morning to evening will also showanother subset of tasks (P6).

• The column “Task is not done, reason” is added to the document (P7).• A date and a time stamp are used. Further the content of a task is just outlined.

Detailed information of task can be achieved by either double-clicking on the taskor by clicking on the button “Show task details” (P8).

Conclusion

Using CA and the proposed questions as driving forces for RE have revealed severalproblems. For example, the simple questions “When is this document created?” and

Figure 5. Proposed IT-based solution



“Who is the communicator?” have revealed a major problem of quality assurance. Thefirst question identified a problem of traceability of what has been done for a client andwhen it has been done. The second question identified that the communicator is omittedin the document. This means that it is hard to trace the responsibility for a performed task.According to the theory of actability the communicator should be visible (for example,Ågerfalk, 2003). All of the questions proposed have in one way or another supported thediscovery of problems.The theoretical basis used has supported the RE process. Language action theory andconversation analysis have contributed to view IS as communication systems. Thismeans that there has been a support for establishing explicit relationships betweendifferent actors and between different roles in the business (between senders andreceivers of information) and a support for identifying what should be communicated andwhen.This approach recommends starting with what is known and an analysis of existingdocuments. In a familiar situation the participating users would not be novices; theywould be experts. A possible problem with this recommendation might be that there isa risk of focusing too much on existing practices and not being open for new, innovativeideas. This approach does not exclude the possibility of incorporating innovativesolutions. A professional designer should have a competence and responsibility forbeing sensitive and suggestive of new alternative solutions when there is a risk of a too-limited focus. Starting with what is known can be seen as an objection against theBusiness Process Reengineering (BPR) argumentation about starting development witha “clean slate” (Hammer & Champy, 1993). In order to create radically new businessprocess, one should, according to classical BPR, think away the current processes. Wedoubt that BPR is a proper approach when involving novice users.There are major differences between CA and popular object-oriented approaches. Weemphasise IS as communication systems. Object-oriented approaches (for example,Rational Unified Process (Kruchten, 1999) and OOA&D (Mathiasen, Munk-Madsen,Nielsen, & Stage, 2000)) seem to focus too early in the RE process on concepts like classesand objects. Identifying classes and objects are important but more fundamental is toanalyse the work practice communication. The handling of objects and classes in an ISis a consequence of the desired communication.Our perspective and method can be used together with other RE methods, object-oriented as well as other methods. The communication perspective guides analysts andusers to focus on communication issues as documents, work practice language, commu-nicative actions, and actors. Our method for CA is not a comprehensive method for RE.It only covers some aspects of the RE process; however, they are very important andunfortunately too often disregarded. CA, as described here as an RE method component,can and should be used together with other RE methods.We think, for example, that several of the notations suggested in object-orientedapproaches could be used together with CA. We think that use cases (Jacobson,Christerson, Jonsson, & Overgaard, 1992) can been used in order to identify differentcommunicative situations (see 0). Another notation that can be used is State TransitionDiagram. Such diagrams seem promising in order to identify which possible communica-tive actions can be performed in a certain state. A third object-oriented notation is Class



Diagram (for example, Kruchten, 1999). Class diagrams have been used in this case study(however, not exemplified) in order to understand the meaning of occurring concepts andhow they relate to each other.

References

Cronholm, S., & Goldkuhl, G. (2002a, April 10-12). Document-driven systems develop-ment - An approach involving novice users. Proceedings of the 7th AnnualConference of United Kingdom Academy for Information Systems (UKAIS), Leeds,UK.

Cronholm, S., & Goldkuhl, G. (2002b, September 12-14). Actable information systems -Quality ideals put into practice. Proceedings of the 11th Conference on InformationSystems Development, Riga, Latvia.

Denzin, N. K. (1978). The research act. New York: McGraw-Hill.Dietz, J. (2001). DEMO: Towards a discipline of organization engineering. European

Journal of Operational Research, 128(2).Ehn, P. (1988). Work-oriented design of computer artifacts. Stockholm: Arbetslivscentrum.Goldkuhl, G. (2003). Conversational analysis as a theoretical foundation for language

action approaches? Proceedings of 8th Int Working Conference on the LanguageAction Perspective (LAP2003), Tilburg.

Goldkuhl, G., & Lyytinen, K. (1982). A language action view of information systems.Proceedings of third International Conference on Information systems, Ann Arbor,MI.

Goldkuhl, G., & Röstlinger, A. (2002). The practices of knowledge – investigatingfunctions and sources. Proceedings of the 3rd European Conference on KnowledgeManagement (3ECKM), Dublin.

Goldkuhl, G., & Röstlinger, A. (2003). The significance of workpractice diagnosis:Socio-pragmatic ontology and epistemology of change analysis. Proceedings ofthe International workshop on Action in Language, Organisations and InformationSystems (ALOIS-2003).

Goldkuhl, G., & Ågerfalk, P. (2001). Actability: A way to understand information systemspragmatics, in coordination and communication. In K. Liu, et al. (Eds.), Using signs:Studies in organisational semiotics - 2. Boston: Kluwer Academic Publishers.

Habermas, J. (1984). The theory of communicative action 1. Reason and the rational-ization of society. Cambridge: Polity Press.

Hammer, M., & Champy, J. (1993). Reengineering the corporation. A manifesto forbusiness revolution. London: Nicholas Brealey.

Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object-orientedsoftware engineering: A use-case driven approach. Addison-Wesley.



Kruchten, P. (1999). The rational unified process: An introduction. Reading, MA:Addison Wesley.

Linell, P. (1998). Approaching dialogue. Talk, interaction and contexts in dialogicalperspectives. Amsterdam: John Benjamins Publ.

Mathiassen, L., Munk-Madsen, A., Nielsen, P.A., & Stage, J. (2000). Object-orientedanalysis & design. Marko Publishing House.

Sacks, H. (1992). Lectures on conversation. Blackwell.Searle, J.R. (1969). Speech acts: An essay in the philosophy of language. London:

Cambridge University Press.Strauss, A., & Corbin, J. (1998). Basics of qualitative research. Techniques and

procedures for developing grounded theory. Beverly Hills, CA: Sage Publications.Weber, M. (1978). Economy and society. Berkley, CA: University of California Press.Winograd, T. & Flores, F. (1986). Understanding computers and cognition: A new

foundation for design. NJ: Ablex Publishing Corporation.Ågerfalk, P.J. (2003). Information systems actability: Understanding information tech-

nology as a tool for business action and communication. Doctoral dissertation.Linköping University, Linköping, Sweden.

About the Editors 359


About the Editors

José Luis Maté is full professor of computer science at the Universidad Politécnica deMadrid (UPM), Spain. He has served as vice-provost of the university and also asdean of the School of Computer Science. He received his telecommunications engineer-ing degree and PhD from UPM. His work on information system design is one of his mostprominent activities, an area in which he advises several Spanish and internationalinstitutions, including the upper and lower houses of the Spanish Parliament. He was adesignated member for the Spanish government in the Spanish Commission for the Y2K.He is the author of several books and papers related to the integration of software andknowledge engineering and in the field of learning environments.

Andrés Silva is a lecturer of software engineering at Universidad Politécnica de Madrid(UPM), Spain, where he is responsible for teaching requirements engineering. He hasthree years of industrial experience in software development and has worked at the JointResearch Centre (JRC) of the European Commission. In 2001 he received a PhD incomputer science from UPM. His research interests are requirements engineering andknowledge management. He is the author of several conference and journal papers inrequirements engineering.

360 About the Authors


About the Authors

Juan Pablo Carvallo is a doctoral candidate at the Universitat Politècnica de Catalunya(UPC), Spain. He received his degree in computer science from the Universidad deCuenca, Ecuador. His interests are COTS-based systems development and COTSselection, evaluation, and certification. He is currently a member of the GESSI group atthe UPC. His research interests are selection of COTS components, quality modelconstruction, and component-based software development. He has been nominated forthe best paper award in ICCBSS’04.

Juan Ares Casal is director of the Department of Information and CommunicationsTechnologies of the University of A Coruña (Spain). He is an associate professor andco-director of the Software Engineering Laboratory at the university. His main researchinterests in computer science include conceptual modeling, knowledge management andsoftware process assessment. He worked as director and consultant in severalorganisations, including Norcontrol Soluziona and Arthur Andersen. He has a BS andPhD in computer science. He is editor of several books and author of numerous chaptersand refereed publications in software engineering.

Chad Coulin is a PhD candidate and member of the Requirements Engineering ResearchLaboratory with the faculty of information technology at the University of Technology,Sydney (Australia). He holds a BEng (honors) in microelectronics and is currentlyworking on the development of new and innovative methods and tools to supportrequirements elicitation for software-based systems. He has worked for a number of yearsin both the U.S. and Europe as a product and technical manager for leading internationalsoftware development companies.

Stefan Cronholm, assistant professor of information systems development at LinköpingUniversity (Sweden), earned his PhD from Linköping University (1998). He is co-directorof the Swedish research network VITS, consisting of nearly 40 researchers at six Swedish

About the Authors 361


universities. Area of interests other than requirements engineering are informationsystems evaluation, communication perspectives, and interpretive and qualitativeresearch methods. He is currently developing a theory of evaluation of informationsystems. Recent works about qualitative research methods are an analysis of GroundedTheory in use and a contribution to the development of Multi-Grounded Theory, (acombination of induction and deduction). For more information, visit [email protected] orwww.ida.liu.se/~stecr.

Angélica de Antonio has been a faculty member since 1990 in the Languages, Systems,and Software Engineering Department (of which she is currently sub-director) at theTechnical University of Madrid (UPM) (Spain), where she also has co-ordinated thedoctoral program since 2000. De Antonio has been director of the Decoroso CrespoLaboratory at UPM since 1995, where she has leaded several R&D projects in the areasof intelligent tutoring systems, e-learning, virtual environments and intelligent agents.De Antonio was a resident affiliate at the SEI (Carnegie Mellon University) during 1995.From 1991-1995 she was researcher at the Artificial Intelligence Laboratory (UPM) andassistant director of the SETIAM section of CETTICO (Center of Technology Transferin Computer Engineering) specializing in the transfer of computer technologies to assistthe disabled.

Christian Denger studied computer science at the University of Kaiserslautern with aminor in economics. He received his master’s in computer science in 2002. Since then hehas worked as a scientist at the Fraunhofer Institute for Experimental Software Engineer-ing in Germany. His research interests are software inspections in the context of defectcost reduction approaches in early development phases and the combination of qualityassurance techniques in the context of embedded systems. Currently he is involved inseveral German and international projects as team member and project leader and ispursuing a PhD from the University of Kaiserslautern.

Stefan Dietze studied business information systems at the University of CooperativeEducation in Heidenheim, Germany (1998-2001). As part of his studies he worked forSoftM Stuttgart GmbH, a developer of integrated business management software, andfor ID-Media in Berlin and Zurich, a multimedia service provider. After graduating witha German diploma in business information systems and with a BA (honors) in businessadministration, he started working as a research associate at the Fraunhofer Institute forSoftware and Systems Engineering in Berlin in 2001. There he is engaged in differentresearch activities as well as in consultation projects for the industry. His main researchfocuses are in the fields of software engineering processes and process modeling ingeneral. He is currently writing his doctoral thesis about the collaborative open sourcesoftware development processes.

Jörg Dörr received his master’s of science in computer science from the University ofKaiserslautern, Germany. He is working as a scientist, consultant, and business areamanager for the domain secure software for infrastructure facilities and services at the



Fraunhofer Institute for Experimental Software Engineering, Germany. His work areasinclude requirements engineering and agile software development, more specificallynon-functional requirements, and requirements engineering for ad-hoc systems such asambient intelligence systems. He is currently involved in several international andnational research and transfer projects.

Xavier Franch is an associate professor at the Universitat Politècnica de Catalunya(UPC), Spain. He received his PhD in informatics from UPC (1996). He has been a principaland co-investigator of several funded research projects. He is currently the leadinginvestigator of the GESSI (Software Engineering Group for Information Systems) groupat the UPC, a compound of more than 10 full-time researchers. His lines of research includerequirements engineering, COTS selection, and quality model construction. He hasparticipated in several industrial collaborations of COTS selection in the fields of ERPsystems, document management tools, health-care solutions, and others. He has pub-lished more than 40 papers in refereed international journals, at conferences, and otherevents. He has been nominated for the best-paper award in ICCBSS’03 and ICCBSS’04.

Javier Andrade Garda is assistant professor with the Department of information andCommunications Technologies of the University of A Coruña (Spain). His main researchinterests in computer science include conceptual modeling, knowledge management, andnatural language processing. He was software engineering and technological solutionsconsultant at IAL Software Engineering and Norcontrol Soluziona (Quality and Environ-ment Department). He has a BS and PhD in computer science. He is author of several bookchapters and refereed publications in software engineering.

J. L. Garrido is an associate professor in the computer science department at theUniversity of Granada (Spain). He obtained his PhD in computer science from the sameuniversity. His articles and research interests focus on requirements and softwareengineering, coordination models and languages, development of groupware systems,and notations for specification and modeling, particularly applied to interactive, coop-erative, and distributed systems.

M. Gea is a researcher in the computer science department at the University of Granada(Spain). He received his PhD in formal methods applied to interactive systems fromGranada University. His research focuses on human-computer interaction. The work isbased on formal methods and techniques for specification, design, and verification ofinteractive systems. He is a co-founder of AIPO, the Spanish Association of Human-Computer Interaction, and he had been a member of several program committees of relatedworkshops and conferences. Currently he is working on CSCW and extension to UML,usability methodologies, and ubiquitous computing.

Göran Goldkuhl, Professor of Information Systems Development at Linköping Univer-sity (Sweden) and Professor of Informatics at Jönköping International Business School,earned his PhD from Stockholm University (1980). He is the director of the Swedish



research network VITS, consisting of nearly 40 researchers at six Swedish universities.He is currently developing a family of theories, which all are founded on socio-instrumental pragmatism: Workpractice Theory, Business Action Theory, and Informa-tion Systems Actability Theory. He has a great interest in interpretive and qualitativeresearch methods and has contributed to the development of Multi-Grounded Theory,(a modified version of Grounded Theory). He is active in such international researchcommunities as Language Action Perspective and Organisational Semiotics. For moreinformation, visit [email protected] or www.ida.liu.se/~gorgo/ggeng.html.

Jaap Gordijn is an assistant professor in e-business at the Free University Amsterdam(The Netherlands), faculty of exact sciences. His research interest is innovative e-business applications. He is a key developer of and has internationally published on e-business modeling methodology (called e3-value) addressing the integration of strategice-business decision making with ICT requirements and systems engineering. Also he isa frequent speaker at international conferences. Recently he was a member of Cisco’sInternet Business Solution Group, and he was employed by Deloitte & Touche as a seniormanager of D&T’s e-business group. As such he was especially involved in rolling oute-business applications in the banking and insurance domains and in the digital contentindustry. For more information, visit http://www.cs.vu.nl/~gordijn.

D. Greer is a lecturer in the school of computer science at Queens University Belfast,UK. He has been lecturing to undergraduates and postgraduates in software engineer-ing-related topics for the past 12 years and carrying out research into risk management,incremental software processes, requirements engineering, and adaptive software de-sign. Prior to this he was an analyst/programmer with Bombardier, working on businesssupport systems. His DPhil is from the University of Ulster, and he is a member of theInstitute of Electrical and Electronics Engineers. Much of his current and past researchis industry related, including collaboration with NEC Corp., the U.K. Civil Service, andBritish Telecom.

Ines Grützner received a diploma in computer science and economics from the DresdenUniversity of Technology. She works as a scientist and project manager in the field ofdocument engineering at the Fraunhofer Institute for Experimental Software Engineering(IESE) in Kaiserslautern, Germany. Her research is focused on technology-enabledlearning, especially the systematic, engineering-style development of online courses.She has led several projects that are targeted at the development of online courses onsoftware engineering topics.

Jon G. Hall is a lecturer in the computing department at The Open University, UK. Hisresearch interests include requirements engineering and software architectures. Hiswork covers real-time, safety-critical, hybrid, and educational systems. He was co-editorof and contributor to Software Architectures: Advances and Applications (Springer-Verlag, 2000) and was a contributing member of the Z Standards committee. He holdsresearch grants to investigate correctness of safety critical systems, the foundations of



problem frames. Hall holds a BSc (Cantuar) and an MSc (Manchester) in pure mathemat-ics, an MSc (Newcastle) and PhD (Newcastle) in computing, and an MBA (Open). Formore information, visit http://mcs.open.ac.uk/jgh23/.

Ricardo Imbert is an assistant professor in the Department of Languages, Systems, andSoftware Engineering in the School of Computer Science at the Universidad Politécnicade Madrid (Spain). He is currently finishing his PhD on cognitive architectures for agentswith behaviours influenced by personality and emotion at the Universidad Politécnicade Madrid. Imbert has been a member and project leader at the Decoroso CrespoLaboratory at UPM since 1996, a research group of computer scientists blendingtechnologies such as virtual reality, software agents, and intelligent tutoring systems tocreate innovative computer learning environments.

Sara Jones is a research assistant with the Centre for Human-Computer Interface Designat City University (UK) and is currently working with Neil Maiden on the application ofthe Requirements Engineering with Scenarios for a User-centred Environment (RESCUE)process to various projects within Eurocontrol, the European Organisation for the Safetyof Air Navigation. She has been working in the fields of human-computer interaction andrequirements engineering since 1987 and has published more than 50 academic papersin conferences and journals in these areas. Sara has taught various courses in relatedareas and has supervised four PhDs, as well as sitting on the program committees forvarious conferences in the field of requirements engineering. For more information, visithttp://www-hcid.soi.city.ac.uk/pSarajones.html.

Daniel Kerkow holds a master’s of psychology from the University of Saarland,Germany. He works as a scientist and consultant in the field of requirements and usabilityengineering at the Fraunhofer Institute Experimental Software Engineering (IESE) (Ger-many), Europe’s largest organisation for applied software engineering research. He haslead several projects and was co-founder of the usability group at IESE. He focuses onnon-functional requirements, especially in the perception of usability quality aspectsand on usability engineering for processes and methods in software developingorganisations.

Tom Koenig received his master’s of science in computer sciences from the Universityof Kaiserslautern, Germany. He has worked as a scientist at the Fraunhofer InstituteExperimental Software Engineering (IESE) (Germany) since 2003, in the Department ofRequirements and Usability Engineering (RUE). His work areas include e-governmentand requirements engineering, more specifically elicitation and specification of require-ments as well as business processes modeling. He is currently involved in severalresearch and transfer projects in these areas.

Marco Lormans is a PhD student working in the software engineering group of the DelftUniversity of Technology, The Netherlands. His research interests are the specification,management, and evolution of requirements with special interests in the non-functional



properties of embedded systems. He holds a Master’s of Science in computer sciencefrom Delft University of Technology. Contact him at: [email protected].

Neil Maiden is professor of systems engineering and head of the Centre for Human-Computer Interface Design, an independent research department in City University’sSchool of Informatics (UK). He received a PhD in computer science from City University(1992). He is and has been a principal and co-investigator of several EPSRC- andEuropean Union (EU)-funded research projects, including SIMP, CREWS and BANKSEC.His research interests include frameworks for requirements acquisition and negotiation,scenario-based systems development, component-based software engineering, ERPpackages, requirements reuse, and more effective transfer of academic research resultsinto software engineering practice. Neil has published more than 100 papers in academicjournals and conference and workshop proceedings. Centre details are available fromwww-hcid.soi.city.ac.uk. For more information, visit http://www-hcid.soi.city.ac.uk/pNeilmaiden.html.

Raymond McCall, PhD, is as a member of the Institute of Cognitive Science and anassociate professor of planning and design at the University of Colorado (USA). Hisresearch has dealt almost exclusively with the design of software for the capture anddelivery of design rationale, and he created the first hypertext systems designed for thispurpose. His current interests are in the use of natural language processing for rationalecapture. Dr. McCall is also executive director of Nexterra, Inc., a non-profit corporationthat makes Web-based software for education. Nexterra is the creator of theExploreMarsNow.org Web site, which won a Webby and a Scientific American Sci-TechWeb Award. His graduate studies were in architecture and product design.

Line Melby is a PhD student in sociology at the Norwegian University of Science andTechnology (NTNU). Her research interests are medical sociology, science and technol-ogy studies, and methods and techniques for interdisciplinary system development.Melby is especially interested in ethnographic methods, and she performed a four-monthethnographic study at a hospital department as part of her dissertation work. Melbyreceived her master’s degree in sociology from NTNU (1999). In 2000 she joined theMOBEL (Mobile Electronic Patient Record) project at NTNU. Since 2003 MOBEL hasbeen part of the Norwegian Centre for Electronic Health Records Research in Trondheim.

Ivan Mistrik is currently a researcher at the Fraunhofer Institute (Germany), a majorresearch and development agency in the field of information and communication. He isa computer scientist who is interested in software engineering and software architecture,particularly requirements engineering and networked multimedia computing. He hasmore than 30 years’ experience in the field of computer systems engineering and has doneconsulting on a variety of large international projects sponsored by ESA, EU, NationalAeronatics and Space Administration (NASA), North Atlantic Treaty Organisation(NATO), and UN/UNESCO/UNDP. He has also taught university-level computer sci-ences courses in software engineering, software architecture, distributed information



systems, and human-computer interaction. His graduate studies were in the fields ofelectrical engineering, international economic relations, and computer science.

Eman Nasr is a research member of the Department of Mathematics and ComputationalSciences at the Faculty of Science, Cairo University in Egypt. Her research interestsinclude object-oriented requirements engineering approaches for embedded softwaresystems. She conducted research at the University of York, UK, while working on thePRECEPT project as a research associate on the use of use cases for the requirementsengineering of large complex embedded software. Nasr received a BSc with highesthonors in computer science from the American University in Cairo and an MSc incomputational methods from Cairo University, Egypt. She has more than 15 years ofindustrial software work experience.

Thomas Olsson works as a scientist and consultant at the Fraunhofer Institute forExperimental Software Engineering, Germany. He received a licentiate engineering insoftware engineering in 2002 and a master’s of science in computer science andengineering in 1999, both from Lund University, Sweden. His research interests are inheterogeneous information and documentation models, especially in the context ofrequirements. Currently he is involved in two European- and one German-funded project,is the project leader for two of them, and is at the same time pursuing a PhD degree at LundUniversity.

Barbara Paech holds the chair of software engineering at the University of Heidelberg,Germany. Since October 2003 she has been department head at the Fraunhofer InstitutsExperimental Software Engineering. Her teaching and research focuses on methods andprocesses to ensure quality of software with adequate effort. For many years she hasbeen particularly active in the area of requirements and usability engineering. She hasheaded several industrial, national, and international research and transfer projects. Sheis spokeswoman for the special interest group on requirements engineering in the Germancomputer science society and member of the accreditation board for the ASQF-CertifiedRequirements Engineer.

Päivi Parviainen (MSc) works as a senior research scientist at VTT Technical ResearchCentre of Finland (Oulu), Software Engineering Group, where she has worked since 1995.She graduated in 1996 from the University of Oulu’s Department of Information Process-ing Science. Her research activities include embedded systems and software processimprovement, requirements engineering, software reuse, and measurement. She hasmanaged several industrial projects at the national level and participated in many nationaland international research projects as well. She has published several papers in interna-tional journals and conferences.

Panayiotis Periorellis received his PhD from the University of Newcastle Upon Tyne(UK) in May 2000 for his thesis on modeling enterprise dynamics. He holds a master’s



degree and a bachelor’s degree in information systems analysis and design. He haspublished more than 25 articles, papers, and reports in journals and internationalconferences. He was part of the Dependable Systems of Systems consortium from June2000 until June 2003, addressing some of the technical but most importantly organisationalaspects of Systems of Systems. He currently works as a senior research associate atNewcastle University. His research interests include distributed systems, dependability,organisational aspects of systems, and modeling.

Carme Quer is associate professor in the software department (LSI) at the UniversitatPolitècnica de Catalunya (UPC), Spain. She received her PhD in software from the UPC.She is currently a member of the GESSI group at the LSI department. Her research interestsare selection of COTS components, quality model construction, and component-basedsoftware development. She has been nominated for the best-paper award in ICCBSS’04.

Lucia Rapanotti is a lecturer in the computing department at The Open University, UK.Previously she has held research and software development positions. Her main researchwork is in requirements engineering and software architectures. Among her recentpublications are works on problem frames foundations and extensions. Rapanotti holdsa number of grants for investigations into foundations of problem frames, evaluation ofgroupware in e-learning, and robotic adaptive controllers. Rapanotti holds a Laurea CumLaude in computing science from the University of Milan and a PhD in computing fromthe University of Newcastle upon Tyne. For more information, visit http://mcs.open.ac.uk/lr38/.

M.L. Rodríguez is an associate professor in the computer science department at theUniversity of Granada (Spain). She received her PhD from the University of Granada. Herresearch interests and publications are in the area of system modeling and softwaredevelopment, UML language, formal methods for specification, object-oriented meth-ods, human-computer interaction, usability, and cooperative systems.

Pete Sawyer holds a BSc and PhD from Lancaster University (UK), where he is a seniorlecturer in the Computing Department. His research interests are in the general area ofsoftware and systems engineering. In particular he is interested in requirements engi-neering, software process improvement, and applications of natural language process-ing to the systems engineering process. He is a member of the British Computer Society(BSC), an affiliate member of the Institute of Electrical and Electronics Engineers (IEEE),and a professional member of the Association of Computing Machinery (ACM). He isalso a member of the executive committee of the BCS Requirements Engineering SpecialistGroup (RESG). He has more than 50 peer-reviewed publications and is the co-author (withIan Sommerville) of Requirements Engineering – A Good Practice Guide (John Wiley,1997).

Gry Seland is a PhD student with the Department of Computer and Information Scienceat the Norwegian University of Science and Technology (NTNU). She earned her



master’s degree from the Department of Psychology at NTNU. During her PhD studiesSeland spent eight months at the University of Victoria, Canada, where she attendedcourses at the School of Health Information Science. Seland’s main research focus isdeveloping and evaluation of methods for user-centred development of informationtechnology systems in health care organisations. She has concentrated on role-play withlow-fidelity prototypes, giving end-users a tool for communicating their needs and ideasfor technology at the workplace.

Inger Dybdahl Sørby is a PhD student in computer science at the Norwegian Universityof Science and Technology (NTNU). Her research interests include medical informaticsand human-computer interaction. In particular she focuses on utilising user, context, andprocess knowledge in intelligent user interfaces to mobile electronic patient records.Sørby received her master’s degree in computer science at the Norwegian Institute ofTechnology (now NTNU) (1993). In 2001 she joined the MOBEL (Mobile ElectronicPatient Record) project at NTNU. Since 2003 MOBEL has been part of the NorwegianCentre for Electronic Health Records Research in Trondheim.

Maarit Tihinen (MSc) is a research scientist at VTT Technical Research Centre of Finland(Oulu), where she has worked since 2000. She graduated in 1991 from the University ofOulu’s Department of Mathematical Sciences. She worked as a mathematics and infor-mation technology teacher at Kemi-Tornio Polytechnic during the ‘90s. After coming tothe VTT she did her secondary subject thesis for the Department of InformationProcessing science (University of Oulu) (2001). Her current research interests involverequirements engineering during distributed software development and also softwareprocess improvement and measurement activities within the improvement process.

Rini van Solingen (PhD, MSc) is a principal consultant at LogicaCMG and a professorat Drenthe University, The Netherlands. At LogicaCMG he specializes in industrialsoftware product and process improvement. At Drenthe University he heads a chair inquality management and quality engineering. Van Solingen has been a senior qualityengineer at Schlumberger/Tokheim RPS and head of the quality and process engineeringdepartment at the Fraunhofer Institute for Experimental Software Engineering inKaiserslautern, Germany. Rini has published more than 100 titles in journals, conferenceproceedings, and books. He is a member of the IEEE-CS, NGI, KiVi and SPIder.

Rafael García Vázquez is director of the Computer Training Unit of the University of ACoruña (Spain). He is associate professor and co-director of the Software EngineeringLaboratory at the Department of Information and Communications Technologies of theUniversity of A Coruña. His main research interests in computer science includeconceptual modeling, knowledge management, and project management. He has beenproject leader in several organisations, including Quibus Computers and Sistema Base.He has a BS and PhD in computer science. He is editor of several books and author ofnumerous chapters and refereed publications in software engineering.



Antje von Knethen received her diploma degree in computer science from the Universityof Bremen (1996). Thereafter she was a member of the research group for softwareengineering in the Department of Computer Science at the University of Kaiserslautern,where she received a PhD in computer science (2001). In the same year she startedworking in the Requirements Engineering competence team at the Fraunhofer Institutefor Experimental Software Engineering (IESE) in Kaiserslautern (Germany). In 2002 shetook over the leadership of this competence team. Her research interests includerequirements engineering, in particular requirements management, object-oriented analy-sis, and empirical software engineering.

Santiago Rodríguez Yáñez is an assistant professor with the Department of Informationand Communications Technologies of the University of A Coruña (Spain). His mainresearch interests in computer science include conceptual modeling, knowledge manage-ment, and distributed systems development techniques and methodologies. He wasproject leader in several Spanish organisations. He has a BS and PhD in computer science.He is author of several book chapters and refereed publications in software engineering.

Didar Zowghi is associate professor of software engineering and director of Require-ments Engineering Research Laboratory in the faculty of information technology at theUniversity of Technology Sydney (Australia). She holds a BSc (Honors) and MSc incomputer science, and a PhD in software engineering. She serves on the programcommittee of many national and international conferences, in particular IEEE’s Interna-tional Conferences on Requirements Engineering since 1998. She is the regional editor(and the editor of the viewpoints column) of the International Requirements Engineer-ing Journal and associate editor of the Journal of Research and Practice in InformationTechnology (JRPIT). She has published extensively on many aspects of requirementsengineering.

370 Index


Index

Aacting out 267actions 251actors 251adaptability 190AFrame 320agent-oriented requirements engineering

69agent-oriented software engineering 69agents 69air traffic control 245architectural frame 320artifact lifecycles 204artifact management 203artifact metadata 203

Bbazaar 192boundaries 252bug reporting guideline 198bug reports 196bug tracking system 194bug triage 199Bugzilla 198

Ccapability maturity model for software

85Cartesian method 55cathedral 192central source code repository (CVS)

194change management 3, 160change requests 195clinical information systems 267cognitive task analysis 251collaborative RE 190collaborative requirements definition

191collaborative requirements review 199communication perspective 341complexity of the organisation 267composition 139computational aspects 58computational model 63computer domain 56computer-oriented 56conceptual model 228conceptual modeling 54conceptual models 54conceptualisation 54

Index 371


conceptualisation process 55conceptualisation techniques and

methods 54content-based retrieval 310cooperative systems 226core developers 194courseware 171courseware architecture 185courseware development 171courseware requirements specification

175creative design 245creative system development 267CSCW 227

Ddata gathering 251definition of a conceptualisation 63dependability 139descriptive process model 190discrepancies 60distributed control 140, 141distributed environments 191distributed processing 140drama improvisation 267

Eeducational profile 178efficiency 285electronic patient record (EPR) 266elicitation 38embedded software system 22enhancement requests 196ethnography 228evolution 139explicit knowledge 304eXtreme Programming 88

Ffunctional 3

Ggoal-oriented requirements engineering

69goals 251

gradual process of softwareimprovement 193

groupware 227

Hhandheld computers 267hospital information systems 267human activity modeling 245human/computer interaction 312hypotheses of conceptualisation 55

Ii* notation 245implementation domain 58Impression 95incremental approach 101information intensity 267information retrieval 310Information Systems 139information systems 340inspection 160instructional requirements 184integration of autonomous systems 140interaction specification 184

Llanguage action perspective 341learning task 171

Mmaintainability 286maturity levels 85medical knowledge 267methodology 226model view controller 320

Nnatural language processing (NLP) 303non-functional 3non-functional requirements (NFR) 285

Oobservational studies 266open source definition (OSD) 191

372 Index


open source initiative (OSI) 191open source software (OSS) 190organizational 141organizational boundaries 139organizational Failure 141OSS development (OSSD) 190OSS development methodologies 190OSSD process model 192

Pparticipatory design 228, 267, 303patch 195patch development cycle 195portability 285prioritisation 101problem diagrams 321problem domain 56problem frames 318, 319problem-oriented 56Problem-sensitive 57problem-sensitivity principle 58

Qquality 155qure 95

Rraw material principle 58RE approaches 23RE challenges 23REAIMS 85regulation 139reliability 286representations 262request tracking method 202request tracking system 202requirement development 3requirement management 3requirements 38, 159requirements allocation and flow-down

4requirements analysis 4, 54, 120, 319requirements definition 190requirements elicitation 267

requirements engineering (RE) 22,69, 226, 285

requirements engineering good practiceguide 84

requirements engineering process 4requirements engineering process

maturity model 84requirements gathering 4requirements management 245requirements management tools 15requirements specification 5requirements validation 3

Sscenario 245selection 121Skater’s principle 58social action 341social sciences 267sociotechnical system 267, 319software development 285, 303software engineering (SE) 190software evaluation 120software evaluation criteria 120software infrastructure 190software process improvement 84software quality 122software requirements development 4software requirements specification 87software support 206solution-sensitive 57special properties 23specification 159stakeholders 155standards 87status attribute 199system design process 267system development 38, 285system goal modeling 245system of systems 141system requirements development 4system requirements development

methods 7system use 306

Index 373


Ttacit knowledge 304task analysis 246technical products 154techniques 38traceability 160traceability 3two ellipse model 319

UUML 228University of Hertfordshire model 84usability 286

use case models 247use cases 246user commanded behaviour 320user commanded behaviour frame 320user interaction frame 320

Vviewpoint 60

Wworking task 171workshops 267

BO O K CH A P T E R S

JO U R N A L ART I C L E S

CO N F E R E N C E PR O C E E D I N G S

CA S E ST U D I E S

The InfoSci-Online database is the

most comprehensive collection of

full-text literature published by

Idea Group, Inc. in:

n Distance Learning

n Knowledge Management

n Global Information Technology

n Data Mining & Warehousing

n E-Commerce & E-Government

n IT Engineering & Modeling

n Human Side of IT

n Multimedia Networking

n IT Virtual Organizations

BENEFITS

n Instant Access

n Full-Text

n Affordable

n Continuously Updated

n Advanced Searching Capabilities

The Bottom Line: With easyto use access to solid, currentand in-demand information,InfoSci-Online, reasonablypriced, is recommended foracademic libraries.

- Excerpted with permission from Library Journal, July 2003 Issue, Page 140

“”

Start exploring atwww.infosci-online.com

Recommend to your Library Today!

Complimentary 30-Day Trial Access Available!

InfoSci-Online

Instant access to the latest offerings of Idea Group, Inc. in the fields of

INFORMATION SCIENCE, TECHNOLOGY AND MANAGEMENT!

DatabaseInfoSci-OnlineDatabase

A product of:

Information Science Publishing*Enhancing knowledge through information science

*A company of Idea Group, Inc.www.idea-group.com

An excellent addition to your library

��

�� !�"

#��$��%�"��%""��& ��'��(�!�) �*��++�

ISBN 1-59140-198-4 (h/c) • US$74.95 • ISBN 1-59140-290-5 (s/c) • US$59.95• 250 pages • Copyright © 2004

Information Science PublishingHershey • London • Melbourne • Singapore

#��,��*��

$��(��

-�� .�/%0��

��

Eugene Kaluzniacky, University of Winnipeg, Canada

There have arisen, in various settings, unmistakable calls forinvolvement of psychological factors in IT work, notably in devel-opment and deployment of information systems. Managing Psy-chological Factors in Information Systems Work: An Orientaion toEmotional Intelligence “pulls together” areas of existing involve-ment, to suggest yet new areas and to present an initial, andcoherent vision and framework for, essentially, extending andhumanizing the sphere of IT work. It may be indeed noteworthythat, while the Industrial Revolution may have moved the humanperson into intellectual predominance, the IT Revolution, with itsrecent calls for addressing and involving the “whole person”, mayindeed be initiating a re-centering of the human being in his/heressential core, giving rise to new consciousness, new vision andnew, empowering experiences. May this book encourage the first few stepsalong a new and vivifying path!

“Although all decisions are about facts, we mediate them through our feelings. In periods of rapid change we relymuch less on facts and more on our intuitions and experience. The uncertainty associated with Information Systems(IS) means that the corner-stone for success of IS professionals depends on their feelings-based abilities to workwith people. With this book Eugene Kaluzniacky has filled a gap in the book-shelf of those who would wish tobecome successful developers of IS projects.”

-Cathal Brugha, University College Dublin, Ireland

An excellent addition to your library

��

�� !�"

#��$��%�"��%""��& ��'��(�!�) �*��++�

ISBN 1-59140-286-7 (h/c) • US$79.95 • ISBN 1-59140-233-6 (s/c) • US$64.95• 338 pages • Copyright © 2005

IRM PressHershey • London • Melbourne • Singapore

��(��, ��

��*��%,��-��

��

Marian Quigley, PhD, Monash University, Australia

NEW RELEASE

Information Security and Ethics: Social and Organiza-tional Issues brings together examples of the latest researchfrom a number of international scholars addressing a wide rangeof issues significant to this important and growing field of study.These issues are relevant to the wider society, as well as to theindividual, citizen, educator, student and industry professional.With individual chapters focusing on areas including: webaccessibility, the digital divide, youth protection and surveil-lance, this book provides an invaluable resource for students,scholars and professionals currently working in InformationTechnology related areas.

“It is through the ongoing, cross-cultural and inter-disciplinary studies, debates anddiscussions undertaken by international scholars such as those present in this volume,that we may achieve greater global awareness and possible solutions to the ethicaldilemmas we are now facing within technologized societies.”

–Marian Quigley