What is Systems Engineering
Systems engineering is the discipline that brings together multiple engineering fields in order to deliver complex engineering projects and products. It is an interdisciplinary field that intersects technology and management.
Why do we need Systems Engineering
Systems engineering is necessary for engineered systems that have a level of complexity in which a small group of specialised engineers cannot themselves manage. The core function of systems engineering processes is to handle complex projects and ensure that the system itself delivers on the capabilities it promises. The more complex a system, the higher the RoI in terms of value that systems engineering provides - both in terms of money and time.
How do I Engineer Systems
There are two notable approaches to following systems engineering processes, notably Document-based Systems Engineering and Model Based Systems Engineering (MBSE). When implementing these approaches, the process typically follows a specific development model. There is no one correct way to do systems engineering, since each project/product has its own unique needs. Delivering 100 trains is different to delivering a robust telecommunication software. Software developers may initially jump to using agile,
Development Models
Traditional V-Model
Agile V-model
Pure Agile
Spiral Model
Document-based Systems Engineering
Disclaimer, NASA’s systems engineering handbook is the go-to reference for document-based systems engineering. Similarly, ESA has useful documentation. The intention of this section is to simplify these large documents and have some ‘ready-to-go’ templates. Markdown is the chosen format since it encourages writing as opposed to document design. You can then use a markdown to pdf converter, or simply copy and paste into your chosen word processor.
1. Concept of Operations (ConOps)
The concept of operations is a document that outlines the functionality and interactions of the system at a high-level. It is meant to be a point of reference for teams to then delve further into technical details. Find a template here.
2. Requirements and Architecture
System requirements are define the specifics of how a system should operate. Requirements should be detailed enough for engineers of different disciplines to create technical design documentation based from. There are known approaches to writing good system requirements, which you can find here. Often, engineered systems need to comply with international standards, the most ubiquitous being ISO9001. Depending on the system, it is likely many more standards should be adhered to, including safety, quality and system uptime standards.
High-level system architectures are a way to help understand how the system is structured, typically through diagrams. There are different system modelling languages available, such as SysML and UML. There is a conceptual overlap with MBSE approaches in this phase.
You can find a requirements template here.
3. Detailed Design
The design phase is engineering lead. Specialist teams will use system requirements and architectures and design their solutions against it.
4. Implementation
During the implementation phase, the system is being built. Many stakeholders will look to design documents, architectures, requirements to ensure they are building to specification.
5. Validation and Verification
Validation is defined as: the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. In other words - does the system work as intended based on what the user asked for? “Are you building the right thing?”
Verification is defined as: the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. In other words - is the built system in line with requirements (and regulations)? “Are you building it right?“