bluuebunny/crossref_metadata_2025 huggingface dataset:
7.6.1 Applying the Object Oriented Systems Engineering Method to A Simple Hardware System
Authors: Hsu John C. , McDonough J. Mike
Published: November 2014

The application of Object‐Oriented Systems Engineering Method (OOSEM) to hardware systems has been controversial since it was initiated. This paper will explore its applicability and its effectiveness relative to traditional systems engineering approach. A simple Mouse Trap hardware system was used for the case study. The System Requirements can be derived from the System Diagram. The Activity Diagram can be used to visualize the workflow scenario. The Sequence Diagram can provide earlier interface identification between subsystems. The Collaboration Diagram shows the functional and physical data between subsystems. The Logical Architecture and allocation can generate logical components and develop the Class Diagram for subsystems. The design of this simple hardware system can be accomplished using the OOSEM. A definitive conclusion cannot be made as to which approach, between the traditional systems engineering and OOSEM, is better in assisting a simple hardware system design.
7.6.2 OBJECT‐ORIENTED AND STRUCTURED ANALYSES ARE HOMEOMORPHIC
Authors: Carl Joseph , Hofmeister Janet
Published: November 2014

Object‐oriented analysis and design methods are becoming predominant in the systems engineering workplace. One result is that object‐oriented analysis (OOA) may come to replace older structured analysis (SA) methods traditionally used by systems engineers. Another result is that assertions are sometimes found in the literature claiming or implying that object‐oriented analysis methods are uniformly better than structured analysis methods. But if OOA and SA are homeomorphic1, a systems engineer should choose to work with the analysis methods and representations that are most effective and convenient to solve specific problems of interest.

A substantially complete invertible mapping is presented in this paper to serve as evidence that OOA and SA are homeomorphic. A characterization of the kinds of problems better suited to one domain than the other is included in the paper.
7.6.3 Role of Emerging Technologies in Facilitating Integration of ATM Operations: A Look at One Example: XML & Its Related Technologies
Authors: Katkin Rafe , Taber Norma , Connolly Kelly
Published: November 2014

The authors present the business case for using the Extensible Markup Language (XML) and its related technologies (Document Type Definitions, Extensible Stylesheet Language, XML Schemas, and XQuery to name just a few) in Federal Aviation Administration (FAA) initiatives that involve fielding air traffic management (ATM) operational systems which will (or may) need to share information with other ATM operational systems. The growing use of these technologies in a wide variety of aviation related applications, several of which are noted in this paper, as well as the growth in the range, robustness, and availability of the technologies themselves lead the authors to recommend that FAA give explicit consideration to using XML to facilitate fielding interoperable ATM applications.
8.1.1 The Use of Planguage to Improve Requirement Specifications
Authors: Gilb Tom
Published: November 2014

I believe that most current requirement specifications lack clarity, and are very poor in their supporting information. We need to make requirement specifications ‘work harder’ by adding more ‘background’ to the requirements By ‘background’ I mean information related to the requirement that is not the core requirement itself. The background information I am referring to includes: prioritization (expressed by such means as ‘Justification’), risk management (expressed using such means as ‘Assumptions’), change management (for example, the integration requirements), and quality control (for example, the testability requirements).

To improve requirement specification, I have developed a requirement specification language, as a subset of my planning language, ‘Planguage‘. This language has developed by practical need, in international industry over three decades, and is supplemented here with some recent ideas. This paper will give an overview of the conceptual basis and some sample detail.
8.1.3 Ten Questions to Ask Before Opening the Requirements Document
Authors: Davies Paul
Published: November 2014

In projects where Systems Engineering is applied, the basis for contract is usually a set of Requirements, captured in one or more requirements documents. The Supplier must understand the requirement set, and evaluate his potential to supply the required functionality and performance at acceptable cost, timescale and risk. There is a risk that he may commit himself to a solution and a cost, thinking that the requirement set is understood, when in fact there are hidden omissions, contradictions and risks which expose the Supplier to potential project failures. This paper presents a simple checklist of ten questions, based on practical experience, that the Supplier's Requirements Analyst or Chief Engineer should ask himself, and ideally to ask his customer, before such a commitment. These questions do not depend on the detailed content of the requirements – instead they are properties of the set itself.
8.5.2 Evaluation of Interrater Agreement in Internal Audit based on ISO 9001:2000
Authors: Hwang Young Ha , Yi Chan‐goo
Published: November 2014

