SOFTWAREENGINEERING

UNIT II –STUDYMATERIAL – II BCA A

Batch: 2022-2025

SYLLABUS

Understanding Requirements: Requirements Engineering - Eliciting Requirements -

Requirement Modeling: Requirements Analysis.

DataModelingConcepts-Class-BasedModeling.

Floworientedmodeling-Creatingabehavioralmodel.
 SoftwareEngineeringLecturenotes

REQUIREMENTSENGINEERING

Thebroadspectrumoftasksandtechniquesthatleadtoanunderstandingofrequirementsiscalledrequirementseng
ineering.Fromasoftwareprocessperspective,requirementsengineeringisamajorsoftwareengineeringactiontha
tbeginsduringthecommunicationactivityandcontinuesintothemodelingactivity.Itmustbeadaptedtotheneedsof
theprocess,theproject,theproduct,andthepeopledoingthework.

Requirementsengineeringbuildsabridgetodesignandconstruction.Requirementsengineeringprovidestheappr
opriatemechanismforunderstandingwhatthecustomerwants,analyzingneed,assessingfeasibility,negotiatinga
reasonablesolution,specifyingthesolutionunambiguously,validatingthespecification,andmanagingtherequir
ementsastheyaretransformedintoanoperationalsystem.Itencompassessevendistincttasks:inception,elicitatio
n,elaboration,negotiation,specification,validation,andmanagement.
a) Inception.Ingeneral,mostprojectsbeginwhenabusinessneedisidentifiedorapotentialnewmarketorservicei
sdiscovered.Stakeholdersfromthebusinesscommunitydefineabusinesscasefortheidea,trytoidentifythebreadt
handdepthofthemarket,doaroughfeasibility analysis, and identify a working description of the project’s
scope.

Atprojectinception,youestablishabasicunderstandingoftheproblem,thepeoplewhowantasolution,thenatureof
thesolutionthatisdesired,andtheeffectivenessofpreliminarycommunicationandcollaborationbetweentheother
stakeholdersandthesoftwareteam.

b)Elicitation.Askthecustomer,whattheobjectivesforthesystemorproductare,whatistobeaccomplished,howth
esystemorproductfitsintotheneedsofthebusiness,andfinally,howthesystemorproductistobeusedonaday-to-
daybasis.Anumberofproblemsthatareencounteredaselicitationoccurs.
• Problemsofscope.Theboundaryofthesystemisill-
definedorthecustomers/usersspecifyunnecessarytechnicaldetailthatmayconfuse,ratherthanclarify,overallsys
temobjectives.
• Problemsofunderstanding.Thecustomers/usersarenotcompletelysureofwhatisneeded,haveapoorundersta
ndingofthecapabilitiesandlimitationsoftheircomputingenvironment,don’thaveafullunderstandingof the
problemdomain,havetroublecommunicatingneedstothesystemengineer,omit information that is believed to
be “obvious,” specify requirements that
conflictwiththeneedsofothercustomers/users,orspecifyrequirementsthatareambiguousoruntestable.
• Problems of
volatility.Therequirementschangeovertime.Tohelpovercometheseproblems,youmustapproachrequirements
gatheringinanorganizedmanner.

c)Elaboration.Theinformationobtainedfromthecustomerduringinceptionandelicitationisexpandedandrefin
edduringelaboration.Thistaskfocusesondeveloping

GPCET,DepartmentofCSE|45
 SoftwareEngineeringLecturenotes

arefinedrequirementsmodelthatidentifiesvariousaspectsofsoftwarefunction,behavior,andinformation.

Elaborationisdrivenbythecreationandrefinementofuserscenariosthatdescribehowtheenduser(andotheractors)
willinteractwiththesystem.Eachuserscenarioisparsedtoextractanalysisclasses—
businessdomainentitiesthatarevisibletotheenduser.Theattributesofeachanalysisclassaredefined,andtheservic
esthatarerequiredbyeachclassareidentified.Therelationshipsandcollaborationbetweenclassesareidentified,an
davarietyofsupplementarydiagramsareproduced.

d)Negotiation.Itusualforcustomers,togiven limited business resources. It’s also relatively

commonfordifferentcustomersoruserstoproposeconflictingrequirements,arguingthattheirversionis“essential
for our special needs.”
Youhavetoreconciletheseconflictsthroughaprocessofnegotiation.Customers,users,andotherstakeholdersarea
skedtorankrequirementsandthendiscussconflicts
inpriority.Usinganiterativeapproachthatprioritizesrequirements,assessestheircostandrisk,andaddressesinter
nalconflicts,requirementsareeliminated,combined,and/ormodifiedsothateachpartyachievessomemeasureofs
atisfaction.

e)Specification.Specificationmeansdifferentthingstodifferentpeople.Aspecificationcanbeawrittendocumen
t,asetofgraphicalmodels,aformalmathematicalmodel,acollectionofusagescenarios,aprototype,oranycombina
tionofthese.Some suggest that a “standard template” should
bedevelopedandusedforaspecifcation,arguingthatthisleadstorequirementsthatarepresentedinaconsistentandt
hereforemoreunderstandablemanner.However,itissometimesnecessarytoremainflexiblewhenaspecificationi
stobedeveloped.Forlargesystems,awrittendocument,combiningnaturallanguagedescriptionsandgraphicalmo
delsmaybethebestapproach.

ESTABLISHINGTHEGROUNDWORK

Inanidealsetting,stakeholdersandsoftwareengineersworktogetheronthesameteam.Insuchcases,requirements
engineeringissimplyamatterofconductingmeaningfulconversationswithcolleagueswhoarewell-
knownmembersoftheteam.

Wediscussthestepsrequiredtoestablishthegroundworkforanunderstandingofsoftwarerequirements—
togettheprojectstartedinawaythatwillkeepitmovingforwardtowardasuccessfulsolution.

IdentifyingStakeholders:Stakeholderis“anyone who benefits inadirectorindirectwayfrom the system

