systems engineering csc 595 495 spring 2018 howard rosenthal · 2018. 2. 14. · se process,...
TRANSCRIPT
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-1118442265
2
LessonGoals
� Understandsystemsengineeringprocessesincludingthedesignandintegrationprocess
� DefinetheSIMILARprocess� Understandsomeofthemodelingapproachesinsystemsengineering
� Understandwhatasystemsarchitectureis� Understandwhatgoodrequirementsare,howtheyshapethesystem
� Understandgoodrequirementwriting� UnderstandtheCycleModel
3
4
WhatIsSystemsEngineering� AsdefinedbyINCOSE(InternationalCouncilOnSystems
Engineering)� “SystemsEngineeringisaninterdisciplinaryapproachandmeansto
enabletherealizationofsuccessfulsystems.Itfocusesondefiningcustomerneedsandrequiredfunctionalityearlyinthedevelopmentcycle,documentingrequirements,thenproceedingwithdesignsynthesisandsystemvalidationwhileconsideringthecompleteproblem.“
� SystemsEngineeringisanengineeringdisciplinewhoseresponsibilityiscreatingandexecutinganinterdisciplinaryprocesstoensurethatthecustomerandstakeholder'sneedsaresatisfiedinahighquality,trustworthy,costefficientandschedulecompliantmannerthroughoutasystem'sentirelifecycle.
� Thisprocessisusuallycomprisedofthefollowingseventasks:Statetheproblem,Investigatealternatives,Modelthesystem,Integrate,Launchthesystem,Assessperformance,andRe-evaluate–TheSimilarProcess
5
TheSIMILARProcess(1)
6
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.
7
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.
8
TheSIMILARProcess(4)� TypesofModels
� ThiscoursewillplaceanemphasisonlearningthemodelingtoolsassociatedwithSystemsEngineering,withanemphasisoninformationsystems.ItwillfocusheavilyonteachingstudentsasetofStructuredSystemsAnalysisandDesignmodelingtoolsandtoalesserextenttheSystemModelingLanguage(SysML).
� InadditiontotheSysMLmodelsthefollowingadditionalmodeling/diagrammingtoolswillbetaught.� ArchitectureDiagramsincludingadiscussionofalternate
topologies� N2Charts–Asamechanismtodefineinternalandexternal
interfaces� IDEF0diagrams� StructureCharts� StateTransitionDiagrams� DataFlowDiagrams� Simulations–Ratherthanlearninganewlanguagewewilldevelop
somesimplesystemsimulationsinJava.
9
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.
10
TheSIMILARProcess(6)� AssessTheSystem
� Technicalperformancemeasuresandmetricsareallusedtoassessperformance.
� Technicalperformancemeasuresareusedtomitigateriskduringdesignandmanufacturing.
� Metrics(includingcustomersatisfactioncomments,productivity,numberofproblemreports,orwhateveryoufeeliscriticaltoyourbusiness)areusedtohelpmanageacompany'sprocesses.
� Ifyoucannotmeasureit,youcannotcontrolit.� Eachsubsystemisallocatedaportionofthetotalbudgetandtheprojectmanagerisallocatedareserve.Theseresourcebudgetsaremanagedthroughoutthesystemlifecycle.
11
FiveMajorFunctionsOfSystemsEngineeringDesign
12
Develop Functional
Architecture
Design Physical
Architecture
Develop Allocated
Architecture
Obtain Approval & Document
Define the Design
Problem
AViewOfTheDesignProcess� Thedesignprocessdevelopsdifferentviewwhichmaybeturnedinto
specificationsatvariouspointsinthedesignprocess� Eachspecificationisacollectionofmorerefinedindividual
requirements
13
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
Specs
ScopeofSystemsEngineering
DetailedFunctionsofSystemsEngineeringDesign
14
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
yes
no
DefinetheDesignProblem
DevelopFunctionalArchitectureDevelopPhysical
Architecture
DevelopAllocatedArchitecture
ObtainApproval&Document
JointApplicationDevelopment–EnsuringYouBuildWhatTheyReallyWant
� JAD(JointApplicationDevelopment)isamethodologythatinvolvestheclientorenduserinthedesignanddevelopmentofanapplication,throughasuccessionofcollaborativeworkshopscalledJADsessions.
� Thepurposeistogetearlieracceptanceoftheactualproductbeingdeveloped� Waitinguntiltheproductisdevelopedtodetermineifitisacceptablehasledtonumerousfailuresinthepast
� Youneedtomeetthebusinessanduserneeds
15
AViewOfTheJADParticipants
16
17
SysMLDiagrams
184/15/2008 Copyright © 2006-2008 by Object Management Group. 16
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
19
Structure Diagrams Behavior
Diagrams Interaction Diagrams Requirement
(new) Class – renamed to be Block Definition Internal Block Component Composite structure Deployment Object Package Parametric Design
(new)
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
20
OPMvs.SysML
21
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
22
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
23
ArchitecturalViewpoints
24
Operational Concept
Functional Architecture
Physical Architecture
Allocated Architecture
Interface Architecture
ExampleofAPhysicalArchitecture
25
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).
26
* 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.
NineFundamentalPrinciplesofSystemsArchitectures(2)
� Asystemcanbebrokendownintoasetofsmallersubsystems
� Amobilephonesystem� Itisinfactascreen,akeyboard,abody,amicrophone,aspeaker,andelectronics.
� Butthephoneistheintegrationofallthoseelementsandcannotbeunderstoodcompletelyfromthissetofelements.
27
* 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.
NineFundamentalPrinciplesofSystemsArchitectures(3)
� Asystemmustbeconsideredininteractionwithothersystems,i.e.itsenvironment
� Amobilephonesystem� Itisininteractionwithusers,relays(totransmitthesignal),repairpersonnel(whenbroken),etc.
� Allthesesystemsconstituteitsenvironmentandshallbeconsideredduringitsdesign.
28
* 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.
NineFundamentalPrinciplesofSystemsArchitectures(4)
� Asystemmustbeconsideredthroughitswholelifecycle
� Amobilephonesystem� Willbedesigned,prototyped,tested,approved,manufactured,distributed,sold,used,repaired,andfinallyrecycled.
29
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
30
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(6)� Asystemcanbeconsideredatvariousabstractionlevels,allowingtoconsider
onlyrelevantpropertiesandbehaviors� Isyourmobilephonesystem
� Adevicetomakephonecalls(andotherfunctionsofmodernphones)?� Asetofmaterialandelectronicscomponentsmanufacturedtogether� Anelementofyourcommunicationsmanagementplan?� AWi-Fibridge?� Ahugesetofatoms?(Soundssillybutyoumightlookartitthiswayifyou
wereteleportingit
31
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(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).
33
8. 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(9)� Asystemcanbedescribedthroughdifferentviewpoints
correspondingtovariousactorsconcernedbythesystem.� Inamobilephonesystem
� Differentpersonnel(i.e.designers,engineersinchargeofsoftware,electronics,acoustics,materials,etc.)users,businessexecutives,salesperson,repairerswillhavedifferentvisionsofthephone.
� Whenthedesignerwillseethephoneasaneasy-to-useobjectcenteredontheuser,theengineerwillseeitasatechnologicaldevicewhichhastobeefficientandrobust.Abusinesspersonmayratherseeitasaproductwhichmustmeetclients'needsandmarkettrendstobesold.
� Allthesevisionsareimportantanddefinethesysteminmultipleandcomplementaryways.
34
8. 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
TheDoDArchitecturalFramework(DoDAF)� DoDAFprovidesanoverallframeworkforexpressingarchitecturesfrommultipleperspectivesorviewpoints
� Theoriginalversionhadthreeview,operational,systemsandtechnical,whichhavenowbeenexpandedtosevenviewpoints
� Eachviewpointhasaparticularpurpose,andusuallypresentsoneorcombinationsofthefollowing:� Broadsummaryinformationaboutthewholeenterprise(e.g.,high-
leveloperationalconcepts).� Narrowlyfocusedinformationforaspecialistpurpose(e.g.,system
interfacedefinitions).� Informationabouthowaspectsoftheenterpriseareconnected
(e.g.,howbusinessoroperationalactivitiesaresupportedbyasystem,orhowprogrammanagementbringstogetherthedifferentaspectsofnetworkenabledcapability).
35
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
37
MappingBetweenDoDAF1.5and2.0
38
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.
39
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.
40
WhatAreRequirements(2)� Functionalrequirementsdescribewhatasystemdoes
� Somearesimple,forexample,thesystemmustbepaintedwithaspecificshadeofgreen.
� Othersaremorecomplex–i.e.identifyplanetsaroundotherstarswithadiameternogreaterthantwiceearth’s
� Performancerequirements� Definesadesireddirectionofperformanceassociatedwithanobjectiveofthestakeholdersforthesystem.
� Foranyperformancerequirement,theremustalsobeaminimumacceptableperformanceconstraintorthresholdandadesigngoalassociatedwiththeindex;thisthresholddictatesthatnomatterhowwonderfuladesign'sperformanceisonotherobjectives,performancebelowthisthresholdonthisrequirementmakesthedesignunacceptable.
� AllrequirementsarestatedwiththewordShall.May,can,shouldwill,etc.arenotdefinitive.
41
SomeTypicalRequirementsDocuments
42
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
43
DOD-STO-2167
I SYSTEM J
1SEGMENTI [ SEGMENT 21
-h
1
TLCSC31
I
LL(XC LLCSC312 313
I I I
‘@ @
@@
621UNIT NIT
limaLLCSC 673LLW ‘Nil ‘Ni3301
UNIT UNl uN! (JNI UNl UNIT
LH!lwlbNIT UNIT Nl NIT NIT UNIT
FIGURE3. CSClsample etatic structure.
)
14
)
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?
44
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.”
45
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)?
46
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
47
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?
48
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?
49
50
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.
51
TheCycleModel
52
form, fit, function
fit, function
form, function
CUSTOMER
Determination ofCustomer Desire
1
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
3
OrderProcessing
3
ContolDocument
ContolDocument
ContolDocument
Verification Cycles
4
Controlling Cycles
StrategicCheck
5