bluuebunny/crossref_metadata_2025 huggingface dataset:
Benchmarking the Systems Engineering Process
Authors: Fisher Gerard H. , Dobry Michael , Jones Kenneth
Published: November 2014

Benchmarking, the search for the best of the best, is mandated by all quality assessment models. It answers the question: How do you know you are performing well unless you know what “well” is? In addition, “the best” is a moving target. Your competitors are always looking for ways to improve. This paper describes an initiative of the Washington Metropolitan Area NCOSE Chapter to benchmark some key systems engineering subprocesses and to make the resulting data available to the general NCOSE membership. The benchmarking activity represents an unique partnership of NCOSE, academia and industry in the measurement of corporate performance while still protecting the privacy of corporate data. This effort was supported financially by Loral Federal Systems, Manassas, VA.
An Interim Model for the Capability Assessment of Systems Engineering and Associated Supporting Documents
Authors: Widmann E. R.
Published: November 2014

The Capability Assessment Working Group (CAWG) is one of four working groups that comprise the Measurement Technical Committee of the Technical Board of the National Council On Systems Engineering (NCOSE). This paper is a forward or descriptive introduction to an Interim Model for Capability Assessment of Systems Engineering and its associated supporting documents, which were developed by the CAWG over the past year. The Interim Model is a preliminary or draft attempt to assess systems engineering capability with respect to a subset of the requirements defined by the CAWG for this purpose. The Interim Model can be viewed as filling a void, since the CAWG believes that a complete Capability Assessment Model for Systems Engineering that satisfies all requirements defined by the CAWG currently does not exist. The paper also presents a background leading up to the development of the Interim Model and a description of the planned activities focused on both improving and offering a degree of validation to the Interim Model and its supporting documents. A key feature of the improvement/validation activity is a series of CAWG facilitated Systems Engineering Process Assessments (SEPAs) at selected companies.
Systems Engineering and Integration for Doe Environmental Management
Authors: Power Gloria , Wiersholm Otto
Published: November 2014

The estimated Environmental Management cost for the Department of Energy (DOE) complex, “the cold war mortgage”, exceeds the projected DOE budget. DOE awarded the Lockheed Martin Corporation the Idaho National Engineering Laboratory (INEL) Management and Operations (M&O) Contract, and Lockheed Martin emphasizes Systems Engineering (SE) as a method to operate a DOE National Laboratory more cost effectively. Lockheed Martin (SE) methods and experience were mainly developed as an aerospace, space, and defense contractor. This paper describes how Lockheed Martin Idaho Technologies (LMIT) applied SE principles to the INEL Environmental Management program within six months of taking over the INEL contract. LMIT transferred and applied SE methods and experience from an industry driven by laws of physics and hardware, to an industry driven by environmental regulations, risk and shrinking budgets.
MINED GEOLOGIC DISPOSAL SYSTEM CONCEPT OF OPERATIONS
Authors: Rindskopf M. Sam
Published: November 2014

A Concept of Operations was developed for the disposal of high‐level radioactive waste in the potential geologic repository at Yucca Mountain, located 90 miles north of Las Vegas, Nevada. The Concept of Operations documents a common understanding of how the repository is envisioned to be operated. Based on the repository functional analysis and the repository architecture as identified in the Initial Summary Report for Repository/Waste Package Advanced Conceptual Design, the Concept of Operations describes the operation of the repository from the initial receipt of waste through repository closure. The development of a Concept of Operations has enabled project participants involved in development activities to have a common understanding of how the total system is envisioned to operate.
INTRODUCING SYSTEMS ENGINEERING INTO A TRADITIONALLY COMMERCIAL ORGANIZATION
Authors: Jackson Scott
Published: November 2014

Many organizations are endeavoring to apply systems engineering (SE) to the development of commercial products. However, the challenge of doing this in a traditionally commercial organization (TCO) is very different from doing it in a traditionally government‐oriented organization (TGO). This paper provides a set of guidelines based on the experiences of the author in both types of organizations. Among the tenets espoused are the respect for the tribal knowledge of the commercial organization, the preservation of useful processes, the recognition that much SE is already practiced in the organization, the insistence on content rather than form in the SE process, the respect for traditional commercial terminology where it may apply, the importance of training, the importance of an internal “champion,” and the use of Integrated Product Development (IPD). The paper also cautions against the disease of arrogance and implores the reader to be grateful for incremental progress. Most important are the complete buy‐in from top management in the organization and the necessity to stand firm on the principles of systems engineering.
THE BRIAR PATCH: FROM DOD TO COMMERCIAL SYSTEMS ENGINEERING
Authors: Hale Pat
Published: November 2014

