Social Modeling for Requirements Engineering

728 Pages·2010·15.376 MB·English

by  Eric Yu, Paolo Giorgini, Neil Maiden, John Mylopoulos, Stephen Fickas

Social Modeling for Requirements Engineering
Cooperative Information Systems
MichaelP.Papazoglou,JoachimW.Schmidt,andJohnMylopoulos,editors
Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering, Nikola K.
Kasabov
Advances in Object-Oriented Data Modeling, Michael P. Papazoglou, Stefano Spaccapie-
tra, and Zahir Tari, editors
Workflow Management: Models, Methods, and Systems, Wil van der Aalst and Kees van
Hee
ASemantic Web Primer,GrigorisAntoniou and Frank van Harmelen
AligningModernBusinessProcessesandLegacySystems:AComponent-BasedPerspective,
Willem-Jan van den Heuvel
ASemantic Web Primer,second edition, Grigoris Antoniou and Frankvan Harmelen
Service-Oriented Computing, Dimitrios Georgakopoulos and Michael P. Papazoglou,
editors
At Your Service, Elisabetta di Nitto, Anne-Marie Sassen, Paolo Traverso, and Arian
Zwegers,editors
Metamodeling for Method Engineering, Manfred A. Jeusfeld, Matthias Jarke, and John
Mylopoulos, editors
SocialModelingforRequirementsEngineering,EricYu,PaoloGiorgini,NeilMaiden,and
John Mylopoulos, editors
SOCIAL MODELING FOR REQUIREMENTS ENGINEERING
edited by Eric Yu, PaoloGiorgini, Neil Maiden, and John Mylopoulos
TheMITPress
Cambridge,Massachusetts
London,England
62011MassachusettsInstituteofTechnology
Allrightsreserved.Nopartofthisbookmaybereproducedinanyformbyanyelectronicormechanicalmeans
(includingphotocopying,recording,orinformationstorageandretrieval)withoutpermissioninwritingfromthe
publisher.
Forinformationaboutspecialquantitydiscounts,[email protected]
ThisbookwassetinTimesNewRomanandSyntaxon3B2byAscoTypesetters,HongKong.
PrintedandboundintheUnitedStatesofAmerica.
LibraryofCongressCataloging-in-PublicationData
Socialmodelingforrequirementsengineering/editedbyEricYu...[etal.].
p. cm.—(Cooperativeinformationsystems)
Includesbibliographicalreferencesandindex.
ISBN978-0-262-24055-0(hardcover:alk.paper) 1.Computersoftware—Development. 2.Intelligentagents
(Computersoftware) 3.Socialinteraction—Computersimulation. I.Yu,EricS.K.,1951–
QA76.76.D47S593 2011
005.1—dc22 2009040472
10 9 8 7 6 5 4 3 2 1
Contents
ForewordbyStephenFickas vii
Acknowledgments ix
I MODELING FRAMEWORK 1
1 SocialModelingforRequirementsEngineering:AnIntroduction 3
EricYu,PaoloGiorgini,NeilMaiden,andJohnMylopoulos
2 ModelingStrategicRelationshipsforProcessReengineering 11
EricYu
II APPLICATIONS AND EXPERIENCES 153
3 Usingi*inRequirementsProjects:SomeExperiencesandLessons 155
NeilMaiden,SaraJones,CorneliusNcube,andJamesLockerbie
4 RequirementsEngineeringforTrust-BasedInterorganizationalNetworks 187
Gu¨nterGans,MatthiasJarke,StefanieKethers,GerhardLakemeyer,andDominikSchmitz
5 UsingFormalAgentSpecificationLanguagesfortheAnalysis,Verification,andSimulation
ofi*Models 219
AlexeiLapouchnianandYvesLespe´rance
6 SociallyGroundedAnalysisofKnowledgeManagementSystemsandProcesses 255
RenataS.S.Guizzardi,AnnaPerini,andVirginiaDignum
III APPLICATIONS IN SECURITY AND PRIVACY 279
7 ImprovingRisk-BasedSecurityAnalysiswithi* 281
EricDubois,NicolasMayer,andAndre´ Rifaut
8 Usingi*toModelAccessPolicies:RelatingActorstoTheirOrganizationalContext 313
RobertCrook,DarrelInce,andBasharNuseibeh
vi Contents
9 DetectingConflictsbetweenFunctionalandSecurityRequirementswithSecureTropos:
JohnRusnakandtheAlliedIrishBank 337
FabioMassacciandNicolaZannone
10 SecureTropos:Extendingi*andTropostoModelSecurityThroughouttheDevelopment
Process 363
HaralambosMouratidisandPaoloGiorgini
IV INCORPORATING SOCIAL MODELING IN SOFTWARE DEVELOPMENT 403
11 TheTroposMethodologyandSoftwareDevelopmentEnvironment 405
PaoloGiorgini,JohnMylopoulos,AnnaPerini,andAngeloSusi
12 SociocentricDesignofMultiagentArchitectures 425
ManuelKolp,YvesWautelet,andSte´phaneFaulkner
13 Integrationofi*andObject-OrientedModels 457
JaelsonCastro,FernandaAlencar,VictorSantander,andCarlaSilva
14 RequirementsAnalysisforRun-TimeServiceCompositions 485
EnzoColomboandJohnMylopoulos
15 OntheUseofi*forCOTSComponentsSelection:PrinciplesandConsequences 517
XavierFranch,EnricMayol,andCarmeQuer
16 Ontology-BasedTransformationFrameworkfromTropostoAORML 547
RenataS.S.GuizzardiandGiancarloGuizzardi
V EVALUATING AND EXTENDING SOCIAL MODELING 571
17 AReferenceModelfori* 573
CarlosCares,XavierFranch,EnricMayol,andCarmeQuer
18 StrengthsandWeaknessesofthei*Framework:AnEmpiricalEvaluation 607
OscarPastor,HugoEstrada,andAliciaMart´ınez
19 GoalModelingandReasoninginTropos 645
PaoloGiorgini,JohnMylopoulos,andRobertoSebastiani
20 AnalyzingtheEffectivenessofHumanActivitySystemswithi* 669
AlistairSutcliffe
Appendix:GuidetoModelingNotations 693
AbouttheAuthors 697
NameIndex 709
SubjectIndex 717
Foreword
Ihavebeenfollowingthei*modelsinceitwasfirstintroducedin1993attheInternational
Symposium on Requirements Engineering (RE’93). Borrowing parlance from AI, I have
watched it move through its scru¤y (soft) phase towards a more neat (formal) phase, now
occupying somewhat of a middle ground that I might call dressy campus (a mixture of in-
formal and formal). While my academic interest always seems to come around to the for-
mal side of requirements engineering, my work with real-world domains forces me to a
confession: It is the more scru¤y side of RE that is always the critical component of my
modeling. In particular, it is the nonfunctional requirements, the ones that i* has focused
on from the very beginning, that make or break the systems that I build. Perhaps I can
provide an example to illustrate this phenomenon. My group set out to build an e-mail
program for those with a cognitive impairment. We dutifully modeled the underlying
(functional) e-mail processes using a (neat) state-transition formalism. Our analysis tool
found several bugs and we fixed them. We put the e-mail program into use. Total flop.
Users abandoned the e-mail system within weeks. After much hand-wringing, we decided
that the problem was not a faulty functional model, nor a poorly designed user interface.
The problem was that e-mail is a social activity and we were not modeling the social
aspects. Once we started to model the relationships between the user and his or her e-mail
partners, we began to make progress. Many of our users were part of an assisted-living
facility, and we found the need to bring the social relationship between the facility/
organizationand user into thepicture. I can’t say we haveanalyzed all thesocial relation-
ships that impinge on our e-mail tool, but we have done enough to at least produce a new
version that has so far avoided abandonment. In closing, I give a heartfelt thanks to the
authors and their research groups for pushing on this work. And I thank the editors for
pulling the threads togetherin one volume.
Stephen Fickas
University of Oregon
Acknowledgments
WethankGregMcArthurforhisableassistancethroughoutthepreparation ofthis book.
Histirelesse¤ortincoordinatingthemanyrevisionsoftextandfigureshasbeenindispens-
able in bringing this book to fruition. Je¤ McArthur re-created many of the figures, skill-
fullyusingAdobeIllustrator.JenniferHorko¤assisted inverifyingthereferences. Markus
Strohmaier coordinated the collection of chapters early in the process. Their contributions
are greatly appreciated.
We thank the authors of individual chapters for contributing to this volume, and for
o¤ering helpful and detailed reviews and suggestionsfor other chapters.
Finally, we thank Douglas Sery and his colleagues at MIT Press for supporting and
facilitating thisproject from conception to print.
I MODELING FRAMEWORK
1 Social Modeling for Requirements Engineering: An Introduction
EricYu,PaoloGiorgini,NeilMaiden,andJohnMylopoulos
Information technology can be used in innumerable ways and has great potential for
improving people’s lives. Yet, designing systems that truly meet people’s needs remains a
considerable challenge. Every day we encounter systems that do not do what we want.
Manysoftwareprojectscontinuetofailatalarmingrates.Muchofthischallengeisattrib-
uted to the di‰culty of pinning down system requirements—e¤ective ways to determine
what people want when theyinitially conceive of the need for asoftware system.
This book o¤ers a new way of approaching the requirements challenge. The central
premise is that to arrive at system requirements, that is, to conceive what system to build,
one should examine and understand the relationships among social actors. A system aims
to improve the relationship that some actors have with other actors. Rather than focusing
on the behavioral properties of software, as in a mechanistic system, we should raise the
levelofabstractionandaskhowthesystemwilladvancetherelationshipsthatsomeactors
have in relation to other actors.
Thisperspectiveleadstoaratherdi¤erentapproachtorequirementsmodelingandanal-
ysis, one that is based on describing and analyzing social relationships. We are then led to
ask how we model and analyze the social world in order to lead to better system require-
ments. What concepts should be the basis for such modeling? What questions should the
models help answer, and how can they lead us to systematically explore alternatives and
analyze the consequencesof our choices?
Traditionally, the task of the requirements analyst is to collect requirements statements
from stakeholders: the customer and representatives of users. These statements say what
the system should do (functionality) and at what levels of quality (nonfunctional proper-
ties such as performance, reliability, extensibility, usability, and costs). For large systems,
therecanbealargenumberofsuchstatementscoming from manystakeholders.The ana-
lyst aims to ensure that these statements are consistent (i.e., they do not contradict each
other), complete (i.e., they fully reflect what the stakeholders are expecting from the sys-
tem), and unambiguous (i.e., su‰ciently precise so that they will not be misinterpreted by
the developers).