bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.4.2 Error Cost Escalation Through the Project Life Cycle
Authors: Haskins Bill , Stecklein Jonette , Dick Brandon , Moroney Gregory , Lovell Randy , Dabney James 
Published: November 2014

AbstractAs systems become more complex, the costs to identify and correct requirements errors can consume large portions of project budgets. In general, there are two categories of cost associated with errors – cost of identification and cost of correction. This paper addresses an important element of the second category – the behavior of the cost of error correction as a project progresses. It is based on a study that used three approaches to determine the relative costs: the bottom‐up cost method, the total cost breakdown method, and the top‐down hypothetical project method. The approaches and results described in this paper presume development of a hardware/software system having project characteristics similar to those used in the development of a large, complex spacecraft, a military aircraft, or a small communications satellite. The results of the study show clearly that cost‐to‐fix escalates exponentially as the project progresses. If the cost of fixing a requirements error discovered during the requirements phase is defined to be 1 unit, the cost to fix that error if found during the design phase increases to 3–8 units; at the manufacturing/build phase, the cost to fix the error is 7–16 units; at the integration and test phase, the cost to fix the error becomes 21–78 units; and at the operations phase, the cost to fix the requirements error ranged from 29 units to more than 1500 units.
8.6.1 Integrating Failure Modes and Effects with the System Requirements Analysis
Authors: Carson Ronald S. 
Published: November 2014

AbstractAssessing failure modes and effects as part of the system requirements analysis activity provides specific benefits. Using the concept offunctionalfailure, the requirements analyst, whose primary focus is system functionality, can address the failure of any identified function to be performed as part of the functional analysis. The requisite behavior is documented as a new route to an existing function, or may be a new function altogether. Such integration reduces rework later in the program, since all conditions (nominal and fault) can be identified while requirements are being formulated, well ahead of integration testing. We find also that focusing onconditionsassociated with requirements stimulates better requirements analysis and documentation, leading to better implementation by designers. In addition, identifying all functional failure modes and their effects during the requirements analysis activity allows the requirements analyst to verify requirements completeness. This provides a management metric for measuring completeness of the requirements analysis process.
2.3.1 SysML – an Assessment
Authors: Herzog Erik , Pandikow Asmus 
Published: November 2014

AbstractSysML is a new standard language for system modeling, built on top of the new version of the popular UML and tailored for the specific needs of systems engineers. In this paper we present a brief overview of the SysML along with observations on the language and some challenges facing the systems engineering and tool vendor community.The purpose of the paper is not to criticize the outcome of the SysML standard but to evaluate its strengths and weaknesses and identify areas for future improvement.
2.3.2 Verification of Selection from Product Line Requirements
Authors: Kaindl Hermann , Mannion Mike 
Published: November 2014

AbstractA product line is a set of similar products e.g. spacecraft mission planning systems, mobile phones, and it facilitates reuse. From a given model of product line requirements, the requirements for new single systems in the product line can be selected. However, verifying that the selected requirements of any single system satisfy the variability constraints in the product line model is difficult especially when the models are large and complex. By modelling variability in the product line requirements using propositional calculus, a logical expression can be developed for the set of product line requirements and selection verification can be achieved by showing that the logical expression is satisfied. A case study using real‐world requirements provides empirical evidence of the computational feasibility of this approach. This paper presents formal semantics of variability representation in product line requirements and their use for verification of selection for single systems.
2.4.2 QuARS: Automated Natural Language Analysis of Requirements and Specifications
Authors: Lami Giuseppe , Ferguson Robert , Goldenson Dennis , Fusani Mario , Fabbrini Fabrizio , Gnesi Stefania 
Published: November 2014

AbstractRequirements analysis is a nontrivial, tedious, error prone and time consuming process. This paper describes a tool that automates identification of requirements defects that exist because of inadequate use of language for the purpose intended. The paper also describes results of using the tool on actual requirements documents from different industries. Our results show that the tool identifies defects that often escape detection by human inspectors.
3.4.1 A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems
Authors: McManus Hugh , Hastings Daniel 
Published: November 2014

AbstractA framework to aid in the understanding of uncertainties and techniques for mitigating and even taking positive advantage of them is presented. The framework is an attempt to clarify the wide range of uncertainties that affect complex systems, the risks (and opportunities) they create, the strategies system architects can use to mitigate (or take advantage) of them, and the resulting system attributes. Current and developing methods for dealing with uncertainties are projected onto the framework to understand their relative roles and interactions.
4.2.3 Network Centric Architectures:Are We Up To The Task?
Authors: Booth Stuart T. 
Published: November 2014

