bluuebunny/crossref_metadata_2025_split huggingface dataset:
Interfacing Requirements Management Tools In The Requirements Management Process – A First Look
Authors: Jones David A. , Kar Pradip C. , van Gaasbeek James R. , Hollenbach Frank , Bell Marty , Ellinger Robert S. 
Published: November 2014

ABSTRACTInterfacing requirements management software tools with other tools can facilitate the requirements management process by allowing people to exchange requirements more easily, to use the optimum tools in their work, and to adapt to tool changes. In this exploratory paper we attempt to provide some useful information to requirement tool users and developers who need to specify or devise requirement tool interfaces.Examination of a simple hierarchical requirement data flow model suggests major interfaces of
Document import / parsing
Derivation analyses
Publication (electronic and / or paper)
Flowdown to lower level
Database import / export
Companion programs (e.g. graphics editors)The model presented suggests the type of data that should flow across these interfaces.Twelve commercial requirements management tools are identified in this paper, and a couple of interface file formats are illustrated.Some generalizations are made, such as that each data item should be entered once and reside in a single master location where possible.Several examples of actual implementations illustrate accomplishments and practical difficulties encountered. Also eight commercial / consortium tool integration efforts are summarized with lists of the major tools involved, and a couple of standardization efforts are described, including a major European effort, SEDRES.Some work by INCOSE in identifying requirements data is recommended in this paper.Not all of the topics in this paper are covered in detail, but we think that a significant amount of useful information is provided.
1.1.2 The Missing Link in Systems Engineering
Authors: Gardner John R. 
Published: November 2014

ABSTRACTThis paper explores a methodology of integrating the Manufacturing Process Design and Prove‐out into a Systems Engineering Process. The methodology include Key Product Characteristics (KPCs) as well as Failure Modes and Effects Analyses (FMEAs). The paper provides examples and insights from the author's implementation on a presently ongoing design effort.
1.1.4 Simulation, IPPD & Systems Engineering: To The Next Level
Authors: Zittel Randy C. 
Published: November 2014

ABSTRACTSimulation tools, as well as the new management schema Integrated Product and Process Development (IPPD) have been applied to an increasing range of ongoing acquisition programs and have significantly reduced development time and life cycle costs and improved system quality. Some improvements have reduced the overall development time by half and some individual activities by 3000 %.“The issue is no longer whether extensive use of Simulation and IPPD have merit for acquisition, but rather how to develop and apply such new processes in a deliberate and coordinated manner to maximum advantage and achieve even more dramatic cost and schedule reductions.” (Sanders, 1997) The application of these tools carries Systems Engineering to a new level of capability.
2.1.4 A Case for the Consideration of System Related Cognitive Functions
Authors: MacLeod Iain S. 
Published: November 2014

ABSTRACTModern avionics and digital computing are rapidly advancing fields. Traditional Human Factors (HF) techniques, and those of other disciplines related to system design, are becoming increasingly inappropriate for use in the design of new avionics systems. This article proposes that the current Systems Engineering methods of requirements capture and system performance specification need to be enhanced. Human‐Machine Systems (HMS) are increasingly entering service with performances less than, or different from, that required by their specification. This problem is partly the fault of traditional HF approaches to HMS design, approaches that lack sensible justification, rigour, and purpose with relation to other important design disciplines. One avenue to promote HF value to design is to complement systems engineering by the early integration of human cognitive functions into the early requirements capture processes. It advocates a human orientated contribution to complementing the logical system specification processes. Suggested is a new emphasis on the capture of system cognitive functions related to HMS direction and control and an urgent need to discover methods suitable for the marriage of HMS human associated functions with engineered functions. It is argued that the mooted approach could assist in the knowledgeable adoption of new technologies and allow a more user‐centred approach to system automation. Discussion is presented on the benefits and possible pitfalls of the proposed approach.
3.1.1 USING THE THEORY OF CONSTRAINTS TO EXAMINE THE CHANGE APPROVAL PROCESS
Authors: Jackson Scott 
Published: November 2014

ABSTRACTA team was assembled to examine the change approval process using the theory of constraints (TOC). The premise of the theory of constraints is that the performance of a system, in this case the change approval process, is constrained in the ability to achieve throughput at key points in the process. It was perceived that improvements could be made in the change approval process, the main characteristic of which was an excessive time from the documentation of an idea to project approval. The team identified many areas for improvement and concluded that a fundamental shift was required from a focus on a time‐consuming effort to minimize the uncertainty in the project before approval to authorize development funds to new criteria which would justify the project's effort in a shorter time. The resulting actions to modify the process, called the new approval process (NAP), suggest key aspects of system engineering (SE).
3.1.2 When Requirements are not isomorphic to COTS Functionality: ‘Dormant Code’ within a COTS product
Authors: Kohl Ronald J. 
Published: November 2014