An internal audit in quality management system based on ISO 9001:2000 is an important process that continually improves the effectiveness and efficiency of a quality management system. The reliability of assessments of an internal audit based on ISO 9001:2000 is an issue that continues to demand the attention of researchers in this field. One element of reliability is the extent to which different teams assessing the same project produce similar ratings when presented with the same evidence. Cohen's Kappa coefficient has been the most popular measure of reliability for measuring the degree of interrater agreement beyond chance. However, the application of the Kappa coefficient may be biased downwards due to two Kappa “paradoxes.” To compensate for the deficiency of the Kappa coefficient, we additionally use a simpler index of observed agreement between two teams of auditors. Using Cohen's Kappa coefficient and the observed agreement, this paper presents some results from two assessments between two teams conducted during internal audits in Electronics and Telecommunications Research Institute in Korea. In each of these assessments, two independent teams performed the same ratings. The results indicate that in general there is at least moderate agreement between the two teams and the extent of agreement between the two teams is substantial.
8.6.3 Maintenance Practices and Metrics across Defense and Commercial Systems
Authors: Ramchand Ramya , Tatikonda Nirmala , Verma Dinesh , Nance Richard E.
Published: November 2014

Systems and software engineering are converging disciplines with increasing evolution of modern complex systems towards increased information and knowledge content. Further, with the capital investment associated with such systems and their long operational life spans, a longer‐term notion of quality during design and implementation is necessary. The realities of cost, safety, and staffing considerations are forcing increasing emphasis on reuse and reengineering strategies. This imperative becomes even more urgent with the thrust towards the inclusion of commercial‐off‐the‐shelf components in system architectures. One key operational imperative for complex systems is the cost of maintenance. This paper presents an industry survey conducted to understand maintenance practices prevalent in commercial and defense industries. Results from an industry survey focused on system maintenance measures and metrics are also presented. This survey focused on information and knowledge intensive systems and was supported by INCOSE‐The International Council on Systems Engineering and SOLE‐The International Society of Logistics.
9.1.2 Future Trends in Automotive Requirements Engineering
Authors: Houdek Frank , Weber Matthias
Published: November 2014

In the last few years, requirements engineering for software‐based systems has attracted a great deal of attention in the automotive industry. Requirements specification documents have been recognized as a crucial element in the software and system quality chain. Consequently, several industrial initiatives have been launched to improve requirements specification quality, the creation process, and tool support. For instance, many automotive OEMs have introduced requirements engineering expert groups and piloting of requirements management tools.

Despite the fact that the situation is still substantially heterogeneous, we observe a common level that the more mature projects have adapted as the current state of practice. However, due to methodological and tool restrictions, this level still falls very short of the full potential of tool‐supported systematic requirements management in the automotive domain.

In this paper, we summarize the current state of the practice in requirements engineering for software‐based automotive systems (such as electronic control units) and identify future research directions and tool enhancement requirements. Additionally, we try to identify some popular myths, i.e. ideas that are often mentioned in the context of automotive requirements engineering but which seem to be unrealistic and/or undesirable from our point of view.
9.1.3 System Engineering Approach to Shipborne Weapon System Design
Authors: Sclano Eliseo , Giuliano Carlo , Calvo Corrado
Published: November 2014

One of the problems that System Engineers have to deal with whilst carrying out system design is to allocate requirements to the subsystems. An approach based on a stochastic model to perform requirements allocation to the subsystems of a Shipborne Weapon System (SWS) is outlined in this paper. The model allows computing the overall system performance, in terms of Probability of Escaping Hits (PEH). Computation of PEH is related to the predetermined set of multi‐threats scenarios (including the threat characteristics), the defended area and the ship vulnerability, but at the same time it is subject to functional, physical and performance assumptions of the subsystems as derived from trade‐off studies. On one hand, the model allows to check whether the overall system performance of a SWS configuration, not completely defined by the customer, is achieved and eventually, after the needed iterations, the parameters characterising each subsystem become requirements. On the other hand, if the subsystems characteristics are known, the model allows checking the overall system performance.
9.2.3 Gathering Historical Lifecycle Quality Costs to Support Optimizing the VVT Process
Authors: Engel Avner , Bogomolni Izhak , Shachar Shalom , Grinman Arie
Published: November 2014

The purpose of this paper is to describe the process and results of gathering historical lifecycle quality costs for avionic systems. This is done via a pilot project conducted at LAHAV, the military aircraft division of the Israel Aircraft Industries (IAI). This project is performed in conjunction with the SysTest project, a European Comission R&D project chartered with developing a systems Verification, Validation and Testing (VVT) methodology and a process model for estimating product lifecycle cost, risk, quality, time, etc.

