bluuebunny/crossref_metadata_2025_split huggingface dataset:
GENERATING TEST CASES FROM FORMAL SPECIFICATIONS
Authors: Toth Kalman C. , Donat Michael R. , Joyce Jeffrey J. 
Published: November 2014

AbstractThis paper describes the possible process elements and benefits of applying “Formal Methods” to the specification and testing of software requirements. It is argued that the overall effort required to generate test cases can be significantly reduced by applying these methods. Ambiguities and inconsistencies are identified and removed from the specifications through the use of formal methods. This paper provides a sketch of a theoretic foundational for generating test cases from formalized software requirements specifications thereby reducing test development effort and providing developers and testers with a consistent interpretation of requirements. Preliminary work also supports the thesis that test case generation can be automated.
A METHODOLOGY FOR CONSOLIDATING SYSTEMS USING OPEN ARCHITECTURES
Authors: Friedman Gerald M. 
Published: November 2014

AbstractThe migration of multiple legacy systems to a single system having an open architecture is increasingly required as the Government modernizes existing capabilities. This paper presents a methodology, based upon open system standards and commercial off the shelf (COTS) products, for performing such migrations. The methodology addresses requirements, legacy system engineering analyses, architecture synthesis, component selection, migration plan development, cost, schedule, and migration plan implementation. The approach is presented in the context of the Theater Battle Management Core System project.
WHAT IS SYSTEMS ENGINEERING? A CONSENSUS OF SENIOR SYSTEMS ENGINEERS1
Authors: Bahill A. Terry , Dean Frank F. 
Published: November 2014

AbstractSystems Engineering is an interdisciplinary process that ensures that the customer's needs are satisfied throughout a system's entire life cycle. This process includes
understanding customer needs,
stating the problem,
discovering system requirements,
defining performance & cost figures of merit,
validating requirements,
defining technical performance measures,
prescribing tests,
exploring alternative concepts,
sensitivity analyses,
functional decomposition,
system modeling,
system design,
designing and managing interfaces,
conducting design reviews,
system integration,
total system test,
configuration management,
risk management,
reliability analysis,
total quality management,
project management,
and documentation.
OBJECT MODELING AND CONCURRENT REQUIREMENTS ANALYSIS AT THE FRONT END OF SYSTEM DESIGN
Authors: Hopkins Frank W. 
Published: November 2014

AbstractThis paper describes a process that provides needed clarity at the front end of system definition and additionally encourages:
Modularity with its benefits for modification and reuse, and
Requirements compliance and traceability.The process incorporates structured requirements parsing concurrently with top level system architecture definition.The process is implemented easily with a toolset including: a requirements editing and management capability, an object modeling capability, a behavior modeling capability, and a repository for the system model data elements. OMTool by (the former) General Electric and RDD‐100 by Ascent Logic are the tools I have principally used for the process. Other toolset combinations may accomplish the same purpose. Many of these were displayed and demonstrated at NCOSE '95.
Strategy, Tactics, and Contingencies ‐ A Brief Tutorial in Planning to Achieve One's Objectives
Authors: Minds Kevin S. 
Published: November 2014

AbstractEvent based planning, empowerment, and risk management methods can be used to support strategic, tactical, and contingency planning. Strategic planning employs event based planning to postulate critical events and choose associated transition criteria. The intent is to choose a set of criteria for each event such that, if the criteria are satisfied, each event will occur as expected. Empowerment supports tactical planning by authorizing others to satisfy strategically chosen transition criteria. This is done by an empowering authority who assigns both transition criteria and decision making boundaries to an individual or group. Contingency plans are determined via risk management methods that identify risk items associated with failing to satisfy transition criteria and creating plans to avert those risks. In this context, all three methods, event based planning, empowerment, and risk management are driven by strategically chosen events and their associated transition criteria.
AN INTEGRATED PRODUCT DEVELOPMENT PROCESS CASE STUDY
Authors: Clouse Aaron J. , Shaw Richard 
Published: November 2014

AbstractThe Defense Systems and Electronics Group of Texas Instruments has developed and is using the Integrated Product Development Process (IPDP™). This paper describes how the process was developed, how it is deployed and the resulting success of the programs it has been used on. This method for creating an integrated product development process may be useful for your organization.
THE INTEGRATED PRODUCT DEVELOPMENT CAPABILITY MATURITY MODEL (CMM) SM
Authors: McIntyre Mac H. 
Published: November 2014