which is being
developed.”Theusualstakeholdersare:businessoperationsmanagers,productmanagers,marketingpeople,inter
nalandexternalcustomers,endusers,

GPCET,DepartmentofCSE|46
 SoftwareEngineeringLecturenotes

• Aremyquestionsrelevanttotheproblemthatyou have?
• AmIaskingtoomanyquestions?
• Cananyoneelseprovideadditionalinformation?
• ShouldIbeaskingyouanythingelse?
Thesequestionswillhelpto“breaktheice”andinitiatethecommunicationthatisessentialtosuccessfulelicitation.

ELICITINGREQUIREMENTS

Requirementselicitationcombineselementsofproblemsolving,elaboration,negotiation,andspecification.
CollaborativeRequirementsGathering:Manydifferentapproachestocollaborativerequirementsgathering
havebeenproposed.
• Meetingsareconductedandattendedbybothsoftwareengineersandotherstakeholders.
• Rulesforpreparationandparticipationareestablished.
• Anagendaissuggested thatisformalenough to coverallimportant points
butinformalenoughtoencouragethefreeflowofideas.
• A“facilitator”controlsthe meeting.
• A“definitionmechanism”(canbeworksheets,flipchartsetc)isused.

Thegoalistoidentifytheproblem,proposeelementsofthesolution,negotiatedifferentapproaches,andspecifyapr
eliminarysetofsolutionrequirementsinanatmospherethatisconducivetotheaccomplishmentofthegoal.

Whilereviewingtheproductrequestinthedaysbeforethemeeting,eachattendeeisaskedtomakealistofobjectsthat
arepartoftheenvironmentthatsurroundsthesystem,otherobjectsthataretobeproducedbythesystem,andobjectst
hatareusedbythesystemtoperformitsfunctions.

Themini-
specsarepresentedtoallstakeholdersfordiscussion.Additions,deletions,andfurtherelaborationaremade.Insom
ecases,thedevelopmentofmini-
specswilluncovernewobjects,services,constraints,orperformancerequirementsthatwillbeaddedtotheoriginall
ists.Duringalldiscussions,theteammayraiseanissuethatcannotberesolvedduringthemeeting.Anissueslistismai
ntainedsothattheseideaswillbeactedonlater.

QualityFunctionDeployment:Qualityfunctiondeployment(QFD)isaqualitymanagementtechniquethattra
nslatestheneedsofthecustomerintotechnicalrequirementsforsoftware. QFD “concentrates
onmaximizingcustomersatisfactionfromthesoftwareengineeringprocess”. QFD identifies
threetypesofrequirements:
Normalrequirements.Theobjectivesandgoalsthatarestatedforaproductorsystemduringmeetingswiththecust
omer.Iftheserequirementsarepresent,thecustomerissatisfied.

GPCET,DepartmentofCSE|48
 SoftwareEngineeringLecturenotes

Examplesofnormalrequirementsmightberequestedtypesofgraphicaldisplays,specificsystemfunctions,anddef
inedlevelsofperformance.
Expectedrequirements.Theserequirementsareimplicittotheproductorsystemandmaybesofundamentalthatt
hecustomerdoesnotexplicitlystatethem.Theirabsencewillbeacauseforsignificantdissatisfaction.Examplesofe
xpectedrequirementsare:easeofhuman/machineinteraction,overalloperationalcorrectnessandreliability,ande
aseofsoftwareinstallation.
Excitingrequirements.Thesefeaturesgo beyond the customer’sexpectations
andprovetobeverysatisfyingwhenpresent.Forexample,softwareforanewmobilephonecomeswithstandardfeat
ures,butiscoupledwithasetofunexpectedcapabilities(e.g.,multitouchscreen,visualvoicemail)thatdelightevery
useroftheproduct.

UsageScenarios:Asrequirementsaregathered,anoverallvisionofsystemfunctionsandfeaturesbeginstomater
ialize.However,itisdifficulttomoveintomoretechnicalsoftwareengineeringactivitiesuntilyouunderstandhowt
hesefunctionsandfeatureswillbeusedbydifferentclassesofendusers.Toaccomplishthis,developersandusersca
ncreateasetofscenariosthatidentifyathreadofusageforthesystemtobeconstructed.

ElicitationWorkProducts:Theworkproductsproducedasaconsequenceofrequirementselicitationwillvary
dependingonthesizeofthesystemorproducttobebuilt.Formostsystems,theworkproductsinclude
• Astatementofneedandfeasibility.
• Aboundedstatementof scopeforthesystemorproduct.
• Alistofcustomers,users,andotherstakeholderswhoparticipatedinrequirementselicitation.
• Adescriptionofthesystem’stechnicalenvironment.
• Alistofrequirementsandthedomainconstraintsthatapplytoeach.
• Asetofusagescenariosthatprovideinsightintotheuseofthesystemorproductunderdifferentoperatingconditio
ns.
• Anyprototypesdevelopedtobetterdefine requirements.

Eachoftheseworkproductsisreviewedbyallpeoplewhohaveparticipatedinrequirementselicitation.

DEVELOPINGUSECASES

Inessence,ausecasetellsastylizedstoryabouthowanenduserinteractswiththesystemunderaspecificsetofcircum
stances.Thestorymaybenarrativetext,anoutlineoftasksorinteractions,atemplate-
baseddescription,oradiagrammaticrepresentation.Regardlessofitsform,ausecasedepictsthesoftwareorsystem
fromtheenduser’s point of view.

Thefirststepinwritingausecaseistodefinethesetof “actors”thatwillbe
involvedinthestory.Actorsarethedifferentpeople(ordevices)thatusethesystemorproductwithinthecontextof

GPCET,DepartmentofCSE|49
 SoftwareEngineeringLecturenotes

