bluuebunny/crossref_metadata_2025 huggingface dataset:
SYSTEM ENGINEERING: COMMUNICATING FROM A SYSTEM DESIGN DATABASE
Authors: Baker Loyd
Published: November 2014

During a recent System Engineering Tool Users Group meeting, a common complaint voiced by users was, “getting the desired data / information out of the project's analysis/design database in a timely fashion, and in a usable form, has been a major obstacle to the adoption of automated system engineering tools”. Keeping project members, management, and customers informed about the evolving system specification/design is crucial to maintaining a competitive edge. If the required project data/information can not be accessed, documented, and shared quickly enough, the expected benefits to be gained by communicating from a comprehensive project analysis/design database may not be realized. This paper discusses a process that makes publication of project documents a by‐product of the engineering/management process, providing increased productivity due to improved communication of requirements, design decisions/rationale, system verification, and traceability of system changes.
A SYSTEMS ENGINEERING APPROACH TO FAULT ISOLATE AND ASSESS DEGRADED MODES IN A REAL‐TIME BUILT‐IN‐TEST ENVIRONMENT
Authors: Sanchez James A. , Systems Radar
Published: November 2014

This paper describes a methodology that was successfully implemented as an experiment within a tactical radar program to create a software package with features superior to traditional customized software. The critical elements of the system are described in a way that makes it easier to create the package. These elements are then modeled, and a software package is created.

For the systems engineer the package has made transformations from specification to executable symbols so economical that the cost of making changes becomes almost inconsequential. A development effort that took six man‐months in past years was reduced to a one hour effort, as illustrated in Figure 1. Moreover, the software package could be transported to any similar platform for use in radar software development efforts.

The result is a reliable tool that has uncovered errors encoded by programmers, as well as system engineers, in prior years. The ease of use and consistency of results empowers the system engineers who are not trained as software developers. Errors due to the shear volume of detailed specifications or miscommunication among various people are greatly reduced. When hardware and software efforts are developed in parallel, changes to the target machine's I/O interface can be implemented quickly.

In the world of personal computers, the user often has any number of software packages from which to choose. The user examines the limitations and features of various packages and makes a comparison. A particular package may not meet a specific user's needs, whereupon the persevering user either works with what is available or communicates the need for a new or enhanced software package.

Using the methodology described in this paper an engineer can present the needs of the system as 1) fundamental pieces of information separated into logical groups, 2) rules of dependence among the groups, 3) attributes of each related group of information, and 4) functions to be performed on the information. A mathematical model may then be constructed and realized in the form of a reusable software package. This package is then judged on the basis of meeting the user's needs, including ease of installation, cost, user friendliness and similar “customer” criteria.
THE UNWRITTEN LAWS OF SYSTEMS ENGINEERING
Authors: McClinton David F.
Published: November 2014

The paper states some of the unwritten but spoken laws that abound in any engineering project. The laws are really simple basic truths that arise in typical engineering discussions. We didn't hear them in engineering school but they came through loud and clear in that school of hard knocks, the engineering project. The initial three laws are (1) Everything interacts with everything else; (2) Everything goes somewhere; and (3) There is no such thing as a free lunch. Several other laws capture the lessons learned in various activities in the systems engineering process.
Metrics Concepts and New Directions
Authors: Edelmann Richard , Miller William D. , Rhodes Donna H. , Wilbur Ann L.
Published: November 2014

This paper presents a brief history of the National Council on Systems Engineering (NCOSE) Metrics Working Group (MWG), fundamental concepts, key issues and future plans.
A Draft Systems Engineering Tools Taxonomy and Mapping to a Meta‐Process Model
Authors: Oliver David W. , Steiner Rick
Published: November 2014

The goal of this paper is to provide a draft classification of tools that may be useful to systems engineers in understanding tool choices for the automation of their work. An accepted classification will require input from NCOSE members and modification of the draft.

The tools automate the systems engineering process. Each kind of tool performs particular functions and captures particular sets of information. In this paper the tools are mapped to a meta‐model for the systems engineering process. That meta‐model describes the core systems engineering steps and gives an information model for each step. Mapping the tools to the meta‐model defines the functions performed by each tool type and the information it captures. The mapping also establishes the interfaces between tool types.
COLLABORATIVE SYSTEM ENGINEERING APPROACH TO AN EVOLUTIONARY OCEANIC SYSTEM DEVELOPMENT
Authors: Feerrar Wallace N. , Sinha Agam N.
Published: November 2014

