systems engineering csc 595 495 spring 2018 howard rosenthal · 2018. 2. 14. · se process,...

SystemsEngineeringCSC595_495Spring2018

HowardRosenthal

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-1118442265

LessonGoals

� Understandsystemsengineeringprocessesincludingthedesignandintegrationprocess

� DefinetheSIMILARprocess� Understandsomeofthemodelingapproachesinsystemsengineering

� Understandwhatasystemsarchitectureis� Understandwhatgoodrequirementsare,howtheyshapethesystem

� Understandgoodrequirementwriting� UnderstandtheCycleModel

WhatIsSystemsEngineering�  AsdefinedbyINCOSE(InternationalCouncilOnSystems

Engineering)�  “SystemsEngineeringisaninterdisciplinaryapproachandmeansto

enabletherealizationofsuccessfulsystems.Itfocusesondefiningcustomerneedsandrequiredfunctionalityearlyinthedevelopmentcycle,documentingrequirements,thenproceedingwithdesignsynthesisandsystemvalidationwhileconsideringthecompleteproblem.“

�  SystemsEngineeringisanengineeringdisciplinewhoseresponsibilityiscreatingandexecutinganinterdisciplinaryprocesstoensurethatthecustomerandstakeholder'sneedsaresatisfiedinahighquality,trustworthy,costefficientandschedulecompliantmannerthroughoutasystem'sentirelifecycle.

�  Thisprocessisusuallycomprisedofthefollowingseventasks:Statetheproblem,Investigatealternatives,Modelthesystem,Integrate,Launchthesystem,Assessperformance,andRe-evaluate–TheSimilarProcess

TheSIMILARProcess(1)

Ramos et al.: Revisiting the SIMILAR Process to Engineer the Contemporary Systems 330 J Syst Sci Syst Eng

Engineering Process Model, and the SIMILAR

Process are perhaps the most referred models in

the field (Bahill & Gissing 1998, Martin 2000;

Buede et al. 2002, INCOSE 2007a). It is also

common to found some variants from the DoD

and the NASA.

With more or less details, these roadmap

models share the obvious relation with the

lifecycle stages, and a series of iterative

high-level activities, namely: (i) to know what

the customers want and to define the systems

objectives; (ii) to define and manage system

requirements and to establish the functionality;

(iii) to identify and minimize risk conducting

trade studies as a basis for informed decision

making; (iv) to evolve design and operation

concepts; (v) to plan and integrate the work; (vi)

to enhance communication and system

understanding; and (vii) to verify that the system

meets customers’ needs.

The international standardize version of the

SE process, established at the ISO/IEC 15288,

outlines the areas of concern for SE but does not

detail the process to do the work, giving some

flexibility to pick the right processes for a given

situation but suffering, from our perspective, of

some lack of “glue”. Being a simpler, intuitive,

integrated, and guided model, more closely

related to human thinking (Bahill & Gissing

1998), and gathering the consensus of a

representative group of senior system engineers,

the SIMILAR process (Figure 2) constitutes our

preferred process approach. Nevertheless, and

for the reasons previously mentioned, it is quite

important to straighten out worldwide norms and

to adopt international SE process standards.

The SIMILAR Process is an abstraction

which reflects a logically consistent and

effective means of planning and problem solving.

The acronym stands for State the problem,

Investigate alternatives, Model the system,

Integrate, Launch the system, Assess

performance, and Re-evaluate. As their authors

state, this process is quite “universal” and a

considerable number of well known processes

from diverse fields can be mapped to the

SIMILAR process. The authors also remind that

the linear appearance of the model does not

represent a sequential procedure. The functions

are performed in a parallel and iterative manner.

The Figure 3 depicts the ISO/IEC 15288 SE

processes mapped to the elected SIMILAR

process, as well as the main lifecycle stages

defined at the international standard, and a series

of several processes and factors that are traversal

to the entire lifecycle and that can be

accommodated into three major categories, as

proposed by Martin (2000): Project

Figure 2 SIMILAR process model (source: Bahill & Gissing 1998)

Thisclasswillfocusonthefirstthreestepswithanemphasisonmodeling

TheSIMILARProcess(2)�  StateTheProblem

�  Theproblemstatementstartswithadescriptionofthetop-levelfunctionsthatthesystemmustperform:thismightbeintheformofamissionstatement,aconceptofoperationsoradescriptionofthedeficiencythatmustbeameliorated.

�  Mostmandatoryandpreferencerequirementsshouldbetraceabletothisproblemstatement.

�  InvestigateAlternatives�  Alternativedesignsarecreatedandareevaluatedbasedonperformance,

schedule,costandriskfiguresofmerit.�  Nodesignislikelytobebestonallfiguresofmerit,somulti-criteriadecision-

aidingtechniquesareusedtorevealthepreferredalternatives–thesearetrade-offstudies

�  Thisanalysisshouldberedonewhenevermoredataareavailable.�  Forexample,figuresofmeritshouldbecomputedinitiallybasedonestimatesbythe

designengineers.�  Then,concurrently,modelsshouldbeconstructedandevaluated;simulationdata

shouldbederived;andprototypesshouldbebuiltandmeasured.�  Finally,testsshouldberunontherealsystem.

�  Alternativesshouldbejudgedforcomplianceofcapabilityagainstrequirements.Forthedesignofcomplexsystems,alternativedesignsreduceprojectrisk.Investigatinginnovativealternativeshelpsclarifytheproblemstatement.

