Control strategies for structural design - Revision history

Iain at 19:43, 19 November 2021

2021-11-19T19:43:28Z

← Older revision		Revision as of 20:43, 19 November 2021
Line 3:		Line 3:
	'''General'''		'''General'''

	* Be vigilant throughout the design process about requirements conformance		* Be vigilant throughout the design process about requirements conformance
	* At design review meetings have requirements conformance on the agenda.		* At design review meetings have requirements conformance on the agenda.

Iain at 17:49, 11 August 2021

2021-08-11T17:49:05Z

← Older revision		Revision as of 18:49, 11 August 2021
Line 28:		Line 28:
	Use the strategies recommended in [http://stempedia.com/wp-content/uploads/Modelling-proces-3-1.docx this document.]		Use the strategies recommended in [http://stempedia.com/wp-content/uploads/Modelling-proces-3-1.docx this document.]

	=== <big>Code of practice conformance</big> ===		=== '''<big>Code of practice conformance</big>''' ===
	'''Validation of code provisions'''		'''Validation of code provisions'''

Iain at 17:45, 11 August 2021

2021-08-11T17:45:17Z

← Older revision		Revision as of 18:45, 11 August 2021
Line 26:		Line 26:

	=== '''<big>Analysis modelling</big>''' ===		=== '''<big>Analysis modelling</big>''' ===
	Use the strategies recommended in this document		Use the strategies recommended in [http://stempedia.com/wp-content/uploads/Modelling-proces-3-1.docx this document.]

	=== <big>Code of practice conformance</big> ===		=== <big>Code of practice conformance</big> ===

Iain: Created page with " === Requirements conformance === '''General''' * Be vigilant throughout the design process about requirements conformance * At design review meetings have require..."

2021-08-11T17:42:25Z

Created page with " === <big>Requirements conformance</big> === '''General''' * Be vigilant throughout the design process about requirements conformance * At design review meetings have require..."

New page

=== <big>Requirements conformance</big> ===
'''General'''

* Be vigilant throughout the design process about requirements conformance
* At design review meetings have requirements conformance on the agenda.

'''Actions'''

* Define the requirements at Stage 1. The requirements at this stage should be independent of the type of structure.
* Modify the requirements at Stage 2 taking account of decisions made at that stage.
* Seek to avoid changes to the requirements after stage 2.

'''Validation of the requirements: '''

Seek to ensure that:

* all requirements been identified
* all requirements been adequately stated in the Structural Design Brief

'''Verification'''

* Ensure that the mandatory requirements have been satisfied
* Explain why any non-mandatory requirements have not been fully implemented.

=== '''<big>Analysis modelling</big>''' ===
Use the strategies recommended in this document

=== <big>Code of practice conformance</big> ===
'''Validation of code provisions'''

Ensure that the design context is within the scope of the codes that are specified in the Structural Design Brief. If it is not, seek to ensure that relevant issues that are not covered in the codes are addressed. This is especially important in innovative contexts. See, for example, the [[Structural design failures|Ronan Point Collapse]]

'''Performing the calculations'''

Code of practice rules should be processed using software that has been subject to rigorous QA assessment.

Hand calculators should only be used in preliminary work and back-of-an-envelope checks. They should not be used for final calculations because of the increased risk of errors when values are being keyed-in.

See guidance on programming of calculations.

'''Input checking'''

Verify input to software

'''Results transfer'''

Verify that the results have been correctly transferred to drawings and schedules,

=== <big>Working with integrated systems</big> ===
Special vigilance is needed when the analysis model is generated directly from a graphical/parametric model and when results from the analysis model are automatically passed to the code checking software. There is potential for error when this process results in changes to the analysis model and the graphical model. It is essential that such changes (a) are capable of being reviewed by an engineer, (b) are reviewed by an engineer and (c) that intervention by an engineer in the integrated process is feasible.