bluuebunny/crossref_metadata_2025_split huggingface dataset:
3 Panel: How Do Requirements Relate to Objects?
Authors: Kaindl Hermann , Glinz Martin , Kasser Joseph E. , Kasser Joseph E. 
Published: November 2014

AbstractThis position paper discusses arguments in favor and against regarding requirements as objects. As there are good arguments for both standpoints, a partial synthesis is developed. The synthesis is based on the idea of not treating requirements as objects, but using objects for organizing and understanding requirements.Object‐oriented systems engineering contains a broad chasm. On one side is object‐oriented systems engineering and on the other are the systems and sub‐systems that are objects by definition. The chasm is the domain of requirements. Whiles conventional systems and software requirements engineering have ignored the chasm, Total Quality Management (TQM) can be used to bridge the chasm and reduce cost and schedule overruns. This approach is based on a starting assumption that since requirements drive the work of implementing the system, object‐oriented requirements have both the traditional properties describing the product but also have properties than can assist in ensuring a cost‐effective production process. Several candidate properties that have been identified and their usefulness are discussed. Some concept demonstration tools that have been developed are summarised, and the presentation concludes by pointing out that the object‐oriented properties can be used to provide views of a proposed system at the System Requirements Review that would be difficult to observe in the current paradigm.
5.2.1 Can Systems Engineering be taught at Undergraduate Level?
Authors: Goodlass Sue 
Published: November 2014

AbstractEveryone knows that Systems Engineering is complicated and difficult. It takes a long time to become sufficiently experienced to be a good practitioner and people need to make mistakes in order to learn from them. How successfully then, can such a difficult topic be taught at undergraduate level? In the early 1990's, BAE SYSTEMS engaged Loughborough University to develop and deliver an undergraduate systems engineering programme and has recruited engineers from it since the first cohort graduated in 1997. This paper describes how the programme was designed and developed and compares systems engineers graduating from this programme with other engineers in BAE SYSTEMS.
5.3.3 The Need for Observable States Affects the Make‐Reuse‐Buy Decision
Authors: Botta Rick , Wuersch Bill , Bahill Terry 
Published: November 2014

AbstractToday, systems are supposed to be designed so that they are better, faster and cheaper. The mantra for doing this seems to be the reuse of available components. This paper presents a process to help select and reuse existing components in new system designs. An important part of this process is identifying observable states.
5.5.1 The Analysis and Evaluation of Customer Satisfaction and Service Management
Authors: Trappey Amy J.C. , Hsu Fu‐Chiang , Kuo J. , Trappey Charles V. , Chao Charles L.J. , Lu Tony T. H. 
Published: November 2014

AbstractAdaptation of information technology in business applications enables enterprises to understand customer behaviors and use customer‐related knowledge to increase competitiveness, adjust product market position, and build customer loyalty. The Internet and computer telephony integrated (CTI) applications, in particular, enhance the communication channels among members of extended enterprises (e.g., customers and suppliers). Thus, Customer Relationship Management (CRM) has become a key focus of modern enterprise operations with the help of modern Internet and CTI techniques. A company can achieve the customer‐centric business model and the one‐to‐one marketing strategy by using contact center applications and data mining methodologies. With the increasing number of communication channels, telephone‐based contact centers are no longer sufficient to build and maintain good customer relations. Multi‐channel contact centers that integrate phone, fax, e‐mail, web, and PDAs enable managers to respond to customer queries, complaints and service requests. An improved CRM program not only provides greater access but also provides the means to analyze customer interaction data. Corporations gain benefits such as enhanced customer loyalty and brand enhancement by transforming data collected through multiple communication channels into meaningful knowledge. This research uses a multi‐channel contact center (CC) as a basis to model customer interaction processes, define key performance indicators (KPIs) of CC, and develop CC evaluation methods to measure customer satisfaction and service quality of a contact center based on the set KPIs.
5.5.2 Application of SSM and Architecture Frameworks as a Method of Enquiry for Organisational Behaviour
Authors: Vencel Les , Sweetman Elizabeth 
Published: November 2014