TheSIMILARProcess(3)�  ModelBasedSystemsEngineering(MBSE)

�  Theprocessofdesigningasystemthroughanintegratedsetofmodels�  Therearetoolsthathelpintegratemultiplemodelstogether�  IBM’sRationalRose,ViTech’sCORE,andothertoolsareusedtomodel

systemswithanintegratedtoolset�  ModelTheSystem

�  Modelswillbedevelopedformostalternativedesigns.�  Themodelforthepreferredalternativewillbeexpandedandusedtohelp

managethesystemthroughoutitsentirelifecycle.�  Manytypesofsystemmodelsareused,suchasphysicalanalogs,analytic

equations,statemachines,blockdiagrams,functionalflowdiagrams,object-orientedmodels,computersimulationsandmentalmodels.

�  SystemsEngineeringisresponsibleforcreatingaproductandalsoaprocessforproducingit.�  Modelsshouldbeconstructedforboththeproductandtheprocess.�  Processmodelsallowusto

�  Studyschedulingchanges,createdynamicPERTchartsandperformsensitivityanalysestoshowtheeffectsofdelayingoracceleratingcertainsubprojects.

�  Runningtheprocessmodelsrevealsbottlenecksandfragmentedactivities,reducescostandexposesduplicationofeffort.

�  Productmodelshelpexplainthesystem.�  Thesemodelsarealsousedintradeoffstudiesandriskmanagement.

TheSIMILARProcess(4)�  TypesofModels

�  ThiscoursewillplaceanemphasisonlearningthemodelingtoolsassociatedwithSystemsEngineering,withanemphasisoninformationsystems.ItwillfocusheavilyonteachingstudentsasetofStructuredSystemsAnalysisandDesignmodelingtoolsandtoalesserextenttheSystemModelingLanguage(SysML).

�  InadditiontotheSysMLmodelsthefollowingadditionalmodeling/diagrammingtoolswillbetaught.�  ArchitectureDiagramsincludingadiscussionofalternate

topologies�  N2Charts–Asamechanismtodefineinternalandexternal

interfaces�  IDEF0diagrams�  StructureCharts�  StateTransitionDiagrams�  DataFlowDiagrams�  Simulations–Ratherthanlearninganewlanguagewewilldevelop

somesimplesystemsimulationsinJava.

TheSIMILARProcess(5)�  IntegrateTheSystem

�  Showthedesignandarchitecturefortheintegratedsystem�  LaunchTheSystem

�  Launchingthesystemmeansrunningthesystemandproducingoutputs.�  Inamanufacturingenvironmentthismightmeanbuyingcommercialoffthe

shelfhardwareorsoftware,oritmightmeanactuallymakingthings.�  Launchingthesystemmeansallowingthesystemdowhatitwasintendedto

do.Thisalsoincludesthesystemengineeringofdeployingmulti-site,multi-culturalsystems.

�  Thisisthephasewherethepreferredalternativeisdesignedindetail;thepartsarebuiltorbought(COTS),thepartsareintegratedandtestedatvariouslevelsleadingtothecertifiedproduct.

�  Inparallel,theprocessesnecessaryforthisaredeveloped–wherenecessary-andappliedsothattheproductcanbeproduced.

�  Indesigningandproducingtheproduct,dueconsiderationisgiventoitsinterfaceswithoperators(humans,whowillneedtobetrained)andothersystemswithwhichtheproductwillinterface.Insomeinstances,thiswillcauseinterfacedsystemstoco-evolve”.

�  Theprocessofdesigningandproducingthesystemisiterativeasnewknowledgedevelopedalongthewaycancauseare-considerationandmodificationofearliersteps.

TheSIMILARProcess(6)� AssessTheSystem

� Technicalperformancemeasuresandmetricsareallusedtoassessperformance.

� Technicalperformancemeasuresareusedtomitigateriskduringdesignandmanufacturing.

� Metrics(includingcustomersatisfactioncomments,productivity,numberofproblemreports,orwhateveryoufeeliscriticaltoyourbusiness)areusedtohelpmanageacompany'sprocesses.

�  Ifyoucannotmeasureit,youcannotcontrolit.� Eachsubsystemisallocatedaportionofthetotalbudgetandtheprojectmanagerisallocatedareserve.Theseresourcebudgetsaremanagedthroughoutthesystemlifecycle.

FiveMajorFunctionsOfSystemsEngineeringDesign

Develop Functional

Architecture

Design Physical

Architecture

Develop Allocated

Architecture

Obtain Approval & Document

Define the Design

Problem

AViewOfTheDesignProcess�  Thedesignprocessdevelopsdifferentviewwhichmaybeturnedinto

specificationsatvariouspointsinthedesignprocess�  Eachspecificationisacollectionofmorerefinedindividual

requirements

Stakeholders’ Need

System Design

Segment Design

Element Design

Component Design

Stakeholders’ Requirement

System Allocated

Architecture

Segment Specs

Segment Allocated

Architectures

Element Specs

Element Allocated

Architectures

Component Specs

Component Allocated

Architectures CI

ScopeofSystemsEngineering

DetailedFunctionsofSystemsEngineeringDesign

Higher Level Requirements & Constraints from

Approved Baseline

Define the problem, the

system/segment/CI Boundary, & the

objectives

Develop the Op’l Concept

for the Sys,Seg,CI under analysis

Define the required

behavior in a functional interaction

diagram

Define the required

functional performance

by quantitative analysis

Allocate requirements to functions

Define candidate physical solutions