AbstractThe emergence of network centric architectures and the achievement of information superiority is the new paradigm that is being embraced by the military's next generation of systems to be developed and deployed. The changes dictated in this new architecture are instigating revolutionary changes throughout the DoD. These changes should have an equally profound effect on system integrators in terms of integration practices and policies that will allow network centric architectures to be realized within budgetary and schedule time constraints. The purpose of this paper is to identify key issues currently limiting the effectiveness of system integrators in their efforts to architect network centric architectures and offer suggestions on how to strengthen the integration process through the application of model‐based systems engineering, integrated information repositories, and teams that have both a vertical and horizontal architecture definition and integration responsibilities.
6.3.2 Some really useful principles: A new look at the scope and boundaries of systems engineering
Authors: Sillitto Hillary 
Published: November 2014

AbstractIn the search for a description of systems engineering that is precise and suitable for use outside the traditional defence/aerospace domains, this paper examines three emerging or “rediscovered” systems engineering concepts. These are the “generic reference model”, the “system value cycle”, and the notion of systems engineering as the management of emergent properties. They are shown to be useful in tackling some “classic problems” in systems engineering for which the standard definitions give little guidance. The problems include agreeing on the system boundary, understanding what is a “good” system, making the business case for systems engineering, and applying systems engineering outside the requirements driven context common in the defence industry. The place for innovation in the engineering of successful systems is illustrated with reference to successful and well‐documented World War 2 era platform systems. The paper seeks to identify definitions and principles that clearly distinguish “systems engineering” from other disciplines and are robust enough to be useable and relevant in both academia and industry, and to enhance the business case for systems engineering.The strategic choices discussed in the paper can be clarified by organising them into a three‐layer framework of “principles”, “practices” and “information structures“.
6.3.3 Practical Applications of Complexity Theory for Systems Engineers
Authors: Sheard Sarah A. 
Published: November 2014

AbstractThis paper provides a basic background in chaos and complexity theory and shows systems engineers how to improve the way they work in accordance with their increased awareness of the complex nature of systems, enterprises, and the environment. As systems and the enterprises in which they are developed become increasingly complex, systems engineering as learned and taught in the twentieth century should be supplemented by principles learned in the new sciences of complexity and chaos. Awareness of complexity theory can help practicing engineers perform their tasks differently on projects, in ways ranging from understanding the problem space and making models of the environment early in the life cycle, through managing changing requirements, designing differently, and identifying and managing risks, to supporting changing project management approaches.In addition, a science of complex systems engineering is being formed. This involves developing a formal theoretical backdrop for the heuristics that systems engineers have experientially found effective in architecting and developing complex systems. Complexity theory is enriching efforts to develop this advanced system engineering approach and practices.
9.1.2 Adaptive Test Process – Designing a Project Plan that Adapts to the State of a Project
Authors: Lévárdy Viktor , Browning Tyson R. 
Published: November 2014

AbstractConventional techniques for project planning make the flawed assumption that all activities and relations are known and can be planned a priori. Iteration models show that iteration is a fundamental aspect of novel projects, but they also assume all activities and interactions are known. Of course, some kind of hypothesized project baseline (plan) is required for management. Such plans are acknowledged to be imperfect, so management reserves are kept for schedule and budget where possible. How big should these reserves be? This paper describes research on an improved approach to process planning and control whereby activity modes are allowed to vary and dynamically recombine based on the evolving state of the project as it progresses. If the project is behind schedule or over budget, then activities or iterations which would seem prudent from a technical performance standpoint may not be feasible as originally planned. Similarly, if a project is ahead of schedule or under budget, additional improvements versus the original plan may add value. What is prudent depends on the effect of any action on the overall value of the project. As such decisions are made under uncertainty, the proposed approach accounts for uncertainties and their impacts (risks) in the decision. By assuming from the outset—while formulating the project plan—that the project will adapt, it is possible to build an improved project plan, one that is more accurate, realistic and flexible. Additionally, the proposed method supports management decisions about potential corrective actions during project execution. This paper applies the approach in the context of system verification and validation (V&V) processes.
10.3.2 A Conflict Resolution Approach to Capturing System Architecting Lessons Learned
Authors: Bryan Charles J. , Dagli Cihan 
Published: November 2014