AbstractSystems engineering is traditionally used as a method of design. In this study, it has been used as a method of enquiry into organisational behaviour in a sociotechnical system. A mix of methodologies from both the functionalist and interpretative social paradigms has been adopted. The methodology mix comprises Checkland's Soft Systems Methodology (SSM) and Structured Analysis and Design Techniques. This hybrid methodology allowed the use of rich pictures and architectural models to analyse organisational behaviour from two representative views: the human activity system and the operational architecture.The paper relates the goals of developing an understanding of the current organisational operational behaviour and then discusses the use of methodological pluralism, its rationale and the use of a revised Total Systems Intervention (TSI) model by Jackson based on contemporary critical systems thinking as a checklist for pluralism. The hybrid methodology using both soft and hard methods employed rich pictures and Defence Architecture Framework (DAF) compliant architecture models (AS‐IS views) to enquire into organisational behaviour. The DAF models represented both the perceived and actual state of operations. Comparison of the DAF models correlated with the SSM derived rich pictures and issues log were used to develop an understanding of the organisational behaviour as well as produce an updated operational architecture. Recommendations for change were made to senior management. We finish the paper with a 12‐point lessons learnt discussion of our experiences in doing this study. We conclude that the use of a pluralist systems engineering approach as a method of enquiry into sociotechnical organisational behaviour can provide a richer understanding of operational behaviour as it complements the human activity systems view with the operational architecture views. The pluralist approach is methodologically sound and Jackson's modified TSI provides an evaluation checklist.
5.6.1 The Application of Complexity Theory in the Development of Large‐scale ICT Systems
Authors: du Preez Lukas Johannes , Smith Abraham Johannes 
Published: November 2014

AbstractThe elements of complexity theory (chaos theory) found application in many diverse disciplines, including the social and management sciences. It became a means to address some of the vexing problems that could not be solved through direct causal analysis. Complexity theory contradicts many of the existing views of conventional management and requires a cognitive change from a rational Newtonian paradigm to a non‐linear, dynamic and complex systems paradigm. This paper unites the principles of complexity theory with Information and Communications Technology (ICT) project management by considering any large‐scale ICT development project as a non‐linear, dynamic and complex system within the context of a larger complex environment. The interactions between the different complex dimensions of the project state space are discussed. ICT project‐ and risk management are described within the context of the elements of complexity theory such as sensitive variables, attractors and fractals.
5.6.2 User Requirements for a Technical Risk Assessment Technique
Authors: Bijl Maarten G.H. , Hamann Robbert J. 
Published: November 2014

AbstractThis paper addresses the results of a study identifying the user requirements for a technical risk assessment technique, specifically for use by small to medium sized enterprises active in space engineering. By means of a questionnaire Systems Engineers and Project Managers of four companies where interviewed in order to collect data on the companies' business, the experience of the personnel with risk management, constraints on the technique's implementation and the content of the technique.Major result of the study is that the view on risk and the factors composing it varies widely and that a technique or tool will likely not be applied if it does not agree with the view of the assessor. As a consequence a technique must enable the modelling of the assessor's perception of the structure of the risk (that is: the factors determining the probability of occurrence of a risk and their mutual interaction). A basic set of risk models (Risk Spaces) is proposed and the constraints on technique and tool are summarized.The paper presents the main elements of the User Requirements for a technical risk assessment technique for the specific target group: they address both a technique and tool to construct the risk model (Model Tool Kit) and the risk assessment technique and tool itself.
6.1.2 Interactive Metamodel‐Compliance Checking of Requirements in a Semiformal Representation
Authors: Kaindl Hermann , Kramer Stefan , Hailing Mario , Harput Vahan 
Published: November 2014

