REQUIREMENTS ELICITATION PROCESS: AN ITERATIVE APPROACH BASED ON THE SPIRAL MODEL

Claudine Toffolon (*) (**) Salem Dakhli (**) (*) Littoral University, LIL, France (**) Paris-Dauphine University, CERIA, France Abstract he value o!taine" #ro$ or%ani&ations vast invest$ent in in#or$ation technolo%y is o#ten less than e'pecte", "ue in lar%e $easure to the so#t(are crisis) he so#t(are crisis has t(o $ain ra$i#ications* social an" econo$ic) +ocial ra$i#ication o# the so#t(are crisis is characteri&e" !y users resistance, stress an" pro"uctivity loss) Econo$ic ra$i#ication o# the so#t(are crisis is characteri&e" !y so#t(are "evelop$ent costs an" sche"ule slippa%es an" $aintenance !ur"en) In particular, $any so#t(are pro,ects are t(o or three ti$es over their sche"ule an" !u"%et) -y another (ay, "elivere" syste$s o#ten #ail to $eet users nee"s an" are "i##icult an" e'pensive to chan%e) .any authors stress the #act that re/uire$ents "e#iciencies are a$on% the $ost i$portant contri!utors to the so#t(are crisis) hey point out that approaches an" techni/ues provi"e" !y e'istin% so#t(are "evelop$ent $etho"s to carry out re/uire$ents elicitation an" $ana%e$ent process are o#ten insu##icient) oo o#ten, so#t(are syste$s "on0t a"e/uately $eet all the sta1ehol"ers true re/uire$ents) his paper provi"es an iterative approach !ase" on so#t(are prototypin% to i$prove the so#t(are re/uire$ents elicitation process) his approach is !ase" on a #ra$e(or1 (hich $o"els the sta1ehol"ers points o# vie( an" interactions) Keywor s: project actor, project space, requirements engineering, software dimensions, software model, spiral model

!"

I#tro $ct%o#

The role of software s stems in organi!ations is alwa s increasing and constantl e"ol"ing# it consists in pro"iding $usiness and decision support ser"ices% &e"ertheless, the "alue o$tained from organi!ations "ast in"estment in information technolog is often less than e'pected, due in large measure to the software crisis caused $ high maintenance costs and an increasing num$er of projects failures% (n addition to the seemingl intracta$le pro$lems encountered $ software professionals during de"elopment and maintenance software life c cles, software crisis has two main ramifications: social and economic% Social ramification of the software crisis is characteri!ed $ users resistance, stress and producti"it loss )*+ ),+% -conomic ramification of the software crisis is characteri!ed $ software de"elopment costs and schedule slippages and maintenance $urden% (n particular, man software projects are two or three times o"er their schedule and $udget% . another wa , deli"ered s stems often fail to meet users needs and are difficult and e'pensi"e to change% /an authors stress the fact that requirements deficiencies are among the most important contri$utors to the software crisis% .rowne )0+ stated that software s stems misuse and disuse can often $e traced to an inadequate requirements determination% 1s pointed out $ 2ee )33+, approaches and techniques pro"ided $ e'isting software de"elopment methods to carr out requirements elicitation and management process are often insufficient, all too often software s stems don4t adequatel meet all the stakeholders true requirements% (t is o$"ious toda that these methods are not

adequate to take into account the increasing comple'it of software s stems resulting from integration of continuous changes, stakeholders conflicting needs and points of "iew and groupware% (n particular, the earl approaches $ased on the waterfall model )35+ contend that requirements should $e completel specified $efore implementation% 6owe"er, Swartout and .al!er )37+ pro"ed that requirements specification and software implementation acti"ities are intertwining and conclude that a single de"elopment approach interlea"ing these acti"ities will impro"e the software de"elopment process% This paper pro"ides an iterati"e approach $ased on software protot ping to impro"e the software requirements engineering elicitation process% This approach rests on the glo$al software model proposed $ the authors )8+ )9:+% The remainder of this paper is organi!ed as follows% (n section 9, we descri$e the state of software requirements engineering in particular research work related to our approach% Section ; presents s ntheticall the glo$al software model used to define the requirements engineering approach presented in section 5% (n section 0, we conclude this paper $ descri$ing lessons learned from the "alidation of our approach and listing some research directions%

&"

Re'ate wor(