The SysTest project and IAI's pilot project are described briefly. The paper presents IAI's methods for obtaining historical quality cost data covering the entire lifecycle with a further focus on the development phases. Quantitative methods for aggregating the results as well as quality cost implications are discussed along with means to optimize the VVT process and reduce the cost of quality at IAI.
9.3.1 A Knowledge Management System Life Cycle Description Using the ISO/IEC 15288 Standard
Authors: Herald Tom , Berkemeyer Wayne , Lawson Harold W.
Published: November 2014

Development of a Knowledge Management (KM) system is often considered to be a technical challenge of incorporating the proper system building blocks that provide the mechanism for information transfer from a knowledge source to a potential user. These building blocks include tangible elements such as databases, servers, networks, search engines, web portals and even extend to expert networks and artificial intelligence algorithms. This paper provides a life cycle description of a KM system that includes both tangible and intangible elements. These intangible elements include interfacing the human‐in‐the‐loop, human motivation to contribute to (and to search) the KM system, and establishing a community of practice that includes policies, procedures and guides that encourage a learning organization. Peter Senge (Senge 1994) defines a learning organization as requiring an environment for individual and organizational growth to facilitate continual improvement and maintain a leadership position. The KM system is a tool that, when properly implemented in a business, can indeed facilitate the environment of a learning organization. This paper uses the recently released ISO/IEC 15288 standard (ISO/IEC 2002) and provides a detailed system description model for the life cycle Technical Processes implemented for a KM system. ISO/IEC 15288 also provides descriptions of Enterprise, Agreement and Program Management processes which are summarized for the KM system as a part of Appendix A.
9.3.2 Integrating System Engineering into PDM by AP233
Authors:   EADS Deutschland GmbH, Eckert Roland ,   EADS Deutschland GmbH, Mansel Wolfgang
Published: November 2014

In the manufacturing industry Product Data Management (PDM) systems are backbone systems. The data must be complete, correct, easy to find, easy to visualise and extractable for reports. A drawback is that today's PDM systems are focussed on automotive applications. There is however an increasing need e.g. from aerospace industry for an extended PDM schema to cover systems engineering product aspects. STEP ISO 10303 ‐ AP233 provides an appropriate approach for integrating systems engineering needs into PDM systems, specifically future modularised STEP ISO 10303 application protocols will allow to construct the required PDM schema extensions at reduced customisation effort. A framework for a systems engineering PDM system is proposed and data exchange aspects discussed. A demonstrator for the proposed solution was build using AP233 interfaces for systems engineering CASE tools coupled to an appropriate PDM system.
9.4.3 Thales system engineering community of practice : a knowledge management approach
Authors: Decamps Cécile , Galinier Michel
Published: November 2014

About 3000 people worldwide belong to the Thales system engineering community. This community of common practices is first of all based on human networks and coordination, but it also requires a systematic approach (tools, methods and processes) to facilitate knowledge and work sharing.

This paper describes the objectives, way to proceed and main results of such a knowledge management approach.
9.5.2 An integrated set of technical measures to support earned value management and technical review
Authors: Sillitto H G
Published: November 2014

Successful experience with the use of key technical performance indicators, in a number of projects in various businesses within the group, has allowed us to define a coherent set of key technical indicators. This set provides a comprehensive “health check” showing the status and current achievement of a project, and supports risk assessment and earned value management by providing an objective view of the current level and trend of solution maturity, requirements compliance, and residual uncertainty.

The set includes requirements and verification status, estimate of performance against key technical requirements, estimate of solution maturity, cost drivers, and issue close‐out. The paper presents the rationale and philosophy of the approach, and shows examples of the measures in action.
10.1 Achieving CMMI level 3
Authors: Richard Robert
Published: November 2014

Thales Training and Simulation (TT&S) SA achieved CMMI level 3 in June 2003. This covers Software, Project Management and Systems Engineering.

Following an action plan on Software (CMM level 3 achieved in 1996) TT&S defined a strategy leading to reach CMMI level 3 for all disciplines (including Bid and Project management). This paper aims at sharing :

lessons learnt to reach CMMI level 3

benefits perceived by TT&S

brakes encountered during implementation of the action plan

Three keys strongly contributed to this success. The first one is the experience that TT&S gained during the Software CMM action plan. The second one is the involvement of management. The third one is measurement of progress through internal assessments

Note: CMM and CMMI are registered copyrights of CMU/SEI
10.3 Architecture: A View Based on Multiple Impacts
Authors: Gilb Tom
Published: November 2014

