bluuebunny/crossref_metadata_2025 huggingface dataset:
6.4.1 On the Use of Knowledge Modeling Tools and Techniques to Characterize the NOAA Observing System Architecture
Authors: Martin James N
Published: November 2014

The National Oceanic and Atmospheric Administration (NOAA) in the United States has a very broad charter that includes making “observations” of environmental phenomena worldwide. These observing systems are used to provide accurate and timely information to various stakeholders who depend on this information to make critical decisions about farming, construction, fishing, military operations, traffic safety, and so on. This paper describes a project to develop the NOAA Observing System Architecture to assist NOAA in formulating its strategic plans and invest its funding more effectively. We used “knowledge modeling” as the basic approach to capture information about the systems and other entities associated with the architecture. We are using the Metis enterprise architecture tool along with DOORS for requirements, NOAA Forge for team collaboration, and ArcIMS for geospatial data visualization.
6.4.2 Predicting Structural Change in Environmental Systems: a Complement to Model‐based Forecasting
Authors: Osidele Olufemi
Published: November 2014

Simulation models are commonly employed for predicting both the impacts of natural stressors and the outcomes of anthropogenic actions on the environment. Such model‐based forecasting depicts a forward approach to environmental systems analysis. This paper presents a complementary backward approach that uses prescribed future scenarios to identify the dominant components of the modeled system. In particular, two Monte Carlo methods for uncertainty analysis – namely, Regionalized Sensitivity Analysis (RSA) and Tree‐Structured Density Estimation (TSDE) – are applied in detecting structural change between observed past and speculated future ecological behavior in a small southeastern US Piedmont reservoir (Lake Oglethorpe, GA). Results indicate that sediment‐water‐nutrient interactions are key elements of structural change that distinguish between the past and future scenarios analyzed. General implications for predicting structural change in environmental systems are discussed.
2.5.1 Systems Engineering and Rapid Product Development
Authors: King Greg
Published: November 2014

This paper describes the processes used at MDS‐SCIEX to quickly deliver a radical new product to the marketplace. Although the product is based on current technologies, it represents a novel use of these technologies. The use is so novel that our scientists were unable to fully predict how customers would use the product. In addition to making it difficult to define complete requirements this also imposed the requirement that the system architecture be flexible enough to quickly adapt to unexpected new requirements.

An iterative approach was taken but the deliverables at each stage were complete in themselves. At the start, an over‐all general architecture was defined along with the stages and their deliverables. For each stage the requirements were gathered and analyzed, specifications produced, components were designed, implemented, and tested.

Despite what appears to be a lot of redundant work we proceeded rapidly because at no time did we have to completely specify the whole system in detail. Debugging was also facilitated because the changes for each stage were limited and testing commenced earlier. Also by keeping the whole system in mind when designing each stage we were able to minimize backtracking if a deliverable was deemed unacceptable and needed redesign. This approach also serves to mitigate risk as at each stage we have a functional, albeit incomplete, system.
5.5.2 Engineering Tomorrow's Systems Engineers Today
Authors: Goodlass Sue , Seabridge Allan
Published: November 2014

To date, the majority of engineers in UK industry have acquired their qualifications and skills from a ‘traditional’ engineering education, and tend to specialise in a particular ‘branch’ or discipline of engineering or science.

Developing the breadth as well as depth needed by Systems Engineers has traditionally only been achievable over a long period of time, especially in the Aerospace and Defence sector where lifecycles of complex systems and platforms can be as long as 50 years.

Given the increased demand for reductions in ‘to‐market’ times and the emphasis on whole life services, how can BAE SYSTEMS fast track the process needed to develop the breadth of knowledge and experience to become a successful Systems Engineer in today's rapidly changing Defence environment? Is it possible to convert large numbers of specialist engineers with different educational backgrounds and experience levels into useful Systems Engineers?
2.6.1 Extending the Systems Engineering Methodology to Include Supportability Engineering
Authors: Hanna Michele
Published: November 2014

Systems' engineering has always been an essential part of developing integrated solutions. From its' earliest inceptions, systems engineering dealt with providing a solution that balanced performance and operational requirements at the lowest life cycle cost. As an art form, systems' engineering was based upon the methods and processes of individuals. As the tools, methodologies and philosophies of systems engineering evolved, it was transformed from an art to a science. This transformation is demonstrated in evolution that occurred through IEEE 1220, EIA 632, and EIA 731.

While many of the attributes of these guidance documents map in to understood design areas such as hardware, software, and ease of manufacture, they do not clearly map into areas such as support strategy, impact to total ownership cost, maintenance planning and technology refresh cycles. These later actions fall under the discipline of supportability engineering. The systems engineering model contains numerous opportunities for supportability linkage, however the supportability hand‐offs were undefined when the systems engineering standards were released. This is because systems engineering guidance documents were being written at the same time supportability engineering was evolving to a standalone entity. The result is the documents have a strong interface, but without the necessary details to effectively integrate the disciplines.

