bluuebunny/crossref_metadata_2025 huggingface dataset:
4.5.2 Taming the Sofware Monster with Threads
Authors: Alford Mack
Published: November 2014

One of the biggest challenges facing system engineers is the way in which they interface with the development of the software which implements the desired behavior of the system. Experience has shown that the approach of passing paper specifications between systems and software developers does not yield satisfactorily results. This paper proposes the use of stimulus‐condition‐response threads for controlling software development – for specification, review, and testing.
5.5.2 Foundations Of A Human Systems Theory and Systems Engineering
Authors: Mayhew Michael E. , Alessi R. Samuel
Published: November 2014

Human beings and the dynamics of human interaction are central features of systems engineering. Since engineers are often technically oriented, understanding and dealing with this human dimension can become problematic. Built upon the technical foundations of General Systems Theory and cybernetics, a human systems theory may provide systems engineers a more rigorous way to understand themselves, other team members, and stakeholders. This paper gives the historical development and general description of human systems theory with examples to help communicate meaning. This theory can give systems engineers a better understanding of the human dimension of systems engineering, thereby enabling rigorous management of the system.
6.4.1 Industrialization Of Formal Methods Through Process Definition
Authors: Toth Kalman C. , Joyce Jeffrey J.
Published: November 2014

This paper advocates the use of process definition methods to drive the “industrialization” of new techniques – that is, the transformation of a technique, or combination of techniques, developed by a research organization into a production process that can be used by an industrial organization. We relate our own experience at Hughes Canada Systems Division (HCSD) based on an effort to industrialize an application of “Formal Methods” to support the development of large automated air traffic control systems. In addition to providing an account of some components of our approach to process definition, this paper provides a glimpse into the topic of “Formal Methods” which is already becoming established in Europe as an important systems engineering discipline and can be expected to soon become as important within North America.
6.4.4 INITIAL SYSTEM VERIFICATION AND VALIDATION CONSIDERATIONS
Authors: Morrison Arthur F. , Mar Brian W.
Published: November 2014

Early consideration of a system development project's system verification and validation aspects can make an important contribution to its success. Three specific areas of consideration–management method, technical approach, and information system utilization–are examined to identify considerations that need to be taken into account from the beginning of a project. A proposal is made to use an integrated approach involving concurrent engineering with customer and system team member representation, early system modeling, simulation, and analysis targeted toward addressing system verification and validation, and integrated system development information that provides a system verification and validation thread throughout all phases.
6.5.1 PARTNERSHIP FOR ORGANIZATIONAL EFFECTIVENESS
Authors: Rhodes Donna H.
Published: November 2014

Organizational effectiveness can be improved in a multitude of ways, some more obvious than others. “Small changes can produce big results ‐ but the areas of highest leverage are often the least obvious”, says Peter Senge, author of The Fifth Discipline. This paper describes a very successful program which inserted systems engineering paraprofessionals into an existing organization. While the addition of an individual to a team is a small change in the scheme of things, the program has turned out to be a high leverage change for our business. Benefits to the engineering organization's effectiveness go well beyond the initial expectations for the program.
6.5.3 THE DESIGN LIFE AFFECTS SYSTEM DESIGN
Authors: Bahill A. Terry , Dean Frank F. , Senglaub Mike E.
Published: November 2014

When a system is being designed, one of the system requirements will specify the intended duration of life for the system, which is called the design life, the system life, the expected operational life or the service life. This specification is an important driver of the total life cycle cost. This paper suggests how specifying this design life affects the design and the cost of the system.

If the customer requires a longer design life, then the system will cost more. Figure 1 shows the manufacturer's suggested list price (dollars) as a function of design life (number of pages) for 166 laser printers (Computer Select, 1994). The cost increases as the design life increases. The correlation for these data is high, 0.84.
7.4.2 RELATIONSHIPS BETWEEN COMMON GRAPHICAL REPRESENTATIONS USED IN SYSTEM ENGINEERING
Authors: Long James E.
Published: November 2014

Most system engineers today use graphical representations of a system to communicate its functional and data requirements. The most commonly used representations are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 Chart, IDEF0 Diagram, and Behavior Diagram (BD). This paper discusses the characteristics of each and shows how they are related.

