SystemsEngineeringCSC595_495Spring2018

HowardRosenthal

1

Notice�  Thiscourseisbasedonandincludesmaterialfromthetext:TheEngineeringDesignofSystems:ModelsandMethods(WileySeriesinSystemsEngineeringandManagement)3rdEditionDennisM.Buede,WilliamD.MillerPublisher:Wiley;3edition(February29,2016)Language:EnglishISBN-13:978-1119027904�  Italsoutilizesinformationfromthesetwoadditionalbooksaswellasmanycitedreferences:PracticalGuidetoSysML,ThirdEdition:TheSystemsModelingLanguage(TheMK/OMGPress)3rdEditionSanfordFriedenthal,AlanMoore,RickSteinerSeries:TheMK/OMGPressPublisher:MorganKaufmann;3rdedition(November7,2014)ISBN-13:978-0128002025SystemEngineeringAnalysis,Design,andDevelopment:Concepts,Principles,andPractices(WileySeriesinSystemsEngineeringandManagement)2ndEditionCharlesS.WassonSeries:WileySeriesinSystemsEngineeringandManagementHardcover:882pagesPublisher:Wiley;2edition(December2,2015)Language:EnglishISBN-13:978-1118442265Othermaterialwasusedfromthesewebsites:http://classes.engr.oregonstate.edu/mime/winter2013/ie366-001/Handouts/01-2a%20WIDGETS%20V2%20all%20text.pdfhttp://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdfhttps://sparxsystems.com.au/resources/uml2_tutorial/uml2_usecasediagram.htmlhttps://sparxsystems.com.au/resources/uml2_tutorial/uml2_sequencediagram.html

2

LessonGoals

� Understandwhatismeantbyarequirement� Understandwhatagoodrequirementis� Understandtherequirementshierarchy� Definelife-cyclerequirements� Thesevenstepsinstakeholderrequirementsdevelopment

� TheJointApplicationDesign(JAD)process�  Feasibilityanalysis� RolesandResponsibilitiesInRequirementsGeneration

3

4

ThereAreManyDifferentDefinitionsOfTheTermRequirement�  MIL-STD499B[MilitaryStandard,1993]

�  Arequirementidentifiestheaccomplishmentlevelsneededtoachievespecificobjectives.

�  ChambersandManos[1992]�  Arequirementdescribestheattributesofthefinaldesignthatmustbeapart

ofanyacceptablesolutiontothedesignproblem.�  Davis[1993]

�  Arequirementdefinesauserneedornecessaryfeature,function,orattributeofasystemthatcanbesensedfromapositionexternaltothatsystem.

�  Grady[1993]�  Arequirementisanessentialattributeforasystemoranelementofasystem,

coupledbyarelationstatementwithvalueandunitsinformationfortheattribute.

�  Harwelletal.[1993]�  “Ifitmandatesthatsomethingmustbeaccomplished,transformed,produced,

orprovided,itisarequirement-period.”

Note:Seetextforcompletereference

5

RequirementsAreTheCornerstoneoftheSystemsEngineeringProcess�  Obtaining“good”requirementsiscriticaltothesuccessfulengineeringofasystem�  Inthenextfewlessonswe’lllearnsomeofthesemethods

�  Requirementsmaybedividedbetweenstakeholderandderivedrequirements�  Stakeholders'requirements

�  Provideoperationalstatementsbythestakeholdersconcerningtheirneeds

�  Providethemeansforvalidatingthesystem'sdesignduringqualification�  RemembertheVeemodel

�  Derivedrequirements�  Enabletheengineersofsystemstopartitionthedesignprobleminto

componentsthatcanbeworkedinparallelwhilemaintainingdesigncontrolthroughtherequirementspartitionandtheinterfacesbetweenthecomponents

�  Enabletheverificationoftheconfigurationitemsandcomponentsduringthequalificationactivityduringdevelopment

�  Therequirementsforasystemsetupstandardsandmeasurementtoolsforjudgingthesuccessofthesystemdesign.

6