AbstractIntegrated Product Development (IPD) is a systematic approach to product (or service) development that achieves a timely collaboration of necessary disciplines throughout the product lifecycle to better satisfy customer needs. This paper provides the architecture and content description for a Capability Maturity Model for IPD. The formal model is based on industry (service and manufacturing), government, and academic input for IPD and the roles of teams within it. The intent of the session will be to update the current model state and to collect feedback on practitioner‐targeted, short, informational presentations and what else practitioners who help develop and implement processes need/want to know to want to try out this IPD CMM SM.
AN AUTOMATED ANTHROPOMETRIC TOOL FOR HUMAN FACTORS ENGINEERING
Authors: Saffer Valeria , Stanton Brian C. 
Published: November 2014

AbstractFor some time there have been software prototyping tools available to the Human Factors engineer to develop the human‐computer interface (HCI) of a system. Recently, software programs that aid in the prototyping of the hardware have been developed. These programs run on graphical workstations and enable the human factors engineer to build three dimensional models and analyze them, on a number of anthropometric variables, using human form models. This paper describes how such a program is being used to model and analyze the FAA's Display System Replacement (DSR) Air Traffic Control workstations.
A System Approach to the Client Server Distributed Architecture
Authors: Tronstad Yngvar , Earley Robert 
Published: November 2014

AbstractThis paper describes the need for a system engineering approach as a means to migrate the current rigid legacy system to a flexible distributed system architecture that can take advantage of the emergent client server technology. This approach focuses on a re‐alignment of the business processes as opposed to rehosting applications to a new technology. In doing so the enterprise becomes more aligned with the business objectives and the associated business objects. This modeling approach allows businesses to respond to dynamic changes in an increasingly more competitive environment.
ON THE NATURE OF INTEGRATION: AN ESSENTIAL TASK IN THE ENGINEERING OF SYSTEMS
Authors: Martin James N. 
Published: November 2014

AbstractIt has been said that systems engineering is concerned with the integration of system elements. This is certainly true, but there are some critical things left unsaid. What system and what elements are to be integrated?It turns out that there are several systems of concern in any application of the systems engineering process. First, there is the system that ends up in the hands of the user. This is sometimes called the end product. There is also the system that manufactures the end product. There are also systems for verification (or test), deployment, installation, training, maintenance, administration, and disposal.There are also all the non‐product related elements such as process, methods, tools, and environment. Also, how about technology and people? Hence, there are many “elements” that need to be integrated. This paper describes the things that need to be integrated and some of the means by which full integration can be ensured.
ON THE RELATIONSHIP BETWEEN ENABLING ELEMENTS & ENABLING PRODUCTS FOR A SYSTEM
Authors: Martin James N. 
Published: November 2014

AbstractCritical requirements for a system are often missed because the full life cycle of a system is not well understood or the enabling products for the system are not well defined. Enabling products are those products that provide the means for getting end items into use, and for properly retiring thoseend items from use.This paper describes a system life cycle, defines enabling product types, and gives examples of enabling products for a system. The utility of developing a full definition of the system life cycle and its enabling products is described. A mapping between enabling product types and the system life cycle is described. Full consideration of the system life cycle and its enabling products will ensure greater coverage of the requirements needed for the engineering of systems.
GRAPHICAL DESCRIPTION LANGUAGE:™ A SOLUTION FOR THE SYSTEM‐SOFTWARE INTERFACE PROBLEM
Authors: LaBudde Edward V. 
Published: November 2014

AbstractA growing gap exists between the systems engineer and the software engineer. A major source of this gap is the failure of both engineering groups to adequately address certain system, function, and performance requirements during the decomposition process. This is especially true for logic, sequencing, and timeline requirements (LaBudde 1995).One reason for this gap is that the old reliable system engineering tools like functional flow designs diagrams and N2 charts fail to capture all the requirements. In addition, the new software techniques like object‐oriented design also fail to capture all the requirements including sequencing, timeline, and performance. Another reason for this gap is the proliferation of software requirements and design methodologies. These have created a “Tower of Babble” of notations (Alford 1992). The confusion created by different notations can have serious consequences to system behavior and performance (Shaw 1995).We define the requirements for a general purpose system engineering requirements and design capture method and tool. Furthermore, a proposed solution to this problem which will meet the specified requirements is presented. We have developed a robust Graphical Description Language™ (GDL™) which ensures that all the requirements can be described and related using graphical representations. This method is simple to execute and easy to understand by all team members. The method works equally well on describing requirements for mechanical, electrical, optical, and software implementations.The approach provides a single, common method of communications for all engineers on the program and solves the system‐software interface problem.
INTEGRATING SYSTEMS ENGINEERING AND PROGRAM MANAGEMENT
Authors: Lilburn Bert 
Published: November 2014