Evaluate candidate physical

solutions & select

best based upon objectives & requirements

Allocate functions to Seg/CIs

Develop interfaces between Seg/CIs

Plan test & integration of Seg/CIs

Obtain approval

of boundary, objectives,

concept of ops, requirements,

physical solution, & test plan

Document Seg/CI design

as approved baseline for next

lowest level

DefinetheDesignProblem

DevelopFunctionalArchitectureDevelopPhysical

Architecture

DevelopAllocatedArchitecture

ObtainApproval&Document

JointApplicationDevelopment–EnsuringYouBuildWhatTheyReallyWant

�  JAD(JointApplicationDevelopment)isamethodologythatinvolvestheclientorenduserinthedesignanddevelopmentofanapplication,throughasuccessionofcollaborativeworkshopscalledJADsessions.

� Thepurposeistogetearlieracceptanceoftheactualproductbeingdeveloped� Waitinguntiltheproductisdevelopedtodetermineifitisacceptablehasledtonumerousfailuresinthepast

�  Youneedtomeetthebusinessanduserneeds

AViewOfTheJADParticipants

SysMLDiagrams

SysML Diagram Taxonomy

SysML Diagram

StructureDiagram

BehaviorDiagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

ParametricDiagram

RequirementDiagram

Modified from UML 2

New diagram type

Package Diagram

Same as UML 2

SysMLvs.UML�  SysMLDiagramsareusedbysystemsengineerstomodelthesystematahigherlevelofabstraction�  UMLdiagramsareusedtodesignandimplementthesystemandisusedinmanycasestogenerate

code�  ModerntoolsallowyoutoimportSysMLdiagramsintotheUMLmodel�  BothSysMLandUMLaremanagedbytheObjectManagementGroup

Structure Diagrams Behavior

Diagrams Interaction Diagrams Requirement

(new) Class – renamed to be Block Definition Internal Block Component Composite structure Deployment Object Package Parametric Design

Activity (modified)

State Machine Use case

Collaboration - Communication

Interaction overview Sequence diagram Timing

Requirement (new)

ObjectProcessingModel�  ObjectProcessMethodology(OPM)ISO/PAS19450isaconceptualmodelinglanguage

andmethodologyforcapturingknowledgeanddesigningsystems.�  Basedonaminimaluniversalontologyofstatefulobjectsandprocessesthattransform

them,OPMcanbeusedtoformallyspecifythefunction,structure,andbehaviorofartificialandnaturalsystemsinalargevarietyofdomains.

�  AnOPMmodelrepresentsthesystemunderdesignorstudyinbothgraphicsandtextforimprovedrepresentation,understanding,communication,andlearning.

�  InOPM,anobjectisathingthatexists,ormightexist,physicallyorabstractlyasinformation.�  Objectsarestateful—theymayhavestates,suchthatateachpointintime,theobjectis

atoneofitsstatesorintransitionbetweenstates.�  Aprocessisathingthattransformsanobjectbycreatingorconsumingit,orbychanging

itsstate.�  OPMisbimodal;

�  Itisexpressedbothvisually/graphicallyinObject-ProcessDiagrams(OPD)�  Itisexpressedverbally/textuallyinObject-ProcessLanguage(OPL),asetof

automatically-generatedsentencesinasubsetofEnglish.�  AsoftwarepackagecalledOPCAT,forgeneratingOPDandOPL,isfreelyavailable.

�  Reference:Dori,Dov,ModelBasedSystemsEngineeringWithOPMandSysML,Springer,2016

OPMvs.SysML

OPM SysML/UML

System’s structure and behavior are specified side-by- side, enabling one to see the whole picture in a single view

System’s structure and behavior are specified at different and separate views

Process is an entity that uniformly represents patterns of behavior

Behavior of the system can be spread across five diagram types

No need for mental transformations and integration across different views

Need to validate consistency among the various views

25 Symbols - Overall simpler to learn and use 150 symbols

In an experiment took 2 weeks to learn In an experiment took 5 weeks to learn

OPM better for understanding the dynamic aspects of the system and the relationships between modules

SysML Block Structure diagrams are better for those looking at the structure

While an ISO standard not yet widely used With backing of the OMG has become more widely used, especially for modeling software systems

InthisclasswewillfirstlearnsomeoftheclassicmodelingtechniquesWewillthenlearnsomebasicSysMLstructuresOPMiseasiertolearn,butSysMLismorewidelyused

TheConceptOfArchitectures�  Architecturesareviewpointsonasystem

�  ConceptofOperations(CONOPS)�  Adocumentdescribingthecharacteristicsofaproposedsystemfromthe

viewpointofanindividualwhowillusethatsystem.�  Itisusedtocommunicatethequantitativeandqualitativesystemcharacteristics

toallstakeholders.�  Functional(orLogical)Architecture

�  Definesthesystem’sfunctionsandthedatathatflowsbetweenthefunctions�  PhysicalArchitecture

�  Identifiesandpartitionstheresourcesrequiredtoperformthelogicalfunctions�  AllocatedArchitecture

�  Mapsfromfunctionstoresources�  InterfaceArchitecture

�  Describesboththeinternalandexternalinterfaces�  Thepreviouslydescribedclassical,SysMLandOPMmodels,aswellas

writtendescriptionscanbeusedtodefinearchitectures�  Ifasingletoolorintegratedmodelisusedconsistencywillbehigher

anderrorsfewer

ArchitecturalViewpoints

Operational Concept

Functional Architecture