Don’tRushTheRequirementsProcess�  Theexitcriterionforthisinitialactivityintheengineeringofasystem

istheapprovaloftherequirementsdocumentbythestakeholders�  Theauthor’sdefinitionofstakeholderreallydefinesalltheusers

including�  Ownerand/orbillpayer,developer,producerormanufacturer,tester,deployer,

trainer,operator,user,victim,maintainer,sustainer,productimprover,anddecommissioner

�  Eachstakeholderhasasignificantlydifferentperspectiveofthesystemandthesystem'srequirements.Ifoneperspectiveissingledoutastheonlyappropriateone,thedevelopersofthesystemwillmisskeyinformation,andthesystemwillbeviewednegativelyorasafailurefromtheotherperspectives

�  ThisisanarrowerlistthanusedbytheProjectManagementInstitute(PMI)whichalsoincludesalltheallthepersonnelinvolvedindeliveringtheproject

�  Theengineersofasystemarefocusedonobtainingthisapprovalasquicklyaspossible,oftenwithoutdefiningalloftherequirements�  Thetrade-offandqualificationrequirementsaremissingfrommost

requirementsdocuments�  BuedeandMillerbelievethattherealexitcriterionofthe

requirementsdefinitionprocessistheapprovalbythestakeholdersoftheAcceptancePlanforthesystem�  IftheAcceptancePlanisaffirmed,thenalloftheotherportionsofthe

requirementsdocumentarepresumedtobedefinedinacceptabledetail

7

TheRequirementsHierarchy(1)

8

Mission Requirements

Stake- holders’

Requirements

System Requirements

Component Requirements

CI Requirements

Derived Requirements

TheRequirementsHierarchy(2)�  Atthetoparemission-levelrequirementsthatestablishhowthestakeholders

willbenefitbyintroducingthesysteminquestionintothesuper-systemofthesystem�  Thesemissionrequirementsrelatetoobjectivesofthestakeholdersthatare

definedinthecontextofthesupersystem,notthesystemitself�  ExampleBoeing777

�  Boeingidentifiedtwoprimarymissionrequirements�  Tripcostperseat�  Totaltripcost.

�  EachairlinecompanythatpurchasesaBoeing777ispartofthesuper-systemthatmostinfluencesanaircraftcompanyduringthedevelopmentphase.

�  Stakeholders'requirementsaredevelopednextinthecontextofthesemissionrequirements�  Focusontheboundaryofthesystem

�  Ifthestakeholders'requirementsaredefinedinternallytothesystem,theriskofhavingdesignstatementsembeddedintherequirementsgoesupsubstantially

�  Stakeholders'requirementsshouldbeasdesignindependentaspossible�  Boeing'sstakeholders'requirementsfortheBoeing777included

�  Liftableweightoftheaircraftatspecifiedconditions�  Emptyweightoftheaircraft�  Dragforceontheaircraftforcertainspecifiedflightconditions�  Fuelconsumptionoftheaircraftatcertainspecifiedflightconditions.

9

TheRequirementsHierarchy(3)�  Systemrequirementsareatranslation(orderivation)ofthe

stakeholders'requirementsintoengineeringterminology�  Modernsystemsengineeringsaythatsystemsengineersmustbe

involvedinthisprocess,whichleadstotheStakeholdersRequirementsDocument

�  Thesystemsengineersjobistoworkwiththestakeholderstodefinethestakeholders'requirementssoastomakesurethatthereissignificantdesignfreedomwithintheserequirementsandthatmanyfeasibledesignsexist�  Ifthereisnofreedomtodesign,thenwhybotherwithdesigntrade-offs�  Rememberthatakeyelementofsystemsengineeringinvolvesdesigningthe

system�  Oncethistranslationoccurs,thederivationprocessofrequirements

continues�  Thegoalofthedesignprocessistocreateasystemspecificationthat

canbedevelopedintospecificationsforthesystem'scomponents,whicharethensegmentedintospecificationsforthesystemconfigurationitems(CIs)

�  Thetop-leveldocumentderivedfromthisprocessistheSystemsRequirementDocument(SysRD)

