Systems Engineering in Construction (2020 – 2021)
Summary of the lectures and literature System Engineering in Construction
Systems Engineering in Construction
Summary of the lectures and literature Systems Engineering in Construction
Lecture 1: Introduction of Systems Engineering and Circularity
The definition of systems engineering is according to INCOSE: “Systems Engineering is an
interdisciplinary approach and means to enable the realisation of successful systems. The methodology
considers both the business and the technical needs of all customers and is aimed at providing a quality
product that meets the users' needs.”
Two domains will be discussed in this course:
- Systems Engineering: design is a systematic effort.
- Circular Economy: waste is a design error.
Leading principles in Systems Engineering (SE) are:
- A structured design process.
- Managing complexity and risks.
- Client and stakeholder focus.
- A life cycle approach.
- Considering technical and business needs.
Systems Engineering: Required in nearly all major civil engineering projects Example: In the
Netherlands, Rijkswaterstaat and ProRail prescribe SE methodology for all their projects.
Circular Economy: Emerging concept and increasingly mandated worldwide Example: The Netherlands
strives to realise a fully circular economy in 2050 and set a 50% reduction in virgin materials used as
an intermediate target for 2030.
Lecture 2: Methodology for Systems Engineering in Construction
In systems engineering, we design what the client really wants and not what the client described he
really wants.
The Systems Engineering process model
The 1st phase: “Input” ambitions, documents, environment, and stakeholders are investigated.
Investigate “system” and its interactions (interfaces). There are several tools such as the power-
interest grid, dome method, logical process method, stakeholder method that can be used during this
phase. This first phase is documented as the situation analysis document.
We need to structure the messy “input”, it needs to be translated into solution-neutral system
requirements (via “customer Requirements Specification”).
Page 1 of 21
,Systems Engineering in Construction (2020 – 2021)
Summary of the lectures and literature System Engineering in Construction
A customer requirement needs to be broken down, prioritised, and translated into system
requirements. Make them SMART (Specific, Measurable, Acceptable, Realistic, and Time-bounded).
The 2nd phase: “Requirements analysis” the input can be structured by translating the (messy) input
into requirements. Organising the requirements in a design brief structure. Tools that can be used are
the SE design brief template, and software (e.g., Relatics). This stage is documented as the design brief.
Design Brief in Systems Engineering:
The 3rd phase: “Functional analysis and allocation”, it is defined what the system should do. Analyse
and determine the functionality of a system. Function = verb + noun. Avoid passive formulations, for
example, use illuminate room instead of providing light. In this phase, we need to map the
functionalities in schemes. Tools that can be used are the function tree, timeline analysis, functional
analysis system technique (FAST) diagram. This phase is documented as functional diagrams and
explanations.
The 4th phase: “Requirements loop”, checks if the linkages are correct. There must be checked if all
requirements are linked to functions. Tools that can be used are Requirements Allocation Sheet (RAS).
This phase is documented as RAS and explanations.
Requirements Allocation Sheet (RAS) for Systems Engineering:
Principle of Allocation
The 5th phase: “Functional analysis and allocation” is the
materialisation of the system. In the previous phase the
functions were created, now objects are connected to it. We
link functions to objects following a certain design ratio. Tools
that are used are the object breakdown structure (OBS) and
extend the requirements allocation sheet (RAS). This phase is documented as function-object
diagrams and explanations.
The 6th phase: “Design synthesis”, make alternative design representations with all objects and their
interfaces. Tools that are used are floor plans, cross-sections, 3D/BIM models, mock-ups, and multi-
criteria analysis (MCA). This phase is documented as design alternatives and the “best” ones.
Lego® blocks can be compared with modular-sectional architecture. It has decoupled interfaces,
interfaces are the same (structure of the block, maybe smaller or larger blocks but the same interface)
and not specifically linked to one central objects. Interfaces are the connections between other
elements.
Page 2 of 21
, Systems Engineering in Construction (2020 – 2021)
Summary of the lectures and literature System Engineering in Construction
Design synthesis: How to represent objects?
The 7th phase: “Design loop”, check if the linkages are correct. Revise the functions and objects based
on selected alternative and vice versa. There are no specific tools. This phase is documented by
explanation.
The 8th phase: “Verification”, is checking if the design meets the requirements. Check if the design
and/or construction meets requirements. Tools that are used are calculation, simulation, and (expert)
inspection. This phase is documented as a verification plan or a verification report.
Verification building the model correctly (correctly implemented with good input and structure).
Purpose: ensure the conceptual model has reflected accurately in the computerised representation.
An example of an (interface) requirement: The room must have one power outlet.
Design verification: Inspection (drawing)
Construction verification: Inspection (picture/form)
Verification Table:
The 9th phase: “Validation”, check if the design meets the expectations of stakeholders. There are no
formalised tools, but design/progress meetings and virtual reality methods can be used. This phase is
documented with a validation report.
Validation building the correct model (an accurate representation of the real system). Purpose: Ensure
that the simulation model is a “fair” representation of the real system (considering the modelling
purpose)
Verification vs. Validation:
Verification is about is it built in the right way and Validation is about is it the right system.
Page 3 of 21
