Lecture Requirements Engineering · Lecture Requirements Engineering by Gerrit Muller University of South-Eastern Norway-NISE e-mail: [email protected] ... of key drivers and story

Lecture Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE

e-mail: [email protected]

Abstract

This article describes the Requirements Engineering session part of the SoftwareEngineering block in the OOTI curriculum of the Technical University Eindhoven.The focus of this course is on capturing and managing requirements. The notionof key drivers and story telling will be introduced as a means to capture andmanage. During the course an exercise is used based on video distribution viasatellite. The students have to elicit the requirements for the required systems,working in teams of 4 students. Every student writes an individual report aboutthe exercise.

Distribution

This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.

September 9, 2018status: finishedversion: 1.1

block 2; actual current case of OOTI education

block 1; teacher provides case

What are requirements, black box, SMART

Customer and Application view, Story telling

Financial viewpoint, Presentation to management

Discussion of requirement specification per team

Documentation How-to Coaching and discussion

Presentation project case to management team

homework: make requirement specification

homework: improve requirement specification

homework: make presentation outline

homework: make presentation

1/2 day

1/2 day

1/2 day

1/2 day

1/2 day

1/2 day

individual report

Program

time subject

Session 1 What are requirements, black box, SMART

Session 2 Customer and Application view, Story telling

Session 3 Discussion of requirement specification per team

Session 4 Financial viewpoint, Presentation to management

Session 5 Documentation How-to, Coaching and discussion session

Session 6 Presentation of project case to management team

Lecture Requirements Engineering2 Gerrit Muller

version: 1.1September 9, 2018

OOTICprogramTable

Schedule

block 2; actual current case of OOTI education

block 1; teacher provides case

What are requirements, black box, SMART

Customer and Application view, Story telling

Financial viewpoint, Presentation to management

Discussion of requirement specification per team

Documentation How-to Coaching and discussion

Presentation project case to management team

homework: make requirement specification

homework: improve requirement specification

homework: make presentation outline

homework: make presentation

1/2 day

1/2 day

1/2 day

1/2 day

1/2 day

1/2 day

individual report



OOTICschedule

Case Instructions

1. Block 1 session 1: Make an initial requirements specification2. Block 1 session 2: Improve and complete requirements specification3. Block 2 session 4: Make an outline of a presentation of maximum 10 minutes,

target audience: management team of your company4. Block 2 session 5: Prepare and exercise presentation5. Block 2 session 6: Write an individual report reflecting on: requirement speci-

fication, management presentation, lessons learned and how to do it nexttime.



OOTICcaseInstructionList

Case: Recommended Steps

1. Make a black box view of the system

2. Make some initial drafts and designs to explore the problem.

3. Make a story which helps to understand the products, make sure to use thecriterions for a story.

4. Look from all stakeholder points of view towards the problem and identify whatthey need and what they expect.

5. Analyze the information obtained so far and extract the underlying require-ments.

6. Abstract the key drivers behind the requirements.

7. Make a top-down description of the requirements.



OOTICcaseListOfSteps

Case: Questions for Individual Report

• What are the most important lessons you learned from these exercise(requirement specification, management presentation)?

• Which roles did the members of the group play during the exercise?• How would you approach such a problem the next time?• Which stakeholders understand your group presentation? Are they happy

with the presentation?



OOTICcaseIndividualQuestions

Submission of Homework

Homework instructions

specification minimum 4 hours work/person, maximum 8 hours

maximum 6 A4 pages

presentation minimum 2 days work/ person, maximum 5 days

filename: [OOTI<year>] spec|presentation <team id>.<version number>

e.g. [OOTI2008] spec team1.1.doc

all team members on front page

email to:

subject: [OOTI<year>] spec|presentation <team id>

from/cc: <all email addresses of team members>

when: 48 hours before next lecture

<gerrit muller gmail com>



OOTIChomeworkInstructions

Module Requirementsby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

This module addresses requirements: What are requirements? How to find,select, and consolidate requirements?

Distribution


September 9, 2018status: conceptversion: 1.4

Fundamentals of Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Requirements engineering is one of the systems engineering pillars. In thisdocument we discuss the fundamentals of systems engineering, such as thetransformation of needs into specification, the need to prescribe what rather thanhow, and the requirements when writing requirements.

Distribution



system seen as black box

inputs outputsfunctions

quantified characteristics

restrictions, prerequisites

boundaries, exceptions

standards, regulations

interfaces

Definition of “Requirement”

Requirements describing the needs of the customer:

Customer Needs

Requirements describing the needs of the company

itself over the life cycle: Life Cycle Needs

Requirements describing the characteristics of the

final resulting product: Product Specification

The requirements management process recursively

applies definition 2 for every level of decomposition.

Fundamentals of Requirements Engineering10 Gerrit Muller


REQdefinition

Flow of Requirements

What

What

How

customer needs:

What is needed by the customer?

product specification:

What are we going to realize?

system design:

How are we going to realize the product?

What

How

What

How

What

How

What are the subsystems we will realize?

How will the subsystems be realized?

What

How

What

How

What

How

What

How

What

How

What

How

up to "atomic" components

choices

trade-offs

negotiations


version: 0.1September 9, 2018REQwhatWhatHow

System as a Black Box

system seen as black box

inputs outputsfunctions

quantified characteristics

restrictions, prerequisites

boundaries, exceptions

standards, regulations

interfaces



REQsystemAsBlackBox

Stakeholders w.r.t. Requirements

Policy and Planning

(business, marketing,

operational managers)

customer

(purchaser, decision maker, user, operator, maintainer)

company

Product Creation Process

(project leader, product

manager, engineers, suppliers)

Customer-Oriented Process

(sales, service, production,

logistics)

People, Process, and Technology management process

(capability managers, technology suppliers)



REQstakeholders

The “Formal” Requirements for Requirements

Specific

Unambiguous

Verifiable

Quantifiable

Measurable

Complete

Traceable



REQrequirementsForRequirementsList

The Requirements to Enable Human Use

Accessible

Understandable

Low threshold



REQrequirementsFromHumans

Short introduction to basic “CAFCR” modelby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The basic “CAFCR” reference model is described, which is used to describea system in relation to its context. The main stakeholder in the context is thecustomer. The question “Who is the customer?” is addressed.

Distribution


September 9, 2018status: draftversion: 0.4

Customer

What

Customer

How

Product

What

Product

How

What does Customer need