AbstractHow do you integrate the work the Systems Engineer performs with the work the Program Manager performs? This was the problem facing the developer of a project management training course. The objective of the training course was to instruct employees on how to manage project work, how to implement a systems engineering process and culture, and how the company complies with project management and systems engineering requirements. The customer's criteria for a program management system and the company's requirements for systems engineering were the course requirements. A functional analysis of the process of managing contract work was performed. From this, a common set of functions were identified from which the specific tasks the Systems Engineer performs were integrated with those of the Program Manager.
BENEFITS OF STRUCTURED REQUIREMENTS METHODS FOR MARKET‐BASED ENTERPRISES
Authors: Novorita Robert J. , Grube Gary 
Published: November 2014

AbstractThe Land Mobile Products Sector of Motorola is currently transforming its commercial core business processes. Systems engineering has been recognize as a key solution for balancing the system developer, user, customer, and internal business manager perspectives. A cost effective balance between these various perspectives is of vital importance for commercial enterprise success dealing with complex internal and external environments. The first component of systems engineering capability adopted by Motorola Land Mobile Products Sector has been the functional area of requirements capture, analysis, and management. Improvement in the requirements functional area within Motorola Land Mobile Products Sector has lead to an improvement in delivered systems quality and a reduction in systems development cycle time. This paper describes the relationship between driving requirements, systems development cycle time, and systems quality from a commercial systems engineering perspective with some supporting data results.
AUTOMATING THE SPEC MANAGEMENT PROCESS
Authors: Kepchar Kenneth J 
Published: November 2014

AbstractThe management of requirements, especially in military programs, has always been a complex undertaking. During the course of a contract, considerable effort is expended managing the requirement as the design matures. Clarifications and interpretations to the original requirements become inevitable. The fine tuning of the requirement set continues up to, and even after, a weapon system is delivered. Recent software advances offer a number of tools capable of assisting the Systems Engineer to manage the complexity involved. This paper presents a case study of the integration of a commercial off‐the‐shelf (COTS) tool set with RDD‐100® to perform specification management and delivery on the F/A‐18E/F Super Hornet military aircraft program at McDonnell Douglas.
AUTOMATING CONFIGURATION PROCESSES: A STEP TOWARD MASS CUSTOMIZATION
Authors: Shreve Susan 
Published: November 2014

AbstractFor companies to maintain a competitive advantage in a changing global market they must continuously improve to operate profitably and strive for customer satisfaction. Customer satisfaction means delivering the right product, customized to exact specifications, delivered when it is needed with excellent support services available. Today's manufacturing processes are moving from mass production to mass customization to support individual customer needs. In addition to the production process complexity, the systems themselves are becoming increasingly more complex. A key enabler to manage this complexity is to capture and organize user requirements and map them to a configurator to produce accurate Bills of Material. This paper describes aspects of implementing automated configuration processes using a semiconductor equipment manufacturer for examples of business issues.
EVOLUTION OF THE TECHNICAL REQUIREMENTS BASELINE WITH DESIGN PHASES OF A PROGRAM OR PROJECT
Authors: Rindskopf M. Sam 
Published: November 2014

AbstractThe U. S. Department of Energy Civilian Radioactive Waste Management System has unique requirements that drove tailoring of the technical baseline development process. Because of different schedules for start up of various elements of the system, the technical baseline was developed from top to bottom very early in the program. Many interfaces existed and early development of technical requirements aided identification of these interface requirements. This technical baseline development process provides a method for managing the ever‐increasing level of detail required for the technical baseline as it evolves. Successful management of the technical baseline, with the evolution of the design, requires a disciplined process to identify requirements at the appropriate level of detail for the phase of design. A key for success is implementing a change process that is responsive to the program needs.
OBJECTS, ACTORS AND ROLES: AN IDENTITY TRIAD FOR REQUIREMENTS
Authors: Rhodes Robert R. 
Published: November 2014

ABSTRACTThe author proposes a technique for identifying all needed requirements for a system component. The technique is applied at the earliest stage of a system project, when the system developer and the customer must work together to define operations concepts and capabilities for the conceived system. This also is the time when system engineering seems more like an art than a discipline, and guidance is rarely to be had.The technique employs “actors”, “roles”, and “objects” to identify all the functional capabilities required for a system component in the context of a larger system in which the component resides. The technique can be used very early on, even when an information model has not been fully formulated, and the system boundaries are not yet clear. The technique can be further used at all levels of requirement analysis and architecture design, because it is based on external “interest” in the functional capabilities of the component.
CLOSING THE GAP BETWEEN REQUIREMENTS DEFINITION AND PRODUCT DEVELOPMENT: A CASE STUDY
Authors: Iwach Alexander E. , Sims Steven J. 
Published: November 2014