This paper describes the interconnections and key linkages that need to be addressed to flow information between supportability engineering and systems engineering, and the further evolution of the systems engineering process through assimilation of supportability engineering.
3.6.2 Using a Rapid Incremental Solution Construction Approach to Maximise the Completeness and Correctness of a Set of Requirements for a System
Authors: Kasser Joseph E. , Cook Stephen C.
Published: November 2014

While the problem of poor requirements engineering and management has been documented since the dawn of systems engineering the continual documentation and discussion of the problem requirements has not resulted in a practical solution to the problem. This paper discusses applying the Blackboard methodology used in Artificial Intelligence to the development of a suite of Computer Enhanced Systems Engineering (CESE) tools that may be able to alleviate much of the problem. The paper also describes conceptual prototypes of the tools that have already been developed, their effect on alleviating the problem of poor requirements, and some concepts for future tools in the suite.
4.6.1 An Integrated Tool Suite for the NOAA Observing System Ar chitecture
Authors: Martin James N
Published: November 2014

The NOAA Observing System Architecture describes a number of observing systems that provide accurate and timely environmental information to various stakeholders who depend on this information to make critical decisions about farming, construction, fishing, military operations, traffic safety, and so on. This paper describes a project to develop the interfaces between several tools to assist in development of the NOAA Observing System Architecture. We used “knowledge modeling” as the basic approach to capture information about the systems and other entities associated with the architecture. We are using the Metis enterprise architecture tool along with DOORS for requirements, NOAA Forge for team collaboration, and ArcIMS for geospatial data visualization.
3.7.3 Integrated Requirements & Configuration Management For Advanced Software Engineering
Authors: Sibbald Chris
Published: November 2014

Requirements Management is essentially the documentation and communication of what is to be delivered for a product. Requirements management ensures a common understanding, between customer and supplier, of what's needed for a project to be successful – and for the customer to be satisfied. The fundamental nature of collecting and managing requirements must accept and welcome change. In fact, most organizations lack any sort of formal process for describing who is accountable and responsible for approving change. This is especially difficult when hundreds of developers, contractors, customers, and leaders are involved. Configuration Management consists of identifying configuration items and associated configuration documentation, implementing change control, maintaining configuration status and performing configuration audits. Linking requirements and configuration management improves communication, accountability and delivery of software and systems projects.
5.7.3 Developing an Information Sharing Architecture across a Complex Competitive Environment
Authors: Macaulay Andrew L , Jenkins Adrian
Published: November 2014

The UK's Warship Support Agency (WSA) works with hundreds of companies to support the Fleet. The information needed is often hosted and managed by these companies, with many of them in active competition with one another.

As many business processes span organisations, the sharing of information across boundaries is crucial. To achieve this, change projects were initiated by individual business units, resulting in ‘Shared Data Environments’ between these business units and their partners. Although this approach promotes innovation and rapid progress, it can hinder information sharing across the wider enterprise.

