Updating Topical Parameterization

As previously discussed (six months ago!), I’ve made a pass through the material in order to ensure a reasonable consistency in how the word “characteristic” is used.  Naturally, that turned out to be more work than I thought it would be1.

I’ve tweaked many pages and a few definitions to clarify concepts about describing systems and components:

– A revision to what I think I know about features simplifies the definition, and contains a very brief overview of core concepts for many of the the changes in this revision with many links to derivative concepts.  The definition more rigorously defines the distinctions drawn by successive specialization of terms (and concepts).

– Derivative pages include those for characteristic and requirement, along with the “technical” counterparts (Technical Feature, Technical Characteristic, and Technical Requirement).  In all cases, the specifics of prosaic expression2 are of less interest than the formulation of technical content.  As Musashi almost used to say: give careful thought to this, because it will make things go much better down the road3.

– New material regarding Topical Parameterization (Parts I, II, and III) discusses the rationale and core concepts of assigning parameters to topics up to, and including, the notion that System Engineers should associate parameters with the algorithms used to develop values for them.

– Definitions for associated things I think I know are also established for concepts of Measure, including the special case of Verification Measure.  A nuance on the use of “measure” with regard to Performance is also addressed here.

More to come.

Footnotes
  1.   Over 10,000 words in all.[]
  2.   e.g., the text of a requirement[]
  3.   See Go Rin no Sho.  Naturally, I’ve taken some liberties of phraseology.[]