EMIS 7307

1

Chapter 2

• How important is determining (or creating) the need first? – Defining the problem is the hardest part.– Consider the alternative. What happens?– Answers the question, What function(s) must this

system perform?– Answers the most basic test planning questions too!

• Fig 2.1 “waterfall”, are there elements of this that must be sequential versus concurrent?

EMIS 7307

2

Chapter 2

• Feasibility analysis.– Determines the technology to be used.– Determines need for applied research.– Big decisions are made here!– Lead by Systems Engineers but details executed

by specialists.

EMIS 7307

3

Chapter 2 • Operational requirements.

– Figure them out and declare your first baseline!– What, when, where, about the system.– Operational deployment.– Mission scenario.– Critical performance parameters.– Utilization requirements.– Effectiveness requirements (often the only bastion of SE in a

company, but still ignored).– Lifetime.– Environment- don’t forget shipping and storage!

EMIS 7307

4

Chapter 2 • What’s the effect of the chosen

maintenance approach on integration?• What’s the effect of the chosen

maintenance approach on test?• Glance at Figures 2.5 and 2.6

EMIS 7307

5

Chapter 2 • How does one determine appropriate technical

performance measures (TPM)?– Fundamental to many other important issues.– Must be verifiable.-

• Not: “should do’s” but “must do’s”.• It’s known how well. (What if you don’t know?)

– Traceability is essential for both integration and testing. Not limited to TPMs.

• See examples Figure 2.10.

EMIS 7307

6

Chapter 2 • If you have never seen a so called house of quality

(HOQ) see Figures 2.8 and 2.9. • Regardless the technique, here’s what’s important.

– Customer requirements are determined and prioritized. Why important?

– Alternative approaches are determined and traded-off. Why important?

– Requirement flowdown to more detailed levels is formal i.e. not ad hoc. Why important?

EMIS 7307

7

Chapter 2 • Fig 2.10 is a good start but what is missing?• Functional analysis:

– “Putting meat on the TPMs”– What has to be done and how well should it be done.

• Not how to do it!– Think through each use or action the system will perform.– Usually subsystems are built around major functions.– This is only an initial look at interfaces, but it is essential

to successful integration.

EMIS 7307

8

Chapter 2 • What’s a functional flow diagram(FFD)?• The interconnects are clues for possible:

– Places to establish formal interfaces.– Logical division of labor between groups/companies.

• Applications of FFDs.– Start input/output definitions.

• Must be well understood to help decide on preferred approach.– Start resource identification.

• Let’s walk-thru Figures 2.15 and 2.16.

EMIS 7307

9

Chapter 2 • Using FFD consider COTS - Pros? Cons?

• Part of make/buy decision includes off the shelf vs new build (Fig 2.18).

• Use of open architecture - Pros? Cons?• Using FFDs can facilitate later design evolution even after

deployment.• Well defined FFDs can alleviate or lessen the trial by error

aspects of eventual integration (Fig 2.19 a mini integration plan).

– Poorly defined functional interfaces lead to need for rework and redesign.

EMIS 7307

10

Chapter 2 • See page 77 for examples of FFD uses.

• Note the flow in Figure 2.20.– Produces a common though very preliminary

baseline.– Without this the design engineers make their

own assumptions and do what they do best.… but without a common vision it won’t integrate!

EMIS 7307

11

Chapter 2 • Partitioning (allocation) is next. (i.e. where do you place the

functions in a possible design).– Define subsystems, assemblies, subassemblies.

• How does one decide where to place a function?– Define software development packages. (CSCIs) Which

functions are HW? SW?– Individual packages should be as independent as possible:

• Minimize interface complexity at the expense of internal complexity.

• Pros?/Cons?

EMIS 7307

12

EMIS 7307

13

Chapter 2 • Any problem with Fig 2.21?

– Too high a level breakout of HW vs SW?• Allocation of the requirements to the “level

required to provide a meaningful input to design”.– Where is this level? Theoretically and practically?– How does A vs. B vs.C level specification enter this

issue?– Where does SE end and design engineering begin?

EMIS 7307

14

Chapter 2 • How formal and structured should

requirement flow down be? Ever heard of SREM or DOORS?– Do customer stated requirements ever make it

to the design, i.e. “C” spec? When?– What’s the difference in specificity in new

design vs. COTS?

EMIS 7307

15

Chapter 2 • System synthesis, analysis and design

optimization:– Synthesis is design. (So does this mean that SE’s

are not involved?)– Synthesis produces trial combinations of functions

hypothetically placed into various components.• Figure 2.25 is the typical order of importance.

Note that design is at the 4th level!

EMIS 7307

16

Chapter 2 • Alternatives are subject to analysis/

evaluation to determine meeting TPMs. See Fig 2.26.

• Analysis includes modeling e.g. Fig 2.27.• The modeling of the interrelationships is

essential to successful integration!

EMIS 7307

17

Chapter 2 • Design Integration

– See Figure 2.29.– Best accomplished by having a team that

represents each of the perspecti (an IPT!).– Requirements.– Design skills (EE, ME, CS etc).– Specialty engineering.– Testers.

EMIS 7307

18

Chapter 2

• Design integration is facilitated by:– Co-location or VTC.– Shared databases both management info and

design info accessed via internet-like structure.– Strong SE management.– Totally open communication.– Strong CM.

EMIS 7307

19

Chapter 2

• T&E is accomplished at all levels of integration not just at the end.– Purpose is to give the decision maker facts upon

which to make decisions (risk reduction).– Decision maker can be a lowly design engineer

all the way to the President.

EMIS 7307

20

Chapter 2

• Figure 2.32 is very useful but not the only way various verifications are delineated.– Type 2 and 3 are often for the customers i.e.

leading to sell-off.– The DAU handbook will provide much more

information later in the course.

EMIS 7307

21

Chapter 2

• The cost associated with verification is high. • However compared to the cost of not testing it’s

trivial. See handout with estimates of the impact of insufficient software testing.

• The value of the test and the limiting of it’s cost is best accomplished by good planning.– The TEMP and ITTs will be discussed much more, later

in the semester.

EMIS 7307

22

Chapter 2

• Figure 2.33 is a good overall depiction of the test/modification interrelationships.

• What’s the SE role in production, operations and retirement?