Abstract. The last 20 years have shown a dramatic expansion in Systems Engineering theory, knowledge, knowhow and practical application. Despite this increase, there is evidence within organisations that there has been a growing gap between the SE required and the SE delivered. The authors of this paper describe the results of a study into the reasons for this gap, based on an on-line survey which received 85 valid responses.The authors conclude that:• Project professionals are using approaches that are not appropriate to the problems being tackled; • Behaviour is being driven by narrow views of what organisations believe is right, rather than the broader range of practice that they allow; • Project professionals adopt preferred approaches which they apply across more than one type of problem.The authors demonstrate that there is truth in the assertion that Systems Engineers apply the same approach, irrespective of the situation. Whilst standard Systems Engineering approaches, for example the V lifecycle, are the right approach in the complicated space, it is less appropriate in simple, complex or chaotic spaces. All too often, projects start with the assumption that we should use standard Systems Engineering approaches that we have used before, rather than ask: 'To V or not to V?'
There has been an explosion of interest in the development of System of Systems engineering approaches in the last ten years. Going from an average of 10 papers a year at the end of the 1990s, there has been over 250 papers a year published on the topic each year for the past five years.The vast majority of these papers present System of Systems' (SoS) challenges as novel and challenging at the edge of our understanding of systems engineering. The general consensus is that the explosion of SoS is unprecedented, and therefore requires unprecedented approaches to SoS engineers.Whilst the authors do not disagree that SoS are challenging and require a different approach than product systems engineering techniques, we do not believe that SoS are unprecedented. This paper describes the development of a large and complex SoS as it was established, evolved and then eventually merged into a single large system. This evolution took place from the early 1830's through to the early 1950s. The SoS was the British rail network. This paper:• Describes the growth of the British rail network from 150 independent railways through to one integrated network; • Describes the key operational, business and technical changes needed to move the network from a virtual SoS, through a collaborative SoS to a directed single system; 617• Evaluates the SoS against three basic SoS approaches/taxonomies: the US DoD SoS classifications, the UK MOD SoS Approach and the UK Department for Transport engineering assurance framework; • Identifies the lack of importance of global technical standards in delivering SoS effectiveness; • Identifies gaps in the frameworks, in particularly with respect to the economic drivers for creating an SoS.Much like the artistic and literary genre of Steampunk, this case study is a mixture of familiar SoS concepts and approaches in an unfamiliar Victorian setting. Unlike Steampunk this case study is not only amusing and entertaining, it is also educational.
Recognizing the stated aims of the Engineering of Computer-Based Systems (ECBS) discipline, namely the design, development, deployment, and analysis of complex systems whose behavior is, to a substantial degree, determined or controlled by computers, the proposal is that the term [and the associated process] of "requirements" be replaced with "decisions" and a decision process. Requirements, by definition, mandate a flow that originates with the senior and are directed unilaterally to the junior: "I require this of you." The decision process is exactly the opposite in both flow and participation. Rather than unilateral direction to the junior that is originated by the senior, decisions are choices by the senior resulting from united consideration with the junior of the latter's nominated set of alternatives: "I select the following as a result of our mutual consideration of the options and associated assessments and recommendations you have provided. " 435 0-8186-7889-5/97 $10.00 0 1997 IEEE
A brand-new high-speed railway project such as HS2, currently under development in the United Kingdom, presents a requirements engineering problem that is similar to domains where Systems Engineering (SE) is more traditionally applied, such as an aircraft, but with some differences in system structure that preclude a direct mapping of routine techniques. With over 300 separate elements of design in the Country South portion of the route, fitting into roughly 20 categories and inheriting requirements at multiple levels, including location-specific constraints, it was considered necessary to implement a model-based solution to provide an adequate level of technical assurance by managing the requirements and their links to the design elements. A database tool with diagramming capability was used to create a visual traceability structure between the client's original requirements and the refined requirements. A layered model of the system architecture was used to apply requirements to the correct sets of individual design elements. From this combined requirements and architecture model, spreadsheet checklists were generated for designers to perform verification. The resulting data were then re-imported to the database and processed into a detailed report for submission to the client. The solution developed automates assignment of requirements traceability in order to provide exactly the right set of requirements for each deliverable on the route, which may consist of multiple asset types in differing combinations and with local requirements as well as more generic requirements assigned by equivalence. C⃝ 2015 Wiley Periodicals, Inc. Syst Eng 18: 300-309, 2015
Although Agile is well‐defined, and relatively widely‐used within the software engineering field, applying Agile to Systems Engineering (SE) is still under debate. While some feel that Agile SE offers potential to improve customer satisfaction and reduce cost, risk and time to market, it is unclear how well Agile approaches apply to SE. This paper explores diverse rationales for applying Agile SE, various types of systems it can be applied to, and different Agile SE approaches, showing that there is no single definition of Agile. Views range from: a high tempo approach to systems delivery analogous to Agile software, radical tailoring of conventional SE against fixed requirements, using agile software techniques to develop SE documents and models, to using Agile as a sales mechanism with no real understanding of chance of success. These perspectives are analysed against the 12 Agile software principles, Snowdon's Cynefin Framework and Ring's Value Cycle, concluding with 14 observations about Agile SE approaches.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.