-
Waste Recycling Facilities
Link -
Sports Field Infrastructure
Link -
Traffic Management Systems
Link
Systems Engineering
Systems engineering is an interdisciplinary field of engineering focusing on how complex engineering projects should be designed and managed over their life cycles. We have used systems engineering techniques on some complex construction projects, and on several occasions this has resulted in projects which have had no variations.
Where appropriate, as a foundation, we normally use Bahill's eight systems engineering documents.
An example of our systems engineering documents can be found on - wasterefinery.net
About Systems Engineering Documents
Introduction
Systems engineering can be traced back to the 1940's when Bell Telephone Laboratories started to develop techniques to manage their telephone networks. Complex systems reach a point when it is no longer possible to rely on design evolution to manage or improve the systems. So systems engineering methods have to be employed that address the complexity directly.
The need to identify and manipulate the properties of a complex system has driven the development of engineering techniques. Systems engineering allows for a better comprehension of large integrated systems, especially as they grow more complex.
Generally, where this is appropriate, we use the systems engineering framework articulated by A. Terry Bahill. Usually two of Bahill’s eight-document sets are created: one for the 'product', and another for the 'process' that will create it. It is almost always a mistake to mix the product, and process requirements. The following documents are generalised proto-types of documents used by industry for the design, and implementation, of complex systems.
Systems engineering is used by NASA to manage projects such as it’s space probes. Also, weapons systems often use systems engineering. Scientific projects, and chemical plants, also use systems engineering processes. For example, we used systems engineering to design a plant that would use household garbage to produce energy, and then process all the remaining material so that it could be easily harvested for recycling.
Document 1:
The Problem Situation Document is an executive summary. It articulates the customer’s needs, and states the goals of the project. It defines the business needs, capabilities, and scope. It lists the deliverables, the key decisions, and provides an analysis of the alternatives. This document provides a summary of the metrics and deliverables. This document is intended for management and the public, and should be clear and easy to understand.
Document 2:
The Customer Requirements Document is a detailed description of the problem in plain language. This document does not describe a solution, but is based on the use cases and the supplementary requirements specification. This document is intended for management, the customer, and engineering.
Document 3:
The Derived Requirements Document is a technical description of the problem statement requirements. And each item is derived from a requirement in the customer requirements document. This document is intended for engineering.
Document 4:
The Verification and Validation Document makes sure that the system does what it is supposed to do, and ensures that the system will satisfy the needs of the customer. And that a real-world solution can be built, that satisfies each requirement. This document is intended for engineering and the customer.
Document 5:
The Concept Exploration Document is a study of alternative system designs. This document is revised on an iterative basis as more information becomes available. And an analysis of the various alternatives is made. This is one of the most popular documents, and it should be easily understood by the public.
Document 6:
The Use Case Model contains many use case reports that in the aggregate describe the required behaviour of the proposed system. The early use cases should not include potential solutions. The intended audience for this document is management, the customer, the public and engineering,
Document 7:
The Design Model shows the objects that are required for all system functions. This document should contain the system boundary diagram, and all the system interfaces and model diagrams that comprise the system. As work is progressed the design model will become the implementation model, and then the operational model.
Document 8:
The Models, Mappings and Management Document contains a table that shows the mappings between the requirements of documents, It also includes activity diagrams, the user’s manual, the risk analysis, the scheduling, the business plan, and the technical language glossary.
Conclusion
The systems engineering eight documents are not written sequentially, but they are structured so they can be read sequentially. Typically the documents are started in this order -
1, 5, 6, 7, 3, 4, 8.
Creating these eight documents is not a serial process, and there are typically several iterations of each document. Therefore there are many opportunities for parallel processing, and re-ordering of the work flow. However, the documents are commonly completed in this order -
8, 3, 4, 5, 1, 2, 6.
It is important to note that, depending on the situation, it can be appropriate to adapt the format of this process to accommodate specific situations. The documents are a set of living documents, that are continually updated throughout the entire life cycle of the process.
If you have a project that you would like to discuss, please contact us.
Systems engineering is an interdisciplinary field of engineering focusing on how complex engineering projects should be designed and managed over their life cycles. We have used systems engineering techniques on some complex construction projects, and on several occasions this has resulted in projects which have had no variations.
Where appropriate, as a foundation, we normally use Bahill's eight systems engineering documents.
An example of our systems engineering documents can be found on - wasterefinery.net
About Systems Engineering Documents
Introduction
Systems engineering can be traced back to the 1940's when Bell Telephone Laboratories started to develop techniques to manage their telephone networks. Complex systems reach a point when it is no longer possible to rely on design evolution to manage or improve the systems. So systems engineering methods have to be employed that address the complexity directly.
The need to identify and manipulate the properties of a complex system has driven the development of engineering techniques. Systems engineering allows for a better comprehension of large integrated systems, especially as they grow more complex.
Generally, where this is appropriate, we use the systems engineering framework articulated by A. Terry Bahill. Usually two of Bahill’s eight-document sets are created: one for the 'product', and another for the 'process' that will create it. It is almost always a mistake to mix the product, and process requirements. The following documents are generalised proto-types of documents used by industry for the design, and implementation, of complex systems.
Systems engineering is used by NASA to manage projects such as it’s space probes. Also, weapons systems often use systems engineering. Scientific projects, and chemical plants, also use systems engineering processes. For example, we used systems engineering to design a plant that would use household garbage to produce energy, and then process all the remaining material so that it could be easily harvested for recycling.
Document 1:
The Problem Situation Document is an executive summary. It articulates the customer’s needs, and states the goals of the project. It defines the business needs, capabilities, and scope. It lists the deliverables, the key decisions, and provides an analysis of the alternatives. This document provides a summary of the metrics and deliverables. This document is intended for management and the public, and should be clear and easy to understand.
Document 2:
The Customer Requirements Document is a detailed description of the problem in plain language. This document does not describe a solution, but is based on the use cases and the supplementary requirements specification. This document is intended for management, the customer, and engineering.
Document 3:
The Derived Requirements Document is a technical description of the problem statement requirements. And each item is derived from a requirement in the customer requirements document. This document is intended for engineering.
Document 4:
The Verification and Validation Document makes sure that the system does what it is supposed to do, and ensures that the system will satisfy the needs of the customer. And that a real-world solution can be built, that satisfies each requirement. This document is intended for engineering and the customer.
Document 5:
The Concept Exploration Document is a study of alternative system designs. This document is revised on an iterative basis as more information becomes available. And an analysis of the various alternatives is made. This is one of the most popular documents, and it should be easily understood by the public.
Document 6:
The Use Case Model contains many use case reports that in the aggregate describe the required behaviour of the proposed system. The early use cases should not include potential solutions. The intended audience for this document is management, the customer, the public and engineering,
Document 7:
The Design Model shows the objects that are required for all system functions. This document should contain the system boundary diagram, and all the system interfaces and model diagrams that comprise the system. As work is progressed the design model will become the implementation model, and then the operational model.
Document 8:
The Models, Mappings and Management Document contains a table that shows the mappings between the requirements of documents, It also includes activity diagrams, the user’s manual, the risk analysis, the scheduling, the business plan, and the technical language glossary.
Conclusion
The systems engineering eight documents are not written sequentially, but they are structured so they can be read sequentially. Typically the documents are started in this order -
1, 5, 6, 7, 3, 4, 8.
Creating these eight documents is not a serial process, and there are typically several iterations of each document. Therefore there are many opportunities for parallel processing, and re-ordering of the work flow. However, the documents are commonly completed in this order -
8, 3, 4, 5, 1, 2, 6.
It is important to note that, depending on the situation, it can be appropriate to adapt the format of this process to accommodate specific situations. The documents are a set of living documents, that are continually updated throughout the entire life cycle of the process.
If you have a project that you would like to discuss, please contact us.