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