Systems Engineeringand Design 3B

Module: 1

The Systems Engineering Introduction

The Design Process

2

It is impossible to fully cover and explain every detail of all the differentsystems analysis and design tools, techniques, principles, andmethodologies in a single course.

We will rely on Paretos 80 : 20 rule.

For most the knowledge of a relatively small subset (20%) of theunderlying concepts and terminology is sufficient to understand the lionsshare (80%) of the topics functionality.

The objective is to explain that crucial 20%.

Course strategy.

"Education helps one cease being intimidatedby strange situations." Maya Angelou

The Design Process

3

"Imagination is more important than knowledge.Knowledge is limited. Imagination encircles the world." Albert Einstein

Your value as an Engineer is measured by the size of the problems youare willing to undertake.

- Dr John Tibane motivational speaker

Course strategy.

The Design Process

4

What is the difference between:

High performance superCar engineering

Prostitution

The Design Process

5

Let us look at the common points:

High performance super vs ProstitutionCar engineering

Produce pleasure

May become additive

Marketed by advertising of high performance features

Additional safety devices required for safe operation

Can be lethal

Create a sense of false empowerment to user

Can destroy moral values (entices to break commitments)

The Design Process

6

Unless the engineer is practicing histrade for the benefit and uplift mend ofsociety his trade is not much different toprostitution.

The Design Process

7

Finding the optimal peg for the right hole.

Unless we know what the hole looks like wewill not recognise when the peg fits

The Problem

The Solution

The Design Process

8

The Basic Design Process

The Design Process

9

Systems Engineering is the method forapplying the Design Process toengineering projects.

The Engineering Domains

10

The ProblemDomain

The SolutionDomain

The ImplementationDomain

The ManagementDomain

The Problem Domain

11

The ProblemDomain

In the problem domain the user/client expresses a specific need orwant.The problem domain contains the user needs/wants and theenvironment of the potential solutions.

What must the solution be capable of doing to be considered as asolution?

What must the solution not be capable of doing to be consideredas a solution?

What are the interfaces of the solution? What must the solution attributes be to be considered as a

solution?

A statement of What is to be doneDefine the hole

The Solution Domain

12

The SolutionDomain

In the problem domain the user/client expresses a specific need orwant.The problem domain contains the user needs/wants and theenvironment of the potential solutions.

How will the solution function? How will the solution not function? Constraints, Limitations How will the solution domain interface to the problem domain?

An statement of How it is to be doneDefine the peg

The Implementation Domain

13

The ImplementationDomain

TBD

The manufacturing of the solution

The Management Domain

14

The ManagementDomain

Project Management Technical Management

The managing the solution

The Problem Domain

15

AgreementProcesses

User GoalsDocument

Users needs/wantsUsers Constraints Budgetary Financial Time Technology Others

RequirementsEngineeringProcesses

UserRequirementSpecification

UserAcceptanceProcedure

UserOperationalDescription

User Goals Document All stakeholders

requirements Legal requirements Regulatory

requirements Environmental

requirements

What is to be done

Input Process Output

What is to be done

DesignProcess

The Solution Domain

16

RequirementsEngineeringProcesses

SystemDevelopmentSpecification

SystemArchitectureDiagram

SystemInterfaceControlDocument

SystemAcceptanceProcedure

SystemOperationalDescription

User RequirementSpecification

What is to be done

Input Process Output

How it is to be done

DesignProcess

The Implementation Domain

17

RequirementsEngineeringProcesses

SubSystem /ComponentDevelopmentSpecification

Sub-System /ComponentInterfaceControlDocument

Sub-System /ComponentAcceptanceProcedure

System DevelopmentSpecification

System ArchitectureDiagram

System InterfaceControl Document

System AcceptanceProcedure

System OperationalDescription

What is to be done

Input Process Output

How it is to be done

DesignProcess

The Management Domain

18

EngineeringProcesses

SystemsEngineeringManagement Plan

Verification andValidation Plan

ConfigurationManagement Plan

Risk ManagementPlan

Qualification andCertificationManagement Plan

Contract

What is to be done

Input Process Output

How it is to be done

The SE Process

19

Slide Number 1Slide Number 2Slide Number 3Slide Number 4Slide Number 5Slide Number 6Slide Number 7Slide Number 8Slide Number 9Slide Number 10Slide Number 11Slide Number 12Slide Number 13Slide Number 14Slide Number 15Slide Number 16Slide Number 17Slide Number 18Slide Number 19