{InsertLogoHere}

{SystemName}
{SubsystemNameifapplicable}
{System/SubsystemVersionId}
SystemRequirementsandDesignDocument(SRDD)

{DateofGeneration}
{RevisionIDifapplicable}
Preparedfor:
{Customer}

Preparedby:
{ProgramTeam}
{Email}
{WebSiteifapplicable}

VotingSystemSRDD
01/25/17

TableofContents
1 Introduction..................................................................................................................4
1.1
PurposeoftheSystem.............................................................................................4
1.2
ObjectiveandSuccessCriteriaoftheProject..........................................................4
1.3
DefinitionofTermsandAcronyms.........................................................................4
1.4
References................................................................................................................4
1.5
DocumentTree........................................................................................................5
2 SystemOVERVIEW...................................................................................................6
3 SystemRequirements..................................................................................................7
4 SystemArchitectureandConceptofOperations.........................................................9
4.1
KeyDesignDrivers.................................................................................................9
4.2
KeyDecisions..........................................................................................................9
4.3
SystemArchitecture.................................................................................................9
4.4
ConceptofOperations.............................................................................................9
5 SystemAnalysis...........................................................................................................9
5.1
UseCases..............................................................................................................10
5.2
SystemLevelScenarios.........................................................................................10
5.3
SystemLevelStaticStructure...............................................................................10
5.4
SystemLevelBehavior.........................................................................................10
6 SystemOperationsandInterfaces.............................................................................10
7 SystemTesting&Validation.....................................................................................11
8 SystemDesign...........................................................................................................13
9 subsystemspecifications............................................................................................14
9.1
SubsystemX..........................................................................................................14
10 FutureCapabilities.....................................................................................................16
{ExampleAppendices}.......................................................................................................17
APPENDIXCOMMAND/SENSORLISTSandotherInterfacetables.........................17
APPENDIXComponenttablewithpower,size,etc......................................................17
AppendixImplementationinformation..........................................................................17
AppendixPreviousVersions.........................................................................................17
AppendixTradeandFeasibilitystudies........................................................................17

Pagei

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

ListofFigures&Tables
Error!Notableoffiguresentriesfound.

Pageii

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

