CSUTechnicalSolutionDesign
Document
forProject<projectname>
V1.00
CSUTechnicalSolutionDesignDocument
DocumentStatusandRevisionHistory
Version
Author
Issuedate
Revisions
V1.00
PaulCullen
23/07/2009
Firstreleaseversion
DocumentAuthorisation
Name:
PaulCullen
Position:
Manager,EnterpriseSolutionServices,DIT
Name:
BrianRoberson
Position:
Manager,TechnologyIntegration
DocumentDistribution
No.
Recipient
PositionandDivision
1.
TimArcher
EnterpriseSolutionArchitectTesting
2.
WayneMarr
EnterpriseSolutionArchitectApplications
3.
CraigPatterson
EnterpriseSolutionArchitectIntegration
4.
ConradDareEdwards
EnterpriseSolutionArchitectInfrastructure
5.
LukeWeston
EnterpriseSolutionArchitectSecurity
6.
DotCottee
TeamLeader,TechnologyIntegration
7.
ShaneJeffries
TeamLeader,TechnologyIntegration
8.
BrianRoberson
Manager,TechnologyIntegration
DocumentPurpose
Thepurposeofthisdocumentistoserveasatemplateforthecreationofthetechnicalsolutiondesigndocument.Forthetechnical
solutiondesigndocumenttobecompletedthefollowingcpmpletedandsignedoffdocumentsneedtobedeliveredviathe
EA&L/ESSgateway:
BusinessRequirements
Page2of19
CSUTechnicalSolutionDesignDocument
FunctionalRequirements
RelevantEnterpriseArchitecturalStandards
Eachsectioncontainsnotes,considerationsandsuggestionstoguideanenterprisesolutionarchitectinthecompletionofthe
document.Dependingonthetypeofproject,eginternallyorexternallysourced,somecomponentsmaybeoptionalorcompleted
fromsuppliersdocumentation.Sectionscanberenamed,asappropriate,tosuitthetypeandcomplexityoftheproject.
TableofContents
TABLEOFCONTENTS.....................................................................................................................................................................3
1.
PROJECTSUMMARY.............................................................................................................................................................6
2.
APPLICATIONDESIGN...........................................................................................................................................................6
2.1.
Userinterfaces.................................................................................................................................................................6
2.2.
UserManagement...........................................................................................................................................................6
2.3.
DataOutput.....................................................................................................................................................................6
2.4.
DataManagement...........................................................................................................................................................6
2.5.
CodingRequirements.......................................................................................................................................................6
3.
INTEGRATIONDESIGN..........................................................................................................................................................7
3.1.
IntegrationSchematic......................................................................................................................................................7
3.2.
EnterpriseDataRequirements.........................................................................................................................................7
3.3.
MasterDataDefinitions...................................................................................................................................................7
3.4.
IntegrationScope.............................................................................................................................................................7
3.5.
MasterDataDocumentTypes..........................................................................................................................................7
3.6.
EnterpriseInterfaceRequirements...................................................................................................................................7
3.7.
DataTransferVolumes.....................................................................................................................................................8
3.8.
DataAvailability..............................................................................................................................................................8
3.9.
Latency............................................................................................................................................................................8
4.
4.1.
SECURITYDESIGN.................................................................................................................................................................9
Securityrequirementsanalysisandspecification..............................................................................................................9
Page3of19
CSUTechnicalSolutionDesignDocument
4.2.
Assessingsecurityrisks....................................................................................................................................................9
4.3.
Treatingsecurityrisks......................................................................................................................................................9
4.4.
Correctprocessinginapplications....................................................................................................................................9
4.5.
Cryptographiccontrols.....................................................................................................................................................9
5.
5.1.
INFRASTRUCTUREDESIGN..................................................................................................................................................10
SystemArchitecture(development,qaandproductionimplementations)......................................................................10
5.2.
InfrastructureManagement...........................................................................................................................................13
5.2.1.
Availabilityrequirements.................................................................................................................................................13
5.2.2.
Businesscontinuityfailoverandfailback.......................................................................................................................13
5.2.3.
Archivalrequirements......................................................................................................................................................13
5.2.4.
Maintenance....................................................................................................................................................................13
5.2.5.
Logfilerotation................................................................................................................................................................13
5.2.6.
Startingandstoppingtheapplication..............................................................................................................................13
5.2.7.
Monitoringinterfaces......................................................................................................................................................13
5.2.8.
Dependences....................................................................................................................................................................13
AccessControl...............................................................................................................................................................14
5.3.
5.3.1.
BusinessRequirementforAccessControl.......................................................................................................................14
5.3.2.
UserAccessManagement................................................................................................................................................14
5.3.3.
UserResponsibilities........................................................................................................................................................14
5.3.4.
FileSystemAccessControl...............................................................................................................................................14
5.3.5.
NetworkAccessControl...................................................................................................................................................14
5.3.6.
MobileComputingandTeleworking...............................................................................................................................14
5.3.7.
OperatingSystemAccessControl....................................................................................................................................14
5.3.8.
ThirdPartymanagementandaccess...............................................................................................................................14
5.3.9.
PhysicalandEnvironmentalSecurity...............................................................................................................................14
5.3.10.
ApplicationandInformationAccessControl...................................................................................................................14
5.4.
ApplicationManagement...............................................................................................................................................15
5.4.1.
ThirdPartyServiceDeliveryManagement.......................................................................................................................15
5.4.2.
OperationalProceduresandResponsibilities..................................................................................................................15
5.4.3.
Upgradeandcodemigration...........................................................................................................................................15
5.4.4.
OSpatchingandsecuritypatching...................................................................................................................................15
5.4.5.
Solutiondependencies.....................................................................................................................................................15
5.4.6.
Jobmanagement(cron,timedprocesses,...)..................................................................................................................15
5.4.7.
Userinteractions(printing,outputfolders,http,ssh,...)...............................................................................................15
5.4.8.
Licensing...........................................................................................................................................................................15
5.4.9.
Ongoingcosts..................................................................................................................................................................15
5.5.
ClientApplications.........................................................................................................................................................15
5.5.1.
Architecture.....................................................................................................................................................................15
5.5.2.
Installation.......................................................................................................................................................................15
5.6.
Migration.......................................................................................................................................................................16
5.6.1.
Migrationstrategy(howarewegoingtogointoproduction)........................................................................................16
5.6.2.
Rollbackstrategy..............................................................................................................................................................16
5.6.3.
Decommissioning.............................................................................................................................................................16
Page4of19
CSUTechnicalSolutionDesignDocument
6.
TESTDESIGN.......................................................................................................................................................................17
6.1.
PSC/SDLCAnalysisPhase(RequirementsTesting)...........................................................................................................17
6.1.1.
UseCases.........................................................................................................................................................................17
6.1.2.
RiskRegister.....................................................................................................................................................................17
6.1.3.
Requirementvalidation...................................................................................................................................................17
6.2.
PSC/SDLCDesignPhase(FunctionalTesting)...................................................................................................................17
6.3.
PSC/SDLCTestingPhase(VerificationTesting)................................................................................................................18
6.4.
ImplementationPhase...................................................................................................................................................19
Page5of19
CSUTechnicalSolutionDesignDocument
1. ProjectSummary
Provideadescriptionofwhatapplication/system/productwillbedevelopedusingthissolutiondesign.Includeasummaryof:
Currentapplication,systemorproductinuse,ifany.Thiswillprovideareferencepoint.
Themainfeaturesofthissolutionincludingadescriptionofgeneralfunctionality,maincomponents,outputexpectationsandtarget
usergroups.Thisappliestobothinternallyandexternallysourcedapplications.
2. ApplicationDesign
Thissectionisflexibleinthatcomponentsmayormaynotbeincludeddependingonthecomplexityoftheprojectandwhetheritis
sourced/developedinternally.ProvidesufficientdetailtoallowatechnicalbuilddocumenttobegeneratedbyTIusingthis
documentasabase.Thedepthofdetailisdependentontherelationshipofthesolutiontotheexistingsystem.Forexample,anew
DEEWRSreportwillfollowwelldefinedconventionsandelementswhereasathirdpartyapplicationwillonlyhavehigherlevel
designelements,ornoneatall.
2.1. Userinterfaces
Definespecificelementsoftheuserinterfacesuchaswebpages,oracleforms,etc.,andincludemockupsasagreedwiththeclient.
2.2. UserManagement
Definetheownersandgroupsfortheapplication/systemandthegeneric,administrativeand/orsystemuserloginsandtheir
functions,ifany.Includeanythirdpartyaccessrequirements.Identifythejobpositionthathasownershipandadministrative
responsibilityfortheapplication/system.
2.3. DataOutput
Defineanyoutputartefactssuchasreports,files,screendisplays,datatransferstodatabasetables,orthirdpartyapplications,etc.
Includecommentsregardingfrequencyofoutputortransferandanyrequirementstoautomateprocesses,suchasovernightbatch
processing.
2.4. DataManagement
Definerequirementsforeachenvironmentincludingfolderstructures,filestorelocations,databaseelementsschemas,tables,
packages,triggersandsequences,asapplicable.
2.5. CodingRequirements
Definespecificrequirementsthatmustbecodedinthesolution.Include:thepreferredcodeplatform;theneedtouseincludefiles
and/ordatabasepackages;datavalidationrequirements;specificmethodologiesoralgorithmsrequiredtoderivedatavalues;
significantspecificoutputrequirementsexpectedbasedoninputdata,includinglogs;referencetoanyexistingcodeelementsthat
canbereused;anyintersystemtransferrequirements;authenticationandaccessmethodology.
Page6of19
CSUTechnicalSolutionDesignDocument
3. IntegrationDesign
TheintegrationdesignprovidesdetailsonhowthesolutionapplicationwillintegratewithotherCSU
applicationsand/orapplicationsoutsidetheuniversity.
3.1. IntegrationSchematic
Acontextdiagramistobeprovidedshowinghowthesolutionintegrateswithotherapplications.Alsoinclude
anysourcesthatmayberequiredformasterdata.
3.2. EnterpriseDataRequirements
AnySolutionDatawhichalreadyexistsintheMasterDataCataloguemustbesourcedfromthere.Ifknown,listthesedataobjects
andindicateifanyofthisMasterDatawillbechangedwithinthesolution.Indicatetheflexibilityforthesolutiontobeableto
consumedatafromanexternalsourceandcontributedatatoanexternaltarget(asmasterdata).Describetheability/flexibilityto
selectwhichtablesorattributeswillbepopulatedfrommasterdata,andwhichwillcontributetomasterdata.
3.3. MasterDataDefinitions
MasterDatadefinitionsareavailableinthefollowingdocumentslocatedintheUNCpath,S:\Administrative\Information
Technology\Architecture\6InformationArchitecture\MasterDataDefinition\1CurrentApproved
3.4. IntegrationScope
ERDshowingthemasterdataentitiestobeusedbythesolutionconsultationmaybewiththeEnterpriseDataArchitect,e.g:
3.5. MasterDataDocumentTypes
Defineenterprisedatastructurestobeusedbytheapplication.Inthecaseofnewstructuresbeingrequiredthatarenot
implementedinthedefinedEnterpiseDataModelornotimplementedinwebMethodsorMDR,thenconsultationwiththe
EnterpriseDataArchitectwillberequired.Forthisconsultation,youshouldgainthenecessaryinformationtocompletethe
structure.i.eName,Attributes,Sizes(?)andsqlnecessarytogatherfromthesourceapplication.Thisneedstoberecordedinthe
design,preferentiallyinatablestructureforTItoimplement.
3.6. EnterpriseInterfaceRequirements
TheITDataArchitectureStandardshowsthestandardmethodsofinteractionwithCSUdata.Showdetailsonhowthissolutionwill
connecttotheMasterDataand/orotherCSUapplications
WillthesolutionusewebMethodsorothermethodstoexchangedatawithotherapplications?Ifso,referto4.2.1to
providedetailsonrequirements.
Willtheapplicationrequiremasterdatatobeprovidedtoitslocaldatabase?
WillservicesbecalledinsidewebMethodstoreturndatafrommasterdata?ifso,providedetailsonservicei.ename,desc,
inputs,outputs,selecttouse(orflowdesign)
WilltherebeconnectionstoActiveDirectoryorLDAPforauthentication?
Willtherebegenericvendorprovidedintegrationbetweenapplications?i.eDegreeworksandBanner,DentistrysSaludand
Romexis
Willpasswordsneedtobepushedtotheapplication?(Currentlywedontprovidethisserviceasanumberofsecurity
questionsareraised...YouwillneedtoconsultwiththeEnterpriseIntegrationArchitect,EnterpriseDataArchitect,
EnterpriseApplicationArchitectandSecurityArchitecttodiscussifitbecomesarequirement.
Willdataberequiredtobepushedtoanexternalhostedapplication?i.eHeims
WillTransactionalControlneedtobeimplemented?i.e.XATransactions..dontcommitunlesstransactionsaresuccessful
onmorethanonedatabase.
Note:Whencreationofwebmethodsservicesortransfersarerequired,thereisawebMethodsDevelopersHandbookinthe
followinglocationS:\Administrative\InformationTechnology\Architecture\IntegrationCentre\Handbooks\Developers\Developers
Handbook.doc
Page7of19
CSUTechnicalSolutionDesignDocument
3.7. DataTransferVolumes
Provideestimatesonthevolumeofdatatobetransferredtoandfromthesolution.Thisshouldincludesizeforcurrentdemands
andfuturegrowth.
3.8. DataAvailability
DescribehowthesolutionwillcopeifaccesstotheMasterDataisunavailableforaperiodoftime.Addressspecificsituationssuch
ashowthesolutionwillrespondifuserauthenticationinformationisunavailable,orifCSUInteractisunavailable.Thiscanbecomea
problemfortheapplicationwhereservicestoselectfromMasterdataaretobeused.CurrentlythereisonlyoneMDRdatabasesoif
itbecomesunavailable,thiswillneedtobecateredforintheapplication
.
3.9. Latency
WhenusingMasterDatawithintheSolutionsownschemas.Howquicklywillthisdatahavetoberefreshed?Egrealtime,withinan
hour,overnightetc.Istherethepotentialforanadverseeffectonperformancewhereadatatransferisrunningbetween
campuses?
Page8of19
CSUTechnicalSolutionDesignDocument
4. SecurityDesign
ThegoalofsecuritydesignintheSDLCistoensuresecurityisanintegralpartoftheinformationsystemsolutionsdevelopedAll
securityrequirementsshouldbeidentifiedattherequirementsphaseofaprojectandjustified,agreedanddocumentedaspartof
theoverallbusinesscaseforaninformationsystem.AS/NZSISO/IEC27002:2006.
Thebusinessrequirementsfornewsolutions,orenhancementstoexistingsolutionsshouldspecifytherequirementsforsecurity
controls.Theriskmanagementprocesscanbeusedtoidentifytherequirementsforsecuritycontrols.
Specificationsforsolutionsshouldconsiderbothautomatedcontrolsandtheneedforgovernanceprocessestosupportmanual
controls.Thisalsoneedstobeconsideredwhenevaluatingsoftware,bothdevelopedandpurchased.
Thesecurityrequirementsandcontrolsshouldreflectthebusinessvalueoftheinformationassetsinvolved,andthepotential
impacttoCSUshouldafailureorabsenceofsecurityoccur.(SeealsoCSUMasterDataGovernance.doc)
Purchasedproductsneedtoundergoaformaltestingandacquisitionprocessthatincludessecurityfunctionality.
4.1. Securityrequirementsanalysisandspecification
4.2. Assessingsecurityrisks
ThepotentialrisksassociatedwiththeimplementationofanewsolutionneedtobeassessedatthebeginningoftheSDLC.The
assessmentofsecurityrisksshouldbeincludedinthesolutioncoordinatorschecklistandfollowthemethodspecifiedinthe
SolutionRiskAssessmentMethodologyforSolutionDesign.
Riskassessmentsshouldidentify,quantify,andprioritizerisksagainstcriteriaforriskacceptance(oravoidance)andtheobjectives
ofthesolutionbeingdevelopedand/ortheobjectivesofDIT.Theyshouldbeperformedinamethodical,standardised,reproducible
manner.
Theriskassessmentshouldhaveaclearlydefinedscope.Forthepurposesofthedocumentthescopewouldusuallybethe
individualsolutionbeingdeveloped,howeveritshouldincluderelationshipswithriskassessmentsonothersolutionsin
developmentorproduction.Itmayalsohavetoincludeelementsofrisktotheentireorganisation.
Theoutputofariskassessmentshouldthendeterminetheappropriatelevelofriskmanagement.Theappropriatelevelofrisk
managementwillguideanddetermineprioritieswhenimplementingcontrolstominimiserisk.
Riskassessmentsshouldincludeasystematicapproachofmeasuringorestimatingthemagnitudeofrisks(riskassessment)andthe
processofcomparingtheestimatedrisksagainstriskcriteriatodeterminethesignificanceoftherisks(riskevaluation).
RiskassessmentsshouldalsoformpartoftheSDLCreviewprocessthatincludesreassessingtherisksofasolutionperiodically
and/orwhensignificantchangesoccur.
4.3. Treatingsecurityrisks
Oncethesecurityrequirementsandriskshavebeenidentifiedandthedecisionforthetreatmentofriskshasbeenmade,the
appropriatecontrolsshouldbeselectedandaddedtothedesigndocument.ControlscanbeselectedfromtheISO27002standardor
fromothercontrolsets,ornewcontrolscanbedesignedtomeetspecificneedsasappropriate.
Theselectionofsecuritycontrolsisdependentuponthesolutionscriteriaforriskacceptance,andrisktreatmentoptionsandshould
alsobesubjecttoallrelevantnationalandinternationallegislationandregulations.
4.4. Correctprocessinginapplications.
Correctprocessinginapplicationsisneededtopreventerrors,loss,unauthorisedmodificationormisuseofinformationin
applications.Securitycontrolsshouldbeimplementedthatensurethevalidationofinputdata,internalprocessingandoutputdata.
4.5. Cryptographiccontrols.
Cryptographiccontrolscanbeusedtoprotecttheconfidentiality,authenticityandintegrityofinformation.
Theneedforcryptographiccontrolscanbedeterminedbyriskassessmentprocessesandalsothedatasclassificationlevelas
determinedbytheCSUMasterDataGovernanceprocess.
Cryptographiccontrolsmaybeneededinbothinformationstorageandtransmission.
Iftheuseofcryptographickeysistobeconsidered,akeymanagementprocessisessentialtoensuredistribution,storage,changing,
revoking,recovery,archiving,destroyingofkeys.
Page9of19
CSUTechnicalSolutionDesignDocument
5. InfrastructureDesign
Infrastructuredesignprovidesdetailsandguidanceonthecommondesignconsiderationsthatarerequiredtomadewhendesigning
infrastructuresolutionswithintheCSUDIT.
EnvironmentsrequiredMarkrequiredenvironmentswithanX
Environment
Role
Production
clientsconductbusiness
QualityAssurance
Functionaltestingofinhouseenhancements
Development
Inhouseenhancementsdevelopedandtested
Training
Clientapplicationtraining
Implementation
Newversionsimplementedandtestedpriorto
migrationtoproduction
Lifespanofenvironments
Permanent
AdHoc
Production
QualityAssurance
Development
Training
Implementation
5.1. SystemArchitecture(development,qaandproductionimplementations)
OperatingSystem
ServerSpec
Architecture
NumberofCPUs
RAM
Datacentre
RedHatEnterprise5(x86)
Allocatedstorage
RaidType
raid1+0(SASfibrechannel)
Size
20G
MountPoint
/
raid5(SASfibrechannel)
raid5(Sata)
LocalAttachedstorage
Page10of19
CSUTechnicalSolutionDesignDocument
Disk
Size
Type
C1t1d0
146G
SAS
Disk
MountPoint
RaidType
C1t1d0
Raid1
C1t2d0
Raid1
MetaDevices
Device
Submirrorof
MountPoint
RaidType
d10
Raid1
Raid1
MountPoint
RaidType
d11
Raid1
OperatingSystemPartitions
Partition
Raid1
Size
Type
10G
/var
20G
Network
DNS
VLAN(campus,public,
secure)
Ip
Shares
Protocol
Location
Version
RequiredInstalledSoftware
Software
Backup
Page11of19
CSUTechnicalSolutionDesignDocument
Partition
Frequency
Rotational/Archive
Timeframe
Database
Vendor
Version
Machine
Partition
DBName
DBServiceName
DBUser
DBPw
Page12of19
CSUTechnicalSolutionDesignDocument
5.2. InfrastructureManagement
5.2.1. Availabilityrequirements
Howlongcanthesystembeunavailablebeforeitstartstoimpactonthebusiness.Isthisimpactfeltonlyduringbusinesshoursor
doesthisextendafterhoursorduringweekends.
5.2.2. Businesscontinuityfailoverandfailback
Businesscontinuityprovidesalevelofbackupthatwillenabletheservice/applicationtoberestoredtoworkingorderinadefined
period.Whatstandbysystemsareavailableforfailoveroftheapplicationservices.Howisfailoverachievedandwhatprocedures
areinplacetoperformthisprocess.
5.2.3. Archivalrequirements
Arethereanyarchivalrequirementswithlogsorothercreateddata.Ifany,whataretheretentionperiodsforthisinformation?
Rememberbackupstorageisrotatedsoifyouneeddatafromapointintimegreaterthanthefrequencyofthebackupsyouneedto
specifythisasanarchivalrequirement.
5.2.4. Maintenance
Arethereanymaintenanceplansforanyofthesystems.Whatlevelofmaintenanceisprovided.
5.2.5. Logfilerotation
Arethereanylogsproducedbytheapplication.Whatinformationisavailableinthelogfilesandforwhatperiodaretheyrequired
tobekept.
5.2.6. Startingandstoppingtheapplication
Whatinterfacesareavailabletostartandstoptheapplication.Whatdocumentationisavailabletooperatorstocheckthestatusof
theapplication.Arethereanychecksordependenciesthatneedtobeconsideredbeforetheapplicationcanbestartedorstopped.
5.2.7. Monitoringinterfaces
Whatexternalmonitoringofthesystemcanbedonetoalertpeopleofanoutage.SelfmonitoringIsthereanyconfigurations
requiredtoallowtheapplicationtoalertoperatorsofpotentialissues(ping/Servicebased).
Nagios
ServerName
Test
NotificationTimeframe
ContactGroup
ServerName
Test
NotificationTimeframe
ContactGroup
OEM
5.2.8. Dependences
Whatexternaldependenciesdoesthisapplicationhave.Whatimpactwouldanexternaloutagehaveonthefunctionsofthe
application.Whatdependsonthissystemandhowwouldanoutageofthisapplicationimpactonothersystems.
Page13of19
CSUTechnicalSolutionDesignDocument
5.3. AccessControl
5.3.1. BusinessRequirementforAccessControl
Defineaccesscontrolpolicy
5.3.2. UserAccessManagement
Userregistration,provisioning,privilegeandpasswordmanagement.
5.3.3. UserResponsibilities
Passwordpolicies,unattendeduserequipmentandcleardeskandclearscreenpolicy
5.3.4. FileSystemAccessControl
Physicalorlogicalaccesstosystemsbysuppliersforsupportshouldbemonitoredandchangesauthorisedusingthechange
managementprocess.Protectionofsystemtestdataandaccesstoprogramsourcecodesecuritycontrol.
5.3.5. NetworkAccessControl
Whataccesscontrolsaretobeimplementedonthenetworklevel.Aretheirpoliciesthatrelateusagefromspecificmachinesor
locations?
5.3.6. MobileComputingandTeleworking
Whataretheconsiderationsaroundusingtheapplicationfromoffcampus.
5.3.7. OperatingSystemAccessControl
Securelogonprocedures,useridentificationandauthentication,useofsystemutilities,sessiontimeoutandlimitingofconnection
time
5.3.8. ThirdPartymanagementandaccess
Isthissystemmanagedbyathirdpartyifsowhoandhowdowecontactthem.HowdotheyaccessthesystemandwhoinCSUdo
theyreportto.
5.3.9. PhysicalandEnvironmentalSecurity
5.3.10. ApplicationandInformationAccessControl
Informationaccessrestrictionandsensitivesystemisolation
Page14of19
CSUTechnicalSolutionDesignDocument
5.4. ApplicationManagement
5.4.1. ThirdPartyServiceDeliveryManagement
Servicedelivery,monitoringandreviewofthirdpartyservicesandmanagingchangestothirdpartyservices.
5.4.2. OperationalProceduresandResponsibilities
Documentedoperatingprocedures,changemanagement,segregationofduties,separationofdevelopment,test,andoperational
facilities
5.4.3. Upgradeandcodemigration
Howareupgradestotheapplicationandorhardwaredelivered.
5.4.4. OSpatchingandsecuritypatching
WhatlevelofOSpatchingisrequested.Doesanygroupneedtobeconsultedaboutthetimingofpatching
5.4.5. Solutiondependencies
Arethereanyotherapplicationsorphysicalhardwarethatneedtobeinstalled?Whatversionoftheapplication?Aretheyinstalled
aspartoftheapplicationandhardwareinstallationordotheyneedtobeacquiredandinstalledseparately?
5.4.6. Jobmanagement(cron,timedprocesses,...)
Whattimedprocessesarerequiredandwhatistheirpurposeandfrequency.
5.4.7. Userinteractions(printing,outputfolders,http,ssh,...)
Howdousersinteractwiththeapplicationoutputfolders,webaccess,ssh,ftp,fileshares,telnetorotheraccess.Isprintingrequired
fromaWebor/andApplicationserver,pleasespecifyanyUNIXprintqueuesthatwillberequiredandiftheyneedanyothersettings
eg:portrait/landscape
5.4.8. Licensing
Whatsoftwareand/orhardwarelicenceshavebeenpurchased.Whatinsummaryarethelimitationsoftheselicenses.
5.4.9. Ongoingcosts
Whatongoingcosts(licensing,maintenance)areassociatedwiththeapplication.Whatprocessiscapturingtheseandmanaging
these.
5.5. ClientApplications
5.5.1. Architecture
Howdo/willtheclientsconnecttotheapplication?
5.5.2. Installation
Howwilltheapplicationbedeliveredandtowhatuserbase
Page15of19
CSUTechnicalSolutionDesignDocument
5.6. Migration
5.6.1. Migrationstrategy(howarewegoingtogointoproduction)
Howisthesystemgoingtobemadeavailablewithoutimpactingoncurrentsystems.Whatchangestoothersystemsneedtobe
madetomakethisserviceoperational.
5.6.2. Rollbackstrategy
Whatchangeshavebeenmadetoothersystemstoaccommodatethisapplication.Documenthowthesecanberemovedwithout
impactingonothersystems.
5.6.3. Decommissioning
Doesthissystemreplacethefunctionsofotherproductionsystems?Whatsystemsaretheseandwhatprocessisinplacetoremove
thesesystemsthatarenowredundant?
Page16of19
CSUTechnicalSolutionDesignDocument
6. TestDesign
TestingshouldoccurateachstageintheDevelopmentLifecycle.Someoftheactivitiesbelowshouldbeperformedaspartof
ProjectManagementactivities.
Note:Currentlytestingwilloccurinthisdocumentasanendtoendprocess,butwillhavesomesectionsmovedtotheSDLCintro
documentasrevisionsoccursothatthereisatestingoverlayintheintrodocandachecklistinthisdocumentoftestingelements
thatshouldcoverthesolutiondesign.
6.1. PSC/SDLCAnalysisPhase(RequirementsTesting)
6.1.1. UseCases
Astherequirementsarecompleted,UseCasesshouldbedevelopedtomodelprocessflows.Thesearethenusedatmultiplelevels
throughouttheprocessandoncesignedoffbythebusiness,arethemselvesatesttoensurerequirementsarecorrectlydefined.
UseCasesshouldbedevelopedbytheBusinessAnalyst(BA)and/orBusinessExpert(BE)andshouldincludesampledatawhichcan
beusedintestexecution
6.1.2. RiskRegister
Akeyreasonfortestingistoreducethelevelofriskandconveythecurrentlevelofrisktothemanagementandstakeholders.In
realworldsituationstestingislikelytobeconstrainedbyavailabilityofresourcesortimeorbothandthereforeitisimperativethat
testingisprioritisedbasedontherisksidentified.Risksshouldbeidentifiedforeachrequirementdefinedaswellasforgeneral
risks.UseofariskchecklistsuchasonemodelledonISO9126ishighlyrecommended.
TheRiskRegistershouldbedevelopedbytheProjectManager(PM)inconjunctionwiththeProjectTeam.
Thefollowingtableshowstheriskmatrix:
Likelihood
VeryHigh
High
Low
VeryLow
Severity
VeryHigh
A
A
A
B
High
A
B
B
C
Low
A
B
C
C
VeryLow
B
C
C
C
6.1.3. Requirementvalidation
AtleastonetechniquesuchasCauseEffectorStateTransitiontestingshouldbeappliedtotherequirementstounearthpotential
problemsbeforeprogressingfurtherthroughthedesign.
Thesetechniquesshouldnotbeperformedbythesamepersonwhowrotetherequirements,andislikelytobetheresponsibilityof
thePMorBE.
6.2. PSC/SDLCDesignPhase(FunctionalTesting)
Functionaltestingensuresthatthefunctionalcomponentsofthesolutionhavebeenconstructedinlinewithfunctional
specificationspriortoundertakingintegrationandacceptancetesting.
Testcasesshouldbedevelopedfromthefunctionalspecificationandusecases.Usecasesprovideavaluablebackbonetotestcase
preparationduetothecorrelationbetweenausecaseandassociatedtestcases.
Testcasesshouldidentifythefunctionalrequirement,usecaseorriskbeingtested,thestepsnecessarytoperformthetestandthe
expectedoutcomeofthetest.
Page17of19
CSUTechnicalSolutionDesignDocument
TestCasepreparationandexecutionshouldbeprioritisedbasedontheriskregisterforthesystem.Highriskitemsshouldhave
moretestcasesassociatedwiththemandbetestedmorethoroughlyandlowriskitemsmaynotbetestedatallgiventimeand
resourceconstraints
Functionaltestcasesarespecifictothefunctionbeingtestedandtesttheexecutionofthatfunction.Howeverthereshouldbe
additionaltestcasesthatcoverfunctionalityofthesystemoncethecomponentsareintegratedtogether.
UnitTestPreparation
Description:UnitTestsareusuallyautomatedandgetruneachtimeabuildofthesystem
happens.Whiletheyadddevelopmenttime,theygreatlyassistintheconfidenceinthesystemcomponentsandreducetheriskthat
changeswillintroducedefects.Theyarewrittenattheverylowestleveloftestingoutputsfromknowninputs.
Responsibility:Developer
Preconditions:SignedoffRequirementsDocuments
Outputs:Unittestexecutionreports
InputValidation&BoundaryValueTestPreparation
Description:InputValidationandBoundaryValuetestsensurethatinvalidinputtothesystemiscorrectlytrappedandhandled.
Theytrytomakethedataascleanaspossibletoavoiddatainconsistenciesandunformattederrorbeingreportedtotheenduser.
Responsibility:Developer
Preconditions:CompletedUnitTestExecution
Outputs:TestCaseexecutiondocumentation
UnitTestExecution
Responsibility:Developer
Preconditions:SignedoffRequirementsDocuments
Outputs:Unittestexecutionreports
InputValidation&BoundaryValueTestExecution
Responsibility:Developer
Preconditions:CompletedUnitTestExecution
Outputs:TestCaseexecutiondocumentation
AccessibilityTestPreparation
Description:
Accessibleapplicationsandsystemsarenowlegalrequirements.Systemsshouldcomplywiththerelevant
accessibilitypoliciesandguidelines,suchastheCSUWDAAP.
Responsibility:Developer
Preconditions:Allotherdesignphasetestingcompleted
Outputs:AccessibilityTestcases
AccessibilityTestExecution
Responsibility:Developer
Preconditions:Allotherdesignphasetestingcompleted
Outputs:Accessibilityreport
6.3. PSC/SDLCTestingPhase(VerificationTesting)
IntegrationTestexecution
Description:Integrationtestingisperformedoncetestingofdiscretefunctionsiscompletedandensuresthatthefunctionsofthe
solutionoperatetogetherasspecifiedinthefunctionalrequirements
Responsibility:SystemsOfficer
Preconditions:Systemcomponentsindividuallytestedandassembled
Outputs:TestCaseexecutiondocumentation
Page18of19
CSUTechnicalSolutionDesignDocument
SystemTestexecution
Description:Systemtestsfocusnotonlyonthedesign,butalsothebehaviourandeventhebelievedexpectationsofthecustomer.
Theyalsotestuptoandbeyondtheboundsdefinedintherequirementsspecification,andincludeareassuchasregressionsand
Securitytesting.
Responsibility:SystemsOfficer
Preconditions:Systemcomponentsindividuallytestedandassembled
Outputs:TestCaseexecutiondocumentation
Performance,LoadandStressTestexecution
Description:Performancemeasuringsystemresponsetimesandloadunderexpectednormalconditionsincludingother
applicationsandusernumbersLoadmeasuringsystemresponsetimesandloadunderexpectedpeakperiodsStressfindingthe
breakingpointofthesystemintermsofvolumeoftraffic,numbersofusersetc
Responsibility:SystemsOfficer
Preconditions:SystemOfficercompletesothertesting,codemovedtoQA
Outputs:Performancemetrics
6.4. ImplementationPhase
UserAcceptanceTesting(UAT)
Description:Testingofrealworldsituationswithrealisticdatabyactualusersofthesystem.
Responsibility:BusinessUserswithguidancefromsystemofficers
Preconditions:SystemOfficercompletestesting,systemreadyforrelease,codemovedtoQA
Output:Signedoffdocumentstatingthatthebusinessishappywithreleasingtheproducttoproduction,
listingtestsconductedindetailandtheresultsofthosetests.
Page19of19
