View
7
Download
0
Category
Preview:
Citation preview
Systems EngineeringSystems EngineeringTutorialTutorial
SEPG ConferenceMarch 2004
Orlando, Florida
SE Tutorial Sys Thinking - 2version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
WelcomeWelcomeようこそ
Wilkommen
Bienvenido
WelKom
Bienvenue
BienvenutoVälkommen
Tervetuloa Witamy
Huan Yín
ЌАΛΟΣΟΡΙΣΑΤΕ
SE Tutorial Sys Thinking - 3version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
IntroductionsIntroductions
SE Tutorial Sys Thinking - 4version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
ExpectationsExpectations
SE Tutorial Sys Thinking - 5version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Logistics Logistics -- 11
SE Tutorial Sys Thinking - 6version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Logistics Logistics -- 22
SE Tutorial Sys Thinking - 7version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Tutorial ObjectivesTutorial Objectives
By the end of this course, you will be able toHave a better understanding of Systems Engineering and Systems Management
Understand the roles and responsibilities of Systems Engineers
Utilize standard processes for engineering a system
Be able to choose an appropriate lifecycle to guide systems development on a project
Understand the recursive nature of requirements development
SE Tutorial Sys Thinking - 8version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Tutorial Objectives Tutorial Objectives -- 22
Develop feasible functional, physical, and implementation architectures
Understand the importance of interface development, management and control and how it leads to successful product integration
SE Tutorial Sys Thinking - 9version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
ScheduleSchedule
December
SE Tutorial Sys Thinking - 10version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Engineering Engineering Systems Systems ThinkingThinking
SE Tutorial Sys Thinking - 11version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems ThinkingSystems Thinking
Systems Thinking is a discipline for seeing the wholeSystems Thinking is a framework for seeing interrelationships and repeated events rather than thingsSystems Thinking is seeing patterns of change rather than static snapshotsSystems Thinking embodies the idea that the interrelationships among parts relative to a common purpose of a system are what is important
SE Tutorial Sys Thinking - 12version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Fifth DisciplineThe Fifth Discipline
According to Peter Senge, systems thinking is the fifth discipline “and is the catalyst and cornerstone of the learning organization that enables success through the other four disciplines”:
Personal mastery through proficiency and commitment to lifelong learningShared mental models of the organization’s markets and competitorsShared vision for the future of the organizationTeam learning
Peter Senge, The Fifth Discipline: TheArt and Practice of the LearningOrganization, Doubleday, New York, 1990
SE Tutorial Sys Thinking - 13version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of the Fifth Laws of the Fifth DisciplineDiscipline
Contemporary and future problems often come about because of what were presumed to be past solutionsFor every action, there is a reactionShort-term improvements often lead to long-term difficultiesThe easy solution may be no solution at allThe solution may be worse than the problemQuick solutions, especially at the level of symptoms, often lead to more problems than existed initially
SE Tutorial Sys Thinking - 14version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of the Fifth Laws of the Fifth Discipline Discipline -- 22
Cause and effect are not necessarily closely related, either in time or in space
Sometimes solutions implemented here and now will have impacts far away at a much later time
The actions that will produce the most effective results are not necessarily obvious at first glanceThe entire system, comprised of the organization and its environment, must be considered together
SE Tutorial Sys Thinking - 15version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Processes for Processes for Engineering a Engineering a
SystemSystemEIA EIA -- 632632
SE Tutorial Sys Thinking - 16version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Fundamental Processes Fundamental Processes for Engineering a Systemfor Engineering a System
Processes for EngineeringA System
Acquisition and Supply•Supply Process•Acquisition Process
Technical Management•Planning Process•Assessment Process•Control Process
System Design•Requirements Definition Process•Solution Definition Process
Product Realization•Implementation Process•Transition to Use Process
Technical Evaluation•Systems Analysis Process•Requirements Validation Process•System Verification Process•End Products Validation Process
SE Tutorial Sys Thinking - 17version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
T e c h n i c a l M a n a g e m e n tP la n n i n gP r o c e s s
A s s e s s m e n tP r o c e s s
C o n t r o lP r o c e s s
T e c h n i c a l E v a l u a t i o nS y s t e m sA n a l y s i sP r o c e s s
R e q u i r e m e n t sV a l i d a t i o n
P r o c e s s
S y s t e mV e r i f i c a t i o n
P r o c e s s
E n d P r o d u c t sV a l i d a t i o n
P r o c e s s
A c q u i s i t i o n & S u p p l y
S u p p lyP r o c e s s
A c q u i s i t io nP r o c e s s
P r o d u c tR e a l i z a t i o n
I m p le m e n t a t io nP r o c e s s
T r a n s i t io n t o U s eP r o c e s s
S y s t e mD e s i g n
R e q u i r e m e n t sD e f i n i t i o n P r o c e s s
S o lu t io n D e f i n i t io nP r o c e s s
P l a n s ,D i r e c t i v e s
& S t a t u s
O u t c o m e s&
F e e d b a c k
P r o d u c t s
Acq
uisi
tion
Req
uest
Syst
em
Prod
ucts
Relationship of Processes Relationship of Processes for Engineering a Systemfor Engineering a System
SE Tutorial Sys Thinking - 18version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of Engineering Laws of Engineering Systems ThinkingSystems Thinking
In all of the project’s phases/stages, and along the system’s life, the systems engineer has to take into account:
The customer’s organization vision, goals, and tasksThe customer’s requirements and preferencesThe problem to be solved by the system and the customer’s needs
The whole has to be seen as well as the interaction between the system’s elements
Iterative or recursive thinking must replace the traditional linear thinking
SE Tutorial Sys Thinking - 19version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of Engineering Laws of Engineering Systems Thinking Systems Thinking -- 22
The solution is not always an engineering one – remember to always take into account
Business and economic costsReuse or utilization of products and infrastructure already developedOrganizational, managerial, political, and personal considerations
The end user must be considered as a major part of the system
At each stage the human element must be considered
SE Tutorial Sys Thinking - 20version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of Engineering Laws of Engineering Systems Thinking Systems Thinking -- 33
When a need arises to carry out a modification to the system always take into account:
The engineering and non-engineering implicationsThe effects on the form, fit, and functionThe system’s response to the changesThe needs, difficulties, and attitudes of those who must live with the modification (stakeholders)
Each problem may have more than one possible working solution
All possible alternatives should be examined and compared to each other by quantitative and qualitative measurements
SE Tutorial Sys Thinking - 21version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of Engineering Laws of Engineering Systems Thinking Systems Thinking -- 44
Evaluate future logistic requirements in all development phases
Spare partsMaintenance infrastructureSupportServiceMaintenance levelsTechnical documentation
SE Tutorial Sys Thinking - 22version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Laws of Engineering Laws of Engineering Systems Thinking Systems Thinking -- 55
Avoid adapting a known solution for the current problem – it might not be suitableTake into account development risksIt is impossible to run a project without:
ControlConfiguration managementMilestonesManagementScheduling methods
SE Tutorial Sys Thinking - 23version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
SummarySummary
One of the most prominent problems observed in software and software / systems organizations today is the lack of engineering discipline - cited by managers at all levelsThe CMM was developed to encourage organizations to develop processes to guide its software developmentThe CMMI integrated Software CMM and Systems Engineering CMM and put the “engineering” back into processEngineering Systems Thinking has again been recognized as an important asset for building systems
SE Tutorial Sys Thinking - 24version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering and Systems and Systems ManagementManagement
OverviewOverview
SE Tutorial Sys Thinking - 25version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering RolesRoles
Common and Not-So-Common names for systems engineering
Systems EngineersSystems ArchitectsSystems IntegratorsSystems Management EngineersSystems Quality Assurance EngineersSystems TheoristsSystems ReengineersOperations ResearchManagement Science Closely Related Professions
SE Tutorial Sys Thinking - 26version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Engineering of Engineering of SystemsSystems
Systems Engineering is concerned with the engineering of systemsSystems Management is concerned with strategic level Systems Engineering Systems Engineering efforts involve:
Systems engineering methods and tools or technologiesSystems processSystems management
SE Tutorial Sys Thinking - 27version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Three Levels of Three Levels of Systems EngineeringSystems Engineering
Syst
ems
Engi
neer
ing
Team Systems Management
Systems Engineering Processes, or Methodologies
Systems EngineeringMethods and Tools or
Technologies
Syst
em P
rodu
ct o
r Ser
vice
U
nder
Dev
elop
men
t
SE Tutorial Sys Thinking - 28version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Management Management TechnologyTechnology
Systems Engineering is a Management Technology
Technology is the organization, application, and delivery of a scientific and other forms of knowledge for the betterment of a client group
Technology can be viewed as a fundamentally human activity
SE Tutorial Sys Thinking - 29version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Management Management Technology Technology -- 22
Management involves the interaction of the organization with the environmentThe purpose of management is to enable organizations to better cope with their environments in order to achieve purposeful goals and objectivesManagement Technology involves the interaction of:
TechnologyOrganizations that are collections of people concerned with the evolvement and use of technologiesEnvironment
SE Tutorial Sys Thinking - 30version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Management Management Technology Technology -- 33
Environment
Management
Organization
Science
Technology
Organization
Science
InformationOrganization
EnvironmentManagement Technology
SE Tutorial Sys Thinking - 31version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Management Management Technology Technology -- 44
Systems Engineering is the management technology that controls a total system life-cycle process, which evolves and which results in the definition, development, and deployment of a system that is of high quality, and is cost-effective in meeting the user’s needs
SE Tutorial Sys Thinking - 32version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Knowledge TypesKnowledge Types
Knowledge PrinciplesGenerally represent formal problem-solving approaches to knowledgeGenerally employed in new situations and/or unstructured environments
Knowledge PracticesRepresent the accumulated wisdom and experiences that have led to the development of standard operating policies for well-structured problems
Knowledge PerspectivesRepresent the view that is held relative to future directions and realities in the technological area under consideration
SE Tutorial Sys Thinking - 33version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Knowledge Types Knowledge Types -- 22
Knowledge Perspectives
Knowledge Principles
Knowledge Practices
Learning Over Time
System Planning and Marketing
ResearchDevelopment, Test,
And Evaluation
Product AcquisitionProduction, or Procurement
SE Tutorial Sys Thinking - 34version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Formulation, Analysis, Formulation, Analysis, and Interpretationand Interpretation
Systems Engineering is management technology to assist and support policymaking, planning, decision making, and associated resource allocation or action deploymentSystems Engineers utilize quantitative and qualitative formulation, analysis, and interpretation of
The impacts of action alternatives upon the needs perspectivesThe institutionalization perspectivesThe value perspectives of the clients or customers
SE Tutorial Sys Thinking - 35version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Formulation, Analysis, Formulation, Analysis, and Interpretation and Interpretation -- 22
Issue Formulation – Identifies the needs to be fulfilled and the requirements associated with these in terms of:
Objectives to be satisfiedConstraints and alterables that affect issue resolutionGeneration of potential alternate courses of action
Issue Analysis – Enables us to determine the impacts of the identified alternative courses of action, including possible refinement of the alternatives
SE Tutorial Sys Thinking - 36version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Formulation, Analysis, Formulation, Analysis, and Interpretation and Interpretation -- 33
Issue Interpretation – Enables us to rank the alternatives in terms of need satisfaction and to select one for implementation or additional study
Systems Engineering can be thought of as consisting of formulation, analysis, and interpretation efforts, together with the system management and technical direction efforts necessary to bring this about
SE Tutorial Sys Thinking - 37version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Primary Systems Primary Systems Engineering StepsEngineering Steps
Formulation
Analysis
Interpretation
Primary InformationFlowSecondaryInformationFlow
SE Tutorial Sys Thinking - 38version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Primary Systems Primary Systems Engineering Engineering LifeLife--Cycle PhasesCycle Phases
Systems Definition
SystemDevelopment
System Deployment
Primary InformationFlowSecondaryInformationFlow
SE Tutorial Sys Thinking - 39version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems ManagementSystems Management
Systems Management can be viewed from an inactive, reactive, interactive, or proactive perspective
Inactive – Organization does not worry about issues and does not make efforts to resolve themReactive – Organization will examine a potential issue only after it has developed into a real problem
an outcomes assessment will be performedsymptoms that produced the problem will be eliminated
SE Tutorial Sys Thinking - 40version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Systems Management Management -- 22
Interactive – Organization will attempt to examine issues while they are in the process of evolution in order to detect problems at the earliest possible time
efforts at diagnosis and correction will be implemented as soon as possiblerecycling, feedback, and retrofit to and through that portion of the life-cycle process in which the problem occurred will take place
Proactive – Organization predicts the potential for progress hindering issues and synthesizes an appropriate life-cycle process that is sufficiently mature
SE Tutorial Sys Thinking - 41version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Systems Management Management -- 33
Systems Engineering often fails at the level of systems management:
Purpose, function, and structure of a new system are not identified sufficiently before the system is defined, developed, and deployedFormulation, analysis, or interpretation efforts are deficient
SE Tutorial Sys Thinking - 42version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Systems Management Management -- 44
Systems Management and integration issues are of major importance in determining the effectiveness, efficiency, and overall functionality of systems designTo achieve a high measure of functionality, it must be possible for a system (product or service) to be efficiently and effectively:
ProducedUsedMaintainedRetrofittedModified
SE Tutorial Sys Thinking - 43version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
SummarySummary
Systems Engineering is a Management TechnologyTechnologyOrganizations that are collections of people concerned with the evolvement and use of technologiesEnvironment
Systems Engineering is concerned with the engineering of systems
Systems engineering methods and tools or technologiesSystems processSystems management
SE Tutorial Sys Thinking - 44version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
ProductProductLifecyclesLifecycles
SE Tutorial Sys Thinking - 45version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Research, Development, Research, Development, Test and Evaluation LifeTest and Evaluation Life--Cycle ModelCycle Model
BasicResearch
AppliedResearch
Test andEvaluation
Full ScaleDevelopment
ProductionSupport
Definition
Development
Deployment
SE Tutorial Sys Thinking - 46version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Research, Development, Research, Development, Test and Evaluation LifeTest and Evaluation Life--Cycle ModelCycle Model -- 22
A well-managed RDT&E program is often thought of as a tool for risk mitigationRDT&E lifecycle provides a framework within which to manage research and development
The concept of the lifecycle can be defined abstractly3 major phases can be defined: definition, development, deployment
SE Tutorial Sys Thinking - 47version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
A Closer Look at the A Closer Look at the RDT&E LifecycleRDT&E Lifecycle
Definition PhaseBasic research is either well defined or non-well definedWell defined research is defensive, undertaken to protect the organization’s market position from market competitionNon-well defined research is more likely to result in product diversification
SE Tutorial Sys Thinking - 48version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
A Closer Look at the A Closer Look at the RDT&E Lifecycle RDT&E Lifecycle -- 22
Development PhaseProduct is designed and builtOrganizational constraints may be felt and reflect the need for corporate changeBusiness processes may need to be realigned to accommodate new productionProduct-level insights cause iteration on the requirements phase until an acceptable product is defined and built
the development phase may be regarded as the prototyping element of the requirements phaseat the end of the development phase, the requirements will be more stable but not frozen
SE Tutorial Sys Thinking - 49version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
A Closer Look at the A Closer Look at the RDT&E Lifecycle RDT&E Lifecycle -- 33
Deployment PhaseTest and Evaluation provide the content for the Deployment PhaseThe goal of this phase is to deploy a useful model of a potential product for the consideration of managementThe model provides information about the impact potential upon the organization in terms of:
start-up costsperturbation of existing functionsapplicability of existing assets
SE Tutorial Sys Thinking - 50version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
CustomerView
SystemsEngineer
View
ContractorView
UserRequirements
System Specification
Built and Tested System
Built and Tested Subsystems
Built and Tested Components
Subsystem Specifications and Designs
Component Specifications and Designs
3 Views of the System3 Views of the System
SE Tutorial Sys Thinking - 51version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
3 Views of the 3 Views of the System System -- 22
Customer ViewAssociates system requirements with their realization as a delivered systemThis view is from the perspective of the stakeholders whose consolidated input forms the customer requirementsA list of requirements are delivered and a finished product that meets the requirements is expected
SE Tutorial Sys Thinking - 52version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
3 Views of the 3 Views of the System System -- 33
Systems Engineering ViewThis layer represents the architectural model which addresses the decomposition of the system-level specification into systems design and subsystem specifications and designs
The architectural model is the perspective of the systems engineer who is interested in:
decomposing the whole into manageable partsre-specifying and designing the partsintegrating the parts to compose the finished system
SE Tutorial Sys Thinking - 53version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
3 Views of the 3 Views of the System System -- 44
Contractor ViewThe lowest level couples component specifications and designs with fully tested componentsThe implementation model is the perspective of the contractor who is interested in component-level specifications, designs, and products
The Systems Engineering must therefore:Recognize the product or component as a systemAnalyze the system requirementsSynthesize the system components
SE Tutorial Sys Thinking - 54version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Product Systems Product LifecycleLifecycle
CONCEPTUAL
DEFINITION
PRODUCTION
OERATIONALDIVESTMENT
DETERIORATIONMATURITY
MA
RK
ET
INTR
OD
UC
TION
GROWTHPUREBASICRESEARCH
DEATH
APPLIED RESEARCH
INVE
STM
ENT
RET
UR
N
ROI
REVENUE
PROFIT
BREAKEVEN POINT
RESERCH AND DEVELOPMENT
INVESTMENT
SE Tutorial Sys Thinking - 55version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Definition of a Definition of a Project LifecycleProject Lifecycle
CONCEPTUAL PHASE
PLANNINGPHASE
DEFINITION& DESIGN
PHASE
IMPLEMENTATIONPHASE
CONVERSIONPHASE
PMD
RES
OU
RSE
S
PMO
REQUIRED RESOURCES
SE Tutorial Sys Thinking - 56version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Systems ApproachThe Systems Approach
Systems
REQUIREMENTS
REQUIREMENTS
REQUIREMENTS
REQUIREMENTS
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
ALTERNATIVE
Constraints* Legislative * Financial* Timing * Policy
Selection Criteria* Performance * Cost/Benefit* Response Time * Policy
Translation Trade OffAnalysis Synthesis
SE Tutorial Sys Thinking - 57version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
A Concurrent Engineering A Concurrent Engineering LifeLife--Cycle ModelCycle Model
TC>CT
CETEAM
ConceptDevelopment
MarketAnalysis
Set, Cost,Target (CT)
FullProduction
Marketing andDistribution
RequirementsAnalysis
Specifications
Design
Implementation
Testing
Estimation of Total Cost (TC)
RequirementsAnalysis
Specifications
Design
Implementation
Testing
RequirementsAnalysis
Specifications
Design
Implementation
Testing
ManufacturingProcess
Development
ManufacturingSystem
Development
ProductDevelopment
SE Tutorial Sys Thinking - 58version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements EngineeringEngineering
SE Tutorial Sys Thinking - 59version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
What Are What Are Requirements?Requirements?
Customer’s needs, expectations, and measures of effectivenessItems that are necessary, needed, or demandedImplicit or explicit criteria that must, should, or might be metContain system and software informationShould not contain details regarding the internal implementation of a solutionMay be derived from other requirements during analysis, operational concept and operational scenarios development
SE Tutorial Sys Thinking - 60version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
What Are What Are Requirements? Requirements? -- 22
Description of the services the system is to provideDescription of how the system should behaveDescription of the circumstances under which it is required to operateApplication domain informationConstraints on the system’s operationsSpecifications of a system property or attributeConstraints on the development process of the system
SE Tutorial Sys Thinking - 61version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
What Are What Are Requirements? Requirements? -- 33
Requirements invariably contain a mixture ofProblem information
Statements of system behavior
Systems properties
Design constraints
Manufacturing constraints
This can and normally does result in conflictsthat must be negotiated and resolved
SE Tutorial Sys Thinking - 62version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Sources of Sources of RequirementsRequirements
CustomerMarketingSurveysSystems EngineeringExisting Systems, SpecificationsStandardsIndustry StudiesAcademic Research
SE Tutorial Sys Thinking - 63version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Sources of Sources of Requirements Requirements -- 22
Prototyping
Simulation
Quality Assurance Group
Configuration Management Group
SE Tutorial Sys Thinking - 64version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements CategoriesCategories
Product Requirements - define the technical criteria that must, should, or might be met by the delivered product
Project Requirements - stipulate resources that will be made available, and how different aspects of the project will be carried out
Process Requirements - indicate standards, procedures, methods, languages, ...
SE Tutorial Sys Thinking - 65version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Hierarchy of Hierarchy of RequirementsRequirements
Customer orMarket Needs
System or ProductRequirements
HardwareRequirements
SoftwareRequirements
ServicesRequirements
ProcessRequirements
PeopleRequirements
SE Tutorial Sys Thinking - 66version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements EngineeringEngineering
Requirements Engineering topics include:ElicitationAnalysisSpecificationReviewTraceabilityManagement
Change RequestsImpact Analysis
VerificationValidation
SE Tutorial Sys Thinking - 67version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements DevelopmentDevelopment
SE Tutorial Sys Thinking - 68version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Customer, Product, and Customer, Product, and Product Component Product Component RequirementsRequirements
OperationalConcept &Scenarios
CustomerRequirements
Definition ofFunctionality
Product and Product ComponentRequirements
DerivedRequirementsCustomer
End User
Co-workers &Management
Stakeholders
Marketing
RegulatoryAgencies
Independent Test
QualityAssurance
SE Tutorial Sys Thinking - 69version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Customer, Product, and Customer, Product, and Product Component Product Component Requirements Requirements -- 22
Processes
H/W, S/W,Mechanical,
Electrical,Engineering
Product
Require
ments
Alloca
ted to
Functions
Product andProduct ComponentRequirements
Services
People
Customer
End User
Co-workers &Management
Stakeholders
Marketing
RegulatoryAgencies
Independent Test
QualityAssurance
SE Tutorial Sys Thinking - 70version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Collecting and Collecting and Coordinating Coordinating Stakeholders’ Needs Stakeholders’ Needs -- 22
Stakeholders include:CustomersEnd-usersDevelopersProducersTestersSuppliersMarketersMaintainersSafety Regulation AgenciesManagers
SE Tutorial Sys Thinking - 71version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Elicitation TechniquesElicitation Techniques
Examples of techniques to identify and elicit Stakeholders’ needs include:
DialogueScenario reviewsTechnology demonstrationsModelsSimulationsPrototypesBrainstormingObservations of existing systemsExtractions from sources such as documents, standards, and specifications
SE Tutorial Sys Thinking - 72version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Generic Requirements Generic Requirements Elicitation ProcessElicitation Process
Establish objectives Understand background Organize knowledge Collect requirements
Businessgoals
Businessgoals
Problems tobe solved
Problems tobe solved
Systemconstraints
Systemconstraints
Organizationalstructure
Organizationalstructure
ExistingsystemsExistingsystems
Applicationdomain
Applicationdomain
StakeholderidentificationStakeholderidentification
Goalprioritization
Goalprioritization
Domainknowledge
filtering
Domainknowledge
filtering
Domainrequirements
Domainrequirements
StakeholderrequirementsStakeholder
requirements
Organizationalrequirements
Organizationalrequirements
Gerald Kotonya and Ian Sommerville, Requirements Engineering, John Wiley and Sons, 1998
SE Tutorial Sys Thinking - 73version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Product and Product Product and Product Component Component RequirementsRequirements
Product and product component requirements define what the system is required to do and the circumstances under which it is required to operateCustomer requirements are analyzed in conjunction with the development of the operational concept to derive a more detailed and precise set of requirements called “product and product component requirements”Product and product component requirements include technical requirements and the criteria that will be used to verify that the products satisfy the requirements
SE Tutorial Sys Thinking - 74version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Interface Interface RequirementsRequirements
Interfaces between functions must be defined and controlled as part of the product and product component integrationAs interface designs are defined, the design becomes a requirement for products and product components that are affected by the interface
SE Tutorial Sys Thinking - 75version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Operational Concepts Operational Concepts and Scenariosand Scenarios
Scenarios and Operational Concepts are developed, analyzed, and reviewed to refine existing requirements and discover new requirements, needs, and constraints
Scenarios are normally sequences of events that might occur in the use of the product
Operational concepts depend on both the design solution space and the scenarios
define the interaction of the product, the end user and the environment
define the operational, maintenance, support, and disposal needs
SE Tutorial Sys Thinking - 76version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Validating Validating RequirementsRequirements
Customer requirements should be validatedearly in the development schedule to gain confidence that the customer requirements are capable of guiding a development that results in the customer’s operational needs being met
SE Tutorial Sys Thinking - 77version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Spiral Model of the Spiral Model of the Product Requirements Product Requirements Engineering ProcessEngineering Process
START
Requirements elicitation
Requirements validationRequirements documentation
Requirements analysisand negotiation
Informal statement ofrequirementsDecision point:
accept documentor re-enter spiral
Agreedrequirements
Gerald Kotonya and Ian Sommerville, Requirements Engineering, John Wiley and Sons, 1998
Requirementsdocument and
validation report
Draft Requirementsdocument
SE Tutorial Sys Thinking - 78version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
RequirementsRequirementsManagementManagement
SE Tutorial Sys Thinking - 79version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
RD
RM
The Requirements Management and The Requirements Management and Requirements Development Partnership Requirements Development Partnership (Figure 12.5)(Figure 12.5)
TS
SE Tutorial Sys Thinking - 80version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements ManagementManagement
Requirements and requirements change requests are analyzed and reviewed to ensure that a compatible, shared understanding is reached on the meaning of the requirementsChanges to the requirements must be controlled as they evolve over the product lifecycle due to changing needs and derived requirementsA change history is maintained for each requirement along with the rationale for the change
Initially captured and/or derivedAfter approved changes have been applied
SE Tutorial Sys Thinking - 81version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Impact Analysis for Impact Analysis for Requirements Change Requirements Change RequestsRequests
Impact Analysis is made based on the requirements change request:
Development ScheduleRelease ScheduleChanges required to this systemStaffingComponentsDevelopment and Target equipmentRisks SCOPECostsChanges required to other systems or interfaces within the projectOther existing products or product lines
SE Tutorial Sys Thinking - 82version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Requirements Requirements TraceabilityTraceability
Requirements cannot be managed effectively without requirements traceabilityA requirement is traceable if:
You know the source of each requirementWhy the requirement existsWhat requirements are related to itHow that requirement relates to other information such as systems designs, implementations, and user documentation
Traceability information is used to find other requirements which might be affected by proposed changes
SE Tutorial Sys Thinking - 83version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Consistency of LifeConsistency of Life--Cycle Work ProductsCycle Work Products
The project plans, work products, and activities are changed to be consistent with approved changes made to the requirements and must be:
IdentifiedEvaluatedAssessed for riskDocumentedPlannedCommunicatedTracked to completion
SE Tutorial Sys Thinking - 84version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
SummarySummary
Requirements development and requirements management contribute to product development
Requirements and analysis are essential to producing high quality software and maintaining control over product development
Supports controls of requirements change requests throughout the development lifecycle
Takes all stakeholders views into consideration
Is an iterative and recursive process
SE Tutorial Sys Thinking - 85version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Summary Summary -- 22
Requirements are the foundation:For the product (H/W and/or S/W)For the planningFor acceptance by the customerFor defining quality expectations
SE Tutorial Sys Thinking - 86version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Systems ArchitecturesArchitectures
SE Tutorial Sys Thinking - 87version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems ArchitectingSystems Architecting
Systems Architecting has been defined as the process of creating complex, unprecedented systemsBuilding systems in today’s world is tenuous at best
Requirements of the marketplace are ill-definedRapidly evolving technology provides new services at a global level instantlyUncertainty is increasing about they way the system will be used, the components that will be incorporated and the interconnections that will be made
SE Tutorial Sys Thinking - 88version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Systems Architecting Architecting -- 22
Generating a system architecture as part of the systems engineering process can be seen as a deliberate approach to deal with the uncertainty or risk that characterizes these complex, unprecedented systems
SE Tutorial Sys Thinking - 89version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Traditional Approach Traditional Approach to System Architectingto System Architecting
Many methodologies have been developed to support a traditional system development model
Define the requirementsConsider several optionsEmerge with a well-defined design through a process of eliminationBased on structured analysis and design
SE Tutorial Sys Thinking - 90version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Traditional Approach to Traditional Approach to System Architecting System Architecting -- 22
Effective when the requirements are well defined and remain essentially constant during the system development periodCannot handle change well
If the implementation of the system is long – on the order of years – the requirements change because of changing needs and new technology offers different alternatives and opportunities
SE Tutorial Sys Thinking - 91version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Traditional The Traditional ApproachApproach
O
P
T
I
O
N
S
DESIGN
time
SE Tutorial Sys Thinking - 92version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Evolutionary ApproachEvolutionary Approach
New approach that is emerging with roots in software systems engineeringDeals with uncertainty in requirements and in technology, especially for systems with a long development time and expected long life cycle
Evolutionary developmentBuild-a-little, Test-a-little
Requirements are allowed to be more abstract and therefore subject to interpretationAlternative solutions are explored and pursued further as new technology options become available
SE Tutorial Sys Thinking - 93version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Evolutionary ApproachEvolutionary Approach
time
SOLUTIONS
PROBLEM
SOLUTIONS THAT LEAD TO DESIGNS
SE Tutorial Sys Thinking - 94version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Select, Build, and FieldSelect, Build, and Field
At any time in the development process, when there is a need to build a system, the available solution that best meets the current requirements is selected and implemented using any systems engineering approach
SE Tutorial Sys Thinking - 95version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Select, Build, and FieldSelect, Build, and Field
SOLUTI
ONS
PROBLEM
REQUIREMENTS PROCESS DESIGN
SELECT
BUILD AND FIELD
SE Tutorial Sys Thinking - 96version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Defining an Defining an ArchitectureArchitecture
Architecture – The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution
A system architect, not only knows about the individual components, but also understands the interrelationships among the components
SE Tutorial Sys Thinking - 97version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Defining an Defining an Architecture Architecture -- 22
A functional architecture is:A set of activities or functions that are arranged in a specific order and when activated, achieves a set of requirements
A physical architecture is:A representation of the physical resourcesExpressed as nodes that constitute the system and their connectivityExpressed in the form of links
SE Tutorial Sys Thinking - 98version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Defining an Defining an Architecture Architecture -- 33
An important task in the architecture development process is to define the operational concept
A concise statement that describes how the goal will be metHow will the system look and act in the operational environment
A technical architecture is a minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements that must ensure that a conformant system satisfies a specified set of requirements
SE Tutorial Sys Thinking - 99version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Defining an Defining an Architecture Architecture -- 44
The functional, physical, and technical architecture are static representations that attempt to describe the dynamic behavior of the architectureIn order to analyze the behavior of the architecture and evaluate the performance characteristics, an executable model is needed
SE Tutorial Sys Thinking - 100version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Interfaces & Interfaces & Product IntegrationProduct Integration
SE Tutorial Sys Thinking - 101version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
InterfacesInterfaces
SE Tutorial Sys Thinking - 102version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Importance of The Importance of InterfacesInterfaces
Interface development is a Systems Engineering activity because of the basic need to break down large problems into many related smaller ones
The smaller problems have interfaces between them that must be compatible across all terminals
Interface – a point at which independent systems or components meet and act or communicate with each otherInterfaces can exist between system elementsInterfaces can also exist between a system element and the system environment
SE Tutorial Sys Thinking - 103version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Importance of The Importance of Interfaces Interfaces -- 22
Interfaces can enhance system capability but a trade-off must be made between internal and external complexity
In Software Engineering, this is recognized in the attempt to balance the concepts of cohesion and coupling
Interfaces between hardware and software must be carefully examined due to the impact those interfaces have on the design of complex, software intensive systemsAn Interface Requirements Specification can represent the requirements or constraints of system interfaces, both internal and external, and can include both functional and external interfaces
SE Tutorial Sys Thinking - 104version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
The Importance of The Importance of Interfaces Interfaces -- 33
Terminal 1 Terminal 2
InternalInterfaces
MediaExternalInterface
Media
Types of Implementation Interfaces
SE Tutorial Sys Thinking - 105version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Common InterfacesCommon Interfaces
Internal Interface – An internal interface resides inside the element of focus, including its terminals, connectors and mediaExternal interface – An external interface to an element will have at least one internal terminal and one external terminal
The media connecting the terminals will go across the plane that separates the internal from the external terminal through a connectorAn external terminal can be an environment
SE Tutorial Sys Thinking - 106version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Common Interfaces Common Interfaces -- 22
Functional Interface – Functional interfaces describe the role of an internal or external interface in terms of translating control, information, or energy across an interfaceEnvironmental Interface – An interface between a system or component and the natural or induced environment
The environment may serve as a terminal and as the media
SE Tutorial Sys Thinking - 107version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Common Interfaces Common Interfaces -- 33
Hardware to Software Interfaces – Software interfaces occur through hardware media
Bits are transferred through hardware media and stored in hardware such as magnetic memory or a cache until it is made available to the softwareHardware serves as the media in all software interfacesHardware such as processing, data transmission, and storage, buffering, display, and input are often transparent to the software developer
SE Tutorial Sys Thinking - 108version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Product Product IntegrationIntegration
SE Tutorial Sys Thinking - 109version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Integration StrategyIntegration Strategy
The basis for effective product integration is an integration strategy that uses combinations of techniques in an incremental manner
An integration strategy should be developed early in the project, concurrently with product development plans and specifications
The integration plan should identify a sequence for receipt, assembly, and activation of the various components that make up the product
SE Tutorial Sys Thinking - 110version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Integration Strategy Integration Strategy -- 22
Establishing the product integration strategy including the following:
Integration sequenceWork to be doneResponsibilities for each activityResources requiredSchedule to be metProcedures to be followedTools requiredEnvironmentPersonnel skills
SE Tutorial Sys Thinking - 111version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Product Integration Product Integration EnvironmentEnvironment
Establish and maintain the environment needed to support the integration of the product componentsThe product integration strategy may identify needs for an environment that must be acquired or developedThe product integration environment may include the reuse of existing organizational resources
SE Tutorial Sys Thinking - 112version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Product Integration Product Integration Environment Environment -- 22
The environment required at each step of the product integration may include:
Test equipmentSimulatorsPieces of real equipmentRecording devices
SE Tutorial Sys Thinking - 113version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Detailed Product Detailed Product Integration ProceduresIntegration Procedures
Detailed procedures for the integration of the product components include such things as detailed criteria
Can include criteria indicating the readiness of a product component for integration or its acceptabilityCan be defined for how the product components are to be verified and the functions they are expected to haveMay also include the degree of simulation permitted for a product component to pass a testMay describe the environment for the integration test
SE Tutorial Sys Thinking - 114version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Ensure Interface Ensure Interface CompatibilityCompatibility
Product component interface requirements, specifications, and designs must be managed effectively to help ensure that all implemented interfaces will be complete and compatibleThe interfaces should include, in addition to product component interfaces, all the interfaces with the environment as well as other environments for verification, validation, operations, and support
SE Tutorial Sys Thinking - 115version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Ensure Interface Ensure Interface Compatibility Compatibility -- 22
Pro
duct
Com
pone
nt
Env
ironm
ent
Pro
duct
Com
pone
nt
Interface toEnvironment
Interface to Product
Component
SE Tutorial Sys Thinking - 116version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Confirm Readiness of Confirm Readiness of Product Components Product Components for Integrationfor Integration
Confirm that each product component is compliant with its interface requirements
Ensure that the product components are delivered to the product integration environment in accordance with the planned product integration strategy
Verify the receipt of each product component
Verify the configuration status of the product component against the expected configuration
Verify the configuration status of the accompanying interface documentation against the expected configuration
Perform pre-checks of all physical interfaces before connecting product components together
SE Tutorial Sys Thinking - 117version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Assemble and Assemble and Evaluate Product Evaluate Product ComponentsComponents
Assemble and conduct product or product component evaluation using an iterative approach moving from the initial product components through the interim assemblies of product components to the product as a wholeEvaluation includes examining and evaluating the assembled product components for performance, suitability, and readinessEnsure that the actual product evaluation results are compared against the expected resultsVerify and validate assembled and evaluated out product components per the integration and verification strategies
SE Tutorial Sys Thinking - 118version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
SummarySummary
Interface – a point at which independent systems or components meet and act or communicate with each otherInternal Interface – an internal interface resides inside the element of focus, including its terminals, connectors and mediaExternal interface – an external interface to an element will have at least one internal terminal and one external terminal
SE Tutorial Sys Thinking - 119version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Summary Summary -- 22
Integration presents the concepts to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration strategy
The integration plan should identify a sequence for receipt, assembly, and activation of the various components that make up the product
SE Tutorial Sys Thinking - 120version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Tutorial SummaryTutorial Summary
Systems Thinking is a discipline for seeing the wholeAccording to Peter Senge, systems thinking is the fifth discipline “and is the catalyst and cornerstone of the learning organization that enables success through the other four disciplines”:
Personal mastery through proficiency and commitment to lifelong learningShared mental models of the organization’s markets and competitorsShared vision for the future of the organizationTeam learning
SE Tutorial Sys Thinking - 121version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Tutorial Summary Tutorial Summary -- 22
Systems Engineering is a Management TechnologyTechnologyOrganizations that are collections of people concerned with the evolvement and use of technologiesEnvironment
Systems Engineering is concerned with the engineering of systems
Systems engineering methods and tools or technologiesSystems processSystems management
SE Tutorial Sys Thinking - 122version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Tutorial Summary Tutorial Summary -- 33
Systems Engineering is the management technology that controls a total system life-cycle process, which evolves and which results in the definition, development, and deployment of a system that is of high quality, and is cost-effective in meeting the user’s needs
SE Tutorial Sys Thinking - 123version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering Tutorial Summary Tutorial Summary -- 44
Systems Engineering involves:Requirements EngineeringProduct and Project LifecyclesFunctional, Physical and Technical ArchitecturesInterfaces and Product Integration
SE Tutorial Sys Thinking - 124version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems EngineeringSystems EngineeringQuestions and AnswersQuestions and Answers
SE Tutorial Sys Thinking - 125version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Thank YouThank Youようこそ
Wilkommen
Bienvenido
WelKom
Bienvenue
BienvenutoVälkommen
Tervetuloa Witamy
Huan Yín
ЌАΛΟΣΟΡΙΣΑΤΕ
SE Tutorial Sys Thinking - 126version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Kasse InitiativesKasse InitiativesContact InformationContact Information
Kasse Initiatives LLCPMB 2931900 Preston Road, Suite 267Plano, Texas 75093972 – 987 – 7601 Office972 – 987 – 7607 FAXwww.kasseinitiatives.com
SE Tutorial Sys Thinking - 127version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Systems Engineering Systems Engineering ReferencesReferences
SE Tutorial Sys Thinking - 128version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Selected ReadingsSelected Readings
Bate, Roger, et al, “A Systems Engineering Capability Maturity Model”, Version 1.1, Software Engineering Institute, CMU/SEI-95-MM-003
CMMI Development Team, “CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development”, Version 1.02, Continuous Representation, CMI/SEI-2000-TR-031, 2000
EIA-632, “Processes for Engineering a System”, Electronics Industries Alliance, 1998
EIA/IS-731-1, “EIA Systems Engineering Capability Model”, Electronic Industries Alliance / Interim Standard, 1998
SE Tutorial Sys Thinking - 129version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Selected Readings Selected Readings -- 22
Frank, Moti, Engineering Systems Thinking and Systems Thinking, Systems Engineering, Vol 3, No. 3, John Wiley & Sons, 2000Kasse, Tim, CMMI Workshop, Kasse Initiatives LLC, 2000
Maier, Mark W., Rechtin, Eberhardt, The Art of Systems Architecting, CRC Press, 2000
Sage, Andrew P., Lynch, Charles L., Systems Integration and Architecting: An Overview of Principles, Practices, and Perspectives, John Wiley & Sons, 1998
SE Tutorial Sys Thinking - 130version SEPG 2004 Conf © 2004 Kasse Initiatives, LLC
Selected Readings Selected Readings -- 33
Sage, Andrew P., Rouse, William B., Handbook of Systems Engineering and Management, John Wiley & Sons, 1999
Recommended