ABSTRACTIdeally, there should always be an isomorphic mapping between the collection of requirements (system, software, etc.) and the collection of software which is intended to satisfy those requirements. This would normally always be the case with custom developed software. But with the increased use of various types of Non‐Development Items (NDI) (e.g. COTS, GOTS, Reusable code, GFE), there is an increasing possibility that such NDI will include functionality for which there is no requirement. This non‐required or non‐specified type of software functionality will be referred to as Dormant Code (DC). This paper will focus on issues and problems caused by DC and will offer some approaches to address these issues.
4.1.2 Reconciling Systems and Software Architecture
Authors: Maier Mark W. 
Published: November 2014

ABSTRACTLarge, complex systems are increasingly software‐intensive or even information‐centric. As a result, the total cost and development effort associated with software is an increasing fraction of the whole system, indeed a dominant fraction. The techniques of architecting, system and software, are one method for dealing with large and complex systems. Unfortunately, the techniques and models of systems engineering commonly used in systems architecture descriptions are not well suited to enabling effective software architecting. This paper discusses the mismatches and suggests tools for reconciling their needs.
5.1.4 Applying an Automated Test Description Tool to Testing Based on System Level Requirements
Authors: Donat Michael R. , Joyce Jeffrey J. 
Published: November 2014

ABSTRACTA partially automated process for generating test procedures has been experimentally applied to a portion of the Software Requirements Specification for an Air Traffic Management system. This process uses algorithms based on formal logic to automate some of the more tedious and error prone aspects of deriving test procedures from requirements. This approach is particularly well suited to functional requirements involving complex decisions within stimulus‐response relationships. In addition to the potential improvement to requirements‐based test generation methodology, this process may also be used to improve requirements authoring.
5.1.5 Advantages of Stimulus Response Requirement Specification Techniques for System Testing
Authors: Cooper Kendra , Ito Mabo 
Published: November 2014

ABSTRACTThis paper presents the advantages of using a Stimulus Response Requirement Specification (SRRS) technique to reduce costs, development time, and errors in the generation of system level test cases in comparison to using a Structured Analysis (SA) technique. A SRRS technique describes requirements in terms of externally visible inputs (stimuli), processing, and externally visible outputs (responses). The SRRS techniques may be viewed as a general category of requirements specification techniques that are based on concepts originating in system test methods. Currently used, popular SRRS techniques include Use Cases and Scenario driven techniques. This paper first reviews a basic process for developing system test cases. An example from a library system is used to illustrate the first step of this process with a conventional SA requirements specification and a SRRS. The use of a SRRS technique to document the requirements specification simplifies the test case generation process by eliminating the first step in the three step process.
1.2.4 The System Engineering Process Definition as Part of the European Cooperation for Space Standardization (ECSS)
Authors: Hartmann Ralf ,   et. al. (The Members of ECSS‐E‐10 Working Group)
Published: November 2014

ABSTRACTThe European Cooperation for Space Standardization (ECSS) is an initiative established in 1993 to develop a coherent, single set of user‐friendly standards for use in all European space activities. The documentation architecture consists of the three branches Project Management, Product Assurance and Engineering. The first level 2 document in the Engineering branch (ECSS‐E‐10) is dedicated to System Engineering and has been released in 1996.
3.2.2 Using A Systems Engineering Web Site For Effective Communication
Authors: Jones David A. , Arunski Karl J. 
Published: November 2014

ABSTRACTAn intra‐company world wide web site serving 700 systems engineers at several sites has been in operation for about two years. The site provides job‐related information, downloadable document and utility job aids, current news, and a calendar of events. The information provided includes descriptions of the organization, standards, processes, training, and tools.The setting, site content, metrics collected, and lessons learned about setting up such a site are described.
5.2.3 Engineering Management Pocket Guides: The “TripTik” Approach to Capability Maturity Models
Authors: Cusick Kerinia 
Published: November 2014

ABSTRACTMany managers are looking for tools to help them implement better systems engineering practices. Capability Maturity Models are such a tool, but they are inherently complex and subtle tools that often take more time to understand than what many people are willing to give. SECAT LLC has developed a series of Pocket Guides, designed to make the Systems Engineering Capability Maturity Model accessible to the casual user. Pocket Guides cut straight to the key points so that your organization can stop repeating past mistakes, improve your ability to deliver a product on time and on budget, and use your limited improvement resources effectively. Pocket Guides are icon based distillations of the SE‐CMM, written in a straightforward language with a series of recommended practices. There are four in the series, each designed for a specific type of person: systems engineers, program managers, organizational leaders and process improvement personnel.
1.3.1 Implementation of System Requirements Models for Space Missions
Authors: Wall S. D. , Baker J. D. , Krajewski J. A. , Smith D. B. 
Published: November 2014