Physical Architecture

Allocated Architecture

Interface Architecture

ExampleofAPhysicalArchitecture

F-22 Weapon System

Vehicle Training Support

Avionics Systems

Utilities & Subsystems

Cockpit Systems

Vehicle Management

System

Electronic Warfare

Navigation, Identification

Processing

Controls &

Displays

Stores Management

Inertial Reference

System Radar

NineFundamentalPrinciplesofSystemsArchitectures(1)

�  Theobjectsoftherealityaremodeledassystems�  Thatis,thinkofasystemaboxperformingafunctionanddefinedbyitsperimeter,inputs,outputsandaninternalstate

�  Amobilephonesystem�  Takesininputavoice&keystrokesandoutputsvoices&displays.

�  Itcanbeon,offorinstandby.�  Overall,thephoneallowstomakephonecalls(amongotherfunctions).

* teams, tools, other resources and their organization following strategies & methods

>> Fundamental Principles

Whatever the type of system and the acception considered (model, method or discipline),Systems Architecture is based on 9 fundamental principles :

"Thinking with a systemic approach"

1. the objects of the reality are modelled as systems (i.e. a box performing afunction and defined by its perimeter, inputs, outputs and an internal state)Ex: a mobile phone is a system which takes in input a voice & keystrokes and outputs voices &displays. Moreover, it can be on, off or in standby. Overall, the phone allows to make phone calls(among other functions).

2. a system can be broken down into a set of smaller subsystems, which is lessthan the whole system (because of emergence)Ex: a mobile phone is in fact a screen, a keyboard, a body, a microphone, a speaker, andelectronics. But the phone is the integration of all those elements and cannot be understoodcompletely from this set of elements.

3. a system must be considered in interaction with other systems, i.e. itsenvironmentEx: a mobile phone is in interaction with users, relays (to transmit the signal), reparators (whenbroken), the ground (when falling), etc. All these systems constitue its environment and shall beconsidered during its design.

� Asystemcanbebrokendownintoasetofsmallersubsystems

� Amobilephonesystem�  Itisinfactascreen,akeyboard,abody,amicrophone,aspeaker,andelectronics.

�  Butthephoneistheintegrationofallthoseelementsandcannotbeunderstoodcompletelyfromthissetofelements.

� Asystemmustbeconsideredininteractionwithothersystems,i.e.itsenvironment

� Amobilephonesystem�  Itisininteractionwithusers,relays(totransmitthesignal),repairpersonnel(whenbroken),etc.

�  Allthesesystemsconstituteitsenvironmentandshallbeconsideredduringitsdesign.

� Asystemmustbeconsideredthroughitswholelifecycle

� Amobilephonesystem� Willbedesigned,prototyped,tested,approved,manufactured,distributed,sold,used,repaired,andfinallyrecycled.

4. a system must be considered through its whole lifecycleEx: a mobile phone will be designed, prototyped, tested, approved, manufactured, distributed,selled, used, repaired, and finally recycled. All these steps are important (and not only the momentwhen it is used).

"Reasoning according to an architecture paradigm"

5. a system can be linked to another through an interface, which will model theproperties of the linkEx: when phoning, our ear is in direct contact with the phone, and there is therefore a link betweenthe two systems (the ear and the phone). However, there is a hidden interface : the air! Theproperties of the air may influence the link between the ear and the phone (imagine for example ifthere is a lot of noise).

6. a system can be considered at various abstraction levels, allowing to consideronly relevant properties and behaviorsEx: do you consider your phone as a device to make phonecalls (and other functions of modernphones), a set of material and electronics components manufactured together, or a huge set ofatoms ? All these visions are realistic, but they are just at different abstraction levels, whoserelevancy will depend on the context.

7. a system can be viewed according to several layers (usually three: its sense, itsfunctions, and its composition)Ex: a phone is an object whose sense is to accomplish several missions for its environment :making phone calls, being a fashionable object, offering various features of personal digitalassistants, etc. But it is also a set of functions organized to accomplish these missions (displayingon the screen, transmitting signal, delivering power supply, looking for user inputs, making noise ifnecessary, etc). And finally, all these functions are implemented through physical componentsorganized to perform these functions.

NineFundamentalPrinciplesofSystemsArchitectures(5)�  Asystemcanbelinkedtoanotherthroughaninterface,whichwill

modelthepropertiesofthelink�  Amobilephonesystem

�  Whenphoning,ourearisindirectcontactwiththephone,andthereisthereforealinkbetweenthetwosystems(theearandthephone).

�  Thereisahiddeninterface:theair!�  Therearetheotherobviousinterfacestothecelltower,etc..�  Interfaceidentificationandspecificationisoneofthemost

importantactivitiesinsystemsengineering

NineFundamentalPrinciplesofSystemsArchitectures(6)�  Asystemcanbeconsideredatvariousabstractionlevels,allowingtoconsider

onlyrelevantpropertiesandbehaviors�  Isyourmobilephonesystem

