Feature

A discernible element of form, fit, or function in the dingus.

The best features are those dreamed up by the designers that can make our designs better¹ than those of our competitors, even if the customers didn’t think of asking for them yet.  Contrast that outcome with the idea of Bill It As A Feature, which entails risk of the opposite.

 *  *  *  *  *   *  *  *  *  *   *  *  *  *  *   *  *  *  *  *

The idea of a “feature” is central to both the description and prescription of the dingus.  The naming convention is refined for specific usage:

A Feature might, or might not, be considered “essential” to the nature of the dingus; that is, a characteristic feature thereof ².  See also Characteristic for further development of that notion.

A Characteristic Feature might, or might not, be considered contractually³ obligated for the dingus; that is, a required feature thereof⁴.  See also Requirement for further development of that notion.

To be of consistent, practical use to Engineers, any Feature⁵ can be described in structured form.  I use the word “technical” to distinguish those from the vernacular usage because that is the form explicitly revealing the information to which we Engineers apply our technical skills.  See Technical Feature, Technical Characteristic, and Technical Requirement, which identify minimum data elements for each refinement.  See also Measure (3), which wraps these concepts with additional information about how values are acceptably generated for the feature properties.

Any of the three technical flavors of feature can be further described by identifying one or more topics, which are further described through parameterization of properties.  Types of topics include, for example, functions, physical characteristics and reliability characteristics.

Having all these layers of abstraction might seem pedantic.  I evolved to this position over a long period of time for two basic reasons:

(1) The layers facilitate the assimilation of tasks that are often considered to be out of scope to System Engineering.  Without them, we usually try to force those tasks into a more limited paradigm, or ignore them altogether.  Such practices include, but are not limited to, the use of Procurement Control Drawings, Selected Item Drawings, Altered Item Drawings, Source Control Drawings, re-use, commonality, and re-development.  In all cases, we can discern and define features for promotion up and down the layers without loss of either generality or specificity.

(2) I found that difficulty in populating those data structures usually indicates that we don’t really understand the problem very well⁶.

Footnotes

1.   Including, but not limited to, more cost effective.[↩]
2.   The concept is sometimes referred to as “identifying”; see Design-to Requirement.[↩]
3.   Or legally[↩]
4.   And, because it is required, it is also characteristic.[↩]
5.   Including those that are characteristic, and those that are required.[↩]
6.   The converse is not as strongly indicative: it turns out there is no magic bullet.[↩]