A feature for which a data structure similar to that of Table 1 can be populated. If we put enough technical features together for a single dingus we can start building models.
As noted in the table comments, at least two general forms exist1, both of which might be in simultaneous use on the same project.
This perspective can lead to significant additional insight, but can be quite the rat hole if executed with too much formality for too many trivial features.
Table 1 Data Elements of a Technical Feature
|
Element |
Guidance |
Comments |
|||
| Topic
|
Persistent from one version to the next. Always required. Often the name of the attribute being specified, but also often heavily modified to distinguish between similar topics. Can be a pointer. | Persistence allows SE to keep track across generations of measures and values. As described in the Topical Analysis and Parameterization pages, this element is pointed to by the associated parameter or value. | |||
| Allocation Target(s) | Always required. The dingus being described by the characteristic or, in the case of an non-unilateral interface characteristic, a list of dingae. Can be a pointer. | Permits extraction and summarization of technical characteristics by Allocation Target. As described in the Topical Analysis and Parameterization pages, this element is pointed to by the associated parameter or value. | |||
| Parameter | A quantification of the topic. Can be a pointer. | Some interpretations of “characteristic” treat it as concrete (that is, a value rather than merely identifying a parameter), in which case the parameter is accessed through the value (so might, therefore, be omitted from this table). | |||
| Measure(s) | The approved means by which values for this characteristic are produced. Always required. Can be a pointer. | As described in the Topical Analysis and Parameterization pages, this element is pointed to by the associated parameter or value. Note that different measure can serve different purposes, and one or more of the measures might be a Verification Measure if serving to provide evidence for a claimed feature. | |||
| Value | A region in the space defined by the parameter. The region can be closed, open, or semi-open in any combination for the degrees of freedom in the parameter. |
See Upon Evaluation. The value can legitimately be represented in either the implicit or explicit form. Some interpretations of “characteristic” will treat it as an abstract concept, in which case this element is omitted. |
|||
This definition does not contend that Table 1 is the only structure suitable for the concept to be useful. Other aggregations of data that can be reached from the items listed might be useful, depending on the specific context of operation. Note that, if the data are stored in a Relational paradigm, Table 1 might be the result of a query rather than the natural storage form.
Contrast with Characteristic, Technical Characteristic, Requirement, and Technical Requirement.
Footnotes- Those being “implicit” and “explicit”.[↩]