Systems Engineering Spring 2018 Howard Rosenthal
Transcript of Systems Engineering Spring 2018 Howard Rosenthal
![Page 1: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/1.jpg)
SystemsEngineeringCSC595_495Spring2018
HowardRosenthal
1
![Page 2: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/2.jpg)
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
![Page 3: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/3.jpg)
LessonGoals
� Characteristicsofsoundrequirements� Writinggoodrequirements
� PleasereviewLesson2Pages39-49� CreatingtheOperationalConcept� Reviewexternalinterfaces� ReviewObjectivesHierarchy� ReviewPrototypingfromtheviewpointofusability
3
![Page 4: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/4.jpg)
4
![Page 5: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/5.jpg)
Introduction
� Thereareanumberofcontradictorydefinitionsinthebookwithrespecttorequirements� Forthepurposeofthefollowingdiscussionwewillbereferringtobothstakeholderrequirementsandsystemrequirements,unlessotherwisenoted
� Rememberthatthereshouldbefewerstakeholderrequirementsandmorederivedrequirementsthatwilleventuallyleadtodesignspecifications
5
![Page 6: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/6.jpg)
AttributesOfIndividualRequirements� Unambiguous
� Every requirement has only one interpretation� Understandable
� The interpretation of each requirement is clear� Correct
� A requirement the system is in fact required to do� Concise
� No unnecessary information is included in the requirement� Traced
� Each requirement is traced to some document or statement of the stakeholders� Traceable
� Each derived requirement must be traceable to an originating requirement via some unique name or number
� Design independent � Each requirement does not specify a particular solution or a portion of a particular
solution� Verifiable
� A finite, cost-effective process has been defined to check that the requirement has been attained
6
![Page 7: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/7.jpg)
AttributesOfTheSetOfRequirements� Unique
� Requirement(s) is (are) not overlapping or redundant with other requirements� Complete
� Everything the system is required to do throughout the system’s life cycle is included � Responses to all possible (realizable) inputs throughout the system’s life cycle are defined � The document is defined clearly and self-contained � There are no to be defined (TBD) or to be reviewed (TBR) statements � Completeness is a desired property but cannot be proven at the time of requirements development,
or perhaps ever� Consistent
� Internal - no two subsets of requirements conflict � External -no subset of requirements conflicts with external documents from which the requirements
are traced � Comparable
� The relative necessity of the requirements is included� Modifiable
� Changes to the requirements can be made easily, consistently (free of redundancy) and completely� Attainable
� Solutions exist within performance, cost and schedule constraints(FeasibilityStudy)
7
![Page 8: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/8.jpg)
8
![Page 9: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/9.jpg)
WritingRequirements� ReviewChapter2Pages39-49
� Belowisasimplersummaryfromthetext� Terminology
� Use“Shalltoindicatethelimitingnatureofarequirement� Statementsoffactuse“will”� Goalsuse“should”
� Requirementsstatementshallinclude� Asubject(therelevantlife-cyclesystem)� Thewordshall� Arelationstatement(e.g.,lessthanorequalto)� Theminimumacceptablethresholdwithunits� Dataclarifyingthetermsintherequirementcanalsobeadded.
� Avoid� compoundpredicates� negativepredicates
� Ambiguoustermsareaplague
9
![Page 10: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/10.jpg)
10
ToWriteGoodRequirementsYouMustKnowHowToTalkToStakeholders
� StartwithUsageScenarios(UseCases)� Asktoobservethemduring“stressful”periods� Givethemdraftstomodify� Givethemchoices(eyedoctor)� Workwiththemingroups
� Theyhitchhikeoffeachother’sideas� Wearepoorfiltersoftheirconversations
� ThesestakeholderrequirementsaredevelopedinearlyJADsessions
![Page 11: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/11.jpg)
11
WhentoStopSeekingRequirements
� Aslateaspossible� Requirementsevolveovertimeastheworldchanges� Emergentrequirementsarenew,undiscovered,oftencritical
� StandishGroup(1996)� Requirementrelateddifficultieswereresponsiblefor34to44
percentofprojectfailures� $81Bin1995and$100Bin1996werespentoncancelledITproducts
![Page 12: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/12.jpg)
SomeExamplesOfGoodRequirements� Thedevelopmentsystemshallreceiveinputsfromstakeholders.(Inputrequirement)
� Themanufacturingsystemshallhaveascrappagerateofx%.(Outputrequirement)
� Thedeploymentsystemshallacceptboxesofxft3.(Inputrequirement)
� Thetrainingsystemshallcompletetraininginxhours.(Outputrequirement)
� Theoperationalsystemshallhaveanoperationallifeofxyears.(Systemwideschedulerequirement).
� Therefinementsystemshallacceptnewtechnologyforthecentralprocessingunit.(Inputrequirement)
� Theretirementsystemshallcostlessthan$x.(Systemwidecostrequirement)
12
![Page 13: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/13.jpg)
SomeBasicWritingRules
� ProperGrammarThesystemshallstoptheflowofliquidhydrogenin0.5secondsorless.Theliquidstoppingtimeismeasuredfromthetimethecontrolsignalforstoppingisreceiveduntiltheflowthroughreacheszero.
� AvoidCompoundPredicatesThesystemshallfit...,weigh...,cost...(thiscausestraceabilityproblems).
� AvoidNegativePredicatesThesystemshallnot...(attempttoturnthisintoapositivestatementofwhatthesystemshalldo).
� AvoidAmbiguousTerms� Verbs:“optimize,”“maximize,”“minimize”� Adjectives:“adaptable,”“adequate,”“easy,”“flexible,”“rapid,”“robust,”
“sufficient,”“supportable,”“user-friendly”
13
![Page 14: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/14.jpg)
14
![Page 15: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/15.jpg)
WhatIsAnOperationalConcept� AnoperationalconceptasdefinedbyLanoisavisionforwhatthesystemis(ingeneral
terms),astatementofmissionrequirements,andadescriptionofhowthesystemwillbeused
� HooksandFarrydescribetheoperationalconceptasa“dayinthelifeofyourproduct”� Hungerusesthephrase“missionanalysis”forthedevelopmentoftheoperational
concept� Thecollectionofscenariosintheoperationalconceptincludessortiemissions(or
scenarios)andlifemissions,bothfromtheperspectiveofthestakeholders� Sortiemissionsarescenariosthatdescribehowthesystemwillbeusedduringthe
operationalphase,capturingthereasonsthesystemhasforexisting� Thelifemissionsaddressthenonoperational,lifecycleaspectsofthesystem,resultingin
scenariosforeachlifecyclephaseandsomethatcrosslifecyclephases� Theoperationalconceptisanopportunitytocreateavisionthatissharedamongallof
thestakeholdersforthereallymajorinteractionsofpeopleandthingswiththesystemofinterest
� Thesharedvisionisfromtheperspectiveofthesystem'sstakeholders,addressinghowthesystemwillbe� Developed� Produced� Deployed� Trained� Operatedandmaintained� Refined� retired
� Itdescribeshowtoovercomesomeoperationalproblemandachievethestakeholders'operationalneedsandobjectives
15
![Page 16: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/16.jpg)
ConceptualDesign(1)� Conceptualdesignidentifiesalternateconceptsandperformsthedecision
analysistoselectapreferredconceptfordevelopment.� Thealternatives,relativelyfewinnumber,spantherangeofkeydrivers
withintheprojectedtechnologycapabilitiesbeginningwithandcontinuingthroughtheoperationallifeofthesystem
� Forexample,minimumtimeorminimumenergytocompleteamission� Aswediscussedpreviouslykeysystemsengineeringconceptsidentifies
constructsequallyapplicabletoconceptualdesignastodevelopment� Operationalconcept� Externalsystemsdiagram� Objectiveshierarchy� Requirements� Function� Items� Components� Interfaces� Verification� Validation� Acceptance
16
![Page 17: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/17.jpg)
ConceptualDesign(2)� Conceptualdesignrequiresalevelofabstractionandfidelityforeach
ofthealternativesmuchlessthanthatforthedevelopmentoftheselectedconcept
� DecisionAnalysisforDesignTradesisequallyapplicableforconceptualtrades,havinganobjectiveshierarchyforeachalternateconceptthatembodiesstakeholder(risk/reward)preferencesforvaluesmeasuresandweights.
� Similarly,eachalternateconcepthasafunctional,physical,andallocatedarchitecturethatcanbeverified(usuallybyanalysisandsimulation)andvalidated
� Thereareseveralpossibleoutcomesregardingacceptanceoftheoperationalconcept� Oneormorealternativesareselectedfordevelopment� Analternativeisselectedsubjecttomodification� Thedecisiontogothroughafurtherconceptualdesignwith
additionalalternativesorhybridalternativescombiningaspectsofexistingalternatives
� Adecisionthatnoalternativeisselectedanddevelopmentdoesnotproceed
17
![Page 18: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/18.jpg)
PragmaticPrinciplesInConceptualDesign� Selectcriteriathathavedemonstrablelinkstocustomer/consumerneedsand
systemrequirements.� Operationalcriteriaincludingmissionsuccess,technicalperformance� Programcriteriaincludingcost,schedule,quality,risk� Integratedlogisticssupport(ILS)criteriaincludingfailurerate,
maintainability,serviceability� Maintaina“need-based”balanceamongtheoften-conflictingcriteria.� Selectcriteriathataremeasurable(objectiveandquantifiable)andexpress
theminwell-known,easilyunderstoodunits.However,importantcriteriaforwhichnomeasureseemstoexist,stillmustbeexplicitlyaddressed
� Usetrade-offstoshowthecustomertheperformance,cost,schedule,andriskimpactsofrequirementsandsolutionsvariations.
� Wheneverpossible,usesimulationandexperimentaldesigntoperformtrade-offsasmethodsthatrelyheavilyon“engineeringjudgment”ratingscalesaremoresubjecttobiasanderror.
� Havethecustomermakeallvaluejudgmentsintrade-offs.� Allowthecustomertomodifyrequirementsandparticipateindevelopingthe
operationalsolutionbasedonthetrade-offs.
18
![Page 19: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/19.jpg)
19
TheOperationalConceptDefinesJustificationAndUseOfTheSystem
• Vision
• Mission Requirements
• Usage Scenarios
Earth
MoonDirect: Earth-Moon-Earth
Earth
MoonEarth Orbit: Earth-Earth orbit-Moon-Earth
Earth
MoonLunar Orbit: Earth-Lunar orbit-Moon-Lunar Orbit-Earth
Kennedy “Put a man on the moon and bring him back safely by the end of the decade”
ThreeConceptualDesigns
![Page 20: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/20.jpg)
DevelopingScenarios(1)� Developingtheoperationalconceptservesthepurposeofobtainingconsensus
inthewrittenlanguageofthestakeholdersaboutwhatneedsthesystemwillsatisfyandthewaysinwhichthesystemwillbeused� Rememberthatthereisasystemforeachphaseofthesystem'slifecycleand
thatanoperationalconceptisneededforeachofthesystems� Bydescribinghowthesystemwillbeused,theoperationalconceptis
providingsubstantial(butincomplete)informationaboutthesystem'sinteractionwithothersystemsandthecontextofthesystem
� Theoperationalconceptincludesacollectionofscenariosasdescribedinausecasediagram� Oneormorescenariosareneededforeachgroupofstakeholdersineach
relevantphaseofthesystem'slifecycle.Theusecasediagramisusedtoprovidea“bigpicture”ofhowtheindividualscenariosrelatetoeachotherindefininghowthesystemistobeemployed
� Eachscenarioaddressesonewaythataparticularstakeholder(s)willwanttouse,deploy,andfixthesystem
� Thescenariodefineshowthesystemwillrespondtoinputsfromothersystemsinordertoproduceadesiredoutput� Includedineachscenarioaretherelevantinputstoandoutputsfromthe
systemandtheothersystemsthatareresponsibleforthoseinputsandoutputs.
� Thescenarioshouldnotdescribehowthesystemisprocessinginputstoproduceoutputs.� Eachscenarioshouldfocusontheexchangeofinputsandoutputsbythesystemwith
othersystems
20
![Page 21: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/21.jpg)
DevelopingScenarios(2)� Togeneratescenarios,startwiththekeystakeholder,theoperator/user,and
generateanumberofsimplescenariosExpandscenariogenerationisexpandedtootherstakeholderswhilestayingsimple
� Finallyaddcomplexitysuchasfailuremodestoallscenariosforeachstakeholder
� Inallscenariosthefocusshouldbeonwhatthestakeholdersandexternalsystemsdoandnotonhowthesystemsaccomplishtheirtasks� Thesystemofinterestshouldbeviewedasablackbox,thatis,thesystem's
internalsareblackedout,leavingonlytheinputsandoutputstothesystem� Therearesomecommonoperatingscenariosfornearlyeverysystem:
� Initializationofthesystem� Normalsteady-stateoperationinstandardoperatingmodesofthesystemfor
allpossiblecontexts(environments)inwhichthesystemmaybeplaced(e.g.,extremecold,outerspace)
� Extremesofoperationsduetohighandlowpeaksoftheexternalsystemsineachstandardoperatingmodeineachcontext
� Standardmaintenancemodesofthesystem� Standardresupplymodesofthesystem� Reactiontofailuremodesofothersystems� Failuremodesduetointernalproblems,providingasmuchgraceful
degradationofthemeta-systemaspossible� Shutdownofthesystem� Termination(phaseout)ofthesystem
21
![Page 22: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/22.jpg)
ExternalSystemsDiagramsandTheOperationalConcept� Note:Wehavepreviouslydiscussedexternalinterfaces,includingN2ChartsandIDEF0 � Thesingle,largestissueindefininganewsystemiswheretodrawthesystem's
boundaries� Everythingwithintheboundariesofthesystemisopentochange,subjecttothe
requirements� Theauthorclaimsthatnothingoutsideoftheboundariescanbechanged,leadingto
manyofthesystem'sconstraintrequirements.� However,sometimessoftwareorhardwaremayneedtobeinsertedintoanexternalsysteminorder
tofacilitateainterface� Theexternalsystems'diagramisthemodeloftheinteractionofthesystemwithother
(external)systemsintherelevantcontexts,thusprovidingadefinitionofthesystem'sboundaryintermsofthesystem'sinputsandoutputs
� Whoisresponsiblefordrawingtheseboundaries?� Allofthestakeholdershaveasayindrawingtheseboundaries� However,therearesubstantialcostandscheduleimplicationssotheprocurerofthe
systemtypicallyhasamajorinput� Eachstakeholdershouldbepreparedtodiscusstheimpactuponthemofvarious
boundary-drawingoptions� Thesystemsengineerisresponsibleforguidingthisboundary-drawingprocesstoa
conclusionthatthestakeholdersunderstandandaccept� Thesystemsengineerusestheseboundariestoestablishandmaintaincontrolofthe
system'sinterfaces.� Eachoftheexternalsystemsmustreceiveatleastoneoutputofoursystem
� Otherwise,thesystemshouldbepartofthecontext
22
![Page 23: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/23.jpg)
A-0OperationalViewOfProvideElevatorServices
23
![Page 24: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/24.jpg)
ElevatorA0Chart
24
![Page 25: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/25.jpg)
A1DiagramForAcceptPassengerRequestsandProvideFeedback
25
![Page 26: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/26.jpg)
ExternalSystemsDiagramExampleFor Accept Passenger Requests and Provide Feedback
26
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.
ProvideElevatorServices
A-0
PassengerCharacteristics
Electric Power& EmergencyCommunication Response
Service, Tests& Repairs
Request forEmergencySupport &EmerencyMessage
Request forFloor & Exit Support
Request forElevator Service &Entry support
BuildingRegulations
StructuralSupport,Alarm Signals& BuildingEnvironment
ModifiedElevatorConfiguration& ExpectedUsage Patterns
PassengerEnvironment
Acknowledgmentthat Request WasRecieved & StatusInformation
Diagnostic &Status Messages
Elevator EntryOpportunity
Elevator ExitOpportunity
EmergencySupport
RequestElevatorServices
A-11
UseElevatorServices
A-12
MaintainElevator
OperationsA-13
ProvideStructuralSupport
A-14
Passengers' Needs
EmergencyMessages
EmergencyCommunication
Passengers Elevator System Maintenance Personnel Building
PassengersNeedingElevatorServices
Passengersin ElevatorSystem
RepairParts
External Systems Diagram for Operational Phase
ElevatorEntry/ExitOpportunity
MaintenanceQuality Standards
None
1
xElevator Case StudyDennis Buede
George Mason Univ.
05/24/99
A-1
Note: A-0 Box is in the center and connects with A1 Functions
![Page 27: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/27.jpg)
TheObjectivesHierarchyDefinesThePerformanceSpaceforDesignSolution
• Objective:Keyperformanceparameter• Minimumacceptablethreshold
• Levelbelowwhichentiresystemisunacceptable
• Oftendefinedtootightly,inisolationofremainingsystemcapabilities
• Desiredperformancelevel• Oftenboundedbytechnologyconstraints
• Boundedbysatiationofstakeholders
• Hierarchyintegratesallobjectives
27
![Page 28: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/28.jpg)
28
ElevatorObjectivesHierarchy-Review
Monthly Operating Costs$1,500 - $1,000, Wt = 0.1
Average Wait (Routine)35 - 27 sec, Wt = 0.3
Average Wait (Priority)35 - 30 sec, Wt = 0.35
Average Transit Time90 - 60 sec, Wt = 0.35
Time in SystemObjectives, Wt = 0.35
Max'm Acceleration1.5 - 1.25 m/s2, Wt = 0.3
Max'm Accel'n Change2 - 1.5 m/s3, Wt = 0.5
Floor Leveling Error0.7 - 0.3 cm., Wt = 0.2
Ride QualityObjectives, Wt = 0.30
Operational MTBF1 - 1.5 yrs, Wt = 0.5
Operational MTTR8 - 4 hrs, Wt = 0.5
AvailabilityObjectives, Wt = 0.35
Operational PerformanceObjectives, Wt = 0.9
OperationalObjectives
![Page 29: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/29.jpg)
29
![Page 30: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/30.jpg)
PrototypingOverview� Prototypingcanapplytoanyaspectofthesystemandissynonymouswith
modeling� Aprototypeisaphysicalmodelofthesystemthatignorescertainaspectsof
thesystem,glossesoverotheraspects,andisfairlyrepresentativeofasubsetofthesystem� Theprototypecanrangefromasubscalemodelofthesystemtoapaper
display(storyboard)oftheuserinterfaceofthesystem� Prototypingbecamestronglyassociatedwithsoftwaredevelopmentinthe
1980s,especiallywiththespiralModel� Inordertobesuccessfulaproductmustbeusable,inotherwords,havea
friendlyuserinterface� Thedevelopmentofaprototypeforauserinterfacerangesfromathrowaway
prototypetoanevolutionaryprototype� Throwawayprototypesarejustwhatthenameimplies,prototypesthatare
developedforthemainpurposeofeducatingtheusersaboutthepossibilitiesandextractingrequirementsfromtheusersbasedupontheirneeds
� Evolutionaryprototypesarebuiltfortheseeducationalandrequirementsdevelopmentpurposesaswell,butwiththeideathattheprototypewilleventuallybeturnedintoaworkingversionofthesystem
� Theevolutionaryprototypeinitiallywillonlyaddressaportionofthetotalfunctionalityofthesystem,andthatnewfunctionalitywillbeaddedonasthedevelopmentandoperationalphasesevolvetogether.
30
![Page 31: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/31.jpg)
UnderstandTheUsersWhenPrototyping� Therearemanywaystoobtaintheviewpointsofthestakeholders� These“elicitation”sessionscanbe
� Interviewswithoneorafewstakeholders� Facilitatedgroupsessions� Observationsofstakeholderperformanceonthecurrentsystemor
withprototypesofthenewsystem� Questionnaires
� Questionnairesarethelastresortwhennootherapproachisavailablesincequestionnairesproducelotsofrandomresponsesfromstakeholdersthatweretoobusyortooconfusedtodobetter
� Valuableinformationisusuallyachievedonlythroughhumaninteractions(JADSessions)� Individualinterviewsarebestatsolicitinginformationfromquiet
peoplewhomightbesilentduringgroupsessions� Facilitatedmeetingsarebestusedtosurfacedisagreementsandtryto
findcommongroundorreasonsforthedifferencesofopinionthattracebacktocontextandexternalsysteminteractions
� Observationsarebestforstressfulperiodsduringwhichpeopledothingsthattheymaynotconsciouslyrecallduringdiscussions
31
![Page 32: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/32.jpg)
UsabilityTesting� Usabilitytestingisobtainingsamplesofusersandelicitingthereactionsof
theseusersabouttheirneedsanddesiresastheyinteractwithprototypes� Theprototypescanbeascrudeaswrittensamplesofscreeninterfacesoras
sophisticatedasworkingmodulesofthesystem� Usabilityisadisciplineassociatedwithhuman–computerinteractionthat
becameverysophisticatedinthe1980sand1990s� Theperformanceelementsofusabilityareeaseoflearning(learnability),ease
ofuse(efficiency),easeofremembering(memorability),errorrate,andsubjectivelypleasing(satisfaction).� Eachofthesemetricshastobemeasuredinthecontextofspecifictypesof
usersandspecifictasks� Thetaskscomefromthescenariosintheoperationalconcept� Fortheerrorrateelement,categorizingerrorsintocategoriessuchasminor,
major,andcatastrophicisimportant� Caremustbetakentoseparaterandomerrorsfromthosecausedbythesystem
� Userscanbecategorizedalongthreedimensions:domainknowledge,computerexperience,andsystemuseexperience� Segmentsofusersalongthesethreedimensionsshouldbedevelopedfor
testingpurposes� Whenasampleofusersisdevelopedfortheusabilitytesting,thepopulationof
actualsystemusersmustbeconsidered,notthepopulationofpeopleinsociety.
32
![Page 33: Systems Engineering Spring 2018 Howard Rosenthal](https://reader031.fdocuments.net/reader031/viewer/2022020707/61fe3070dea3062de93d6fd9/html5/thumbnails/33.jpg)
MetricsforMeasuringUsabilityElements
Usability Element Metric
Learnability • Time to master a defined efficiency level, e.g., 50 words per minute • Time to master a defined skill, e.g., cut and paste
Efficiency • Time for a frequent user to complete a defined task • Rate of producing a defined set of products for a frequent user
Memorability • Time for a casual user to complete a defined task • Time for a casual user to achieve previously achieved rate of
production
Error Rate • Number of errors of a specific type in a given period for a given task
Satisfaction • Stress level associated with use • Fun level associated with use
33