SYSTEMS ENGINEERING PROFILES

[ What is a Systems Engineering Profile ]
[ Profile Topic Areas ]
[ Flowchart of Profile Development ]
[ Web-based Profile Requirements ]
[ Project Deliverables ]

WHAT IS A SYSTEMS ENGINEERING PROFILE?

While the discipline of Systems Engineering has been practiced primarily by the Defense, Aerospace, and some Civil sectors during the past 2-3 decades, we expect that in the 21st Century, nontraditional engineering (and even some non-engineering domains) will benefit from systems engineering techniques. All of these sectors will need to develop highly complex systems, with strict requirements on performance, reliability, economy, and short time-to-market.

A Systems Engineering Application Profile (SEAP) is a high-level description of how systems engineering knowledge, procedures, processes, and technology can be used for problem solving within an application domain. After reading a profile, readers should be left with a basic understanding of what makes an application domain tick!

Benefits

By assembling and presenting a suite of applications profiles in one place, we hope to identify patterns in problem solving strategies and techniques that are common to multiple application domains (INCOSE 95).

Development of these profiles will advance systems engineering education, promote the discipline of systems engineering, and enable systems engineering practice across application domains.

PROFILE TOPIC AREAS

I encourage you to develop a profile for a domain in which you have a keen interest, and for which you have access to information from experts.

Because team development is an essential component of systems engineering, profiles should focus on the end-to-end solution of a problem that requires the resources of at least 20-30 people. "How I installed a web server in my apartment" is a good example of an an unacceptable topic. Suitable topic areas include:

    Agriculture
    Automated Highway Systems 
    Chemical Systems (e.g., oil/chemical refineries)
    Commercial Aircraft
    Electronic Design Automation
    Electronic Packaging
    Energy Systems
    Environmental Restoration/Cleanup
    Entertainment Systems (e.g., Networked Video Games)
    Geographic Information Systems
    Healthcare Information Systems 
    Highway Transportation Systems
    Intelligent Building Systems
    Intranets/Extranets/Web Browsers....
    Infrastructure Systems (e.g., bridges, dams, roads etc..)
    Medical devices
    Microelectronics manufacturing
    Motor Vehicles
    Natural Resources Management
    Office Automation
    Petroleum Exploration
    Power Systems Engineering
    Robotic devices
    Satellite Design and Deployment
    Structural Systems (e.g., buildings and highway bridges)
    Systems Engineering Automation/Tools.
    Telecommunications
    Telemedicine
    Urban Planning
    Waste Management and Disposal

Of course, you are welcome to propose your own topic.

Good introductions to some of these application domains can be found in special issues of Scientific American, Communications of the ACM and IEEE Design and Test. Another good place to look is the Proceedings of the International Council of Systems Engineering (INCOSE), especially papers that have been presented in the "Systems Applications" tracks.

FLOWCHART OF PROFILE DEVELOPMENT

The design and operation of complex systems involves the development and coordinated management of complex relationships among a variety of subsystems and components. Some of these entities and relationships are related to the project itself; others belong to the organizational infrastructure that supports the project development.

With these comments in mind, Figure 1 shows the ingredients, processes, and viewpoints that should be included in your systems profile.

Figure 1 : Flowchart for Systems Profile Development

SEAPs should help readers with technical and management backgrounds and interests understand why an application exists, what the application domain does, how it accomplishes its purpose, and who makes things happen. These factors are shown along the left-most column of Figure 1.

SEAPs should also look at system lifecycle development as the composition of interacting processes:

In part, system development is an organizational process to be managed .
Important factors in an organizational design are estimation of human resources, and management and scheduling of activities and information/data among these resources. The organization should serve the dual role of supporting individual projects, while also work towards the business mission, and meeting stakeholder and customer needs. These concerns are shown on the left-hand side of Figure 1.
System development is also a technical process to be accomplished .
Important components of the development for a domain entity are identifying key business/customer goals and scenarios for the system/entity, mapping of goals/scenarios into technical and performance requirements, transforming the requirements into desired systems behavior, synthesis of a project structure, and procedures for building and testing the engineering product/service. This pathway of activities is shown along the right-hand side of Figure 1,

Each process should consider activities/tasks from the conceptual stages of development through retirement of a product/service.

Organization and Management Viewpoint

Four broad classes of questions for the organization are as follows:

Why does the organization exist?
- Profiles should describe the organization's owners and stakeholders, the key business opportunities for the organization and, if possible, the its long-term strategic goals?
- Who are the intended customers? Where are they located?
- Who are the main players (i.e., competition) in the application domain?
- How is the application domain/industry affected by economic and commercial forces?
Who in the organization actually does this work?
- Profiles should describe the roles and responsibilities of the main groups of people within an organization. Some groups will support the organization as a whole -- others will be assigned to a specific project (e.g., management, architects, engineers).
- Clearly identify the roles and responsibilities of the main project participants (e.g., planners, architects, engineers, contractors). What is the working relationship among these groups?
- How do people within an organization interact with other organizations, and with their customers and stakeholders?
- Are the project operations centralized, distributed, farmed out to contractors, etc?
What does the organization do?
- Profiles should describe the events and scenarios that affect the organization behavior.
- How is the organizational behavior guided by organizational requirements, legal requirements, project requirements, standards, and so forth?
- What functions and processes are put in place by an organization to handle expected/unexpected scenarios?
- What level of capability (i.e., CMM) do organizations within the domain have?
How does the organization achieve its purpose?
- How is the organization structured so that the behavior can be mapped onto structure to produce a smooth running operation?
- Are formal systems engineering processes used, either explicitly or implicitly, within the domain? If not, why not?
- To what extent is the organizational structure vertically/horizontally integrated?