in Product and Why?

drives, justifies, needs

enables, supports

Customer

objectives

Application Functional Conceptual Realization

The “CAFCR” model

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

drives, justifies, needs

enables, supports

Customer

objectives


Short introduction to basic “CAFCR” model17 Gerrit Muller


CAFCRannotated

Integrating CAFCR

Customer

objectives


intention

constraintawareness

objectivedriven

contextunderstanding

oppor-tunities

knowledgebased

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?



MSintegratingCAFCR

CAFCR can be applied recursively

System

(producer)

Customer

BusinessDrives

Enables

Customer's

Customer

BusinessDrives

Enables

ConsumerDrives

Enables

Value Chain

larger scope has smaller

influence on architecture



CAFCRrecursion

Market segmentation

geographical

business model profit, non profit

examples

economics

USA, UK, Germany, Japan, China

high end versus cost constrained

consumers youth, elderly

segmentation

axis

outlet retailer, provider, OEM, consumer direct



BCAFCRcustomerSegmentation

Example of a small buying organization

decision maker(s) purchaser

maintainer

operator

user

CEO

CFO

CTO

CIO

department head

Who is the customer?

CMO

CEO: Chief Executive Officer

CFO: Chief Financial Officer

CIO: Chief Information Officer

CMO: Chief Marketing Officer

CTO: Chief Technology Officer



BCAFCRwhoIsTheCustomer

CAFCR+ model; Life Cycle View

Customer

objectives


Life cycleoperations

maintenance

upgrades

development

manufacturing

installation

sales, service, logistics, production, R&D



BCAFCRplusLifeCycle

Key Drivers How Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The notion of ”business key drivers” is introduced and a method is described tolink these key drivers to the product specification.

Distribution



Safety

Effective

Flow

Smooth

Operation

Environment

Reduce accident rates

Enforce law

Improve emergency

response

Reduce delay due to accident

Improve average speed

Improve total network throughput

Optimize road surface

Speed up target groups

Anticipate on future traffic condition

Ensure traceability

Ensure proper alarm handling

Ensure system health and fault indication

Reduce emissions

Early hazard detection

with warning and signaling

Maintain safe road

condition

Classify and track dangerous

goods vehicles

Detect and warn

noncompliant vehicles

Enforce speed compliance

Enforce red light compliance

Enforce weight compliance

Key-drivers Derived application drivers Requirements

Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition

dependent speed control

Traffic speed and

density measurement

Note: the graph is only partially elaborated

for application drivers and requirements

Cameras

Example Motorway Management Analysis

Safety

Effective

Flow

Smooth

Operation

Environment


Enforce law

Improve emergency

response







Ensure traceability



Reduce emissions



Maintain safe road

condition


goods vehicles

Detect and warn






Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition


Traffic speed and

density measurement



Cameras

Key Drivers How To24 Gerrit Muller


COVmotorwayManagementKeyDrivers

Method to create Key Driver Graph

• Build a graph of relations between drivers and requirements

by means of brainstorming and discussions

• Define the scope specific. in terms of stakeholder or market segments

• Acquire and analyze facts extract facts from the product specification

and ask why questions about the specification of existing products.

• Iterate many times increased understanding often triggers the move of issues

from driver to requirement or vice versa and rephrasing

where requirements

may have multiple drivers

• Obtain feedback discuss with customers, observe their reactions



TCAFkeyDriverSubmethod

Recommendation for the Definition of Key Drivers

• Use short names, recognized by the customer.

• Limit the number of key-drivers minimal 3, maximal 6

for instance the well-known main function of the product• Don’t leave out the obvious key-drivers

for instance replace “ease of use” by

“minimal number of actions for experienced users”,

or “efficiency” by “integral cost per patient”

• Use market-/customer- specific names, no generic names

• Do not worry about the exact boundary between

Customer Objective and Applicationcreate clear goal means relations



TCAFkeyDriverRecommendations

Transformation of Key Drivers into Requirements

Key

(Customer)

Drivers

Derived

Application

Drivers

Requirements

Customer

What

Customer

How

Product

What

Customer

objectives

Application Functional

goal means

may be skipped or

articulated by several

intermediate steps

functions

interfaces

performance figures



REQfromDriverToRequirement

Requirements Elicitation and Selectionby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

An elicitation method for needs is described using many different viewpoints. Aselection process with a coarse and a fine selection is described to reduce thespecification to an acceptable and feasible subset.

Distribution


September 9, 2018status: draftversion: 0 bottom-up

top-down

key-drivers(customer, business)

roadmap(positioning and trends in time)

competition(positioning in the market)

"ideal" reference design

prototyping, simulation(learning vehicle)

bottom-up(technological opportunities)

existing systems

operational drivers(logistics, production, etc.)

NeedsContinued

Product Creation

Process

Feedback

regulations

Complementary Viewpoints to Capture Requirements

bottom-up

top-down







existing systems


NeedsContinued

Product Creation

Process

Feedback

regulations

Requirements Elicitation and Selection29 Gerrit Muller

version: 0September 9, 2018

REQviewpoints

Requirement Selection Process

customer needs

operational needs

roadmap

strategy

competition

selection process

product specification

need

characterization

requirement

phasing

Technology, People, Process

costs and constraints



REQselection

Simple Qualification Method

important

urgent

effort

value

do

don't discuss

discuss

do

don't discuss

discuss



REQqualitativeSelectionMatrix

Examples of Quantifiable Aspects

• Value for the customer

• (dis)satisfaction level for the customer

• Selling value (How much is the customer willing to pay?)

• Level of differentiation w.r.t. the competition

• Impact on the market share

• Impact on the profit margin

Use relative scale, e.g. 1..5 1=low value, 5 -high value

Ask several knowledgeable people to score