Most of us are familiar from childhood with the Uncle Remus story where Br'er Rabbit escapes being the main dinner course by imploring his captor to “Throw me in that briar patch!”. Following defense secretary Perry's initiative to move DoD toward commercial standards and best practices, many DoD systems engineers have wondered what distinguishes commercial systems engineering from traditional aerospace processes and practices. This paper describes the experiences and observations from a DoD systems engineer's transition into a pure commercial product development environment. Topics include: What is ‘commercial’ systems engineering? What practices from DoD provide the highest added value in the commercial world? What are the unique challenges to application of systems engineering in the commercial world? What lessons can DoD learn from commercial industry? And, finally, is this commercial ‘briar patch’ a viable future address for you as an aerospace‐trained systems engineer?
SYSTEMS ENGINEERING IN A MANAGEMENT AND OPERATIONS (M&O) ENVIRONMENT
Authors: Flowers Shirlee J.
Published: November 2014

The nuclear waste management community has opted to use process flows to depict the activities and goals necessary to meet the enormous challenge of nuclear/chemical waste environmental clean‐up. The process flow methodology leads to decomposition of functions much the same as functional flows; however, the methodology to ensure integration of the processes differs from standard Department of Defense (DOD) systems engineering. Examples of other functions necessary to complete the life cycle of the system are described, including the rationale for potential inclusion into the FRAT method. The discussion that follows is a comparison of process flows and functional flows with examples of each method. Recommended changes to the systems engineering environment in an M&O program follow the discussion of methods.
A PRACTICAL APPROACH TO FAILURE MODE, EFFECTS AND CRITICALITY ANALYSIS (FMECA) FOR COMPUTING SYSTEMS
Authors: Becker James Carlin , Flick Glenn
Published: November 2014

This paper presents an approach developed and used for Failure Mode, Effects and Criticality Analysis (FMECA) of a distributed computing system for air traffic control. The concepts, benefits, failure mode classifications, and FMECA process are summarized. The concept of failure mode criticality and its assessment for system safety is also addressed.
A Method for the Selection of Systems Engineering Automated Tools
Authors: van Gaasbeek James R
Published: November 2014

The use of software tools to automate some or all of the systems engineering process holds great promise. Computer‐based tools have provided significant improvements in other disciplinary areas, most notably structural design (CAD), structural analysis (FEM) and software development (CASE). A vendor base has begun to supply tools for the systems engineering discipline and industry has begun to acquire and deploy such tools.

However, the tools are expensive, sophisticated, and require significant effort to integrate their use into the system engineers' daily activities. A mechanism is needed for the selection and acquisition of the right tools, and a mechanism for introducing the tools into the systems engineering culture with minimum disruption and expense. This paper addresses the tool selection activity. The paper addresses the selection of a single tool, but the author believes that the method described can be generalized to selection of a tool suite or a tool integration framework.
LESSONS LEARNED IN THE SELECTION OF A COMPANY STANDARD REQUIREMENTS MANAGEMENT TOOL
Authors: Acaba Ralph H.
Published: November 2014

As systems engineering automation tools become more mature, and systems become more complex, companies are realizing that they must make use of these tools in order to remain competitive. One of the issues that is commonly debated is whether to select and implement a company standard tool, or allow individual projects to select their own tool. This paper describes the benefits and penalties of selecting standard tools and the rationale behind Hughes Aircraft Company's decision to select a standard Requirements Management tool. The process followed by Hughes to make the selection of a standard tool is described as are lessons learned during the implementation of the selection process.
A SYSTEM ENGINEERING APPROACH FOR THE MIGRATION OF COMPUTER‐BASED SYSTEMS
Authors: Makhlouf Mahmoud A. , James John H. , Wigfield Edward C. , Wheeler Thomas M. , Modeen Raymond A. , Schaffner Stuart C.
Published: November 2014

In this paper major factors contributing to system migration failures are reviewed. We highlight the need for a comprehensive system engineering approach that can address the inherent complexities of migrating mission critical systems. To address this need, a model‐based approach supported by tools is presented. Central to this approach is the use of a new type of system architecture model called “Loop Relationship (LR) Models.” These models are used to recover the legacy system design, specify the migrated system requirements and proposed system design; and analyze the performance implications of proposed modifications to the legacy system. Finally we will discuss our experience in forming a team to apply the above approach on a number of system migration projects.
EVALUATION OF THE FEASIBILITY OF USE OF A COMMERCIAL OFF‐THE‐SHELF (COTS) OBJECT‐ORIENTED DATABASE MANAGEMENT SYSTEM FOR REAL‐TIME TACTICAL APPLICATIONS
Authors: Gracia Paul , Larson Stephen
Published: November 2014

This paper describes the development and evaluation of a prototype tactical database for a new military command and control system. The database was developed using a commercially available object‐oriented database management system, and was integrated with seven user applications in a heterogeneous networked computer environment. Testing of the database took place as part of the Navy's New Attack Submarine (NSSN) Program Phase I Open System Critical Item Test (OSCIT) demonstration, conducted during late September 1995. The testing showed that use of a commercial database management product to support limited real‐time applications in a tactical command and control system is feasible. This indicates that the Navy could realize significant savings in this technical area through the use of commercially available products.
Engineering Information Systems and the IEEE Std 1220–1994
Authors: Rochecouste Hervé
Published: November 2014

