bluuebunny/crossref_metadata_2025 huggingface dataset:
11.2.3 Security for the 22nd Century
Authors: De Spain Mark , Darby John , Cloutier Robert
Published: November 2014

Asymmetric threats are the new face of security in the 21st century, where a new breed of adversary threatens long established, essentially monolithic institutions at the core of western civilization. The direction of technology development has the potential to further exacerbate the unbalanced standoff between the new threat and established institutions, whether government, commercial, industrial or cultural, particularly when the adversary is a determined and ideologically driven foe that is willing to bide their time and develop their resources over extended periods that may stretch into decades. Systems Engineering has the potential of offering security solutions that look beyond the traditional approach of adding layers of security to functional systems. Security that is inherent to the product or process may be more adept at addressing the dynamic threat environments of today. The restructuring of organizational and product architectures may “rebalance” the threat/risk equation and reduce potentially catastrophic asymmetric threats to a tolerable symmetric “standoff.” Such restructuring does not come about easily or quickly, however, and fundamental shifts in infrastructure and culture can require generations to fully implement, so research into new security concepts today may not be completely realized until the 22nd century.
11.3.1 Formal Verification in System Design Process: From EFFBDs to Petri nets
Authors: Seidner Charlotte , Lerat Jean‐Philippe , Roux Olivier H.
Published: November 2014

Safety analysis in Systems Engineering (SE) processes, as usually implemented, rarely relies on formal methods such as model checking since such techniques, however powerful and mature, are deemed too complex for an efficient use. This paper thus aims to improve verification practice in SE design: considering the widely used model of EFFBDs (Enhanced Function Flow Block Diagrams), it proposes a method for a translation into time Petri Nets (TPNs); known results are then applied from TPNs to EFFBDs, leading to the possibility of assessing a number of safety‐critical properties. This paper also presents some tools developed in application of these results and in which the underlying complexity is totally concealed from the end‐user.
11.4.2 Applying SE Methods Achieves Project Success to Evaluate Hammer and Fixed Cutter Grinders Using Multiple Varieties and Moistures of Biomass Feedstock for Ethanol Production
Authors: Zirker Larry R. , Wright Christopher T. , Hamelin R. Douglas
Published: November 2014

Applying basic systems engineering (SE) tools to the mission analysis phases of a 2.5‐million dollar biomass pre‐processing project for the U.S. Department of Energy directly assisted the project principal investigator understand the complexity and identify the gaps of a moving‐target project and capture the undefined technical/functional requirements and deliverables from the project team and industrial partners. A creative application of various SE tools by non‐aerospace systems engineers developed an innovative “big picture” product that combined aspects of mission analysis with a project functional flow block diagram, providing immediate understanding of the depth and breath of the biomass preprocessing effort for all team members, customers, and industrial partners. The “big picture” diagram became the blue print to write the project test plan, and provided direction to bring the project back on track and achieve project success.
11.4.3 Systematic design of greenhouse crop production systems
Authors: Hemming Silke , van Henten Eldert , van ‘t Ooster Bert , Vanthoor Bram , Bakker Sjaak
Published: November 2014

Protected cultivation systems are used throughout the world as a powerful instrument to produce crops. They protect the crops from unfavorable outdoor climate conditions and pests and offer the opportunity to modify the indoor climate to create an environment that is optimal for crop growth and production, both in terms of quality and quantity. Designing protected cultivation systems is a multi‐factorial optimization problem. During this process, choices have to be made with respect to construction, cladding material, climate conditioning equipment, energy sources and management, growing substrates, water and nutrient supply, internal logistics and labour, to mention a few. All of these choices mutually influence each other and are influenced by local boundary conditions like climate, economics, market, legislation and availability of resources. This paper presents the outlines of a systematic design methodology to design protected cultivation systems including several design examples of modern greenhouses production systems.
Applying systems thinking and aligning it to systems engineering
Authors: Kasser Joseph , Mackley Tim
Published: November 2014

Abstract1

This is a paper on thinking about thinking. Systems engineering is an emerging discipline in the area of defining and solving problems in the manner of (Wymore, 1993). The emerging paradigm for problem solving is “systems thinking”. Both systems engineering and systems thinking have recognized the need to view a system from more than one perspective. This paper proposes a set of perspectives for applying systems thinking in systems engineering and then defines a systems thinking perspective set of views for a system, the use of which will provide one way of aligning systems thinking to systems engineering. The paper then provides an example of applying the set of perspectives to the Royal Air Force Battle of Britain Air Defence System and shows that not only does the set of perspectives provide a way to model the system; it also picked up two potentially fatal flaws in the system. The paper then concludes with some observations on the state of systems engineering from a number of the perspectives.
KR03 Global Positioning System (GPS) Systems Engineering Case Study
Authors: Bullard Randall , Colombi John , Freeman G. Richard
Published: November 2014