The Federal Aviation Administration (FAA) is in the process of developing significant new capabilities in the Oceanic Air Traffic Management (ATM) System in response to the increasing demand on the system and the needs of the users of the oceanic air traffic management system. The FAA has planned for an evolutionary approach to the oceanic system development with a series of successive “Builds” adding new operational capabilities. The Center for Advanced Aviation System Development (CAASD) at The MITRE Corporation is providing the system engineering support to the FAA in this effort. One of the major components of the R&D system engineering process is the generation/validation of operational concepts and requirements for the successive Builds. A second, equally important, element is the requirements tracking/traceability process to ensure that the system evolution does indeed provide the operational capability to the users/operators/maintainers of the system. This paper describes some innovative measures (including the use of CASE tools) for the life cycle of the evolution of the Oceanic ATM System.
Business Reengineering for Information Technology: From Business Process to System Requirements
Authors: Bohner Shawn A. , McGowan Clement L. , Harlow Mary M.
Published: November 2014

The bridge between business process and information systems reengineering is all too often missing from the roadmap of reengineering efforts. When process and system engineers get to this transition, they discover a rickety old bridge with steep terrain on either side of a wide chasm. Recognizing this dilemma, we developed the Business Reengineering for Information Technology (BRIT) approach that systematically transitions from business process to information systems engineering. BRIT is designed to handle a wide range of reengineering factors including: “best practices,” COTS applications, non‐standard business processes, and change situations ranging from continuous improvement to radical restructuring. This proven approach is described here with relevant examples of its applications.
COTS/NDI ASSESSMENT AND SELECTION METHODOLOGY
Authors: Verma Dinesh , Powers Tipmuny , Blanchard Benjamin S. , Giffin Ralph G. , Webb Rowland , VanBuskirk David
Published: November 2014

In an effort to radically reduce system development times and necessary resources, the Department of Defense (DoD) is emphasizing utilization of “Commercial‐Off‐The‐Shelf (COTS)” or “Non‐Developmental Items (NDI)” in the development of new systems and the upgrade of existing systems. This paper outlines a methodology, involving the integrated application of Quality Function Deployment (QFD) and Analytic Hierarchy Process (AHP), to facilitate the prerequisite analysis and evaluation before making a commitment to a COTS/NDI alternative. While this COTS/NDI analysis and evaluation methodology is generic in its applicability within the system engineering process, in its current state the model based on this process has a system supportability bias.
CONDUCTING A TECHNOLOGY MANAGEMENT ASSESSMENT
Authors: Mackey William F.
Published: November 2014

Technology management is concerned with minimizing the risks associated with new technologies and ensuring the successful integration of those technologies into systems and operations. The role of an Advanced Technology Manager is to identify the technologies that will enhance project operations, identify applications throughout the project that can benefit from appropriate new technologies, and ensure that these technologies are developed and/or transferred for insertion into operations.

This paper describes the past year's experiences conducting technology management assessments for the Mission Operations and Data Systems Directorate (MO&DSD) of NASA's Goddard Space Flight Center (GSFC) and the CSC Systems, Engineering, and Analysis Support (SEAS) project. These assessments are based on a technology management process and on the technology evaluation and analysis methodologies developed for the NASA/GSFC New Technology and Data Standards Manager [Mackey 1995]. The paper includes a brief description of the six stages of technology commitment and focuses on the SEAS activities related to the Technology Awareness Stage. Note that the technology management process discussed in this paper is undergoing evaluation and will mature as it is implemented in the coming months.
THE EMERGING ROLE OF TELECOMMUNICATIONS: CREATIVE APPLICATIONS OF SYSTEMS ENGINEERING METRICS
Authors: Buford Carolyn
Published: November 2014

The rate of change in telecommunications business environments has a major impact on the types of key issues worked on by systems engineers. This paper describes a revolutionary prospective on emerging technologies in telecommunication as it impacts systems engineering metrics. The need for new creative metrics applications using telecommunications is exceptionally high for both new and existing business areas. New unique applications are emerging rapidly, with each application changing further the way business is done and the needs for evolving a particular business segment.

With these changes in process, planning is essential. The more flexible and creative the planning approaches, the longer the utilization lifespan of the systems. Customers need to be involved in all aspects of the evolutionary process because they play key roles in the process resulting in new and better systems. Progress will be measured with ever‐changing metrics on a flexible metrics framework for gathering information. Tools will be developed to support the entire process from initial goal statement, strategic planning to user access, usage, and evaluation. These developments are the basis for a new world interaction for the concurrent involvement of business, community, and individual.

“You have to go twice as fast in order to stay in place.”—Lewis Carroll, Through the Looking Glass
Applying Automated Systems Engineering Tools During The Proposal Process
Authors: Smith Byron J.
Published: November 2014