Note. I do not expect that all groups will have sufficient information to answer all of these questions.

Engineering System and Project Development Viewpoint

Four broad classes of questions for development of the project/engineering system are as follows:

Why is the engineering system (i.e., product or service) being developed?
- From both a customer and organizational perspective, profiles should describe the goals and objectives of the engineering system?
  - What are the purposes of the engineering system?
  - Who will use it? And where?
- What factors influence the economics of product development, choice of technology etc...
- What are the risks in development?
- Are formal systems engineering processes used, either explicitly or implicitly, within the domain? If not, why not?
Who is responsible for system development and operation?
- What are the roles and responsibilities of the main groups of people working on the system development (e.g., architects, engineers)?
- In a high-level sense, what kinds of information passes among these groups of people?
- Who is responsible for operating and maintaining the system?
What does the engineering system do?
- From both a customer and organizational perspective, what will the engineering system do?
- What are the system boundaries? For example, boundaries between:
  - The system and its users;
  - The system and the external environment;
  - Parts of the system that can be adjusted and controled, and those that can't.
- In what range of environmental conditions will the system be expected to operate in an effective manner?
- What are the system inputs and system outputs to/from the external environment?
- Profiles should describe operational scenarios for fragments of the engineering system behavior.
  - How will a user (or the environment) interact with the system during the scenario? What happens during normal operation? What happens when something goes wrong?
  - How are events and operational scenarios translated into operations and functional performance characteristics?
  - How do the requirements generated by scenarios flowdown to the subsystems?
  - Which scenarios support the generation of design ideas? Which scenarios enable evaluation of a proposed design?
- What are the important measures of effectiveness for the application domain?
How does the engineering achieve its purpose?
- What is the lifecycle of a typical product (or service) in the application domain?
- What standards (or guidelines or specifications) are the important to the application domain/industry?
- How are systems designed so that they are adaptable to changes in technology, standards, and regulation?
- For a typical example of the engineering system, how is the system behavior mapped onto system structure to produce a system design?
- How does the application domain partition its activities into individual functions and processes? In otherwords:
  - How do requirements flow down to individual processes and functions?
  - How will the various system components be used?
- What are the existing and planned interfaces?
  - How will the system interface with the external environment; parts of the systems for which the team has no control?
  - How are interfaces between sub-systems defined?
  - Do the interfaces enable a pathway of data (or information or product) flow that is consistent with the desired behavior?
- What are the constraints (hardware, software, economic, procedural) to which the system must comply?
- What is the build and test procedure for a typical product/service in the application domain?
  - Will the final form be a model, prototype, one-of-a-kind implementation, or mass production?
- How are "risks in development" and "quality control" issues handled?
- Is time-to-market a key factor in the success of the product?

Profiles should consider the extent to which these viewpoints can be enhanced through the use of technology, sophisticated techniques for modeling system behavior, and optimization and trade-off analysis procedures.

WEB-BASED PROFILE REQUIREMENTS

Each web-based profile should contain the following sections:

Introduction (Required)
Profiles should begin with a well written introduction to your application profile. The introduction should set the stage for the content to follow, and address some of the big picture issues shown in Figure 1. (e.g., The goals and objectives of the engineering system).
Organization and Management (Required)
This section should describe:
- Why the organization exists.
- What the organization does.
- How the organization achieves its purpose.
- Who in the organization actually does the work.
Assessment of Systems Information (i.e., Requirements Engineering)
Create a concept diagram (and text) showing the technical approach or design concept -- in abstract terms:
- How will the system be integrated to meet the performance and functional requirements?
Create a list of typical initial requirements for your application domain.
- The list (or collection of lists) should reflect the needs of the project participants, and as appropriate, indirect requirements such as standards, environmental and legal regulations.
System Behavior and System Structure (Required)
Profiles should describe the system behavior and system structure, as they exist in the early stages of system development.
System Behavior. Identify and define operational scenarios that cover the range of anticipated uses of the system product/service. For each scenario, define:
- The context (i.e., situation) in which the scenario will occur.
- A sequence of events (or tasks) that must be completed for the scenario to play out.
- Can the tasks be done in any order, or is their an imposed sequence?
- Requirements that must be satisfied in order for the system to behave as expected.
Describe the process of requirements flowdown to the subsystems, and further refinement of requirements via scenarios at the subsystem level.
System Structure. Develop a small number (i.e., more than one!) of alternative system structures. For each structure, define:
- Interactions with the environment and other systems;
- Physical interconnectivities with interfacing systems, platforms, or products.
Measures of Effectiveness (Required)
Describe the measures of effectiveness reflecting customer expectations for your application domain.
- Key measures of effectiveness include simplicity and ease-of-use, economics, high quality, short time-to-market, and so forth.
- Does the application domain make use of production functions? If so, what kinds of production functions make sense?
Present one or two examples showing how these measures of effectiveness apply in practice.
Preliminary System Design (Required)
Develop a small number of preliminary system designs by mapping the system behavior onto alternative system architectures (i.e., more than one architecture).
- How are the functions identified at the "system behavior" step mapped onto the system structure components?
For each alternative:
- Create a functional/physical matrix showing the sub-systems (or components) used by each scenario.
- Verify that the range of operations will work by walking step by step through each scenario (i.e., do the system interfaces allow for the desired system behavior?).
Optimization and Trade-Off Analysis (Optional)
Take a significant problem within your application area, and formulate it in terms of a single- or multiobjective "optimization" problem.
- What are the design variables? Are they discrete or continuous?
- How are requirements translated to optimization constraints?
- What are the key measures of effectiveness for the application domain?
- How are design alternatives generated?
- What are good ways to display and compare the performance of the design alternatives?
- How are system trade-offs made?
- What are the limitations of the methodology you have adopted?
The important point at this stage is choosing a solution pathway that is appropriate to the problem at hand. I expect that some projects will lend themselves to the solution of linear programming problems. Others may lend themselves to analysis with decision tables/tree and possibly the use of utility functions. Both approaches are fine. What I will be looking for is justification of the problem formulation, and a critical assessment of the analysis that is conducted (both good and bad).
Use of Online Spreadsheets (Optional).
The purpose of this section will be to explore the use of Java Applets for analysis of simple systems (and decision making) within the application domain.
- Develop a small set of example problems that illustrate how systems analysis methods can be used for basic decision making within the application domain.
- How can Java bar chart, line charts, spreadsheets ... etc .. be used to convey ideas?
- Can you find applets on the web that could be customized to the analysis of simple engineering/business systems?
If the library of Java Applets cannot portray a simply idea, please let us know and we will consider writing a special applet for your purpose.
Build and Test; Operations and Maintenance (Optional)
Briefly describe procedures for ``building and testing'' entities in your application domain.
- What does a typical plan for building the system look like?
- Are subsystems and components built in-house, or procurred?
- How would you characterize the overall process of building the system (e.g., top-down; bottom-up; a combination of bottom-up and top-down?).
- What role to "operational scenarios" play in testing/validating the system performance?
Briefly describe procedures for ``operation and maintenance'' of products/services in your application domain.
Systems Engineering Challenges (Required)
- What are the near- and long-term systems challenges facing the industry/application domain?
- What technologies could the application domain/industry benefit from -- for example, simulation, optimization, decision analysis, generation of design alternative, and so forth.
Contacts and References (Required)
- Provide a list of contact addresses and references for your project.
- Profiles should contain pointers to on-line case studies (if they exist).
To ensure that the previous sections are accurate, I expect that you will contact and interview professionals working within the industry/domain. Where appropriate, provide links to references and case-studies located on the web.

PROJECT DELIVERABLES

Student groups may have one or two persons. There will be three project deliverables:

Project Announcement
I want to build a web page that briefly summarizes each project. Each summary should contain:
1. The project title (with a link to the project on the web),
2. The authors (with links to their home pages), and
3. An abstract explaining the goals of the project. (I encourage you to revise/improve your project abstract up until about the Thanksgiving break).
Web-based Presentation
Each group will be required to present their project on the web. using HTML, Javascript, Java, cool graphics, and so forth. Segments of projects containing lots of equations may be delivered in postscript (or PDF or MS Word) format, with a link from the appropriate web page to the document.
Hand in a Final Project Report
Hand in a hardcopy of your project. Projects are due 5pm, December 15.
Note. These are hard deadlines. I'm leaving the country on December 22, and if you don't get your project to me way before then, you won't get a grade for the semester. This comment is particularly important for students in ITV-land.

Assessment

In grading the projects I will be looking for:

A clear, concise, statement of the problem domain being considered (longer is not necessarily better);
A strong connection between the nature of the problem domain and the system development and management that emerges;
A descriptive presentation of the systems analysis -- a picture that captures the effectiveness measures and limitations of an ensemble of design alternatives may be worth a thousand words;
A critical assessment of the strengths and weaknesses of present-day systems;
Discussion of the near- and long-term systems challenges and opportunities facing the application domain.

Innovative use of web technologies will be appreciated and is strongly encouraged.

REFERENCES

International Council of Systems Engineering Applications Forum Working Group, Systems Engineering Application Profiles, Version 1.0, May 1, 1996.
Systems Engineering Fundamentals, Defense Systems Management College Press, Fort Belvoir, Virginia, October 1999.