AbstractSuccess in system architecting is more likely if the lessons learned on other projects are captured and applied appropriately. This is especially true when conflicts between different requirements and needs are encountered. The TRIZ approach to innovation management can be used as the basis of a systems architecting tool for capturing methods used by experts to resolve architecture conflicts. The resulting tool is easily adaptable to any organization, is maintainable on a computer yet can be depicted on a few sheets of paper, allows specific solutions to be derived from general methods, and suggests approaches that may not otherwise be considered. The wide variety of sources available to an organization—heuristics, special reports, interview records, etc.—can be combined and analyzed to the determine the most commonly used techniques and when to use them, thereby raising the likelihood of successfully solving current problems.
11.1.1 Calculations of Flexibility in Space Systems
Authors: Nilchiani Roshanak , Hastings Daniel , Joppin Carole 
Published: November 2014

AbstractOne of the important aspects of Engineering Systems design is the measurement of flexibility. In this paper, different measures for flexibility are applied to an orbital transportation network, which provides on‐orbit servicing capability. The paper introduces provider‐side as well as customer‐side flexibility metrics that can be used to evaluate different architectures on the basis of their flexibility. These two sets of approaches to calculating flexibility for space systems highlight the different ways flexibility can be valued, be it in terms of flexibility metrics or real option values. The choice of methodology depends on the context and the engineering system in question, as well as what kind of outputs are expected. While the case studies discussed here are focused on space systems, these measures of flexibility can also be expanded to many other engineering systems.
11.2.1 Requirements Statements Are Transfer Functions: An Insight from Model‐Based Systems Engineering
Authors: Schindel William D. 
Published: November 2014

AbstractTraditional systems engineering pays attention to careful composition of prose requirements statements. Even so, prose appears less than what is needed to advance the art of systems engineering into a theoretically‐based engineering discipline comparable to Electrical, Mechanical, or Chemical Engineering. Ask three people to read a set of prose requirements statements, and a universal experience is that there will be three different impressions of their meaning. The rise of Model‐Based Systems Engineering might suggest the demise of prose requirements, but we argue otherwise. This paper shows how prose requirements can be productively embedded in and a valued formal part of requirements models. This leads to the practice‐impacting insight that requirements statements can be non‐linear extensions of linear transfer functions, shows how their ambiguity can be further reduced using ordinary language, how their completeness or overlap more easily audited, and how they can be “understood” more completely by engineering tools.
11.2.2 Application of Patterns and Pattern Languages to Systems Engineering
Authors: Haskins Cecilia 
Published: November 2014

AbstractOn the strength of the reception of the presentation introducing the concepts of patterns and pattern languages (PPL) during the INCOSE symposium in 2003, a tutorial on writing patterns for systems engineering was conducted before the symposium in 2004 and a Systems Engineering Patterns Working Group was formed. This paper builds on the trend and discusses important issues relevant to the application and actual use of PPL by Systems Engineers. These issues include exploration of the alignment of pattern languages to other languages, their structure and the important question of “how shall the SE community use pattern languages?” Once these questions are answered, the INCOSE may find itself poised to introduce an innovative communications technique into the SE community with the application of PPL.
11.4.3 The Tradespace Exploration Paradigm
Authors: Ross Adam M. , Hastings Daniel E. 
Published: November 2014

AbstractOver the past five years, researchers working on a number of system design projects in the Space Systems, Policy, and Architecture Research Consortium (SSPARC) at the Massachusetts Institute of Technology (MIT) have developed a process of value‐focused, broad tradespace exploration for the development of space systems. The broad tradespace framework has provided insights into communicating and quantifying the impact of changing requirements, uncertainty, and system properties such as flexibility and robustness. Additionally, insights have been made in applications to more complex cases, such as analyzing policy effects on system cost and performance, as well as understanding the time‐dependent effects of architecture and design choices for spiral development. The tradespace exploration paradigm both broadens the perspective of designers in conceptual design to better understand the “physics” of the proposed solutions relative to one another, and focuses the designer on delivering systems of value to key system stakeholders.
1.1.1 START Analysis for ESAS Capability Needs Prioritization
Authors: Lincoln William , Mrozinski Joe , Hua Hook , Merida Sofia , Shelton Kacie , Adumitroaie Virgil , Weisbin Charles R. , Derleth Jason 
Published: November 2014