In order to properly support the systems engineering process, the systems engineering profession needs to consciously adopt a more productive view of systems architecture. Many existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’ The focus needs to be shifted to the impact on requirements.
10.4 A Conceptual Glossary for Systems Engineering
Authors: Gilb Tom
Published: November 2014

This paper discusses some of the insights gained and the problems experienced to date in developing a conceptual glossary for the planning language, ‘Planguage.’ It also outlines a model to build on for similar work in organizing knowledge about concepts. The author's opinion is that further development of such glossaries is needed as concepts form a fundamental basis for educational and organizational purposes.
10.8 Integrating Systems Engineering and Marketing
Authors: Paul David J. , Webster William C. , Kenley C. Robert
Published: November 2014

Customer Oriented Requirements Understanding (CORU) continues to be the key to successful Systems Engineering and Marketing of large Aerospace and Government systems. Buyers hold all of the Requirements and all of the money. This is defined as the “Customer Needs or Requirements PULL” environment.

Systems Engineers ask if the principles of CORU operate in a Commercial “Seller Product or Technology PUSH” environment, and whether causal models can be constructed which address and differentiate (or segment) markets accurately. If so, the principles which are effective in large system acquisition environments (with limited numbers of stakeholders) can be translated to the relatively large stakeholder environment of product development for TELCOs, consumer electronics and high‐technology systems, and other high‐volume commercial products. The key process techniques of Requirements Elicitation and Requirements Causality Modeling are described along with a robust economic and Systems Engineering model for a network‐like architecture of how these processes link the Customers (Buyers) with Needs or Requirements together with the Sellers or developers of Capabilities or Products. Research results are delineated which make the case that these linkages through Requirements Elicitation and Requirements Causality Modeling process techniques are basic principles of CORU which are valid in both the Requirements PULL or DoD environments as well as in the Product PUSH or commercial environments. Examples are given in which Value Hierarchies are aligned across Customer‐Seller boundaries to achieve product success in both the Commercial and the DoD environments.
10.11 SpecRight: Writing correctly requirements, produce product specification and requirement justification file
Authors: Chevallier Jean , Marshall Richard M
Published: November 2014

SpecRight is a tooled approach to the capture of technical requirements, product specifications and requirements justification documents. This is done by combining educational elements, formal definitions, and automated work guides. By answering the questions in each work guide users can create complete systems engineering documents.

The objectives of the approach are to be an aid and a guide to capture and structure technical requirements and to produce and manage product specifications and requirements justification. As systems engineering needs correctly‐documented requirements, SpecRight is a useful means of performing the first step of the engineering process.

Following a demand from the European Space Agency (ESTEC) a prototype of SpecRight has been created to demonstrate that the logic could be performed and supported by software. We are now working to complete SpecRight such that it is in line with ISO 21351 Functional and Technical Specifications.
10.12 SYSTEM LEVEL EMC – FROM THEORY TO PRACTICE
Authors: Zamir R. , Bar‐Natan V.
Published: November 2014

This article discusses the vast importance of incorporating Electro‐Magnetic Compatibility (EMC) engineering as an inseparable part of system engineering in a complex, technologically‐advanced, tight‐scheduled military Project, starting from the Project proposal stage (in response to a Request for Proposal – RFP), down to cositing impacts tests in the platform. The Project's product is defined as an operational prototype. On one hand, this prototype will prove the system's functional properties as were specified by the Customer, while on the other hand serving as a first article that is required to withstand all of the environmental conditions as a serially‐produced system, including full EMC requirements. The unique system which is being addressed here has multiple, diverse capabilities and is comprised of elements and units belonging to various families, e.g., electronic boxes, electro‐optical units, inertial sensors, functional display, computer, etc. The units are based on home‐developed and Commercial Off‐the‐Shelf (COTS) units (military as well as civilian/industrial). Furthermore, we will present the methodology that was employed to minimize problems/failures during system EMC tests, in both the laboratory and after installation in the platform.
1.2.2 Using an Enterprise Architecture to Assess the Societal Benefits of Earth Science Research
Authors: Martin James N
Published: November 2014

An enterprise architecture for the Earth Science activities of the National Aeronautics and Space Administration (NASA) was developed to assist in assessing the capacity of scientific instruments in meeting the needs of society. It can also help them develop the right investment strategies and help scientists and engineers in their planning for system development, especially for complex space‐based environmental sensors. The architecture contains about 3000 elements that are involved in earth science research: observation sources, sensors, environmental parameters, data products, mission products, observations, science models, predictions, and decision‐support tools. The science models use observations from the space‐based instruments to generate predictions about various aspects of the environment. These predictions are used by decision‐makers around the world to help minimize property damage and loss of human life due to adverse conditions such as severe weather storms. The architecture is developed using both traditional and non‐traditional SE tools and techniques. This paper will describe additional methods needed for the SE toolbox.
1.2.3 The Systems Engineering Approach to Warship Signatures Management
Authors: Manzini Mauro , Montigiani Marco
Published: November 2014