• Iseachrequirementachievableinthetechnicalenvironmentthatwillhousethesystemorproduct?
• Iseachrequirementtestable,onceimplemented?
• Doestherequirementsmodelproperlyreflecttheinformation,function,andbehaviorofthesystemtobebuilt?
• Hastherequirementsmodelbeen“partitioned”inawaythatexposesprogressivelymoredetailedinformationab
outthesystem?
• Haverequirementspatternsbeenusedtosimplifytherequirementsmodel?
Haveallpatternsbeenproperlyvalidated?Areallpatterns
consistentwithcustomerrequir
ements?

RequirementsModeling(Scenarios,InformationandAnalysisClasses)

Whatisit?Thewrittenwordisawonderfulvehicleforcommunication,butitisnotnecessarilythebestwaytorep
resenttherequirementsforcomputersoftware.Requirementsmodelingusesacombinationoftextanddiagram
maticformstodepictrequirementsinawaythatisrelativelyeasytounderstand,andmoreimportant,straightfor
wardtoreviewforcorrectness,completeness,andconsistency.
Whodoesit?Asoftwareengineer(sometimescalledan“analyst”)buildsthemodelusing
requirementselicitedfromthecustomer.
Whyisitimportant?Tovalidatesoftwarerequirements,youneedtoexaminethemfromanumberofdifferentp
ointsofview.In this chapter you’ll
considerrequirementsmodelingfromthreedifferentperspectives:scenario-
basedmodels,data(information)models,andclass-
basedmodels.Eachrepresentsrequirementsinadifferent“dimension,” thereby increasing
theprobabilitythaterrorswillbefound,thatinconsistencywillsurface,andthatomissionswillbeuncovered.
Whatarethesteps?Scenario-basedmodelingrepresents the system from the user’s point
ofview.Datamodelingrepresentstheinformationspaceanddepictsthedataobjectsthatthesoftwarewillmanip
ulateandtherelationshipsamongthem.Class-
basedmodelingdefinesobjects,attributes,andrelationships.Oncepreliminarymodelsarecreated,theyarerefi
nedandanalyzedtoassesstheirclarity,completeness,andconsistency.
Whatistheworkproduct?Awidearrayoftextbasedanddiagrammaticformsmaybechosenfortherequireme
ntsmodel.Eachoftheserepresentationsprovidesaviewofoneormoreofthemodelelements.
HowdoIensurethatI’vedoneitright?Requirementsmodelingworkproductsmustbereviewedforcorrectnes
s,completeness,andconsistency.Theymustreflecttheneedsofallstakeholdersandestablishafoundationfrom
whichdesigncanbeconducted.

GPCET,DepartmentofCSE|54
 SoftwareEngineeringLecturenotes

REQUIREMENTSANALYSIS

Requirements analysis results in the specification of software’s operational characteristics, indicates

software’s interface with other system elements, and establishes
constraintsthatsoftwaremustmeet.Requirementsanalysisallowsyoutoelaborateonbasicrequirementsestablish
edduringtheinception,elicitation,andnegotiationtasksthatarepartofrequirementsengineering.Therequirement
smodelingactionresultsinoneormoreofthefollowingtypesofmodels:
• Scenario-basedmodelsofrequirementsfromthepointofviewofvarioussystem “actors”
• Datamodelsthatdepicttheinformationdomainfortheproblem
• Class-orientedmodelsthatrepresentobject-
orientedclasses(attributesandoperations)andthemannerinwhichclassescollaboratetoachievesystemrequirem
ents
• Flow-
orientedmodelsthatrepresentthefunctionalelementsofthesystemandhowtheytransformdataasitmovesthrough
thesystem
• Behavioralmodelsthatdepicthowthesoftwarebehavesasaconsequenceofexternal
“events”

Thesemodelsprovideasoftwaredesignerwithinformationthatcanbetranslatedtoarchitectural,interface,andcom
ponent-
leveldesigns.Finally,therequirementsmodelprovidesthedeveloperandthecustomerwiththemeanstoassessqual
ityoncesoftwareisbuilt.

OverallObjectivesandPhilosophy:Throughoutrequirementsmodeling,yourprimaryfocusisonwhat,notho
w.Therequirementsmodelmustachievethreeprimaryobjectives:(1)todescribewhatthecustomerrequires,(2)toe
stablishabasisforthecreationofasoftwaredesign,and(3)todefineasetofrequirementsthatcanbevalidatedonceth
esoftwareisbuilt.Theanalysismodelbridgesthegapbetweenasystem-
leveldescriptionthatdescribesoverallsystemorbusinessfunctionalityasitisachievedbyapplyingsoftware,hard
ware,data,human,andothersystemelementsandasoftwaredesignThisrelationshipisillustratedinFigure6.1

GPCET,DepartmentofCSE|55
 SoftwareEngineeringLecturenotes

AnalysisRulesofThumb:ArlowandNeustadtsuggestanumberofworthwhilerulesofthumbthatshouldbefollow
edwhencreatingtheanalysismodel:
• Themodelshouldfocusonrequirementsthatarevisiblewithintheproblemorbusinessdomain.The level of
abstraction should be relatively high. “Don’t get bogged down in details”
thattrytoexplainhowthesystemwillwork.
• Each element of the requirements
modelshouldaddtoanoverallunderstandingofsoftwarerequirementsandprovideinsightintotheinformationdo
main,function,andbehaviorofthesystem.
• Delayconsiderationofinfrastructureandothernonfunctionalmodelsuntildesign.Thatis,adatabasemayberequ
ired,buttheclassesnecessarytoimplementit,thefunctionsrequiredtoaccessit,andthebehaviorthatwillbeexhibite
dasitisusedshouldbeconsideredonlyafterproblemdomainanalysishasbeencompleted.
• Minimizecouplingthroughoutthesystem.Itisimportanttorepresentrelationshipsbetweenclassesandfunctions.
However, if the level of “interconnectedness” isextremelyhigh,effortshouldbemadetoreduceit.
• Becertainthattherequirementsmodelprovidesvaluetoallstakeholders.Eachconstituencyhasitsownuseforthe
model.Forexample,businessstakeholdersshouldusethemodeltovalidaterequirements;designersshouldusethe
modelasabasisfordesign;QApeopleshouldusethemodeltohelpplanacceptancetests.
• Keepthemodelassimpleasitcanbe.Don’tcreateadditionaldiagramswhentheyaddnonew
information.Don’tusecomplexnotationalforms,whenasimplelistwilldo.