The proposal process is often characterized by frenzied activities to define a design solution and process by which the solution is to be met. These activities are often compressed into a 45 to 90 day turnaround from the time an RFP is received to the time that a deliverable proposal package must be submitted. Typically, the proposal package contains a technical section that defines how a company is going to address the needs described in the RFP, a cost and planning section defining a cost and work breakdown analysis, a preliminary Systems Engineering Management Plan (SEMP) and a preliminary Integrated Master Schedule. How can tools play a role in the preparation and submittal of a first class proposal package? Traditionally, different tools have been applied to address different aspects of this problem domain. Specific tools were incorporated to address the Program Management aspects of the proposal process. Other tools were deployed to create a plan to describe System Engineering activities. Still other tools were employed to address the design and implementation solution. Because COTS tools have become more sophisticated, it now possible to employ them throughout the proposal process including generation of a SEMP. This paper will focus on how that can be accomplished.
SLATE and the Proposal Process
Authors: Kearney David , Sampson Mark
Published: November 2014

Through the use of a process approach and Systems Engineering tools, a 3x proposal productivity improvement is available. This paper describes an approach to organizing the RFP, gathering the proposal response information, and proposal generation process using SLATE object‐oriented engineering groupware. Approach, proposal development and management process, lessons‐learned, as well as proposal reuse issues are discussed.
Using Object‐Based Simulations for Exploring and Testing Complex Systems
Authors: Schoening William W.
Published: November 2014

Object based (and objected oriented) software design of models and simulations frequently focuses on the top down structure of individual players whose components behave in highly predictable ways. Electronics, engines, missiles, cars, tanks, and satellites give well known responses to inputs defined by the designing engineers. These same object based concepts, coupled with a few additional guidelines, can be applied with striking results to the simulation of complex systems of independent objects whose behavior is not predictable. The trick is to recognized that organization and cooperation between independent objects is a feature of the behavior of the objects themselves rather than some global entity that imposes the organization from above.

Guidelines for turning object‐based models and simulations of real world systems into highly flexible tools for exploring and testing are discussed. Simulations that follow these guidelines give analysts the necessary visibility so they can be trusted and used for exploring requirements and even testing products before the products themselves are built. The guidelines have evolved over the past seven years based on experience with a variety of software simulation environments and tools to simulate complex systems.
A PRACTICAL EVALUATION OF DATABASE RE‐ENGINEERING TOOLS
Authors: Owens David A. , Bighash Iraj
Published: November 2014

The objective of this study was to investigate tools and processes for evolutionary migration of disparate, legacy databases into a single logical design and a new physical implementation. We began by researching the availability and capabilities of current database re‐engineering tools. After reviewing literature on available tools, we selected several candidates for an in‐depth evaluation. We established a practical evaluation approach which exercised the candidate tools against our proposed re‐engineering process using a subset of the databases in an existing legacy system. The study also included investigating approaches for migrating legacy applications to use the new database design and physical implementation. Based on our evaluation, we recommended a set of tools to support our proposed database re‐engineering approach. These recommendations are directly related to our study project, and may not be applicable to other large‐scale, legacy database re‐engineering projects.
USING MS ACCESS TO MANAGE REQUIREMENTS
Authors: Bell Marty , Jones David A.
Published: November 2014

Most commercially available tools that manage requirements are targeted for large projects. Small projects may find them bulky and cumbersome to use for managing a relatively small number of requirements. This paper describes a requirements management tool that is easy to use while providing requirements traceability from upper level specifications to lower level specifications. The tool is called Tracker and is successfully being used on a small project.

This paper describes the tool in detail. Advantages and limitations are discussed. A comparison is made to the “INCOSE Requirement Management Working Group Suggested Possible Tool Features”. Benefits and cost estimates are provided. A sample screen and reports are shown and described. Attributes for each requirement is stated and tool performance is discussed.
Enterprise‐Level Regulatory Analysis and Requirements Management
Authors: Latorre Richard , Sampson Mark , Tominey Kathryn , Wildung Nancy J.
Published: November 2014

To improve overall operational efficiency, a formal requirements management program has been initiated at the Pacific Northwest National Laboratory1. The goal of this program is to develop a robust, dynamic, integrated, informative decision base, for Laboratory‐wide use instead of the more typical assemblage and maintenance of many specific “product line” or “product” requirements.

The external requirement documents that regulate the Laboratory's activities include U.S. Department of Energy (DOE) Orders, Code of Federal Regulations, State of Washington regulations, industry standards, Tribal and local government consent agreements, contracts, city and county ordinances, other Federal interagency agreements, and Battelle Memorial Institute policies. When these documents get updated or revised, these changes can affect the Laboratory's work.

The current estimate is that hundreds of external requirements documents yield thousands of individual external requirements. These documents also have a high degree of variability in format and content, both in a particular document and between document types. Given the large number and scope of issues encompassed by these requirements, our review found that the “historical situation” (i.e., information distributed from personal computers, lists, manuals, procedures, correspondence, and personal memory) was no longer sufficient. No unified requirements analysis set identified all of the individual, applicable external requirements in readily retrievable form, nor were the external requirements linked to the systems to which they apply.

