Conceptual Design - Revision history

Goto: /* Documentation Best Practice */

2025-12-05T05:13:41Z

Documentation Best Practice

← Older revision		Revision as of 05:13, 5 December 2025
Line 34:		Line 34:

	Thus, Review should be documented to facilitate learning as a team, including external teams outside the formal organization because OSE works openly.		Thus, Review should be documented to facilitate learning as a team, including external teams outside the formal organization because OSE works openly.

			Changes integrated between iterations, which typically reflect feedback from an actual build, are listed in the newly improved version as Integrated Feedback Changes.

	=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=		=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=

Marcin: /* OSE Philosophy */

2023-05-21T16:54:51Z

OSE Philosophy

← Older revision		Revision as of 16:54, 21 May 2023
Line 27:		Line 27:
	Jose Urra feedback: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''		Jose Urra feedback: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

	MJ feedback: Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing [[BHAG]]s. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built. 'Bullshit requirements' are the initial non-feasible requirements that the team will cycle through and convert to feasible requirements. As progress continues, the team produces less 'bullshit requirements' and more realistic requirements. There is a danger: realistic requirements may not be ambitious or innovative. This needs to be addressed. We address this by a level of humility that says we do not know everything - so that our 'experience' does not lead us to losing our youth and creativity - and a commitment to extraordinary results. Humility and commitment allows us to produce realistic requirements that are still part of long-term moonshots.		MJ feedback: Calculations provide only a certain level of verification and are themselves not sufficient to prove that a design will work, because “All models are wrong, but some are useful”. Calculations must be verfied by integrated performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing [[BHAG]]s. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built. 'Bullshit requirements' are the initial non-feasible requirements that the team will cycle through and convert to feasible requirements. As progress continues, the team produces less 'bullshit requirements' and more realistic requirements. There is a danger: realistic requirements may not be ambitious or innovative. This needs to be addressed. We address this by a level of humility that says we do not know everything - so that our 'experience' does not lead us to losing our youth and creativity - and a commitment to extraordinary results. Humility and commitment allows us to produce realistic requirements that are still part of long-term moonshots.

	=Documentation Best Practice=		=Documentation Best Practice=

Marcin: /* OSE Philosophy */

2023-05-21T16:51:49Z

OSE Philosophy

← Older revision		Revision as of 16:51, 21 May 2023
Line 27:		Line 27:
	Jose Urra feedback: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''		Jose Urra feedback: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

	MJ feedback: Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing [[BHAG]]s. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built.		MJ feedback: Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing [[BHAG]]s. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built. 'Bullshit requirements' are the initial non-feasible requirements that the team will cycle through and convert to feasible requirements. As progress continues, the team produces less 'bullshit requirements' and more realistic requirements. There is a danger: realistic requirements may not be ambitious or innovative. This needs to be addressed. We address this by a level of humility that says we do not know everything - so that our 'experience' does not lead us to losing our youth and creativity - and a commitment to extraordinary results. Humility and commitment allows us to produce realistic requirements that are still part of long-term moonshots.

	=Documentation Best Practice=		=Documentation Best Practice=

Marcin: /* What is Conceptual Design? */

2023-05-21T16:46:09Z

What is Conceptual Design?

← Older revision		Revision as of 16:46, 21 May 2023
Line 23:		Line 23:
	'''Thus in OSE work we propose the usefulness of Integrated Requirements - ones which embody learning from result data and other insights.''' The concept of integration is key to OSE work: input from numerous individuals who have experience in the [[CAD-BOM-Build]] cycle - and who understand from experience how to break the [[Iron Triangle]].		'''Thus in OSE work we propose the usefulness of Integrated Requirements - ones which embody learning from result data and other insights.''' The concept of integration is key to OSE work: input from numerous individuals who have experience in the [[CAD-BOM-Build]] cycle - and who understand from experience how to break the [[Iron Triangle]].

	Jose Urra sez: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

	Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build.		=OSE Philosophy=
			Jose Urra feedback: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

			MJ feedback: Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing [[BHAG]]s. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built.

	=Documentation Best Practice=		=Documentation Best Practice=

Marcin: /* Documentation Best Practice */

2023-05-21T16:37:43Z

Documentation Best Practice