This paper presents how Systems Engineering (SE) is applied to the design of warship radar and infrared signatures. The two signatures are treated as a system, the “signatures system“. Starting from the system definition a SE approach is described which provides a way of managing the warship signatures, taking into account all aspects involved and the relevant interrelations. The need to use a concurrent approach to reach a successful system design is highlighted.

While modern technologies do permit “fully stealth” designs, these require very great efforts, often in contrast with the constraints imposed by a real project. The aim of this paper is to show how the system level vision of SE allows design of a cost effective system which provides the proper balance of technical and economical factors.

Finally, a brief description of the role of the system engineer is provided.
1.3.3 Potholes in the Road to Good Systems Engineering
Authors: Armstrong James R.
Published: November 2014

Over several decades of observing the practice of systems engineering, both in classrooms and on programs, several recurring problems have been identified. It was anticipated that lessons would be learned, and this set of problems would decrease significantly in occurrence, if not disappear completely. However, that has not happened. It seems that many of the problems are rooted in basic mental roadblocks. This compendium is assembled as a watchlist of some of these roadblocks for new and old practitioners.
1.4.3 Estimating and Optimizing System's Quality Costs of Transport Helicopter Avionic System Upgrade
Authors: Engel Avner , Shachar Shalom , Bogomolni Itzhak
Published: November 2014

This paper depicts IAI's real‐life experience in estimating and optimizing system's quality costs associated with upgrading a transport helicopters' avionic system. This pilot project was conducted at Lahav, the military aircraft division of the Israel Aircraft Industries (IAI) in conjunction with the SysTest project. SysTest was a European Commission R&D project chartered with developing a systems Verification, Validation and Testing (VVT) methodology and a process model for estimating product lifecycle cost, risk, quality, time, etc.

The SysTest endeavor and IAI's pilot project are described briefly. Thereafter, the paper presents a case study where the overall quality costs are estimated based on the current VVT strategy established at Lahav/IAI. Our findings showed that the actual performance of VVT process amounted to 34% of the quality costs. The appraisal risk cost (expected cost associated with the detection of defects during the VVT process) amounted to 6%. Notably, the impact risk cost (cost emanated from not performing VVT as part of the VVT strategy) amounted to 60% of the quality costs. At the same time, a significantly improved VVT strategy, reducing the cost of quality by over 25%, is readily available.

Our conclusion is that the current VVT strategy at Lahav/IAI is clearly not a most efficient one. Less cost‐effective VVT activities are performed at too high a performance level and visa versa. We assert that systems' VVT is performed at many organizations based on “engineering intuition” and, plainly, this is not a good yardstick. We are currently starting to apply a formal VVT optimization methodology in a large IAI program, developing a state of the art communication satellite.
2.1.2 Enterprise Architecture and Aesthetics
Authors: King Paul
Published: November 2014

Enterprise architecture is the discipline of describing and analysing the relationship between an enterprise's objectives and purpose, and the system of systems which the enterprise uses to help achieve those objectives. This paper makes the case for the importance of aesthetics in enterprise architecture. It proposes an enterprise architectural modelling language which addresses enterprise form, purpose and aesthetics. This language is a meta‐model extension of SysML which uses the power of SysML to address the engineering aesthetic of enterprise architecture.

The paper is based on work carried out for the UK Ministry of Defence's Integration Authority to develop an “Integration Services Support Environment” (ISSE). ISSE uses the enterprise architecture modelling language to enable the consistent description, and hence analysis, of a large and heterogeneous system of systems. ISSE itself has been developed as a enterprise architecture modelling tool and as a repository of interconnected models of MoD's enterprise.
2.2.1 A Structured Method for Generating, Evaluating and Using Metrics
Authors: Kitterman Dick
Published: November 2014

This paper presents a method of generating metrics for a project, organization, process, or product. It first points out that metrics generation starts with a bounding of the area of interest. Then it shows how to examine the outputs associated with the area of interest for metrics on effectiveness that are stated in the general parameters of quantity, quality, cost and time. Next, the paper focuses on the area of interest's internal activities to develop metrics on efficiency, using the same general parameters. The paper then demonstrates a number of tests that can be used to evaluate the goodness of the metrics for use in a decision process. Finally, the paper discusses how metrics presentation has importance equal to metrics content and shows examples of good and bad ways to present metrics.
2.2.2 A Meta‐process Producing a Deliverable‐centric Process
Authors: Lizotte M. , Lalancette C. , Dussault G. , Lam S. , Couture M. , Mokhtari M. , Bernier F.
Published: November 2014