Similar external requirement document integration efforts by other organizations have produced work that is obsolete by the time they publish it, because of the failure to address the dynamic nature of the external requirements documents. This report describes an automation tool (“System Level Automation Tool for Engineers” [SLATE]) that we use to support requirements analysis and the ongoing management of requirements. Experience with this tool as a key element of requirements analysis and management in a timely, cost‐effective, Laboratory‐wide manner is discussed.

Pacific Northwest National Laboratory is operated by Battelle Memorial Institute for the U.S. Department of Energy under Contract DE‐AC06‐76RLO 1830.
USE OF CORE™ IN THE SYSTEM ENGINEERING OF AN ANALOG ASIC
Authors: Gardner John R.
Published: November 2014

This paper describes the Systems Engineering process utilized to design and document a high speed, mixed signal, Application Specific Integrated Circuit (ASIC), using CORE™ as a requirements traceability and design tool. The paper describes the problem, the design process used and the ways that CORE™ facilitated the process. It shows how CORE™ aided in causing complete design definition through an iterative process and generating the final design documentation.
Specifying A System Using ERA Information Models
Authors: Baker Loyd , Long James E.
Published: November 2014

Stating the requirements for systems or business processes as a hierarchical collection of English text that can only be analyzed/verified by human inspection has proven time and again to be labor intensive and generally, inadequate. Projects employing a traditional document‐centered system engineering approach have experienced significant numbers of mis‐interpretations of the customer's requirements, or late‐detected design errors results in increased costs, schedule slips, reduced capability, or canceled programs. We have historically fixed requirements problems, that should have been understood and resolved early, during integration and test where it is more costly to identify and fix. Now that computerized system engineering support tools are available on the engineer's desktop, the leading edge aerospace/commercial corporations are transitioning from a document‐centered to a model‐driven system engineering approach to developing, analyzing, and managing explicit system/process specifications. Information and operational models (of varying levels of detail) not only aid in the understanding and communication of intentions such that incorrect assumptions can be eliminated early, they directly support the develop of system verification plans.
DECISIONEERING—A PROCESS SKETCH FOR DECISION SUPPORT SYSTEM DEVELOPMENT
Authors: Wirth John M. , Mar Brian W.
Published: November 2014

Developers of military command and control decision support systems need to use a decision‐based and user‐centered process for product development. The process must integrate the system's human decision‐maker (system operator, or user), with the other key system components—software and hardware.

Decisioneering is a decision‐based, user‐centered process that provides this integration. Its objective is to improve the performance and safety of human‐computer partnerships in process monitoring and control. The approach emphasizes a clear understanding of the operator's cognitive needs and decision‐making environment. Research suggests (Wirth 1995) that the decisioneering methodology should begin as a structured, iterative, build‐and‐test life‐cycle and would encourage (perhaps require) early and committed operator involvement.

Several related technical fields (systems engineering, software safety, human‐computer interaction, decision‐making, and cognitive engineering) each contain significant parts of a user‐centered, decision‐based approach. Their salient points are summarized and a sketch of the decisioneering process is given. Conclusions and recommendations suggest methods to implement the decisioneering process for decision support system product development.
TWELVE SYSTEMS ENGINEERING ROLES
Authors: Sheard Sarah A.
Published: November 2014

Twelve roles are described which are occasionally or frequently assumed to constitute the practice of systems engineering. Some roles fit naturally as life‐cycle roles, others fit the Program Management set of roles, while still others are not normally thought of in either group. Interactions between the roles are discussed, and the systems engineering roles assumed by the papers in the inaugural issue of Systems Engineering, the Journal of INCOSE, are compared to these categories.
ANATOMY OF THE ENGINEERING OF A SYSTEM
Authors: Harwell Richard , Martin James N. , Lake Jerome (Jerry) G. , Velman John
Published: November 2014

The anatomy of the engineering of a system relies on a uniform approach using an elemental “building block” approach. This approach is applicable at any layer in a system development, whether it be the total system solution, a supplier's sub‐system, or a component provided to a supplier. There are four elements of this fundamental building block: (1) the system, (2) the end product, (3) end product subsystems, and (4) the enabling subsystems. This building block approach was introduced in IEEE 1220–1994 “Application and Management of the Systems Engineering Process,” and will be a central theme of the evolving EIA/ANSI Standard for applying the systems engineering process to the engineering of a system.
A CONCEPTUAL FRAMEWORK FOR A CUSTOMER‐CENTERED SYSTEM DEVELOPMENT LIFECYCLE MODEL
Authors: Scotti Richard S. , Gambhir S. S. Gulu
Published: November 2014

