Engineering Systems Thinking - ITQ | IT Quality Group ...itq.ch/pdf/systemengineering/Systems...

130
Systems Engineering Systems Engineering Tutorial Tutorial SEPG Conference March 2004 Orlando, Florida

Transcript of Engineering Systems Thinking - ITQ | IT Quality Group ...itq.ch/pdf/systemengineering/Systems...

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