The IEEE Standard for the “Application and Management of the Systems Engineering Process” (IEEE Std 1220–1994) is the first standard that recommends (para. 4.6, 6.8.12) the use of an “Integrated Database” to assist the Systems Engineering Process (SEP). As technology evolves, and projects become more and more complex, the application of the SEP generates megabytes of data that must be managed effectively. This paper analyses the intent of the IEEE recommendations, and discusses the concept of an Engineering Information System in support of the SEP application for the Engineering of Computer Based Systems. Without integration, the independent tools of Requirements Analysis and Management, Design Modelling, Configuration Management etc. may end up removing value from Systems Engineering work.
AN OPEN LETTER TO THE TOOL COMPANIES
Authors: Grady Jeffrey O.
Published: November 2014

All of the requirements tools developed to date for commercial sale attempt to satisfy the largest possible set of functionalities that the developing company is capable of mastering. As a result, these tools tend to be fairly difficult to master by users and for the users to maintain skills. The tool companies tend to focus inwardly on their own tool without sufficient interest in the common environment within which these tools are used. The tool companies apparently feel they have to protect their market share to the extreme of failing to contribute to raising the floor for all.

Engineers in many aerospace companies feel a need for a requirements system that is very simple to use by a wide range of people without intensive initial and recurrent training. But, there are no suppliers of this kind of system. This “open letter” encourages the development of a tool that is focused on the simplest needs that can be supplemented with additional modules to satisfy more advanced needs when the user has matured their process and personnel skills to support those capabilities.

Also, the tool companies tend to ignore the industry interest in universal hooks that would permit two or more tools to be applied on one program without sacrificing some of the fundamental tool features like traceability across the gaps. Many years ago gasoline station operators found that locating stations on all four corners led to more business for all rather than hurting each. A degree of cooperation among the tool makers would have this same effect by expanding the market size.
TRANSITIONING THE SAFER MANEUVERING UNIT FROM FLIGHT TEST TO PRODUCTION
Authors: Hess Cliff , Steele Gail , Hooks Ivy
Published: November 2014

Many programs face the problem of building a single product that mushrooms into new versions or additional products. Requirements reuse can be a tremendous time and cost saver, but only if other essential information is retained when the original requirements are written.

The Simplified Aid for EVA Rescue (SAFER) began as a flight test unit that was flown as a Detailed Test Objective (DTO) on Space Shuttle Mission STS‐64 in September 1994. The SAFER proved its usefulness as an astronaut maneuvering unit and was approved for production immediately after the flight. This paper details the requirements management process used by SAFER and discusses the changes required to go, not just to production, but also to an intermediate version of the product. The SAFER project used Compliance Automation Inc.'s Document Director requirements management tool for the DTO and transitioned to Vital Link, the Window's version of the tool for subsequent products.
Lessons Learned From Use of a Computer‐based Requirements Management Tool in the Environment of a Project Configuration Control Board
Authors: Meilich Abe
Published: November 2014

This paper presents some lessons learned and experience gained in Requirements Management (RM) utilizing a computer‐based tool in conjunction with a Configuration Management process and with the oversight of a Project Configuration Control Board. Computer‐based RM tools should help facilitate systems engineering on large complex system development projects. But, sometimes, the drive to either develop tools or purchase Commercial Off‐The‐Shelf (COTS) RM tools early in the life of a project is often done without a thorough understanding of the process, environment, or culture in which the tools will be used. The individual or group responsible for tool procurement are often not the same as those that will have to manage the tools as part of an overall systems engineering process. Those who are responsible for procuring the tool sometimes get caught up in the flexibility and number of features the tool provides (i.e., typical vendor selection criteria checklists), only to find out later that the flexibility which the final tool choice has must be severely constrained, in order to manage and report the requirements and their dependencies to the Project Configuration Control Board. Even though taken from actual experience, the specifics of the actual projects used as a model and the computer‐based tool names have been deliberately removed from this paper to better focus on the issues addressed in the paper.
The Application of a Tool Like RDD‐100® to Accommodate Traceability from Requirements to Test Results
Authors: Smith Byron
Published: November 2014

This paper will focus on the ability to capture a full thread of traceability, from the inception of a requirement, to the test results that validate that the system (element) designed meets criteria defined by that requirement. As contracting agencies become more and more sophisticated, they are expecting their contracted agents to define a thread of traceability to include the test results that validate a design. The following paragraphs describe a process that can be used to enhance the effectivity of using a tool like RDD‐100® in the System Engineering process.
CRITICAL PROCESS ASSESSMENT TOOL (CPAT) FOR ACQUISITION REFORM IN DOD
Authors: Rountree Richard C. , Crabtree William , Davis David E.
Published: November 2014