DomainAnalysis:Theanalysispatternsoftenreoccuracrossmanyapplicationswithinaspecificbusinessdomai
n.Ifthesepatternsaredefinedandcategorizedinamannerthatallowsyoutorecognizeandapplythemtosolvecomm
onproblems.Thisimprovestime-to-marketandreducesdevelopmentcosts.

Domainanalysisdoesn’tlookataspecificapplication,butratheratthedomaininwhichtheapplicationresides.Thei
ntentistoidentifycommonproblemsolvingelementsthatareapplicabletoallapplicationswithinthedomain.Dom
ainanalysismaybeviewedasanumbrellaactivityforthesoftwareprocess.Figure6.2illustrateskeyinputsandoutpu
tsforthedomainanalysisprocess.Sourcesofdomainknowledgearesurveyedinanattempttoidentifyobjectsthatca
nbereusedacrossthedomain.

GPCET,DepartmentofCSE|56
 SoftwareEngineeringLecturenotes

RequirementsModelingApproaches:Oneviewofrequirementsmodeling,calledstructuredanalysis,consid
ersdataandtheprocessesthattransformthedataasseparateentities.Dataobjectsaremodeledinawaythatdefinesthe
irattributesandrelationships.Processesthatmanipulatedataobjectsaremodeledinamannerthatshowshowtheytr
ansformdataasdataobjectsflowthroughthesystem.

Asecondapproachtoanalysismodeling,calledobject-
orientedanalysis,focusesonthedefinitionofclassesandthemannerinwhichtheycollaboratewithoneanother.UM
LandtheUnifiedProcessarepredominantlyobjectoriented.

Eachelementoftherequirementsmodel(Figure6.3)presentstheproblemfromadifferentpointofview.Scenario-
basedelementsdepicthowtheuserinteractswiththesystemandthespecificsequenceofactivitiesthatoccurastheso
ftwareisused.

Class-
basedelementsmodeltheobjectsthatthesystemwillmanipulate,theoperationsthatwillbeappliedtotheobjectstoe
ffectthemanipulation,relationshipsbetweentheobjects,andthecollaborationsthatoccurbetweentheclassesthata
redefined.Behavioralelementsdepicthowexternaleventschangethestateofthesystemortheclassesthatresidewit
hinit.Finally,flow-
orientedelementsrepresentthesystemasaninformationtransform,depictinghowdataobjectsaretransformedasth
eyflowthroughvarioussystemfunctions.Analysismodelingleadstothederivationofeachofthesemodelingeleme
nts.However,thespecificcontentofeachelementmaydifferfromprojecttoproject.

GPCET,DepartmentofCSE|57
 SoftwareEngineeringLecturenotes

DATAMODELINGCONCEPTS

Ifsoftwarerequirementsincludetheneedtocreate,extend,orinterfacewithadatabaseorifcomplexdatastructures
mustbeconstructedandmanipulated,thesoftwareteammaychoosetocreateadatamodelaspartofoverallrequirem
entsmodeling.Asoftwareengineeroranalystdefinesalldataobjectsthatareprocessedwithinthesystem,therelatio
nshipsbetweenthedataobjects,andotherinformationthatispertinenttotherelationships.Theentity-
relationshipdiagram(ERD)addressestheseissuesandrepresentsalldataobjectsthatareentered,stored,transform
ed,andproducedwithinanapplication.

GPCET,DepartmentofCSE|61
 SoftwareEngineeringLecturenotes

DataObjects:Adataobjectisarepresentationofcompositeinformationthatmustbeunderstoodbysoftware.Th
erefore,width(asinglevalue)wouldnotbeavaliddataobject,butdimensions(incorporatingheight,width,anddept
h)couldbedefinedasanobject.

Adataobjectcanbeanexternalentity(e.g.,anythingthatproducesorconsumesinformation),athing(e.g.,areportor
adisplay),anoccurrence(e.g.,atelephonecall)orevent(e.g.,analarm),arole(e.g.,salesperson),anorganizationalu
nit(e.g.,accountingdepartment),aplace(e.g.,awarehouse),orastructure(e.g.,afile).Thedescriptionofthedataobj
ectincorporatesthedataobjectandallofitsattributes.

Adataobjectencapsulatesdataonly—thereisnoreferencewithinadataobjecttooperationsthatactonthedata.

DataAttributes:Dataattributesdefinethepropertiesofadataobjectandtakeononeofthreedifferentcharacterist
ics.Theycanbeusedto(1)nameaninstanceofthedataobject,(2)describetheinstance,or(3)makereferencetoanoth
erinstanceinanothertable.Inaddition,oneormoreoftheattributesmustbedefinedasanidentifier—
thatis,theidentifierattributebecomes a “key” when we want
tofindaninstanceofthedataobject.Insomecases,valuesfortheidentifier(s)areunique,althoughthisisnotarequire
ment.

Relationships:Dataobjectsareconnectedtooneanotherindifferentways.Considerthetwodataobjects,persona
ndcar.TheseobjectscanberepresentedusingthesimplenotationillustratedinFigure6.8a.Aconnectionisestablish
edbetweenpersonandcarbecausethetwoobjectsarerelated.Butwhataretherelationships?Todeterminetheanswe
r,youshouldunderstandtheroleofpeople(owners,inthiscase)andcarswithinthecontextofthesoftwaretobebuilt.
Youcanestablishasetofobject/relationshippairsthatdefinetherelevantrelationships.Forexample,
• Apersonownsa car.
• Apersonisinsuredtodriveacar.

Therelationshipsownsandinsuredtodrivedefinetherelevantconnectionsbetweenpersonandcar.Figure6.8billus
tratestheseobject-relationshippairsgraphically.ThearrowsnotedinFigure