1lthough requirements engineering is a relati"el recent practice, it recei"ed a lot of attention in literature% <or e'ample, .rowne )0+ proposed a task $eha"ior oriented approach to the determination of information requirements for the de"elopment of decision support s stems% This approach is a shift from the data=dri"en requirements determination approaches used to de"elop $usiness information s stems, in particular transaction processing applications% >ther proposals assume that the multi=stakeholders consideration is a critical issue in requirement engineering% <or e'ample, (.(S ((ssue=.ased (nformation S stem) )7+, addresses multi=stakeholders considerations $ supporting relations among s stem o$jecti"es% This approach is $ased on ?issues? which can $e "iewed as requirements that impact on design decisions% 1lthough (.(S ena$les anal sis of requirements interactions, it has two main disad"antages% <irstl , it doesn@t pro"ide tools for anal !ing trade=offs% Secondl , it doesn@t support negotiation acti"ities needed to reconcile stakeholders points of "iew% The &1TAB(&o"el 1pproaches to Theories Anderl ing Bequirements -ngineering) approach appl artificial intelligence techniques to requirements engineering% 1ccording to Cohl )39+, &1TAB- addresses three important dimensions of requirements engineering: the specification dimension, the representation dimension and the agreement dimension% The &1TABagreement dimension corresponds to the multi=stakeholders consideration% De think that the approaches $ased on the Din Din spiral model );+ )5+ )33+ are closest to our approach% These approaches take into account indi"idual stakeholders requirements (win conditions) and help produce reconciled stakeholders requirements $ capturing conflicting requirements and using options to sol"e them% The Din Din spiral model supporting these approaches permits accommodating requirements change% &e"ertheless, our approach presents two main differences with the approaches cited a$o"e% >n the one hand, it "iews stakeholders as project actors carr ing out contracts related to the software s stem to $e de"eloped% >n the other hand, it pro"ides an instrument to descri$e stakeholders conflicting interests and points of "iew, and take into account all the aspects of software engineering%

)"

T*e +'oba' so,tware -o e'

The glo$al software model proposed $ the authors )8+ )9:+ is a framework which uses the economic agenc theor )93+ to identif the stakeholders in"ol"ed in software s stems de"elopment and operation, and descri$e the relationships $etween them% 1ppl ing agenc theor in anal !ing information technolog role in modern organi!ations demonstrates that software engineering is go"erned $ a set of contracts among actors concerned with the software s stem to $e de"eloped or maintained% 1t a gi"en time, each project actor pla s the

role of consumer (principal) or producer (agent) under the contracts which link him to the other project actors% So, a software de"elopment or maintenance project is a ne'us of contracts among different actors with conflicting interests and points of "iew% The discrepancies $etween the project actors o$jecti"es are partl the source of software engineering inconsistencies and related agenc costs% 1 preliminar condition to cope with these inconsistencies is to identif the different actors concerned with the software project as well as their o$jecti"es (e%g% what the e'pect from the project) )9:+% . another wa , the glo$al software model refers to the software dimensions theor )3*+ to represent all the aspects of software in particular economic, organi!ational and human aspects% Toffolon )3*+ has identified ten major aspects of software or dimensions% These dimensions has $een determined on the $ase of a deep anal sis of the effects of the software crisis and organi!ations, that mean interrelations $etween all organi!ational components (structural, tasks, indi"idual, technical), en"ironment and information technolog % Those ten dimensions concern altogether the software process and the artifacts produced $ this process% The process4 dimensions (cost dimension, dela dimension, technical dimension, communication dimension and organi!ational dimension) and the product4s dimensions (functional dimension, human dimension, economic dimension, organi!ational dimension and temporal dimension) demonstrate that a same software ma reflect man different realities which depend on the organi!ational, social and economic conte'ts of its use and e'ploitation% The software dimensions theor e'plains the software crisis and pro"ide an a priori decision oriented anal sis tool which permits a classification of dimensions on the $asis of the nature of the software and the characteristics of its use and operation conte'ts% This theor pro"ides also an a posteriori anal sis and e"aluation tool $ased on the software components e"aluation in relation to dimensions, which permits setting off an iterati"e impro"ement process of software artifacts and preliminar choices% To $uild the glo$al software model, )9:+ notice that software de"elopment methodologies in use make a confusion $etween four $usinesses: the customer4s $usiness, the end user4s $usiness, the de"eloper4s $usiness and the architect4s $usiness% -limination of this confusion leads to identif four different spaces representing respecti"el these four $usinesses: The .rob'e- s.ace where are defined the customerEend user4s pro$lem and its organi!ational solution% This space represents the customer4s $usiness% The so'$t%o# or arc*%tect$ra' s.ace where are defined computer solutions of the customerEend user4s pro$lems% This space represents the architect4s $usiness% The co#str$ct%o# s.ace where these solutions are implemented% This space represents the de"eloper4s $usiness% The o.erat%o# s.ace where are e"aluated the software4s usa$ilit from the end user4s perspecti"e as well as its contri$ution to the organi!ation4s competiti"eness% This space represents the end user4s $usiness% .esides, each software project is represented in the four spaces $ a static part, a d namic part and actors% (n each space, project4s d namic part relates to the software engineering process, project4s static part is composed of software artifacts issued from this process, while project4s actors are human resources concerned with this project% -ach actor ma ha"e two categories of roles: producer (agent) or consumer (principal) of software artifacts% 1 role pla ed $ a project4s actor in one of the four spaces is either principal or secondar % (n each space, it is possi$le that a project has man actors assuming secondar roles, $ut there can $e onl one project actor in"ol"ed in a principal role% /oreo"er, an actor can pla a secondar role in man spaces, $ut a principal role onl in one (e"er actor pla the principal role in some space)% To $e complete and efficient, an software de"elopment process must take into account all the aspects of the software as well as all the conflicting interests and points of "iew of the project4s actors% So, each project space is associated with a su$set of the ten software

dimensions )9:+% Consequentl , the economic agenc theor and the software dimensions theor pla complementar roles in modeling software engineering% (ndeed, the agenc theor underlines the conflicting interests and points of "iew of the organi!ation4s actors concerned with the software s stem, and pro"ides an instrument to model software engineering in terms of contracts $etween the consumers (or principals) and the producers (or agents)# while the software dimensions theor permits identif ing all the software engineering aspects and facilitates the e'pression of the organi!ation4s priorities and constraints according to the Simon4s .ounded Bationalit Crinciple )30+% (n addition to the project4s actors and $usinesses identification, the four software project4s spaces pro"ide tools to anal !e deepl and descri$e the "arious contracts $etween the software project4s actors, and the inconsistencies inherent in software engineering%

/"

T*e re0$%re-e#ts e'%c%tat%o# a..roac*

The requirements engineering approach we propose in this paper rests on the software engineering model presented a$o"e% (t is composed of two le"els: the intra=space le"el and the inter=spaces le"el% The intra=space le"el permits taking into account the stakeholders interests and points of "iew while the inter=space le"el supports trade=offs and reconciliation of stakeholders points of "iew% To $e compliant with the software engineering model, we define requirements as information set needed $ a stakeholder to carr out contracts linking him to the other stakeholders which ha"e an interest in the software s stem under de"elopment% This definition integrates end users functional and non=functional requirements, as well as constraints resulting from the organi!ational and technical conte'ts% (t is compliant with the (--- definition which states that a requirement is: 3% 1 condition or capacit needed $ a user to sol"e a pro$lem or achie"e an o$jecti"e# 9% 1 condition or capa$ilit that must $e met or possessed $ a s stem or s stem component to satisf a contract, standard, specification, or other formall imposed document# ;% 1 document representation of a condition or capa$ilit as in 3 or 9% To take into account the stakeholders conflicting interests and points of "iew, the requirements engineering process must $e cooperati"e% >n the other hand, it must $e iterati"e to cope with the weaknesses of the approaches $ased on the waterfall model in which requirements are positioned $efore design and implementation% (n particular, the requirements engineering process is composed of acti"ities intertwining with implementation acti"ities%

/"!

T*e %terat%1e #at$re o, re0$%re-e#ts e#+%#eer%#+

The iterati"e nature of the requirements elicitation process ma $e pro"ed using two paradigms: the Simon@s .ounded Bationalit Crinciple and the Copper@s ?knowledge growth theor ?% he -oun"e" Rationality Principle )30+ ad"ocates that for a gi"en pro$lem, there is no optimal solution suited for all organi!ations or people which ha"e an interest in sol"ing this pro$lem% (ndeed, gi"en the uncertaint inherent in real world situations, and the dramatic changes in technolog and organi!ational conte't, perfect rationalit doesn@t appl % (n turn, it is not possi$le to determine the $est solution% (nstead of doing the $est, agent do the $est the can% Simon pro"es that to cope with a pro$lem, an agent (human, organi!ation) looks for a satisficing solution which is the $est for now, since it has a $ounded rationalit instead of perfect rationalit % This solution will likel no longer $e the $est in a few months% 1rthur )3+ anal sis of the rationalit in economics pro"ides more e'planations a$out the .ounded Bationalit Crinciple% 1ccording to this author, the perfect (deducti"e) rationalit is e'tremel useful in sol"ing theoretical pro$lems% &e"ertheless, human $eha"ior needed $ perfect rationalit is much more than humans can usuall deli"er%