AbstractAs a part of the restructuring of the space mission design process, the Jet Propulsion Laboratory is investigating a model‐driven concept for capturing and refining system‐level requirements for space missions. Anticipated advantages include (1) earlier achievement of system design maturity; (2) earlier detection of system‐level problems through virtual test; and (3) enabling of mission/system trades throughout the design phase.Traditionally, system requirements are captured and held in a set of documents, which are parsed into increasingly lower level requirements until they are at the level where a single engineering team can design to them. For large or complex systems, however, the main disadvantages of document‐driven requirements capture schemes are that they are (1) inadequate in communicating dynamic aspects of system design, and (2) unwieldy to modify as design evolves, thus inhibiting creativity. In this paper we propose a model‐driven requirements scheme, wherein system‐level requirements models capture requirement allocations and inter‐relationships, are executed against mission scenarios, and are measured against performance goals. System‐level models can be used by a design team more effectively than requirements documents to facilitate communications amongst team members, thus leading to quicker convergence on a preliminary design. Further, model‐driven schemes enable rapid evaluation of changes and, it is hoped, significantly shorter development periods and less rework.
1.3.3 Improving Requirements Processes Through Modeling and Data To Achieve Level 5 Capability Maturity
Authors: Beshore David G. , Vietinghoff P.E. William , Kiser P.E. Jonathan 
Published: November 2014

ABSTRACTThe model described in this paper used actual data and a real IPPD organization framework to quickly measure team productivity goals and achievement along with necessary attributes to track and direct requirements.Effort is underway to gather data on past and current programs within the organization to identify either best practices or develop program independent, standardized processes in requirements management. This modeling and metrics development will help the organization achieve Level 5 Systems Engineering capability maturity.
1.3.4 Web‐based Requirement Management and Regulatory Tracking
Authors: Sampson Mark E. 
Published: November 2014

ABSTRACT“The Internet is the sum total of man's knowledge updated in real time.”With the advent of the World Wide Web, a tremendous resource of information is now available in real time for the asking—including many national, international, and industry standards and grovernment regulations. Many industries live by compliance to these standards and regulations… wouldn't it be great to reach out across the Internet to access and link to these standards and regulations from your requirements management tool?
2.3.3 Smalltalk as a System Modeling Tool
Authors: Helton Steven B. , Douglass James R. 
Published: November 2014

ABSTRACTSmalltalk is a rich, general purpose object‐oriented programming language and environment. It is also an effective tool for modeling systems. Smalltalk employs constructs that are applicable to any hard systems design problem, and these constructs aid the system designer in reducing the system complexity. However, the trade off is a one‐time, steep learning curve on the order of three to six months.
4.3.3 Simulation‐Emulation‐Stimulation A Complete System Engineering Process
Authors: Huang Paul , Kar Pradip , Sleder Al , Kato Hiroko 
Published: November 2014

ABSTRACTThe complexity of modern hardware/software systems, the reduction in defense funding levels, and the desire of DoD (US Department of Defense) to reduce the acquisition cycle using Simulation Based Acquisition have significantly impacted the manner in which new weapon systems are concepted, designed, integrated, tested, produced, and supported throughout their life cycles. The traditional approaches for engineering systems are no longer adequate for rapid developments and must be modernized in an integrated methodology to take advantage of the significant advancements in computer technologies. Many efforts using computer technology up to this point in time have been fragmented and lacked a systematic approach to make full use of the technologies. By taking advantage of the advances in microprocessors and software to create a System Integration Environment (SIE), a Simulation ‐ Emulation ‐ Stimulation (SES) Process can be developed that handles all aspects of the life cycle including system analysis, design, documentation, test and evaluation (T&E), integration and training. This paper reports on some of the advances that have been made thus far in developing such a System Integrated Environment for use in Army and Navy Combat System Developments.
5.3.1 Modeling Communication Satellite Protocols with a System Design Automation Tool
Authors: Colligan Robert , Meseroll Thomas C. , Shamash Micah , Wells Tyler , Thompson Francis 
Published: November 2014

