Conceptual Design: Difference between revisions
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
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 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.''' | |||
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 of validation, in the sense that you check to some extent if is needed, not if is feasible in detail. Validation/Verification of a Concept, when a concept is good enough is because there is a minimum check of validation(is needed, desirability), and verification (feasibility) | 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 of validation, in the sense that you check to some extent if is needed, not if is feasible in detail. Validation/Verification of a Concept, when a concept is good enough is because there is a minimum check of validation(is needed, desirability), and verification (feasibility) | ||
Revision as of 02:02, 26 September 2019
The Design Concept is the first step of implementing the machine Requirement into an actual design.
The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.
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.
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 of validation, in the sense that you check to some extent if is needed, not if is feasible in detail. Validation/Verification of a Concept, when a concept is good enough is because there is a minimum check of validation(is needed, desirability), and verification (feasibility)
Protocol
A concept should be in the form of a cloud, collaboratively editable document such as a google doc which allows various parts of a design to be detailed.
- To write a concept, start a google doc based on the Google Slides Template - click edit below the template to get to the viewable document, and make a copy of the document
- Include Design Rationale information for as many aspects of the design as possible. The Design Rationale should frequently refer to OSE Specifications as the basis.
- Name that document Machine_Name_Concept. See Taxonomy for information on naming projects.
- Embed in wiki, in a page named Machine_Name_Concept. If there is a naming conflict, add some more words to your title, such as Machine_Name_Version#_Concept.