This paper is divided into two parts. The first contains a survey of various system development lifecycle models, including the Waterfall, Spiral, and Evolutionary Models. The second part introduces a conceptual framework for a new approach to complex, large‐scale system developments based upon a customer focus throughout the system development lifecycle. This customer‐focused approach utilizes automated Concept of Operations (CONOPS) and group dynamics techniques to allow greater understanding of end‐user ‘actual’ needs by system designers via more productive interactions. This approach is based on the development and use of detailed user objectives and critical success factors prior to and separate from their mapping into basic and derived system requirements. It provides a means for capturing previously obscure requirements within the user environment and mindset.
The Architectural Metaphor as a Foundation for Systems Engineering
Authors: Hilliard Richard F. , Rice Timothy B. , Schwarm Stephen C.
Published: November 2014

Over the history of systems engineering, there have been numerous attempts to establish the foundations of that field on other disciplines. In this paper, we explore a new approach, founding systems engineering on an architectural metaphor. This approach is based upon our work of the past five years to establish a discipline of systems architecture. We outline the key principles of our approach and discuss their relevance to the broader field of systems engineering.
RISK AND OPPORTUNITY MANAGEMENT
Authors: Forsberg Kevin , Mooz Harold
Published: November 2014

Many people are searching for the secret to success in managing risks and opportunities on their project. Some hope for a panacea in computer tools including monte carlo simulations which provide probability distributions and confidence limits on the risks to be managed. However practitioners ultimately realize that there is no analytical “silver bullet” that solves the risk equation. Risk and opportunity management is fundamentally a judgmental process, in which the project manager must evaluate appropriate data using intuition, common sense (or uncommon sense), and team consensus to determine the best approach for the project and for the organization.

While some risk and opportunity issues are complex, many are relatively straight‐forward and can be readily solved. It is the number of issues to be faced – and the constant addition and deletion of issues – combined with the technical, cost, and schedule pressures that make risk and opportunity management a challenging process in project management. In order to be consistently successful, the project manager and team must follow a defined process. While monte carlo simulations, decision tree analyses, and other computerized techniques play a vital role, they must be used in the context of the risk and opportunity management process, and then only to the extent necessary to support the decision‐making process.

The objective of this paper is to describe the risk and opportunity management process in the context of project management.
Engineering of Computer‐based Systems (ECBS) Three New Methodologies–Three New Paradigms
Authors: Evans Richard P. , Park Sooyong
Published: November 2014

The integration of information technologies dramatically increases the interactions among physical components and processes, generates complex dynamics, and creates component interdependencies unknown in earlier systems. Although development processes for the individual components exist, they remain largely fragmented. Thus, the need for a system‐level discipline and interdisciplinary engineering specialty—engineering of computer‐based systems (ECBSs). The IEEE Computer Society Technical Committee on ECBS provides a focus, in conjunction with the efforts of other organizations such as INCOSE, to promote the ECBS discipline, encourage research in the field, and establish a framework for education and training. This paper includes a description of three new methodologies developed and applied in the engineering of several large‐scale computer‐based systems: System Assessments, and Assessment Control Board (ACB); a Systems Integration (SI) Program; and an Engineering Baseline System (EBS).
PROPOSING A TOOL TO SUPPORT THE PROCESS OF SYSTEM ARCHITECTING
Authors: Chasse John L. , Hyer Scott A. , Parker Thomas A.
Published: November 2014