This paper sets out the approach adopted by the WSA and Cap Gemini Ernst & Young (WSA's strategic e‐business partner) to develop a Technical Architecture for further information sharing across the enterprise. Key findings from the architecture study are also presented, which have relevance to many organisations seeking to integrate information systems across enterprise boundaries.
6.7.3 The Raytheon Enterprise Architecture Process (REAP)
Authors: Siegers Rolf
Published: November 2014

Architecture processes have become an essential component in the construction of complex systems and in the government's evaluation of defense contractors. The Raytheon Enterprise Architecture Process (REAP) is a systems architecting process being developed by Raytheon Company to address both the needs of our customers and of Raytheon as a system integrator. This process integrates established industry and government standards including: Zachman Framework for Enterprise Architecture, C4ISR/Department of Defense Architecture Framework, Software Engineering Institute's Architecture Tradeoff Analysis Method, Unified Modeling Language, and Colored Petri Nets. The REAP initiative is being approached as a “one‐company” standardized methodology to address architecture definition, description, evolution, and assessment throughout Raytheon. The REAP facilitates higher interoperability for our customers' systems, enables the sharing of architectural best practices through common taxonomy and representation, and supports the creation of product line architecture templates to provide established architecture baselines for the design of new systems.
1.8.2 Managing Project Risks in Requirements, Design and Development using Planguage
Authors: Gilb Tom
Published: November 2014

Risk management must be fully integrated into all the development and maintenance processes for systems. It involves far more than applying risk assessment methods to identify and evaluate system risks.

To explain this broad approach to risk management, this paper discusses the way in which ‘Planguage,’ which consists of a specification and planning language, and a set of methods developed by the author, contributes to handling risks. It explains some suggested principles, some suggested processes and some specification methods.
1.8.3 Military Value of Spectrum (MVOS): A Case Study in Resource Risk Assessment
Authors: Jones Leo H.
Published: November 2014

The Military Value of Spectrum (MVOS) initiative was begun in late FY01 by the Defense Spectrum Office (DSO) to explore the potential for applying military operations research disciplines and principles to the challenges in spectrum access and use facing the DoD. In this paper we define MVOS as a decisive military advantage gained through the use of spectrum‐dependent technology. We have developed a logical framework to aid the Department of Defense in evaluating the impacts of various spectrum access strategies. Our initial studies demonstrate significant quantifiable connections between spectrum access and traditional measures of military success. We encourage broad participation in the further development of MVOS.
2.8.1 Will Car Manufacturers Survive the Second Death of Henry FORD?
Authors: Jean‐Philippe M.
Published: November 2014

Henry FORD was a visionary man that did not only create a huge company, he also built up a comprehensive architecture of the “car system”, including the product, the process, the operations and the service. This architecture was so good that it lasted nearly 100 years, being the basis for one of the strongest industries of the 20th century.

The 21st century comes with new requirements, as well as with new technological opportunities that drastically change the way the car systems may be built. But, just as the “fly by wire” killed most of the aircraft manufacturers, the “drive by wire” is likely to produce the same results and be as lethal for the automotive industry.

This paper tries to re‐capture the Henry FORD architecture and to put it in perspective with today's concerns and evolutions. Then, a possible systems engineering road map is given to highlight areas where car engineering may reduce the time and money wasted when designing a car.
2.8.2 Deployment of SE including Manufacturing Systems development: Theoretical Aspects
Authors: Lardeur Etienne , Auzet Christian , Bocquet Jean‐Claude
Published: November 2014

Nowadays, the improvement of engineering efficiency is presently one of the most important issue within the industry field. Engineering coordination through information control is often taken as a means to resolve this issue. PSA Peugeot Citroën has decided to explore this approach, and has consequently decided to deploy Systems Engineering. SE provides an adequate and structured approach for the development of the new vehicles. Vehicles can be considered as complex products. Manufacturing Systems also. Because of its industrial background, the SE Framework of an automotive company must take into account the development of the products, but also the development of the related manufacturing systems. This study is the answer ‐ on theoretical aspects ‐ to the following problematic: how can optimal co‐ordination of the engineering of a complex and mass product and its associated manufacturing systems can be reached in reality? This paper presents the theoretical aspects of a Ph. D. study. Another submitted and accepted paper presents the practical aspects of the same study.
3.8.1 Repeating Design Errors or “Where's The History?”
Authors: Bennett Randal D. , Sloan Crystal D.
Published: November 2014

The Oliver Hazard Perry class of frigates and the Arleigh Burke class of destroyers, the US Navy's newest combatants, share a common design fault despite, or perhaps because of, a 20‐year difference in design time. This paper describes the fault and links the underlying cause of the error to a lack of readily available historical knowledge. A solution is proposed to prevent the recurrence of error repetition by increasing the visibility of corrective maintenance actions to designers and of the status of material condition throughout the fleet to the maintenance managers and operations planners. The results of the process include better design, elimination of repetitive design errors, and true depictions of fleet readiness as a systems engineering solution.
2.3.3 A Transparent Way for Process Guidance in Satellite Design
Authors: Finkel Stephan , Burazanis Michael
Published: November 2014

This paper describes the development of a satellite design process and its implementation within a process guidance tool (Process Steering Tool – ProST) for the work within a design center environment (Satellite Design Office – SDO). Process and tool have been developed at the Institute of Astronautics (LRT) of the Technische Universität München in cooperation with EADS Astrium Ottobrunn within the BaiCES project (Bavarian Center of Excellence for Satellite Constellation Systems) partially funded by the Bayerische Forschungsstiftung BFS. The work presented in this paper was based on two major aspects, the design center concept and the satellite design process. The paper emphasizes a new way of process guidance, using a web based tool support, against the background of these aspects.

The authors present the overall process development and guidance approach, in particular the design and implementation of the satellite design center process within the process steering tool and the process guidance provided by the tool. The paper also highlights the evolution from the idea of developing a HTML based process guidance demonstrator to a dynamic PHP/mySQL based tool. It also shows that this approach is well suited for the guidance of a design center team through a development process. The usability and flexibility of this process was shown during a satellite design workshop at the Institute of Astronautics. At the end of the paper the next steps of the process and tool development will be presented.
2.5.3 Unifying Systems Engineering Through the System Record
Authors: Baden Gregory R.
Published: November 2014

Managing the information and processes that are intrinsic to systems engineering efforts requires the identification and control of a range of enterprise data. This paper presents an approach to systems engineering management that is based on the concept of the “system record.” By capturing and managing the system record, an organization gains visibility into the five major content areas that feed the systems engineering effort and integrates these content areas within a managed process from the concept phase through retirement. Intrinsic to this approach is the ability to operate on system engineering content from the highest system level to the detailed component level within the context of both process and content interrelationships. Examples of how the system record concept can be utilized in system engineering projects are included.
3.1.3 Complex System Classification
Authors: Magee C. L. , de Weck O. L.
Published: November 2014

The use of terms such as “Engineering Systems”, “System of systems” and others have been coming into greater use over the past decade to denote systems of importance but with implied higher complexity than for the term systems alone. This paper searches for a useful taxonomy or classification scheme for complex Systems. There are two aspects to this problem: 1) distinguishing between Engineering Systems (the term we use) and other Systems, and 2) differentiating among Engineering Systems. Engineering Systems are found to be differentiated from other complex systems by being human‐designed and having both significant human complexity as well as significant technical complexity. As far as differentiating among various engineering systems, it is suggested that functional type is the most useful attribute for classification differentiation. Information, energy, value and mass acted upon by various processes are the foundation concepts underlying the technical types.
3.2.1 Failure Modes And Two Types Of Robustness
Authors: Clausing Don , Frey Daniel D.
Published: November 2014