GPCET,DepartmentofCSE|62
 SoftwareEngineeringLecturenotes

6.8bprovideimportantinformationaboutthedirectionalityoftherelationshipandoftenreduceambiguityormisint
erpretations.

CLASS-BASEDMODELING

Class-
basedmodelingrepresentstheobjectsthatthesystemwillmanipulate,theoperationsthatwillbeappliedtotheobjec
tstoeffectthemanipulation,relationshipsbetweentheobjects,andthecollaborationsthatoccurbetweentheclasses
thataredefined.Theelementsofaclass-
basedmodelincludeclassesandobjects,attributes,operations,classresponsibility,collaborator(CRC)models,co
llaborationdiagrams,andpackages.

IdentifyingAnalysisClasses
Classesaredeterminedbyunderliningeachnounornounphraseandenteringitintoasimpletable.Iftheclass(noun)i
srequiredtoimplementasolution,thenitispartofthesolutionspace;otherwise,ifaclassisnecessaryonlytodescribe
asolution,itispartoftheproblemspace.
Analysisclassesmanifestthemselvesinoneofthefollowingways:
• Externalentities thatproduceorconsumeinformationtobeusedbyacomputer-basedsystem.
• Things(e.g.,reports,displays,letters,signals)thatarepartoftheinformationdomainfortheproblem.
• Occurrencesorevents(e.g.,apropertytransferorthecompletionofaseriesofrobotmovements)thatoccurwithin
thecontextofsystemoperation.
• Roles(e.g.,manager,engineer,salesperson)playedbypeoplewhointeractwiththesystem.
• Organizationalunits(e.g.,division,group,team)thatarerelevanttoanapplication.
• Places(e.g.,manufacturingfloororloadingdock)thatestablishthecontextoftheproblemandtheoverallfunction
ofthesystem.
• Structures(e.g.,sensors,four-
wheeledvehicles,orcomputers)thatdefineaclassofobjectsorrelatedclassesofobjects.

SpecifyingAttributes:Attributesarethesetofdataobjectsthatfullydefinetheclasswithinthecontextoftheprobl
em.Attributesdescribeaclassthathasbeenselectedforinclusionintherequirementsmodel.Inessence,itistheattrib
utesthatdefinetheclass—thatclarifywhatismeantbytheclassinthecontextoftheproblemspace.
Todevelopameaningfulsetofattributesforananalysisclass,youshouldstudyeachusecase
andselectthose“things”thatreasonably“belong”totheclass.

DefiningOperations:Operationsdefinethebehaviorofanobject.Althoughmanydifferenttypesofoperationse
xist,theycangenerallybedividedintofourbroadcategories:(1)operationsthatmanipulatedatainsomeway.(2)ope
rationsthatperformacomputation,(3)operationsthatinquireaboutthestateofanobject,and(4)operationsthatmon
itoranobjectfor

GPCET,DepartmentofCSE|63
 SoftwareEngineeringLecturenotes

theoccurrenceofacontrollingevent.Thesefunctionsareaccomplishedbyoperatingonattributesand/orassociatio
ns.Therefore,anoperation must have “knowledge” of the natureofthe class’ attributes and associations.
Asafirstiterationatderivingasetofoperationsforananalysisclass,youcanagainstudyaprocessingnarrative(oruse
case)andselectthoseoperationsthatreasonablybelongtotheclass.Toaccomplishthis,thegrammaticalparseisaga
instudiedandverbsareisolated.Someoftheseverbswillbelegitimateoperationsandcanbeeasilyconnectedtoaspe
cificclass.

Class-Responsibility-Collaborator(CRC)Modeling:Class-responsibility-
collaborator(CRC)modelingprovidesasimplemeansforidentifyingandorganizingtheclassesthatarerelevanttos
ystemorproductrequirements.

OnepurposeofCRCcardsistofailearly,tofailoften,andtofailinexpensively.Itisalotcheapertotearupabunchofcar
dsthanitwouldbetoreorganizealargeamountofsourcecode.

AmblerdescribesCRCmodelinginthefollowingway:
ACRCmodelisreallyacollectionofstandardindexcardsthatrepresentclasses.Thecardsaredividedintothreesecti
ons.Alongthetopofthecardyouwritethenameoftheclass.Inthebodyofthecardyoulisttheclassresponsibilitiesont
heleftandthecollaboratorsontheright.

Inreality,theCRCmodelmaymakeuseofactualorvirtualindexcards.Theintentistodevelopanorganizedreprese
ntationofclasses.Responsibilitiesaretheattributesandoperationsthatarerelevantfortheclass.Statedsimply,ares
ponsibilityis“anything the class knows or
does”.Collaboratorsarethoseclassesthatarerequiredtoprovideaclasswiththeinformationneededtocompletear
esponsibility.
Ingeneral,acollaborationimplieseitherarequestforinformationorarequestforsomeaction.

GPCET,DepartmentofCSE|64
 SoftwareEngineeringLecturenotes

AsimpleCRCindexcardfortheFloorPlanclassisillustratedinFigure6.11.Thelistofresponsibilitiesshownonthe
CRCcardispreliminaryandsubjecttoadditionsormodification.TheclassesWallandCameraarenotednexttothere
sponsibilitythatwillrequiretheircollaboration.

Classes.Basicguidelinesforidentifyingclassesandobjectswerepresentedearlierinthischapter.Thetaxonomyof
classtypespresentedinSection6.5.1canbeextendedbyconsideringthefollowingcategories:
•​ Entityclasses,alsocalledmodelorbusinessclasses,areextracteddirectlyfromthestatementoftheproblemThe
seclassestypicallyrepresentthingsthataretobestoredinadatabaseandpersistthroughoutthedurationoftheapplic
ation.
• ​ Boundary
classesareusedtocreatetheinterface(e.g.,interactivescreenorprintedreports)thattheuserseesandinteractswit
hasthesoftwareisused.Entityobjectscontaininformation