10

PragmaticPrinciplesInDefiningStakeholderRequirements1.  Becomethe“customer/consumeradvocate/surrogate”throughoutthedevelopmentand

fieldingofthesolution2.  Beginwithavalidatedcustomer(buyer)need-theproblem3.  Statetheprobleminsolution-independentterms4.  Knowthecustomer’s(orbuyer’s)missionorbusinessobjectives5.  Don’tassumethattheoriginalstatementoftheproblemisnecessarilythebest,oreventhe

rightone.6.  Whenconfrontedwiththecustomer’sneed,considerwhatsmallerobjective(s)is/arekeyto

satisfyingtheneed,andfromwhatlargerpurposeormissiontheneedderives;thatis,findatthebeginningtherightlevelofproblemtosolve

7.  Determinecustomerpriorities(performance,cost,schedule,risk,etc.)8.  Probethecustomerfornewproductideas,productproblem/shortfalls,identificationof

problemfixes9.  Workwiththecustomertoidentifytheconsumer(user)groupsthatwillbeaffectedbythe

system10.  Useasystematicmethodforidentifyingtheneedsandsolutionpreferencesofeachcustomer

group11.  Don’tdependonwrittenspecificationsandstatementsofwork

�  Face-to-facesessionswiththedifferentcustomer/consumergroupsarenecessary12.  Stateasmuchofeachneedinquantifiedtermsaspossible

�  However,importantneedsforwhichnoaccurateorquantifiedmeasureexistsstillmustbeexplicitlyaddressed

13.  Clarifyeachneedbyidentifyingthepowerandlimitationsofcurrentandprojectedtechnologyrelativetothecustomer’slargerpurpose,theenvironment,andwaysofdoingbusiness

11

KeyDefinitions(1)�  System

�  Asetofcomponents(subsystems,segments)actingtogethertoachieveasetofcommonobjectivesviatheaccomplishmentofasetoftasks.

�  SystemTaskorFunction�  Asetoffunctionsthatmustbeperformedtoachieveaspecificobjective.

� Human-designedSystem�  A specially defined set of segments (hardware, software,physicalentities,humans,facilities)actingasplanned

�  Itoperatesviaasetofinterfaces,whicharedesignedtoconnectthecomponents

�  Itisdesignedtoachieveacommonmissionorfundamentalobjective(i.e.,asetofspeciallydefinedobjectives)throughtheaccomplishmentofapredeterminedsetoffunctions.

�  Itissubjecttoasetofconstraints

12Note:TheseTermsWereIntroducedInLesson3

KeyDefinitions(2)�  System’sExternalSystems

�  Asetofentitiesthatinteractwiththesystemviaexternalphysicalandlogicalinterfaces�  Physical–Theactualwiresandsignalsthatconnecttwosystemstogether�  Logical–Theformatsofthedata,packets,etc.andthemeaningofthatdata

�  Inputsmaycomefromexternalsystemsorthecontext�  Allthesystem’soutputsflowtotheexternalsystems

�  SystemContext�  Thesetofentitiesthatcanimpactthesystem,butcannotbeimpactedbythe

system�  Weatherconditionscanimpactarocketlaunch,butthelaunchdoesn’timpact

theweather

13

System

External Systems

Context

are impacted by “System”

impacts, but not impacted by, “System”

Note:TheseTermsWereIntroducedInLesson3

DefiningTheDesignProblem

14

Life-cycleRequirements

� Requirementsmustbedevelopedforeachlife-cyclephase�  Development(designandintegration)�  Verification�  Manufacturingorproduction�  Deployment�  Training�  Operations�  Maintenance,supportandrefinement�  Retirement/Disposal

�  Thereisastrongcorrelationbetweenthestakeholdersandthelife-cyclephases.�  Theeightfunctionsshouldbeappliedtoeachstakeholdergroupandphaseofthe

system’slifecycle,whereverrelevantNotethatsomeofthesephasesmaynotberelevantforsomesystems.

15

