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

� Characteristicsofsoundrequirements� Writinggoodrequirements

�  PleasereviewLesson2Pages39-49� CreatingtheOperationalConcept� Reviewexternalinterfaces� ReviewObjectivesHierarchy� ReviewPrototypingfromtheviewpointofusability

3

4

Introduction

� Thereareanumberofcontradictorydefinitionsinthebookwithrespecttorequirements�  Forthepurposeofthefollowingdiscussionwewillbereferringtobothstakeholderrequirementsandsystemrequirements,unlessotherwisenoted

�  Rememberthatthereshouldbefewerstakeholderrequirementsandmorederivedrequirementsthatwilleventuallyleadtodesignspecifications

5

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

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

8

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

10

ToWriteGoodRequirementsYouMustKnowHowToTalkToStakeholders

�  StartwithUsageScenarios(UseCases)� Asktoobservethemduring“stressful”periods� Givethemdraftstomodify� Givethemchoices(eyedoctor)� Workwiththemingroups

�  Theyhitchhikeoffeachother’sideas� Wearepoorfiltersoftheirconversations

� ThesestakeholderrequirementsaredevelopedinearlyJADsessions

11

WhentoStopSeekingRequirements

�  Aslateaspossible�  Requirementsevolveovertimeastheworldchanges�  Emergentrequirementsarenew,undiscovered,oftencritical

�  StandishGroup(1996)�  Requirementrelateddifficultieswereresponsiblefor34to44

percentofprojectfailures�  $81Bin1995and$100Bin1996werespentoncancelledITproducts

SomeExamplesOfGoodRequirements�  Thedevelopmentsystemshallreceiveinputsfromstakeholders.(Inputrequirement)

�  Themanufacturingsystemshallhaveascrappagerateofx%.(Outputrequirement)

�  Thedeploymentsystemshallacceptboxesofxft3.(Inputrequirement)

�  Thetrainingsystemshallcompletetraininginxhours.(Outputrequirement)

�  Theoperationalsystemshallhaveanoperationallifeofxyears.(Systemwideschedulerequirement).

�  Therefinementsystemshallacceptnewtechnologyforthecentralprocessingunit.(Inputrequirement)

�  Theretirementsystemshallcostlessthan$x.(Systemwidecostrequirement)

12

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

14

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

ConceptualDesign(1)�  Conceptualdesignidentifiesalternateconceptsandperformsthedecision

analysistoselectapreferredconceptfordevelopment.�  Thealternatives,relativelyfewinnumber,spantherangeofkeydrivers

withintheprojectedtechnologycapabilitiesbeginningwithandcontinuingthroughtheoperationallifeofthesystem

�  Forexample,minimumtimeorminimumenergytocompleteamission�  Aswediscussedpreviouslykeysystemsengineeringconceptsidentifies

constructsequallyapplicabletoconceptualdesignastodevelopment�  Operationalconcept�  Externalsystemsdiagram�  Objectiveshierarchy�  Requirements�  Function�  Items�  Components�  Interfaces�  Verification�  Validation�  Acceptance

16

ConceptualDesign(2)�  Conceptualdesignrequiresalevelofabstractionandfidelityforeach

ofthealternativesmuchlessthanthatforthedevelopmentoftheselectedconcept

�  DecisionAnalysisforDesignTradesisequallyapplicableforconceptualtrades,havinganobjectiveshierarchyforeachalternateconceptthatembodiesstakeholder(risk/reward)preferencesforvaluesmeasuresandweights.

�  Similarly,eachalternateconcepthasafunctional,physical,andallocatedarchitecturethatcanbeverified(usuallybyanalysisandsimulation)andvalidated

�  Thereareseveralpossibleoutcomesregardingacceptanceoftheoperationalconcept�  Oneormorealternativesareselectedfordevelopment�  Analternativeisselectedsubjecttomodification�  Thedecisiontogothroughafurtherconceptualdesignwith

additionalalternativesorhybridalternativescombiningaspectsofexistingalternatives

�  Adecisionthatnoalternativeisselectedanddevelopmentdoesnotproceed

17

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

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

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

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

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

A-0OperationalViewOfProvideElevatorServices

23

ElevatorA0Chart

24

A1DiagramForAcceptPassengerRequestsandProvideFeedback

25

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

TheObjectivesHierarchyDefinesThePerformanceSpaceforDesignSolution

•  Objective:Keyperformanceparameter•  Minimumacceptablethreshold

•  Levelbelowwhichentiresystemisunacceptable

•  Oftendefinedtootightly,inisolationofremainingsystemcapabilities

•  Desiredperformancelevel•  Oftenboundedbytechnologyconstraints

•  Boundedbysatiationofstakeholders

•  Hierarchyintegratesallobjectives

27

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

29

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

UnderstandTheUsersWhenPrototyping�  Therearemanywaystoobtaintheviewpointsofthestakeholders�  These“elicitation”sessionscanbe

�  Interviewswithoneorafewstakeholders�  Facilitatedgroupsessions�  Observationsofstakeholderperformanceonthecurrentsystemor

withprototypesofthenewsystem�  Questionnaires

�  Questionnairesarethelastresortwhennootherapproachisavailablesincequestionnairesproducelotsofrandomresponsesfromstakeholdersthatweretoobusyortooconfusedtodobetter

�  Valuableinformationisusuallyachievedonlythroughhumaninteractions(JADSessions)�  Individualinterviewsarebestatsolicitinginformationfromquiet

peoplewhomightbesilentduringgroupsessions�  Facilitatedmeetingsarebestusedtosurfacedisagreementsandtryto

findcommongroundorreasonsforthedifferencesofopinionthattracebacktocontextandexternalsysteminteractions

�  Observationsarebestforstressfulperiodsduringwhichpeopledothingsthattheymaynotconsciouslyrecallduringdiscussions

31

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

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