GPCET,DepartmentofCSE|65
 SoftwareEngineeringLecturenotes

thatisimportanttousers,buttheydonotdisplaythemselves.Boundaryclassesaredesignedwiththeresponsibility
ofmanagingthewayentityobjectsarerepresentedtousers.

• Controllerclassesmanagea“unitof work”fromstarttofinish.That
is,controllerclassescanbedesignedtomanage(1)thecreationorupdateofentityobjects,(2)theinstantiationofbou
ndaryobjectsastheyobtaininformationfromentityobjects,(3)complexcommunicationbetweensetsofobjects,(4)
validationofdatacommunicatedbetweenobjectsorbetweentheuserandtheapplication.Ingeneral,controllerclas
sesarenotconsidereduntilthedesignactivityhasbegun.

Responsibilities.Thefiveguidelinesforallocatingresponsibilitiestoclasses:
1. Systemintelligenceshouldbedistributedacrossclassestobestaddresstheneedsoftheproblem.Everyap
plicationencompassesacertaindegreeofintelligence;thatis,whatthesystemknowsandwhatitcando.Thisintelli
gencecanbedistributedacrosssclassesinaumber of different ways. “Dumb” classes can
bemodeledtoactasservantstoafew“smart” classes.
Todeterminewhethersystemintelligenceisproperlydistributed,theresponsibilitiesnotedoneachCRCmodelind
excardshouldbeevaluatedtodetermineifanyclasshasanextraordinarilylonglistofresponsibilities.Exampleisag
gregationofclasses.
2. Eachresponsibilityshouldbestatedasgenerallyaspossible.Thisguidelineimpliesthatgeneralresponsibili
ties(bothattributesandoperations)shouldresidehighintheclasshierarchy
3. Informationandthebehaviorrelatedtoitshouldresidewithinthesameclass.Thisachievestheobject-
orientedprinciplecalledencapsulation.Dataandtheprocessesthatmanipulatethedatashouldbepackagedasacohe
siveunit.
4. Informationaboutonethingshouldbelocalizedwithasingleclass,notdistributedacrossmultipleclasses.
Asingleclassshouldtakeontheresponsibilityforstoringandmanipulatingaspecifictypeofinformation.Thisrespo
nsibilityshouldnot,ingeneral,beshared

GPCET,DepartmentofCSE|66
 SoftwareEngineeringLecturenotes

acrossanumberofclasses.Ifinformationisdistributed,softwarebecomesmoredifficulttomaintainandmorechall
engingtotest.
5. Responsibilitiesshouldbesharedamongrelatedclasses,whenappropriate.Therearemanycasesinwhicha
varietyofrelatedobjectsmustallexhibitthesamebehavioratthesametime.

Collaborations.Classesfulfilltheirresponsibilitiesinoneoftwoways:(1)Aclasscanuseitsownoperationstoman
ipulateitsownattributes,therebyfulfillingaparticularresponsibility,or(2)aclasscancollaboratewithotherclasses.
Tohelpintheidentificationofcollaborators,youcanexaminethreedifferentgenericrelationshipsbetweenclasses(
1)theis-part-ofrelationship,(2)thehas-knowledge-ofrelationship,and(3)thedepends-uponrelationship.

WhenacompleteCRCmodelhasbeendeveloped,stakeholderscanreviewthemodelusingthefollowingapproach
1. AllparticipantsinthereviewaregivenasubsetoftheCRCmodelindexcards.Cardsthatcollaborateshouldbesep
arated
2. Alluse-casescenarios(correspondinguse-casediagrams)shouldbeorganizedintocategories.
3. Thereviewleaderreadstheusecasedeliberately.
4. Whenthetokenispassed,theholderoftheSensorcardisaskedtodescribetheresponsibilitiesnotedonthecard.
5. Iftheresponsibilitiesandcollaborationsnotedontheindexcardscannotaccommodatetheusecase,modificatio
nsaremadetothecards.

Thiscontinuesuntiltheusecaseisfinished.Whenallusecaseshavebeenreviewed,requirementsmodelingcontinu
e.

GPCET,DepartmentofCSE|67
 SoftwareEngineeringLecturenotes

AssociationsandDependencies:Inmanyinstances,twoanalysisclassesarerelatedtooneanotherinsomefashio
n,muchliketwodataobjectsmayberelatedtooneanother.InUMLtheserelationshipsarecalledassociations.
Insomecases,anassociationmaybefurtherdefinedbyindicatingmultiplicity.ReferringtoThemultiplicitycon
straintsareillustratedinFigure6.13,where“oneormore”isrepresented
using1..*,and“0ormore”by0..*.InUML,the asteriskindicatesanunlimitedupperboundontherange.

AnalysisPackages:Animportantpartofanalysismodelingiscategorization.Thatis,variouselementsofthe
analysismodelarecategorizedinamannerthatpackagesthemasagrouping—calledananalysispackage—
thatisgivenarepresentativename.

Forexample,ClassessuchasTree,Landscape,Road,Wall,Bridge,Building,andVisualEffectmightfallwithinthis
category.Othersfocusonthecharacterswithinthegame,describingtheirphysicalfeatures,actions,andconstraints.
TheseclassescanbegroupedinanalysispackagesasshowninFigure6.15.Theplussignprecedingtheanalysisclas
snameineachpackageindicatesthattheclasseshavepublicvisibilityandarethereforeaccessiblefromotherpacka
ges.

GPCET,DepartmentofCSE|68
 SoftwareEngineeringLecturenotes

Althoughtheyarenotshowninthefigure,othersymbolscanprecedeanelementwithinapackage.Aminussignindi
catesthatanelementishiddenfromallotherpackagesanda#symbolindicatesthatanelementisaccessibleonlytopa
ckagescontainedwithinagivenpackage.

GPCET,DepartmentofCSE|69
 SoftwareEngineeringLecturenotes

RequirementsModeling(Flow,Behavior,PatternsandWEBAPPS)