{Instructions}
{Through this document, there are {italized} notes. These notes are general
instructionsasthetheformorcontentofagivensection.Theyshouldberemovedbefore
submittingthisdocumenttoanyreviewingauthority

RevisionHistory
{List all revisions here. Include the date of the revision, a description of what
changed,andbywhom.}
EXAMPLEOctober6thDevelopedinitialversionbasedonprevioussoftwareSRDDs

Pageiii

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

INTRODUCTION

{Thisdocumentisdesigntoprovidethecompletespecificationofagivensystem.(Itcanbe
usedtodescribeaspecificsubsystemorcomponenttoo).
TheSRDDcapturesbothrequirementsanddesignofagivensystem.Typically,inthecase
ofsoftware,detailsofdesignandimplementationarecapturedinthecodeitself.Inthecaseof
hardware,detailsarecapturedinindividualhardwarecomponentspecsordrawings.
Pleasereferenceallfiguresinthetext. Youmustfollowtheoutlinenumberingbelow. If
thereisasectionthatyoudonotneed,justputN/A(andeliminateallsubsectionsofthat
section).
Theintroductionsectiongivesthereaderanunderstandingofwhatthissystem/subsystemis.
Keepthisbriefagreaterdescriptionofthesystem/subsystemanditsconceptcanbefoundin
thenextsection.}
1.1

PurposeoftheSystem

ThetypicalvotingsystemsdeployedintheUnitedStatestodayaresubjecttoamyriadof
problemsandarefundamentallyimperfect.Notonlyaretheypronetonumeroushumanerrorsin
thecastingandcountingofvotes,buttheyplacetheburdenofstrategicvotingsquarelyonthe
shouldersofthevoters.Duetotheimpossibilityofgatheringperfectknowledgeofothervoters
opinions,manycitizens unwittinglycaststrategicvotesthatfailtoworkintheirownbest
interest.
Declaredstrategyvoting(DSV)isanondeterministic (itsnondeterminismisnotitsstrong
point;conductingsensiblesurveysis,though)votingsystemwiththepotentialtovastlyreduce
theoccurrenceofsuchwastedvotes.InordertorunaDSVelection,however,asophisticated
electronicinfrastructureisapracticalnecessity. Votescannotsimplybecountedbyhand
ballots of preferences must be interpreted and processed to select the vote that will yield
maximumutilityforthatindividual.Tomakethissortofsystemmoreaccessible,weproposeto
developanddeployasecure,webbasedplatformforinstantiatingandrunningDSVelections.
Perhaps a bigger pressure is the need to conduct elections with a physically distributed
electorate.Wecantexpectpeopletoauthenticatethemselvesinaphysicallocation,ortocasta
voteatthatphysicalspot.
Oneinterfacewillallowthecustomertospecifyparameterstodescribetheelectiontheywish
to conduct. We will provide access to parameters of the actual election as well as meta
parametersdescribingthebehavioroftheDSValgorithm. Aseparate,isolatedinterfacewill
allowendusersto(splitinfinitive)securelylogin,authenticate,andsubmittheirballots.Once
theelectionhasterminated(asspecifiedbythecustomerduringinstantiation),acentralserver
willprocesstheballotsandreturntheoutcome. Thisfinalstagewillalsoprovideaccessto
usefulstatisticsrelatedtotheelectionandallowaclienttovisualizetheelectionprocess.
Nicedescriptionoverallgoodwork!

Page4

ElecTechProjectTeam


1.2

VotingSystemSRDD
01/25/17

ObjectiveandSuccessCriteriaoftheProject

{Describethecentralissueorproblem.Alsodescribethegeneralapproachtosolvingthe
problem.Thisisagoodplacetoreiterateandexpanduponstatementofconcept(problem/high
levelsolution).Makesurethatyoureallyunderstandtherealproblemcustomerssometimes
hideitundertheirownperceivedsolution.}
1.3

DefinitionofTermsandAcronyms
DSVDeclaredStrategyVoting

1.4

References

Cranor,LorrieFaith.DeclaredStrategyVoting:AnInstrumentforGroupDecisionMaking.
December,1996[whatkindofreferenceisthis?Thesis?Thereisalsoapaperortwo]
1.5

DocumentTree
Intro
Overview
Requirements

1.6

Deliverables
Acoupleniftywebpagesandatidybackend.Fairenoughbutyoucanbemorespecific.

Page5

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

SYSTEMOVERVIEW

Theactualelectionprocesswilltakeplaceonasecureserver,executingcompiledJavacode
parameterizedwithuserspecifications.Thisserverwillbefedballotsfromawebserverthat
providesafrontendforballotsubmission.Votersmustauthenticatebeforevoting,sowewill
accessathirdpartyservertoverifytheircredentials.Instantiationofelectionswillalsotake
placeonthewebserverthroughaseparatefrontend.
DatawillbestoredinaMySQLdatabaseuntilitisneededforprocessing.Theprovided
algorithmwillquerythedatabaseforrelevantinformationanddeterminetheoutcomeofthe
election.Astheprocessingoccurs,statusdatawillbeavailableviaasocketforthirdparty
applicationstoanalyzeandvisualizethedata.

Page6

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

SYSTEMREQUIREMENTS
{ThissectionshowstheSystemlevelrequirements.
TypeTypeofrequirement:FFunctional,NNonFunctional,PPhysical,GGoalorPseudo,DDerived

IDOutlineorderedid1,1.1,1.1.1,etc.ItisnotnecessarythattheIDsbeinanysortofsequentialorder,rathertheyshould
notchangeids
DescriptionSeebelow
SourceWheredidtherequirementcomefrom
VerificationMethodHowwillthethisrequirementbeshowntobemeet
TracedtoWhatsubsystemsareinvolvedinmeetingthisrequirement
Listallrequirements.Thesecanbebrokenintogroupsbutavoidanyimplicationofdesign.Thecapabilities/functionsarebest
describedasalistofshalls,forexample:
1. Thesystemshallgatherenvironmentaldataperiodically
1.1. Thesystemshallrecordtemperaturesevery5minutes.
1.2. Thesystemshallrecordpressureevery30minutes.
Requirements can be organized into group or hierarchically. Each requirement should be numbered. Also, sometimes
requirementsarecapturedthathavenotbeenimplemented.Ifyouhaverequirementsthatarenotimplementedinyousystem,please
markthemwitha*anditalicizethem.Somerequirementshavespecificrangeorvaluesnotethoseintherange/valuecolumn(this
helpspreventthenumbersfrombeinglostinthetext)/
Thesourceoftherequirementshouldalsobenoted.Thesourceisusuallyauseroracustomer.Bespecific!Finally,discussthe
verificationmethodtobeusedtoshowthattherequirementhasbeenmeet.Verificationmethodsusuallyinvolvesomeformofformal
testingbutmayalsobemeetwithanalysis,design,heritage(i.e.previouslyshowntobemeet).
Fornonfunctionalrequirements,describeanyuserlevelrequirementsthatarenotdirectlyrelatedtofunctionality.Thisincludes
performance,security,modifiability,errorhandling,hardwarerestrictions,andphysicalenvironment. Alsoincludeuserinterface
andhumanfactorconstraints,documentationrequirements,extremeconditions,qualityrequirements,andresourceconstraints.

Page7

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

Forphysicalrequirements,describesanyphysicalrequirementsthatthesystemmustmeet.Examplesincludesize,mass,power,
etc.Oftenphysicalrequirementshavespecificvaluesassociatedwiththem.
Goalsareitemsthatthecustomerdesiredbutarenothardrequirements. Thesystemcanbeconsideredsuccessfulwithout
meetingthegoalbutdesignersshouldattempttogetasclosetothegoalaspossible. Designersshouldworkwithcustomersin
determiningthecostformeetingthegoal.Goalscanbefunctional,nonfunctionaland/orphysical.
Derived requirements are those that are directly related to another requirement or the chosen architecture. If either the
requirementorarchitecturalelementchanges,thisderivedrequirementcanchange.Derivedrequirementscanalsobefunctional,
nonfunctional,physical,and/oragoal.}
ID
1

Type
F

Description

Values/
Ranges

Source

Thesystemshallprovideanonlinefrontendforholding
declaredstrategyvotingelections.

Customer

Verificati
on
Method
Design

Customer

Testing

Admin Web
Module

Customer

Testing

Admin Web
Module

Customer

Testing

Admin Web
Module

Design Team

Testing

Admin Web
Module

Customer

Testing

Admin Web
Module
Admin Web
Module
Voter Web
Module
Voter Web
Module

1.1

FD

1.1.1

ND

1.2

FD

1.2.1

FD

1.2.2

ND

Provideabilityforremoteinstantiationofelectionsusinga
webpageprovidedbythesoftwareengineeringteam
Duringinstantiation,theparameterslistedinAppendixA
maybespecified.Whynonfunctional?
Electionwillberunwhenanadministratorconnectsthe
activationsocket.
Onlyoneconnectiontotheactivationsocketisallowedper
election.
Ensurereliablecommunicationovertheactivationsocket.

1.2.2.1

FD

UseTCP/IP.

Design Team

Testing

1.3

FD

Provideabilityforballotstobesubmittedremotely.

Customer

Testing

1.3.1

NG

Noballotsgetlost.Thisisstatedasarequirement.Itshould
beoftheform:Thesystemwillloseasfewballotsas
possible.

Customer

Testing

Page8

ElecTechProjectTeam

Traced To
Web Module


ID

VotingSystemSRDD
01/25/17

Type

Description

1.3.1.1

FD

Design Team

1.4

FD

Customer

Testing

Evaluator
Module

1.4.1

ND

Customer

Testing

Evaluator
Module

1.4.1.1

ND

Areceiptisproducedforeachsubmittedpreferencelist,
withoutanylinktothevoter.
RuntheelectionusingaprovidedDSValgorithmaccording
touserprovidedparameters.Theparameters,theirmeanings
andpossiblevalues,aredocumentedinAppendixB.
Allowtheevaluatortobereplacedwithoutmodifyingsystem
functionalityorsoftwareinterfaces.
DocumentthevotingsystemusingJavaDoc/Doxygen(See
AppendixC).
AllowtheevaluatortobeinC++,CorJava

Verificati
on
Method
Testing

Customer

Testing

All Modules

1.4.2

Values/
Ranges

Source

Traced To
Voter Web
Module

Evaluator
Module
Evaluator
Module
Database
Module

1.4.2.1

ND

UseJNItoaccesstheevaluatormethod.

Customer

Testing

1.5

FD

ProvideeachinstantiatedelectionwithauniqueIDsothat
preferencesheetscanbetiedtoaparticularelection.
Allowmonitoringofelectionstatusasitruns.

Design Team

Testing

Customer

Testing

Offerasocketforthirdpartyvisualizationprograms,using
theprotocolinAppendixC.
Oncetheelectionstarts,amonitoringsocketopensfor
trackingoftheelection
Maintainahighlevelofreliabilityfortransmittingthe
electionstatusdata.
UseTCP/IPtomonitorsocketcommunication.

Customer

Testing

Customer

Testing

Visualizer
Module

Customer

Testing

Visualizer
Module

Design Team

Testing

Maintainahighlevelofsecurity.
Protectagainstwebpagespoofs.
Usepostvariabletopreventspuriousdatatransmission.
Allowvariabletoexpireafteranallottedtimeperiod.
UseSSLtokeepauthenticationsecure.

Customer

Testing

Visualizer
Module
Web Module

Design Team

Testing

Web Module

Design Team

Testing

Web Module

Design Team

Testing

Web Module

Design Team

Testing

Web Module

2.1

FD

2.1.1

FD

2.2

ND

2.2.1

FD

NG

3.1

ND

3.1.1

FD

3.1.2

FD

3.2

FD

Page9

30min.

ElecTechProjectTeam

Visualizer
Module
Visualizer
Module


ID
4

VotingSystemSRDD
01/25/17

Type

Description

Useathirdpartyauthenticationsystemtoverifyvoter
identity.
ReliablysendauthenticationinformationtoanIPaddressand
portspecifiedbytheservicevendor.
UseTCP/IPforauthenticationsocketcommunication.

Customer

Verificati
on
Method
Testing

Customer

Testing

Authenticatio
n Module

Design Team

Testing

Authenticatio
n Module
Authenticatio
n Module
Voter Module
Database
Module

4.1

ND

4.1.1

FD

Values/
Ranges

Source

4.2

Inthecaseofauthenticationfailure,discardtheballotand
informthevoter.

Customer

Testing

Adheretospacerequirements.

Customer

Testing

Traced To
Authenticatio
n Module

5.1

ND

Allowthemaximumdatastoragesizetobesetasaparameter
atcompiletime.

Customer

Testing

Database
Module

5.2

FD

Implementaprocedureforstoringrecentelectionresultsand
automaticallycleaningupolddata.

Customer

Testing

Database
Cleaning
Module

5.2.1

FD

Deletionpolicy:removeanythingthatcompletedmorethan
onedayago.

Customer

Testing

Database
Module

5.2.2

FD

Ifspacerunsout,anerrormessagewillbedeliveredtothe
customer.

Customer

Testing

Database
Module

NG

Useasmuchopensourcesoftwareaspossible

Customer

Testing

Evaluator
Module
Visualizer
Module

Page10

ElecTechProjectTeam


ID
6.1

ND

UsetheGnucompilersuiteforC,andC++.

Design Team

Verificati
on
Method
Testing

6.2

ND

UsetheJavaSDKtoprovidevisualizationsupport.

Design Team

Testing

6.3

ND

UsetheApachewebservertoprovideelectionfrontends.

Design Team

Testing

Web Module

6.4

ND

RunLinuxonservermachine.

Design Team

Testing

Web Module

CompleteprojectbyDecember2006.

Customer

Testing

All Modules

Page11

Type

VotingSystemSRDD
01/25/17

Description

Values/
Ranges

ElecTechProjectTeam

Source

Traced To
Evaluator
Module
Visualizer
Module
Visualizer
Module

VotingSystemSRDD
01/25/17

SYSTEMARCHITECTUREANDCONCEPTOFOPERATIONS

{Thissectiondescribesthesystemarchitectureandconceptofoperations.Assuch,itisa
highlevel view of the system. Often the system architecture and CoOps emerge during
requirementsphase(andinsomecases,arethemselvesrequirements).Thesystemarchitecture,
conceptofoperations,andanalysisaredoneinparallelwitheachother.}
4.1

KeyDesignDrivers

{Startwithanidentificationofthedesigndrivers,i.e.thekeyrequirementsthatwilldrive
thedesign. Examples mayinclude:performanceormaintainability ormodifiability ordata
integrity.Thereareusuallytwoorthree.}
4.2

KeyDecisions

{Provideasimplelistofthekeydesigndecisionsthathavebeenmade.Usually,theseare
decisions that have wide ranging implications about how the system is designed and
implemented.}
4.3

SystemArchitecture

Therearefivemajorcomponentsofthesystemitselfwithoneextraneouscomponent.The
cruxofthedesignisthewebfrontend,dividedupintotheadministratorandvotersections.
Fromtheadministrativesection,onecaninstantiateanelectionandcauseanexistingelectionto
run.Fromthevotersection,onecanviewtheelectionsforwhichheisabletocastapreference
list,andchooseanelectionforwhichtocasttheaforementionedlist. Thefrontendinteracts
directly with the backend database to store election details and store preference lists
respectively.
Theevaluatoritselfinteractsdirectlywiththedatabasealsotoobtainvoterpreferencesfrom
whichitconductstheactualelection.Itcalculatestheresultsandstorestheseresultsbackinto
thedatabaseforlaterretrieval.

Page12

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

The communications module is a multithreaded socket listener that handles both the
initiationsocketandthemonitoringsocket. Whenanadministratoraccessestheappropriate
sectionofthewebfrontendandchoosestorunanexistingelection,thisactionopensasocket
fromthefrontendthatconnectionstothecommunicationsmoduleandsignalstheevaluatorto
startconductingtheelection. Italsohandlesthemonitoringsocketfromwhichathirdparty
clientcanconnecttoobtainthestatusofthecurrentrunningelection.
Finally, there is the separate monitoring module that can be run remotely on another
machine.Whenrequested,itopensasockettothecommunicationsmodule,requeststhestatus
ofthecurrentelectionandreturnstheresultsatthatpoint.
4.4

ConceptofOperations
{Provideahighleveloverviewofhowthesystemisexpectedtooperate.}

SYSTEMANALYSIS

{Theanalysisisusedtoexpandourunderstandingofthesystem.Analysisshouldprovidea
better understanding of how the system looks, what it contains (objects, data), what their
relationshipsare,andhowitbehaves.Analysisreflectsthesystemrequirements,architecture,
interfaces,etc..
Awidevarietyofmethodsmaybeusedhere. IhaveoutlinedthreesectionsbelowthatI
wouldrecommendthatyoustartwith.Feelfreetoaddadditionalmodels,sectionsasyoufind
useful.
FunctionalAnalysis Providesanindepthlookatthefunctionalityofthesystem. This
oftenisusedtohelpdevelopthesystemrequirements.Thiscanbedonethroughanumberof
methodsincludingscenarios,viewpointanalysis,andusecaseanalysis. Ifyouuseusecase
analysis (recommended), provide one or more overall usecase diagrams. Then include a
sectiondescribingeachusecase.Eachusecaseshouldincludetheentry,exit,andsequenceof
operationsduringtheusecase.Theyalsomaybesupplementedbyscenarios,state,activity,or
sequencediagrams. Remember,this isa functional viewofthesystem. Earlyinanalysis,
activitydiagramscanbeparticularlyusefulsincenormally,youhaventyetdefinedobjects.
Sequence diagrams are good for showing the flow of events between subsystems or other
identified.However,sequencediagramscanbedifficulttousesincetheyarebasedonobjects.
ScenariosAnothertoolistheuseofscenarios.Ascenarioisaspecificsetofeventsand
responses,oftenofthemoregeneralizedusecasesoroftheoverallsystem.Sequencediagrams,
activitydiagrams,oranEnglishdescriptionoftheeventsandresponsesareappropriate.
SystemBehaviorDescribingtheoverallsystembehaviorcanbeveryusefulparticularly
wherethesystemhasclearmodesofoperation. Showtheoverallsystembehaviorthrougha
toplevelstateoractivitydiagram.Thendecomposethevariousstatesasuseful.However,you
mayfindthatbeyondthetoplevel,itiseasiertousetheObjectStructureandBehaviorsection
belowtodecomposestates. Anotherkeyelementcanbesystemtimingdiagramsweretime
basedoperationsarecrucial

Page13

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

ObjectsForexample,youmighthaveanobjectdiagramthatshowsvariousdataitemsand
theirrelationships.Youmightuseanobjectdiagram.
Foreachobject,youmightinclude:

DescriptionandPurposeProvideanexternaldescriptionoftheelement.
CharacteristicsListthevariousobjectcharacteristicsandtheirpossiblevalues
ObjectBehaviorDescribetheobjectstatesthattheexternaluserwouldwishtoknow.
Feelfreetouseorthogonalstatestorepresentdifferentaspectsofthecomponent.
DataModelAnotherapproachwouldbetomodelsystemdataandtheirrelationshipsa
goodstartingpointfordataintensivesystemslikedatabases.
Thereareoftensystemlevelissuesthatneedtobeanalysized,studies,andstructuredtoaid
inthedesignedofthesystemanditscomponents.Examplesinclude:

5.1

ReliabilityandFDIR(FaultDetection,Isolation,andRecover)
Usability
Maintainability
DataModels}

UseCases

Use case

Actors

Election
Instantiation

Administrator,
website, database

Preference List
Submission

Voter, website,
database

Running an
Election

Administrator,
website, database,
socket listener,
evaluator

Sequence of Events

Observing an
Election

Visualizer, socket
listener, evaluator

Administrator submits login credentials to website.

Administrator fills out form containing election parameters.
Form is checked for errors and re-submitted if necessary.
Election is added into database.
Voter submits login credentials to website.
Voter selects election.
Voter submits preference list.
Preference list is checked for errors and re-submitted if
necessary.
Preference list is added into database.
Administrator submits login credentials to website.
Administrator clicks button to start election.
Evaluator is sent message to begin running election.
Socket listener is sent message to start accepting
connections from users wishing to observe this particular
election.
Evaluator begins pulling preference lists from database
and casting them as actual ballots.
Visualizer (or other observer client) opens connection to
socket listener.
Visualizer submits login credentials to socket listener.
Visualizer selects which election it would like to observe.
Evaluator begins sending results of election to observer.

Nicejob!
Page14

ElecTechProjectTeam

5.2

VotingSystemSRDD
01/25/17

SystemLevelScenarios

{Addsectionifapplicable.}
5.3

SystemLevelStaticStructure

{Addsectionifapplicable.}
5.4

SystemLevelBehavior

{Addsectionifapplicable.}
6

SYSTEMOPERATIONSANDINTERFACES

{This section identifies all external interfaces including user interfaces. Detailed
descriptionsoftheseinterfacesmaybeplacedintheappendixorseparateInterfaceControl
Documents(ICD)sbutshouldbereferencedhere.
Include user interface descriptions. Each should be tied to appropriate usecases and
actors.Descriptionsshouldincludescreenmockups,navigationpaths,anduserevents(mouse
selections,keypresses,menuitems,etc.).Onmanysystems,thisisaverysubstantialsection.
Oneapproachistobreakthissectionoutintoaseparateusersmanual.
Interfaces should include user interfaces, physical interface, and logical (software)
interfaces (including software object or package interfaces of they can be used by external
entities.

Page15

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

Describeeachexternalinterface.Everyexternalinterfacemustbedescribedindetail.For
eachexternalinterface,addasubsectionthatincludes:

PurposeoftheInterface
Conditionsunderwhichitisused.ThiscanbedescribedinEnglishorcanbedescribed
usingstatediagrams.Statediagramsareparticularlyeffectivewitheventdriven
interfaces.
Thedataitemstobepassedinandout.Includeadataitemdescriptionincludingdata
type,range,andotherrelevantinformationforeachdataitem.

Foreachsynchronouscallinginterface,identifytheobjectthatwillbecalledbytheexternal
softwareortheobjectintheexternalsoftwarethatwillbecalledbyyoursystem/subsystem.
Includeasequencediagramorotherrelevantinformationtoclearlyshowhowyoursoftware
workswiththeexternalsoftware.
Foreachnonsynchronouscallinginterfaceincludethefollowing.Youmayalsoincludeany
relevantdiagramstoillustratetheinterfaceorcommunicationsmethod.

CommunicationsMethodIdentifyhowthedataispassedsuchasshared
memory,datapool,orviahardwareinterface.

HardwareUsedIftheinterfacerunsacrossahardwareinterface,indicatethe
hardwareinterfaceandhardwareprotocalsinvolved(forexample,theinterfaceAruns
betweenthedistributedworkstationsviatheinternalethernetnetworkrunningTCP/IP
protocal).

DataFormatDescribetheformatofdatapassedacrosstheinterfaceincluding
datastructures.Forexample,thedataispassedin32Byterecordsmadeupofthe
followingdataelementsorthedataispassedData_PacketformatwhereData_Packetis
definedhereorinthedatadictionary.

DataFrequencyFordatathatisperiodic,describethedatafrequencyordata
rate.Fordatathatisnonperiodic,describetheconditionsunderwhichdataispassed
orreceived.

OtherIncludeanyotherinformationrelevanttounderstandingtheinterface
andtodesigningsoftwaretocommunicateusingtheinterface.Dontbeafraidtoinclude
additionalinformation.}
7

SYSTEMTESTING&VALIDATION
{Outlinethestepsneededtoprovethatthissystemwillworkinspace.

Describe how we will prove that this system meets requirements. Potential proofs
include:

Test(vibration,thermalvacuum,functionaltest,etc)

Analysis(mathematicalmodel,handcalculations,simulation)

Heritage(thesystemisthesameasonethathasalreadyproventoworkinspace)

Page16

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

Analogy(thesystemissimilarbutnotidenticaltoaflightprovensystem,butthere
areenoughsimilaritiesthatweareconvinceditwillwork)

Inspection(wecanconvinceourselvesbylookingatthecomponent/designthatitwill
meettherequirementkeepinmindthatthisisarareproof)

Describe any tests performed on this system. Systemlevel tests will be handled in the
systemsdocument,althoughtheyshouldbelistedhere(sothatfutureteamsarenotsurprised
whentheircomponentgetstested!).Includealltestresultseitherhereorreferenceanexternal
document.

Page17

TestPlanTheoverallplanfortestingthesystem
TestProceduresThespecifictestprocedurestobeused
TestCasesIndividualtestcasesincludingtestsetup,input,andexpectedoutput
TestResultsForeachtestcaserun,includethetestresults}

ElecTechProjectTeam

VotingSystemSRDD
01/25/17

SYSTEMDESIGN
{Thissectionprovidesdetailsonthedesignthatwasinitiallydescribedinthearchitecturesection.

First,provideatableofsystemdesigndecisions. These,ineffect,provideadditionalrequirementsforsubsystems. TheIDs

shouldstartat1000.Otherwise,theylooklikerequirements,ExampleTable:
ID
1000

1000.1
1000.1.1

Typ
e
F
N
P
/
G
D
F
F

Description

Values/
Ranges

Source

TheSystemShallThennotescanbeaddedinnonbold.
Youcanshowimportantorhighlevelrequirementsinshaded
cells

Mission
Specification

ModeABanditusesimagesfromthecameratonavigate

Mission
Specification
Mission
Specification

Navigationwillinterpretthecurrentlocationfromtheimages
andcomparethatwiththetargetlocationanddeterminewhich
thrustersneedtobefired

Verificatio
n Method
Design

Traced To

Provideasystem/subsystembreakdownthatidentifieseachofthesubsystem(eachsubsystem,inturnwillhaveasectioninthe
subsystemssection).Thiscanbedoneinatable,diagram,orindentedlist.
Thenincludeacomponenttablethatsummarizeskeyinformationaboutthesubsystems. Examplesmightincludeacomponent
tablethatincludepower,mass,volume,etc.fortheentirespacecraftbrokendownbysubsystems(andfurtherbycomponentsif
desired).
Finally,provideadescriptionofeachsubsystemtosubsysteminterface.Insomecasestheinterfacesthemselvesareregardedas
eitherseparatesubsystemsorpartofaspecificsubsystem. Remember,therearevariouslevelsinvolvedininterfacesphysical,
electrical,thermal,logical.}

Page18

ElecTechProjectTeam


9
9.1

DSVVotingSystemSRDD
01/25/17

SUBSYSTEMSPECIFICATIONS
SubsystemX

Eachsubsystemshouldbedescribedwiththesametypeofinformationasincludedinthe
systemlevel descriptions. These include subsystem requirements, architecture, interfaces,
design,andcomponents.Subsystems,inturn,arebrokenintosmallercomponents.Thesecan
createahierarchyofsections.
Summarizeeachsubsystem(component)with:
Description/Purpose:Description/purpose
Parent:Nameofparentsubsystemorcomponent
Class:PrimarilyHardwareorSoftware
Subcomponents:Listthesubcomponents
Interfaces:Identifyallinterfaces.Thiscouldbeasimplestatementoracomplexdescriptionof
interfaces,interfacestandards,etc.Complexinterfacedescriptionsshouldbeplacedinthe
detailssection,aseparatecomponentsection,orinanappendix.
ExplainwhatcomponentXdoesandwhichofthemajorrequirementsitmeets.Listthe
componentrequirements.Thiscouldbeasimplestatementoracomplextableofrequirements
similartothesystemrequirements. Useanotherfunctionalblockdiagramorotheranalysis
diagrams if helpful, or at least reference the main diagram. Give precise numbers of its
performancecharacteristics.
ExplainhowcomponentXisdesigned&built,orwhereitwaspurchasedandwhyyou
pickedthatvendor.Forsomecomponents,thedesigndecisionsshouldbespecified.
Ifthisisasoftwarecomponent:
Thedesignmodeldescribesthetoplevelorarchitecturaldesign.Thismodelshouldprovide
abridgeforthereadertounderstandthecode.Themodelshouldincludeadescriptionofthe
software structure. This could include objects, classes, modules, packages, files, etc. The
behavior of each subcomponent should be described as well as their interaction. If the
subcomponentissufficientlylargeorcomplexenough,includethedescriptionatthesubsystem
componentlevel.Ifitissmallandisprimarilydescribedincode,includeitasasubsectionto
thiscomponentssection.
Object/package/deploymentdiagramsareusedtocreateastaticstructure.Thisstructure
may or maynot be utilized during design. Object diagrams are usedto identify dataand
understandrelationships betweenthesethings. Eachobjectinthediagramsshouldidentify
whetheritisaninstanceoraclassandwhatstatesand/orattributestheobjecthas. Unless
neededtounderstandthesystem,internalinterfacescanbecapturedjustthroughrelationships.
Sequence, activity, state, and collaboration diagrams are used to define behavior. State
diagramsareusedtodefineobjectbehavior.Eventsononestatediagramcanbeusedtotrigger
eventsonotherstatediagrams.
Page19

ElecTechProjectTeam

DSVVotingSystemSRDD
01/25/17

The decision to include this information is complex. The basic issue is how much
informationdoyouneedbeforeworkingatacodeleveland/orhowmuchinformationdoesa
readerneedtounderstandthecode.

DescriptionandPurposeProvideanexternaldescriptionofthecomponent,i.e.what
doestheuserofthiscomponentneedtoknow.Also,describethecharacteristicsofthe
componentincluding:
Dynamic,Static,orEvolving
Adynamiccomponentcanchangeitsownstatewithoutanothercomponent
callingit.Typically,thismeansthatthecomponentisitsownprocess,task,or
thread.
Astaticcomponentcannotchangeitsownstatewithoutanothercomponent
callingit.Thiswillbethebulkofcomponents.
Anevolvingcomponentisusuallyanobjectthatcontrolsanexternaldevice.The
componentitselfdoesnotchangestateonitsownbutthedeviceitcontrolsmay
changeitsstateonitsown.Forexampleaprinterobjectthatmanagesthe
interfacetoaphysicalprinter.Theprinterobjectdoesnotchangeitsownstate,
therefordoesnothavetobeaprocess,task,orthread,buttheprinteritselfcould
changestates.
Temporary,Permanent,orPersistent
Atemporaryobjectiscreated,deleted,orbothatsomepointduringprogram
execution.Foralltemporaryobjects,describewhattriggerscreationand/or
deletion.
Apermanentobjectiscreatedatthestartofprogramexecutionandremainsuntil
programtermination.
Apersistentobjectexistsbetweenprogramexecutions(i.e.afileoradatabase
object).
Otherrelaventcharacteristicssuchaspublicvsprivateorsharedvsnonshared
objects.
OverallSubcomponentStates(Bestviastatediagram)Describethecomponentstates
thattheexternaluserwouldwishtoknow.Ofparticularimportancearestatesthat
controltheorderofprocedurecalls.Feelfreetouseorthogonalstatestorepresent
differentaspectsofthecomponent.

OverallSubcomponentProcessing(shownviaactivity,sequenceor
collaborationdiagram)Describethecomponentprocessingthatanexternaluser
wouldneedtoknow.

HardwareComponentIfthesubsystemhasmorethanonecomputeror
processor,indicatewhichcomputer(s)orprocessor(s)thatthecomponentrunson.
Listofallcomponentprocedure,methodsorentrypoints:
Foreach,includethepurpose,allpreandpostconditions(whatcomponentstatethe
componentneedstobeinbeforethisprocedure,method,orentrypointcanbecalled
andwhattheresultingcomponentstateis),andwhatdataispassed.Forallpassed
data,includethedatatype(thedataordatatypemaybereferencedinthedata
dictionarysection).

Page20

ElecTechProjectTeam

DSVVotingSystemSRDD
01/25/17

Example(assumescompass_directionandazmuth_directionaredefinedinthedata
dictionary)
Set_Location
Theset_locationfunctionsetsthetargetlocationfortheradar.
PreConditions
RadarObjectState:On
PostConditions
RadarObjectState:Targeted
I/O
Direction:compas_direction;Magneticcompassdirection.
Angle:angle_direction;Anglefromthehorizon.

Ifthisisahardwarecomponent:

MechanicalModifications
DiscussallmechanicalmodificationsmadetopreparecomponentXforflight.Ifthisisa
purchasedpart,describeallchangestothepackaging,structureormajorshiftingofcomponent
locations&functions.Ifthisisadesignedpart,describethemajorelementsinbuildingit(parts
lists,machineoperationsneeded,etc.).

ElectricalModifications
DiscussallelectricalmodificationsmadetopreparecomponentXforflight. Ifthisisa
purchasedpart,explainalloftheelectronicchanges(capacitorswapping,tracecutting,re
soldering,wireharnesschanges,etc.).Ifthisisadesignedpart,givethecircuitlayout,parts
listandwhere/howtheboardwasfabbed&stuffed.

SoftwareModifications
DiscussallmodificationstoexistingsoftwareinordertogetcomponentXflightready.If
thesechangesinvolvesignificantnewsoftwarework,usesection,instead.

TestingPlan
Describeanytestsperformedonthiscomponent.Systemleveltestswillbehandledinthe
systemsdocument,althoughtheyshouldbelistedhere(sothatfutureteamsarenotsurprised
whentheircomponentgetstested!).
Includealltestresults(eitherhereorreferenceanexternaldocument).
10 FUTURECAPABILITIES
List any future capabilities which, while not required in the current system, should be
consideredduringdesign.

Page21

ElecTechProjectTeam

DSVVotingSystemSRDD
01/25/17

{EXAMPLEAPPENDICES}
Appendicescanbeusedtocaptureanyinformationthatiseither:(a)toobigtoplaceinthe
maintextordoesnotseemtofit.Feelfreetoaddappendicesasneeded}.
APPENDIXCOMMAND/SENSORLISTSANDOTHERINTERFACETABLES
APPENDIXCOMPONENTTABLEWITHPOWER,SIZE,ETC.
APPENDIXIMPLEMENTATIONINFORMATION
Provideanyinformationneededtounderstandthecode.Thismightincludethingslike:

DirectoryStructures
Code/documentlistings
Compilation/assemblyinstructions

APPENDIXPREVIOUSVERSIONS
Thissectionisusedtocaptureinformationaboutpreviousversionsofthesystem(subsystem).
Youshouldprovidethefollowingfortheimmediatelypreviousversion:

Statusofpreviousversion(whatwasimplemented,etc.)

Issueswiththepreviousversion

AnalysisModelofthepreviousversion
FunctionalModel
StructuralModel
BehaviorModel

ArchitecturalDesignModelofthepreviousversion(AnalysisandDesignModels
maybemerged).
APPENDIXTRADEANDFEASIBILITYSTUDIES
Describe all trade and feasibility studies. Include all information relavent to making
requirementanddesigndecisions. ITISCRITICALTHATYOUINCLUDEINFORMATION
NOTJUSTABOUTWHYYOUCHOSEONEWAY,BUTALSOINFORMATIONABOUTWHY
YOU DID NOT CHOOSE ANOTHER WAY. Otherwise, subsequent developers may keep
revisitingthesameideasoverandoveragain.
Tradeandfeasibilitystudyinformationmaybecapturedintheappropriatesectionaboveor
hereinsubappendixsections.

Page22

ElecTechProjectTeam