The Global Positioning System (GPS) Systems Engineering Case Study (O'Brien & Griffin, 2008) describes the application of systems engineering during the concept validation, system design and development, and production phases of the GPS program. The case examines the applied systems engineering processes, as well as the interactions of the GPS Joint Program Office, the prime contractors, and the plethora of government agencies that were associated with the programs development and fielding. The systems engineering process is traced from the initiation of studies and the development of key technologies that established the vision of a satellite navigation system in the 1960s, through the multi‐phase joint program that resulted in a full operational capability release in 1995. Numerous interviews were conducted with individuals who personally directed, managed and engineered the program, from which the systems engineering story emerged. Results are organized using the Friedman‐Sage Framework
KR07 SYSTEMS ENGINEERING: THE GLUE THAT BINDS DISPARATE ACQUISITION ORGANIZATIONS
Authors: Holzer Thomas H.
Published: November 2014

This case study presents how an effective joint systems engineering team can bring together disparate but mutually dependant acquisition organizations to improve enterprise acquisitions and technical integrity. The organization providing software applications and associated hardware may not be the same organization providing the host network and server infrastructure. The result can be incompatibilities between system needs and infrastructure capacity, stovepipe capabilities, and flawed acquisitions. A joint systems engineering forum with expanded responsibilities is mitigating these problems by improving collaboration and communication between the two organizations. Their concept of operation reflects how a team spanning application and infrastructure acquisitions can work together in minimizing redundant engineering functions and create a more cost effective and technically sound operational enterprise. Findings presented further show that joint systems engineering will help infrastructure providers and the applications developers successfully establish a more productive and cost efficient relationship.
KR12 Processes and Beyond
Authors: Gonçalves Duarte
Published: November 2014

Systems engineering is about coordination. To coordinate is to bring the different elements of a complex activity or organization into a harmonious or effective relationship as a whole system. This paper views coordination in the context of unprecedented or innovative systems and attempts to focus some attention on important social issues relating to how work gets done. A framework of coordination mechanisms is developed. Coordination can be performed using processes, work products, skill/knowledge and mutual adjustment (personal or group communication). Under conditions of high task uncertainty, high task interdependence and dynamic environments, mutual adjustment is favored as opposed to process. Under these conditions this is not a choice. Most methodologies use some combination of the basic coordination mechanisms. The paper presents a case study illustrating some aspects of coordination.
KR14 Emergent Behavior in Systems of Systems
Authors: Osmundson John S. , Huynh Thomas V. , Langford Gary O.
Published: November 2014

As the development of systems of systems becomes more important in global ventures, so does the issues of emergent behavior. The challenge for systems engineers is to predict and analyze emergent behavior, especially undesirable behavior, in systems of systems. In this paper we briefly discuss definitions of emergent behavior, describe a large‐scale system of system that exhibits emergent behavior, review previous approaches to analyzing emergent behavior, and then present a system modeling and simulation approach that has promise of allowing systems engineers to analyze potential emergent behavior in large scale systems of systems.
KR16 Moving Towards a Normative System Engineering Process: Why standards sometimes fail to gain traction
Authors: Haynes David , Dagli Cihan
Published: November 2014

The use of standards is one of the four architecting methodologies commonly used in Systems Engineering, but where do standards come from? Why are standards developed? Why do some standards fail to gain traction? Are standards always developed for the right reasons and along the right lines? This paper discusses the timing and emergence of new standards in the marketplace. The paper selects an emerging industry – Automated Meter Reading (AMR) and discusses the four “who's” (who benefits, who pays, who provides, and who loses) with respect to standard development. Finally, the paper offers some concluding remarks which contain recommendations for would‐be standards sponsors and developers.
KR18 Decomposition of Projects: How to Design Small Incremental Steps
Authors: Gilb Tom
Published: November 2014

The basic premise of iterative, incremental and evolutionary project management (Larman 2003) is that a project is divided into early, frequent and short duration delivery steps. One basic premise of these methods is that each step will attempt to deliver some real value to stakeholders. While it is not difficult to envisage the steps of construction for a system; there is often difficulty in carrying out decomposition into steps when each step has to deliver something of value to stakeholders, in particular to end‐users. This paper gives some guidelines, policies and principles for decomposition. It also gives a short example from practical experience. The evolutionary project management method (Evo) is used (Gilb 2005).
KR21 Systems Thinking and Technical Planning: The Roadmap for Air Force Systems Engineering in the 21st Century
Authors: Bullard Randy , Loren Jeff
Published: November 2014

Military acquisition has long emphasized the portion of the life cycle between the Request for Proposal (RFP) and Initial Operational Capability (IOC). In response to changing political and economic realities during the 1980s, though, much of the Services' own performance of many technical acquisition tasks devolved to management of contractor efforts. After a number of aircraft accidents in the mid‐ to late 1990s were traced to breakdowns in these processes, the Air Force issued new policy stressing the need to apply Systems Engineering (SE) discipline during later life cycle phases. Significant cost and schedule overruns on major programs, and resultant intense Congressional scrutiny, engendered several initiatives to restore technical and programmatic credibility throughout the entire Department of Defense (DoD) acquisition enterprise. This paper recounts the Air Force's approach to modernizing engineering and technical management policy and practices over the 2000–2006 timeframe, and provides a glimpse of key highlights of their roadmap for the next several years.
KR22 Standards for Defending Systems against Interaction Faults
Authors: Harel Avi
Published: November 2014

Interaction faults are operational failures attributed to improper interaction between system components. A special, very important case is when at least one of the system components is a human operator. For example, 60–80 percents of the accidents are due to user errors. This article presents guidelines for preventing and protecting from interaction faults.

Did you ever wonder why interactive systems are typically error‐prone and why system development is typically behind schedule? Interaction faults are a main source for productivity and maintenance loss, for customer dissatisfaction, for accidents and eventually, project failure and shortening the system life cycles. Interaction faults are actually the results of design defects. The article shows that the effort required to handle exceptional events is in an order of magnitude more than that for conforming to the requirements for normal operation.

A special, very important type of interaction faults is of state mismatch. The first section presents examples of various types of interaction faults, and the design defects that caused these faults.

Standards are essential for defending against user errors, because developers often feel irresponsible for user errors and typically avoid fixing the design mistakes that enable these errors. Yet, many of the standards proposed here may also help for the interaction between non‐human system elements.

An interaction fault is preceded by a trigger, which is a deviation of one of the interacting subsystems from the normal operational procedure. The article provides guidelines for preventing triggers attributed to user errors of two sources: usability mismatch and user slips. Few methods for preventing mode errors were tested using ModeTester, an experiment interaction specification tool by ErgoLight.

To detect interaction faults, the system may include an implementation of a protocol formalizing the operational procedures. The standards should provide guidelines for specifying the system behavior in cases of deviations from this protocol, in order to avoid the unpredictable results of operating in the unexpected circumstances.

From each incident, we can learn. The standards should include guidelines about enabling learning from incidents and from accidents.

Recently, the Standards Institute of Israel (SII) joined the international effort for usability standardization. Besides adopting international usability standards, which target usability practitioners, the Israeli chapter initiates standards that will target system engineers as well. In particular, the intention is to elaborate and formalize the guidelines and methods presented in this article, to help system engineers defend the system against interaction faults.

More about interaction faults: http://www.usability‐standards.com/English/Interaction‐Fault/
Right Sizing Reference Architectures; How to provide specific guidance with limited information
Authors: Muller Gerrit
Published: November 2014

The growing complexity and size of systems and the organizations that create these systems trigger the need for instruments that facilitate the creation of these systems. We shortly analyze these trends and the (potential) role of reference architectures as facilitating means. After a short discussion about the content of Reference Architectures and their relation with system architectures, system design and actual systems, we zoom in on the question what the appropriate level of detail is for Reference Architectures. We discuss an evolutionary approach to create and maintain Reference Architectures
A Large‐Scale Systems Engineering Perspective of Water Management in Singapore
Authors: Seng Eng , Gilbert Foo Kong Pin
Published: November 2014

For a small country with almost no natural resources, Singapore has, over its 42 years of independence, developed an intricate water management system. This system has evolved from a combination of resource development, political diplomacy and acceleration towards enabling water technology. Singapore has found that ensuring a viable water supply for future growth is no longer dependent on any specific domain, but rather across a series of options that, at present, have already poised the island state for self‐sufficiency. The selection of these options is not additive and must be analysed in consideration with the country's regional, political and economic goals. This paper examines Singapore's water management system from a large‐scale systems engineering perspective: goals, boundaries, stakeholders and complexities involved in such a system. Such an approach illustrates how systems thinking and systems engineering tools may be used to understand systems complexities, how learning organization concepts and methodologies may be applied to understand behavioural complexities and how lean thinking facilitates a long term strategic philosophy, built on the premise of continuous improvements. Perhaps more importantly, it shows that while systems engineering, especially the systems approach, is necessary for the conceptualisation and planning of such a system, it is the systemic structures that have been put in place and the people/ culture that make it possible.
What is Systems Engineering for Embedded Systems?
Authors: Boyer Adrian
Published: November 2014

This paper asks the question “What is Systems Engineering for Embedded Systems?” First the scene is set by discussing the prevalence of embedded systems in the world around us including examples, design metrics, and technology issues such as processor architecture. Then the aspects of Systems Engineering that apply to embedded systems are discussed in some detail with a focus on requirements issues such as end product utility and power management. This is followed by a discussion of the System Design issues relating to embedded systems such as real time operation, size & weight and cost. Some focus is applied to the issue of data management for embedded systems. Finally some tool related issues are discussed.
Paradox of the Bermuda Triangle Applying Systems Engineering in a PPP‐environment
Authors: Audsley Robert , van der Vooren René , Elich Erik
Published: November 2014

Applying Systems Engineering to a Public Private Partnership (PPP) contract requires a closed‐loop control between the project goals, the project management and the content itself. Unexpected events, contradicting incentives and many more reasons can easily open the closed‐loop without initially being perceived. All parties involved should participate actively at peer levels in order to assure the closed‐loop control. The transparent and phased approach of Systems Engineering supports achieving this peer level closed‐loop control.
Mitigating Rail Transit Project Risks with Systems Integration
Authors: Kouassi Alain J.
Published: November 2014

As rail transit systems are becoming more complex, from a hardware, software and technology standpoint, new approaches are being contemplated to reduce capital project risk. Systems integration has come forward as a way to efficiently transition from traditional systems designed and installed independently without the need for a formal, structured process for physical, functional, logical, and operational integration, to more integrated systems. This paper presents the application of systems integration as a way to mitigate risk on two light rail projects in New Jersey, USA. It discusses how and at what levels various and complex interfaces were managed, and presents methods used to ensure that interface gaps were avoided, duplication reduced, conflicting requirements across projects negotiated and managed, and coordination among all stakeholders refined. It also highlights similarities and differences in approaching the systems integration process for these two projects, the unique challenges faced by the project teams, and general lessons learned that can be carried forward on other capital projects.
1.1.2 Moving the Mindset: from Safety to Systems Safety
Authors: Campbell Alistair , Qureshi Zahid
Published: November 2014

Safety is the focus when accidents occur, and the default approach among the experts deployed to investigate such safety incidents, is to concentrate on the technology issues or human errors in isolation. While specific technical faults or human errors can typically be identified as having initiated the safety breach, widening the focus to gain a more systemic understanding of the context within which the accident occurred, is increasingly being recognised as best‐practice. Using the background of some important advances in the field of systems safety by authors such as Jackson and Leveson, this paper draws out the crucial role of the socio‐technical aspects.

This discussion is then contextualised by using examples taken from railway safety case studies, to focus on some key practical implications of using this enterprise‐wide systems approach. The paper concludes that a systems approach which includes the enterprise as well, becomes especially important when formulating strategic policy which works towards systems safety.
1.2.1 Development of an Exploratory Computer Model for Acquisition Management of System‐of‐systems
Authors: Ghose Shayani , DeLaurentis Daniel
Published: November 2014

The Department of Defense (DoD) has placed a growing emphasis in recent years on the pursuit of agile capabilities via net‐centric operations. In this setting, systems are increasingly required to interoperate along several dimensions. Yet, the manner in which components of these “system‐of‐systems” are acquired (designed, developed, tested and fielded) has not kept pace with the shifts in operational doctrine. Acquisition programs have struggled with complexities in both program management and engineering design. This paper presents a classification of underlying complexities in the acquisition of system‐of‐systems and describes a conceptual model that exposes the connectivity between systems, requirements, and externalities throughout the acquisition lifecycle. Implementing this model in an exploratory computer simulation highlights the relationship between requirement dependencies, risk profiles of the project and management parameters like span‐of‐control of SoS engineers and managers. The objective of the simulation (which remains under development) is to allow acquisition professionals to develop intuition for procuring and deploying system‐of‐systems, providing a venue for experimentation to develop insights that will underpin successful acquisition of SoS‐oriented defense capabilities.
1.4.0 “Has Asia Been Resilient to Natural Disaster Events and Terrorist Attacks? A Debate on the Issues”
Authors: Mackey W. , Jackson S. , Weng Y. L. , Durodie B. , Ferris T. , Dagli C. , Elias E.
Published: November 2014

During the past few years, natural disasters including the major earthquakes in China and Pakistan, the Tsunami floods of Indonesia, the firestorms of Australia, and terrorist attacks in Mumbai, India and Bali, Indonesia have caused major loss of life, injury and significant loss of property in Asia. How resilient have these Asian and Pacific countries been to these events?

During the same period, insurgent attacks in Iraq, subway bombings in London, fire attacks on the city of Paris, and continued threats of terrorists throughout the world have placed life at risk due to terrorist activities. Also hurricanes and destruction in New Orleans, LA and the Gulf Coast region of the United States have caused major loss of life, injury and significant loss of property. How does resilience in these communities compare to similar communities in Asia?

Terrorism is the systematic use of violence and force as a means of coercion through fear and intimidation. As we have seen since World War II and experienced first hand since the terrorist attacks of September 11, 2001, the calculated murder of political personalities has given way to the random killing of innocent people and civilian populations.

Natural disasters are perhaps even more threatening. Are we building systems and responding in a way that permits these communities to respond properly and be resilient to these kinds of events? How can the discipline of systems engineering assist in preparing for, responding to, recovering from and mitigate against the risks of natural disasters and terrorist events?

Since September 11, 2001, INCOSE through its Anti‐Terrorism International Working Group (ATIWG) has focused the principles, techniques, and practices of systems engineering on how to reduce and eradicate international terrorism. We have taken this opportunity to expand emergency preparedness efforts to natural disasters as well.

Through the ATIWG sponsoring of panels at previous INCOSE symposia (2002–2008), writing papers for publication (2003), a tutorial (2004), an Insight Issue (2006) and working group activities, the systems engineering community has discussed the application of collaborative engineering environments, simulation and modeling, religion, system solutions to defend against terrorism, psychology, and root causes of terrorism to address the vulnerabilities of systems as well as the attack responses to threats.

This panel continues the INCOSE application of systems engineering to these international problems by discussing the proper responses, recovery and resiliency of society and the systems it builds to natural disaster events and terrorist attacks.
2.2.2 Harmonizing Systems and Software Cost Estimation
Authors: Wang Gan , Roedler Garry J. , Valerdi Ricardo , Ankrum Aaron , Gaffney John E.
Published: November 2014

The objective of this paper is to examine the gaps and overlaps between software engineering and systems engineering cost models with intent to harmonize the estimates in engineering estimation. In particular, we evaluate the central assumptions of the COSYSMO and COCOMO II models and propose an approach to identify gaps and overlaps between them. We provide guidelines on how to reconcile and resolve the identified gaps and overlaps. The ultimate purpose of this work is to develop effective techniques for accurately estimating the combined systems and software engineering effort for software‐intensive systems.
3.2.2 A Bayesian Approach for Estimating Complex System Reliability
Authors: DOGUC Ozge , RAMIREZ‐MARQUEZ Jose Emmanuel
Published: November 2014

Although a number of recent studies on using BN for system reliability estimation have been proposed, these studies are based on the assumption that a pre‐built BN was designed to represent the system. In these studies, the task of building the BN is typically left to a group of specialists who are BN and domain experts. However the process of building a system‐specific BN is generally very time consuming and may lead to incorrect deductions. As there are no existing studies to eliminate the need for a human expert in the process of system reliability estimation, this paper introduces a holistic method that uses historical data about the system to be modeled as a BN and provides efficient techniques for automated construction of the BN model and estimation of the system reliability. Moreover, very limited human intervention is sufficient for the process of BN construction and reliability estimation.
3.4.1 Global Systems Engineering at Rolls‐Royce: Using Stories to Explore Ambiguous Standards and Emergent Architecture
Authors: Atherton Malvern J. , Collins Shawn T. , Fisher Stephen A. , Hill Ralph W. , Fisher Stephen A.
Published: November 2014

This paper discusses Rolls‐Royce' experience in implementing a standardized set of roles and control system requirements for its product development projects. It reviews the responsibilities of systems and software engineers, the task of system architecture and its implications on documentation structures. Industry guidelines allow for the definition of more detailed item‐level requirements arising from the system architecture process. However, there is considerable ambiguity in the information transfers to the component life cycle processes and the distinction between these “item/ derived requirements” and “system requirements” in general. A review of projects shows that Rolls‐Royce programs have developed different approaches to the system architecting process. This demonstrates the variety of interpretations for the industry standards such as DO‐178B and ARP‐4754. It also provides a broad set of potential resources for a globally managed development program. However, the ambiguity in the industry standards means that the system architecting process is not always straightforward (as evidenced by its varying Rolls‐Royce embodiments). The paper concludes by developing stories and use cases that help to address differing cultural perspectives, and to replace existing local stories with a new set of stories that can be globally recognized and adopted.
3.4.3 A Comparative Analysis of Project Management and Systems Engineering Techniques in CubeSat Projects
Authors: Elstak Joost , Amini Rouzbeh , Hamann Robbert
Published: November 2014

In the year 2000, California Polytechnic State University and Stanford University issued a new standard for small satellites: The CubeSat standard. This standard allowed universities to design, build, test and operate affordable, small, satellites within a time span of two to three years. Both Delft University of Technology (DUT) and Aalborg University (AAU) have used the CubeSat standard to develop a student satellite. In Delft, the Delfi‐C3 and in Aalborg AAUSAT‐II satellites were developed. This paper evaluates the different techniques that are used in the Project Management and Systems Engineering of CubeSats. The satellite projects of DUT and AAU, which are highly different in setup, will be used as reference points for this evaluation. AAU has a strong pragmatic approach, while DUT uses a structured industrial standard approach.
4.2.1 Business meets Systems Engineering: Facing and Handling Collaboration Challenges in Requirements Analysis
Authors: Laudan Timo , Mauritz Axel , Tollenaere Michel , Gardoni Mickaël
Published: November 2014

Traditional requirements analysis models focused on system‐ and user interactions. Whereas, much effort – in particular industrial – is devoted to the logical breakdown, management, dissemination and proof on the level of implementation of requirements without being strongly connected to the organization and its business intents. Recent works focus on “front‐end negotiations”, i.e. early requirements analysis activities concerned with reconciling business problems, opportunities and high‐level product/system requirements. Literature shows that communication and coordination is challenging in conjunction with the visualization and representation of knowledge in a cross‐community/domain constellation of Business and Product Development (PD) teams concerned with early requirements analysis. In this context, we present our research results (within an empirical context) with emphasis on establishing interactivity structures and creating group‐awareness at the interface of Business and Systems Engineering (BSE). Our work articulates a knowledge‐driven concept that anchors a value‐oriented organization of intentional structures (i.e. business needs and expectations) and traces to engineering definitions (in our case with a focus on product/system requirements). In addition, this concept serves the organization, representation and deployment of BSE knowledge illustrating how to perform valuation and verification of intentional structures implemented in forms of specified product/system requirements.
5.1.1 Systems Engineer your Retirement by Simply Implementing a Verification Plan
Authors: Pietras Sherry L.
Published: November 2014

Of course what comes to mind is ‘how can you perform verification without requirements?’ Obviously one must develop their retirement requirements but as you do keep verification in mind for several reasons: First, requirements must be written to be verifiable. Secondly, requirements that will not be verified, i.e., included in a planned verification event or activity, are useless rubbish. Thirdly, through identification of verification events or activities it is often realized that requirements are either missing, incorrect, or should be deleted. Finally, when new system designs or services to be provided are the same or similar to what has been done before the requirements most likely already exist and have been verified; therefore they may be borrowed and used with minimal alterations.

Certified scuba divers are taught this rule: Plan your dive and dive your plan. This is the key to a successful gratifying dive experience. It is no coincidence that a successful gratifying retirement experience must also be planned. As System Engineers (SEs) we know a lot about planning and every program we work has several types of plans: Concept of Operations, Program Execution, SE Management Plan, Requirement Development, Requirement Management ‐ just to name a few. I propose if you only use one SE plan for your retirement the best plan to select is a verification plan. I say this because the quality of your life is based on what you do. Verification demands awareness as to what you are doing or not doing. It provides a necessary check as to whether or not precious time is being wasted on projects that are off track from your intended retirement pursuits.

As you increase your skill in writing necessary verifiable requirements, verification events, approaches, success criteria, closure statements, and verification reports, for your own life the better qualified you will become in your SE career. Remember, it is never too soon to begin planning for your retirement. Also, based on the evidence from human behavior research, too many workers fail to plan appropriately for their retirement. Therefore, the development of a prime SE retirement verification plan template may serve as a beneficial INCOSE technical working group project for the benefit our INCOSE membership and beyond.
5.1.2 A Study on effective Design Review of Urban MAGLEV Program case
Authors: Song Seonho , Park Chulho , Chung Kyung‐Ryul , Choi Chunho
Published: November 2014

To reduce the risk of failure in a project of development of complex system, clear definition and verification of system requirements (SR) are very important. It is known that around 50% of project failures are originated to the failure of SR. Therefore, SR should be verified by reviewing design in each development stages. To perform the design reviews (DRs) effectively, the verification concept for the SR should be established in the view of system integration and adequate tools or templates for DR should be prepared. In this paper, a template for effective DR on large complex system is suggested, with references to the Urban MAGLEV Development Program in Korea.
5.2.1 Task‐oriented System Engineering
Authors: Zonnenshain Avigdor , Harel Avi
Published: November 2014

Traditional system engineering (SE) is technology driven. In the design of interactive systems we typically assume that the human operator traces the changes in the system states and operates the system correctly. However, the human operator obeys different rules. The difference between the designers' and the operator's rules often results in loss of productivity, decreased performance and accidents, and eventually, loss of market share. In special cases, it makes sense to demand that the user follows the designers' logic. However, in most projects, it is the designer who needs to adapt to the user's logic. The article analyzes the limitations of common design practices in resolving mismatches between the system and the user states. Complex system engineering (CSE) is a framework suitable for handling the human operator as a critical system component. This article presents a methodology for handling the human attributes in this framework. The methodology extends the capability of common practices of user‐centered design and usability testing, which miss critical interdisciplinary issues. To resolve state mismatches, the system engineers must be aware of the user's logic. Such knowledge should be reflected in the system architecture, to ensure that the user interface provides protection against unexpected user events and to facilitate the system operation in new situations, such as in emergency. The methods and guidelines presented here are applicable to the whole development cycle.
5.2.3 Taiwanese Engineering Process Survey Results — A Preliminary Study
Authors: Peng Willy Y.S. , Ferris Timothy L.J. , Wang T.J.
Published: November 2014

The authors have administered a survey to explore certain issues in the management of engineering processes in Taiwan. The results of the survey are reported in this paper along with indications of future research which are suggested by the results obtained. The survey was developed in order to explore the manner in which engineering work is organized and led in Taiwan. The immediate goal of the work is to explore the interaction of Chinese culture and engineering process. The purpose of the work is to develop an understanding of the interaction of Chinese culture and engineering processes in order to provide a foundation to develop a culturally sensitive approach to the management of engineering work that is appropriate in the Chinese context. The survey explores a number of issues around the effect of corporate and project governance and the kinds of management processes used. The survey was developed with closed form questions to enable data analysis independent of language and to provide data which can be analyzed quickly in the development of sufficient empirical understanding to develop future research approaches. The survey deliberately used common language to describe the issues about which questions were asked to avoid any difficulty with alienating respondents who do not overtly practice or use the technical vocabulary of systems engineering. The results we obtained show that systems level issues are important in most of the companies surveyed.
5.3.1 Development of healthcare service management system using systems engineering and RFID technology
Authors: Kuan Jyh‐Horng
Published: November 2014

The purpose of this research is to apply systems engineering and RFID technology to develop a service management information system, which includes the functions of operation revenue, operation expenditure, service timing and account balance enquiry, and management related statistics and analysis. This research is separated in two stages. In the first stage, Delphi software technology and SQL database are used to develop the management system, whereas in the second stage RFID technology is added in to the customer consumption record management and enquiry system to improve management efficiency. The development of the system is based on systems engineering and Delphi software. The process of systems engineering includes demand estimation, conceptual design, preliminary design, detailed design and development, logistic support and maintenance. Integrating systems engineering with Delphi software technology can facilitate to develop new product at low cost and upon customer's need. Blanchard and Fabrycky are applied in the development of our product, including demand analysis, functional analysis, function configuration and system design. Four main parts in the service management information system, including operation revenue, has been finalized. And we also assisted the enterprise to launch the system, which now has used for two years. The system performs stably and the functions we develop cater the customer's need completely.
5.3.2 A Generic Method for Defining Viewpoints in SysML
Authors: Yamada Takahiro
Published: November 2014

It is important for system engineers to present the information on the systems that they are developing in a precise way so that the information can be understood by as many people as possible. The OMG Systems Modeling Language (SysML) (OMG 2008) was developed to meet that kind of needs of system engineers. It is a common practice to present descriptions of large systems using multiple views, each of which addresses one or more of the concerns of the system stakeholders. SysML has the concepts of view and viewpoint and it requires that a view conform to a viewpoint, which specifies conventions and rules for constructing and using the view, but it does not specify any method for specifying viewpoints.

One of the examples of specifying viewpoints in a particular problem domain is an ISO/IEC standard called the Reference Model of Open Distributed Processing (RM‐ODP). This standard specifies five viewpoints to describe distributed processing systems, but it does not provide generic rules on how to construct viewpoints.

This paper proposes a generic method for defining viewpoints in SysML by generalizing the concepts used in defining viewpoints in RM‐ODP. By using this method, viewpoints to be used in different problem domains can be defined in a systematic way, and reuse and/or sharing of viewpoints across different problem domains can also be facilitated.
6.2.1 Foundations of Value Based Gap Analysis: Commercial and Military Developments
Authors: Langford Gary
Published: November 2014

Gap Analysis is widely regarded as a useful tool to facilitate commercial and defense system acquisitions. This paper presents a rethinking of the theoretical foundations and systematics of Gap Analysis with practical extensions to illustrate its utility and limitations. The growing sophistication and complexity of new systems or system of systems have resulted in a dramatic increase in time and money to reach operational capability. Gap Analysis, properly defined and enacted, clarifies goals, appropriate investments and the end‐use. This paper introduces the concept of thinking in terms of value and worth, termed Value Systems Thinking; and the concept of analyses and judgments for acquisition and product development – termed Value Systems Engineering.
6.2.3 Coping with System Evolution ‐ Experiences in Reverse Architecting as a Means to Ease the Evolution of Complex Systems*
Authors: Borches P. Daniel , Bonnema G. Maarten
Published: November 2014

Creating systems from scratch is time consuming and costly, therefore companies often choose to evolve existing systems. The understanding that a company has about the impact that a change has in the system architecture determines their ability to cope with system evolution.

System architects and designers need to have an architecture representation that enables them to understand and to foresee consequences of evolving the system. This representation however is often not documented. Reverse architecting enables to recover the architecture representation. In this paper, experiences in reverse architecting in a industrial case at Philips Healthcare MRI Group is presented. We show that the proposed approach provides an effective framework to reason about evolvability and impact that design changes has on the system.
6.3.2 The Systems Engineer: a Communicating Saté Skewer
Authors: Schreinemakers Paul J.P. , Elich Erik H.J.
Published: November 2014

Communication is recognised as an important ingredient to execute projects. It is not just a single capacity, but can be drawn along multiple dimensions. This paper describes the Systems Engineer as a ‘Communicating Saté Skewer’, addressing his ability to concatenate different aspects (people, means and content) to secure that the system becomes successful. To be able to act as a good Systems Engineer, this paper describes six dimensions that are important for optimal communication and to fulfil the role of ‘concatenater’ of content. These dimensions range from the organisational‐ and system hierarchy to the intercultural aspects of communication within and between teams or organisations. Moreover these dimensions vary from East to West. Trying to find a person who meets the needs along all dimensions may result in looking for the impossible. Some thoughts are given that may help constructing a balanced team that meets the project needs.
7.1.3 Fault Propagation and Sensitivity Analysis to Support Counterterrorism Activities
Authors: Nagel Robert L. , (Monty) Greer James L. , Stone Robert B. , McAdams Daniel A.
Published: November 2014

This paper discusses research on fault propagation analysis and two associated fault sensitivity measurement approaches for the investigation of faults in human‐centric processes. The techniques presented grew out of a joint project between the U.S. Air Force Academy and Missouri University of Science and Technology to investigate terrorist activities involving improvised explosive devices. Two potential counterterrorism activities related to improvised explosive devices are developed through the paper to demonstrate the application and usefulness of the methodologies. Provided with the examples is a discussion of fault propagation, the sensitivity analysis performed, an interpretation of the results, and an overview of anticipated future applications in system design.
7.2.3 Thermal/Acoustic trade‐off design for Consumer Electronics in a distributed design environment
Authors: Seki Kenichi , Nishimura Hidekazu , Ishii Kosuke , Balmelli Laurent
Published: November 2014

Today's market demand for smaller, more powerful consumer electronics poses a major challenge to the rapid design of products. In addition, the ability to perform strategic coordination amongst different stakeholders within the enterprise increasingly becomes an important criterion to enable global engineering. We begin the paper with an introduction to a typical design process involving distributed design teams In particular the process allows the thermal‐acoustic design of cavities, i.e. air space inside the enclosure, in terms of flow rate and acoustic radiation resistance. Then we proceed with the investigation of an approach leveraging recent modelling technology to support such a process efficiently. The process makes use of the system modelling language (SysML.) as product description support and the Design Structure Matrix as an analytical design tool. We use the model and the DSM as a means to drive numerical simulation and perform trade‐off studies. Simulation results show that performing trade‐off study in the early system design phase leads to a potentially optimal module layout for the problem studied.