AbstractChecking requirements is highly desirable but hard to achieve in practice, where only word processors are used in most projects. While in this case reviews are more or less the only means, formal representations allow for a variety of automated checks. Unfortunately, formal representations of requirements are rarely available in real‐world projects.Semiformal representations are easier to obtain and still offer some possibilities for automated checks. Based on an object‐oriented hypertext representation, we present an implemented approach for compliance checks against a metamodel, which resembles some kind of completeness checking. In addition to allowing checks to be invoked by a human user of the tool, the checks are periodically and automatically invoked by taking into account the already existing information on the requirements. In summary, we propose an interactive approach with shared initiative between the tool and its user for compliance checking of requirements against a metamodel in a semiformal representation.
6.3.2 Goal / Strategy Maps Methods, Techniques and Tools to Specify Requirements in Different Evolutionary Contexts
Authors: Salinesi Camille , Etien Anne , Zoukar Iyad 
Published: November 2014

Abstractthis paper reports the status of a research program that deals with the issues specifically raised by Requirements Engineering (RE) in the context of Information System (IS) evolution projects. This research program was triggered by the ‘Chaos’ report by the Standish Group, which explains that the lack of adequate RE methods techniques and tools is a major cause of failure of IS projects, and on the other hand, by Bohem's report, which says that most of IS projects are set in an evolutionary context rather than for developing new IS. Our goal was three‐fold: (i) to identify the methodological frameworks for doing RE in IS evolution projects, (ii) to build adequate modeling techniques that match the need of these frameworks, and (iii) to propose adequate methods and tools to deal with IS evolution requirements. This paper reports on each of these aspects.
7.1.1 Assessing the Impact of Requirements Volatility on the SE Process using Bayesian Analysis
Authors: Russell Michael S. 
Published: November 2014

AbstractThere are many factors that affect the level of requirements volatility a system experiences over its lifecycle. Improper requirements generation, undocumented user expectations, conflicting design decisions, and anticipated / unanticipated world states are representative of these volatility factors. Combined, these volatility factors adversely affect successful system development. This paper proposes that a Bayesian Network can be used to support reasonable judgments concerning the most likely sources and types of requirements volatility a developing system will experience prior to starting development; and by doing so it is possible to predict the level of requirements volatility the system will experience over its lifecycle. This assessment offers valuable insight to the system's developers, particularly by providing a starting point for risk mitigation planning and execution.
7.2.3 Too Hard, Too Soft, Just Right … Goldilocks and Three Research Paradigms in SE
Authors: Cropley David H , Harris Michael B 
Published: November 2014

AbstractThis paper examines the spectrum of methodologies that can be utilized in research in general. The two primary categories, quantitative and qualitative, traditionally find use in particular discipline areas. This paper will examine the characteristics of common quantitative and qualitative methodologies and discuss how these can be applied to research in systems engineering. The result is a wide choice of methodologies covering both the functionalist (hard) and interpretive (soft) paradigms. The broad focus of systems engineering, covering both hard (technical) and soft (socio‐technical) approaches, will be shown to benefit from a broad appreciation of the full range of research methods. The paper discusses the predisposition to quantitative methods that dominates engineering thinking and argues for the inclusion of qualitative research methods in the toolkit of systems engineering researchers.
7.3.3 The Applications of Systems Engineering for the Development of RFID in e‐Logistic Service
Authors: Wang T.J. , Tsen Y.J. , Chang Larry 
Published: November 2014

AbstractCurrent paper will apply system engineering to Radio Frequency Identification (RFID) system that is developed for the purpose to improve Taiwanese logistic industry competitiveness. Based on the development strategy for systems engineering in the e‐environment, the production line and warehouse management e‐logistic RFID system program integrate both domain knowledge and systems engineering. The methodologies, tools, procedures, templates and management system of systems engineering have been applied in this program. Using systems engineering technology, such as requirement analysis, risk management and others will help to solve the complex and changing environment of present logistic service industry in Taiwan.
7.4.1 An Architecture Description Language for Developing Automotive ECU‐Software
Authors: Freund Ulrich , Gurrieri Orazio , Küster Jochen , Lonn Henrik , Migge Jörn , Reiser Mark‐Oliver , Wierczoch Thomas , Weber Matthias 
Published: November 2014