Whatisit?Therequirementsmodelhasmanydifferentdimensions.Floworientedmodels,behavioralmod
els,andthespecialrequirementsanalysisconsiderationsthatcomeintoplaywhenWebAppsaredeveloped.
Eachofthesemodelingrepresentationssupplementstheusecases,datamodels,andclassbasedmodels.
Whodoesit?Asoftwareengineer(sometimescalledan“analyst”)buildsthemodelusingrequireme
ntselicitedfromvariousstakeholders.
Whyisitimportant?Yourinsightintosoftwarerequirementsgrowsindirectproportiontothenumberofdi
fferentrequirementsmodelingdimensions.Althoughyoumaynothavethetime,theresources,ortheinclin
ationtodevelopeveryrepresentation,recognizethateachdifferentmodelingapproachprovidesyouwithad
ifferentwayoflookingattheproblem.Asaconsequence,youwillbebetter able to assess whether you’ve
properly specifiedwhatmustbeaccomplished.
Whatarethesteps?Flow-
orientedmodelingprovidesanindicationofhowdataobjectsaretransformedbyprocessingfunctions.Beha
vioralmodelingdepictsthestatesofthesystemanditsclassesandtheimpactofeventsonthesestates.Pattern
-
basedmodelingmakesuseofexistingdomainknowledgetofacilitaterequirementsanalysis.WebApprequi
rementsmodelsareespeciallyadaptedfortherepresentationofcontent,interaction,function,andconfigura
tionrelatedrequirements.
Whatistheworkproduct?Awidearrayoftextbasedanddiagrammaticformsmaybechosenfortherequire
mentsmodel.Eachoftheserepresentationsprovidesaviewofoneormoreofthemodelelements.
How do I ensure that I’ve done it right?
Requirementsmodelingworkproductsmustbereviewedforcorrectness,completeness,andconsistency.
Theymustreflecttheneedsofallstakeholdersandestablishafoundationfromwhichdesigncanbeconducte
d.

INTRODUCTION

Therequirementsmodelhasmanydifferentdimensions.Floworientedmodels,behavioralmodels,andthespecialr
equirementsanalysisconsiderationsthatcomeintoplaywhenWebAppsaredeveloped.Eachofthesemodelingrep
resentationssupplementstheusecases,datamodels,andclassbasedmodels.

FLOW-ORIENTEDMODELING

Althoughthedataflowdiagram(DFD)andrelateddiagramsandinformationarenotaformalpartofUML,theycanb
eusedtocomplementUMLdiagramsandprovideadditionalinsightintosystemrequirementsandflow.

GPCET,DepartmentofCSE|70
 SoftwareEngineeringLecturenotes

TheDFDtakesaninput-process-
outputviewofasystem.Thatis,dataobjectsflowintothesoftware,aretransformedbyprocessingelements,andresu
ltantdataobjectsflowoutofthesoftware.Dataobjectsarerepresentedbylabeledarrows,andtransformationsarerep
resentedbycircles(alsocalledbubbles).TheDFDispresentedinahierarchicalfashion.Thatis,thefirstdataflowmo
del(sometimescalledalevel0DFDorcontextdiagram)representsthesystemasawhole.Subsequentdataflowdiagr
amsrefinethecontextdiagram,providingincreasingdetailwitheachsubsequentlevel.

CreatingaDataFlowModel:Thedataflowdiagramenablesyoutodevelopmodelsoftheinformationdomainan
dfunctionaldomain.AstheDFDisrefinedintogreaterlevelsofdetail,youperformanimplicitfunctionaldecompos
itionofthesystem.

Afewsimpleguidelinesofadataflowdiagram:
(1) thelevel0dataflowdiagramshoulddepictthesoftware/systemasasinglebubble;
(2) primaryinputandoutputshouldbecarefullynoted;
(3) refinementshouldbeginbyisolatingcandidateprocesses,dataobjects,anddatastorestoberepresentedatthene
xtlevel;
(4) allarrowsandbubblesshouldbelabeledwithmeaningfulnames;
(5) informationflowcontinuitymustbemaintainedfromleveltolevel,2and
(6) onebubbleatatimeshouldberefined.Thereisanaturaltendencytoovercomplicatethedataflowdiagram.Thiso
ccurswhenyouattempttoshowtoomuchdetailtooearlyorrepresentproceduralaspectsofthesoftwareinlieuofinfo
rmationflow.

CreatingaControlFlowModel:Forsometypesofapplications,thedatamodelandthedataflowdiagramareallt
hatisnecessarytoobtainmeaningfulinsightintosoftwarerequirements.However, a large class of applications
are “driven” by events rather than
data,producecontrolinformationratherthanreportsordisplays,andprocessinformationwithheavyconcernforti
meandperformance.Suchapplicationsrequiretheuseofcontrolflowmodelinginadditiontodataflowmodeling.

GPCET,DepartmentofCSE|71
 SoftwareEngineeringLecturenotes

AneventorcontrolitemisimplementedasaBooleanvalue(e.g.,trueorfalse,onoroff,1or0)oradiscretelistofconditi
ons(e.g.,empty,jammed,full).Toselectpotentialcandidateevents,thefollowingguidelinesaresuggested:
• Listallsensorsthatare“read”bythesoftware.
• Listallinterruptconditions.
• Listall“switches”thatareactuatedbyanoperator.
• List alldataconditions.

GPCET,DepartmentofCSE|72
 SoftwareEngineeringLecturenotes

• Recalling the noun/verb parse that was applied to the processing narrative, review all “control items” as
possible control specification inputs/outputs.
• Describe the behavior of a system by identifying its states, identify how each
stateisreached,anddefinethetransitionsbetweenstates.
• Focusonpossibleomissions—averycommonerrorinspecifyingcontrol

TheControlSpecification:Acontrolspecification(CSPEC)representsthebehaviorofthesystemintwodiffere
ntways.TheCSPECcontainsastatediagramthatisasequentialspecificationofbehavior.Itcanalsocontainaprogra
mactivationtable—acombinatorialspecificationofbehavior.
Figure7.4depictsapreliminarystatediagramforthelevel1controlflowmodelforSafeHome.