Systems engineering tools are continuously being developed to make arduous tasks easier by reducing cycle times and smoothing transitions from one phase to another. A tool should ultimately free individuals from labor intensive, repetitive, non‐creative tasks and allow them to concentrate their talents on the problem at hand. The process of systems architecting is a task which requires a great deal of creativity. However, it can be dominated by cumbersome tasks involving traceability, documentation, verification, and validation. A system architecting tool could perform, or at least support many of these tasks, allowing the architect to focus on understanding the client's situation and produce an innovative system solution. A system architecting tool could also assist in managing information distributed over multiple platforms. Although existing tools accomplish some portion of these tasks, there are vast capabilities yet to be developed. This paper describes the capabilities required of a system architecting tool. To a tool developer, it describes these capabilities from the architect's (user's) point of view. To potential users, it serves to suggest what could and should be expected from systems engineering tools. This paper also serves to emphasize the aspects of good system architecting practices.
MONITORING THE DEFINITION AND DEVELOPMENT PROCESS OF LARGE SOFTWARE SYSTEMS
Authors: Kaslow David E. , Shupp Jeffrey K.
Published: November 2014

In developing large software systems, systems engineers too often pay more attention to the allocation of the mission functional requirements based on system specifications and less to operator based or design requirements derived from design concepts. However, the success of any large system development lies with the maturation of these design concepts and requirements. Of special importance are the concepts covering requirements key to satisfying the mission objective, or the concepts which span functional components, made up of hardware and software configuration items (CIs) and manual operations, within the system. This paper discusses a criteria which, when applied to a given design concept, identifies the concept as key. Key concepts must be identified early, analyzed thoroughly, and checked for consistency with the requirements that drive them throughout the definition and development process. If the proper level of analysis and design is performed against these concepts, the system will have a minimum number of issues to resolve as it approaches operational status.
CURRENT TRENDS IN REQUIREMENTS AND SPECIFICATION MANAGEMENT
Authors: James Laurence
Published: November 2014

Over the last 5 years, Marconi Systems Technology has been involved in developing a state‐of‐the‐art software product for requirements elicitation, traceability and management, able to interface with other best‐of‐breed CASE (Computer Aided Systems Engineering) tools. The product, known as “RTM” (Requirements & Traceability Management) (MST 1996), has achieved critical worldwide acclaim and is currently in use on some of the most advanced systems under development.

Through direct contact with many projects, it became clear that the different interest groups present in a company or project (from marketing to project management and systems engineers) had radically different expectations both on how they wanted to use such requirements management support and also what capabilities they as specific interest groups wanted from a requirements management tool.

Two common themes appeared to be shared by these interest groups. The first was the need to move away from the realm of primitive ASCII based requirement representations into the much more powerful and comfortable review and editing environments provided by many of today's leading desktop publishing tools. The second was to have the powerful information modeling, traceability, audit trail and impact analysis capabilities of RTM “fused” into their preferred editing environments.

This paper describes some of these current trends in requirements & specification management and their implementation in RTM V3.
SYSTEMS ENGINEERING IS MORE THAN JUST A PROCESS
Authors: Harwell Richard
Published: November 2014

The systems engineering process is a roadmap, a pathway to help us achieve our goals. As with systems engineering tools, the process assists ‐but is not a substitute for “getting the job done”. Unlike many processes, systems engineering must have a proper environment to flourish ‐ in fact, it's an inherent element of the application of the process.
AN INTEGRATED PROCEDURE FOR EXPLAINING SOFTWARE REQUIREMENTS
Authors: MacStravic James A.
Published: November 2014

An integrated procedure is presented for the analysis of subsystem requirements and the explanation of software requirements to Software Engineers for implementation. The procedure is supported by the tailored use of a system requirements analysis tool, RDD‐100, used to develop the requirements descriptions, to provide traceability through the levels of analysis, and to support the automated production of System Requirements Specifications and Interface Requirements Specifications. The procedure was applied to a program and achievements are described.
A Simplified Method for Requirements Flowdown and Test Limit Definition
Authors: Acaba Ralph , Bostic Kevin
Published: November 2014

A simple yet disciplined method for consistently flowing down requirements was created and implemented on a production radar program at Hughes Aircraft Company. This structured Requirements Flowdown Methodology was supplemented by a similar methodology developed for determining the limits at which the flowed down requirements are tested. These methodologies were created with the objective of producing a system that will better suit the needs of the customer. These customer needs include the need for proper operation of the product as specified for the entire product life under all specified environmental conditions, as well as improved system performance and increased reliability. With the structured definition of test limits as defined in the methodology described herein, a reduction in the number of field failures that cannot be duplicated at repair facilities is also accomplished. This reduces the amount of logistical support necessary to maintain an operational product in the field, minimizing the time necessary to isolate and repair failures, and resulting in increased customer satisfaction.
DESIGNING FOR FAILURE: ANOMALY IDENTIFICATION AND TREATMENT IN SYSTEM REQUIREMENTS ANALYSIS
Authors: Carson Ronald S.
Published: November 2014

A method for identifying anomalous (or “what if”) conditions in the system requirements analysis (SRA) is proposed using the concept of functional failure (Spangler 1993, Armstrong 1995). The method complements and extends (Carson 1995) by defining “sufficient” conditions for SRA completeness which complement the previously defined “necessary” conditions for completeness. Identification of the functional failures during the SRA allows the system designer to treat different anomalies rigorously at the beginning of a program as part of the system design. System requirements for “fault tolerance” or “inhibiting fault cascading” are easily incorporated into the resulting SRA as required behaviors (functions) for specific antecedents. The developed process ensures in a verifiable manner that the SRA is complete and there are no incorrect or indeterminate behaviors due to inadequate system design. If applied at all levels of the system development (mission design, system design, subsystem design, end item design) one could expect no surprises during test and integration atanylevel of design.
Heuristic Structuring and Methods Selection in the SEP: An Expert System in M.4
Authors: Clayson Mark H.
Published: November 2014

Systems engineering problems, and their analysis and design methods, become increasingly structured during the systems engineering process. The analysis and control function plays a structuring role in the concept phase and at the start of every loop (e.g., requirements, design, validation) in the systems engineering process. Part of analysis and control can be decomposed into a structuring loop which selects or matches methods to be applied. Heuristics are a powerful unstructured method for leveraged structuring in the critical concept phase, and later.

The criteria for matching of heuristics and more structured methods to problems is logically described in decision tables. These in turn may be implemented in a knowledge base or expert system. One such operational prototype has been developed in the M.4 rule‐based environment, and is described here. The benefits of such aids may be significant for the systems engineering management and systems architects heavily involved in the analysis and control function. The same approach may be followed using existing taxonomies for specific tool selection.
LESS IS MORE: CAPTURING THE ESSENTIAL DATA NEEDED FOR RAPID SYSTEMS DEVELOPMENT
Authors: DeGregorio Gary L. , Novorita Robert J.
Published: November 2014

In order to improve customer satisfaction and reduce systems development cycle time, engineering organizations must enhance their requirements capture and management capabilities. This means using formally specified and prioritized user requirements to drive technical development and supplying management with the information needed to make and implement decisions.

Most system development processes define their inputs and outputs in the form of documents, instead of the essential data consumed or generated. These documents tend to weave together user and system requirements with architecture and design concepts which result in an unstructured set of information. To remedy this situation, an information structure has been developed, that will hold the essential data needed to support system development.

This paper describes the motivation, components, and implementation of a requirements and decision management information structure, which includes requirements, decisions, rationale, and other key marketing, management, and engineering information, to support systems engineering improvement efforts.
INTEROPERABILITY OF DISTRIBUTED INFORMATION HANDLING SYSTEMS
Authors: Harmon S. Y. , Hritz L. M.
Published: November 2014

Development of distributed computing systems is a complex process made even more difficult by the interactions between algorithms and their execution environments. To improve the development process, nine algorithm characteristics and four execution environment characteristics were identified. These are independent of the specific functions and applications with which they are associated. Dependencies between these characteristics were explored for distributed algorithms and execution environments. Eight algorithm constraints and four environment constraints were derived which must be met to avoid the injection of anomalies into the computed results.
DISTRIBUTED SYSTEM ENGINEERING: IMPLEMENTING SE IN AN INTEGRATED PRODUCT TEAM ENVIRONMENT
Authors: Pittman Bruce
Published: November 2014

Many organizations are turning to Integrated Product Development (IPPD) and Integrated Product Teams (IPT's) as a way to improve the speed and cost effectiveness of their system development process. The Secretary of Defense issued a directive on May 10, 1995 directing the use of IPPD and IPT's to the maximum extent practicable. IPPD and IPT's have proven to be an effective tool when implemented properly, but they are no panacea. One of the challenges of IPT's is that the culture of the organization must change and the implementation of the system engineering process must also change. This paper will take the DoD Guide to Integrated Product and Process Development (Version 1.0) and examine the changes that are required in the way that system engineering has been implemented within project organizations on both the government and contractor side. The applicability of this approach to purely commercial projects will also be examined.

The concept of Distributed System Engineering (DSE) was developed to describe a new process for implementing SE within an IPPD structured project. DSE includes cultural changes that are required, new ways of developing and managing requirements and tradeoffs, as well the new knowledge and skills that the IPT members will need in order to step up to this challenge. The role of the project manager and the functional managers in project implementation must also change. An implementation strategy for getting started with DSE in a IPPD environment will be described.
Document Centered vs. Design Centered Systems Engineering or Word Processors vs. Systems Engineering Tools
Authors: Sampson Mark E.
Published: November 2014

Many systems engineers currently use word processors and spreadsheets to do their job of document generation. This paper discusses another way of generating design documentation as a by‐product of a computed‐aided design capture process. This paper describes the differences between the two approaches to design, provides examples, and shows the advantages of using tools to capture the design and generating documents from the “logic” contained in the design database versus using “word processors for schematic capture”
CREATING LOW‐COST, LOW‐IMPACT METRICS DESIGNED TO FOSTER PROCESS IMPROVEMENT EFFORTS IN THE ENGINEERING ENVIRONMENT
Authors: DiGiovanna Darryl , Redling Thomas , Miller William , Stratton Richard
Published: November 2014

AlliedSignal, AT&T, and Lucent Technologies have spent a great deal of time and money to design and implement effective metrics programs. After much trial and error the companies created a set of metrics that are useful and easily collected and analyzed. Along the way, many trial metrics programs were piloted. The following case studies document both the pilot tests that led up to the development of a working metrics program as well as the improved metrics programs that are now in place at both organizations.
“Good is Not Good Enough” Strategies of Implementing Performance Measures in a Mature and Successful Program
Authors: Hines James E. , Antony Patrick R.
Published: November 2014

The present Space Shuttle program is one in transition ‐ both from the government agency and the contractor level. NASA is restructuring the management of the Space Shuttle Program by turning over the reins of the day‐to‐day operations to a prime contractor, United Space Alliance ‐ USA (a joint venture partnership with Rockwell and Lockheed Martin). This move is intended to save millions of dollars in costs by eliminating duplicate resources, streamlining operations, and reducing nonessential program requirements. As a contractor, Rockwell, responsible for Orbiter operations and production as well as systems and payload/cargo integration, is also restructuring. All separate shuttle related contracts have been consolidated into one Shuttle Program. While this consolidation effort is taking place, Rockwell, the NASA, and USA are working closely together to provide the American public a Space Shuttle Program that continues to be technically viable, safe, and now more cost effective.

Central to the paradigm shift of organizational consolidation is the way people think and do their work and the importance of setting key performance measures for success. This paper deals specifically with the methodology and implementation procedures Rockwell applied in utilizing metrics to measure Shuttle product success. Applying metrics on a new program is difficult enough. But incorporating a formal set of performance measurements into a well established, mature program that is in the process of restructuring is doubly difficult.
Using EPIC's Systems Engineering Capability Maturity Model to Support Process Improvement at Texas Instruments Incorporated
Authors: Kuhn Dorothy A.
Published: November 2014

This paper describes the use of EPIC's Systems Engineering Capability Maturity Model (SE‐CMM) within the Systems Group (SG) of Texas Instruments Incorporated. TI's SG has used the SE‐CMM in several ways, some of which have had more utility than others. The utility of each of these uses is discussed in the context of the model's intended use. Additionally, a brief description of the new SE‐CMM Version 1.1 is provided.
ALLIED SIGNAL CAPABILITY MODELS AND ASSESSMENT TOOL
Authors: Booth Thomas C. , Oran William A.
Published: November 2014

In 1995 AlliedSignal Aerospace (ASA) developed a Systems Engineering (SE) Maturity Model which was widely distributed at the Fifth Annual INCOSE Symposium in St. Louis MO. In addition, AlliedSignal has also developed both Program Management (PM) and Integrated Product Delivery and Support (IPDS) maturity assessment tools. The rationale and genesis for the development of these models/tools will be discussed along with a description of a new integrated SE/PM/IPDS capability assessment tool. The tool has been used in assessments performed in 14 sites spread among 4 strategic business units. The rationale for these assessments and some of the preliminary findings will also be discussed. The results of the assessments are being used by each site to develop focused action plans to improve its total IPDS performance.
QUALIFICATION STRATEGIES FOR THE INTERNATIONAL SPACE STATION U. S. LABORATORY
Authors: Purves Byron
Published: November 2014

A systematic method has been applied in an Integrated Product Team environment to develop verification strategies for the International Space Station, US Laboratory Module. The method uses a graphical verification logic network and well defined verification objectives to specify a set of verification activities which are sufficient to prove compliance with the development specification.
THE APPLICATION OF ELECTRONIC INFORMATION SHARING IN SUPPORT OF SYSTEMS ENGINEERING PRACTICE
Authors: Allen Charles R. , Young Ralph R.
Published: November 2014

The capability of organizations to share information electronically in support of systems engineering practice is often discussed but seldom applied successfully. PRC has developed a capability which has been effective in sharing technology throughout the Company and which has greatly facilitated reuse. This paper describes PRC's Process Asset Library (PAL) and reports on current efforts to improve navigation to make it even more effective, as well as other plans for the future. An electronic Program Manager's Binder developed by PRC is improving information sharing and facilitating start‐up time of new programs. A PRC project tackling the office of the 21st century is discussed. Preliminary data which indicate a ten‐fold improvement in time to develop an engineering process are shared. It is believed that the results being achieved are quickly taking PRC toward world‐class levels in systems and software engineering.
Requirements Management Working Group: Characteristics of Good Requirements
Authors: Kar Pradip , Bailey Michelle
Published: November 2014

This paper identifies and documents the major characteristics of well defined requirements for both individual requirements and aggregates of requirements such as those found in specifications. Characteristics exhibited by well defined requirements are described. The descriptions are followed by a brief discussion of the characteristics. A few examples of well defined requirements are provided. Some supporting characteristics of requirements are also described. These supporting characteristics are not properties of the requirements themselves but are attributes assigned to individual requirements to assist in managing the requirements through the life cycle. The paper was written and reviewed by members of the requirements working group of the INCOSE.