When analyzed in the context of specifying functional control and data modeling, it appears that the FFBD and DFD representations are limiting, special cases of the Behavior Diagram. The N2 Chart has the same capability as the DFD, with a more formal format. The IDEF0 is essentially an N2 Chart with some control definition (no constructs) capability. The IDEF0 has the capability to indicate the allocation of functions to system components.

Thus, the Behavior Diagram features comprise a “parent/unified” set of graphical system representations. To achieve the same level of specification completeness, you would have to use an integrated set of the FFBD and one of the data models or augment the FFBD with a graphical representation of the data model, as was done at TRW (then called Function Sequence Diagrams, FSDs).
7.4.3 Human‐System Interaction Development: An Integral Part of the Systems Engineering Process
Authors: Buie Elizabeth , Vallone Antonio
Published: November 2014

As currently defined and practiced, the systems engineering process (SEP) overlooks the design of human‐system interaction (HSI) as a systems engineering activity. Integrating HSI engineering into the SEP would promote the cost‐effective development of highly usable, reliable systems and products. This paper shows that the integration effort must identify the roles that humans play and the perspectives from which system development can be perceived: Support system, environmental system, and total system (which includes the system's users). This paper presents a scheme for an SEP that includes HSI definition and design, and it shows an example of applying the scheme to a software system, where the HSI is human‐computer interaction. Integrating HSI engineering and SEP forms the basis of effective multidisciplinary collaboration and the development of human‐centered systems.
7.5.2 RAPID PROCESS DESIGN A SYSTEM ENGINEERING DESIGN METHOD
Authors: Aguilar Ronald J.
Published: November 2014

A rapid method has been developed for the design of computing system capabilities and/or human work flow activities. This design method is call Rapid Process Design (RPD) and is based on the definition of processes and not requirements. This design originally was developed for use as a preliminary design tool supporting the Definition Phase for system development programs using the Rapid Development Methodology (RDM) [1]. The RPD method allows for quick design of automated computing processes for immediate computing system capability deliveries. A key element of RPD is the definition of a process and its associated conditions and constraints. The process definition can be used to support evaluation and testing of a delivered computing system capability or human work flow.
INFORMATION SYSTEM TRENDS INFLUENCING SYSTEMS ENGINEERING
Authors: Howe Donald M.
Published: November 2014

Government and industry are focusing on “information” system technology to provide dramatic changes that will be the critical factors in a comprehensive range of activities from achieving‐competitive‐advantage to winning‐wars. System, software, and security engineering for information systems involve principles and practices that continue to evolve. This paper identifies, compares, and questions those principles and practices. It characterizes the information system development/integration paradigms as being in a state of flux. In addition, architectural concepts are discussed that provide a framework for information system services that support a variety of missions and functions.

Three salient points of the paper are: (1) system engineers should become familiar with “technical” information system architecture alternatives, (2) advances in technology are leading to the merging of system, software, and hardware engineering disciplines at the architectural level, and (3) requirements‐definition and design‐resolution procedures are being revolutionized through incremental/continuous development paradigms.
An Interface Control Approach to Land‐Use Management
Authors: Carson Ronald S.
Published: November 2014

An interface control approach is formulated for land‐use management that relies on establishing and maintaining interface conditions rather than defining the content of the activity on the land. This is analogous to the system engineering concept of constraining the interface boundary conditions rather than specifying the detailed design. An application to regulating wetlands is examined. This approach has the possibility of producing relatively more stable land‐use regulations by eliciting the intent behind a regulation.
Development Of Laboratory Capabilities For The Integration Of Global Positioning Satellite (GPS) System Onto The F‐14 Aircraft
Authors: Chan Hin K. , Hugh Robert , Krinsley Brian
Published: November 2014

This paper discusses the systems approach used in the design and development of laboratory test capabilities used to integrate GPS capabilities onto the F‐14 aircraft. Modifications made to the existing simulation/stimulation capabilities, radar target generators and airframe wiring will be discussed as well as the installation and alignment of a three axis tilt table, the design of a stand‐alone workstation, and the use of COTS test tools.
Using Systems Engineering for Automotive Advanced Development
Authors: Wittig William H.
Published: November 2014

This paper describes the Systems Engineering process used to develop new automotive products and shows how the process is driven by the automotive industry business issues. A history of Systems Engineering at General Motors is outlined, the role of the Systems Engineer in one of the advanced development group described, and future plans for improving the Systems Engineering process are discussed.
System Modeling and Possible Applications for the Social Sciences
Authors: Koehler Andrew , Pelmulder Susan , Stone Adam
Published: November 2014

System Engineering tools have been used extensively to model the technical characteristics of large systems or processes. However, little use of these tools has been made in the social sciences, and the modeling of the social factors that contribute to design choices—in the case of systems that involve political processes—remains relatively crude. This paper discusses the efforts of the Center for Nuclear and Toxic Waste Management, University of California, Berkeley to employ system design tools as part of social science research into US surplus plutonium disposition options.
Overcoming Problems in the Development of an Automated Car Park System by Introducing Systems Engineering Methods
Authors: Harzenetter Florian , Beutler Jörg , Negele Herbert , Fricke Ernst
Published: November 2014

Since 1992 Maurer Söhne is developing an automated car park system and now has built a prototype for the City of Augsburg, 60 km west from Munich. During this project problems arose, especially with respect to changes. Therefore, Maurer Söhne started to implement systems engineering methods to overcome those problems in the planned serial production of the automated car park system. This paper is not a glorification of a development process, instead it describes the problems and their causes, what we called “management by Beckenbauer”, during the development phase. Furthermore, the paper shows how Maurer Söhne started to solve one of the main problems, i.e. to manage changes, by implementing special systems engineering methods.
The Science of Railway Systems Engineering?
Authors: Williams John S , Allan Jeff , Jin Jenny Q
Published: November 2014

It is described how a scientific approach to railway systems engineering is needed to lead to a modelling development plan coupled closely to the system development and test programme. This coupling is best achieved using databased information which is sourced both from the design process and from the tests and trials conducted during implementation. The final models and databases need to be not just a record of the project development, but to form the basis for the planning of future operations and railway updates.
MODELING AND SIMULATION BASED SYSTEM INTEGRATION APPROACH
Authors: Huang Paul , Kar Pradip , Kennedy Alan , Kato Hiroko
Published: November 2014

This paper describes a modeling and simulation (M&S) based approach to provide life cycle support for the Bradley Fighting Vehicle (BFV) M2A3. The BFV A3 is being developed under an Engineering and Manufacturing Development (EMD) program at United Defense LP (UDLP). The BFV A3 Upgrade program incorporates lessons learned in the Desert Storm Operation. Upgrades are primarily in the area of fire control, electronics and software.
ENGINEERING OF INTELLIGENT, COMPLEX ADAPTIVE SYSTEMS USING AN AGENT‐BASED ARCHITECTURE
Authors: Clymer John R.
Published: November 2014

A methodology for bringing intelligent, Complex Adaptive Systems (CAS) into being is discussed, and the requirements for such intelligent systems are summarized. An agent‐based system architecture is proposed that will satisfy the requirements for such an intelligent system. A facilitator agent that manages communication, coordination, and collaboration is proposed as a part of this architecture. A goal‐directed behavior process is included as part of the facilitator agent to satisfy many of the intelligent system requirements.
Spreadsheet Aided System Engineering and Optimization
Authors: Mincer Tom R. , Hooper David M.
Published: November 2014

The Excel™ spreadsheet has become a valuable, powerful engineering tool that now provides strategic capabilities to:

create graphical user interfaces (GUIs)

command other languages like FORTRAN and C through Dynamic Link Libraries (DLLs)

control an integrated object oriented programming language called Visual Basic Applications (VBA)

command databases

The GUI capability of Excel allows the system engineer to create windows like applications (icon driven) with minimum effort. This GUI capability enhances system information presentation and provides the means to manage system information flow efficiently. Excel allows a design team to redefine the “back of the envelope calculation.” This is accomplished by interfacing with other languages such as FORTRAN and C, its own programming language VBA, and an optimization tool called Solver. With the modular, platform nature of Excel, engineers can now apply the system engineering process and develop unique applications devoted to their project team needs.
HOW DO YOU MODEL A SYSTEM ?
Authors: Plastow Ian
Published: November 2014

In answering the question How do you model a system? this paper considers the requirements for modelling of a system in the context of the systems development lifecycle. It examines the issues that have to be resolved for a systems model particularly those related to integration (both horizontal and vertical). A means of satisfying the wide ranging requirements of a systems model is proposed. Neither the proposed requirements nor the means of satisfying them are intended as definitive but are anticipated and intended to stimulate further discussion.
A Framework for Research Into Model‐Driven System Design
Authors: Lykins Howard
Published: November 2014

There is a pressing need for research into the use of machine interrogable models for requirements analysis, design, integration, testing, and management at all levels of systems and software engineering. This paper describes a candidate framework for research into model‐driven systems engineering. The framework is a recently published process for integrated systems and software‐level engineering of software‐intensive systems, described in terms of management and development activities and associated information. To show how the process can serve as a research framework, this paper selects a subset of the activities and information flows, discusses how modeling relates to them, and raises some example issues.
Systems Engineering Specification Techniques
Authors: Ghahramani Bahador
Published: November 2014

The primary purpose of the Specifications Techniques Supported by CASE Tools (STCT) is to improve the effectiveness of Systems Engineer's (SE) efforts in design and development processes. These techniques help SE's by guiding them through the system's design and development (D&D), architecture, documentation, requirements, and verifications phases. This practice is a practical and efficient alternative to the traditional procedures of developing specifications, in which the specifications developed do not necessarily follow modern engineering approaches. STCT applies to both systems and software specifications as well as firmware and high‐level hardware requirements.
An Effective Approach To System Integration: A Comprehensive Checklist
Authors: Hyer Scott A.
Published: November 2014

System integration is one of many ambiguous terms used in high technology system development communities which needs to be better understood and recognized. Its definition often depends on one's point of view and purpose. However, it must be recognized that system integration is an idea which must drive the development process from start to finish. The influence of system integration must carry significant weight at the beginning during requirements development and system design as well as through the detailed design, build, and test activities as more traditionally recognized. This paper attempts to treat system integration as a more universal activity by first defining it from different aspects and then by presenting an approach which can be effective in a wide variety of situations. The approach is offered in the form of a checklist, which tends to be more easily visualized, understood, and incorporated into a plan of action. This paper also attempts to remain independent of particular technology applications and business areas to maximize its applicability.
REDESIGN COST AVOIDANCE USING SYSTEM ENGINEERING
Authors: Helm Jim , Cantrell R. T.
Published: November 2014

A system engineering approach was used for development of the Motorola space‐based cellular network called IRIDIUM1. Significant cost reductions were realized using requirements analysis and management along with system engineering team processes. Statistics show a 40 to 1 reduction in development engineering time due to team requirements inspections. Due to their general nature, these system engineering processes are easily transportable to any project with a development phase.
The Vortex Principle: Systems Engineering with a Twist
Authors: Jorgensen Raymond W.
Published: November 2014

Many models have been used to describe the processes that engineers should be following to provide effective engineering solutions for today's problems. Each model has drawn attention to the fact that engineering requires a disciplined approach to problem resolution. However, these models are failing to capture the concepts of information abstraction as it applies toward effective system decomposition. Appropriate application of abstract reasoning, however, is necessary for effective communication of a system definition. This paper presents an engineering process model that depicts the iterative flow of requirements and design along a vortex that follows an appropriate breakdown of abstracted system components.
Considerations in Developing Originating Requirements
Authors: Buede Dennis M. , Charbonneau Steven
Published: November 2014

This paper addresses the issue of what types of analysis might be best for analyzing the interaction the system under question with relation to its external systems during the requirements development process. We examine process or functional modeling as well as behavioral or state modeling. The effort employs academic case studies and a survey of practicing systems engineers.
Report on Development of ISO Standard 15288 System Life Cycle Processes
Authors: Lake Jerome G.
Published: November 2014

Since the late 1980s there has been a focused effort to produce standards, guides, and models that will enhance the development of systems. With the deemphasis of military standards within the US Department of Defense, these efforts by US and international standard bodies have been further stimulated.

In 1994 the US published interim standard EIA/IS 632, Systems Engineering, and IEEE 1220 Trial‐Use Standard, Application and Management of the Systems Engineering Process. The International Organization for Standardization (ISO) has also been creating a series of standards and guides. ISO/IEC 12207, Software Life Cycle Processes, is one such standard published in 1995. Additional ISO guides and national implementations standards pertaining to 12207 are under preparation. Also in 1995, the same ISO working group that developed 12207 has undertaken the development of a system standard to be known as 15288, System Life Cycle Processes. And in 1996, the United Kingdom Defence Evaluation and Research Agency (DERA) prepared a draft guide with a system model that provides an excellent framework for engineering a system.

This paper puts these and other efforts into perspective. The focus is on the 15288 development.
A Business System Engineering Model Architecture
Authors: Tronstad Yngvar D. , Peterson Jan
Published: November 2014

This paper describes a Business System Engineering (BSE) approach to Information System Reengineering which can be applied to the Year 2000 problem as well as the more strategic migration from legacy computer systems to client server environments. The BSE is founded on proven System Engineering (SE) principles where changes in Information Systems (ISs) are driven by business requirements.
Development and Implementation of a Systems Engineering Process
Authors: White Paul , Tufts Robert , Treadwell Terry , Schier Jim , Reynolds Patti , Nolte Jerry , Newbern Dave
Published: November 2014

We have developed a standard systems engineering process for TASC, and have begun implementing that process on systems engineering projects. We have found the standard systems engineering process to be a very useful tool in executing our work.
Applying Programmatic Risk Assessment to Nuclear Materials Stabilization R&D Planning
Authors: Kenley C. Robert , Hoozer S. Alenka Brown‐Van
Published: November 2014

A systems engineering approach to programmatic risk assessment, derived from the aerospace industry, was applied to various stabilization technologies to assess their relative maturity and availability for use in stabilizing nuclear materials. The assessment provided valuable information for trading off available technologies and identified the at‐risk technologies that will require close tracking by the Department of Energy (DOE) to mitigate programmatic risks.
Risk Management Implementation in a Product Team Environment
Authors: Elam Rudy , Kohrs Bob
Published: November 2014

The implementation of a project‐wide risk management effort, in a project environment which uses product teams as the principal organization structure, requires a special management approach for effective results. Discussed herein are the practical experiences encountered in applying risk management to a two billion dollar wind tunnel design and construction project with a multiple set of project teams differentiated by technology specialties, corporate cultures and widely dispersed geographical locations. Lessons learned are summarized for use in future applications of risk management in a complex multidimensional project matrix environment.
Enhancing Teamwork with Cross‐Product Teams (CPT's)
Authors: Martin James N.
Published: November 2014

Integrated Product Teams (IPTs) are all the rage now. However, teamwork can be more effectively implemented on development projects if Cross‐Product Teams (CPTs) are also used. The Systems Engineering Process cannot be performed well in a vacuum. It requires the right people, the right organization for those people, and the right functional design disciplines involved (e.g., software, mechanical, circuit card, logistics, ASIC/FPGA, microwave, interconnect assemblies, and test equipment). It also requires the proper timing with regard to when the different “levels” of the system architecture are defined and when the related functional design disciplines are brought to bear. This paper describes the programmatic framework within which the Systems Engineering Process should be performed. This framework involves the system breakdown structure (or product hierarchy), the organizational breakdown structure (or project teaming chart), and the project schedule.
A Sixth Discipline For Future Awareness
Authors: Hall Elaine , Gorsuch Thomas
Published: November 2014

What are the disciplines required to successfully manage and develop software systems in today's fast‐paced world? This paper describes a sixth discipline for future awareness—reasoning about possibilities. The current model of software development is based on an adaptation of the Deming model of process optimization. This adaptation is lacking a known discipline that is essential to software‐systems engineering. We develop the sixth discipline that extends the Deming model by adding the ability to discover risk and opportunity. To demonstrate the utility of the six‐discipline model, we describe the distribution of risk‐management practices to the six disciplines. Future awareness improves the current model of software‐system development by providing the capability to manage a future full of change and uncertainty.
Development Of A “Systems Engineering” Organization
Authors: Jackson William N.
Published: November 2014

Organizations develop and cultures change over time. For an organization to be successful over the course of many years, strong foundations must be established. A properly defined and implemented Strategic Plan can provide a strong foundation. A prime example of a solid foundation is the Constitution of the United States. It provides guidance to a large diverse populace, permits modifications, is continuously being monitored and has been fairly successful for over 200 years. The US Constitution could be considered a “Strategic Plan”, developed by the first US Systems Engineers, our founding fathers!
SYSTEM INTEGRATION AND TEST IN INTEGRATED PRODUCT AND PROCESS DEVELOPMENT (IPPD): ENGINEERING OUT THE SURPRISES{PRIVATE}
Authors: Roe Charles L.
Published: November 2014

System integration is the process of assembling and evaluating a product after component design and development has been completed. This consists of interfacing and integrating the subassemblies and verifying that they perform according to the top‐level specifications. Since system integration is where the system comes together, its significance and importance should be readily apparent to the systems engineer, who must work the interfaces diligently during component development and establish lines of communication among the development teams to ensure that the finished product works as planned when tested against the system requirements.
Joint Development Teams in Action: Government and Industry Perspectives
Authors: Kollmorgen Leland S. , Terry William S.
Published: November 2014

Many organizations are embracing development of new systems or products through the use of integrated teams. Although clearly the direction of the future, there are some challenges along the way particularly when the new organizational ideas are inserted into development programs which are already in progress. This paper describes an integrated team environment which is currently being used to develop a complex new weapon system for the U.S. Navy. The implementation of this team environment can be used as a useful case study for others embarking on similar undertakings as both positive and negative aspects of the program team environment are discussed as well as a summary of lessons learned. This paper examines the team approach from both the position of the government and that of the prime contractor.
Important Skills and Knowledge to Include in Corporate Systems Engineering Training Programs
Authors: Watts Jerry G. , Mar Brian W.
Published: November 2014

This study identifies the skills and knowledge that companies consider important for systems engineers to have and determines the amount of training offered by the companies to develop the same skills and knowledge. A survey of companies with training programs for systems engineers was administered and identified critical skills and knowledge to be basic problem solving, development and management of requirements, teamwork and communication, and system optimization. The amount of training offered to develop these skills and knowledge varies considerably from company to company and does not correlate with the emphasis the company places on the same skills and knowledge.
Systems Engineering Process Help Window
Authors: Grady Jeffrey O.
Published: November 2014

Training accomplished closest to the need best serves that need. Most systems engineering training opportunities, where they do occur, are too far removed in time from the need for that training. Commonly, good external training opportunities cost more than we can afford to spend and are not scheduled for our convenience but rather for broader market demands. The combination of these factors act to make it very difficult to progress rapidly in improving one's skills and knowledge in this field. This paper offers a system engineering organization a way to parlay a prior investment in networking and systems engineering process definition into an affordable solution for this problem. The solution offered also permits the use of a simple generic enterprise systems engineering process manual by providing the detailed how‐ to information in the form of just‐in‐time training materials linked to the process manual.
Covert SE: Teaching SE in a Disciplinary Context
Authors: Maier Mark W.
Published: November 2014

Most INCOSE members agree, systems engineering is not just for systems engineers. But if systems engineering belongs in the disciplinary engineers toolkit, how should it be taught? This paper describes the authors observations in teaching systems engineering within a disciplinary context, and in particular in trying to make it a normal part of that disciplinary practice. Thus “covert SE” refers to the use and teaching of systems engineering methods without calling them by that name. In the authors experience systems methods apply to disciplinary engineering, but their teaching and application is not simple and is not without problems. The persistent nature of some of the problems suggests that the remedy is only partially in better materials, but also partially in rethinking the value of certain methods.
A Case Study for Teaching System Requirements Analysis
Authors: Gonzales Regina M. , Johnson Eric
Published: November 2014

This paper presents an analysis of a semester course in System Requirements Analysis taught at the Klipsh School of Electrical and Computer Engineering at New Mexico State University. A real‐world model for product development was used with a life‐sized project. Methods and theory for product development were taught on an as needed basis. The lessons learned and insights gathered are presented.
Interfacing Requirements Management Tools In The Requirements Management Process – A First Look
Authors: Jones David A. , Kar Pradip C. , van Gaasbeek James R. , Hollenbach Frank , Bell Marty , Ellinger Robert S.
Published: November 2014

Interfacing requirements management software tools with other tools can facilitate the requirements management process by allowing people to exchange requirements more easily, to use the optimum tools in their work, and to adapt to tool changes. In this exploratory paper we attempt to provide some useful information to requirement tool users and developers who need to specify or devise requirement tool interfaces.

Examination of a simple hierarchical requirement data flow model suggests major interfaces of

Document import / parsing

Derivation analyses

Publication (electronic and / or paper)

Flowdown to lower level

Database import / export

Companion programs (e.g. graphics editors)

The model presented suggests the type of data that should flow across these interfaces.

Twelve commercial requirements management tools are identified in this paper, and a couple of interface file formats are illustrated.

Some generalizations are made, such as that each data item should be entered once and reside in a single master location where possible.

Several examples of actual implementations illustrate accomplishments and practical difficulties encountered. Also eight commercial / consortium tool integration efforts are summarized with lists of the major tools involved, and a couple of standardization efforts are described, including a major European effort, SEDRES.

Some work by INCOSE in identifying requirements data is recommended in this paper.

Not all of the topics in this paper are covered in detail, but we think that a significant amount of useful information is provided.
The Development of a Systems Reengineering Tool Taxonomy
Authors: Fisher Gerard H. , Biggs Bruce
Published: November 2014

This paper describes the motivation, objectives, and plans related to the development of a Systems Reengineering Tool Taxonomy. This is a product of the Systems Reengineering Working Group and will be placed on the web in coordination with the Tools Working Group.
1.1.2 The Missing Link in Systems Engineering
Authors: Gardner John R.
Published: November 2014

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

Simulation tools, as well as the new management schema Integrated Product and Process Development (IPPD) have been applied to an increasing range of ongoing acquisition programs and have significantly reduced development time and life cycle costs and improved system quality. Some improvements have reduced the overall development time by half and some individual activities by 3000 %.

“The issue is no longer whether extensive use of Simulation and IPPD have merit for acquisition, but rather how to develop and apply such new processes in a deliberate and coordinated manner to maximum advantage and achieve even more dramatic cost and schedule reductions.” (Sanders, 1997) The application of these tools carries Systems Engineering to a new level of capability.
2.1.4 A Case for the Consideration of System Related Cognitive Functions
Authors: MacLeod Iain S.
Published: November 2014

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

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

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

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

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

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

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

An intra‐company world wide web site serving 700 systems engineers at several sites has been in operation for about two years. The site provides job‐related information, downloadable document and utility job aids, current news, and a calendar of events. The information provided includes descriptions of the organization, standards, processes, training, and tools.

The setting, site content, metrics collected, and lessons learned about setting up such a site are described.
5.2.3 Engineering Management Pocket Guides: The “TripTik” Approach to Capability Maturity Models
Authors: Cusick Kerinia
Published: November 2014

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

As a part of the restructuring of the space mission design process, the Jet Propulsion Laboratory is investigating a model‐driven concept for capturing and refining system‐level requirements for space missions. Anticipated advantages include (1) earlier achievement of system design maturity; (2) earlier detection of system‐level problems through virtual test; and (3) enabling of mission/system trades throughout the design phase.

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

The model described in this paper used actual data and a real IPPD organization framework to quickly measure team productivity goals and achievement along with necessary attributes to track and direct requirements.

Effort is underway to gather data on past and current programs within the organization to identify either best practices or develop program independent, standardized processes in requirements management. This modeling and metrics development will help the organization achieve Level 5 Systems Engineering capability maturity.
1.3.4 Web‐based Requirement Management and Regulatory Tracking
Authors: Sampson Mark E.
Published: November 2014

“The Internet is the sum total of man's knowledge updated in real time.”

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

Smalltalk is a rich, general purpose object‐oriented programming language and environment. It is also an effective tool for modeling systems. Smalltalk employs constructs that are applicable to any hard systems design problem, and these constructs aid the system designer in reducing the system complexity. However, the trade off is a one‐time, steep learning curve on the order of three to six months.