AbstractA critical factor in efficient product development is defining the system requirements in a product development team environment. This paper describes the implementation of a strategy for defining meaningful system and subsystem requirements within a predominantly hardware‐oriented engineering culture. The resulting requirements documentation became the baseline for subsequent design and development efforts, thereby linking the requirements definition to product development. Critical ingredients in building this link include: (a) defining engineering guidelines to establish an initial conceptual framework; (b) fostering an environment conducive for integrated product development teams to perform requirements analysis effectively through requirements elicitation; and (c) providing leadership in resolving technical difficulties to accelerate the resolution of complex requirement issues through consensus building. Examples of the process of solving requirements issues are provided.
REQUIREMENTS FOR DISTRIBUTED WORK SUPPORT SYSTEMS
Authors: Byers James C. , Kaplan Bruce L. , Gilbert B. Gay , Reece Wendy J. 
Published: November 2014

AbstractThe purpose of this paper is to present the results of research which developed a general model of Distributed Work Support Systems (DWSS)–computer based tools that enable geographically dispersed groups and teams to communicate, coordinate, and otherwise work together on complex problems. The model developed was intended to be one that could be used 1) to evaluate currently available DWSS, as well as 2) to point the way towards development of better DWSS. The development of a general model involved investigation of three principal areas. The three areas were: Organizational Study, Human Capabilities Study, and Available Technology Assessment. The general model was put together by integrating information from these three studies. The model is composed of a series of requirements for a DWSS tool. The requirements are often broad in nature because this is a general model for a DWSS. Under development are a set of prototype tool requirement to aid groups in performing systems oriented work. This paper presents an overview and examples of the requirements identified thus far.
MULTI‐TEAM INTEGRATION: INTERDEPENDENCE AND INTEGRATIVE MECHANISMS
Authors: Browning Tyson R. 
Published: November 2014

AbstractThe drive towards Integrated Product Development (IPD) includes an impetus to organize around Integrated Product Teams (IPTs). The use of IPTs has brought with it many issues, including those at the IPT interfaces. Program integration (cross‐functional, upstream/downstream, customer and supplier) can exist at several levels, within IPTs and between IPTs. This paper focuses on the realm of IPT interdependence, and categorizes several Integrative Mechanisms (IMs) to facilitate interteam integration. IMs are strategies and tools for effectively coordinating actions across IPTs within a program. This paper is based on studies in the aerospace industry, but the implications extend to any large, complex development program.
Application of Statistical Processes on a Set Theory Model for Anomaly Handling in System Requirements Analysis
Authors: Sanchez James A. 
Published: November 2014

AbstractIn 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 author assumes that the requirements for this simple example are stochastic, rather than deterministic, in nature. The arguments in support of this assumption are compelling. One is that many processes which are defined by a set of requirements are themselves stochastic in nature. Another is that a near deterministic model can be developed from a stochastic model in many applications. One can also argue that a stochastic process is more robust and better suited to a set of requirements subject to change due to ambiguities in syntax or lexicon or in how a system is thought to behave.The entire set of requirements constitutes the probabilistic universe of the system. Each requirement has a probability associated with it that the requirement is satisfied. Furthermore, the requirements may have dependencies.The methodology is developed from simple Bayesian relationships that have been used in a number of computer automated tools. What may seem different is that the probability is a characteristic of the antecedent rather than the requirement itself.This model, though not desirable for all classes of requirements, may fit a number of situations where the outcome of the requirement is not certain.In conclusion, the SRA model utilizing elementary set theory is expanded from a deterministic system to a stochastic system. The method is rigorous, and can account for 1) ambiguities in language, 2) unforeseen conditions, 3) undefined initial conditions, and 4) probability density function of primitives. It can also make the system defined by a set of requirements more robust.
TEAMS ARE NOT INTEGRATED PRODUCT DEVELOPMENT
Authors: Armstrong James R. 
Published: November 2014

Abstract…Necessarily. In the current race to embrace IPD (or IPPD) as the panacea of the nineties, teams have been identified as the pro forma solution. The assumption is that by establishing multi‐discipline teams, the objectives of IPD will be automatically achieved. However, evidence conflicts with this assumption. In reality, focusing on teams can distract management from the real goals of IPD. By understanding the objectives of IPD and the effects of teams, the relationship of the two can be understood. Then, effective implementation can occur.