TheProcessSpecification:The PSPEC is a “minispecification” for each transform

atthelowestrefinedlevelofaDFD.Theprocessspecification(PSPEC)isusedtodescribeallflowmodelprocessesth
atappearatthefinallevelofrefinement.Thecontentoftheprocessspecificationcanincludenarrativetext,aprogram
designlanguage(PDL)descriptionoftheprocessalgorithm,mathematicalequations,tables,orUMLactivitydiagr
ams.

GPCET,DepartmentofCSE|73
 SoftwareEngineeringLecturenotes

CREATINGABEHAVIORALMODEL

Wecanrepresentthebehaviorofthesystemasafunctionofspecificeventsandtime.
Thebehavioralmodelindicateshowsoftwarewillrespondtoexternaleventsorstimuli.Tocreatethemodel,yousho
uldperformthefollowingsteps:
1. Evaluateallusecasestofullyunderstandthesequenceofinteractionwithinthesystem.
2. Identifyeventsthatdrivetheinteractionsequenceandunderstandhowtheseeventsrelatetospecificobjects.
3. Createasequenceforeachusecase.
4. Buildastatediagramforthesystem.
5. Reviewthebehavioralmodeltoverifyaccuracyandconsistency.

IdentifyingEventswiththeUseCase:Theusecaserepresentsasequenceofactivitiesthatinvolvesactorsandthe
system.Ingeneral,aneventoccurswheneverthesystemandanactorexchangeinformation.Ausecaseisexaminedf
orpointsofinformationexchange.

Theunderlinedportionsoftheusecasescenarioindicateevents.Anactorshouldbeidentifiedforeachevent;theinfo
rmationthatisexchangedshouldbenoted,andanyconditionsorconstraintsshouldbelisted.Oncealleventshavebe
enidentified,theyareallocatedtotheobjectsinvolved.Objectscanberesponsibleforgeneratingeventsorrecognizi
ngeventsthathaveoccurredelsewhere.

State Representations: In the context of behavioral modeling, two

differentcharacterizationsofstatesmustbeconsidered:
(1) Thestateofeachclassasthesystemperformsitsfunctionand
(2) Thestateofthesystemasobservedfromtheoutsideasthesystemperformsitsfunction.

GPCET,DepartmentofCSE|74
 SoftwareEngineeringLecturenotes

Thestateofaclasstakesonbothpassiveandactivecharacteristics.Apassivestateissimplythecurrentstatusofallofa
nobject’sattributes.Theactivestateofanobjectindicatesthe
currentstatusoftheobjectasitundergoesacontinuingtransformationorprocessing.Anevent(sometimescalledatr
igger)mustoccurtoforceanobjecttomakeatransitionfromoneactivestatetoanother.Twodifferentbehavioralrepr
esentationsarediscussedintheparagraphsthatfollow.
1) Thefirstindicateshowanindividualclasschangesstatebasedonexternalevents
2) Thesecondshowsthebehaviorofthesoftwareasafunctionoftime.

Statediagramsforanalysisclasses.Onecomponentofabehavioralmodelis
aUMLstatediagram9thatrepresentsactivestatesforeachclassandtheevents(triggers)thatcausechangesbetw
eentheseactivestates.Figure7.6illustratesastatediagram
fortheControlPanelobjectintheSafeHomesecurityfunction.
EacharrowshowninFigure7.6representsatransitionfromoneactivestateofanobjecttoanother.Thelabelsshownf
oreacharrowrepresenttheeventthattriggersthetransition.

Sequencediagrams.Thesecondtypeofbehavioralrepresentation,calledasequencediagraminUML,indicatesh
oweventscausetransitionsfromobjecttoobject.Onceeventshavebeenidentifiedbyexaminingausecase,themode
lercreatesasequencediagram—
arepresentationofhoweventscauseflowfromoneobjecttoanotherasafunctionoftime.Inessence,thesequencedia
gramisashorthandversionoftheusecase.Itrepresentskeyclassesandtheeventsthatcausebehaviortoflowfromcla
sstoclass.Figure7.7illustratesapartialsequencediagramfortheSafeHomesecurityfunction.

GPCET,DepartmentofCSE|75
 SoftwareEngineeringLecturenotes

PATTERNSFORREQUIREMENTSMODELING

Softwarepatternsareamechanismforcapturingdomainknowledgeinawaythatallowsittobereappliedwhenanew
problemisencountered.Insomecases,thedomainknowledgeisappliedtoanewproblemwithinthesameapplicatio
ndomain.

Oncethepattern has been discovered, it is documented by describing “explicitly the general

problemtowhichthepatternisapplicable,theprescribedsolution,assumptionsandconstraintsofusingthepatterni
npractice,andoftensomeotherinformationaboutthepattern,suchasthemotivationanddrivingforcesforusingthe
pattern,discussionof the pattern’s advantages and
disadvantages,andreferencestosomeknownexamplesofusingthatpatterninpracticalapplications”.

Thepatterncanbereusedwhenperformingrequirementsmodelingforanapplicationwithinadomain.Onceanappr
opriatepatternisselected,itisintegratedintotherequirementsmodelbyreferencetothepatternname.

DiscoveringAnalysisPatterns:Therequirementsmodeliscomprisedofawidevarietyofelements:scenario-
based(usecases),data-oriented(thedatamodel),class-based,flow-oriented,andbehavioral.
Eachoftheseelementsexaminestheproblemfromadifferentperspective,andeachprovidesanopportunitytodisco
verpatternsthatmayoccurthroughoutanapplicationdomain,orbyanalogy,acrossdifferentapplicationdomains.

Themostbasicelementinthedescriptionofarequirementsmodelistheusecase.Asemanticanalysispattern (SAP)
“is a patternthatdescribesasmallsetofcoherentusecasesthattogetherdescribeabasicgeneric application”.

GPCET,DepartmentofCSE|76