ThereAreSevenStepsInStakeholderRequirementsDevelopment

� Developtheoperationalconcept� Definesystemboundarywithexternalsystemsdiagram

� Developsystemobjectiveshierarchy� Develop,analyze,andrefinerequirements(stakeholders'andsystem)

� Ensurerequirementsfeasibility� Definethequalificationsystemrequirements� Obtainapprovalofsystemdocumentation

16

IDEF0ViewOfStakeholderRequirementsDevelopment

17

USED AT: CONTEXT:

NODE: TITLE: NUMBER:

AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:

WORKINGDRAFTRECOMMENDEDPUBLICATION

READER DATE

P.

Originating & System Requirements,

Objectives Hierarchy, Boundary & Qualification

System Requirements

System-level Operational

Concept Design Changes

LowerLayerChanges toRequire-ments

Develop Operational

ConceptA1111

Define System

Boundary with an External Systems

A1112

Develop, Analyze and

Refine Requirements

A1114

Obtain Approval of

Requirements Documentation

A1117

RequirementsIssues

Originating & SystemRequirements

SystemBoundary

Define Qualification

System Requirements

A1116

QualificationSystemRequirements

Develop System

Objectives Hierarchy

A1113

ObjectivesHierarchy

System Boundary & ObjectivesHierarchy

Stakeholders'Constraints

Stakeholders'Objectives

Ensure Requirements

FeasibilityA1115

Proven RequirementsFeasibility

Proven RequirementsInfeasibility

Qualification System Issues

Inputs of Stakeholders

Originating & System

Requirements

Approval orDisapprovalQualification

ConstraintsStakeholders'Uses

Stakeholders'Jurisdiction

Operational ArchitectureChanges to Requirements

Engineers'RequirementsIssues

Stakeholders'RequirementsIssues

6

x

Engineering Design of a SystemDennis Buede

GMU Systems Engineering

Program

05/24/99

Define System-Level Design ProblemA111

Step1-DevelopTheOperationalConcept�  Theoperationalconceptispreparedfromtheperspectiveofthestakeholdersofthesystem�  Itdescribeshowthesestakeholdersexpectthesystemtofitintotheirworld,whichcontainsanumberofexternalsystemsandhasacertaincontext

�  Theoperationalconceptdefinesthesystemandexternalsystemsinverygeneralterms(oftenasablockdiagram)

�  Theobjectivesofeachstakeholdergroupareidentified�  Ausecasediagramandtheassociatedusagescenariosassequencediagramsareestablished�  Theseusagescenariosdescribewaysinwhichthestakeholderswillusethesystem

�  Thescenariosalsodescribestheinteractionsbetweenthesystemandothersystems�  Thescenariosdefineinputstoandoutputsofthesystem

�  Theoperationalconceptalsoincludesthemissionrequirementsforthesystem

18

Step2-DefineSystemBoundaryWithExternalSystems

�  Creatingtheexternalsystemsdiagrammakestheboundariesbetweenthesystemandexternalsystemsclear,leavingnodoubtinanyone'smindwherethesystemstartsandstops

�  Thedevelopmentofthisdiagramandofthesystem'sboundariesarenearlyalwaysharderthanmostpeopleexpect

�  Aspartofdefiningthesystem'sboundaries,alloftheinputstoandoutputsofthesystemareestablished�  Theexternalsystemorcontextwithwhicheachinputandoutputisassociatedisalsodefined

�  Insomecasesthereissomedefinitionofquantitativeandqualitativedataaswell,includingsize,reliability,performanceparameters,etc.

�  Atthispointyoucannowseewherethesystemfitsintoanylargersystemofsystems

19

Step3-DevelopSystemsObjectivesHierarchy

� Thenextstepistoclarifytheobjectivesofthestakeholdergroupsandformulatesacoherentsetofobjectivesforthesystem

� Thisisusuallyanarduoustask,asusersarenotalwayscompletelycertainofwhattheywant�  Eachobjectiveispartofthevaluesystemofoneormorestakeholdersfordeterminingtheirsatisfactionwiththesystem.

�  Theseobjectivesmayconflictwitheachotherinthesensethatgainingvalueononeobjectivemeansitwillbemaybenecessarytogiveupvalueonanother

�  Forinstance,thereareoftencostversussomefeature,i.e.howmuchreliabilitycanyouafford

20

Step4-Develop,AnalyzeandRefineRequirements�  Thissteprequiresthecreationofthestakeholders'requirementsfollowedbythe

translationoftheserequirementsintosystemrequirements�  Analyzeoftheoperationalconceptforsystemfunctions�  Identifyallofthesystem'sinputsandoutputs�  Specifytheinterfacesoftheexternalsystemswithwhichthesystemmustinteract�  Understandthesystem'scontext�  Understandtheoperationalconceptforsystem-wideandtechnologyconstraints�  Holdadetaileddiscussionswiththestakeholderstounderstandtheirwillingnesstotrade

offawiderangeofnon-mandatorybutdesirablesystemfeatures�  Definethecompletespecificationofqualificationrequirementsneededtoverifyand

validatethesystem'scapabilitiesfromthestakeholdersperspectives�  Oftenasimulationmodelthatdepictssomeoralloftheinteractionbetweenthesystem

andoneormoreotherexternalsystemsisdeveloped�  Thesesimulationmodelsoftenaddresstimingissues,specificperformanceissues,reliabilityor

availability,safetyandsecurity,orqualityofinputsandoutput�  Costanalysesofasystemshouldbedonewiththecontextinwhichthesystemisgoingto

operateinmind�  Animportanttoolusedduringrequirementsdevelopmentisprototyping,the

developmentofreplicasofthepartsofthesystem�  JointApplicationDesign(JAD)sessionsareanimportantpartofthisprocess

�  Foruserinterfaces,thisprototypingisparticularlyimportantbecauseusersoftendonotknowwhatispossiblewithnewtechnologyorhowtheymightusethisnewtechnologyeffectively

�  Forprototypingofuserinterfacestobeeffective,someformofusabilitytestingiscommonlyusedtodeterminehowtheusersfunctionwiththeprototype

�  Typicallythesejointsessionsaredonewithanexperiencedfacilitator

21

TheJointApplicationDesignProcess�  JointApplicationDesign(JAD)sessionsaremeetingswhereparticipantsexchangerequirementsand

specificationsinformationtobetterunderstandSDLC�  JADsessionsarere-engineeringbusinessresearchprocessestochangethewaytheyoperate,andthe

productstheyprovide�  JADparticipantsincludebutarenotlimitedto

�  Facilitator�  Endusers�  Clients�  ProjectSponsor�  Sr.ProjectManagerorVP�  ProjectLeaderorProjectManager�  Groupleaders-AreaSupervisors�  ITanddevelopmentspecialist�  Observers�  Recordkeepers.

�  JADProcessPhilosophy�  Peoplewhoworkonaprojecthavethebestunderstanding.�  PeoplewhoaretrainedinITunderstandexpertiseofspecifictechnologies.�  Informationsystemsandbusinessprocessareinterdependentprocesses.Peoplewhoworkinboth

areasarevaluableinunderstandingthesystemasawhole�  Bestsystemsaredevelopedwheneveryoneinagroupcollaboratesonaprojectequally

�  JADAdvantages�  Allowsforeffectiveparticipationamongteammembers�  Betterunderstandingofprojectobjectives�  Shorterprojectcompletiontimes�  Commitmenttothesuccessofprojectdeliverables�  Validationrequirementsdeterminedupfront

22

TheJADProcess

23

StakeholdersInTheJADProcess

24

JADPlanSessionDeliverables

25

Step5-EnsureRequirementsFeasibility

�  Allrequirementsmustbeexaminedtoensurethatafeasibledesignexiststhatmeetstherequirements�  BuildingaspacecrafttocarryhumanstoMarscannotbedoneforaproductioncostof$1,000,ooo

�  Inpracticethedevelopmentofhundreds,oreventhousands,ofrequirementsmakesthetestforfeasibilityquitedifficult

�  Trytoexaminetherequirementsearlytoensurethatadifficultrequirementisnecessary�  Remembermyexampleoftheantennathathadarequirementto

bendto90oineachdirectionat-40oC4500times,eventhoughtheantennaneverbentmorethan30oinrealworldtests

26

AreasofFeasibilityAnalysis(1)�  FunctionalDesirabilityandFeasibility

�  Doestheprojectofferfunctionalitythatcoversthestatedoperationalconceptsandneeds?

�  Whatpercentageoffunctionswillbesupportedbythesystem?�  Whatisthedegreeofsupportoffered?

�  Fullautomation–theoperatorneedsonlytoprovidetheminimumnecessaryinputandthesystemcarriesonthewholefunction

�  Criticalsupport–thesystemexecutesthemain/mostdifficultsteps,freeingtheuserfromtedioustaskssuchassearchingintoarchivematerialorperformingcomplicatedcalculations

�  What‘nice-to-have’featureswillalsobeoffered?�  Istheuserinterfacewelladaptedtotheenvironment?�  Compatibilityoftheuserinterfacewitheventualearlierapplicationsinuseinthe

companyisaplusthatcansignificantlyeasetheintroductionandacceptanceofthesystembytheusers.

�  Compatibilitywithotherapplicationsbeingimplementedwithinthecompanyorinstalledinexternalorganizationswithwhichthereisfrequentexchangeofinformationmayalsobehelpful

�  Howisthesystemexpectedtorespondtofuturebusinesschallenges:�  Architecture:Isitsufficientlyflexibletoaccommodatepossiblefutureneedsthatdifferfrom

today’s?�  Hardware:Cantheprocessingpower,storagespaceetc.beincreasedtohandleincreased

requirements?�  Systemsoftware:Isitsufficientlyup-to-datetoreasonablyensurethatitwillbesupportedduring

theproject’swholelifetime?�  Applicationsoftware:Havemeasuresbeentakentomakeitmaintainable?(useofstructured

developmentmethods,availabilityofsourcedocuments,…)

27

AreasofFeasibilityAnalysis(2)�  TechnicalFeasibility–Canitbebuilt?

�  Arethetechnologiesproposedcommerciallyavailable?Ifnot,whenaretheyexpectedtobe?Withwhatdegreeofcertainty?Howsafeisitconsideredtousethem?

�  Doesthesystemuseanyproprietarytechnologies?Ifso,howcriticalistheensuingdependencefromaspecificmanufacturer?

�  Arethecomponentsneededtobuildthesystemcommerciallyavailable?�  Doestheknow-howrequiredtoimplementandoperatethesystemexistonthelocal

market?�  Arethereanyfeaturesofthesystemthatarenotsuitedtotheparticularrequirementsof

theproject?(e.g.if24hoursoperationisneeded,canthesystemfunctionproperly?Ifthesystemneedspreciselycontrolledenvironmentalconditions,canthesebesecured?)

�  Istheinfrastructureappropriatetosupportthesystemoperation(e.g.arethecommunicationlinesofsufficientcapacitytocarrythedatatrafficattherequiredspeedandqualitylevels?)

�  FinancialFeasibility�  Whatisthecostofimplementationofthesystem?�  Whatistheannualcostofoperationofthesystem?�  Whataretheexpectedfinancialbenefitsfromthesystemoperation(directandindirect)?�  Havethefinancialresourcesneededtoimplementtheprojectbeenfound?�  Howwilltheeventualdifference(cost–benefit)befinancedafterthesystemisin

operation?�  Ifthecostgoesupduringimplementation(aquitecommonphenomenon!)orthe

availableresources‘dry-up’,whatwillhappen?Willtheprojectstop?Willitbepossibletoatleastpartiallyexploittheunfinishedsystem?Couldadditional(back-up)financialresourcesbefound?

�  Willthesystemretainsomevalueaftertheendoftheplanningperiod?Howcanthisbeexploited? 28

AreasofFeasibilityAnalysis(3)�  OperationalFeasibility

�  Typicalimplementationphaseprerequisitesmightbe:�  Legalframework

�  Arethereanynewlawsthatneedtobeestablished,inordertoallowthedevelopmentofthesystem?

�  Regulatoryframework�  Arethereanyinternalregulationsthatneedtobeamendedinordere.g.to

allowthepersonneltoparticipateinworkgroupsthatmaybeneededinthevarioussub-phasesoftheimplementation

�  Whatlevelofparticipationofvariouspersonnelisexpectedduringtheimplementationphase?�  Howseriouslywillnormalfunctioningbeimpairedbythedecreasein

employeetimeavailablefortheusualoperations?�  Arethereanypreparationactivitiesneededduringtheimplementationphase?

�  Willtheseinterferewith‘normalbusiness’?�  Arethesiteswherethesystemunitsshallbeinstalledreadytoreceivethem?�  Isthereenoughspace?�  Aretheenvironmentalconditionsappropriate?�  Isthereenoughpoweravailable?�  Aretherecommunicationlinesofsufficientcapacity?�  Hascablingbeeninstalledtocoverthelocalcommunicationneeds?

�  Canthetrainingoftheusersbeconductedinsuchawayasnottoexcessivelydrainemployeesoutofthesystemforlongtimeperiods?Woulditbepossibleorpreferabletotemporarilyclose-downsomeunitsduringtrainingtimeinsteadofhavingthemoperateatfractionalcapacity?

29

AreasofFeasibilityAnalysis(4)�  OperationalFeasibility

�  Typicaloperationphaseprerequisitesofteninclude:�  Contractualobligations

�  Arethereanyexistingcontractsthatneedtobeterminatedbeforethenewsystem’skick-off?

�  Operationalprerequisites�  Arethereinitialdatatobeloadedbeforeactualsystemstart-up?

�  Canitstotalvolumebeestimatedandinwhatformisitavailable?(electronic,paper,…).

�  Howreliable,completeandretrievableisit�  Whoisexpectedtoplan,perform,monitorandverifythisdatamigrationoperation?

�  Willaperiodof‘paralleloperation’(newsystemandproceduresalongsidetheexistingones)beneeded?�  Ifthenewsystemfails,isthereacontingencyplanthatallowsrollingbacktothe

previousstateofaffairs?I�  Willitbepossibletohavea‘parallelrun’periodaftertheinitialsystemstart-uporwill

thenewsystemimmediatelyreplacetheoldone?Whowillprovideuserswithassistance?

�  Howisthenewsystemexpectedtobeintroduced?�  Willthetotalsystemfunctionalitybeavailablefromthebeginningtoallusers?�  Willtherebeafunctionaland/or‘geographical’gradualroll-out?�  Doesthesystemstructure(bothhardwareandapplicationarchitectures)allow/dictate

suchaphasedactivationoffunctions?Isitdesirable?�  Dataentry:

�  Willextensivedataentrybeneededduringnormalsystemoperation?�  Whatistheexpectedvolumeofdataentryandwhoisgoingtoperformit?�  Havethecostandtimeneededbeencalculated?

�  Dataretentionrequirements,informationstorageandretrievalprocedures.�  Canthesystemsupportthefunctionalandquantitativerequirementsconcerning

archivaldata? 30

Step6-DefineQualificationSystemRequirements�  Qualificationistheprocessofverifyingandvalidatingthesystemdesignandthen

obtainingthestakeholders’acceptanceofthedesign�  Verificationisthedeterminationthatthesystemwasbuiltright�  Validationdeterminesthattherightsystemwasbuilt

�  Thequalificationsystemneededtoverifyandvalidatetheresultingsystem.�  Thisinvolvesthedevelopmentofinput/outputrequirementsforthequalificationsystem,

aswellassystem-widerequirements�  Trade-offrequirementsarealsoneededforthequalificationsystem�  Thequalificationsystemitselfmustalsobequalified

�  Todevelopthequalificationsystemrequirementswemust�  Reviewsystemobjectives�  Identifyqualificationsystemobjectives�  Identifypass/failthresholds�  Definequalificationoperationalconcept�  Definequalificationrequirements�  Definequalificationfunctionalarchitecture�  Definequalificationgenericphysicalarchitecture�  Generatequalificationcoveragematrices(allocaterequirementstofunctionalarchitectureand

functionstothegenericphysicalarchitecture)�  Besidesaddressingverification,validation,andacceptance,thequalificationsystemis

oftenbrokenintofourmethods�  Inspection�  Analysisandsimulation�  Instrumentedtest�  Demonstration

31

QualificationMethods

32

Method Description Used During: Most Effective When: Inspection (static test)

Compare system attributes to requirements.

During all segments of verification, validation, and acceptance testing for requirements that can be addressed by human examination.

Success or failure can be judged by humans; examples include inspection of physical attributes, code walkthroughs, and evaluation of user’s manuals.

Analysis and simulation

Use models that represent some aspect of the system. Examples of models might address system’s environment, system process, system failures.

Used throughout qualification, but emphasis is early in verification and during acceptance. Often used in conjunction with demonstration.

Physical elements are not yet available. Expense prohibits instrumented test, and demonstration is not sufficient. Issue involves all or most of the system’s life span. Issue cannot be tested (e.g., survive nuclear blast).

Instrumented test

Use calibrated instruments to measure system’s outputs. Examples of calibrated instruments are oscilloscope, voltmeter, LAN analyzer.

Verification testing. Engineering test models through system elements are available. Detailed information is required to understand and trace failures. Life and reliability data is needed for analysis and simulation.

Demonstration or field test

Exercise system in front of unbiased reviewers in expected system environment.

Primarily used for validation and acceptance testing.

Complete instrumented test is too expensive. High-level data/information is needed to corroborate results from analysis and simulation or instrumented test.

Step7-ObtainApprovalOfRequirementsDocumentation

� Thestakeholdersmustapprovetherequirementsdocuments�  Thisapprovalprocessworksbestwhenthestakeholdersareactivelyinvolvedinandunderstandtheprevioussteps

� Mostdocumentapprovalprocessesincludemultiplesteps

33

SampleRequirementsApprovalProcess

34

RolesandResponsibilitiesInRequirementsGenerationResponsibility Responsible Party

Who has the right to have an operational requirement?

Any individual/organization with an operational need involved in the development (design and qualification), production, deployment, training, operation, maintenance, support, refinement, decommissioning of and payment for the system

What does one call a requirer? Customer or stakeholder.

Who must respond to the requirer(s) having a requirement and how?

System’s requirements team, a collection of stakeholders and systems engineers. Response is acceptance, request for clarification, or rejection.

By what criteria does the systems requirements team respond?

The team establishes the external systems diagram and fundamental objectives hierarchy of the system, and then determines if the requirement fits within the scope of the system’s boundary and fundamental objective. Originating requirements also have to be assessed for the proper level of abstraction. A requirement should not be too strategic (mission oriented) or means (or solution) oriented.

How does one know that the requirement is "right"?

There is no right or wrong, only acceptable or unacceptable at this time. Over time, some of the system’s originating requirements will change.

How are these requirements conveyed to the people who get involved once a requirer has enunciated a requirement?

The system’s requirements team documents the collection of originating requirements. This Originating Requirements Document (ORD) is distributed to the stakeholders and systems engineers and includes a discussion of the operational concept of the system and the external systems and context associated with the system, including how each stakeholder expects to interact with the system. By reviewing the originating requirements document each stakeholder can see how the requirement suggested fits into the envisioned operation of the system, and can judge whether this vision makes sense from her/his perspective.

What does the systems requirements team do next?

The system’s originating requirements team remains active throughout the system’s life cycle. During design there will be many occasions when the system’s originating requirements must be reviewed and modified. These occasions will diminish in frequency once the system is deployed, but the requirements process is still critical as requirements changes and system modifications are envisioned, agreed to, developed, and fielded.

35