�  Adevicetomakephonecalls(andotherfunctionsofmodernphones)?�  Asetofmaterialandelectronicscomponentsmanufacturedtogether�  Anelementofyourcommunicationsmanagementplan?�  AWi-Fibridge?�  Ahugesetofatoms?(Soundssillybutyoumightlookartitthiswayifyou

wereteleportingit

NineFundamentalPrinciplesofSystemsArchitectures(7)�  Asystemcanbeviewedaccordingtoseverallayers

�  Itssense�  Itsfunctions�  Itscomposition

�  Amobilephonesystem�  Itisanobjectwhosesenseistoaccomplishseveralmissionsforitsenvironment:making

phonecalls,beingafashionableobject,offeringvariousfeaturesofpersonaldigitalassistants,etc.

�  Itisalsoasetoffunctionsorganizedtoaccomplishthesemissions:displayingonthescreen,transmittingsignal,deliveringpowersupply,lookingforuserinputs,makingnoiseifnecessary,etc.

�  Allthesefunctionsareimplementedthroughphysicalcomponentsorganizedtoperformthesefunctions.

328. a system can be described through interrelated models with given semantics(properties, structure, states, behaviors, datas, etc)Ex: from the point of view of properties, the phone is a device expected to meet requirements like "aphone must resist to falls from a height of one meter". But a phone will also change state : when aphone is off and that the power button is pressed, the phone shall turn on. Function dynamics of thephone are also relevant: when receiving a call, the screen will display the name and the speakerwill buzz, but if the user presses no button the phone will stop after 30 secondes... This willtypically be described with diagrams in SysML (an evolution of UML).

9. a system can be described through different viewpoints corresponding tovarious actors concerned by the system.Ex: commercials, designers, engineers (in charge of software, electronics, acoustics, materials, etc)users, repairers... All these people will have different visions of the phone. When the designer willsee the phone as an easy-to-use object centered on the user, the engineer will see it as atechnological device which has to be efficient and robust. A commercial may rather see it as aproduct which must meet clients' needs and market trends to be sold. All these visions are importantand define the system in multiple and complementary ways.

>> Socio-Cognitive Aspects

Systems Architecture involves multiple views (sometimes partial or conflictual) of the samesystem by multiple actors. These views can be understood as "projections" of the system inthe spaces of those different actors:

this is the set of all those views (themselves involving several interrelated models at

NineFundamentalPrinciplesofSystemsArchitectures(8)�  Asystemcanbedescribedthroughinterrelatedmodelswithgivensemantics

�  Properties�  Structure�  States�  Behaviors�  Data,etc.

�  Inamobilephonesystem�  Fromthepointofviewofproperties,thephoneisadeviceexpectedtomeet

requirementslike"aphonemusthaveameanbatterylifewithoutrechargeofatleast11hours".

�  Aphonewillalsochangestate:whenaphoneisoffandthatthepowerbuttonispressed,thephoneshallturnon.

�  Functiondynamicsofthephonearealsorelevant:whenreceivingacall,thescreenwilldisplaythenameandthespeakerwillbuzz,butiftheuserpressesnobuttonthephonewillstopafter30seconds.-Thiswilltypicallybedescribedwitheitherclassic,SysMLorOPMmodel).

NineFundamentalPrinciplesofSystemsArchitectures(9)�  Asystemcanbedescribedthroughdifferentviewpoints

correspondingtovariousactorsconcernedbythesystem.�  Inamobilephonesystem

�  Differentpersonnel(i.e.designers,engineersinchargeofsoftware,electronics,acoustics,materials,etc.)users,businessexecutives,salesperson,repairerswillhavedifferentvisionsofthephone.

�  Whenthedesignerwillseethephoneasaneasy-to-useobjectcenteredontheuser,theengineerwillseeitasatechnologicaldevicewhichhastobeefficientandrobust.Abusinesspersonmayratherseeitasaproductwhichmustmeetclients'needsandmarkettrendstobesold.

�  Allthesevisionsareimportantanddefinethesysteminmultipleandcomplementaryways.

TheDoDArchitecturalFramework(DoDAF)�  DoDAFprovidesanoverallframeworkforexpressingarchitecturesfrommultipleperspectivesorviewpoints

�  Theoriginalversionhadthreeview,operational,systemsandtechnical,whichhavenowbeenexpandedtosevenviewpoints

�  Eachviewpointhasaparticularpurpose,andusuallypresentsoneorcombinationsofthefollowing:�  Broadsummaryinformationaboutthewholeenterprise(e.g.,high-

leveloperationalconcepts).�  Narrowlyfocusedinformationforaspecialistpurpose(e.g.,system

interfacedefinitions).�  Informationabouthowaspectsoftheenterpriseareconnected

(e.g.,howbusinessoroperationalactivitiesaresupportedbyasystem,orhowprogrammanagementbringstogetherthedifferentaspectsofnetworkenabledcapability).

TheSevenDoDAFViewpoints�  DoDAForganizestheDoDAF-describedModelsintothefollowingviewpoints:

�  TheAllViewpointdescribestheoverarchingaspectsofarchitecturecontextthatrelatetoallviewpoints.

�  TheCapabilityViewpointarticulatesthecapabilityrequirements,thedeliverytiming,andthedeployedcapability.

�  TheDataandInformationViewpointarticulatesthedatarelationshipsandalignmentstructuresinthearchitecturecontentforthecapabilityandoperationalrequirements,systemengineeringprocesses,andsystemsandservices.

�  TheOperationalViewpointincludestheoperationalscenarios,activities,andrequirementsthatsupportcapabilities.

�  TheProjectViewpointdescribestherelationshipsbetweenoperationalandcapabilityrequirementsandthevariousprojectsbeingimplemented.TheProjectViewpointalsodetailsdependenciesamongcapabilityandoperationalrequirements,systemengineeringprocesses,systemsdesign,andservicesdesignwithintheDefenseAcquisitionSystemprocess.TheServicesViewpointisthedesignforsolutionsarticulatingthePerformers,Activities,Services,andtheirExchanges,providingfororsupportingoperationalandcapabilityfunctions.

�  TheStandardsViewpointarticulatestheapplicableoperational,business,technical,andindustrypolicies,standards,guidance,constraints,andforecaststhatapplytocapabilityandoperationalrequirements,systemengineeringprocesses,andsystemsandservices.

�  TheSystemsViewpoint,forLegacysupport,isthedesignforsolutionsarticulatingthesystems,theircomposition,interconnectivity,andcontextprovidingfororsupportingoperationalandcapabilityfunctions. 36

APictorialViewofDoDAF

MappingBetweenDoDAF1.5and2.0

DoDAF Viewpoints(click to enlarge)

DoDAF V2.0 is a more focused approach to supporting decision-makers than prior versions. In the past, decision-makers would look at DoDAF offerings and decide which were appropriate to their decision process. An example isthe JCIDS process architecture requirements inside the JCIDS documentation (ICD, CDD, CPD, etc.). Additionally,older version Architectural Description products were hard-coded in regard to content and how they were visualized.Many times, these design products were not understandable or useful to their intended audience. DoDAF V2.0,based on process owner input, has increased focus on architectural data, and a new approach for presentingarchitecture information has addressed the issues. The viewpoints categorize the models as follows:

As illustrated below, the original viewpoints (Operational Viewpoint, Systems and Services Viewpoint, TechnicalStandards Viewpoint, and the All Viewpoint) have had their Models reorganized to better address their purposes.The Services portion of the older Systems and Services Viewpoint is now a Services Viewpoint that addressesin more detail our net-centric or services-oriented implementations.

DoDAF V1.5 Evolution to DoDAF V2.0

All the models of data (conceptual, logical, or physical) have been placed into the Data and InformationViewpoint rather than spread throughout the Operational Viewpoint Viewpoint and Systems and ServicesViewpoints.The Systems Viewpoint accommodates the legacy system descriptions.The new Standards Viewpoint can now describe business, commercial, and doctrinal standards, as well as thetechnical standards applicable to our solutions, which may include systems and services.The Operational Viewpoint now can describe rules and constraints for any function (business, intelligence,warfighting, etc.) rather that just those derived from data relationships.Due to the emphasis within the Department on Capability Portfolio Management and feedback from theAcquisition community, the Capability Viewpoint and Project Viewpoint have been added through a best-of-breed analysis of the MODAF and NAF constructs.

WhatAreRequirements(1)�  Requirementsforasystemaddresstheneedsandobjectivesofthe

stakeholders.�  Justasthereisahierarchyassociatedwiththephysicalcomponentsofthe

system,thereisahierarchyofrequirements.�  Alllowerlevelrequirementsarederivedfromandtraceabletohigherlevel

requirements�  Atthetopofthehierarchyaremissionrequirements,whichrelatetoneeds

associatedwithmissionsoractivitiesthatareimportanttooneormoregroupsofstakeholders.�  Thesemissionrequirementstypicallyinvolvetheinteractionofseveral

systems,oneormoreofwhichincludeindividualsorgroupsofpeopleandarethereforestatedinthecontextoftheoperationofthesysteminquestionwiththeseothersystems,calledthemeta-systemorsystemofsystems.

�  Missionrequirementsrepresentstakeholderpreferencesfortheincreasedabilitytoperformtheiractivitieswiththeintroductionofthesysteminquestionatalowercostandinafastertimethantheexistingcapability.

�  Stakeholders'requirementsarestatementsbythestakeholdersaboutthesystem'scapabilitiesthatdefinetheconstraintsandperformanceparameterswithinwhichthesystemistobedesigned.�  Systemsengineerstakethesehigh-level,stakeholders'requirementsandderive

aconsistentsetofmoredetailedengineeringstatementsofrequirementsasthedesignprogresses.

�  Requirementsaredividedintofunctionalandperformancerequirements.

WhatAreRequirements(2)�  Functionalrequirementsdescribewhatasystemdoes

�  Somearesimple,forexample,thesystemmustbepaintedwithaspecificshadeofgreen.

�  Othersaremorecomplex–i.e.identifyplanetsaroundotherstarswithadiameternogreaterthantwiceearth’s

�  Performancerequirements�  Definesadesireddirectionofperformanceassociatedwithanobjectiveofthestakeholdersforthesystem.

�  Foranyperformancerequirement,theremustalsobeaminimumacceptableperformanceconstraintorthresholdandadesigngoalassociatedwiththeindex;thisthresholddictatesthatnomatterhowwonderfuladesign'sperformanceisonotherobjectives,performancebelowthisthresholdonthisrequirementmakesthedesignunacceptable.

�  AllrequirementsarestatedwiththewordShall.May,can,shouldwill,etc.arenotdefinitive.

SomeTypicalRequirementsDocuments

Document Titles Document Contents Problem Situation or Mission Element Need Statement and Systems Engineering Management Plan (SEMP)

• Definition of stakeholders and their relationships • Stakeholders’ description of the problem and its context • Description of the current system • Description of major objectives in general terms • Definition of the systems engineering management

structure and support tools that will be responsible for developing the system

Stakeholders’ Need or Stakeholders’ Requirement (StkhldrsRD)

• Definition of the problem needing solution by the system (including the context and external systems with which the system must interact)

• Definition of the operational concept on which the system will be based

• Creation of the structure for defining requirements • Description of the requirements in the stakeholders’

language in great breadth but little depth • Trace of every requirement to a recorded statement or

opinion of the stakeholders • Description of trade-offs between performance

requirements, including cost and operational effectiveness

System Requirements (SysRD)

• Restatement of the operational concept on which the system will be based

• Definition of the external systems in engineering terms • Restatement of the operational requirements in

engineering language • Trace of every requirement to the previous document • Justification of engineering version of the requirements

in terms of analyses, expert opinions, stakeholder meetings

• Description of test plan for each requirement System Requirements Validation

• Documents analyses to show that the requirements in the SysRD are consistent, complete and correct, to the degree possible

• Demonstrates that there is at least one feasible solution to the design problem as defined in the SysRD

ATypicalRequirementsandProductHierarchy

DOD-STO-2167

I SYSTEM J

1SEGMENTI [ SEGMENT 21

TLCSC31

LL(XC LLCSC312 313

‘@ @

621UNIT NIT

limaLLCSC 673LLW ‘Nil ‘Ni3301

UNIT UNl uN! (JNI UNl UNIT

LH!lwlbNIT UNIT Nl NIT NIT UNIT

FIGURE3. CSClsample etatic structure.

WritingGoodRequirements(1)�  Everysystemsengineerwillberequiredatsomepoint(usuallymanytimes)intheircareertowritegoodclearrequirements

�  EditorialChecklistIseachrequirement�  Usingthecorrectterm?

�  Shall=requirementWill=factsordeclarationofpurpose

�  Should=goal�  Writteninthe“Who”shall“What”format,usingactiveratherthan

passivevoice?Examples:�  Thesystemshalloperateatapowerlevelof...�  Thesoftwareshallacquiredatafromthe...�  Thestructureshallwithstandloadsof...

�  Usingconsistentterminologytorefertotheproductanditslower-levelentities?

�  Grammaticallycorrect?�  Freeoftypos,misspellings,andpunctuationerrors?

WritingGoodRequirements(2)�  GoodnessChecklist-Iseachrequirement...

�  Clearandunderstandable?�  Canonlybeunderstoodoneway?�  Freefromindefinitepronouns(e.g.,this,these,it)?�  Expressingonlyonethoughtperrequirementstatement?�  Statedsimplyandconcisely?�  Statedpositivelyasopposedtonegatively(e.g.,“shallnot”)?�  Locatedinthepropersectionofthedocument?�  Definedatthecorrectlevel?�  Aretherequirementsclearandunambiguous?�  Cantherequirementbemisinterpreted?�  Freeofambiguities?�  Freeofunverifiableterms?i.e.:

�  “flexible”...“easy”...“sufficient”...“safe”...“adequate”...“user-friendly”...“useablewhenrequired”...“fast”...“small”...“large.”

WritingGoodRequirements(3)�  GoodnessChecklist(Continued)-Iseachrequirement...

�  Freeofimplementation?�  RequirementsshouldstateWHATisneeded,notHOWtoprovideit(i.e.,state

theproblemnotthesolution;ask,“Whydoyouneedtherequirement?”).�  Freeofdescriptionsofoperations?

�  Todistinguishbetweenoperationsandrequirementsaskthequestions:Doesthedeveloperhavecontroloverthis?Isthisaneedtheproductmustsatisfyoranactivityinvolvingtheproduct?Sentenceslike“Theoperatorshall...”arealmostalwaysoperationalstatements,notrequirements.

�  FreeofToBeDetermined(TBD)andToBeResolved(TBR),values?�  Enterthecurrentbestestimatewithinbrackets[value]intherequirementand

stateintherationalewhythevalueisstillanestimate.�  Completewithtolerancesforquantitativevalues?�  Accompaniedbyintelligiblerationale,includinganyassumptions?�  Traceabletorequirementsinthelevelaboveit?Ifit'satthetoplevel,

isittraceabletoscope?�  Identifiedwithaverificationmethod(s)(i.e.,test,demonstration,

analysis,orinspection)?�  Doesameansexisttomeasureitsaccomplishment?�  Canyoustatethecriteriarequiredforverification?Cancompliancebeverified?

�  Unique(asopposedtoredundant)?�  Consistentwithotherrequirements(asopposedtoconflicting)?

WritingGoodRequirements(4)�  Completeness

�  Arerequirementsstatedascompletelyaspossible?�  Haveallincompleterequirementsbeencapturedforlaterclarification

(i.e.performance)?�  Haveallassumptionsbeenexplicitlystated?�  Areanyrequirementsmissing?Checkfor:

�  Functional�  Performance–speed,reliability,quality�  Interface�  Environment(development,manufacturing,test,transport,storage,operations)�  Facility(manufacturing,test,storage,operations)�  Transportation(amongareasformanufacturing,assembling,deliverypoints,

within�  Storagefacilities,loading)�  Training�  Personnel�  Operability�  Safety�  Security�  Appearanceandphysicalcharacteristicsdesign

WritingGoodRequirements(5)�  Compliance

�  Areallrequirementsatthecorrectlevel(i.e.,system,segment,element,subsystem)atwhichyouareworking?

�  Arerequirementsspecifiedinanimplementation-freewaysoasnottoobscuretheoriginalrequirements(i.e.,dotherequirementsstate“what”andnot“how”)?

�  Arerequirementsspecifiedontheproduct,notonanoperator?Isthisarequirementthedeveloperhascontrolover,somethingtheproductmustdo,oraqualityitmusthave,ratherthananactivityinvolvingtheproduct?

�  Consistency�  Aretherequirementsstatedconsistentlywithoutcontradictingthemselvesorthe

requirementsofrelatedsystems?�  Istheterminologyconsistentwiththeuserandsponsor'sterminology?Isthe

terminologyconsistentlyusedthroughoutthedocument?Arethekeytermsincludedintheproject'sglossary?

�  Traceability�  Iseachrequirementneeded?Iseachrequirementnecessarytomeettheparent

requirement?Iseachrequirementtracedtoaparentrequirement?Isallocationtothenextlowerleveldocumented?

�  Correctness�  Iseachrequirementcorrect?�  Aretherequirementstechnicallyfeasible?

�  Functionality�  Arealldescribedfunctionsnecessary,andtogether,sufficienttomeetthesystemneeds,

goals,andobjectives?�  Aredifferentmodesofoperation(Day/night,maintenance,etc.laidout?

WritingGoodRequirements(6)�  Performance

�  Areallrequiredperformancespecificationsandmarginslisted(e.g.,timing,throughput,storagesize,latency,accuracy,andprecision)?

�  Iseachperformancerequirementrealistic?�  Arethetolerancesoverlytight?�  Arethetolerancesdefendableandcost-effective?

�  Ask,“Whatistheworstthingthatcouldhappenifthetolerancewasdoubledortripled?”�  Note:Sometimesthegovernmentcanbequiteinflexibleinthisarea.

�  Interfaces�  Areallexternalinterfacesclearlydefined?�  Areallinternalinterfacesclearlydefined?�  Areallinterfacesnecessary,sufficient,andconsistentwitheachother?

�  Maintainability�  Havetherequirementsforsystemmaintainabilitybeenspecifiedinameasurable,verifiablemanner?�  Arerequirementswrittentobeasweaklycoupledaspossiblesothatrippleeffectsfromchangesare

minimized?�  Reliability

�  Areclearlydefined,measurable,andverifiablereliabilityrequirementsspecified?�  Arethereerrordetection,reporting,handling,andrecoveryrequirements?�  Areundesiredevents(e.g.,singleeventupset,datalossorscrambling,operatorerror)consideredand

theirrequiredresponsesspecified?�  Haveassumptionsabouttheintendedsequenceoffunctionsbeenstated?�  Dotheserequirementsadequatelyaddressthesurvivabilityafterasoftwareorhardwarefaultofthe

systemfromthepointofviewofhardware,software,operationspersonnel,andprocedures?�  Verifiability/Testability

�  Canthesystembetested,demonstrated,inspected,oranalyzedtoshowthatitsatisfiesrequirements?�  Aretherequirementsstatedpreciselytofacilitatespecificationofsystemtestsuccesscriteriaand

requirements?

TheCycleModelDesignandIntegrationCycles�  Thecyclemodelstressesfivecyclesthatincludetheelementsofdesignandintegration

thathavealreadybeendiscussedaswellasthemanagementaspectsofsystemsengineering.

�  TheCoreorStakeholderSatisfactionCycle�  Beginswiththedeterminationoftheneedandendingwiththedeliveryofthesystemto

satisfythoseneeds.�  Thedevelopmentfunctionsonthisfirstcycleincluderequirementsdevelopmentand

creationofthesystemdesign,followedbymanufacturingandproductdelivery.�  TheVerificationCycle-Verification

�  Addressestheanalysis,modeling,prototyping,integrationandtesting,whichmustbepartofthedevelopmentprocess

�  Thesecycleswithintheverificationcycleenabletherequirementsandthesolutiontoberefinedandverified.

ManagementCycles�  TheTechnologyandExternalResourceInsertionCycle

�  Enablesmanagementtoinserttechnologiesandexternalresourcesintoboththedevelopmentandthemanufacturingprocessestoimprovethechancesofstakeholdersatisfaction,subjecttotheconstraintsfacedbymanagement.

�  TheControllingCycle�  Providesconfigurationmanagementthroughoutdevelopmentandenablesproduct

releasesandupdatesthroughoutthesystem'slifecycle.�  TheStrategicCheckCycle

�  Top-levelmanagementandstakeholderreviewandapprovalareincludedinthefinalcycle.

TheCycleModel

form, fit, function

fit, function

form, function

CUSTOMER

Determination ofCustomer Desire

Delivery& Sales

Realization1

Translation intoManufacturable

Solution

Translation ofRequirements into

Abstract Specs

Modeling

Prototyping

2Pilot Tests

Creation ofAbstract Solution

Profitability?Feasibility?

Effort? Risks?

Improvement ofTechnologies &

External Resources

Coordination ofExternal

Resources

OrderProcessing

ContolDocument

Verification Cycles

Controlling Cycles

StrategicCheck

systems engineering csc 595 495 spring 2018 howard rosenthal · 2018. 2. 14. · se process,...

Documents

rosenthal porcelain production

copyright: avi rosenthal, 2003. all rights reserved 1...

a review of systems engineering standards and...

engineering project management · the project shall...

curriculum vitae of joachim rosenthal -...

copyright: avi rosenthal, 2002- 2003. all rights reserved 1...

david rosenthal

rosenthal vision

rosenthal homeowners association

rosenthal seiler design portfolio

rosenthal atlanta

rosenthal 2015

rosenthal estate

noncommutative burkholder/rosenthal …

rosenthal cir

rosenthal catalog

rosenthal - crop fertilization

rosenthal novedades 2015

rosenthal selection catalog

rosenthal catalogue 2014