The current paper introduces the Iterative and Incremental Meta‐process (I2M) being applied to develop a Capability Engineering Process (CEP). This simple method is founded on the assumption that such a CEP, and even any process, should be developed as methodically as engineering is performed for systems and software system development. This effort is performed as part of a major Canadian R&D effort called the Collaborative, Capability, Definition, Engineering and Management (CapDEM).
2.2.3 Observable States May be Necessary When Using COTS Products
Authors: Botta Rick , Bahill Zach , Bahill Terry
Published: November 2014

In order to use commercial off the shelf (COTS) products, the engineer must be able to prove that the COTS product is equivalent to the specified design. In most cases, this requires observable states, which are usually not available. Other techniques that have been used in lieu of proving system equivalence include creating multiple reset (or test) states and proving input/output equivalence with respect to these initial state pairs, designing built‐in self‐tests, building observers to estimate the system states and adding extra outputs that imply the states. This paper also gives examples where states are necessary and unnecessary in modeling systems.
3.2.2 Four Strategies for Reliability
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 – it must avoid failure modes even in the presence of the broad range of noise factors such as harsh environments, changing operational demands, and internal deterioration. In this paper we focus attention on “one‐sided” failure modes, which occur only on one side of a range of noises. Four effective strategies are presented for achieving improved robustness to one‐sided failure modes by conceptual improvements. Each strategy is illustrated through two examples from industrial practice.
4.1.2 A Model‐Based Requirements Database Tool for Complex Embedded Systems
Authors: Bennett Matthew B. , Rasmussen Robert D. , Ingham Michel D.
Published: November 2014

It has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem‐level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to capture accurately the systems engineer's understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer's intent, potentially leading to software errors. This problem is addressed by a systems engineering methodology called State Analysis, which provides a process for capturing system and software requirements in the form of explicit models. This paper describes (1) how requirements for complex aerospace systems can be developed using State Analysis, (2) how these requirements inform the design of the system software, and (3) how this process has been aided through a State Analysis Database (SDB) and supporting multi‐platform client. The SDB provides a productive, collaborative development environment for State Analysis that is shared by both systems and software engineers.
4.3.1 Generic Measures of Effectiveness for Systems
Authors: Mackley Tim
Published: November 2014

The development of systems projects is often beset by problems because important parameters are not considered during their development. This paper sets out to determine a generic set of parameters for measuring the effectiveness of a system solution that can be used to compare different solutions, assess their development or consider strategies for replacement when in service. By consideration of a number of methods and models currently used within the domain of systems engineering, an attempt is made to produce a comprehensive list of measures of effectiveness.
4.3.3 Systems Engineering Measurement Primer – A Metrological Evaluation
Authors: Ferris Timothy L.J.
Published: November 2014

The paper presents the results of an investigation of the INCOSE Systems Engineering Measurement Primer from the framework of measurement theory. This approach to the Primer is outside the scope of the claims of the Primer, and so is not entirely fair to the authors of the Primer. This investigation is conducted in order to contribute to the development of measurement processes suitable for use in systems engineering and also to provide a theoretical framework for measurement of systems engineering processes.
4.4.3 Developing Requirements for Technology‐Driven Products
Authors: Wheatcraft Louis S.
Published: November 2014

New technology development is often a mainstay in product development, yet projects responsible for developing products based on new technology frequently are over budget, delivered late, poor in quality, and fail to meet customer and user needs and expectations. Two things that contribute to these problems are: 1) failing to define the product requirements up‐front and 2) failing to adequately manage the maturation of the enabling technology(s) needed. This paper introduces several key approaches and processes that address these issues and the many challenges of developing and managing requirements for technology‐driven products.
5.1.1 A Meeting of the Minds: A Successful Systems Engineering Experiment using Concept Maps for Effective Communications
Authors: BeVier John L. , Calimer Colleen A.
Published: November 2014

An informal experiment was conducted to test the effectiveness of communicating Systems Engineering concepts with customers using Concept Maps. The goal was to understand systems engineering concepts and techniques with customers using nontechnical diagrams, as well as to establish that the systems engineers had more‐accurately captured customer needs.

