Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
48 Chapter3. State<strong>of</strong>thePractice<br />
Requirementsspecifywhatasystemdoes;adesigndescribeshowto<br />
realiseasystem. S<strong>of</strong>twareengineeringtextbooksstrictlyseparatetherequirements<strong>and</strong>thedesignphases<strong>of</strong>s<strong>of</strong>twaredevelopment;inpractice,this<br />
separationislessobvious.Infact,thesmallcompanies<strong>of</strong>tenputboththe<br />
requirements<strong>and</strong>designintothesystemspecification. Thesecompanies<br />
didnotexplicitlyderives<strong>of</strong>twarerequirementsfromthesystemrequirements.<br />
Thedevelopmentprocessesinthelargercompaniesdidresultin<br />
separaterequirements<strong>and</strong>designdocumentsondifferentabstractionlevels.<br />
However,inmanycases,thesecompaniesdirectlycopiedinformation<br />
fromadesigndocumentintoarequirementsdocumentforthenextabstractionlevelinstead<strong>of</strong>firstperformingadditionalrequirementsanalysis.<br />
Forinstance,as<strong>of</strong>twarearchitecturespecification(i.e.,adesigndocument)<br />
mightlistsomecharacteristics<strong>of</strong>thecomponentsthatcomprisethearchitecture.<br />
Onthenextabstractionlevelarequirementsdocumentconcerns<br />
onlyanindividualcomponent.Oftensimplythecharacteristicsmentioned<br />
inthearchitecturespecificationareusedastherequirements,instead<strong>of</strong><br />
elaboratingthoserequirements<strong>and</strong>addingmoredetailedrequirements.<br />
3.4.1 RequirementsSpecification<br />
Requirementswereusuallyspecifiedinnaturallanguage<strong>and</strong>processed<br />
withanordinarywordprocessor.Thecompaniesnormallyusedtemplates<br />
<strong>and</strong>guidelinestostructurethedocuments.Thetemplatesprescribedwhat<br />
aspectshadtobespecified. However,notallprojectsatacompanyused<br />
these templates, so requirements specifications from different projects<br />
sometimeslookedquitedifferent.<br />
Becauseembedded-s<strong>of</strong>tware’snonfunctionalpropertiesaretypicallyimportant,weexpectedthesetemplatestoreserveasectiononnonfunctional<br />
requirementsnextt<strong>of</strong>unctionalrequirements.Thiswasn’talwaysthecase.<br />
Forexample,therequirementsspecificationdidn’talwaysexplicitlytake<br />
intoaccountreal-timerequirements.Sometimesaprojectexpressedthem<br />
inaseparatesectionintherequirementsdocuments,but<strong>of</strong>tentheywere<br />
implicit.Requirementsspecification<strong>and</strong>designalsousuallydidn’texplicitlyaddressothertypicalembedded-s<strong>of</strong>twarerequirements,suchasthose<br />
forpowerconsumption<strong>and</strong>memoryuse.<br />
Projectsthatemployeddiagramstosupportrequirementsusedmostly<br />
free-form<strong>and</strong>box-linediagramsinastylethatresemblestheUnified<strong>Model</strong>ingLanguage<br />
1 (UML),data-flowdiagrams,orothernotations. Project<br />
membersprimarilyusedgeneral-purposedrawingtoolstodrawthediagrams.<br />
Because<strong>of</strong>thelack<strong>of</strong>propersyntax<strong>and</strong>semantics,otherproject<br />
members<strong>of</strong>tenmisinterpretedthediagrams. Thiswasespeciallytruefor<br />
1 http://www.uml.org(June2007)
Change language