AbstractSTART is a tool to optimize research and development primarily for NASA missions. It was developed within the Strategic Systems Technology Program Office, a division of the Office of the Chief Technologist at NASA's Jet Propulsion Laboratory.START is capable of quantifying and comparing the risks, costs, and potential returns of technologies that are candidates for funding. START can be enormously helpful both in selecting technologies for development – within the constraints of budget, schedule, and other resources – and in monitoring their progress.START's methods are applicable to everything from individual tasks to multiple projects comprising entire programs of investigation. They can address virtually any technology assessment and capability prioritization issue. In this report, START is used to analyze the capability needs using data from NASA's Exploration Systems Architecture Study (ESAS).
1.4.1 Using the Knowledge Pyramid to Characterize Systems
Authors: Martin James 
Published: November 2014

AbstractMany systems help us increase our knowledge of the world in one way or another. Systems engineering needs a better way to understand how systems help or hinder the creation of knowledge. The Knowledge Pyramid was developed as a reference model to facilitate systems analysis with respect to data, information and knowledge. This paper describes the elements of the Pyramid and how they relate to system architecture.
1.4.3 Cross‐Cutting Concerns and Ergonomic Profiling Using UML/SysML
Authors: Hause Matthew C. 
Published: November 2014

AbstractModeling with UML/SysML involves many different organizing principles. These include inheritance and aggregation hierarchies, association networks, and dependency relationships. These can be addressed by the model architecture itself, and by the different UML/SysML diagrams. Also, there are requirements or areas of concern such as safety, risk, and traceability that can cut across the entire model at all levels. These need to be addressed early on in the project as they can have far reaching consequences for both product and process. Just as no architect would complete the design for a house, and only then address plumbing, gas, and electricity, no system architect would finish their system without having addressed safety, risk, and traceability. This paper will look at methods for integrating these cross‐cutting concerns into a SysML model. It will demonstrate how ergonomic profiling supported by an integrated database provides diagrammatic information in a format familiar to a domain specialist, maintains model and viewpoint consistency, and allows generation of customized reports to address specific concerns.
4.3.1 Meeting the Challenge of Knowledge‐Creating Systems
Authors: Martin James 
Published: November 2014

AbstractMany systems help us increase our knowledge of the world in one way or another. Business application systems help managers understand the marketplace and how best to address market needs. Military systems provide command and control capabilities so we can have better battlefield awareness so we can fight to win. Chemical processing facility systems help us gain awareness of what is happening all along the processing chain. If all these systems help us gain knowledge of the world, does SE have the tools to analyze the knowledge‐creation capacity of our systems? This paper will explore that question.
4.3.3 Applying Systems Modeling Language to A Simple Hardware System
Authors: Hsu John C. 
Published: November 2014

AbstractThis paper used the Systems Modeling Language (SysML) to explore its applicability and effectiveness to a simple hardware system. The system and design requirements derived from the customer requirements were modeled in the requirements hierarchy diagram. The spring load equation with all the variables and constant were defined in the parametric constraint definition diagram. Parametric constraint on a block diagram was then used to design a conical helical spring. A link between design and requirements was demonstrated in the model. State machine diagrams depicted the finite state‐transition on how a person emptied the mousetrap and how a mouse entered the trap. These diagrams were linked to verification requirements for system verification. SysML is shown to be an effective modeling language for hardware systems. The applicability of SysML to a combined hardware and software system has still to be demonstrated and proven.
6.1.2 Using Cognitive Engineering to Improve Systems Engineering
Authors: Bonaceto Craig , Burns Kevin 
Published: November 2014

AbstractEnterprise Systems Engineering (ESE) must go beyond the hardware and software of systems to address Human‐Systems Integration (HSI). Towards that end, we propose that Cognitive Engineering techniques can and should play a key role in Systems Engineering efforts. In this paper we survey various methods in Cognitive Engineering, showing where these methods apply to specific problems in Systems Engineering from Concept Definition and Requirements Analysis, through Function Allocation and Performance Estimation, to Training Development and Performance Assurance. We also describe several uses of selected methods, including Cognitive Task Analysis, Computational Cognitive Modeling, and Critical Incident Analysis, to tackle specific problems in air traffic control. Taken together, these specific cases along with our general survey offer a roadmap for using Cognitive Engineering to improve Systems Engineering.
6.1.3 A Value‐Based Theory of Systems Engineering
Authors: Boehm Barry , Jain Apurva 
Published: November 2014

AbstractThe INCOSE definition of “systems engineering” is “an interdisciplinary approach and means to enable the realization of successful systems.” The Value‐Based Theory of Systems Engineering presents necessary and sufficient conditions for realizing a successful system and elaborates them into an executable process. The theory and process are illustrated on a supply‐chain system example, and evaluated with respect to criteria for a good theory.