In short, the experiment was about creating a more customer‐friendly vehicle that enabled dialog between the customer and the engineer, without asking the customer to comprehend “Systems Engineering‐speak“. This paper describes the customer/engineer communication problems found during the experiment, compares the effectiveness of Concept Maps and Use Cases for this experiment, describes Concept Map basics and the customer's reaction to them, and describes the proposed Systems Engineer's use of Concept Maps. The authors note that there are other, successful systems engineering communication methodologies and endeavors. They were not addressed in this experiment.

Never‐the‐less, the result of the experiment was an enthusiastic and successful meeting of the minds, resulting in a successful shared customer/engineering vision. We offer our Concept Map findings for serious consideration in establishing both customer‐friendly and Systems Engineer effective communications.
5.1.3 Work Practice in Research: A Case Study
Authors: Martin Nathaniel G.
Published: November 2014

Work practice analysis is a type of Ethnography that studies individual and group work. It has been developing at Xerox over the past 20 years. Recently, it was applied by a research group studying text mining. It showed flaws in the group's initial understanding of the problem and redirected the group's attention from classification to clustering. In addition, it led to the development of a novel approach to text mining. Further study showed that the novel approach is widely applicable. We describe work practice in general, then provide a case study of the application or work practice analysis to the gathering requirements for text mining. We conclude that work practice analysis in specific helps bridge academic results and industrial practice.
5.3.1 What can a project manager learn from an actor? ‐ improving professional skills through analogical thinking
Authors: Backlund Göran , Sjunnesson Jan , Josephson Erland
Published: November 2014

A project manager with a holistic systems engineering perspective, encounters dilemmas and must make decisions on a daily basis. Traditional skills development programs are not well‐suited for these persons. Based on knowledge theory, a program has been developed that focuses on the practical knowledge that an experienced person has developed. The Dialog Seminar method has been used and tested on a group of project managers. At the final seminar of the program, the group met the well‐known Swedish actor Erland Josephson, and through analogical thinking, the project managers improved their understanding of their own professional roles through comparison with those of the actor and the director. The result is an awareness of the dilemmas, an ability to see them and meet them with improved security, and also insights on how they could improve their project management skills.
5.3.3 i‐pub – Towards Electronic Access to INCOSE Publications
Authors: Herzog Erik , Pandikow Asmus , Andersson Jonas
Published: November 2014

Over the years a large number of high quality papers have been published at INCOSE symposia and conferences. However, the knowledge encoded in these papers is not easily available to INCOSE members. Symposia papers are generally only available to the attendees of the symposium where the paper was published, and then only in a format that does not supports structured access, considering today's technical possibilities.

In this paper, we propose the implementation of an internet‐based INCOSE publication database (i‐pub) for facilitating access to INCOSE published papers. Results from initial prototyping activities are presented and an available COTS‐based software system is proposed for implementing the system.
5.4.1 RAS‐Centered Requirements Analysis
Authors: Grady Jeffrey O.
Published: November 2014

System engineers for years have used the requirements analysis sheet (RAS) as a means of connecting the functions identified for a system under development with the corresponding performance requirements and product entities that should accomplish those requirements and functions. But we have commonly not extended the utility of the RAS to cover every requirement found in a specification. This paper extends the RAS to include every requirement that would be found in a system or hardware specification but it is no problem to extend it further to contain all requirements. Work continues to extend the concept to the several software modeling methods (modern structured analysis, early OOA, UML, and DOD AF). The content of the paper resulted from research undertaken during re‐write of the author's book “System Requirements Analysis” in preparation for its re‐publishing by Elsiver Publishing in November 2005.
5.4.2 Why Are Requirements So Hard To Get Right?
Authors: Carl Joseph
Published: November 2014

There are many instances in the history of system developments that illustrate how difficult it is to discover and understand system requirements in the same way that stakeholders understand them. This has resulted in cancellation of some programs, and has resulted in cost and schedule overruns on other programs. Misunderstanding of requirements is an acute problem in the development of systems for government agencies, but it appears in commercial developments, too, where it takes the form of products that fail to meet market expectations (the Ford Edsel is a classic example).

This paper examines the deep reasons why requirements expressed in language are so hard to convey from a stakeholder to a supplier or from consumers to manufacturers. Semiotic concepts are summarized and bolstered with physiological and psychological evidence about the phonemic, syntactic and semantic properties of language. The paper concludes that language is profoundly arbitrary, whether spoken or written, whether in words or in pictures. It is therefore incumbent on all of us to remember the strong principle of communication: each party to a communication must work hard to understand what the other is trying to say. Such effort is one main thing that will help understand requirements. Additional help comes from development methodologies that quickly lower the level of abstraction by demonstrating solutions as early as possible, and by requesting feedback from stakeholders. Automated tools can also help.
6.1.3 Conceptual Design of an Environment for Systems Engineering Education
Authors: Ring Jack , Buede Dennis , Bolling Fred
Published: November 2014

