Systems Engineering, as used at NASA (for example), encompasses the following major responsibilities:

1. oversight of scientific and engineering efforts
2. development of user training procedures (and of associated equipment and reference materials)
3. management of system configuration
4. bookkeeping of work assignments and workers
5. enabling of management decisions that affect project
6. evaluation of new techniques, procedures and technology

A single systems engineer does all of these things to some extent, but may pass some responsibilities off to others. In each of these responsibilities, the Systems Engineer is obviously gearing efforts toward "making some system work." What does this mean? Desired ends usually include at least one optimization objective (e.g. "minimize cost," "maximize useful science"), and as such we are automatically in an environment of tradeoffs. The Systems Engineer will trade off (among other things) cost against system performance against risk.

The trick is to turn such vagueness as "maximize useful science" into positive meaningful targets. Some companies consider trade-off areas in priority order: safety, environment, economy, etc. The task in that case is always to make the safest possible system that will endure in, and not degrade the environment in which it is to operate, and at as low a cost as is practicable.

Each sub-system will require a mix of knowledge and skills across several disciplinary boundaries. Making use of that fact yields a team who can the required sub-system in shorter periods of time than if teams were formed by splitting disciplines.

The text shows performance (or, effectiveness) as a nice, smooth, well-behaved function of cost -- a monotonically increasing function, but one which clearly follows the Law of Diminishing Returns. Anything whose effectiveness is above the curve is not a feasible design. Anything below is feasible, but may not be worth what you pay for it. If you have uncertainty, that generates a "cloud" around some point on or below the curve. Unfortunately, both "cost" and "effectiveness" are really not simple scalar variables, so coming up with such a curve and all of its "clouds" is not so easy, and if it's even possible may have questionable meaning when done. So we leave all that up to the Systems Engineer. :-)

Here are the steps in the life of the project, from the Systems Engineer's point of view:

1. define some need, or recognize that opportunity is knocking
2. determine the goals of a mission that satisfies step 1
3. conceptualize designs
4. perform trade studies on those designs
5. select one of the concepts
6. increase the "resolution" (or, start "decomposing" the design to the subsystem level), then repeat steps 3 through 5
7. implement the designs from step 6 -- including the steps of
   • build
   • integrate
   • test
   • certify

8. perform the mission!
9. dispose of what's left over

Each step results in

• "baselined" information, usually in documentation
• "control gates," usually design reviews that lead to go/no-go decisions

The review is the real test of the value of material produced. Make sure that the right people are chosen for review panels. And remember that you have to help them understand what they're reviewing, in advance. Plan ahead!

How does the systems engineer organize all this stuff? The text indicates that among the fundamental tools used by the Systems Engineer is the Work Breakdown Structure (WBS), which includes the following information:

• work assignments
• project planning & status information
• cost & budget information
• access to specs & drawings

each of which is (theoretically) traceable back to some system requirements. Once again, we hit those terms "specs" and "requirements." You have the requirements first. Then you have the specs. In general, anyway -- sometimes a requirement slips through the cracks or is otherwise not recognized until the specs have set in.

Here are some helpful definitions:

• integration = "fitting pieces together"
• verification = "show correct interfaces & subsystem design"
• validation = "ensure that interfaced subsystems work together as advertised"

Some organizations use verification and validation (V&V) as a tool in system design. Some form of this activity will show up in any modeling effort or trade study. Trade studies weigh system requirements and identify performance measures, weeding out things that are not worthy and ranking what's left according to importance. Trade studies require

• a review of the issue(s) at hand
• a summary of alternatives and constraints
• development of a model
• identification of an information/data source
• rule(s) used to select an alternative

and result in the selection of an alternative, along with other results (many of them quantitative, if not numerical).

The model you use in a trade study is by its nature incomplete: it leaves something out. And that flaw in the trade study is the source of other flaws: namely, that the model type may be chosen out of no concern more quantitative than "convenience." Or that multiple models (e.g. for multiple subsystems or boxes) may lead to multiple incomplete information. How well do the models work together, anyway? Or simply that the model lends itself to questions about its structure, its parameters, and its inputs. (Yes, we encounter all this in dynamic simulation too.)

A critical path is that sequence of activities that takes the longest to accomplish. Within all project activities, there will be one of these, and others may be close -- or there will be a critical path for each subsystem or project responsibility, etc. A non-critical path may have some room for rescheduling (or, "float") in one of two ways: path float, which involves some delay of a sequence before that sequence becomes critical; or free float, in which an individual activity will not affect other paths if it is itself delayed.

Process metrics during the life of the project may include the following:

• requirements identified/completed/approved (possibly as a function of engineering hours)
• trade studies planned/completed
• specs planned/completed
• drawings planned/released
• V&V plans identified/approved; procedures planned/completed
• RIDs and action items dealt with.

A RID is a review item discrepancy, and involves something that may need more explanation, or may need to be changed. It may be thought of as a Problem Report. It is usually a problem of understanding material presented or a problem in the design logic (based on incorrect assumptions). These must be reviewed to evaluate the best way of resolving the problem. Problems are potentially a requirement for change.

In some organizations, anyone can raise a problem report. Each report is then reviewed and any changes to the specification documents are incorporated in a change request. those not requiring a change are just merely responded to with an appropriate explanation. The problem report is then returned to the originator to verify any action taken.

Reviews should include a sweep-up operation that ensures the status of problem reports received and their satisfactory resolution. If a problem report remains unresolved the review has failed and the new issue cannot proceed.

Risk usually implies the possibility of one or more of the following conditions:

• safety (death, injury, or property damage)
• technical (loss of mission, failure, malfunction, or poor performance)
• cost (overrun)
• schedule (miss deadlines or windows)

Risk assessment involves (often subjective) probability estimates of one of these things going wrong given some conditions. Risk mitigation may involve a tradeoff of one form of risk against another. Reliability assessments involve some understanding of causes of failures, and of the hazard rate (or probably the mean time between failures, or MTBF) of subsystems during various stages of system life. Risk is (hopefully) taken account of in the verification process.

Two typical stages in verification are

• qualification -- does the system meet performance and/or operational requirements?
• acceptance -- are we ready to reproduce and/or fly this system?

Verification can be accomplished by various means, depending on what's being verified:

• analysis
• demonstration
• inspection
• similarity (to something else that's flown)
• test

and each of these is applied to (hopefully) appropriate boxes and subsystems.