← Older revision		Revision as of 16:37, 21 May 2023
Line 29:		Line 29:
	=Documentation Best Practice=		=Documentation Best Practice=

	Concept design requires verification. Calculations are related to a certain level of verification, and calculations are a separate Development Template (item #6).		Concept design requires verification. Calculations are related to a certain level of verification, and calculations are a separate Development Template (item #6). Concepts should be refined through review.

			Thus, Review should be documented to facilitate learning as a team, including external teams outside the formal organization because OSE works openly.

	=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=		=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=

Marcin: /* What is Conceptual Design? */

2023-05-21T16:36:16Z

What is Conceptual Design?

← Older revision		Revision as of 16:36, 21 May 2023
Line 15:		Line 15:
	The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.		The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.

	In OSE's design language, an ''Integrated Requirement'' is one into which feedback from an actual build has already been provided. That is, if materials, calculations, or result data have been selected or obtained - then these can go into the Requirement - if they meet spec. 'Spec' means a certain level of predetermined performance.		In OSE's design language, an ''Integrated Requirement'' is one into which feedback from an actual build has already been provided. That is, if materials, calculations, or result data have been selected or obtained - then these can go into the Requirement - if they '''meet spec'''. 'Spec' means a certain level of predetermined performance.

	'''In the limit of a fully-detailed Requirement - we have a concept.'''		'''In the limit of a fully-detailed Requirement - we have a concept.'''

	'''In the limit of a concept being filled in with technical details - we have a Technical Design.'''		'''In the limit of a concept being filled in with technical details - we have a Technical Design.'''

			'''Thus in OSE work we propose the usefulness of Integrated Requirements - ones which embody learning from result data and other insights.''' The concept of integration is key to OSE work: input from numerous individuals who have experience in the [[CAD-BOM-Build]] cycle - and who understand from experience how to break the [[Iron Triangle]].

	Jose Urra sez: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''		Jose Urra sez: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

Marcin: /* What is Conceptual Design? */

2023-05-21T16:26:31Z

What is Conceptual Design?

← Older revision		Revision as of 16:26, 21 May 2023
Line 21:		Line 21:
	'''In the limit of a concept being filled in with technical details - we have a Technical Design.'''		'''In the limit of a concept being filled in with technical details - we have a Technical Design.'''

	Jose Urra sez: When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.		Jose Urra sez: ''When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.''

			Calculations are not sufficient. Calculations must be verfied by performance data - the actual results from a build.

	=Documentation Best Practice=		=Documentation Best Practice=

Marcin: /* What is Conceptual Design? */

2023-05-21T16:24:45Z

What is Conceptual Design?

← Older revision		Revision as of 16:24, 21 May 2023
Line 22:		Line 22:

	Jose Urra sez: When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.		Jose Urra sez: When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.

			=Documentation Best Practice=

			Concept design requires verification. Calculations are related to a certain level of verification, and calculations are a separate Development Template (item #6).

	=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=		=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=

Marcin: /* What is Conceptual Design? */

2023-05-21T16:23:25Z

What is Conceptual Design?

← Older revision		Revision as of 16:23, 21 May 2023
Line 14:		Line 14:

	The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.		The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.

			In OSE's design language, an ''Integrated Requirement'' is one into which feedback from an actual build has already been provided. That is, if materials, calculations, or result data have been selected or obtained - then these can go into the Requirement - if they meet spec. 'Spec' means a certain level of predetermined performance.

	'''In the limit of a fully-detailed Requirement - we have a concept.'''		'''In the limit of a fully-detailed Requirement - we have a concept.'''

Marcin: /* How Does Conceptual Design Relate to Other Aspects of a Product Development Process? */

2020-09-16T20:40:35Z

How Does Conceptual Design Relate to Other Aspects of a Product Development Process?

← Older revision		Revision as of 20:40, 16 September 2020
Line 22:		Line 22:

	=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=		=How Does Conceptual Design Relate to Other Aspects of a Product Development Process?=

			Once we have defined [[Conceptual Design]], we can proceed to further refinement of concept towards a technical design. Upon sufficient refinement, there is sufficient information to manifest the technical design in the form of [[3D CAD]]. The [[Modular Breakdown]] step is where the concept can be refined further by examining the constituent modules. The Modular Breakdown is the best place to capture the transition from concept to the actual design. Once the actual design (3D CAD) is produced - we can do full Calculations including structural, thermal, fluid, and electromagnetic. Partial calculations can be made at the phase of conceptual design - with ''back of the envelope'' calculations just to get an idea of basic feasibility. All of these steps can be done at various levels of product-service system organization: the system, machine, module, and submodule (part) levels.

	=Links=		=Links=