Acquisition reform within the U.S. Department of Defense (DoD) has induced a wide variety of innovative engineering methodologies on the part of Air Force agencies such as the Space and Missile Systems Center (SMC) in El Segundo, CA to minimize government risk. One of these methodologies is a set of Critical Process Assessment Tools (CPATs) being developed to support project officers and project engineers: (1) in preparing Requests for Proposals (RFPs), (2) for subsequent source selection or factfinding, and (3) to participate in or review contract execution after contract award. CPATs are applicable to processes that, because of risk, are considered to be critical to execution of the involved contract. The Systems Engineering CPAT (SE‐CPAT) is the overriding element in the set since it is most likely to be critical to the success of a contract when new military or other system functional requirements are to be levied or requirements allocations and/or design must be changed for some reason. Furthermore, the SE‐CPAT serves as the integrator of other multidisciplinary engineering CPATs acting under the Integrated Product Development environment. The SE‐CPAT described in this paper, and available on the Internet, identifies a menu of objectives and other inputs to a RFP, factors and standards for source selection, and key questions for conducting technical evaluations and factfinding, and post‐contract award reviews. Throughout the paper selected SE‐CPAT excerpts are provided.
SYSTEMS ENGINEERING'S ROLE IN THE RFP PROCESS
Authors: Clouse Aaron J. , Shaw Richard
Published: November 2014