Reliability is one of the most important characteristics of a system. To be reliable a system must be robust and mistake free. Robustness is achieved by avoiding failure modes, even in the presence of noises that strongly tend to excite the failure modes. Basic systems engineering primarily considers two‐sided failure modes, such as excessive deviation from the correct voltage reading for a voltmeter, which can be either positive or negative; thus the name two sided. In this paper we focus attention on one‐sided failure modes, which occur only on one side of the distribution for the exciting noise(s). A single one‐sided failure mode is easy to avoid. However, in complex systems it is common for two or more one‐sided failure modes to be affected by one critical design parameter in such a way that it is challenging to avoid both failure modes. A path to a reliable system is to open an operating window between the two one‐sided failure modes.
5.3.2 Creativity in Systems Engineering
Authors: Warner Dawn E.
Published: November 2014

A survey of the systems engineering literature reveals an interesting relationship between the artistic terms of ‘art’, ‘originality’, ‘creativity’, and ‘innovation’. An order and nesting of these terms is proposed, and their relationship to the systems engineering discipline is examined. The specific focus is on how creativity is defined in the context of systems engineering, its importance to the discipline, and how it is being used today in system architecting, the transition from research to development, design synthesis, alternatives in decision making, emergence, and project management.
6.2.2 A Program of Research into Systems Engineering
Authors: Kasser Joseph E. , Cook Stephen C.
Published: November 2014

This paper provides an overview of a number of research areas that include investigating the nature of systems engineering and its underlying concepts, defining the properties of object‐oriented requirements, producing prototype object‐oriented tools for systems engineering, and applying of systems engineering to various domains.
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

As 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

Assessing 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

SysML 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

A 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

Requirements 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

A 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

The 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

In 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

This 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

Conventional 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

Success 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

One 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

Traditional 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

On 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

Over 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

START 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

Many 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

Modeling 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

Many 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

This 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

Enterprise 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

The 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.
9.3.2 “Real Options and Value Driven Design in Spiral Development”
Authors: Dahlgren John W.
Published: November 2014

This paper proposes that the failure of many programs stems from inaccurate requirements development and failure to design for spiral development. The tremendous growth in the complexity of our society has led to a proportional growth in the number of requirements and requirements changes for many systems. This paper proposes the use of the Real Options and Value Driven Design paradigms to the system engineering, design, sprial development and program management processes. The paper also discusses how the use of the Pareto frontier with the purpose of optimizing the performance/cost ratio may actually lead to problems in fielding complex systems. This author has recently begun a research project in Real Options to determine the design tenets that make some systems flexible, adaptable, upgradeable, and scalable, while still reliable; thereby enabling these systems to last many more years than comparable systems. Research results will be discussed in a follow up paper.
The Architecture of Enterprise Architecture
Authors: Blevins Terence
Published: November 2014

The Architecture of Enterprise Architecture paper answers questions such as; what makes up enterprise architecture? where is enterprise architecture relative to other enterprise processes? and what is necessary to make enterprise architecture work in the complex environments where it is deployed? This paper presents a categorization of architecture offerings that can be used to position and describe the architecture space and provides summarized and supportive information to the main thesis including architecture in the value chain, the social framework in which architecture exists, the skills required for success, and a view of the roles and responsibilities of architects.