Discussion provides insight (don't fall in spreadsheet trap)


version: 0September 9, 2018MPBAvalueCriteria

Exercise Requirements Capturing

• Determine the key drivers for one particular product family.• Translate these drivers into application drivers and derive from them the

requirements.

Exercise Requirements Capturing33 Gerrit Muller


MREQexercise

Needs and Requirements

Needs, Specification, RequirementsRequirements describing the needs of the customer:

Customer Needs

Requirements describing the needs of the company

itself over the life cycle: Life Cycle Needs

Requirements describing the characteristics of the

final resulting product: Product Specification

The requirements management process recursively

applies definition 2 for every level of decomposition.

Flow of RequirementsWhat

What

How

customer needs:

What is needed by the customer?

product specification:

What are we going to realize?

system design:

How are we going to realize the product?

What

How

What

How

What

How

What are the subsystems we will realize?

How will the subsystems be realized?

What

How

What

How

What

How

What

How

What

How

What

How

up to "atomic" components

choices

trade-offs

negotiations

Requirements for Requirements

Specific

Unambiguous

Verifiable

Quantifiable

Measurable

Complete

Traceable

Enable Human Use

Accessible

Understandable

Low threshold



CAFCR, Customer Key Driver Graph

CAFCR+ ModelCustomer

objectives


Life cycleoperations

maintenance

upgrades

development

manufacturing

installation

sales, service, logistics, production, R&D

Iterate over Views

Customer

objectives


intention

constraintawareness

objectivedriven

contextunderstanding

oppor-tunities

knowledgebased

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

Example Key Driver Graph

Safety

Effective

Flow

Smooth

Operation

Environment


Enforce law

Improve emergency

response







Ensure traceability



Reduce emissions



Maintain safe road

condition


goods vehicles

Detect and warn






Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition


Traffic speed and

density measurement



Cameras

Complementary Viewpoints

bottom-up

top-down







existing systems


NeedsContinued

Product Creation

Process

Feedback

regulations



Story How Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

A story is an easily accessible story or narrative to make an application live. Agood story is highly specific and articulated entirely in the problem domain: thenative world of the users. An important function of a story is to enable specific(quantified, relevant, explicit) discussions.

Distribution



Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

story caseanalyze

design

designanalyze

design

a priori solution knowledgemarket

vision

Customer

objectives


From story to design

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

story caseanalyze

design

designanalyze

design

a priori solution knowledgemarket

vision

Customer

objectives


Story How To37 Gerrit Muller


SHTfromStoryToDesign

Example story layout

A day in the life of Bob

bla blah bla, rabarber music

bla bla composer bla bla

qwwwety30 zeps.

nja nja njet njippie est quo

vadis? Pjotr jaleski bla bla

bla brree fgfg gsg hgrg

mjmm bas engel heeft een

interressant excuus, lex stelt

voor om vanavond door te

werken.

In the middle of the night he

is awake and decides to

change the world forever.

The next hour the great

event takes place:

This brilliant invention will change the world foreverbecause it is so unique and

valuable that nobody beliefs the feasibility. It is great and WOW at the same time,

highly exciting.

Vtables are seen as the soltution for an indirection problem. The invention of Bob will

obsolete all of this in one incredibke move, which will make him famous forever.

He opens his PDA, logs in and enters his provate secure unqiue non trivial password,

followed by a thorough authentication. The PDA asks for the fingerprint of this little left

toe and to pronounce the word shit. After passing this test Bob can continue.

draft or sketch of

some essential

applianceca. half a page of

plain English text

Yes

or

No

that is the question



SHTexampleStoryLayout

Points of attention

• purpose

• scope

• viewpoint, stakeholders

• visualization

• size (max 1 A4)

• recursive decomposition, refinement

What do you need to know for

specification and design?

“umbrella” or specific event?

Define your stakeholder and viewpoint

f.i. user, maintainer, installer

Sketches or cartoon

Helps to share and communicate ideas

Can be read or told in few minutes


version: 1.2September 9, 2018SHTattentionPoints

Criteria for a good story

• accessible, understandable

• valuable, appealing

• critical, challenging

• frequent, no exceptional niche

• specific

"Do you see it in front of you?"

attractive, important

"Are customers queuing up for this?"

"What is difficult in the realization?"

"What do you learn w.r.t. the design?"

names, ages, amounts, durations, titles, ...

"Does it add significantly to the bottom line?"

Customer

objectives

Application

Functional

Conceptual

Realization

Customer

objectives

Application

Application

Application



SHTcriterionsList

Example of a story

Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed

away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,

come and visit her every weekend, often with Betty’s grandchildren Ashley and Christopher.

As so many women of her age, Betty is reluctant to touch anything that has a technical

appearance. She knows how to operate her television, but a VCR or even a DVD player is

way to complex.

When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy

environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of

the frequency spectrum shows a loss of about 45dB. This is why she had problems

understanding her grandchildren and why her children urged her to apply for hearing aids two

years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing

aids’ batteries. Fortunately her children can do this every weekend.

This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folk’s

home. It’s summer now and the tables are outside. With all those people there it’s a lot of

chatter and babble. Two years ago Betty would never go to the bingo: “I cannot hear a thing

when everyone babbles and clatters with the coffee cups. How can I hear the winning

numbers?!”. Now that she has her new digital hearing instruments, even in the bingo

cacophony, she can understand everyone she looks at. Her social life has improved a lot and

she even won the bingo a few times.

That same night, together with her friend Janet, she attends Mozart’s opera The Magic Flute.

Two years earlier this would have been one big low rumbly mess, but now she even hears the

sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol also

has hearing aids, however hers only “work well” in normal conversations. “When I hear music

it’s as if a butcher’s knife cuts through my head. It’s way too sharp!”. So Carol prefers to take

her hearing aids out, missing most of the fun. Betty is so happy that her hearing instruments

simply know where they are and adapt to their environment.

source: Roland Mathijssen

Embedded Systems Institute

Eindhoven



SHTexample

Value and Challenges in this story

Challenges in this story:

Intelligent hearing instrument

Battery life at least 1 week

No buttons or other fancy user interface on the hearing instrument,

other than a robust On/Off method

The user does not want a technical device but a solution for a problem

Instrument can be adapted to the hearing loss of the user

Directional sensitivity (to prevent the so-called cocktail party effect)

Recognition of sound environments and automatic adaptation (adaptive

filtering)

source: Roland Mathijssen, Embedded Systems Institute, Eindhoven

Conceptual

Realization

Customer

objectives

Application

Value proposition in this story:

quality of life:

active participation in different social settings

usability for nontechnical elderly people:

"intelligent" system is simple to use

loading of batteries



SHTexampleCriteria

Module Management Presentationby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

This module addresses the presentation of architectural issues to highermanagement teams.

Distribution



Simplistic Financial Computations for System Architects.by Gerrit Muller University of South-Eastern Norway-NISE


Abstract

This document explains how simple financial estimates can be made by systemarchitects. These simplistic estimates are useful for an architect to performsanity checks on proposals and to obtain understanding of the financial impactof proposals. Note that architects will never have full fledged financial controllerknow how and skills. These estimates are zero order models, but real businessdecisions will have to be founded on more substantial financial proposals.

Distribution


September 9, 2018status: preliminarydraftversion: 1.3

sales volumein units

$

income

expenses

break even

point

profit

expected

sales volume

fixe

d c

ost

s

variable

Product Margin = Sales Price - Cost

material

labour

miscellaneous

margin

cost

pri

ce

sale

s p

rice

Cost per product,

excluding fixed costs

Margin per product.

The margin over the sales volume,

must cover the fixed costs, and generate profittransportation, insurance,

royalties per product, ...

purchase price of components may cover

development cost of supplier

retailer margin

and costs

stre

et p

rice

Simplistic Financial Computations for System Architects.45 Gerrit Muller


SFCmargin

Profit as function of sales volume


$

income

expenses

break even

point

profit

expected

sales volume

fixe

d c

ost

s

variable



SFCprofitAndSalesVolume

Investments, more than R&D

research and development

NRE: outsourcing, royalties

marketing, sales

training sales&service

financing

including:

staff, training, tools, housing

materials, prototypes

overhead

certification

strategic choice:

NRE or per product

business dependent:

pharmaceutics industry

sales cost >> R&D cost

often a standard staffing rate is used

that covers most costs above:

R&D investment = Effort * rate



SFCinvestments

Income, more than product sales only

products

options,

accessories

other recurring

income

services

sales priceoption * volumeoption

sales priceproduct * volume product

incomeservice

options

services

content, portal

updates

maintenance

license fees

pay per movie



SFCincome

The Time Dimension

Q1

100k$

-

-

-

(100k$)

(100k$)

investments

sales volume (units)

material & labour costs

income

quarter profit (loss)

cumulative profit

Q3

20k$

30

600k$

1500k$

880k$

1480k$

Q2

60k$

30

600k$

1500k$

840k$

600k$

Q1

100k$

20

400k$

1000k$

500k$

(240k$)

Q4

100k$

10

200k$

500k$

200k$

(740k$)

Q3

500k$

2

40k$

100k$

(440k$)

(940k$)

Q2

400k$

-

-

-

(400k$)

(500k$)

cost price / unit = 20k$

sales price / unit = 50k$

variable cost = sales volume * cost price / unit

income = sales volume * sales price / unit

quarter profit = income - (investments + variable costs)



SFCtiming

The “Hockey” Stick

profit

loss

time

(1M$)

(0.5M$)

0.5M$

1M$



SFChockeyStick

What if ...?

profit

loss

time

(1M$)

(0.5M$)

0.5M$

1M$delay of 3 months

early more expensive

product + follow-on

original model



SFChockeyStickWhatIf

Stacking Multiple Developments

-2

-1

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8 9 10 11 12 13 14

cumulative 1

cumulative 2

cumulative 3

cumulative 4

cumulative total

M€

quarter



SFCmultipleDevelopments

Fashionable financial yardsticks

Return On Investments (ROI)

Net Present Value

Return On Net Assets (RONA)

turnover / fte

market ranking (share, growth)

R&D investment / sales

cash-flow

leasing reduces assets, improves RONA

outsourcing reduces headcount, improves this ratio

"only numbers 1, 2 and 3 will be profitable"

in high tech segments 10% or more

fast growing companies combine profits with negative cash-flow,

risk of bankruptcy



SFCyardsticks

How to present architecture issues to higher managementby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Architects struggle with their visibility at higher management echelons. Theintrovert nature of architects is a severe handicap. Participation of architectsin management teams is important for balanced technical sound decisions andstrategy. Improved managerial communication skills of architects are required.This article describes how to give a more effective presentation to highermanagement teams. Subjects discussed are the preparation, content and form,do and don’t advise.

Distribution



Market drivers Options Typical performance

Bill of material Schedule

Power budget

fte's profit-investment

Operating principle worst-case performance

Power details

cost ttm wow DRM

integration multiple suppliers nifty features fashionable design Hollywood pact standards

MPEG4 MP3 color display ePen GPS sensor GSM UTMS BT 802.11b

A B A B

load

trans

fer/s

ec

infra sensor display power total

A B

7 6

20 3

36

8 8

17 4

37

302 304 310 318 326

A

302 304 308 322 326

B

330


A B

7 6

20 3

36

8 8

17 4

37

infra control display appl total

A B

2 6 6 3

17

8 4 8 3

23

salesprice cost/p units sales costs investment profit

A B

10M 3M 2M 5M

10 3

1M 10M

4M 3M 3M

10 4

1M

A B

load

trans

fer/s

ec


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37

backup material

recommendation recommendation:

select A

follow up: allocate Jan, Piet, Klaas

per 1/11 go/nogo 1/1/03

mention the red information only

Architectural issues related to managerial viewpoints

management

technology

market organizational

! issues

logistics

financial

How to present architecture issues to higher management55 Gerrit Muller


AMIintroduction

Characteristics of managers in higher management teams

common characteristics

+ action-oriented

+ solution rather than problem

+ impatient, busy

+ want facts not beliefs

+ operate in a political context + bottom-line oriented:

profit, return on investment, market share, etc.

highly variable characteristics

? technology knowledge from extensive to shallow

? style from power play to inspirational leadership



AMImanagementCharacteristics

How to prepare

content

+ gather facts

+ perform analysis

+ identify goal and message

+ make presentation

+ polish presentation form

understand audience

+ gather audience background

+ analysis audience interests

+ identify expected responses

+ simulate audience, exercise presentation

mutual interaction

Always prepare with small team!

70% of effort

30% of effort



AMIpreparation

Recommended content

+ clear problem statement (what, why)

+ solution exploration (how)

+ options, recommendations

+ expected actions or decisions

supported by facts and figures



AMIcontent

Mentioned info, shown info and backup info



Power budget



Power details

cost ttm wow DRM



A B A B

load

trans

fer/s

ec


A B

7 6

20 3

36

8 8

17 4

37

302 304 310 318 326

A

302 304 308 322 326

B

330


A B

7 6

20 3

36

8 8

17 4

37


A B

2 6 6 3

17

8 4 8 3

23


A B

10M 3M 2M 5M

10 3

1M 10M

4M 3M 3M

10 4

1M

A B

load

trans

fer/s

ec


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37

backup material


select A


per 1/11 go/nogo 1/1/03




AMIinfoTypes

Form is important

presentation material

+ professional

+ moderate use of color and animations

+ readable

+ use demos and show artifacts but stay yourself, stay authentic

presenter's appearance

+ well dressed

+ self confident but open

poor form can easily distract from purpose and content



AMIform

Don’t force your opinion, understand the audience

do not do

- preach beliefs + quantify, show figures and facts

- underestimate technology knowledge of managers

+ create faith in your knowledge

- tell them what they did wrong + focus on objectives

- oversell + manage expectations



AMIdoAndDont

How to cope with managerial dominance

do not do

- let one of the managers hijack the meeting

+ maintain the lead

- build up tensions by withholding facts or solutions

+ be to the point and direct

- be lost or panic at unexpected inputs or alternatives

+ acknowledge input, indicate consequences (facts based)



AMIdoAndDontMore

Exercise presentation to higher management

+ Bring a clear architecture message to

+ a Management team at least 2 hierarchical levels higher

+ with 10 minutes for presentation including discussion (no limitation on number of slides)

* architecture message = technology options in relation with market/product

* address the concerns of the management stakeholders : translation required from technology issues into business consequences (months, fte's, turnover, profit, investments)



AMIexercise

Exercise schedule

prepare in team of 4 1 2 1 2

present and discuss feedback

3 4 3 4

13:30 17:00 14:00 15:00 16:00



AMIexerciseSchedule

Simplistic Financial Computations

Product Margin = Sales Price - Cost

material

labour

miscellaneous

margin

cost

pri

ce

sale

s p

rice

Cost per product,

excluding fixed costs

Margin per product.

The margin over the sales volume,

must cover the fixed costs, and generate profittransportation, insurance,

royalties per product, ...

purchase price of components may cover

development cost of supplier

retailer margin

and costs

stre

et p

rice

Profit as function of sales volume


$

income

expenses

break even

point

profit

expected

sales volume

fixe

d c

ost

s

variable

Hockey stick and scenarios

profit

loss

time

(1M$)

(0.5M$)

0.5M$

1M$delay of 3 months

early more expensive

product + follow-on

original model

intentionally left blank

Summary Module Management Presentation65 Gerrit Muller


Presentation to Management

Managerial Viewpointsmanagement

technology

market organizational

! issues

logistics

financial

Prepare Content, Understand Audience

content

+ gather facts

+ perform analysis

+ identify goal and message

+ make presentation

+ polish presentation form

understand audience

+ gather audience background

+ analysis audience interests

+ identify expected responses

+ simulate audience, exercise presentation

mutual interaction

Always prepare with small team!

70% of effort

30% of effort

Show underlying info



Power budget



Power details

cost ttm wow DRM



A B A B

load

trans

fer/s

ec


A B

7 6

20 3

36

8 8

17 4

37

302 304 310 318 326

A

302 304 308 322 326

B

330


A B

7 6

20 3

36

8 8

17 4

37


A B

2 6 6 3

17

8 4 8 3

23


A B

10M 3M 2M 5M

10 3

1M 10M

4M 3M 3M

10 4

1M

A B

load

trans

fer/s

ec


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37


A B 7 6

20 3

36

8 8

17 4

37

backup material


select A


per 1/11 go/nogo 1/1/03


Form, do and do not

presentation material

+ professional

+ moderate use of color and animations

+ readable

+ use demos and show artifacts but stay yourself, stay authentic

presenter's appearance

+ well dressed

+ self confident but open

poor form can easily distract from purpose and content

Summary Module Management Presentation66 Gerrit Muller


Module Supporting Processesby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

This module addresses supporting processes, for instance documentation,templates, and reviewing.

Distribution



Granularity of Documentationby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The design of documentation is discussed, with emphasis on the requirements,the need for decomposition, the measures needed to maintain overview andcriteria for granularity.

Distribution



compound document

document

structure

overview

document

document

document

document

document

Requirements for the Entire Documentation Structure

Accessibility for the readers

Low threshold for the readers

Low threshold for the authors

Completeness

Consistency

Maintainability

Scalability

Evolvability

Process to ensure the quality of the information

Granularity of Documentation69 Gerrit Muller


DGrequirementsStructure

Requirements from Reader Point of View

Convenient

viewing

printing

searching

easy

fast



DGrequirementsReader

Requirements per Document

High cohesion (within the unit)

Low coupling (outside of the unit)


Low threshold for the reader

Low threshold for the author

Manageable steps to create, review, and change

Clear responsibilities

Clear position and relation with the context

Well-defined status of the information

Timely availability



DGrequirementsUnit

Accessibility Requirements

Ease of reading, “juiciness”

High signal-to-noise ratio: information should not be hidden in a

sea of words.

Understandability

Reachability in different ways, e.g., by hierarchical or full search

Reachability in a limited number of steps



DGrequirementsAccessibility

Responsibility Requirements

single author

limited amount of reviewers



DGrequirementsResponsibility

Scalability Requirements

well defined documentation structure

overview specifications at higher

aggregation levels

recursive application of structure and

overview

delegation of review process



DGrequirementsScalability

The Stakeholders of a Single Document

specification

implementation

des

crib

es

author

producerconsumer

context

interacts with

inte

ract

s with

architect

or editor

is responsible

for technical

Project

leader

is responsiblefor time, budget, result

others

writes

uses realizesstake-

holder

artifact

relation

legend



DGdocumentationRoles

Decomposition of Large Documents

compound document

document

structure

overview

document

document

document

document

document



DGcompoundDocument

Documentation Tree by Recursive Decomposition

compound document

compound

document

compound

document compound document

overview

document

structure

overview

atomic

documentdocument

structure

overview

document

structure

overview

document

structure

atomic

document

atomic

document

compound

document

compound

document



DGdocumentRecursion

Payload: the Ratio between Content and Overhead

title

identification

author

distribution

status

review

history

changes

front page

meta information

max 2 pages

diagrams

tables

lists

and ca 50%

text

1. aap

2. noot

3. mies

contents

2..18 pages



DGpayload

LEAN and A3 Approach to Supporting Processesby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

LEAN product development is in the process and means area pragmatic. Lowtech tools, such as paper, pen and magnets, with very direct interaction are used.For communication the use of single A3-size documents is promoted, becausethis is a manageable amount of information.

Distribution



A3 architecture overview of the Metal Printer (all numbers have been removed for competitive sensitivity)

process steps

metal printing cell

Fluidic

subsystem

chamber

bottom chuck

electronics

infrastructure

process

power

supply

1

3

2

4

5electronics

infrastructure1 5granite

ZUBA

stage

frame

base frame +

x, y, stage

stage

control

ZUBA

control

optics

stagescoop

cameravision

op

tics s

tag

e

co

ntr

ol

vision

control

6

7

8

9

1

0

cabling

covers and

hatches

ventilation

air flow

contamination

evacuation

sensors

measurement

frame

machine

control

"remote"

electronics rack

10

11

12

13

14

15

?

metal printer back side metal printer front sideintegrating

subsystems

metal printer subsystems

tprepare

= tclose doors

+ tmove to proximity

tprint

= tp,prepare

+ tp,align

+ tchamber

(thickness) + tp,finalize

tfinalize

= tmove to unload

+ topen doors

tprint

= tp,overhead

+ Ctransfer

*thickness

2. Align

3. Move to proximity

4. Process

6. Open doors

1. Close doors

5. Move substrate unloading position

talign

tchamber

note: original diagram was annotated with actual performance figures

for confidentiality reasons these numbers have been removed

metal printer

functional flow formula print cycle time

key performance parameters

metal printer subsystems, functions, and cycle time model

metal printing cell: systems and performance model

back-end factory: systems and process model

pattern quality

cost per layer

environmental

impact

design enablinge.g. CD, separation

pattern

resolution

X-section control

accuracy overlay

high MTBF

early delivery

vs

volume production

uptime

throughput

operational

costs

system cost

electric power

clean water

elyte

N2, air

disposal water, air, ...

reliability

integral costs

consumables

waste

contamination

and climate

partial graph

many nodes

and connections

are not shown

customer key drivers

Customer key-drivers and Key Performance Parameters

Document meta-information

author

version

date last update

scope

statusGerrit Muller

0.1

August 3, 2010

system and supersystem

preliminary draft

metal printing time-line

min. line width

overlay

throughput

MTBF

a m

b m

c WPH

d hr

wafer size

power

clean room class

floor vibration class

200, 300 mm

x kW

throughput

1. inspection

2. seed sputter

3. metal print

4. seed etch

wafer

waferseed

wafer

Cu

wafer

5. coat/develop dielectricswafer

6. exposure or CMP for polymer viaswafer

7. E-test

spin coated

polymer

per waferthroughput in minutes

1

t

1

3..4

1..2

dual layer only

robot

prefill

master

FOUP

wafer

FOUP

wafer

FOUPflip

prealignclean

wafer

clean

master

metal

printer

print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b

wafer

with

ICs

back-end factory

expose

wafer

stepper

expose

wafer

stepper

metal

printer

advanced

process

control

logistics &

automation

power

chemicals

climate

infrastructure

computing &

networking

infrastructure

metrologymask

power, chemicals

consumables, waste

ICs

REX

wafer fab

(front end)

Characteristics of LEAN

A holistic, systems approach to product development

including people, processes, and technology.

Multi-disciplinary from the early start, with a drive to be fact based.

Customer understanding as the the starting point.

Continuous improvement and learning as cultural value.

Small distance between engineers and real systems, including

manufacturing, sales and service and the system of interest.

LEAN and A3 Approach to Supporting Processes80 Gerrit Muller


LEANcharacteristics

Example of A3 Architecture Overview

A3 architecture overview of the Metal Printer (all numbers have been removed for competitive sensitivity)

process steps

metal printing cell

Fluidic

subsystem

chamber

bottom chuck

electronics

infrastructure

process

power

supply

1

3

2

4

5electronics

infrastructure1 5granite

ZUBA

stage

frame

base frame +

x, y, stage

stage

control

ZUBA

control

optics

stagescoop

cameravision

op

tics s

tag

e

co

ntr

ol

vision

control

6

7

8

9

1

0

cabling

covers and

hatches

ventilation

air flow

contamination

evacuation

sensors

measurement

frame

machine

control

"remote"

electronics rack

10

11

12

13

14

15

?

metal printer back side metal printer front sideintegrating

subsystems

metal printer subsystems

tprepare

= tclose doors

+ tmove to proximity

tprint

= tp,prepare

+ tp,align

+ tchamber

(thickness) + tp,finalize

tfinalize

= tmove to unload

+ topen doors

tprint

= tp,overhead

+ Ctransfer

*thickness

2. Align

3. Move to proximity

4. Process

6. Open doors

1. Close doors

5. Move substrate unloading position

talign

tchamber

note: original diagram was annotated with actual performance figures

for confidentiality reasons these numbers have been removed

metal printer

functional flow formula print cycle time

key performance parameters

metal printer subsystems, functions, and cycle time model

metal printing cell: systems and performance model

back-end factory: systems and process model

pattern quality

cost per layer

environmental

impact

design enablinge.g. CD, separation

pattern

resolution

X-section control

accuracy overlay

high MTBF

early delivery

vs

volume production

uptime

throughput

operational

costs

system cost

electric power

clean water

elyte

N2, air

disposal water, air, ...

reliability

integral costs

consumables

waste

contamination

and climate

partial graph

many nodes

and connections

are not shown

customer key drivers

Customer key-drivers and Key Performance Parameters

Document meta-information

author

version

date last update

scope

statusGerrit Muller

0.1

August 3, 2010

system and supersystem

preliminary draft

metal printing time-line

min. line width

overlay

throughput

MTBF

a m

b m

c WPH

d hr

wafer size

power

clean room class

floor vibration class

200, 300 mm

x kW

throughput

1. inspection

2. seed sputter

3. metal print

4. seed etch

wafer

waferseed

wafer

Cu

wafer

5. coat/develop dielectricswafer

6. exposure or CMP for polymer viaswafer

7. E-test

spin coated

polymer

per waferthroughput in minutes

1

t

1

3..4

1..2

dual layer only

robot

prefill

master

FOUP

wafer

FOUP

wafer

FOUPflip

prealignclean

wafer

clean

master

metal

printer

print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b

wafer

with

ICs

back-end factory

expose

wafer

stepper

expose

wafer

stepper

metal

printer

advanced

process

control

logistics &

automation

power

chemicals

climate

infrastructure

computing &

networking

infrastructure

metrologymask

power, chemicals

consumables, waste

ICs

REX

wafer fab

(front end)



LEANoverviewA3

multiple related views

digestable

(size limitation)

quantifications

practical

close to stakeholder experience

one topic

per A3

capture

"hot" topics

source: PhD thesis Daniel Borches http://doc.utwente.nl/75284/



LAWFleanArchitecting

Light Weight Review Processby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

A light weight review process is described that can be used for documents madeduring product creation. This review process is focused on improving the contentsof specifications as early as possible. The process is light weight to increase thelikelihood that it is performed de facto instead of pro forma.

Distribution


September 9, 2018status: preliminarydraftversion: 0

draft

authorized

concept

final review= final check contents

authorization= check process

consultation

& review

- wide group of people,

with an active concern or

an expected contribution;

- many iterations

- multiple media:

+ meetings,

+ on paper

+ informal et cetera

specification specific Change Control Board

4 peoples/roles:

1 producer

1 consumer

1 context

1 independent

by "lowest" operational manager:

project leader, subsystem PL, ...

change

request

the author is responsible

for contents and

organization of the flow

(consults and review)

criteria for reviewers:

+ know how

+ critical

+ sufficient time

Product Life Cycle and Change Management

product

creation

production

used by customers

yearsmicro specification control board project team present

specification = communications means

very dynamic, many changes

light weight review processSCB

maintenance control boardno project team any more

documentation = organizational memory

changes only to cope with logistics or safety problems

Light Weight Review Process84 Gerrit Muller


LWRlifeCycle

Light Weight Specification Review Process

draft

authorized

concept



consultation

& review




- many iterations

- multiple media:

+ meetings,

+ on paper



4 peoples/roles:

1 producer

1 consumer

1 context

1 independent



change

request


for contents and




+ know how

+ critical

+ sufficient time

Light Weight Review Process85 Gerrit Muller

version: 0September 9, 2018LWRstateDiagram

Template How Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The introduction of a new process (way of working) is quite often implementedby supplying ready-to-go tools and templates. This implementation mainly servesthe purpose of a smooth introduction of the new process.Unfortunately the benefits of templates are often cancelled by unforeseen side-effects, such as unintended application, inflexibility, and so on. This intermezzogives hints to avoid the Template Trap, so that templates can be used moreeffectively to support introduction of new processes.

Distribution



Header

Body

Header

Footer

Body

Title Author

Abstract

Title, Date

Page, Author

1 Introduction 2 Scope

Title Author

Body

Title, Date

Page, Author

Body

Title, Date

Page, Author

3 Design

Title, Date

Page, Author

17 Interfaces

..

recommended template type

layout only

prescribing contents

meta information

Rationale for Templates

• Low threshold to apply a (new) process (1)

• Low effort to apply a (new) process (2)

• No need to know low level implementation details (3)

• Means to consolidate and reuse experiences (4)

Template How To87 Gerrit Muller


TemplatesRationaleList

Bogus Arguments for Templates

• Obtain a uniform look (5)

• Force the application of a (new) process (6)

• Control the way a new process is applied (7)



BogusRationaleTemplates

Forces of Change: Action = - Reaction

counteract

induces

Reaction

New Process

Support

Net change = all Forces


version: 1.6September 9, 2018THTchangeVectors

Template as Support for Process

principle process procedure tool

formalism

template

abstract specific and executable

drives

is

elaborated

in

is

supported

by



SAPabstractionHierarchy

Types of Templates

Header

Body

Header

Footer

Body

Title Author

Abstract

Title, Date

Page, Author

1 Introduction 2 Scope

Title Author

Body

Title, Date

Page, Author

Body

Title, Date

Page, Author

3 Design

Title, Date

Page, Author

17 Interfaces

..

recommended template type

layout only

prescribing contents

meta information



THTtypes

Recommendation

template type context knowhow value

layout only no low

meta information process high

prescribing content process and domain constraining• Use templates for meta-information.

• Use checklists for structure and contents.



Template Development

Templates are an optimization of the Copy Paste Modify pattern:• Look for a similar problem

• Copy its implementation

• Modify the copy to fulfil the new requirements



Spiral model: Use before Re-use

Implement document

Use Evaluate

Extract template



THTdevelopmentSpiral

Example Guidelines Meta Information(1)

Mandatory per page:• Author

• Title

• Status

• Version

• Date of last update

• Unique Identification

• Business Unit

• Page number




Mandatory per document:• Distribution (Notification) list

• Reviewers and commentators

• Document scope (Product family, Product, Subsystem, Module as far asapplicable)

• Change history




Recommended Practice:• Short statement on frontpage stating what is expected from the addressed

recipients, for example:

• Please send comments before february 29, this document will be reviewedon that date

• This document is authorized, changes are only applied via a changerequest

• See Granularity of Documentation [?] for guidelines for modularization andcontents



Template Pitfalls

• Author follows template instead of considering the purpose of the document.

• Template is too complex.

• There is an unmanageable number of variants.

• Mandatory use of templates results in:

• no innovation of templates (= no learning)

• no common sense in deployment

• strong dependency on templates

Recommendation:• Enforce the procedure (what)

• Provide the template (how) as supporting means.



Summary

• Templates support (new) processes

• Use templates for layout and meta information support

• Do not use templates for documents structure or contents

• Stimulate evolution of templates, keep them alive

• Keep templates simple

• Standardize on what (process or procedure), not on how (tool and template)

• Provide (mandatory) guidelines and recommended practices

• Provide templates as a supportive choice, don’t force people to use templates



TemplateSummaryList

System Integration How-Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

In this document we will discuss the full integration flow. We will discuss the goalof integration, the relation between integration and testing, what is integrationand how to integrate, an approach to integration, scheduling and dealing withdisruptive events, roles and responsibilities, configuration management aspects,and typical order of integration problems occurring in real life.

Distribution



measure

alignment

signal

exposemeasure

alignment

signal

position x,y

destination

measure

x,y source

position

x,y source

measure x,y

destinationalign source

destination

adjust light

source

adjust lens

focus

process

measure

correlate

stage

source

correlate

stage

destination

calibrate

x,y

measurement

control x,y

destination

qualify

Typical Concurrent Product Creation Process

design

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

6.

product operational

life cycle

-1

strategy

integrate test

requirements and

specification

policy

testintegratedesignrequirementspolicy

System Integration How-To101 Gerrit Muller


SINTproductCreationProcess

Zooming in on Integration and Tests

0.

feasibility

1.

definition

2.

system

design

3.

engineering4.

integration & test

5.

field

monitoring

6.

product operational

life cycle

integratebeta

test

system

test

alpha

test

gamma

test



SINTtesting

Integration Takes Place in a Bottom-up Fashion

component

system function

product

subsystem

integratealpha

test

context



SINTlevels

Transition from Previous System to New System

existing base system

new HW subsystem

SW dev system

test HW subsystem

test SW for new HW subsystem

new application

existing base system

integrate subsystem

SW dev system test and refine application

integrate and refineapplication

adopt existing base SW

new base system test new base systemintegrate HW

system

integrate

system

SW for new HW subsystem

adopt existing base SW

existing new

2 partial

systems for

SW testing

2 existing

base

systems

new base

systems

time

integrated

system

application integration

new subsystem

integration


version: 0.2September 9, 2018CVintegrationPlan

Alternatives to Integrate a Subsystem Early in the Project

(modified)

existing

subsystems

(prototype)

new

subsystems

to-be-integrated

subsystem

physical

environment

simplecomplex

virtual

spectrum

virtual environment

stubssimulated

subsystems

physical

simulated

physical

reality


version: 0.2September 9, 2018SINTenvironments

Stepwise Integration Approach

Determine most critical system performance parameters.

Identify subsystems and functions involved in these parameters.

Work towards integration configurations along these chains of

subsystems and functions.

Show system performance parameter as early as possible;

start with showing "typical" system performance.

Show "worst-case" and "boundary" system performance.

Rework manual integration tests in steps into automated regression

tests.

Monitor regression results with human-driven analysis.

1

7

5

3

2

6

4

Integrate the chains: show system performance of different parameters

simultaneously on the same system. 8



SINTapproach

Order of Functions Required for the IQ of a Waferstepper

measure

alignment

signal

exposemeasure

alignment

signal

position x,y

destination

measure

x,y source

position

x,y source

measure x,y

destinationalign source

destination

adjust light

source

adjust lens

focus

process

measure

correlate

stage

source

correlate

stage

destination

calibrate

x,y

measurement

control x,y

destination

qualify



SINTorder

Roles and Responsibilities During the Integration Process

project leader

organization

resources

schedule

budget

systems architect/

engineer/integrator

system requirements

design inputs

test specification

schedule rationale

troubleshooting

participate in test

system tester

test

troubleshooting

report

engineers

design

component test

troubleshooting

participate in test

machine owner

maintain test model

support test

logistics and

administrative support

configuration

orders

administration



SINTroles

Simplified Process Diagram

company customer

Customer-Oriented Process

sales logistics production


Tech

nic

al P

rod

uct

D

ocu

men

tati

on

(TP

D)

supplier

goods

specs

Customer-

Oriented

Process

Product

Creation

Process

orders Operation

Processproduct

order

Purchasing

Processtender

TPD

req

uir

emen

ts

life

cycle

goods flow



SINTprocessDecomposition

Configuration Management Entities

companysupplier

Customer Oriented Process

Customer

Oriented

Process

goods flow

customer



Tech

nic

al P

rod

uct

D

ocu

men

tati

on

(TP

D)

goods

specs

Product

Creation

Process

orders Operation

Processproduct

order

Purchasing

Processtender

TPD

req

uir

emen

ts

life

cycleTPD TPD

test models

test models

specifications

components

content of

pipelineproducts

product

tender

dataphysical

entitylegend



SINTconfigurationManagement

Typical Order of Integration Problems

1. The (sub)system does not build.

2. The (sub)system does not function.

3. Interface errors.

4. The (sub)system is too slow.

5. Problems with the main performance parameter, such as image quality.

6. The (sub)system is not reliable.



SINTproblems

Exercise Documentation

Make a design for the documentation structure of the case, take into account a.o.:• target audience per documentation module

• lifecycle

• author

• size (budget)Present (max 1 flip) the proposed documentation structure and the rationale.

Summary Module Supporting Processes112 Gerrit Muller


MSPexercise

Documentation

Requirements Entire DocumentationAccessibility for the readers

Low threshold for the readers

Low threshold for the authors

Completeness

Consistency

Maintainability

Scalability

Evolvability

Process to ensure the quality of the information

Requirements per DocumentHigh cohesion (within the unit)

Low coupling (outside of the unit)


Low threshold for the reader

Low threshold for the author

Manageable steps to create, review, and change

Clear responsibilities

Clear position and relation with the context

Well-defined status of the information

Timely availability

Decompose Large Documents

compound document

document

structure

overview

document

document

document

document

document

Recursive Decomposition

compound document

compound

document

compound

document compound document

overview

document

structure

overview

atomic

documentdocument

structure

overview

document

structure

overview

document

structure

atomic

document

atomic

document

compound

document

compound

document



Documentation

Maximize Payload

title

identification

author

distribution

status

review

history

changes

front page

meta information

max 2 pages

diagrams

tables

lists

and ca 50%

text

1. aap

2. noot

3. mies

contents

2..18 pages

A3smultiple related views

digestable

(size limitation)

quantifications

practical

close to stakeholder experience

one topic

per A3

capture

"hot" topics

source: PhD thesis Daniel Borches http://doc.utwente.nl/75284/

Light Weight Review

draft

authorized

concept



consultation

& review




- many iterations

- multiple media:

+ meetings,

+ on paper



4 peoples/roles:

1 producer

1 consumer

1 context

1 independent



change

request


for contents and




+ know how

+ critical

+ sufficient time

intentionally left blank



Systems Integration

Integration Starts at Feasibility

design

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

6.

product operational

life cycle

-1

strategy

integrate test

requirements and

specification

policy

testintegratedesignrequirementspolicy

Bottom-up

component

system function

product

subsystem

integratealpha

test

context

Alternatives for Early Integration

(modified)

existing

subsystems

(prototype)

new

subsystems

to-be-integrated

subsystem

physical

environment

simplecomplex

virtual

spectrum

virtual environment

stubssimulated

subsystems

physical

simulated

physical

reality

Propagation of Configuration Issuescompanysupplier

Customer Oriented Process

Customer

Oriented

Process

goods flow

customer



Tech

nic

al P

rod

uct

D

ocu

men

tati

on

(TP

D)

goods

specs

Product

Creation

Process

orders Operation

Processproduct

order

Purchasing

Processtender

TPD

req

uir

emen

ts

life

cycleTPD TPD

test models

test models

specifications

components

content of

pipelineproducts

product

tender

dataphysical

entitylegend