Many companies that develop products in the defense industry rely on the DoD Request For Proposal (RFP) process as the principal means for acquiring new business. While the process steps used by each company may vary in the details, the general RFP requirements demand that certain steps be accomplished by all participants. It is also at this early stage of acquisition where the Systems Engineer plays a significant role. This paper presents an outline of the process of responding to DoD Requests For Proposals (RFP's) and discusses the process steps that most naturally involve Systems Engineers. Finally, it points out the benefits of having a well‐documented proposal process.
Technical Objectivity Supporting Systems Engineering for Internal R&D Projects
Authors: Hand James A. , Gilmore Jerold P. , Lawrence  , Freier J.
Published: November 2014

Three capabilities, or intellectual tools, are considered particularly important to Research and Development (R&D); namely Technical Objectivity, Technical Depth and Technical Breadth. In this brief report we deal with the first tool and leave the latter two for a future paper. The paper concentrates on the system engineering process in company‐funded Internal R&D. The intent is to illustrate Technical Objectivity as a tool in addressing internal and external corporate product innovation barriers, and as an essential element in achieving an IR&D product's commercial success in the market place.

The systems engineer's task of identifying, acquiring and applying Technical Objectivity is discussed, including characteristics and applications. This task is applicable (tailorable) to several types of IR&D efforts within the fast moving infotech, biotech ‐ medical, telecommunications, instrumentation/electronics, and engineering/technical services industries, as well as the aerospace and defense industries.

Our main observation is that Total Technical Objectivity for planning and operating IR&D projects is a capability found in a team, rather than in an individual.
SYSTEM REQUIREMENTS ENGINEERING PROCESS
Authors: Field Melvin D.
Published: November 2014

The system requirements engineering process is a systematic and comprehensive approach to the development, allocation and management of functional, performance and interface requirements and design constraints over the system or product life cycle. Users, developers and managers use a common, structured communications media to build and manage, an integrated requirements database to develop, operate and maintain a system or product effectively. System or product quality and timeliness can be improved. Concurrent system engineering is feasible.

A primary objective is to maintain traceability (both down and up) between user requirements and system and/or product design requirements during development and system or product use. The system requirements engineering process is usable for new acquisitions and for product improvements and supports the system engineering process as defined in IEEE P1220 and EIA 632/MIL‐STD‐499B.
Systems Engineering: A Problem of Perception
Authors: Senglaub Michael
Published: November 2014

The characterization of systems engineering as a discipline, process, procedure or a set of heuristics will have an impact on the implementation strategy, the training methodology, and operational environment The systems engineering upgrade activities in the New Mexico Weapons Development Center and a search of systems engineering related information provides evidence of a degree of ambiguity in this characterization of systems engineering. A case is made in this article for systems engineering being the engineering discipline applied to the science of complexity. Implications of this characterization and some generic issues are delineated with the goal of providing an enterprise with a starting point for developing its business environment.
Unraveling the Systems Engineering Lexicon
Authors: Lake Jerome (Jerry) G.
Published: November 2014

Terms related to systems engineering have had a tempestuous history, at least for the years that the International Council on Systems Engineering has been in existence. The term “Systems Engineering” has been at the center of the confusion.

This paper looks at the history and problems associated with defining systems engineering and then applies a systems engineering approach to provide definitions of what systems engineering is and what systems engineering does.

The definitions provided in this paper are not to end the discussion but to stimulate more discussion.
Modeling the Realm of Systems Engineering
Authors: Ju Wilfred T.
Published: November 2014

A new view of systems engineering is presented. The domain within which systems engineers exist is modeled and a decision process is defined. Examples of systems engineering, used to operate the Liberty Chapter of the International Council on Systems Engineering, highlight applications of the model and the decision process.
AGGREGATE SYSTEMS ARCHITECTING
Authors: Grady Jeffrey O.
Published: November 2014

The INCOSE definition of a system recognizes the existence of the components, items, or elements of which the system consists. This paper addresses the development of systems where those components are systems themselves in several specific subsets of the full range of possibilities with which a developer may be confronted. The developer should evaluate alternative system functionalities and configurations leading up to selection of a preferred solution, but this same well understood activity can be extended to embrace the development of families of systems to serve several needs of interest to the developer and its potential customer base. The tool makers are challenged to support this capability.
Architecting Principles for Systems‐of‐Systems
Authors: Maier Mark W.
Published: November 2014

While there is growing recognition of the importance of “Systems‐of‐systems,” there is little agreement on just what they are or on by what principles they should be constructed. This paper proposes a taxonomy of these super‐systems and exhibits a basic set of architecting principles to assist in their design. While several heuristics are particularly applicable to systems‐of‐systems, the key insight is the central role played by communication standards. The enabling architecture of systems‐of‐systems is non‐physical, it is set of standards that allow meaningful communication among the components. This is illustrated through existing and proposed systems.
How to Survive as a Change Agent in Hostile Territory: “Principles of Process Improvement Terrorism”
Authors: Garcia Suzanne M.
Published: November 2014

Prophets have always run the risk of being disregarded in their own land. Many champions of organizational change face the same problem as the prophet–their message is clear, but it is not attended to by those in positions of power to make the necessary changes. I call these prophets of change “process improvement terrorists”, not because they are physically violent, but because they are often forced to work underground, outside the conventional power and communication channels of the organization, their weapons are obtained from unconventional sources and are applied in unconventional ways, and their situation is much like that of the terrorist – often in hostile territory, needing to take drastic but often subtle actions to get their message heard and acted upon. Terrorism is used as a “processmorph” for process improvement (see body of paper for a definition). This paper provides survival and (hopefully!) success strategies for the change champion who has had to go to ground and become a Process Improvement Terrorist (PIT).
SPENT NUCLEAR FUEL APPLICATION OF CORE® SYSTEMS ENGINEERING SOFTWARE (U)*
Authors: Grimm R. J.
Published: November 2014

The Department of Energy (DOE) has adopted a systems engineering approach for the successful completion of the Spent Nuclear Fuel (SNF) Program mission1. The DOE has utilized systems engineering principles to develop the SNF Program guidance documents and has held several systems engineering workshops to develop the functional hierarchies of both the programmatic and technical side of the SNF Program. The sheer size and complexity of the SNF Program, however, has led to problems that the Westinghouse Savannah River Company (WSRC) is working to manage through the use of systems engineering software. WSRC began using CORE®, an off‐the‐shelf PC based software package, to assist the DOE in management of the SNF Program. This paper details the successful use of the CORE® systems engineering software to date and the proposed future activities.
DOORS™ TO AUTOMATED METRICS
Authors: Miller William D.
Published: November 2014

This paper describes the automation of metrics data collection and analysis using the Dynamic Object Oriented Requirements System (DOORS™) tool from Quality Systems and Software (QSS). Using the concept stated by Crosby that “Quality is conformance to requirements”, DOORS tracks the completeness, timeliness, and cost of project deliverables that are the outputs from standard processes. The traceability links in DOORS bind the project and process metrics together to higher level organizational objectives. Metrics automation based on a foundation of standard processes, methodologies, tools, and environment provides a quantum improvement in the objectiveness, cost, and fidelity of metrics. Also, metrics definitions important to organizations change over time. The change control capability of DOORS provides complete history to the ongoing metrics collection and analysis to provide a continuum from past performance to the present and future.
“MIL‐STD‐001” ‐ A SYSTEM STANDARD (THEORY OF SYSTEMS = ACQUISITION REFORM!*)
Authors: Marshall John A.
Published: November 2014

Product improvement means product behavior understanding; Acquisition process begs for it. Needed: more focus and vision on product performance: Without it, at best incremental improvement; With it, the bigger, better view for system Continuous Process Improvement (CPI). Here is a new & improved view.
ADAPTATION OF A SOFTWARE REQUIREMENTS ENGINEERING METHOD TO THE SYSTEM LEVEL FOR SOFTWARE‐INTENSIVE SYSTEMS
Authors: Crowe Dennis , Smith Howard , Haberli Greg , Cohen Robert M. , Lykins Howard
Published: November 2014

This paper reports on an investigation of the adequacies and benefits of applying software‐level analysis techniques to system‐level requirements activities, with specific concern for software‐intensive systems. The investigation takes the approach of adapting a well‐defined, mathematically precise, software requirements engineering method to a real‐world, complex, system engineering problem. This case study is a preliminary application of the Software Productivity Consortium's CoRE method, which has been applied to embedded real‐time applications, to developing requirements that will be allocated to the landing capability of a military combat helicopter. This effort takes a step toward model‐based system engineering by addressing some of the representational issues and semantic gaps that make it difficult to model subsystem‐level behavior from the system level without commitment to system architectures and designs. This paper proposes conceptual representations that support multitiered abstraction of performance measures and requirements for analyzing interactions between elements of a system and their external environments.
VALIDATION OF TRADE OFF STUDY METHODS APPLICABLE TO PACKAGE‐BASED ENGINEERING
Authors: Botten LeRoy H.
Published: November 2014

A mature tradeoff study methodology, developed over the past 25 years, is shown to be consistent with emerging package‐based engineering methods. The tradeoff study methodology and related experiences in implementing complex systems from commercial off‐the‐shelf (COTS) and legacy components are described. Validation of the methodology as a tool for Integrated Process Team use in package‐based engineering is presented.
THE APPLICATION OF QFD TO SUPPORT A MISSION NEEDS ANALYSIS
Authors: LaSala Kenneth P. , Phillips Brent W. , Wallace William E.
Published: November 2014

The technique of Quality Function Deployment (QFD) has been applied to an analysis of the mission needs for the existing NOAA atmospheric observing system. QFD shows clear relationships between customer needs and the observing system capabilities. QFD will play an important role in the continued evolution of both the customer needs and the observing system itself. We believe that QFD can contribute significantly to the development of Government mission needs analyses for systems similar to our observing system. Although this paper discusses the use of QFD within NOAA, the views expressed in this paper are solely those of the authors and do not necessarily represent the views of NOAA.
Evaluation of Risk Management Strategies for a Low‐Cost, High‐Risk Project
Authors: Shishko Robert , Jorgensen Edward J.
Published: November 2014

This paper summarizes work in progress to define and implement a risk management process tailored to a low‐cost, high‐risk NASA mission–the Microrover Flight Experiment (MFEX, commonly called the Mars microrover). The tailored risk management process is described along with the extensive data collection, documentation, and quantitative analyses that are being performed. This effort has the explicit purpose of trying, evaluating, and documenting new risk management techniques so as to help not only the MFEX mission, but future missions in the same risk class.
REFINEMENT OF THE REQUIREMENTS DEFINITION (RD) CONCEPT IN SYSTEM DEVELOPMENT: DEVELOPMENT OF THE RD AREAS
Authors: White Michelle M. , Lacy James A. , O'Hair Edgar A.
Published: November 2014

To alleviate problems in performing the definition of requirements, it is necessary to review and understand the practice of requirements definition (RD). Refinement of RD is necessary in order to improve the processes and effectiveness. The purpose of this paper is to present some results of research performed to refine the RD concept in System Development. The objectives were to obtain an organized, coherent and unified representation of RD. Results of this research will enhance communication among the engineering communities, provide guidance in the effective development and management of requirements and provide the avenue for comparison, measurement, and improvement. Development of the RD representation consisted of identifying the areas of RD, primary functions of each area, and interfaces. The first step, identifying the RD areas, is presented in this paper. Documented RD representations were analyzed to determine a preliminary set of RD areas. A total of five areas were determined. Further research was performed to find evidence to reinforce the five areas determined. The procedures for developing the RD areas are presented. The RD areas identified were: Requirements Acquisition, Requirements Analysis & Synthesis, Requirements Correlation, Requirements Communication, and Requirements Management.
TEN LESSONS LEARNED FROM IMPLEMENTING CONCURRENT ENGINEERING AND IPTS
Authors: Popick Paul R. , Sheard Sarah A.
Published: November 2014

Concurrent engineering (CE) and integrated product teams (IPTs) offer many advantages in product quality and cycle time reductions. Many companies are beginning to organize projects using IPTs, but the transition to CE and IPTs requires implementation details that are not commonly discussed in the literature. This paper covers ten of the most important lessons we have learned in our implementation of CE and IPTs.
A TEAM METHOD TO CAPTURE CONCURRENT ENGINEERING LESSONS LEARNED
Authors: Popick Paul R. , Smith Craig L.
Published: November 2014

The merits of Concurrent Engineering (CE) and Integrated Product Team (IPT) approaches are widely discussed (Miller 1993) but little attention has been given to methods to identify areas of difficulties and improve implementation. This paper describes a team based approach to capture, analyze, and deploy lessons learned. The lessons learned process is described with a process flow diagram and through charts developed in the lessons learned sessions. Several observations about learning and improving CE and IPTs are given.
Virtual Prototyping: A Powerhouse For Integrated Product & Process Development
Authors: Zittel Randy C.
Published: November 2014

The use of computer prototypes in industry and defense programs has exploded to become a significant tool used in all aspects of the systems engineering and development processes. Carried along with the electronics revolution, virtual prototypes are becoming more capable, accurate, understood and accepted. Now the logistician, decision maker and end‐user are finding valuable integration of engineering simulation with applications and operational procedures.

The US military's program is developing a global network that allows for the modeling of integrated computer prototypes where one complete system, and sometimes complete military units of multiple and dissimilar systems, can be computer simulated long before formal design. Never expecting to combine war games with virtual prototyping, the easy variability obtained from computers allows for feedback to doctrine developers as well as the system builders that dramatically improves the requirements.

Examples across industry prove virtual prototypes are showing greater returns on investment than ever expected. These savings empower better capabilities, open up new opportunities, and provide a better product sooner.
AN IEEE STD 1220–1994 BASED SYSTEMS ENGINEERING LIFE‐CYCLE REFERENCE MODEL, IMPLEMENTED IN RDD‐100®
Authors: Fossnes Terje
Published: November 2014

This paper addresses the motivation and some of the effort undertaken to develop and describe a Systems Engineering Life‐cycle Reference Model and a Generic Systems Engineering Management Plan (SEMP) for introduction of the Systems Engineering process into an organisation.

The work is based on the IEEE Std 1220–1994 “IEEE Trial‐Use Standard for Application and Management of the Systems Engineering Process” and is modelled in the Systems Engineering tool RDD‐100® from Ascent Logic Corporation. A description of the principles of the content and how projects can utilise the model are included. Finally the future objective of the initiative is addressed.
Integrated Risk Assessment: A Case Study
Authors: Roberts Barney B. , Winterlin Ronald C.
Published: November 2014

The customer was the project manager for a research facility that is to fly on the International Space Station Alpha. The facility consists of two racks, plant and animal research units, and the associated ground and support systems.
SYSTEMS ENGINEERING: Myth or Reality
Authors: Kasser Joe
Published: November 2014

Each year at the National Council of Systems Engineering (NCOSE) symposium lots of dedicated people spend a lot of energy assessing, measuring and educating people about an incomplete body of knowledge (systems engineering). The incompleteness is due to the lack of a definition of what that body of knowledge is supposed to cover. Now every systems engineer knows that it is important to capture all the requirements as early as possible in the program, so why have the systems engineers not defined systems engineering (SE)? This situation led me to hypothesize that there was no such thing as systems engineering (after all, if the experts in NCOSE can't come up with one, then there isn't one).

This paper analyzes the functions performed by systems engineers, shows there seems to be no unique body of knowledge to SE, which explains why the NCOSE experts have failed to define SE. The paper then looks outside the SE box for the reasons for the failure, and provides a surprising conclusion.
Project Management, Systems Engineering and the Amazing DNA Double Helix
Authors: Smith Byron , van Gaasbeek Jim
Published: November 2014

What possible connection is there between Project Management, Systems Engineering and DNA? The answer is the double helix and the amino acid pairs. It is the contention of the authors that, just like the DNA double helix, Project Management and Systems Engineering could also be thought to have a double helix. A unique amino acid like Thiamin appears at one location on a DNA strand, it is opposed on the opposite strand by Adenine. This same kind of synergy can be found in the relationship between Project Management and Systems Engineering. In our terms, however, we don't deal with amino acids but tasks or responsibilities. When an integrated master plan is prepared by Project Management, for example, Systems Engineering is inevitably called to provide significant contribution to that plan including development of a SEMP. During the course of this paper this and other corollaries will be discussed. The discussion will also focus on how a strong bond between the two disciplines can have a significant impact on a project's success. Furthermore, the authors will focus on the fact that this unique Project Management/Systems Engineering helix forms the nexus at the core of a process that can be replicated to other projects much in the manner that the DNA can replicate itself.
Decision/Risk Analysis Software: Survey for Trade Studies
Authors: Buede Dennis M.
Published: November 2014

This paper provides an overview of the PC and Mac‐based software market for decision/risk analyses. Decision/risk analysis is a powerful methodology for conducting systems engineering trade studies and selecting system designs because the methodology explicitly deals with conflicting performance and cost objectives, uncertainty and risk preference. Information on 28 software packages is provided. Before describing these packages several applications of decision/risk analysis in systems engineering design are presented. In addition, technical performance, usability, compatibility and output documentation issues are discussed. Finally, we forecast the future trends for this software.
THE VALUE OF TWELVE SYSTEMS ENGINEERING ROLES
Authors: Sheard Sarah A.
Published: November 2014

A description of the value of systems engineering, long sought by practitioners in order to justify funding for systems engineering, must be explained in the context of clear systems engineering roles. A companion paper defines twelve systems engineering roles in detail. Value added is not a simple concept. In manufacturing terms, value added work changes the product that is delivered to the customer. This paper suggests a more robust definition of value added that applies to the systems engineering environment, including managing work, defining the problem, and reducing risk. Then, this paper explores the value of each of the twelve systems engineering roles in terms of this definition of value added and other considerations.
A CONCURRENT PROCESS FOR DEVELOPMENT AND VALIDATION OF OPERATIONAL REQUIREMENTS
Authors: Anderegg Alfred H.
Published: November 2014

The FAA's Oceanic and Offshore Integrated Product Team has established a process for development and validation of system level requirements through the use of Joint Application Design. This process is initiated with operational requirements set in the context of a concept of operations. The concept and system behavior are wholly contained within a requirements model. The goal is to collect user inputs that compliment the operational requirements with a level of detail necessary to complete a system level specification in the model. The model will then be used to validate the requirements against the concept of operations and target benefits for the system build. This paper describes the requirements development and validation process and preliminary results of the application of the process.
Software Design of System Requirements Utilizing Set Theory Model for Anomaly Handling
Authors: Sanchez James A.
Published: November 2014

In 1995 Ronald Carson developed a mathematical model for system requirements analysis (SRA) utilizing set theory to explicitly treat unwanted or unexpected conditions that may be experienced by the system being analyzed. He showed that the SRA model can be used to derive completeness criteria. He claimed that the highest utility of the model would be found in the area of software requirements because of the focus on system states.

A simple example using a Power Distribution Unit (PDU) was made in order to clarify the salient points. This simple example had only three states and six transitions, which were identified as nine antecedents (conditions which precede). Eight requirements were generated for the PDU.

In this paper, the requirements for this simple example, along with its principles, are used to construct a simple software implementation in graphical fashion in order to test the effectiveness of the methodology for software.

In conclusion, the SRA model utilizing elementary set theory needs some refinement for software applications. Though the method is rigorous, problems surface because of 1) ambiguities in language, 2) unforeseen conditions, 3) undefined initial conditions, and 4) probability density function of primitives.