ABSTRACTMilitary communication satellites use an extremely complex set of protocols for sending/receiving messages and controlling payload resources. These protocols are typically implemented in software for modern satellites because software is easier to modify than hardware and offers on‐orbit reprogramability. Traditional methods of specifying, designing, implementing, and testing payload software have proven to be expensive and error prone. Recent enhancements in system modeling/simulation tools offer the potential to automate the progression of all these life cycle phases in a “seamless” manner wherein the outputs of one life cycle phase become inputs for the next.This paper describes our evaluation of one of these tools: Statemate Magnum, produced by i‐Logix of Andover, MA. We evaluated the tool by using it to construct a simulation of satellite communication protocols. This simulation is to be used to facilitate the training of new project personnel.
5.3.2 Teams and Organization, a Model‐Based Approach
Authors: Oliver David W. 
Published: November 2014

ABSTRACTThe techniques for engineering systems with models, usually applied to products and services, are applied here to the human issues of teams, organization, and culture. This provides a means to explore solutions to human and organization issues and find near optimal solutions using the best practices of systems engineering. It provides a basis for rigorous discussion and evolution of teams, organization, and culture through execution and improvement of models. This analysis relates goals, rewards and tasks to classes of cultural behavior, and finds four basic organization architectures. This paper produces results that are consistent with industrial experience and the abstractions and representations from the fields of anthropology and psychology. The modeling generates the results in rigorous executable structure models.
5.3.3 Model‐Based Proposal Development
Authors: Fisher Gerard H. 
Published: November 2014

ABSTRACTThe competition for new business is increasing. There are fewer new starts being pursued by the government. Consequently, bidders need to find ways to increase their probability of win and reduce the cost of proposal preparation. This paper addresses the application of a model‐based systems engineering CASE tool, CORE®, to the proposal preparation process. The development and application of the proposal schema is discussed. The user benefits by decreasing the cost of writing the proposal and being better prepared when the contract is awarded.
2.4.1 Using System Engineering on A C‐17 Performance Improvement Project
Authors: Hsu John C. 
Published: November 2014

ABSTRACTA complete system engineering process is applied to a pilot project that will determine the initial deployment of the system engineering process for future projects. It was a challenge to complete the entire system engineering process to include project team utilization of system engineering tools in such a short time span. Therefore, system engineering products had to be useful and productive to the project. The system requirements definition, Quality Function Deployment (QFD) evaluation, trade study, risk identification and risk mitigation processes were completed in a timely manner and assisted in the System Requirements, System Design and Preliminary Design Reviews successfully.
2.4.3 Deep Space One Spacecraft System Engineering Techniques and the Application of Heuristic Reasoning
Authors: Basilio Ralph R. 
Published: November 2014

ABSTRACTThe Deep Space One Project is part of the National Aeronautics and Space Administration's (NASA's) New Millennium Program. The team is chartered with the design, development, and in‐flight validation of new technologies. The knowledge gained in flight will be instrumental in the success of future projects as they strive to build “faster, better, cheaper” spacecraft for NASA, the nation, and the world. There are a total of twelve new technologies planned to fly as part of the first deep space mission, many of which were either selected by the program and/or project manager independently or some that were coupled un‐conditionally with one another. These technologies include the miniature imaging camera and spectrometer, autonomous on‐board optical navigation, and the small deep space transponder. However, the most striking of these are arguably the ion propulsion system and advanced solar concentrator array, the combination of which will result in a ten fold or order of magnitude increase in impulse (ratio of force over the propellant mass) over a conventional chemical system. At the time of this writing, the Deep Space One Project is nearing completion of the thirty‐three month development life cycle and is being mechanically and electrically integrated and tested at the Jet Propulsion Laboratory in Pasadena, California. This paper discusses the system engineering techniques used to date, especially the application of heuristic reasoning, in the design, development, and test of the Deep Space One spacecraft.
3.4.2 Design Review Checklist for a Business Process Model
Authors: Ring Jack 
Published: November 2014

ABSTRACTAre you faced with designing a new systems engineering process to improve your organization's capability level or with customizing a standard process such as EAI 632A? If so, you are entering the domain of business process modeling. This checklist, based on systems principles and evolved from several years experience in several businesses, is intended to forestall promulgation of inadequate or inaccurate models of business processes or operations. Business models that meet the criteria in this checklist can be expected to foster success and avoid implementation problems such as organizational resistance to change.
4.4.3 System Engineering For Informal Regulation
Authors: Koehler Andrew C. , Stone Adam D. 
Published: November 2014

AbstractWhile systems engineering has traditionally concentrated on formal regulations as the basis for design requirements, other informal regulations may have equally strong impacts on the nature of any given industry or processes' relationship to its regulators. Through SE analysis of programs at Los Alamos National Laboratory, we argue that these informal regulations can have substantial effects on project outcomes. We develop a framework which can be used to include these informal regulations in both static and dynamic SE approaches and argue that such factors can and should be included in our analyses, despite the difficulties such an approach might generate.