A major problem in the teaching and learning of systems engineering is one of feedback concerning the quality of what we do: we often do not get any, and when we do, it is very late and imperfect. Accordingly, both initial learning and retention suffer. One of the few engineering domains involving complex systems and in which feedback is fast and quite accurate is racing, e.g., race cars!! Our proposed solution for the academic problem is a studio for modeling the “design, test, and operation of race cars“. This laboratory stresses the breadth of systems and systems engineering rather than the depth that is typical of classes in other engineering disciplines. The proposed studio can be used for capstone design and project courses at both the undergrad and grad courses.
6.2.1 “SYSTEMS ENGINEERING: DRIVING THE EVOLUTION TO ACTIONABLE ARCHITECTURE”
Authors: Popkin Jan
Published: November 2014

Systems engineering is a well‐developed, proven practice in both the commercial world and the US government. Enterprise architecture, while comparatively new to many federal agencies, brings together proven commercial and government architecture and modeling best practices from the last three decades. Systems engineering is a key thread in any enterprise architecture initiative. With its enterprise view, architecture builds a thread through systems engineering and relates it to broader enterprise IT efforts.

This paper examines the role and value of systems engineering in architecture development. How do the two relate to each other? Both utilize standards; both deliver a common platform that facilitates communications and information sharing among users.

Systems engineering delivers an actual product–a system; enterprise architecture delivers a blueprint. Both deliver interoperability, yet systems engineering deals with product development while enterprise architecture deals with alignment and management. Systems engineering provides information for decision support, but this is not the primary goal. Enterprise architecture delivers a blueprint for decision support, not for product development. Both disciplines share a relatively long history of practice.

We will discuss how systems engineering is related to broader architecture efforts. The importance of systems engineering as part of an architecture roadmap, and ultimately, a decision support tool, will be explored. We will also look at the trend toward ‘actionable’ architecture that integrates systems and mission, goals and capabilities into one view. ‘Actionable architecture’ offers improved decision support for IT in areas such as technology investments, gap analysis, cost reduction and improved efficiency.
6.4.3 Requirements Management, from the RFP to the Project
Authors: Jakacky Ronald F. , Doty Ormond R.
Published: November 2014

System Engineers during preparation of proposals for new contracts often overlook requirements analysis as a vital step in producing a comprehensive and compliant proposal. The rigor required for a traditional requirements analysis goes by the wayside in the rush of tight deadlines, limited staff, and the stress of proposal production. Once the program starts, the team then performs requirements analysis with the initial task of reconciling the requirements with the proposed offering. This reconciliation often uncovers compliance issues not identified during conceptual design, or discovers that there may be alternate solutions for the set of requirements.

A well thought out and streamlined requirements assessment process, implemented during the proposal, facilitates the development of system concepts that are complete and compliant while still satisfying demanding proposal preparation schedules. The assessment process then feeds a set of well‐analyzed and structured requirements directly into the post‐award contract work that reduces the need for reconciling the offering to the real program.

ITT Aerospace/Defense Division developed and deployed this process with great success in reducing compliance and coverage issues during the proposal phase and providing a solid foundation for beginning the new program. This process is also in deployment to another division of ITT.
7.1.2 Sea Level Requirements as Systems Engineering Size Metrics
Authors: Valerdi Ricardo , Raj Jatin
Published: November 2014

The Constructive Systems Engineering Cost Model (COSYSMO) represents a collaborative effort between industry, government, and academia to develop a general model to estimate systems engineering effort. The model development process has benefited from a diverse group of stakeholders that have contributed their domain expertise and historical project data for the purpose of developing an industry calibration. But the use of multiple stakeholders having diverse perspectives has introduced challenges for the developers of COSYSMO.

Among these challenges is ensuring that people have a consistent interpretation of the model's inputs. A consistent understanding of the inputs enables maximum benefits for its users and contributes to the model's predictive accuracy. The main premise of this paper is that the reliability of these inputs can be significantly improved with the aide of a sizing framework similar to one developed for writing software use cases. The focus of this paper is the first of four COSYSMO size drivers, # of Systems Requirements, for which counting rules are provided. In addition, two different experiments that used requirements as metrics are compared to illustrate the benefits introduced by counting rules.