In addition, the start condition of the timers are undefined, as are the initial states of primitives, e.g. valid input, degraded input and inhibit output and degraded output.
IMPLEMENTATION OF DYNAMIC AIRCRAFT MODELS USING MATRIXx
Authors: Redling Thomas J.
Published: November 2014

Today, the design of modern control systems is greatly facilitated by the use of computer based design and analysis tools. More specifically, the design of aircraft flight controls has benefited immensely from these tools. The ability to simulate control laws in a virtual environment allows for the design of complex algorithms whose functionality and performance may be evaluated during the design phase of a project rather than during the flight test phase. Besides improving the control engineer's ability to create a superior design, these tools reduce cost by uncovering design flaws and performance deficiencies before the flight test program commences.

Before one can begin the analysis of a set of control laws, an accurate representation of the plant being controlled must be derived. In the case where one wishes to evaluate an autopilot, the plant is the aircraft being controlled. Therefore, the dynamics of the airframe must be modeled. This paper presents a framework for the derivation of a Laplace domain representation of an airframe based on raw aerodynamic data from both wind tunnel testing and actual flight tests. This representation can then be implemented using a dynamic systems modeling tool such as MATRIXx. This process has been carried out successfully on aircraft such as the C‐141B and A‐4D at AlliedSignal Aerospace Guidance and Control Systems by the author. Once this model has been generated, it is used to design and analyze the control laws targeted for that airframe.
USING PROBABILISTIC ANALYSIS TOOLS TO SIMULATE ALTERNATIVE PROJECT STRATEGIES
Authors: Keizur Alan E. , Miller Ian
Published: November 2014

Systems Engineers and project managers routinely analyze and compare sets of alternatives in an effort to identify the best design or strategy to achieve the project's stated objectives. Software tools are available for performing such tasks, but the issue of uncertainty is often given little or no attention.

This paper introduces the concept of analyzing and comparing project alternatives using probabilistic methods and provides an illustrative example of the use of software tools to simulate such analyses.
ASSESSING THE QUALITY OF LEGACY APPLICATIONS WITH PERSISTENT DATA: ASSESSING THE BASELINE FOR SYSTEM MIGRATION
Authors: Campbell Pamela D.
Published: November 2014

Consistent comparison of applications which store data, written in different languages and using varying types of Database Management Systems, requires an assessment that measures the system(s) in accordance with a well defined, repeatable set of criteria.

This paper describes a tool and methodology (MARS) for identifying the lifecycle risks related to data within existing applications, and describes the taxonomy of data quality assumed during the development of the assessment methodology.

An example question is shown, with the rationale and method for applying the question. The relationship of the data quality taxonomy is also described in terms of database focus areas, such as data integrity and data dictionary, that are of interest to those working operationally with databases.