(ndeed, there are two reasons for perfect rationalit to $reak down under complication% <irstl , $e ond a certain complication threshold, the human logical reasoning means fail to cope, so our rationalit is $ounded% Secondl , in interacti"e situations of complication, agents guess the $eha"ior of the other agents the are dealing with since the can@t rel on them to $eha"e under perfect rationalit % Belationships $etween agents are characteri!ed $ su$jecti"e $eliefs resulting in su$jecti"e $eha"ior% Therefore, neither o$jecti"e assumptions nor perfect reasoning $ased on well=defined processes can appl to predict the $eha"ior of interacting agents% (n turn, interacti"e situations of complication correspond to ill=defined pro$lems% To deal with such pro$lems, 1rthur suggests the use of ps cholog which states that instead of perfect rationalit , human agents simplif the complicated pro$lems encountered $ constructing temporar internal working models $ased on patterns% So, each agent has a pri"ate collection of internal $elief models which result in learning=oriented $eha"ior s stem% (ndeed, agents learn which of their internal working models is suited to cope with a gi"en ill=defined complicated situation, and ma impro"e these models $ generating new h pothesis to replace the poorl performing ones% 1ccording to Faplan )3:+, Simon@s .ounded Bationalit theor results in conser"ati"e incrementalism consisting in cautious, feed=$ack sensiti"e attitude on the part of the agents concerned with complicated pro$lems% Consequentl , since software s stems pla a ke role in supporting ill=structured organi!ational pro$lems, the .ounded Bationalit Crinciple ma appl to cope with the complication inherent in the software s stem under de"elopment% (ndeed, agents impro"e in an iterati"e wa their knowledge and in turn the requirements needed to carr out the contracts linking them to the other agents concerned with this s stem% he 1no(le"%e %ro(th $o"el Copper )3;+ suggested that human knowledge growth results from pro$lem sol"ing and is go"erned $ a ne"er=ending e"olution process% (ndeed, e"er solution to a pro$lem generates new pro$lems not intentionall created $ humans% These pro$lems emerge Gautonomousl from the field of new relationships which we cannot help $ringing into e'istence with e"er action, howe"er little we intend to do soH% The knowledge growth process continues ad infinitum since sol"ing the newl created pro$lems requires new knowledge i%e% new theories and tools% The Copper4s knowledge growth model applies to the software de"elopment process% (ndeed, each software solution to an organi!ational pro$lem creates new technical and organi!ational pro$lems $ distur$ing esta$lished relationships go"erning the organi!ational conte't% (n principle, it is not possi$le to predict the precise manner in which manner a new software s stem will distur$ the organi!ational conte't% >n the one hand, this conte't is comple' $ecause of the "er high num$er of interactions $etween its components% >n the other hand, this conte't is continuousl changing% Therefore the stakeholders concerned with a software s stem modif their requirements firstl , to sol"e the new pro$lems created $ this s stem and secondl , $ disco"ering new wa s to use this s stem% Therefore, the stakeholders requirements cannot $e descri$ed completel $efore implementation% The e"ol"e in an iterati"e manner as the software s stem is used% Consequentl , either Simon@s .ounded Bationalit Crinciple or Copper@s knowledge growth model pro"e that the stakeholders requirements can@t $e made once and for all% The requirements engineering process must pro"ide for the periodic re"iew of the stakeholders requirements according to the knowledge learned while using the software s stem and the changes of the organi!ational conte't%

/"&

T*e escr%.t%o# o, t*e re0$%re-e#ts e'%c%tat%o# .rocess

To integrate the iterati"e nature of the stakeholders requirements determination, the intra= space and the inter=spaces le"els of the approach we propose in this paper are $ased on .oehm@s spiral model )9+% To descri$e these two le"els, we "iew requirements as inputs needed

$ a stakeholder to perform tasks related to the contracts linking him to the other stakeholders in"ol"ed in the software project% Stakeholders requirements result from their functional and non=functional needs, and from constraints related to the organisational conte't% The meta= model (<igure 3) s nthesi!es this "iew of stakeholders requirements% So, the proposed requirement engineering process ma $e considered task $eha"ior oriented% So, methods and techniques used in task $eha"ior oriented requirements (task anal sis, workflow anal sis, decision process anal sis) appl when implementing our approach% &e"ertheless, these methods and techniques should $e com$ined with methods and techniques specific to data oriented requirements determination (structured inter"iews, questionnaires, I1D technique, J) to o$tain more information a$out, for e'ample, data, critical success factors and stakeholders goals% (n the remainder of this section, the processes supporting the intra=space and the inter= spaces le"els of our approach are presented%
'%#(e '%#(e '%#(e '%#(e

E# 3$ser

C$sto-er

Arc*%tect

De1e'o.er

%s3a .'ays Sta(e*o' er carr%es o$t

Co#tract

escr%bes

%#tereste %#

co-.ose o,

Ro'e

Re0$%re-e#t

-eets composed of

Pro2ect

is=a

+e#erates No# ,$#ct%o#a'

Seco# ary ro'e

Pr%#c%.a' ro'e

4$#ct%o#a'

Co#stra%#t

4%+$re ! : Sta(e*o' ers re0$%re-e#ts -eta-o e' he intra-space level) The intra=space le"el of our approach is supported $ four processes $ased on the .oehm@s spiral model which permit determining respecti"el the end=user requirements, the customer requirements, the architect requirements and the de"eloper requirements% -ach process takes place in the space in which the stakeholder pla s the principal role and is em$edded in the spiral model represented in the set of dimensions associated with this space% The intra=space le"el requirements engineering processes are called as following: The end=user requirements spiral corresponds to the operation space% (t is represented in the space generated $ the organi!ational, human and functional software product dimensions% The customer requirements spiral corresponds to the pro$lem space% (t is represented in the space generated $ the economic, temporal, organi!ational and functional software product dimensions% The architect requirements spiral corresponds to the solution space% (t is represented in the space generated on the one hand, $ the organi!ational and functional software product dimensions and on the other hand, $ the cost, dela and technical software

process dimensions% The de"eloper requirements spiral corresponds to the construction space% (t is represented in the space generated on the one hand, $ the human and functional software product dimensions and on the other hand, $ the cost, dela , organi!ational and communication software process dimensions% -ach spiral is implemented according to the meta=lifec cle ( IDEA5 )38+ composed of four phases: 3% (dentification (I)# 9% De"elopment (D)# ;% -"aluation (E)# 5% 1melioration (A)% -ach phase splits up into man tasks which num$er, input and output depend on the methods used to carr it out and the process to which it $elongs% Begrouping these tasks shows that the lifec cle of each phase is consistent with the meta=lifec cle 6IDEA5% The I"enti#ication phase consists in descri$ing the stakeholders4 pro$lem i%e% the list of functional and non=functional needs, and constraints required to carr out their contracts% The Develop$ent phase aims to descri$e the needs and constraints resulting from the pre"ious phase $ di"iding them into man categories associated with the software dimensions corresponding to the space% So, all the aspects of software engineering are taken into account while descri$ing the stakeholders requirements% The Evaluation phase consists on the one hand in identif ing the uncertain requirements and on the other hand, in e"aluating the impact of each requirement on the software s stem under de"elopment and in turn classif ing these requirements according to the stakeholder@s priorities and constraints% Bequirements classification is $ased on the Simon@s .ounded Bationalit Crinciple consisting to look for the ?$est for now? requirements instead of the optimal requirements% The A$elioration phase aims to reduce uncertaint inherent in the requirements according to the -"aluation phase results% The software informati"e protot ping is among the most popular and efficient approaches used to reduce requirements uncertainties% Software protot ping is a de"elopment approach which permits $uilding e'ecuta$le models intended either to learn more a$out a pro$lem or a solution to a pro$lem, or to implement confirmed requirements of organi!ational actors% The models $uilt are called informati"e protot pes in the first case, and operational protot pes in the second case )8+% >perational protot pes are software "ersions $uilt in a qualit manner% (nformati"e protot ping permits stakeholders to impro"e their knowledge accurac $ o$taining information a$out things the don@t know well% 1nother ad"antage of software informati"e protot ping is related to its compliance with the iterati"e nature of the intra=space requirements engineering processes% &e"ertheless, since each categor of requirements corresponds to one software dimension, there are man t pes of uncertainties related to the software dimensions associated with each software space% So, to cope efficientl with uncertainties inherent in stakeholders requirements, a classification of software informati"e protot pes is needed% 1mong the protot ping classifications proposed in literature, the classification proposed in )8+ seems to $e the most suita$le to our approach since it is $ased on the software dimensions theor % -ach intra=space requirements spiral takes place in man iterations% (n each space, the optimal num$er of iterations is determined $ two rules: 3% 1ll requirements considered as important $ the stakeholder pla ing the principal role in this space are well known# 9% The "alue of information $rought $ software informati"e protot ping is positi"e% The informati"e protot ping e"aluation method proposed in )3,+ ma $e used to determine the optimal num$er of iterations characteri!ing each intra=space requirements spiral% (n a gi"en project space, the intra=space requirements spiral pro"ides the $est "ersion for now of requirements of the stakeholder pla ing the principal role in this space% The intra=space requirements spirals are at the same time participati"e and colla$orati"e

processes% <irstl , since each project space is associated with a requirements spiral, all the stakeholders concerned with the software s stem under de"elopment participate to the de"elopment or maintenance process $ e'pressing their requirements% (n our approach, each categor of stakeholders ha"ing an interest in the software s stem is represented and pla a principal role in one project space and secondar roles in the other spaces% Secondl , in each project space, the stakeholders which are consumer ("s% producer) of software artifacts ela$orated ("s% used) in this space contri$ute to the implementation of the requirements spiral associated with this space% <or e'ample, in the operation space, the end=user pla s the principal role while the de"eloper and the customer pla secondar roles% The de"eloper $eha"es as a producer of software artifacts used in the operation space while the customer $eha"es as consumer of software artifacts issued from this space% So, the de"eloper and the customer colla$orate with the end=user in determining its requirements% (n particular, the contri$ution of stakeholders who pla s secondar roles to a gi"en requirements spiral include technical and e"aluation tasks% Ta$le 3 pro"ides a t polog of the different stakeholders requirements resulting from the intra=space requirements spirals implementation% he inter-spaces level) The inter=spaces le"el which supports the stakeholders interests and points of "iew reconciliation is $ased on e"aluation and coordination acti"ities% To e'press the iterati"e nature of such acti"ities, the process supporting the inter=spaces le"el of the requirements elicitation process is em$edded in a spiral model called the requirements coordination spiral (<igure 9)% The requirements coordination spiral permits inter=spaces K na"igation L, pro"ides e"aluation and coordination tools, and supports trade=offs and negotiation $etween stakeholders% (t also descri$es intra=space and inter=spaces roles distri$ution and communication rules% This spiral is represented in the space generated $ the ten software dimensions and takes place in compliance with the K Pro$lem=Architecture= Construction=Operation L (PACO) loop )9:+% The requirements coordination process, $ased on the requirements coordination spiral, is composed of two su$=processes: a communication su$=process and a meta=process% The communication su$=process descri$es the coordination tasks, the actors communication rules and the roles distri$ution among stakeholders% The meta=process, is $ased on a clientE$u er schema, descri$es negotiation rules and e"aluation tasks, and defines the inter=spaces qualit and acceptation criteria for products issued from the intra=le"el requirements spirals% The coordination process uses two categories of resources contained in a common repositor to all stakeholders: 3% The first resources t pe relates to the e"aluation methods, approaches, technologies and tools in use within the organi!ation% CostE$enefit methods, qualit control techniques, tool selection methods are e'amples of such resources% 9% The second t pe of resources relates to the organi!ational rules and models go"erning the contracts and relationships among the stakeholders% The include in particular e"aluation and acceptation criteria and thresholds used during meta=process implementation% The requirements elicitation processes supporting the intra=space le"el are interdependent% The requirements coordination spiral permits managing the interdependencies $etween the four intra=space requirements spirals% So, the requirements coordination spiral links two categories of stakeholders $eha"iors: a micro=$eha"ior consisting, for each stakeholder, in e'pressing its requirements and a macro=$eha"ior which reconciles non=con"ergent stakeholders interests and points of "iew% -ach c cle of the requirements coordination spiral results in a "ersion of the software s stem which is the $est for now% This "ersion is $ased on the stakeholders requirements "ersions issued from the intra=spaces requirements spiral and re"ised according to negotiation principles em$edded in the requirements coordination process% The $est for now "ersion of the software s stem issued from the requirements coordination c cle 1 is called "ersion 1% (t is a formal model (a set of interrelated artifacts) of the stakeholders requirements

("ersion 1) generated $ pro$lems and new needs resulting from the use of the "ersion 1-3 of the software s stem and federated $ the requirements coordination spiral%

Sta(e*o' er Customer

Pro2ect s.ace Cro$lem space

So,tware .ro $ct %-e#s%o#s -conomic Temporal >rgani!ational <unctional >rgani!ational <unctional 6uman <unctional

So,tware .rocess %-e#s%o#s

Re0$%re-e#ts ty.es Cost constraints, Dela constraints, /arket constraints, -fficienc constraints, TacticalEstrategic constraints, >rgani!ational constraints and priorities, <unctional needs, Mualit of Ser"ice needs, J

1rchitect

Solution space

Cost Dela Technical

>rgani!ational conte't constraints, <unctional constraints, Cost constraints, Dela constraints, 1rchitecture constraints, Beuse constraints, /ethods constraints, Cerformance constraints, J

De"eloper

Construction space

<unctional constraints, &on functional constraints, Croject4s organi!ation Cost constraints, Teams communication needs, Cost constraints, Dela constraints, Dela >rgani!ational J Communication <unctional needs, &on functional needs, >rgani!ational conte't constraints, J

-nd=user

>peration space

>rgani!ational 6uman <unctional

Tab'e ! : T*e sta(e*o' ers re0$%re-e#ts ty.es

Re0$%re-e#ts coor %#at%o# s.%ra' Prob'e- s.ace O.erat%o# s.ace

C$sto-er re0$%re-e#ts s.%ra'

E# 3$ser re0$%re-e#ts s.%ra'

Arc*%tect re0$%re-e#ts s.%ra'

De1e'o.er re0$%re-e#ts s.%ra'

So'$t%o# s.ace

Co#str$ct%o# s.ace

4%+$re &: T*e re0$%re-e#t e#+%#eer%#+ a..roac*3 (n fact, according to the consumerEproducer schema linking stakeholders, each stakeholder, e'cepted the end=user, adds its "ersion 1 of its requirements to the "ersion 1 of another stakeholder requirements to $uild a formal model consumed $ another stakeholder% The end=user initiates the requirements engineering process $ identif ing operational pro$lems encountered and descri$ing its functional and non=functional needs% So (<igure ;), The customer integrates the "ersion 1 of its requirements in the "ersion 1 of the end=user requirements, and produces a formal model (the organi!ational pro$lem) consumed $ the architect# The architect integrates the "ersion 1 of its requirements in the "ersion 1 of the customer requirements, and produces a formal model (the software architecture) consumed $ the de"eloper# The de"eloper integrates the "ersion 1 of its requirements in the "ersion 1 of the end=user requirements, and produces a formal model (the software s stem) consumed $ the end=user# The end=user identifies the operational pro$lems he encounters when using the software s stem and descri$es its functional and non functional needs% 6e produces a conceptual model consumed $ the customer%

escr%bes

C$sto-er re0$%re-e#ts 6Vers%o# (5

E# 3$ser re0$%re-e#ts 6Vers%o# (5

C$sto-er co#s$-es .ro $ces

%#te+rates Or+a#%7at%o#a' .rob'e- escr%.t%o# 6Vers%o# (5

coor %#at%o# Arc*%tect re0$%re-e#ts 6Vers%o# (5 Re1%se or+a#%7at%o#a' .rob'e6Vers%o# (5

Arc*%tect co#s$-es

escr%bes

%#te+rates Arc*%tect$re escr%.t%o# 6Vers%o# (5

.ro $ces

coor %#at%o# De1e'o.er re0$%re-e#ts 6Vers%o# (5

%#te+rates

escr%bes

Re1%se arc*%tect$re escr%.t%o# 6Vers%o# (5

De1e'o.er
co#s$-es .ro $ces

So,tware syste6Vers%o# (5

coor %#at%o#

Re1%se So,tware syste6Vers%o# (5

E# 3$ser co#s$-es .ro $ces

E# 3$ser re0$%re-e#ts 6Vers%o# (5

4%+$re ): T*e %#ter e.e# e#c%es betwee# t*e %#tra3s.ace a# t*e %#ter3s.aces 'e1e's

8"

Co#c'$s%o#

(n this paper, we present a software requirements elicitation approach composed of two le"els: the intra=space le"el and the inter=spaces le"el% The intra=space le"el permits taking into account the stakeholders interests and points of "iew while the inter=spaces le"el supports trade=offs and reconciliation of stakeholders points of "iew% The description of the intra=space and the inter=space le"els confirms that the requirements specification acti"ities and the implementation acti"ities are intertwining and can@t $e separated% To "alidate the approach presented in this paper, we appl it to two large projects and a small project in a <rench insurance compan % The first large project consists in computeri!ing the compan 4s litigation department% The o$jecti"e of the second large project is to de"elop a software s stem for managing the compan 4s contractors% The

small project is $ased partl on end=user computing and partl on a software package which automates the accountanc procedures% 2et us note that the software engineering department of this insurance compan is organi!ed according to the glo$al software engineering model descri$ed a$o"e% /an lessons are learned from this e'perience: This approach is not applica$le when stakeholders requirements are well known and sta$le% (n the same wa , it seems not "er useful in the case of projects $ased on end= user computing% The requirements elicitation approach presented in this paper seems to $e well adapted with software projects in which stakeholders requirements are uncertain and "olatile% Since it is task $eha"ior oriented, our approach is suited to descri$e requirements related to Decision Supported S stems% (n addition, it permits, through the use of the task anal sis techniques, taking into account the cogniti"e process of each project stakeholder% (t permits taking into account all the aspects of software engineering as well as all the project stakeholders conflicting interests and points of "iew representing to the $usinesses e'erted $ these stakeholders% (t pro"ides instruments to cope with uncertaint inherent in software engineering% Since it considers that a software project is a ne'us of contracts among stakeholders which ma $eha"e either as producer or consumer of software artifacts, our approach applies to the de"elopment of distri$uted software s stems where the stakeholders ma pla man roles simultaneousl % This is an open approach since all the well esta$lished methods and techniques pro"ided $ traditional requirements engineering approaches ma $e used with this approach% (t is compliant which man important academic research work in the requirements engineering discipline )33+ );+ )5+% &e"ertheless, the approach presented a$o"e is a framework which need to $e completed% >n the one hand, the requirements coordination process must $e formali!ed% (n particular, a decision process must $e added to the requirements coordination spiral to sol"e the pro$lems resulting from persistent conflicts $etween stakeholders% >n the other hand, the e"aluation tasks needed when carr ing out intra=space and inter=spaces spirals are difficult $ecause of the lack of efficient and eas to learn e"aluation methods%

Re,ere#ces
)3+ 1rthur D%.% : K In"uctive Reasonin% an" -oun"e" Rationality L, 1merican -conomic 1ssociation 1nnual /eetings, 3,,5% )9+ .oehm .%D% : K A +piral .o"el o# +o#t(are Develop$ent an" Enhance$ent L, (--- Computer, 93(0), pp% 73=89, /a 3,**% );+ .oehm .%D%, .ose C%, 6orowit! -%, 2ee /%I : K +o#t(are Re/uire$ents As 2e%otiate" 3in Con"itions L, (n Croceedings of the <irst (nt% Conf% on requirements -ngineering, pp% 85=*;, (--- Computer Societ Cress, 1pril 3,,5% )5+ .oehm .%D%, .ose C%, 6orowit! -%, 2ee /%I%: K +o#t(are Re/uire$ents 2e%otiation an" Rene%otiation Ai"s* A heory-3 -ase" +piral Approach L, (n Croceedings of the 38th (nt% Conf% on Software -ngineering, 1C/ Cress, 1pril 3,,0, pp% 95;=90;%

)0+ .rowne N%I% : LIn#or$ation Re/uire$ents #or Decision +upport +yste$s * A as1 -ehavior 4rientation L, Conference 1(S, 3,,0% )7+ Conklin -%I%, Oakemo"ic F% : K A Process-4riente" Approach to Desi%n Rationale L, 6uman=Computer (nteraction, 7, pp% ;08=;,3, 3,,3% )8+ Dakhli S: K Prototypin% L, ChD% Thesis, Caris (P=Dauphine Ani"ersit , Caris, 3,,*% )*+ Nu nes I%2%: K I$pact o# +yste$ Response i$e 4n +tate An'iety L, C1C/%, Qol% ;3, &R;, /arch 3,**, pp% ;59=;58% ),+ 6irschheim B%, &ewman /%: K In#or$ation +yste$s An" User Resistance* heory An" Practice L, The Computer Iournal, Qol% ;3, &R0, /a 3,**, pp% ;,*=5:8% )3:+ Faplan S%, Faplan B% : K Co%nition an" Environ$ent * Functionin% in an Uncertain 3orl" L, Craeger, 3,*9% )33+ 2ee /%I% : K Foun"ations o# the 3in-3in Re/uire$ents 2e%otiation +yste$ L, ChD% Thesis, <acult of the Nraduate School, Ani"ersit of South California, 1ugust 3,,7% )39+ Cohl F% : K he hree Di$ensions o# Re/uire$ents En%ineerin% L, (n the 0th (nternational Conference on 1d"anced S stems -ngineering, Iune, 3,,;% )3;+ Copper F%B% : K 4!,ective 5no(le"%e, An Evolutionary Approach L,>'ford Ani"ersit Cress, 3,89% )35+ Bo ce D%D% : K .ana%in% the Develop$ent o# Lar%e +o#t(are +yste$s Concepts an" echni/ues L, (n (--- D-SC>&, 3,8:% )30+ Simon 6%1%: K .o"els o# -oun"e" Rationality L, (9 "olumes), /(T Cress, Cam$ridge, 3,*; )37+ Swartout D%, .al!er B% : K 4n the Inevita!le Intert(inin% o# +peci#ication an" I$ple$entation L, Communications of the 1C/, Iul 3,*9, pp% 5;*=55:% )38+ Toffolon C%: K Prototypin% Inci"ence in +o#t(are En%ineerin% Develop$ent .etho"olo%ies L, ChD% thesis, Caris (P=Dauphine Ani"ersit , Caris, 3,,7% )3*+ Toffolon C%: 6 he +o#t(are Di$ensions heory7, in the Croceedings of the (C-(S@,, Conference, Setu$al, Cortugal, /arch 98=;:, 3,,,% )3,+ Toffolon C%, Dakhli S% : K+o#t(are Rapi" Prototypin% Evaluation L, AFS/1 Conference : K Software /easurement in Cractice L, >cto$er 9,=;:, 3,,*, 2ondon AF% )9:+ Toffolon C%, Dakhli S%: K A Fra$e(or1 #or +o#t(are En%ineerin% Inconsistencies Analysis an" Re"uction 8, (n Croceedings 99nd 1nnual (nternational Computer Software S 1pplications Conference (C>/CS1C ,*), 1ugust 3,=93, 3,,*, Qienna, 1ustria, (--- Computer Societ Cress, pp% 98:= 988% )93+ Dilliamson >%-% (3,*,): K ransaction Cost Econo$ics L, in K B% Schmalensee and B% Dillig (-ds): 6and$ook of industrial organi!ation L, &orth=6olland, 3,*,%