AbstractThe significance of embedded software systems in the automotive domain has increased dramatically during the last ten years. In contrast, today's development methods and tools applied in the automotive industry are limited in many ways. They are each restricted to certain stages of development and therefore several approaches need to be used simultaneously, they are not interoperable and most of them are not tailored to the specific needs of the automotive domain. In this paper we present an Architecture Description Language called EAST ADL that seeks to capture all information needed during development, from early analysis to implementation and evolution and meets specific automotive requirements such as support for automatic code generation in the context of common automotive hardware.
7.4.2 Europe's First System of Systems
Authors: Brown Phillip J. 
Published: November 2014

AbstractSystems thinking is as old as civilization. The question is can today's systems engineers benefit from examining the accomplishments of early system builders? This thought is examined in the context of roman engineering achievements.The birth of the Roman republic around 500 B.C. led to the building of an unprecedented array of remarkable systems. The needs of the republic, followed by those of the empire, produced important advances in building construction, water supply, mining and the building of bridges, roads, harbors, ships. Many complex systems such as the aqueducts supplying Rome's water were created.This paper postulates that the Romans developed Europe's first system of systems. The backbone of the system, a network of roads radiating out from Rome, began as a strategic initiative to maintain government control throughout the empire. Over time, this super system evolved into the means for Romanizing the many different cultures dragged into Rome's dominion. The resulting cultural harmonization left a lasting imprint on the world.
7.5.1 Recommendations for Automated Test Requirements Management
Authors: Houser Jody B. 
Published: November 2014

AbstractIn the aerospace community, requirements data has a way of living beyond the end of product validation when it might be expected that it has fulfilled its purpose. Not only are these requirements then used to develop test strategies and acceptance limits for the production line, but certain aerospace standards and product support agreements demand a transmittal of test requirements to the airlines and their representatives. The management of requirements data as it progresses from the interface control document, to test equipment engineering and ultimately to the airframer's customer is explored. Specifically, a set of recommendations for a tool to support production test requirement management is proposed.
7.6.1 Applying the Object Oriented Systems Engineering Method to A Simple Hardware System
Authors: Hsu John C. , McDonough J. Mike 
Published: November 2014

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

AbstractObject‐oriented analysis and design methods are becoming predominant in the systems engineering workplace. One result is that object‐oriented analysis (OOA) may come to replace older structured analysis (SA) methods traditionally used by systems engineers. Another result is that assertions are sometimes found in the literature claiming or implying that object‐oriented analysis methods are uniformly better than structured analysis methods. But if OOA and SA are homeomorphic1, a systems engineer should choose to work with the analysis methods and representations that are most effective and convenient to solve specific problems of interest.A substantially complete invertible mapping is presented in this paper to serve as evidence that OOA and SA are homeomorphic. A characterization of the kinds of problems better suited to one domain than the other is included in the paper.
7.6.3 Role of Emerging Technologies in Facilitating Integration of ATM Operations: A Look at One Example: XML & Its Related Technologies
Authors: Katkin Rafe , Taber Norma , Connolly Kelly 
Published: November 2014

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

AbstractI believe that most current requirement specifications lack clarity, and are very poor in their supporting information. We need to make requirement specifications ‘work harder’ by adding more ‘background’ to the requirements By ‘background’ I mean information related to the requirement that is not the core requirement itself. The background information I am referring to includes: prioritization (expressed by such means as ‘Justification’), risk management (expressed using such means as ‘Assumptions’), change management (for example, the integration requirements), and quality control (for example, the testability requirements).To improve requirement specification, I have developed a requirement specification language, as a subset of my planning language, ‘Planguage‘. This language has developed by practical need, in international industry over three decades, and is supplemented here with some recent ideas. This paper will give an overview of the conceptual basis and some sample detail.
8.1.3 Ten Questions to Ask Before Opening the Requirements Document
Authors: Davies Paul 
Published: November 2014

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