Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
Model-Driven Evolution of Software Architectures - Software and ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
3.4. RequirementsEngineeringResults 49<br />
projectmembersworkinginotherdisciplinesthatemployadifferenttype<br />
<strong>of</strong>notation.<br />
UMLwasnotcommonpracticeyet,butmostcompanieswereatleast<br />
consideringitspossibilitiesforapplicationinrequirementsengineering.<br />
Usecaseswerethemost-usedUMLconstructsinthisphase.Someprojects<br />
usedsequencediagramstorealiseusecases;othersappliedclassdiagrams<br />
fordomainmodelling. However,theinterpretation<strong>of</strong>UMLnotationswas<br />
notalwaysagreedonduringrequirementsengineering. Itwasn’talways<br />
clear,forinstance,whatobjects<strong>and</strong>messagesin UMLdiagramsdenote<br />
whenasequencediagramspecifiesausecaserealisation.<br />
Onthelowestlevels,projectscommonlyusedpre-<strong>and</strong>postconditionsto<br />
specifys<strong>of</strong>twarerequirements.Theyspecifiedinterfacesaspre-<strong>and</strong>postconditionsinnaturallanguage,C,orsomeinterfacedefinitionlanguage.<br />
Projectsrarelyusedformalspecifications.Onereasonwasthatformal<br />
specificationswereconsidereddifficulttouseincomplexindustrialenvironments<strong>and</strong>requirespecialisedskills.Whenprojectsdidusethem,communicationbetweenprojectmemberswasdifficultbecausemostmembers<br />
didnotcompletelyunderst<strong>and</strong>them. Thisproblemworsenedasprojects<br />
<strong>and</strong>customersneededtocommunicate. Inonecase,however,aproject<br />
whosehighestprioritywassafetyusedtheformalnotationZforspecification.<br />
3.4.2 RequirementsManagement<br />
WhenlookingatFigures3.1onpage46<strong>and</strong>3.2onpage47,youcanimagine<br />
thatit’shardtomanagethedifferentrequirementsfromallthesedifferent<br />
sourcesthroughoutdevelopment. Thisissuewasimportantespeciallyin<br />
largeprojects.<br />
Anothercomplicatingfactorwasthatmostprojectsdidn’tstartfrom<br />
scratch.Inmostcases,companiesbuiltanewprojectonpreviousprojects.<br />
So,thesenewprojectsreusedrequirementsspecifications(evenfordevelopinganewproductline).Consequently,keepingrequirementsdocuments<br />
consistentwasdifficult.Tokeepalldevelopmentproducts<strong>and</strong>documents<br />
consistent,theprojectshadtoanalysethenewfeatures’impactprecisely.<br />
However,theprojectsfrequentlydidn’texplicitlydocumentrelationsbetweenrequirements,soimpactanalysiswasquitedifficult.Thistraceabilityisanessentialaspect<strong>of</strong>requirementsmanagement.Tracingrequirementswasdifficultbecausetherelations(e.g.,betweenrequirements<strong>and</strong><br />
architecturalcomponents)weretoocomplextospecifymanually.<br />
Available requirements management tools didn’t seem to solve this<br />
problem, although tailored versions worked in some cases. A general<br />
shortcoming<strong>of</strong>thesetoolswasthattherelationsbetweentherequirementshadnomeaning.Inparticular,tooluserscouldspecifytherelations