Loading...
 
Services offered by Tom & Kai Gilb

Planguage Concept Glossary

Owner: Tom Gilb © 1996-9, 2000, 2001, 2002, 2003, 2004, 2005, 2006.

Email comments: Tom@Gilb.com

Abbreviation Concept *454 August 6 2001

A Planguage parameter meaning ‘abbreviation’.

Type: Planguage parameter.

Synonym: Abbr.

Absolute Specification Concept *509 March 4, 2003 C

An absolute specification of a term can be understood fully without reference to other definitions .

Notes:

1. It would be for example a number (3.14), a number, a date (Jan 1), a standard code (‘NY’ or ‘GB’), or a proper name (‘San Francisco’), rather than a Planguage term, a Project Language term, or a user-defined term.

Related Concepts [Absolute Specification *509]:

  • Planguage Term *211: A term defined by Planguage.
  • Project Language *247: A Planguage-variant term defined by a project.
  • User-Defined Term *530

Type [Absolute Specification *509]: Specification.

Acceptable Range *545 May 29, 2003

This is a performance or cost range that the stakeholder will tolerate, or find acceptable. This does not mean that they are happy or that the system is successful.

  • •••••••••••[!!!!!!!!!!======>______>O•••••••••••••[!!!!!!!!!!======>______>

  • •• is a catastrophe range. [ is a lower survival level. !!!!! is a Failure Range.

==== is an acceptable range. >is a Goal level. _____ is a success range.

Notes:

Synonyms [Acceptable Range, *545]

Related Concepts [Acceptable Range, *545]

  • Range *55
  • Failure Range *546 not an acceptable range
  • Catastrophe Range *603 not an acceptable range
  • Success Range *548 better than just ‘acceptable’ range
  • Acceptable Level *613 any numeric level in the acceptable range.

Type [Acceptable Range, *545]: scalar concept.

Acceptable Level *613 March 3, 2003

Any numeric level in the acceptable range.

The acceptable range extends from just below a Goal level and until a constraint level is reached, if any.

This is a ‘not success’ and ‘not failure or catastrophe’ level. Tolerable.

Acquisition Concept *356 March 8, 2003

Acquisition is the activity of obtaining a component. Acquisition is part of the Development Cycle.

Notes:

1. The intended use of ‘acquisition’ in a systems engineering context, is the acquiring of system components. The components can be anything intended to help reach results. Acquisition can include any process necessary to reach the required system state for a component such as {bidding, request for proposals, negotiation, contracting, paying, financing, testing, getting approvals, quality control, building, maintenance}.

For example: acquired components can include: {equipment, permissions, tools, methods, advice, expertise}.

Examples of use of term in context: ‘architecture acquisition’, ‘step acquisition’, ‘step acquisition costs’.

Related Concepts [Acquisition *356]:

Type [Acquisition *356]: Process.

Act [PDSA] Concept *172 June 4, 2003

Act [PDSA] is part of the Plan Do Study Act Cycle. The ‘Act’ phase decides on what course of action should be taken based on the information supplied by the ‘Study’ phase. It is to standardize the process at a new level or, to draw new conclusions about our original theory or, to determine and select new theories (to design or modify processes).

“to standardize, conclude and theorize”

W. E. Deming [Personal Communication 1991]

Notes:

1. In Evo, ‘Act’means reviewing the Evo plan, determining the gap priorities, finding alternative steps and, deciding on the next step from the various alternatives. If the results of the last step are not satisfactory, a course of action to correct it might be decided upon.

Related Concepts [Act [PDSA] *172]:

  • Plan Do Study Act Cycle *168
  • Plan [PDSA] *169
  • Do [PDSA] *170
  • Study [PDSA] *171
  • Evolutionary Project Management *355
  • Statistical Process Control (SPC) *466

Keyed Icon [Act [PDSA] *172]: There is no keyed icon for Act [PDSA].

Drawn Icon [Act [PDSA] *172]: Act is the south side of the rectangular process symbol.

The four corners of the process drawn icon stand for the Shewhart process-cycle definition of ‘Plan, Do, Study, Act’.

Type [Act [PDSA] *172]: Process.

Act. (Noun) Concept *278 . January 23, 2002

An ‘act’ is a process of doing something, by means of humans or other Agents.

Note: This definition is to help us distinguish between the PDSA ‘Act’ defined above ( *172) and this conventional use of the word.

Related Concepts Act (noun) *278:

Not to be confused with

Act *278 (part of PDSA cycle)

  • Process *113. Process is the set of Entry Process, Task and Exit process, and is formally defined or definable. All formal processes contain tasks. A task alone is not a formal defined process.
  • Task: *149 . A task is the work done when executing a defined procedure

Synonym: action

Type: general systems concept

Action: Concept *538 . March 30 2002

Action is a specification parameter which describes an action to be taken under defined circumstances.

Type: Activity specification

Keyed Icon [Action, *538] ^[<action specification or tag>]. Same as Process.

Example:

Minimum [EU, Children] 15 degrees C, Action [Close School].

_ [EU, Children] 15 degrees C, ^ [Close School].

Parameter: Action

Related Concepts:

*Act *278

Actual Step Content. Concept *369 January 3, 2003

The design ideas, modified by [actual qualifiers] and functionality modified by [actual qualifiers], which are actually delivered in a specific Evo step.

Rationale: we needed a concept to distinguish between plans and reality.

Note: The planned step content is detailed in the step specification. The actual step content must be observed, logged and measured.

Related Concept [Step Content *369]: Step *141.

Type: analytical tool

Adaptive (adjective). Concept *563 . July 2, 2002

‘Adaptive’ refers to the set of concepts which are interesting in relation to changing a system from one defined state to another. This can be while a system is in operation (user changes operational parameters). It can refer to system modification such as porting, extending, improving, correcting.

Add, Concept *643 ‘-’ November 18, 2003

Replace is a Planguage verb indicating the addition of some specification to a defined set of specifications.

Keyed Icon [Add *643] ‘+‘ in context referring to a defined set of specs.

Related Concepts [Remove *642]

Type: Planguage Grammar

After Concept *313 February 12, 2003

‘After’ is a parameter used to indicate a planned sequencing of events, including Evo steps and tasks.

Example:

Product Trials: Step: {F2, F1 After F2, F1 => F3}.

This means that Product Trials (a tag) is a defined Evo ‘Step consisting of step elements F2, and then F1, and then F3 in that sequence.

Keyed Icon [After *313] => and <=

The 'precedence 'arrow'

A => B means A before B and B after A

Type [After *313]: Parameter [Logical].

After Concept *313 February 6, 2003

‘After’ is a parameter used to indicate a planned sequencing of events, including Evo steps and tasks.

Example:

Product Trials : Step: { F2 , F1 After F2 , F1 => F3 }.

This means that Product Trials (a tag) is a defined Evo Step consisting of step elements F2 , and then F1 , and then F3 in that sequence.

Keyed Icon [After *313]: =>

The same icon is used for both ‘Before’ and ‘After .’ Only the positions of the related tags need be positioned correctly, <‘ Before’ event tag > => <‘ After’ event tag >.”

Type [After *313]: Logical Operator.

Agent Concept *163 May 23, 2003

Any combination of person, group, and/or machine, which carries out a defined (written) procedure, thus doing a task, which is a part of a process (other parts being entry and exit sub-processes.

Figure *163: An agent carries out a task, according to a defined procedure, which applies defined standards. This makes up the heart of a process, which consumes process input, and produces the process output.

Type [Agent *163]: Systems Engineering Concept.

Aim Concept *001 February 3, 2003

An ‘aim’ is a stated desire to achieve something by certain stakeholders. An aim is usually specified informally and non-numerically.

Example:

Our aim is to be the dominant supplier of mobile phones in China by the end of the decade.

Note the two constraining qualifiers (China, By End of the Decade) and the function area (Supplying Mobile Phones)

“It is important that an aim never be defined in terms of activity or methods. It must always relate to how life is better for everyone.” <-[DEMING93, page 52]

“The aim must include plans for the future” <- [DEMING93, page 51]

Notes:

1. When using the term ‘aim,’ the intent may be to simplify, and give the ambition level.

2. An aim is ultimately specified in the complete and detailed requirements specification.

Example:

“Our aim is to have the <best> book on <gardening>.”

“The aim precedes the organizational system and those that work in it. Workers, for example, can not be the source of the aim, for how would one know what kind of workers to choose?”

<- [DEMING93, page 52] Attributed to Deming by Carolyn Bailey

Example:

Aim [ New System X ]: Superior long term competitive edge in all market areas and product lines.

Keyed Icon [Aim *001]: @ “The same icon as Target.”

In context,O--@-->

The distinction between the ‘Aim’ and ‘Target’ concepts is the level of system and detail. ‘Aim’ is generally a higher overall concept than goal or target.

Related Concepts [Aim *001]:

Type [Aim *001]: Requirement Type, Parameter.

Alternative Designs: Concept *588

Alternative designs will have satisfactory, but different, performance and cost attributes. The alternative design idea attributes will be so significant that they do not need any other alternative design ideas in addition, or cannot afford it

Related Concepts [Alternative Designs, *588]

  • Supplementary Designs *589

Ambition: *423 February 17, 2003

‘Ambition’ is a parameter, which can be used to summarize the ambition level of a performance or budget target requirement.

Ambition must state the requirement concerned (like ‘Usability’) and it must contain a notion of the kind of level being sought (like ‘high’).

Notes:

1. The Ambition summary is useful for getting team understanding and agreement to its concept, before going on to the detailed specification work. It can then be used during development of the specification as a basis for judging the relevance of the details. The Ambition can also be updated to reflect the detailed specification better, if desired.

2. Once the specification is completed, Ambition provides a useful overview summary of the more detailed specification.

Example:

Usability :

Ambition: The system will be extremely/competitively easy to learn, and to use, for a variety of users and user cultures.

Reference: Quality Attribute Usability Paper, Version 0.2.

Serviceability :

Ambition: The PEXX System shall be extremely easy to learn to service and to service for a variety of service people.

Accessibility :

Ambition: The PEXX System shall contain and support any forms of access, which are prioritized by our stakeholders.

Security :

Ambition: Security levels for protection of the system in operation, and under a variety of threats (intrusion, corruption, and destruction) shall be sufficiently high to protect our customers and our vital interests. They shall also be at such a level that they are a ‘killer argument’ for using our products in general.

Adaptability :

Ambition: The system extension, modification and porting to other environments will be relatively easy and inexpensive by design of the architecture.

Examples of real disguised ambition levels drafts. These are not to be confused with the detailed specifications that follow them with Scale etc. They are not final specifications; they are the beginning of a specification process; or a summary of the specified detail.

Example:

Simplicity [ PEXX System ]:

Ambition: The system must be as simple as possible for any user to learn to use, and to use.

Impacts: {<defined strategic requirements>, for example Machine Utilization }.

Impacted by: {<a set of Designs which impact this Requirement>, for example ‘ Look&Feel ’, Multi-Lingual }.

Type: Quality Requirement.

Stakeholders: { Operator , Supervisor , Instructor , Manual Writer , Production Planner , Salesperson , …}.

Scale: The number of distinct work Operations a defined [ User ] must do, in order to accomplish a defined [ Task ]

Test: Test sets for defined [ Operations] using defined [ Users] , are observed electronically and measured and compared.

========== Benchmarks ======= Analytical background ======

Past [ FCXX II , User = Novice Operator , Task = Status Inquiry ]: 23±5 <-Estimate by Jan .

Record: 0.

Trend: ?

=========== Targets === real requirements =========

Wish [<Qualify when, where, if>]: 0. “On the defined Scale, always”

Goal [ FXXXX + PEXX System , User = Novice Operator , Task = Status Inquiry , Release 2.0 , If TopaXX is installed at this site]: 10 Operations , [ Task = Change Date ]: 5.

Stretch: 4.

=========== Constraints ========================

Fail: 5.

============= Other possible options =============

Risk: The Operator is not trained properly.

Assumption: The User Manual is accessible and updated and will be used.

Basis: No known basis for this is identified <-TG.

Design : < some info about expected designs but NOT a required one>.

Owner : Jan V.

Version: 0.1

This is an example of an Ambition statement, together with a full real draft requirement. It is not perfect, but it is real, with some XX to retain confidentiality.

Keyed Icon [Ambition *003]: @.∑ “Target and Summary.”

Type [Ambition *003]: Parameter [Scalar].

And Concept *045 February 5, 2003

‘And’ is used as a logical operator to join any two expressions within a statement.

Examples:

Goal [If War and Inflation]: 60%.

Goal [If Peace And Inflation]: 60%.

Goal [If War AND Stability]: 60%.

Goal [If War & Peace]: 60%.

To make a statement read better, the lead capital letter can be dropped, giving ‘and’ rather than ‘And’.

Keyed Icon [And *045]: &

Type [And *045]: Logical Operator.

Architecture (collective noun): Concept *192 . January 7, 2004

The ‘architecture’ is the set of entities that

  • in fact exist and impact a set of system attributes directly,
  • or indirectly, by
  • constraining, or influencing, related engineering decisions.

Notes:

Interesting specializations:

  • Perceivable Architecture: the architecture which is somehow directly or indirectly perceivable in a real system, as determining the range of performance and cost attributes possible. This applies regardless of who, if anyone, consciously specified the architecture design artifacts.

  • Inherited Architecture: architecture which was not consciously selected at a particular level of architecture activity, but was either:

  • Specified Architecture: the formally defined architecture specifications at a given level and lifecycle point, including stakeholder requirements interpretation, architecture specification, engineering specification done by this architecture level, certification criteria, cost estimates, models, prototypes, and any other artifact produced as a necessary consequence of fulfilling the architecting responsibility.

Note: an extensive discussion of the architecture concept is given in Maier02, including a special appendix on the history of attempts to define a standard in DoD, IEEE, INCOSE. Appendix C pp283-9. In addition the book gives a great many other insights into the nature of the concept.

Note:

The highest specified level of design ideas for a defined system is called the ‘architecture’. The architecture is the collection of controlling design ideas for a defined purpose. The architecture refers primarily to frameworks, interfaces and other technology and organizational ideas which more-detailed design ideas are expected to fit in to.

Notes:

1. The architecture specifications ( *617) would probably be classified as generic design constraints (or ‘architecture constraints’, if you wanted to emphasize the idea of ‘architecture’).

2. Architecture specifications would have priority over subsequent design decisions, made at more-specialized engineering levels.

3. ‘Architecture specifciation’ is the set of system-wide decisions, which are made in order to improve the systems survival ability, as it is threatened by changes to it, and by its environment.

Architecture: A high level design that provides decisions about:

purpose (What problem(s) that the product(s) will solve)

function description(s) (Why has it been decomposed into these

components?)

relationships between components (How do components relate in

space and time?)

dynamic interplay description (How is control passed between and

among components?)

flows (How does data or in-process product flow in space and

time?)

resources (What resources are consumed where, in the process or

system?).

Source: Standard: FAA-iCMM Appraisal Method Version 1.0 A-19, INCOSE Conference CD, June 1999, Brighton UK [FAA98 ]

This definition differs from Planguage in that we are primarily concerned with design aspects, and this contains three requirement notions.

architecture The organizational structure of a system or component.

Source: [IEEE 90 ] in [SEI-95-MM-003 ]

Standard: An example of an IEEE definition of ‘architecture’.

.

Domain: systems engineering.specification.design.architecture

Related Concepts [Architecture, *193 collective noun]:

Design (noun) *047

Design specification ( *586, or *047 + *137)

Design Ideas *047

Architecture (the process) *499

Architecture Specification, *617

Artifact *645

Keyed Icon *193 Architecture: (delta, symbol pyramid architecture)

Note keyed and drawn icon for design ( a subset of architecture is a rectangle (or [ Design X ] )which is analogous to the blocks used to make the pyramid)

Type: engineering specification type

Architecture Engineering Concept *499 May 29, 2003

The architecture engineering process puts in place the systems architecture, which is a controlling mechanism for the design engineering of any project.

Architecture engineering defines the strategic framework (the systems architecture), which design engineering has to work within. It lays down the standards, which control such matters as the tradeoff processes amongst requirements. It helps synchronize design engineering disciplines across different systems.

The architecture engineering process is a subset of the Systems Engineering process.

Notes:

1. The architecture engineering process is distinct from the larger systems engineering process in that it is focused on design issues. (Systems engineering is broader. It includes consideration of the requirements, quality control, project management, and any other discipline, that is useful for satisfying requirements.)

2. The architecture engineering process is distinct from the other system level design engineering processes because it operates at a higher level, and is therefore concerned with wider issues. It has to consider the overall strategic framework, and provide guidance to all the lower-level systems.

The architecture engineering process considers especially the long-term objectives, and the totality of the requirements for all systems.

3. The architecture engineering process is, ideally, technologically neutral. It should provide guidance on design, using any relevant technology, policy, motivation, organizational idea, contractual agreement, sales practice and other devices. One of the main criteria is that the architecture is cost-effective.

Technological neutrality is not always achieved! For example, promotion of the use of standard platforms could be included within a systems architecture; and while that is an architectural decision, it is not technologically neutral.

Synonyms [Architecture Engineering *499]:

Related Concepts [Architecture Engineering *499]:

  • Systems Architecture *564
  • Requirement Engineering *614
  • Design Engineering *501
  • Architecture Specification *617

Type [Architecture Engineering *499]: Process.

Architectural Description [IEEE] Concept *618 July 18, 2003

Architectural description is “a collection of products to document an architecture.”

(This definition is identical with IEEE Draft Standard 1471, December 1999)

This concept is generic and can apply to any specific architecture type.

Notes:

1. The intentionally broad term ‘products’ is used to include anything, which might be useful in describing an architecture. Anything can include physical models, computerized models, prototypes, blueprints, parts lists, planned test results, actual input and outputs from tests, Planguage architecture specifications, sales and training materials, and real systems – as long as their purpose is to document an architecture.

2. The term ‘Architecture Description’ is an IEEE term, it is NOT used in the Planguage sense of a ‘Description’ parameter: it should really be equated to the Planguage term, ‘Definition.’)

Related Concepts [Architectural Description *618]:

  • Architecture Specification *617: This concept does not include models and real systems, but only abstract specifications
  • Systems Architecture *564: An architecture description can be for any specialized subset of a systems architecture, such as software or hydraulics.
  • Architecture (collective noun) *192: this is the real set of artifacts that the architectural description describes.

Type [Architectural Description *618]: Specification.

Architecture Specification Concept *617 June 17, 2003

An architecture specification is the written definition of an architectural component.

Notes:

1. An architecture specification either specifies a component of a systems architecture, or it specifies an architectural component of a specific system.

2. An architecture specification is a specialized form of design specification.

3. Architecture (the collective noun) is the real set of artifacts that the architecture specification describes. In other words, this is the observable architecture in a defined system. The specification may be describing desired future states of that system. Some parts of that specification might never be implemented in practice, since it serves as a vehicle to discuss architectural possibilities and options.

4. Architecture Description: This can be broader than a specification, and include models, prototypes, and real systems to aid in describing a real or projected architecture.

(Note: the term ‘Architecture Description’ is an IEEE term, it is NOT used in the Planguage sense of a ‘Description’ parameter: it should really be equated to the Planguage term, ‘Definition.’)

Synonyms [Architecture Specification *617]:

  • Architectural Specification *617

Related Terms [Architecture Specification *617]:

  • Architecture (collective noun) *192
  • Architecture Engineering *499
  • Systems Architecture *564
  • Architecture Description *618

Type [Architectural Specification *617]: Specification.

Architecture Review: Concept *596 August 15, 2002

An architecture review is a review process which looks at the entire set of engineering artifacts for a given system at a given level of process or development.

It is not limited to the design architecture, but may choose to look at requirements, the architecture of a sub-system, the software architecture, the test planning. But the point is that it looks at a complete set of specified ideas which apply to a defined system.

Fig. *596 The Architecture review is one type of content review. It can choose many review focus ideas, for example ‘End Life Disposal’, for a variety of purposes.

Related Concepts [Architecture Review, *596]

  • Specification Quality Control, *051 this just checks rules for clear specification. Is the requirement or design clear, complete, consistent and has necessary background information?
  • Specification Concept Review *542 this just checks that a single artifact is specified according to applicable Content Rules *543. Is it a good design or good requirement?

Spec *137 -> Clarity Review *607 -> Content Review *542 -> AR *596 -> next process

Artifact [Development]: Concept *583 January 8, 2004

Development artifacts are engineering information and tools such as specifications, test cases, user documentation which are not regarded as product components, but can potentially be reused to develop products and product components.

Thanks Stefan Ferber, Bosch, for suggesting this term, July 2002.

Synonym:

  • engineering concept
  • engineering artifact
  • development concept

Related Concepts [Artifact [Planguage] *227]:

Artifact [Planguage]: Concept *227 . January 8, 2004

A collective term for all Planguage {books, slides, translations, variants, dialects, and other related things}.

Implied use: a Planguage artifact.

Related Concepts [Artifact [Planguage] *227]:

Synonym: Planguage Artifact

Assertion: Concept *597 . July 24, 2002

An assertion is a statement that something is true, without necessarily backing it up with evidence or proof.

Related Concepts [Assertion, *597]

  • Impact Assertion: a design template parameter that asserts the expected impact of a design without requiring or expecting proof of the assertion.

Asset Concept *581 July 15, 2003C

An asset is a potential resource.

An asset is anything that can potentially be used by a project or a system as a source of resources. Assets are not necessarily being used, or planned used, as resources at all, but they are potentially available, if needed.

An asset for a stakeholder is not necessarily owned by that stakeholder.

Notes:

1. Some assets can give rise to resources.

Examples:

NON-REUSABLE/CONSUMABLE ASSETS WITH THEIR RESPECTIVE RESOURCES

ASSETRESOURCEA UNIT OF MEASURE FOR BOTH

(RESOURCE ATTRIBUTE) ASSET AND RESOURCE

TIME Elapsed Time Hours

WAREHOUSE STOCK Raw Materials Quantity/Day

STAFF Effort Work Hours

OFFICES Room Availability Square Meters/Day

Financial Credit/Loan/Low InterestMoney

Credibility

2. Assets can be owned and upgraded.

Examples:

'REUSABLE'/UPDATABLE ASSETS:

  • DATAFILES/DATABASES: Input Data
  • STANDARDS DOCUMENTATION: Standards
  • STAFF: Knowledge
  • OFFICES: Room Space

3. Processes can modify assets: they can create assets, and they can upgrade assets.

4. Assets can also get transformed by a process into some other thing: an upgraded asset or better performance, improved functionality, etc. For example, sell knowledge (an asset) and get financial resource.

Related Concepts [Asset *581]:

Type [Asset *581]: Design.

Assets [Product Line] Concept *581 July 13, 2002

Any general product line components or development artifacts (specs, test cases etc.) that can potentially be reused for a product are 'assets'.

COMMENT FROM STEFAN:

developing assets usually cost more money than developing just component for single use.

Therefore, you need a concept for the strategic and planned reuse.

We call an asset that is developed and planned for reuse a CORE ASSET.

Thanks to Stefan Ferber, Bosch, for suggesting this concept. July 2002.

Assignable Causes: Concept *020 .

Causes, of change in Attributes of a Process, which have a Common root Cause.

Term coined by Dr. Walter Shewhart. Preferred synonym: common causes <-Deming .

July 9, 2001

Attached Specifications. Concept *517 . April 20, 2002

Attached specifications, are directly and visibly present specification elements to one given specification.

They are not inherited or implied.

Related Concepts:

  • Local *376. Local specifications are only valid in one specification. An attached specification might, by contrast, refer to other specifications and determine or influence them (inherited specifications).

  • inherited specification attributes , *516. These are not directly or locally attached specifications, which nevertheless have the effect of being attached, because of global effect, or specified effect.

Synonyms: attached specification element, attached sub-specification.

Attribute Concept *003 February 20, 2003

An attribute is an observable characteristic of a system.

Any specific system can be described by a set of past, present and desired attributes.

There are four main categories of attributes:

  • Performance: ‘How Good the System Is’
  • Function: ‘What the System Does’
  • Resource: ‘What the System Costs’
  • Design (or Architecture): ‘The Means for delivering the System’

All attributes are qualified by Conditions, which describe the time, place and events under which the attributes exist.

Attribute: “A characteristic of an item; for example, the item’s color, size, or type.”

Source: Dictionary of Computing Terms, IEEE 630-90, 1990.

Notes:

1. Performance and resource attributes are scalar (described by a scale of measure). Function and design attributes are binary (either present or absent).

2. Attributes can be complex. They can be defined by a sub-set of elementary attributes.

3. An attribute may be described by any useful set of Planguage parameters.

Example:

Reliability :“The attribute tag name.”

Ambition: High duration of operation.“Summary of the target.”

Scale: Hours of < uninterrupted service >.“Defining the measure.”

Goal [ Next Release ]: 6,000 hours.“The required target level for the attribute.”

The tag ( Reliability ) and the parameters (Ambition, Scale and Goal) provide a systematic framework for defining and referring to a scalar attribute’s components.

Synonyms [Attribute *003]:

Related Concepts [Attribute *003]:

Keyed Icons [Attribute *003]:

There is no specific icon for ‘attribute.’ The icons for the main categories of attribute are used instead, as follows:

  • For a function attribute: O “The drawn icon is an oval.”
  • For a performance attribute: O-> “An outward pointing arrow from a function.”
  • For a resource attribute: ->O “An inwards pointing arrow to a function.”

(The Past, Record, Trend, Fail, Goal, Stretch and Wish scalar values are various points along these arrows and each have their own icon, see the relevant Glossary entries.)

For a design attribute: [ <design name> ] “The tag name of the design, underlined and enclosed in square brackets.”

Type [Attribute *003]: System Component.

Asset Concept *581 July 15, 2003B

An asset is a potential resource.

An asset is anything that can potentially be used by a project or a system as a source of resources. Assets are not necessarily being used, or planned used, as resources at all, but they are potentially available, but not necessarily ‘owned’, if needed.

Notes:

1. Some assets can give rise to resources.

Examples:

NON-REUSABLE/CONSUMABLE ASSETS WITH THEIR RESPECTIVE RESOURCES

ASSETRESOURCEA UNIT OF MEASURE FOR BOTH

(RESOURCE ATTRIBUTE) ASSET AND RESOURCE

-----------------------------===========================------------------------------------------------------

TIME Elapsed Time Hours

WAREHOUSE STOCK Raw Materials Quantity/Day

STAFF Effort Work Hours

OFFICES Room Availability Square Meters/Day

Financial Credit/Loan/Low InterestMoney

Credibility

2. Assets can be owned and upgraded.

Examples:

'REUSABLE'/UPDATABLE ASSETS:

  • DATAFILES/DATABASES: Input Data
  • STANDARDS DOCUMENTATION: Standards
  • STAFF: Knowledge
  • OFFICES: Room Space

3. Processes can modify assets: they can create assets, and they can upgrade assets.

4. Assets can also get transformed by a process into some other thing: an upgraded asset or better performance, improved functionality, etc. For example, sell knowledge (an asset) and get financial resource.

Related Concepts [Asset *581]:

Type [Asset *581]: Design.

Assets [Product Line] Concept *581 July 13, 2002

Any general product line components or development artifacts (specs, test cases etc.) that can potentially be reused for a product are 'assets'.

Thanks to Stefan Ferber, Bosch, for suggesting this concept. July 2002.

Assumption Concept *002 January 8, 2003

Assumptions are unproven conditions, which if not true at some defined point in time, would threaten something, such as the validity of a specification or the achievement of our requirements.

‘Assumption’ is a parameter that can be used to explicitly specify any assumptions made in connection with a specific statement.

Assumptions are suppositions, conjectures, and beliefs which lack verification at the time of writing, or requirements and expectations that are not within our power to control, but which have been used as part of the basis for planning future actions. We identify for each the degree of risk involved and possible consequences if the assumption is erroneous. <- Don Mills. NZ 2002. donm@softed.com

Notes:

1. We need to document our assumptions systematically in order to give warning signals about any conditions that need to be evaluated, or checked, to ensure that a specification is valid. The aim is that the assumptions will be considered at the relevant future points in time, and that anyone with any additional information concerning an assumption (including lack of specification of an assumption), will volunteer it as soon as possible.

2. The purpose of the Assumption parameter is to explicitly state ‘otherwise hidden’ or undocumented assumptions. This permits systematic risk analysis.

3. There are many different ways in Planguage to express assumptions. Alternatives to using the Assumption parameter include using the Rationale, Condition and Basis parameters.

Example:

Assumption: Cell phones will not be available in remote places. Therefore people will buy satellite phones. <- Katherine.

Example:

Hierarchic Structure [Health and Safety System]:

Type: Design Specification.

Description: A hierarchical database structure will be used.

Assumption: No negative impact on performance of Emergency and Rescue Inquiries JB.

Impacts: Access Response, Portability.

Impacted By: Available database packages.

Rationale: This structure is compatible with the current structure, and can be directly converted to it.

Condition: Off-the-shelf software can be used, and no in-house support is needed.

Basis: Health and Safety System required by National Law.

4. It would be good practice to specify the consequences of a failure for the assumption to be true. Use Impacts, Supports and similar parameters just below the Assumption statement. See above example.

5. It would be good practice to specify the things that determine if this assumption is going to be true. Use Depends On, Authority, Source, Impacted By and similar parameters just below the Assumption statement. See above example.

Related Concepts [Assumption *002]:

Type: Parameter, Risk analysis concept.

Attribute Level Icon Point :( Concept *252 )

July 9, 2001

This is the exact point in space, in a diagram, which represents a given attribute level.

Related Concept: Generic Attribute Level Icon: (Concept *251)

Type: graphic icon concept

Notes:

Example:

O---- |<-- >>|-------->

The Past level (<-) and the Fail limit (->>) are embellished with the Generic Attribute Level Icon (--|--), in order to emphasize the idea of the exact level, graphically.

3. The icon can also be used to represent an attribute level reached by a design idea.

Example:

Figure:

Example of use of generic attribute icons. The left-most ‘|’ icon is the symbolic exact ‘0% of impact’ Past point, our chosen Benchmark. The arrow symbol is itself a bit vague as to borders, even though Planguage specifies the tip of the arrow as the precise border. The ’|’ icon between Design A and Design B symbolizes the extent of impact of Design A on this attribute. The next ‘|’ is the extent of Design B impact. The final ‘|’ is the exact extent of a Goal requirement (our chosen Target), ‘100%’ in Impact Estimation terms. It helps symbolize that an ‘unknown design’ might contribute more than the Goal level requirement for this attribute.

Author Concept *004 Nov 12, 2003

An author is the person, who writes or updates a document or specification of any kind.

Note:

This is a generic term, which depending on the specific document type, is usually replaced by specific roles, such as {engineer, architect, manager, technician, analyst, designer, coder, test planner, specification writer}.

Synonyms [Author *004]:

Related Concepts [Author *004]:

Type [Author *004]: Role.

Authority Concept *005 January 8, 2003

Authority is a specific level of power to ‘decide’ or ‘influence’ or ‘enforce’ a specific matter requiring some degree of judgment or evaluation. For example, the status of a specification is usually the responsibility of some ‘authority’ (some set of individuals holding the specific authority).

Authority is held by a specified individual or by an organizational group. A specific role may hold the authority. In addition, a document that is authorized can be used, within the document’s scope, as a source of authoritative information (in lieu of access to the people holding the authority).

An Authority parameter is used to indicate the specific level of authority, approval, commitment, sanction, or support for a specified idea, specification or statement.

Note: This is not the same as ‘Source’, which is the written or oral source of information. A Source might convey no authority whatsoever (for example, “ 60% My best guess!”).

Example:

Past [Last Year]: 60% Marketing Report [February, This Year].

Authority: Marketing Director [Tim].

Type: Parameter, Risk Analysis, Priority.

Background Concept *507 May 26, 2003 C

Background information is the part of a specification, which is useful related information, but is not central (core) to the implementation, nor is it commentary.

Example:

In a requirement specification, the benchmarks (Past, Trend, Record) are not the actual requirements (not ‘core’), but they are useful ‘background’ to the requirements.

The requirement targets (Goal levels) and constraints (Fail and Survival levels) are central (core) to implementation, and are therefore not background.

Notes:

1. Parameters are clearly typed as either ’core’ (for example, Scale, Meter and Goal) or ‘background’ (for example, Ambition, Gist and Past), or ‘commentary’ (for example, Source and Note).

2. Background specifications are essential to the understanding and use of a specification. However, any defects in background will not necessarily materially and/or negatively impact the real system. Such defects might potentially have bad impacts when used in a certain way. For example, when a Goal (core specification) is set on the basis of an incorrect Past or Record (background specification) the resulting Goal level (a ‘core’ specification) will be incorrect.

Specification defects in ‘background specification’ are either major or minor. depending on our judgment, in the specific context, of the potential consequences.

Examples:

Background parameters include:

  • Benchmarks {Past, Record, Trend}
  • Owner
  • Version
  • Stakeholders
  • Gist
  • Ambition

Related Concepts [Background *507]:

Type [Background *507]: Specification.

Backroom Concept *342 June 4, 2003

Backroom is an adjective or noun, referring to a conceptual place, used to describe any processes or activities in Evo that are not necessarily visible to the Evo step recipients.

Notes:

1. Typically, Backroom is used to refer to the development and production cycles of the Evo result cycle.

2. This is where concurrent engineering takes place. Backroom activities (for example, detailed design, purchasing, construction and testing) may have to be carried out in parallel with other activities as step preparation (prior to being ready for delivery), can take arbitrary lengths of time. The overriding Evo requirement is for frequent stakeholder delivery cycles.

3. Evo project management needs to manage the backroom and frontroom as one synchronized process.

Related Concepts [Backroom *342]:

Type [Backroom *342]: Adjective, Noun.

Baseline Concept *351 January 19, 2003 B

A Baseline is a stable well-defined benchmark set (one or more system attributes) that serve as a comparison for system change.

A system baseline is any set of system attribute specifications that formally define the state of a system, under specified conditions.

An attribute baseline is a single benchmark that has been chosen to compare any system change against (estimated or actual).

Example [System Baseline]

EU Base: Baseline [Europe, 2003]

{Performance Attributes [EU, 2003], Functions [EU, 2003]}.

This baseline is specified without reference to costs.

Note: Within Impact Estimation, for each scalar attribute a ‘Baseline to Target Pair’ is declared. The chosen baseline is usually a Past level and represents zero percentage impact (0%). In an IE table, each baseline to target pair appears immediately under the tag of its attribute on the left hand side on the table.

Examples:

QX:

Type: Quality.

Scale: Time to complete a defined [Task] for a defined [Person Type].

Baseline [Our Competitor’s Product]:

Past [Task = Learn to Drive Off, Person Type = Experienced Driver]: 1 minute.

Target [Our New Product]:

Goal [Task = Learn to Drive Off, Person Type = Experienced Driver]: 10 sec.

This example shows setting an attribute baseline and a target for a quality, QX.

ABC: IE Table [Baseline Date =Nov 7, Target Date =Dec 7].

QX :

BABC: Baseline [ABC]: Past [……. “declare as a baseline for ABC IE table”].

TABC: Target [ABC]: Goal [……”declare as a target for ABC IE table”].

Baseline to Target Pair [ABC]: 1 minute <-> 10 seconds. “deduced from baseline and target declarations above. Strictly not needed as repetition.”

This example shows an alternative way to set a baseline and target. It introduces the idea of declaring a Baseline Date and Target Date applying across an IE Table.

ABC: IE Table:

Design ‘ADI’ has zero percentage impact, meaning that if Design ‘ADI’ were implemented then there would be no visible change in the quality level (it would remain at one minute and there would be no forward progress from the baseline (1 minute) towards the target (10 seconds)).

Design ‘CDI’ would be even worse than the baseline; that is the quality level would be worse than the attribute baseline.

Keyed Icons:

[Baseline *351] {<<<} “set of benchmarks”.

[Scalar Attribute Baseline]: 0%

Note: A baseline is a benchmark, or set of benchmarks. But if referring to a scalar attribute baseline, then ‘0%’ is more explicit.

However, for ‘[Baseline to Target] *200]’ pair, the keyed icon is ‘<->’.”

[System Baseline *145 + *351] {<<<} [System XYZ]: ….

Meaning ‘baseline for a defined system’. Using the qualifier to define ‘which’ system.

[Benchmark *007] <<< (related icon).

Related Concept [Baseline *351]:

Type [Baseline *351]: Parameter [Scalar, Relationship], Benchmark

Domain [Baseline *351]: Impact Estimation, Evolutionary Project Management.

Baseline to Target Pair Concept *220 February 11, 2003

In Impact Estimation, this is a set of two levels (two numeric values) associated with a specific requirement under stated conditions: the Scale value for the benchmark reference point (0%) and the Scale value for the target (100%).

Notes:

1. For example, a baseline to target pair, ‘30<->66’ gives the numeric values for the real Scale benchmark (on the left hand side of the icon) and the target (on the right hand side). These values are used to compute the percentage numbers.

2. A baseline to target pair is usually used, without qualifiers in an IE table, as a form of abbreviated documentation of a requirement’s levels. However, the qualifiers in the requirement specification are actually implied, and if necessary should be explicitly stated for unambiguous documentation. The point is that the 100% impact value is only obtained when the target level is reached on time, and with regard to all the other specified conditions.

Keyed Icon [Baseline to Target Pair *220]: <->

Type [Baseline to Target Pair *200]: Metric.

Basic Planguage: Concept *225 May 19, 2003

Basic Planguage is the original specification of Planguage, as in this book or as updated and expanded on our website, . It is a version of English (USA spelling format) Planguage material ready for translations to variants and subsets.

Notes:

1. ‘Planguage’ itself varies depending on local variations based on ‘Basic Planguage.’

2. There is, as yet, no complete concept of standard or standardized Basic Planguage. So users should state the defined version of Basic Planguage that they are referencing. For example, Basic Planguage [Web version, 3.1, January 2005]! The updated website copy is the master version.

Synonym: Planguage Generics *225

Type: Planguage classification.

Basis Concept *006 January 9, 2003

A basis is an underlying idea that is a foundation for a specification.

A ‘Basis’ parameter is used to specify a foundation idea, so that it is stated explicitly, and can be understood and checked. Hopefully, if necessary, a Basis specification will be challenged and corrected. It is a tool for risk analysis.

Notes:

1. Basis statements are used to declare a set of conditions, which we assume will be true. We want to make it quite clear that the related statements are entirely contingent upon the conditions being true.

A Basis statement is, or will be, for the appropriate qualifier time, place and other conditions, fundamental and stable. We state a Basis in case it is untrue, or is a misunderstanding, or needs improvement in specification: the intended readership needs to check whether they agree that a Basis statement applies. In addition, we state a Basis to ensure that the conditions are checked later, at the relevant time.

2. Basis is different from Assumption. An Assumption is a set of statements, which we expect be true in the planning horizon (for example, the dates indicated in Goal and Fail parameters), but we cannot be sure; they can well change. The related specification may need updating if they do.

3. Basis is quite different from Rationale. A Rationale is a set of statements, which lead to a desire to make a specific specification. It explains how we got to that particular specification. Basis is a set of statements, which are the foundation on which a specification is made. If the result of evaluation of any of the relevant Basis statements changes, then the specification may no longer be valid.

Example:

Fail [A1]: 60%, [Not A1]: 50%? <- Guess as to consequence.

A1: Assumption: Drugs Law [Last Year] is still in force and unchanged with respect to this plan.

Basis: Drugs Law ‘Conditions for Approval for Human Trials’<- Pharmaceutical Law [Last Year].

Rationale: Our Corporate Policy about following laws, strictly and honestly <- Corporate Ethics Policy.

Condition: Applies only to <adult, voluntary, healthy, field-trial people>.

‘A1’ is a defined assumption that can be reused in this or other contexts.

Synonym: Base *006.

Type: Parameter, risk analysis.

Before Concept *312 February 5, 2003

‘Before’ is a parameter used to indicate planned sequencing of events, including Evo steps and tasks.

Example:

Stage Liftoff: Step: {Ignition On Before Check Thrust OK, Ignite Motors} => Release Tie Down}.

The Evo step is planned as a sequence of step elements. Ignition On is to be done first. Followed by Check Thrust OK. Ignite Motors can be done anytime in relation to the first two, but, since it is in the brackets, it, as well as the other two events in the brackets, must be done before Release Tie. The use of the => icon or the term ‘Before’ is a matter of taste; and both are used here for illustrative purposes.

Keyed Icon [Before *312]: =>

Note: The same icon is used for both Before and After. Only the positions of the related tags need be positioned correctly, <’Before’ event Tag> => <’After’ event Tag>.

Type [Before *312]: Logical Operator.

Benchmark Concept *007 February 20, 2003 22:51

A benchmark is a specified reference point, or baseline. There are two main types: scalar and binary benchmarks.

Notes:

1. A scalar benchmark is a reference level for a performance or resource attribute. It is usually used for comparison purposes in requirement specification, design and implementation.

2. A scalar benchmark is normally defined using the benchmark parameters {Past, Record, Trend}.

Example:

Usability :

Ambition: Order of magnitude better than future competitors.

Scale: Average time needed to learn to do Typical Tasks for Typical User .

Trend [ Best Competitors , During New Product Lifetime , Europe Market & USA Market ]: 5 minutes.

Fail [ New Product , All Markets ]: 2 minutes.

Goal [ New Product , Initial Release ]: 1 minute.

Goal [ New Product , 1 Year After Initial Release ]: 30 seconds.

‘Trend’ is the benchmark specification.

3. Function and design attributes are specified as binary benchmarks: binary attributes are either present or absent in a system.

Related Concepts [Benchmark *007]:

Type [Benchmark *007]: Specification Type.

Benchmark Cost: Concept *505 . March 16, 2003

A benchmark cost is an expenditure of resource that has been determined by some means for purposes of comparison and analysis.

Benchmark costs are specified using the benchmark level parameters Past, Record and Trend.

Benchmark costs are determined by observation, measurement, estimation, guessing, asking, analysis, approximation, testing, or any other cost-effective means for our purposes.

Synonym:

Type: …..

Benefit Concept *009 June 4, 2003

Benefit is value delivered to stakeholders.

Notes:

1. Benefits are the positive things that the stakeholders experience from a system. ‘Bene’ means ‘good’.

2. Benefit differs from stakeholder value. Value is perceived future benefit. Value is reflected in what priority, and consequent resources, people are willing to give for something, in order to get the benefits they expect.

3. Benefit is the reality experienced in practice by defined stakeholders.

4. Benefits can include improved stakeholder environment performance, reduced costs, and improved functionality.

5. Benefits could also include the relaxation of previous constraints.

6. Systems engineering control can only be exercised over benefits, which have been specified as requirements. Reaching and keeping an unspecified benefit is unlikely!

7. Systems engineering can add value, it is up to the stakeholders to actually turn that value into benefit by exploiting the system.

8. One way to measure improvements in benefit is to extrapolate from changes in performance levels.

Synonyms [Benefit *009]:

  • Gain *009
  • Profit: Informal use.
  • Advantage: Informal use.

Related Concepts [Benefit *009]:

Type [Benefit *009]: Systems Concept, Priority Data.

Binary Concept *249 May 10, 2003

Binary is an adjective used to describe objects, which are specified as observable in two states. Typically, the two states are ‘present’ or ‘absent’, or ‘compiled with’ or ‘not complied with.’

Notes:

1. All the non-scalar attributes are binary (that is, the function and design attributes).

Related Concepts [Binary *249]:

Type [Binary *249]: Adjective.

Binary Constraint. Concept *467 October 8, 2001 tgFebruary 9, 2003

A Binary Constraint is a constraint that only has two possible status conditions: complied with or not. In systems: the specified constraint is either complied with or not. There are two types known as Veto (positive constraint, do X) and Demand constraints (negative constraint, ‘do not do X’).

Type: Constraint Requirement

Related Concepts:

Keyed icon [Binary Constraint *467] [Constraint Tag] (very similar to qualifier)

Note 1. All qualifiers act as binary constraints, at least on the specification, if not the system or product itself.

Binding: Concept *584 July 13, 2002

A formal engineering decision type which constrains variability of product line artifacts or components in order to improve the potential for reuse and commonality.

Thanks Stefan Ferber for suggesting this term, July 2002.

Black Box: Concept *011 . August 31, 2001 tg

A Black Box is a conceptual interface to any system of perhaps unknown, or unknowable, internal complexity and/or construction.

A black box can be tested, or understood, by observing its external behavior. In particular, any system can be judged as to whether its requirements have been met, without necessarily understanding how they were met (i. e. which design ideas were used).

Budget, To Concept *488 December 20, 2002

‘To budget’ refers to a process to plan the allocation of limited resources to a system.

The budgeting process results in the specification of a set of target and constraint specifications for one or more resources.

Related Concept [Budget, To *488]: Budget *480.

Type: Verb.

Budget Concept *480 March 24, 2003 tg

A ‘budget’ is an allocation of a limited resource.

A ‘Budget’ parameter is used to specify a primary scalar resource target.

The implication of a Budget parameter specification is that there is, or will probably be, a commitment to stay within the Budget level (something which is not true of a Stretch or Wish resource target specification).

Example:

Maintenance Effort :

Scale: Total annual Maintenance Engineering Hours per thousand lines of software code supported.

Budget [ First Four Years Average ]: 10 hours.

Stretch [ First Four Years Average ]: 8 hours.

Wish [ First Four Years Average ]: 2 hours.

Fail [ Any Single Operational Year ]: 100 hours <- Client payment limit in contract §6.7.

A Budget specification, together with 2 other resource targets and a constraint

Notes:

1. A budget level is often arrived at through a formal budgeting process: the budget levels usually being set with regard to priorities, and available financial resources. Sometimes a budget level is determined by cost estimation, or it is determined by using competitive bidding and contracting. In some cases, the budget is absolutely fixed in advance, and we have to try to keep within it by making requirement tradeoffs or by using 'design to cost'.

2. At the very least a warning signal should be noted when a budgeted level is exceeded by a design, by an evolutionary step, or when there is a risk or threat that the budget might be exceeded. For example, we need to react if a resource threat to the budget level is discovered while evaluating potential alternative designs.

Synonyms [budget (the concept) *480]:

  • Budget Level *480: See Level *337
  • Planned Budget *480
  • Plan [Resource] *480: Historic usage only
  • Planned Level [Resource] *480: Historic usage only

Related Concepts [budget (the concept) *480]:

Keyed Icon [Budget parameter *480]: >

“A single arrowhead pointing towards the future. The same icon as for Goal *109.”

In context: --->--->O

Always use an input arrow to a function oval to represent a resource attribute. The Budget icon is the ‘>’ on the arrow. If other levels for the resource are shown on the same arrow, the positioning of the tips of the icon symbols reflects the levels relative to each other.

Type [Budget/budget *480]: a Parameter [Scalar], (‘budget’ the concept) Target.

Budget Cycle Constraint: Concept *012 . July 21, 2001

A restriction regarding budget, which is related to the budget cycle process, such as when, who, how much.

Budget Target: Concept *481 . December 19, 2002

A Budget Target is a numeric resource-expenditure allocation plan. They are expressed with target levels {Budget, Wish, Stretch} .

NOTE DIAGRAM NEEDS UPDATE FOR NEW terms APRIL 16 02 TG and Aug 6 2002

Type: resource requirement.

Keyed icon [Budget Targets, *481]: --->--->+--->?---->O

Related Terms [Budget Target, *481]:

  • Target *048, a scalar level we are aiming at more or less.
  • Budget *480, a resource level requirement concept including budget targets and budget constraints
  • Performance Target *439
  • Stretch Budget *404 & *480, a type of budget target that is more ambitions than the Planned Budget.
  • Wish Budget *244 & *480. A type of Budget Target which has been noted as a ‘stakeholder desire’ or need, but is not committed (changed to a Planned Budget) with respect to achievement of all other requirements.
  • Planned Budget *109 & *480. A type of Budget Target which is agreed, formal, committed and hopefully realistic with regard to all committed requirements.
  • Budget Constraint *421, the Fail, Crash and Survival limits are used to specify budget constraints.

Synonyms [Budget Target *481]:

Bug Concept *339 November 13, 2002

A ‘bug’ is a synonym for a real system fault, which if ‘provoked’ by an agent, or by particular data, can lead a real system to malfunction.

Error/Slip Issue Defect Fault/Bug Malfunction.

The series above is the chain of events leading to malfunction.

Synonym: Fault.

Business Rules: Concept * 532. January 14, 2003

Business Rules are specifications or practices that define or constrain some aspect or principle of how a business operates or should operate, it’s ‘rules of behavior’.

Related Concepts:

Specification Rules: ( *609) these are system rules which concern only the best recommended practices for systems engineering specification.

  • System Rules, *531, the generic concept containing the sub-class business rules and specification rules.
  • Business Rule Practices. Actual practices whether they are documented or not.
  • Business Rule Specifications. Written formal specifications, analytical or planned, whether they are practiced or not.

Keyed Icon [System Rule *531, and *523, *129] : [ ] ->

Example Template: <rule tag>: [Rule Conditions> -> <rule actions>.

Example: Define Scale: [Quality Requirement] -> {Define Scale, Define Meter, Define Targets}.

Business Rules:

This usage is widespread under the name "business rules". This is documented in the work of the Business Rules Group (<http://www.businessrulesgroup.org/brghome.htm>). They say, "A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules which concern the project are atomic ~ that is, they cannot be broken down further" -- except that they can be further broken down into the type of "rule elements" that Don Mills calls CAUSES and EFFECTS.

They continue, "For our purposes, this may be viewed from two perspectives. From the business ... perspective, it pertains to any of the constraints that apply to the behavior of people in the enterprise, from restrictions on smoking to procedures for filling out a purchase order” (specification rules, *129). “From the information system ... perspective, it pertains to the facts which are recorded as data and constraints on changes to the values of those facts. That is, the concern is what data may or may not be recorded in the information system."

Source [Business Rules]<- Don Mills, NZ Feb 24 2002. Don Mills <donm@softed.com>

Case: Concept *213 . July 21, 2001

Cases are real or doctored-for-discretion (originally real) examples of practice of Planguage (this method).

They are of any size from a few lines example to a full-blown complete project documentation and background story. They are not necessarily as extensive as full case studies. They are just real instances used to illustrate the theory.

Catastrophe Concept *602 May 3, 2003

A catastrophe level of an attribute is where disaster threatens all, or part, of a system.

Catastrophe can mean a variety of things such as:

  • contractual non-payment performance level
  • illegal quality level
  • totally unacceptable level for defined stakeholders
  • a level which causes the entire system to be useless (that is, worse than the survival limit)

The Catastrophe parameter can be used to specify any such known disaster level. Using the Survival parameter is another option (These two parameters are the two sides of the same level).

Notes:

1. The default assumption is that the catastrophe is for the complete system. If it is not, then qualifiers must limit its scope.

2. If a design or architecture threatens to result in any attribute being worse than its Catastrophe Level, then you would discard the design, abandon or modify the requirement, or potentially abandon the project.

3. A catastrophe is not a transient failure – that is we do not expect the system to recover without some major intervention.

Catastrophe does not imply complete irrecoverable failure. After the event, someone might change their mind and decide to ‘bail out’ the system. But Catastrophe, once reached, is most likely to be irrecoverable in practice.

4. A Catastrophe Range starts from the ‘best’ Catastrophe Level and goes in the direction of ‘worse’. This can be made explicit by describing the Catastrophe Range, not just the Catastrophe Level (Describe the range by using ‘or less’ or ‘and worse’ after the numeric value).

Example:

Catastrophe [ System Wide ]: 60% or less.

Catastrophe [ Security ]: 60%.

Keyed Icon [Catastrophe *602]: ‘.’ “A full stop or the end on a scalar arrow icon (--->)

Example:

A series of ‘.’ indicates a Catastrophe range *603, for example:

------->--!--------]……….>O………[-----!-->----------->

The survival limit icon (square brackets on a scalar arrow icon ----[----]---->) can be used to emphasize the transition from survival status to Catastrophe (non-survival) status.

Synonyms [Catastrophe *602]:

  • Catastrophe Level *602
  • Catastrophe Limit *602
  • Catastrophic Failure: Informal use only
  • Death: Informal use only
  • Non-Survival: Informal use only

Related Concepts [Catastrophe *602]:

Historical Note: The idea for Catastrophe originated from Terje Fossnes and Cecilia Haskins in August 2002.

Type [Catastrophe *602]: Parameter, Scalar level.

Catastrophe Range Concept *603 March 3, 2003

The catastrophe range is the full numeric extent of all catastrophe levels.

It can be described by a numeric point where the range begins (Catastrophe range start) because it is assumed to continue as long as the numeric level gets ‘worse’..

Related Concepts [Catastrophe Range, *603]

  • Range *552 a defined, tagged, extent on a scale of measure
  • Catastrophe Level *602 a numeric value in a catastrophe range
  • Catastrophe Range Start *604 the exact numeric point where a Catastrophe range begins.

Synonyms [Catastrophe Range *603]:

  • catastrophic range *603
  • disaster level/range *603
  • total/absolute failure range *603

Keyed Icon [Catastrophe Range *603]

A series of 2 or more ‘•’ or ‘.' ‘•••••••’ or ‘..’ usually in context of an attribute scale (‘••••----->’) and possibly in connection with a survival limit icon (square bracket) for emphasis (‘••••[---->----]•••>O’)

Type [Catastrophe Range *603]: <Specification>.

Cell Concept *308 November 19, 2002

In an Impact Estimation table, a cell is an intersection between a requirement attribute (usually a performance or a resource/cost attribute) and a design idea.

A cell contains information about the specific impact of a design idea on a specific requirement. This information includes an impact estimate, and related data such as the uncertainty, evidence, source and credibility.

Keyed Icon *308: [] ([ and ] keyed immediately after one another)

Type: Impact Estimation concept.

Domain: Impact Estimation.

Chance Cause : Concept *019 .Chance Cause . July 21, 2001

Synonym of Special Cause ( *019).

Change Requirement Concept *243 March 25, 2003

A ‘change requirement’ represents a ‘differential’ change with reference to a defined ‘baseline’ system.

Notes:

1. Change requirements can involve any type of requirements: Function requirements, performance requirements, resource requirements, and any design or condition constraints. These are the requirements that determine the necessary changes to move a defined system to a new end state.

2. In general, change requirements are intended to represent ‘improvements.’

Keyed Icon [Change Requirement *243]: +.@ (Incremental.Target)

Related Concepts [Change Requirement *243]:

Type [Change Requirement *243]: Requirement concept.

Changing *631 February 16, 2003

Predefined State. The state is in continuous but predictable flux, not stable.

Related To:

Check, To[SQC] Concept *013 May 29, 2003

To ‘check’ a specification means to determine if it is consistent with any applicable specification rules (standards), which it should be consistent with.

Note: We check primarily against the applicable rules for a specification. The rules might refer to other documents, or to other parts within this same specific specification, which need to be used to check our specification. The rules might optionally be supported by directly rule-related checklists, which should help ensure the rules are interpreted correctly, and specifically, for the specification type.

Related Concepts [Check, To *013]:

Type [Check, To *013]: Verb.

Checker Concept *014 November 20, 2002

A checker is a person, who performs checking within Specification Quality Control (SQC). It is a defined role in the process, and the checking activity can occur in most of the SQC sub-processes, not just the predominant ‘checking’ process itself.

Checkers check specifications against rules, according to defined checking processes, looking mainly for major defects. They will also note and later report, process improvement suggestions; and report ‘questions of intent’ to the author/writer.

Related Concepts:

Type: Role.

Domain: SQC.

Checking [SQC] Concept *287 November 20, 2002

Checking is the name of a sub-process within Specification Quality Control (SQC).

Checking’ is also the name of a widespread SQC activity, (‘checking’ with a small ‘c’), which although predominantly carried out within the Checking [SQC] sub-process, is also used to some degree within all the other SQC sub-processes. Carrying out ‘checking’ is a core activity in SQC.

Notes:

1. In practice within SQC, checking consists of checking a selected specification against its source and kin documents according formal written rules of specification and consistency. These rules can be supported by checklists. The rules will also indicate which specifications need to be used to check our specific specification (example: sources, kin and other parts of our main specification). The rules used must be those either specifically agreed for production of the specification; or the standard applicable rules for this organization. The checklists used will be those needed to effectively support specific individual rules. The source documents used will be those agreed as relevant inputs for the production of the specificationn. It is the responsibility of a team leader to attempt to determine which rules, checklists, source and kin documents apply, and which shall be utilized during checking. The individual checker can supplement this plan to improve their effectiveness in finding major defects. The degree of checking planned is determined by the cost and effectiveness that is appropriate to the objectives of a particular SQC instance.

2. For peak effectiveness in finding defects, checking must be carried out at an optimum-checking rate (optimum for people’s mental speed of correlating different rules and specifications).

3. The main purpose of checking is to help the document author/writer with useful advice, and to gather data to measure the degree of conformance with specification standards (rules, defect levels specified in entry and exit conditions). There are many and varied purposes depending on the situation.

4. During the Checking [SQC] sub-process, for each cycle of checking, individual checkers typically spend up to two hours; primarily checking for major defects. Identifying potential process improvements, and noting questions of intent to the author/writer, are other activities carried out in larger checking processes.. In ‘sampling checking’, where the primary purpose is to estimate major defect density, as little as half a page might be checked and a range of 5 to 30 minutes might be used per checker. This would be sufficient to determine if the exit level was probably exceeded or not.

Related Concepts [Checking *287]

Type: Process.

Domain: SQC.

Checking Rate Concept *015 November 20, 2002

The checking rate is the average speed at which a specification is checked by a checker, using all the relevant related specifications and standards {the main specification, rules, checklists, source documents and kin documents}.

Note: The checking rate is critical for Specification Quality Control, and must normally be about 300 significant words (of checked main specification) per hour. This can vary (0.1 to 1.9 hours per 300 significant words), depending on many factors, such as the number of documents to be referenced while checking. The optimum checking rate is the checking speed that in fact works best for an individual checker to do their assigned tasks.

Related Concepts:

Type: Metric.

Domain: SQC.

Checklist Concept *016 June 4, 2003

A ‘checklist’ for SQC usually takes the form of a list of questions. All checklist questions are derived directly and explicitly from cross-referenced specification rules. Checklists are ‘stored wisdom’ aimed at helping to interpret the rules and explain their application. Checklists are used to increase effectiveness at finding major defects in a specification.

Example:

Checklist Q: Are all performance concepts (including all qualitative concepts – all ‘-ilities’) expressed quantitatively? <- Rule.STDQ.

An example of a checklist question with the rule it supports ( STDQ ) being referenced.

STDQ: Rule: All critical project requirements must always be expressed numerically and measurably.

This is the rule. The associated checklist question is designed to help people understand how to apply the rule in practice, and identify any defects breaking the rule.

Notes:

1. Checklists are like law court interpretations of the law. They are not the official ‘law’ itself, but they do help us understand the proper interpretation of the law. Anyone can write checklists at any time to give advice on how to check. They are intentionally less formal to create, and to change, than specification rules. They do not necessarily have formal ‘owners’

2. Checklists should not be used instead of a proper set of rules, which is maintained by an engineering process owner. They are only intended as a supplement for checkers. Issues can only be classified as real defects if they can be shown to violate the official agreed rules for a specification.

3. Less formal, ‘de facto checklists’ also exist. These include any documents that can be used to check a document with a view to identification of defects. These can have other names and even other purposes than a ‘pure’ checklist. Examples of ‘de facto checklists’ include ‘sources’, ‘standards’, ‘guidelines’, ‘templates’ and ‘model documents’. If they help check, they must be some sort of checklist, irrespective of what people call them or intended them to be used for.

Type [Checklist *016]: Standard.

Chunk Concept *299 November 20, 2002

A ‘chunk’ is a portion of a document being evaluated by SQC, where the intent is to continue checking other chunks after the first chunk is checked, unless the defect data from a chunk is extreme (‘too many’ or ‘zero’ defects).

Notes:

1. A checking sample may be so large that we chunk it in order to handle it in smaller units of work. This is to allow us to ‘sample the sample’ before committing either to more work, or to a specific checking plan or strategy.

2. The major reason for ‘chunking’ is that, when a realistic optimum rate of checking is applied (say 300 non-background words per checker hour), people can only handle smaller parts of a larger document in a reasonable length of time. They may get through one to six physical full pages in say 2 hours. If they try to do an entire document in this time, they may end up using checking rates of 20 pages or more per hour. This speed will reduce their defect-finding effectiveness to less than 5% and so will be a waste of time. It is much more useful to do fewer pages, achieve a higher defect-finding effectiveness (60% to 88% range) and get a deeper insight into the true defect state of the document.

3. In some cases a chunk may turn out to have functioned as a sample. For example, if a two-page chunk of a twenty-page document is checked and 20 Major defects are discovered on each page, then the first ‘chunk’ has served as a sample, to tell us that the rest of the chunks are not worth doing. (Explanation: The defect level is at least an order of magnitude worse than the quality necessary before releasing the document. There is little point in repeating this process for nine more chunks, that is, for the remainder of the document. If we assume 50% defect-finding effectiveness, the defects found represent only about half of the ones that are actually in the checked document pages The entire document must be rewritten to a much higher standard of craftsmanship.)

Type: Artifact.

Domain: SQC.

Claim: Concept *553 . May 28 2002

‘Claim’ is an assertion by a defined source, about a system attribute or an event. The Claim parameter is used to emphasize that the credibility of the claim is not high, and the reader should exercise their judgement and caution, because there is a risk that the claim might not be correct.

A scalar claim might be so vague that it is non-numeric, and is put in fuzzy brackets.

Example

Implementation Ease:

Scale: the relative speed to implement on a defined set of [Telecoms

Architecture].

Claim: <”appears to be relatively easy”> <- MJ, Paper on DISTRIBUTED FEATURE COMPOSITION: A VIRTUAL ARCHITECTURE FOR TELECOMMUNICATIONS SERVICES

Type: parameter

Domain: description of any attribute or plan.

Keyed Icon: Claim *553: ? (positioned first on a line as a parameter)

Example

? [USA, This Year]: The sky will fall <- Chicken Little.

Usage:

‘Claim’ should be used when we need to specify that some information is more of an assertion than a well-established fact. It is a signal about a risk. It can also be the first stage of developing better data and evidence, which improves the quality of the data. This could lead to upgrading the specification to another parameter (Past, Record, Trend, and others).

Claim can be used as a prefix to any other parameter, in order to emphasize the risk-filled nature of the information.

Example:

Claim: Past [UK, Last Year] 66%±20%? <- TG oral comment without evidence.

Related Concepts [Claim, *533]

Synonym: Assertion *553.

Clarity Concept *400 November 21, 2002

The specification quality of ‘being understood by a defined readership as intended by the writer’.

Notes:

1. We assume that there is a way to express an idea so that a defined readership can understand the intended idea perfectly. That means that clarity is viewed primarily as a property of the specification itself.

2. In system terms, clarity will actually be a function of the author group and their training, motivation and tools, as well as a function of the readership group and its training and tools; and finally, clarity is a function of the specification itself and its resistance to corruption and alteration in the environment it resides in.

3. In addition to the generic rule, “The specification must be clear enough to the intended readership to convey the writer’s intended message”, I have found it useful to add, “The specification must be clear enough that it is obvious how we might test for its existence”.

Type: quality attribute.

Domain: SQC.

Clarity Review Concept *607 November 21, 2002

A Clarity Review is a specification review which is primarily used to make sure the specification is clear enough to be interpreted correctly by the intended spec readership, as intended by the spec writers.

In particular, a clarity review is not initially concerned with the engineering goodness of the spec. This is left to later Specification Content Reviews. Clarity Reviews are trying to establish that a specification can be trusted because it is clear, unambiguous, correct, and complete. If so, the basis is laid for deciding if it is good engineering, good architecture and ‘good for business’ – with other analytical processes, which include Specification Content Reviews, experiments, prototypes, Evolutionary Step Delivery, competitive bidding and any other processes which determine how powerful an idea is.

A Clarity Review can be carried out using the generic Specification Quality Control process (SQC). The Rules we check against will tune into these issues. But a clarity review can be less formal – something like a friend checking quickly and declaring it to be fine for them.

Synonym *607, Clarity Review

  • Specification Intelligibility Review *607 (SIR)

Related Concepts [ *607, Clarity review]

Fig. *067 The clarity review is the class of specification reviews which has a team check against official rules about clear, complete, consistent, unambiguous specification for intended readership range.

Type: process

Domain: SQC.

Class [Qualifier]: Concept *017 .

A class is a defined qualifier term category.

Note: Some classes are predefined in Planguage like Task, Date, Time, Place, some are defined locally in a particular project. Some classes are used informally and intended to be interpreted as best we can.

Goal [Date=25 Jan2001, Place=GB] 60% “formal pre-defined classes”

Fail [25 Jan 2001, GB] 55% “implicit definition, ‘guess what class’ based on content”

Goal [division =Washers, market segment =private homes] 55% “informal definition” (no caps)

Synonyms: Term Class, classification, qualifier class, qualifier term class.

THE PLANGUAGE CLASSIFICATION PRINCIPLE:

Any thing we specify may usefully be classified in one or more of a wide variety of ways, depending on how and when it is applied. Specification ideas do not have one single classification category exclusively. This applies to all concepts in the Planguage glossary, and concepts not in the glossary. Classifications are useful because we can then access certain rules, ideas, properties and principles that apply to all things in that class. But, things are what they really are, no matter how we classify them!

For example:

A watch:

Can be viewed as a function ('Function = small time telling device): which has certain performance and cost characteristics.

The same watch, can be a design idea for improving a system of process (Use a watch rather than guessing at the time). This will give it the characteristics of watches generally ( a range of attributes which all watches have), or it will give more-specific attributes when a particular watch is chosen ( a design refinement).

The same watch could be a condition:

Goal [ If Watch] ±1 minute accuracy.

Client Concept *235 May 6, 2003 TG

A client is a person or group who has requested some defined work, system, or product, and will pay for it, directly or indirectly.

Notes:

1. Use the term ‘Client’ for clarity on this concept. The synonym term ‘Customer’ has lost some of its usual meaning, since it has been used to describe other non-paying people within an organizational chain of work processes (See Consumer *038).

Synonyms [Client *235]:

Related Concepts [Client *235]:

  • Consumer *038: Also has ‘Customer’ as a synonym.
  • Stakeholder *233

Type [Client *235]: Role [Stakeholder].

Combine: Concept *393 . July 21 29th , 2001

Combine means: to put together, in some sense and manner.

Related Concepts: Combine, Compress, Condense, Summarize, Implode

Keyed icon [Combine, *393]: ‘}’ (Icon). Antonym Icon: { Generate.

A } B means ‘A {Combine/Compress/Condense/Summarize/Implode} to B’.

Examples:

Project Data } Report A

IF Companies } One Corporation

Design Ideas } Design Decision

Conflicting Requirements } Balanced Set of Requirements

Target {Scale, Goal X, Fail X} } Gist. = Target } Gist

Comment Concept *018 . January 8, 2003

see Note *018

Commentary Concept *632 May 26, 2003

Commentary specifications are remarks about other specifications. Commentary specifications will probably not have any economic, quality or effort consequences if they are incorrect: defects in commentary are almost always of minor severity.

Examples:

  • Note
  • Comment
  • "Text in quotes"
  • Source

Related Concepts [Commentary *632]:

Type [Commentary *632]: Specification.

Commitment Parameters: Concept *027 .

July 21, 2001

Future requirements specification levels which are ‘promised’ at some level.

These are distinguished from non-commitment target parameters:

Wish: valued, but not necessarily practical .

Ideal (‘perfection’) target specifications, which are ‘possible, desired, noted, but’ not promised to anyone’ targets.

Stretch, which is something we will try to look into, but is not promised.

Rationale: this concept is needed so that engineers do not misunderstand all specifications as being a commitment. It also helps us understand the relative priority of a specification.

Common Causes Concept *020 November 21, 2002

These are repetitive systemic causes of consistent measurable process output levels of performance or cost.

“Common causes: of variation, produce points on a control chart that over a long period all fall inside the control limits. Common causes of variation stay the same day to day, lot to lot.” (DEMING93, p.178).

Dr. Shewhart (Deming’s teacher, who invented the concept, called them “assignable causes".

Note: The main point of this concept is that common causes are rooted in ‘organizational‘ things, which ‘must be improved by management’ (Deming’s contention), and are outside the capability of a worker to improve or deal with. The term common causes was first used in 1947 and published by Deming in 1956 (DEMING86 p.314).

Related Concepts:

  • Special Causes *019
  • Statistical Process Control *477

Synonym: assignable causes

Type: Statistical Concept

Domain: Statistical Process Control, Continuous Process Improvement

Commonality [Product Line] Concept *580 July 13, 2002

If any two products share any common assets they have commonality.

Note: in building a product line architecture you will try to maximize commonality potential by both the product line architecture itself, and the design of individual components and individual development artifacts.

See variability

Thanks to Stefan Ferber, Bosch, for suggesting this concept. July 2002.

Competitive Engineering. Concept *395 .

July 21, 2001

A Systems Engineering discipline that is focused on ‘winning’, relative to some competitor, some enemy, some challenges, some events, or some Benchmarks.

Notes:

Competitive Engineering involves:

  • analysis and specification of competitive Benchmarks.
  • determination of competitive target levels for qualities and costs
  • determination of competitive target qualifiers {when, where, if}.
  • analysis and avoidance of undesired risk elements.
  • rapid recognition of changes, and response to them, in the engineering specifications and project plans
  • creativity in finding design ideas with maximum satisfaction of quality targets at minimum costs
  • the ability to avoid, identify and solve engineering problems as early as possible
  • the ability to invest in continuous data collection about product and engineering process, so as to sense problems, and deal with them on a factual rational basis.

Concept and definition © Tom Gilb 1999-2001

Complete. Concept *270 .

July 21, 2001

A ‘complete’ specification, of anything, especially design or requirements, is not lacking in any information necessary for ‘successful’ use of it by [defined parties], at [defined times], under [specified conditions].

Note 1. One formal and measurable (using the SQC process) notion of ‘complete’, is that no defects, according to all pertinent rules for the specification, exist.

Note 2. Another notion is that it is complete for a [defined purpose or situation], though possibly incomplete for other situations.

Complex Concept *021 March 31, 2003 B

A complex component is composed of more than one elementary and/or complex component.

A complex component consists of several sub-components. The sub-components may be all of the same type as the component, or of several different types.

Notes:

1. Requirements, Design Ideas and Evo Steps are often complex components.

Example:

Goal [Alpha]: 30%, [Beta]: 20%. “This is a complex statement.”

Goal [Theta]: 50%. “This is an elementary statement.”

Related Concepts [Complex *021]:

Type [Complex *021]: Adjective.

Component Concept *022 January 11, 2003

A component is a potential, or actual, part of some larger system, or specification.

Notes:

1. A component can be elementary or complex.

2. A component is any identifiable individual part of any set.

3. Product Line Components are final parts of a product or a product line generic asset collection (assets which can be turned into products).

Synonyms [Component *022]:

Related Concepts [Component *022]:

  • Elementary *055
  • Complex *021
  • Consists Of *616
  • Includes *391 “Includes can give a partial list of contents.”

Keyed Icon [Component *022]: X: {y}. “Meaning y is a component of X.”

Type: Specification Object.

Compound Statement: ( Concept *023 ) November 20, 2001

A compound statement contains two or more elements.

Related Concepts:

  • Complex *021 : a complex statement can be decomposed into two or more elements.
  • Elementary, *055 is ‘non complex’.

Concept: Concept *595 . March 12, 2003

A concept is an idea.

Related Concepts: [Concept *595]

  • Planguage Concept, *188 an Idea defined in Planguage.
  • Engineering Concept, a notion of an engineering artifact such as a design idea or requirement idea.

Defined concepts can:

  • be reused without explaining them again.
  • be redefined by Planguage Users locally, and simultaneously changing (hopefully improving) the definition of all terms, which reference the defined concept.

  • be referenced by a set of terms in any language, without necessarily having to rewrite the concept definitions themselves in that language. For example the concepts could be defined in English, but a Norwegian set of pointers to the concepts can be quickly defined, to permit teaching or multinational project learning and use of specifications.

Type [Concept *595]:

Condition Concept *024 April 27, 2003

A condition is a specified pre-requisite for making a specification or a system component valid.

Notes:

1. Evaluation of the status of a condition can be carried out anytime, and on many different occasions, each with a potentially different result. The result of an evaluation of a condition is the ‘current condition status’ or more simply, ‘status.’

2. Evaluation of a condition will determine if its status is currently true or false.

3. There are several distinct kinds of conditions:

  • Reusable Conditions
  • Qualifier Conditions
  • Pre-requisite Conditions

Reusable Conditions:

The Planguage parameter ‘Condition’ is used to define conditional terms. The ‘true or false’ status of such a term can be determined when required. This parameter statement can be used to define:

  • reusable conditions (conditions that many other statements can make use of).
  • conditions which are complex, and get simplified by having a single tag to express them.

Example:

Senior : Condition { Senior Citizen Or Service over 20 years to Company }.

Pass Through : Condition: Traffic Light {Green, Yellow, Blinking Yellow, Not Red }.

Qualifier Conditions:

One or more qualifier conditions can be used to specify a statement qualifier (for example, ‘[End of March, USA, If Peace]’). A statement qualifier must be completely true for the qualified statement to be valid.

Example:

Level X : Goal [ A , B , C ]: 33%.

Note: Level X is only a valid Goal when all three qualifiers { A & B & C } are true/valid.

Another example, a Goal level specification is only valid when all the conditions in its qualifier are true. The qualifier in the Goal statement below has three conditions.

Example:

Goal [Year = Release + 1 Year, Market = Europe, Not War]: 66%.

A qualifier condition may consist of an explicit tag name with an appropriate variable declared (for example, ‘Market = Europe’ . ‘ Market’ is the tag name and ‘Europe’ is the variable).

If there is no ambiguity, the tag name may be implied and simply the variable is stated.

A qualifying condition may, or may not, be satisfying a Scale qualifier.

Example:

Learning Time:

Scale: Time in minutes for a defined [Role] to <learn> a defined [Task].

Goal [Task = Login, Role = Operator, Country = Spain]: 2 minutes.

‘[Task = Login, Role = Operator]’ is a statement qualifier.

Both ‘Task’ and ‘Role’ are qualifier conditions. They are also both Scale qualifiers. Task is assigned a variable of ‘Login’, and ‘Role’ a variable of ‘Operator’.

Country = Spain’ is an additional qualifier condition, which has been added. It is not a Scale qualifier.

If the Task under consideration is ‘Login’, the Role is ‘Operator’ and the Country is Spain, then the target goal for consideration must be 2 minutes.

In other words, the evaluation of the statement qualifier as ‘true’ depends on all its qualifying conditions being ‘true’. Each qualifier condition is only true if its variable matches the specific instance being considered (Task IS ‘Login’, Role IS ‘Operator’ and Country IS ‘Spain’).

Each qualifier condition might have a set of valid variable settings. For example, Country: {Spain, USA, Germany}.

Pre-requisite Conditions:

A set of conditions, can be used as a prerequisite for a system component, such as entry to a defined process, or exit from a defined process, or use of a product. Any such conditions should be explicitly listed as pre-requisites or qualifications.

Example:

Exit Conditions:

X1 : Senior . “See definition in above example”

X2 : Level X . “Not only A & B & C, but also 33% Goal reached”

Example:

Process: Evening Closedown [Application: Default: ABC].

“The square brackets, ‘[ ]’, specify a qualifier condition. It asks the question: Which application is this generic process being applied to?”

Gist: Application process for evening closedown for the night.

Entry Conditions

E1: All users have logged off. “A condition. Are all users logged off: true or false?”

E2: After 8pm. “Another condition. Is time after 8pm: true or false?”

Procedure

“If all entry conditions are met (that is, are ‘true’), then it is ‘valid’ to carry out the process.”

Synonyms [Condition *024]:

  • Conditional Term *024
  • Pre-requisite Condition *024

Related Concepts [Condition *024]:

  • Condition Constraint *498
  • Qualifier *124
  • Status *174: The result of the evaluation of a condition.

Keyed Icon [Condition *024]: [?]

Notes:‘[?]’ alone is a keyed icon meaning Condition and its synonyms. The ‘?’ is an icon for a condition or set of conditions whose status needs to be determined as true or not.

The qualifier square brackets alone ‘[ ]’ serve as a keyed icon for containing conditions, in the context of typical Planguage statements.

Type [Condition *024]: Parameter, Qualifier Concept.

Condition Constraint Concept *498 June 4, 2003

A condition constraint is a requirement that imposes a conscious restriction for a specified system scope.

A condition constraint, also called a ‘restriction,’ is a binary type of requirement.

Notes:

1. A condition constraint differs from a ‘condition’ in that some kind of failure, invalidity, problem, dependency, risk, or other problem may be experienced, if the constraint is not met. It serves as a warning signal for problems.

Example:

CCR: Constraint [Release 1]: Initial product must be delivered before the end of January.

Rationale: Financial penalties apply if this contractual deadline is not met <- Contract Section 2.4.

2. A condition constraint can be categorized by innumerable useful categories, but some common ones are design, legal, cultural, market, geographic, safety, and language. (Note these categories can also apply to other types of constraint, for example, a certain level of reliability – a scalar performance constraint – could also be a ‘legal constraint’).

Examples:

C1: Constraint [Language]: All official languages of a market will be fully supported in the user interface, and all training and handbook information.

C2: Constraint [Safety]: All Electrical Equipment brought onboard any Corporate Aircraft as Standard Kit will comply with Corporate Electrical Safety Standard 1.5.

Synonyms [Condition Constraint *498]:

Related Concepts [Condition Constraint *498]:

Keyed Icon [Condition Constraint *498]: [<Condition Tag Name>]

Square brackets. Same icon as for a Condition

Type [Condition Constraint *498]: Constraint.

Confidentiality: Concept *647 20 April 2004

The level of readership to which a specification is restricted.

Parameter [ *647] Confidentiality.

Type [ *647] Parameter

Constraint Concept *218 March 31, 2003

A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process.

A key property of a constraint is that a penalty or loss of some kind applies if the constraint is not respected.

Constraints include limitations on the engineering process, a system’s operation, or its lifecycle.

A constraint is "something that restricts" <-The American Heritage Dictionary (Dell).

Notes:

1. There are two kinds of constraints: Binary and Scalar.

Binary constraints are statements that tend to include the words ‘must’ or ‘must not’: that is, they tend to make demands about what is mandatory for the system or what is prohibited for the system. Binary constraints are declared either by using a Constraint parameter or by specifying ‘Type: Constraint.’

Examples:

C1: Constraint: A design idea must not be made of material, components or products only produced outside the European Market, if there is any EU material which can be used.

C2: Constraint: The design must contain ideas based on our own patents whenever possible.

C3:

Type: Constraint.

Defined As: All stakeholder critical qualities must be planned and delivered so that they are viewed as obviously and significantly better than any competitor in the same price range.

From an attribute viewpoint, binary constraints are function constraints, design constraints or condition constraints.

Scalar constraints are specified for performance or resource attributes. They are specified using Fail and Survival parameters, which set the constraint levels on a scale of measure.

2. All engineering specifications (requirements and design) and management plans, once stated, potentially and probably have some constraining influence on the rest of the planning or engineering process. So all specifications and plans are ‘constraints’ in this sense.

However, we can clearly distinguish between specifications where the primary intent is to constrain (like a mandatory constraint or a level for Survival), and those specifications where the primary idea is not to constrain, but to motivate positively (for example, a binary function target or, a scalar performance target, such as a Goal or Stretch level). We could classify the former as ‘intentional and direct constraints’ and the latter as ‘unintentional and indirect constraints’.

So, we only classify specifications and concepts as ‘constraints’ when the clear intent and primary purpose is to restrain, limit, restrict constrain, or stop.

3. You have to look at constraints from a ‘stakeholder’ viewpoint. As with any requirement or design, what is a requirement for one level of system stakeholder, is a constraint as viewed by sub-ordinate stakeholder levels.

One stakeholder’s requirement is another stakeholder’s constraint.

4. All constraints are valid for their associated defined conditions. Sometimes the constraint conditions are stated explicitly, sometimes they are implied or inherited from more global specifications.

A ‘global’ constraint is usually imposed by higher levels of authority, or by earlier planning processes. For example: by company policy, law, contract, strategic planning or systems architecture.

Examples:

An example of a global constraint:

Availability Criteria : Constraint: No Company Product shall ever be designed with less than 99.5% availability.

A corresponding local constraint setting a higher constraint level:

Fail [ US Market , Military Systems ]: 99.98%.

5. Constraints can be classified by the ‘relative level of organization’ they apply to, as proposed by Ralph Keeney [KEENEY92]:

  • Fundamental Constraints: handed down to us from higher authority
  • Strategic Constraints: ones we have imposed at our own level, over which we have control
  • Means Constraints: constraints imposed at levels supporting us, which we can therefore overrule.

6. All requirements, including all constraints, have different ‘priority’. This priority (or ‘power’) is determined by the conditions (the qualifiers) and by their related specifications (for example, by parameters like ‘Authority’). It is a complex process to determine constraint priority, and the ‘answer’ is dynamically changing. There is probably no absolute constraint that must be respected ‘no matter what’. That is, there might always be a higher priority consideration that overrides a given constraint. For example, ‘Thou shalt not kill (except in self defense)’.

7. Constraints always represent, in some way, some of the values of some stakeholders. But a given constraint does not necessarily agree with the values of all stakeholders. The constraint of one stakeholder might be in direct conflict with the requirements of another stakeholder.

8. Any set of categories (including no categories!) can be specified for classifying constraints. System, performance, budget and design are an arbitrary few such categories.

9. I view constraints as borders around a problem. We can do anything we like within the borders, but we must not wander outside them.

Figure *218: Constraints impose restrictions on both other requirements and designs. But the remaining space (‘OK’) gives considerable freedom to set more-exact requirements, and to specify more-exact designs.

10. A requirement is a ‘constraint on succeeding engineering processes’ in fact, if and only if it has an authority, or other form of priority, which in fact means that:

  • you must stay within its guidelines (when making later decisions or specifications)
  • you cannot change it yourself (in order to avoid obeying it), without authority to do so.

Related Concepts [Constraint *218]:

Figure *218a: Drawn Icons for Constraints

Keyed Icons [Constraint *218]:

For Survival: [ and/or ]

For Fail: !

In context: ----[-------!---]---->O---[----------!---]----->

Type [Constraint *218]: Requirement Class, Parameter.

Constraint Design: Concept *523 . January 24, 2002

Constraint Design is design specification aimed at, or as a side effect, satisfying Constraint requirements.

Note 1: On the multiple effects of any design.

Any design specification, however intended, in reality will impact many of our requirements. This multiple impact is true whether we like it or not. We cannot, it seems, only design on one pure requirement dimension (cost, performance, quality, condition constraint, function) without having some side effects in others.

Type: Design specification

Related Concepts [Constraint Design *523].

  • performance *434
  • design specification *586
  • cost design *522
  • function requirement *074
  • performance {architecture, solution, design idea, and other synonyms of design)

Consists of *616 August 29, 2002

Parameter:

Describes complete set of elements that a concept consists of.

Security:

Consists of : {Integrity, Attack}.

Related Concepts [Consists of, *616]

  • Includes *391 may list some but not all components

Consumer Concept *038 May 6, 2003

A consumer is a person or group, who makes use of (‘consumes’) a process output (product).

Notes:

1. A consumer is any customer ‘downstream’ in a chain of systems engineering or system implementation processes. Consumers mainly make use of intermediary process outputs of systems engineering, management and manufacturing processes, such as test plans and requirement specifications. A consumer at the end of the chain of consumers, who makes practical use of the final real system, is usually termed a user.

2. Use the term ‘Consumer’ for clarity on this term. The use of the synonym term, ‘Customer,’ is to remind employees that their colleagues in production or development processes, are to be treated like ‘customers.’

Synonyms [Consumer *038]:

Related Concepts [Consumer *038]:

  • Client *235: Also has ‘Customer’ as a synonym.
  • User *234
  • Stakeholder *233

Type [Consumer *038]: Role [Stakeholder].

Content: Concept *594 . August 15, 2002

Content is the meaning or message contained in a specification as distinct from its appearance, form, or style.

Actual specification content may or may not totally reflect a concept we have in mind. It might intentionally simplify the concept, or specify a particular view of it.

Related Concepts [Content *594]

  • Specification *137, the formal documentation of a concept. Content is what is contained in a specification.
  • Concept *595 an idea, which may or may not be specified.
  • Context: *483 a limited view of the problem from any useful perspective
  • Content Rules 543 the engineering standards for how to derive, specify and analyze engineering content, as opposed to clarity rules ( *129) which specify how to make an idea (good or bad) clear.

Context. Concept *483 . July 20, 2002

A context is a system view from any useful perspective.

Example:

Life Cycle Context: {Being Produced, Being Tested, Being Delivered, Being Installed, Being Tested After Installation, Being Used, Being Supported, Having Waste Removed, Being Disposed Of}.

Source: Robert Halligan, Systems Engineering Course, 5 September 2001. . He says it is a common practice to do context analysis using context diagrams.

Usage:

Contexts are established to force us to consider requirements and design that we might otherwise forget.

Related Concepts:

  • Stakeholder: *233: stakeholders are a particular class of context. Contexts by contrast may have no real, active or responsible stakeholder. Consequently a context can be established to make sure that some critical view of the system in space or time is considered.
  • View: *484
  • Context Diagram: a diagram of selected contexts or views of the system. (Halligan)
  • Context Analysis: analysis of considerations, particularly requirements, in defined and selected contexts.
  • qualifiers *124: in Planguage, qualifiers is a major way of specifying a context.

Note: this use of context analysis is a risk management technique.

Type: systems analysis category.

ECB Emergency Communication Buoys

Sept 5 01 Workshop 3 Context Analysis.

Purpose of tool: to capture and validate requirements.<-RH

Water. Assume Sea?

SSE Submerged Signal Ejector. Assume x instances?

SA Sleeve Adaptor <-4.1.1c

Hull.

Air - Surface

Sunlight <-4.1.10

Oil <-4.1.10

Flotation Collar <-4.1.7

Buoyancy<-4.1.7

Integration <- 4.1.9, &.7

Energy <-4.1.11

Shelf Life <-4.1.12

Operational Duration 4.1.16 E

Markings <- (Battery, Buoy) 4.1.13, .16

Unattended Support or Storage <-4.1.14

Testing <-4.1.15, 4.3.3.4

Cooling <-4.1.5

Peripheral programming Equipment <-4.1.5

Damage <- 4.1.4

Warnings <- 4.1.16

==================== operational requirements

Loading In <- 4.2.1

Activation <- 4.2.1,

Discharge 4.2.2

Distress Transmission Activation <- 4.2.1

Homing Signals Activation <- 4.2.1

Operator programming <-4.2.2

Radiation <- 4.3.3.4

Example of initial brainstorming of potential context categories. The cross reference (<-) is to the requirements paragraph which mentions the context.

Continuous Process Improvement Concept *424 January 21, 2003

Continuous Process Improvement (CPI) includes any and all continuous long-term effort to systematically improve an organization’s work processes.

Abbreviation [Continuous Process Improvement *424]: CPI.

Related Concepts [CPI *424]:

  • Defect Prevention Process *042
  • Statistical Process Control *466

Type [Continuous Process Improvement *424]: Process.

Control Axis. Concept *261 . July 22, 2001

The Process Control Axis is the horizontal, left to right, direction of ‘process flow’ in a Planguage process diagram.

Precedent processes are diagrammed as flowing into the left quadrant (CE below). The next process, after ‘this one’, is diagrammed as being pointed to by an arrow flowing out of the right quadrant (CX below).

Not coincidentally, the control axis coincides with the Plan and Study components of the quadrangle. See also Input/Output Axis .

Process and data flow conventions in the Planguage Graphical Language.

These conventions can also be exploited in the Planguage Keyed Icons like this:

^[Architecture] ^[Engineering] ^[Component Design] ^[Prototyping]

Showing the relationship between processes (^[Keyed Process Icon])

Below, we have added the notation for data in and out of the Architecture Process, the vertical axis.

Sys. Requirements

V

^[Architecture] ^[Engineering] ^[Component Design] ^[Prototyping]

V

Arch. Specs

Control Chart Concept *029 May 18, 2003

“A control chart is a graphic comparison of process performance data to computed ‘control limits’ drawn as limit lines on the chart” [JURAN74].

Source: The control chart was invented in 1924 by Dr. Water A. Shewhart, and was first expounded in his book, ‘The Economic Control of Manufactured Product’ Nostrand, 1931. It was first known as a ‘Shewhart control chart’, but extensive usage led to the shorter term ‘control chart’ [JURAN74].

Related Concepts [Control Chart *029]:

  • Control Limits *028
  • Statistical Process Control (SPC) *466

Type [Control Chart *029]: Feedback Data.

Control Limits Concept *028 May 18, 2003

Control limits are the upper and lower bounds on a control chart. Control limits should contain, within those boundaries, all observations of ‘variation due to common causes’. Observations outside the control limits are probably due to special causes.

Notes:

1. Deming observed on control limits that:

“the device was invented by Dr. Shewhart in 1925 and used a ‘3-sigma’ control limit. They provide under a wide range of unknowable circumstances, future and past, a rational and economic guide to minimum loss from …. mistakes [in determining the distinction between Special and Common Causes]”.

[DEMING86, p. 319]

3-Sigma means plus/minus three times the standard deviation of the statistic used. It implies that only a tolerable 0.3% of observations outside the control limits are really due to common causes, and that they are also false alarms about ‘special causes’ [JURAN74, section 23-4].

A symbolic control chart with control limits being the solid horizontal lines. Common causes being within the lines and special causes outside the upper and lower bounds.

Related Concepts [Control Limits *028]:

Type [Control Limits *028]: Control Variable.

Control Point Concept *346 March 15, 2003 12:51

Control points are the specified elements that must be considered in solving a problem. They include requirements, constraints, qualifiers and inherited specification elements.

The number of problem control points that must be considered is a measure of the complexity of the problem to be solved.

Synonyms [Control Point *346]:

  • Problem Control Points *346
  • Problem Dimensions *346

Related Concepts [Control Point *346]:

Type [Control Point *346]: Engineering Concept, metric.

Controllability: Concept *175 January 21, 2002

A component of the system state vector is ‘Controllable’ if there exists a control signal which can bring the system from the current state to a desired state.

It is ‘Observable’ if it is possible to compute or estimate the state from a finitely long observation of the system output.

Source: Steve Poppe, California, Personal Communication. .

Concepts from feedback control theory, controllability and observability.

Controllable. Concept *232 July 22, 2001

‘Controllable’ is the ‘type of objective’, if the Design Ideas chosen are capable of influencing Fundamental Objectives at all.

Source: Ralph Keeney . (see Bibliography)

Related Concept: Essential.

Core Specification Concept *633 May 26, 2003 D

Anything classed as, ‘core specification,’ will result in real system changes being made: incorrect core specification would materially and negatively affect the system in terms of costs, effort or quality. Specification defects in core specification are almost always of major severity.

Examples:

Core Specification Parameters include:

  • Scale
  • Meter
  • Goal
  • Definition
  • Constraint

Notes:

1. Core specification can be distinguished from ‘commentary’ and ‘background’ (supporting) specification.

2. Core specification is the ‘meat’ in specifications of requirements, designs, Evo steps and test cases .

Synonyms [Core Specification *633]:

Implementable Specification *633

Related Concepts [Core Specification *633]:

Type [Core Specification *633]: Specification.

Cost: (adjective). Concept *185 January 21, 2002

‘Cost’ as an adjective is used to signify that ‘Resources’, rather than ‘Qualities’ or ‘Functions’ or ‘Designs’ are the category of the noun being used.

Example ‘Cost Constraint’: a requirement relating to cost, such as "budgets are maximum three million, unless Board approved".

More examples: Cost Attribute, Cost Requirement, Cost Level, Cost Plan, Cost Scale, and Cost Meter.

Note the essential distinction between the two similar terms:

  • Resource: latent capability or fuels.
  • Cost: expense incurred (resource used) in development or operation.

Examples:

So: here are some examples to help distinguish these two concepts.

Cost attribute: a system attribute relating to the expense of developing or maintaining.

Example: “ the calendar time currently necessary to develop a new language version of our base stations is three months”.

Resource Attribute: a system attribute relating to potential resources, such as total money, total time, total engineering hours, which are potentially available. These need to be distinguished from Resource Constraints (stakeholder-determined specified limits on the use of the potentially available resources; and Resource Budgets (Goal, Fail targets for specific qualifiers which regulate and plan our use of a resource, within the overall resource constraint.

Example: “this Corporation can deploy over 1 million engineering hours per year for new product development, if they are not misused by unnecessary rework”.

Cost Requirement: (Synonym: Budget)

Example: I hope we can now build the system on half the engineering hours we used for the last product in that line” (a Wish target),

Resource Requirement: a specified requirement that a defined resource be produced or be allocated, for potential later expenditure. This later exploitation would in the next process, be registered or tracked as a cost; a use of the resource.

Example: The system must produce 50 million barrels of oil annually”.

Cost Level: a numeric level on a defined Scale, measured by a defined Meter, probably expressed as a Benchmark {Past, Record, Stretch} of consumption of a resource.

Example: they used $2 Billion for a single ‘space launch’.

Resource Level: a numeric level on a defined scale of measure that is stipulated for production, allocation or is otherwise recognized.

Example: “all the gold on earth”.

Cost Plan: a specific Benchmark or Vision or Ambition specification regarding resource consumption.

Example: “ we aim to cut development time, to 10% of today’s time, within 3 years.”

Resource Plan: a specific Benchmark, Vision or Ambition specification regarding production or allocation of a defined resource.

Example: Our corporation will have to double current engineering resources and corresponding R&D capital available in order to remain competitive in the increasingly globalized marketplace of this decade.

Cost Scale: a defined scale of measure, units of measure, for costs or expenses.

Example: Scale: Engineering Hours per average Module delivered to Plan quality levels.

Resource Scale: a defined scale of measure, units of measure, for resources.

Example: Scale: Gigabytes actually free for deployment under [defined Circumstances] for defined [Purposes] after defined [Events].

Keyed Icon: -->O

Synonym: Resource (Adjective *185, not to be confused with Resource noun *199)

For example ‘resource constraint’, and ‘resource requirement’.

Cost Concept *033 May 26, 2003

Cost is an expense incurred in building or maintaining a system. It is consumption of a resource.

Synonyms [Cost *033]:

  • Price *033
  • Expense *033: The degree of consumption, how much resource was used.

Related Concepts [Cost *033]:

Keyed Icon [Cost *033]: -|->O

The keyed icon is a level symbol, ‘|’ set on a resource scale of measure, ‘-->O’.

Note: The neutral symbol ‘|’ is chosen to represent the generic cost concept, rather a currency symbol, because the resources involved are more than just money. If you want to link the icon to the idea of a cost range, then think of the chosen symbol as a minus sign, turned 90 degrees.

Example:

---||||||||-->O expresses a cost range.

The keyed icon for Cost [Money] is a currency symbol, default € (Euro).

Example:

--€--> to express a money cost

and ----<€€€€€€€€€|======> to express a cost range.

In a local culture, the local currency symbol can be used instead of the more neutral and default € symbol.

Example:

£, $, ¥, ---AUS$----> or ----CAN$--->

Type [Cost *033]: Attribute Concept.

Cost, to: (Verb). Concept *184 . July 22, 2001

To ‘cost’ something is specifically to estimate the resources needed to achieve

a planned set of requirements. To estimate costs.

Type: process concept.

Synonym: To estimate ( *059). The term ‘to estimate’ is more general than ‘to cost’. ‘To estimate’ applies to any attribute or parameter estimate. For example, estimating the quality impact of a design.

Usage: They costed the system

In particular, the term ‘to cost’ implies that the estimates are about financial resources, unless otherwise specified.

Cost Budget : Concept *479 . December 19, 2002

A cost budget is a requirement level set for a resource. Cost budgets are either Budget Constraints or Budget Targets.

Related Concepts:

  • Cost-Level Constraint: *479 Limit and Fail for resources
  • Budget Targets *481. {Goal, Wish, Stretch}.
  • Budget Constraints 421: these are Cost-Level Constraints and Binary Cost Constraints ( *467)

Type: requirement type.

EDIT NOTE DEC 19 2002 DIAGRAM NEED UPDATING TG

Synonyms:

Related Concepts:

Cost Design: Concept *522 . January 24 2002.

Cost design is conscious design specification aimed at, or at least incidentally resulting in, the achievement of specified cost targets and cost constraints.

Note 1: On the multiple effects of any design.

Any design specification in reality, however intended, will impact many of our requirements. This multiple impact is true whether we like it or not. We cannot, it seems, only design on one pure requirement dimension (cost, performance, quality, condition constraint, function) without having some side effects in others.

Type: Design Specification.

Related Concepts [Cost Design *522].

Cost-Level Constraint: ( Concept *186 ) August 31, 2001 tg 1330

A ‘cost-level constraint’ specifies a cost-level limitation, on a defined resource scale.

It is a numeric cost requirement constraint, on the costs of design ideas, for a specified function or system.

A simple example of a cost-level constraint. Note that the Cost-Level Constraint is expressed by the ‘Limit’ specification. The ‘Goal’ specification concurrently expresses a ‘Budget’ ( *421), which is different.

Mission Budget:

Type: Cost Level Constraint.

Conditions [Non-NATO Missions Only, Peacekeeping Missions]

Scale: % of the deployed forces at any one moment of planned and actual deployment.

Goal [Next Budget Year, If Peace Conditions, Our National Contribution] 5%

Source [Goal]: Defense Budget for Next 5-year period.

Limit [Next Budget Year, If Peace Conditions, Our National Contribution] 10%

Authority [Limit]: NATO Ministers Meeting August 31 20xx, multinational agreed maximum restriction for any one nationality.

Type: scalar resource constraint requirement

Synonym:

Cost Constraint [ *186]. ‘Level’ implied, but not quite as clear to others.

Related Concepts [Cost-Level Constraint *186]:

  • Cost Requirement. A cost-level constraint is a sub-class of ‘cost requirement ‘.

The ‘cost-level constraint’ is a fundamental requirement, handed to our project level by some defined level of stakeholder authority, which generally has higher priority than ‘our’ project level does. So, we must respect the cost constraint from the outset, and work within its framework. It is not something we can trade off , against performance requirements, and other resource requirements, without approval from the defined authority. Other cost requirement types (Budget Targets *421) are set within the constraint framework and are more flexible as need, priority and resource availability permit. The cost constraint would always be set using Fail or Limit statements.

  • Budget Targets (also ‘Budgets’), *421:

The difference is that Budget Targets imply human intent to plan and budget for a limitation of resource use. Budget Targets imply willingness to ‘trade off’ these budgets with respect to higher priority requirements.

Cost-level constraints could normally be set due to other constraint causes than ‘human budgeting intent’; for example due to contracts, formal agreements, natural causes, legal limits, higher authority budgets or regulations and policies. Budgets by contrast to cost-level constraints (using Limit, Fail, Constraint) would always be set using Target statements Goal, Wish and Stretch.

  • Resource Type Constraint, *221

A resource constraint can also be a constraint on the type of resource used. Example:

  • “Do not use capital, if current income can be deployed instead”.
  • “Use local labor rather than offshore or imported labor.”

Resource Type Constraint is a Binary Constraint (Veto or Demand subtypes). Resource Type Constraints would not be stated in terms of a defined scale of resource. They would be binary in nature.

Keyed Icon [Cost Constraint *186]: -----[-->>----]-->O(Resource Limit icons)

the ‘[‘ being a lower limit and the ‘]’ being an upper limit. The >> being a Fail type constraint specification. All of these can be multiple instances with different qualifiers for each one.

Example (of multiple cost constraints in a single statement):

Failure Levels: Fail [USA] US$ 100,000, [EU] ¤ 200,000, [Rest Of World, Next Year] GBP 300,000.

Illegal levels: Limit [USA] US$ 500,000, [EU] ¤ 500,000

Cost constraints can be used as an overall framework within which a more-detailed set of Budget level specific constraints can be planned.

Example of global (applies entire project) and generic (must be determined in detail depending on profitability) cost constraint:

C4:

Type: Cost Constraint:

Constraint [Project XX]: no expenditure shall exceed a level that will make the product unprofitable in the <short term>.

Authority: Business Policy 5.6.8

Parameters Used: Limit, Fail, Constraint.

Cost Level: Concept *033 . August 31, 2001tg 1510 May 6 03

Cost level is ‘expense’ level; resource consumption level.

A cost level specification is either a specific required (target), or historical (benchmark), for a cost attribute. It is a specific numeric value on the ‘Scale’, used to define the resource consumption level referred to.

Related Concept: Resource level. (The level a resource is currently at. The resource which remains after the cost expense is accounted for)

Synonym:

  • expense level. (the degree of consumption, how much resource was used).
  • Price *033

Note: Current Resource level = Old level of resource minus Cost Level

Icon: -|->O(level ‘|’ of a cost/resource/system fuel ‘->O’)

Other specific attribute level indicators can be used as desired. For example >, <, >>, <<.

Usage: The ‘monetary cost of the project’ was more critical than the ‘cost of our reputation’, or the ‘cost in terms of future site rehabilitation - due to pollution’.

Example:

  • A statistical analysis system might have as a resource requirement, a certain quality level (accuracy, completeness, credibility) of data.
  • This input data once had a set of other costs (time, people, money) needed to bring it to the quality levels required for some process. It is still the ‘data itself’ which is the fuel (resource) to the ‘statistical process’, not the previous-process costs of the data qualities. • The expense of the data quality (resource) levels, are the resources which were needed in a previous process, i.e. the process that made the data ‘good enough’ for the later statistical analysis process.

Note that a Cost level attribute, like quality and other performance attributes,

  • can describe the ‘analyzed past’ of a system (benchmarks),
  • and/or can specify future requirements (budget, targets).

The Cost level requirements

  • can be specific target requirements

(‘The project budget [for Planned Levels] is ¤ 3 million’)

  • or can be Global Cost Constraints

(‘No Budget can exceed ¤10 million without Board authorization Policy’).

Example:

Costs might be expressed like this:

‘about 1,000 engineering hours budgeted’.

Note that a ‘Cost’ is a numeric level of some defined cost type (its Scale defines the exact Cost type), like ‘investment $’. It is any type of Cost (or ‘Resource , or Process Input ), work-hours, real time, talented people, goods, data and money.

A cost is not a Resource ! It is a specific quantity (level) of a resource. A resource is a ‘potential source’ of cost inputs.

Note: a quality output (Resource X, below) from a precedent product or process, which itself is a necessary input to a subsequent system, is a cost (of operating the second system), and its costs (CY, in the first system) are the indirect cost of that quality.

The indirect cost ‘CY’ of Quality Y is the cost of fueling the precedent system to the one producing the quality Y.

This is easier to see if we consider the two systems to be sub-systems of a single Supra-system, as above.

Related concept: System Input. The ‘cost’ (cost level requirement) is the level of System Input needed.

Example:

Capital Budget ------>>[1st Year] 3million --->O.

The double right-pointing arrowhead (>>), above, indicates a Fail (should not exceed) budget level of 3 million for the time period ‘1st Year’, on a scale (defined somewhere else in Capital Budget). This is a ‘cost budget’ type of requirement. The Attribute is identified by its tag ‘Capital Budget’.

Capital Budget --------------] 4million --->O.

The ultimate limit, a budget requirement type, is 4 million.

Capital Budget ------>>[1st Year] 3million -------------------] 4million ---->O.

This illustrates a combination.

Type [Cost Level]: resource requirements specification concept, budget requirement level

Crash (parameter): Concept *602 . August 18, 2002

Crash is the popular and short form Planguage parameter suggestion for the concept Catastrophe Limit ( *602).

Credibility Concept *035 November 18, 2002

Credibility expresses the strength of belief in and hence validity of, information.

Within Impact Estimation, credibility is usually assessed for the evidence and sources supporting each specific impact estimate. Credibility is expressed as a numeric value on a range of credibility ratings from 1.0 (for perfect credibility) to 0.0 (for no credibility at all). These credibility values can be used to credibility-correct the impact estimates: each impact estimate is multiplied by its relevant credibility.

Example:

If an impact estimate were 40% and its credibility were 0.5, then the credibility-adjusted estimate would be 20% (40% multiplied by 0.5).

Keyed Icon: ±?.# “An uncertainty estimate.”

Type: Systems Engineering concept.

Domain: Impact Estimation.

Credibility Rating Concept *272 February 11, 2003

A credibility rating is the assignment of a number on a defined credibility scale that ranges from 0.0 for no credibility for an impact estimate, to 1.0 for perfect credibility of an impact estimate.

Credibility RatingMeaning

0.0 wild guess, no credibility

0.1we know it has been done somewhere

0.2we have one measurement somewhere

0.3there are several measurements in the estimated range

0.4the several measurements are relevant to our case

0.5the method of several relevant measurements is considered reliable0.6we have used the method/design/idea/strategy in-house

0.7we have reliable measurements for the design idea in-house

0.8reliable in-house measurements correlate to independent external measurements

0.9we have used the idea on this project and measured it

(Evo step, pilot and field trial)

1.0perfect credibility, we have rock solid, contract-guaranteed, long-term and credible experience with this idea on this project and, the results are unlikely to disappoint us.

Type [Credibility Rating *272]: Defined Variable.

Critical Factor Concept *036 February 25, 2003/April 1, 2003

A critical factor is an attribute level or condition in a system, which can on its own, determine the success or failure of the system under specified conditions.

A critical failure factor is usually specified as a constraint level (for example a ‘Fail’ or ‘Survival’ level), or as a binary constraint (‘Constraint’).

A critical success factor is usually specified as a target level (a ‘Goal’ or ‘Budget’ level), or as a binary target. (‘Target’).

Notes:

1. System or component failure might occur, possibly only under certain ‘extreme’ conditions. These ‘critical’ conditions should be explicitly specified by some of the means available such as: {State, Condition, [qualifiers], Risk, Dependency, Impacts, Impacted By, Assumption, Authority, Source, and Impact Estimation specification terminology, such as Credibility, Safety Factor and others}.

2. A critical failure level of performance is usually defined by a Fail or Survival level specification with numeric level and relevant [qualifiers]. Each such level must be achieved or improved upon, otherwise critical breakdown, and official failure of the entire system, threatens to occur. Of course, reality might turn out to be different, either way!

3. Constraints (example: legal requirements or architectural requirements), for a product, are also generally ‘critical’. If they are not satisfied they might well cause failure somewhere, sometime, under given circumstances.

Related Concepts [Critical Factor *036]:

  • Critical Success Factor *418
  • Critical Failure Factor *025

Type [Critical Factor *036]: Classification Concept.

Critical Failure Factor Concept *025 April 1, 2003

A Critical Failure Factor is any factor that determines any degree of failure of a system. This includes, and can be specified and articulated using both scalar levels and binary conditions.

A critical failure factor may be specified as a constraint level (for example a ‘Fail’ or ‘Survival’ level), or as a binary constraint (‘Constraint’).

Related Concepts [Critical Failure Factor *025]:

  • Critical Success Factor *418
  • Critical Operational issues (COI) <- SPROELS02, DoD 5000-2-R [1996] Defense Acquisition, US Dept Def. Wash DC. “The issues (not parameters, objectives or thresholds) that must be examined… to evaluate/assess the systems capability to perform its mission.”
  • Fail *098
  • Critical Factor *036

Type[Critical Failure Factor *025]: Classification Concept.

Critical Success Factor Concept *418 February 25, 2003

Any an attribute level or condition of a system that can itself, alone, determine practical or total system success, is a critical success factor.

Related Concept [Critical Success factor *418]:

  • Critical Factor *036
  • Critical Failure Factor *025

Acronym [Critical Success Factor *418]: CSF

Type [Critical Success Factor *418]: Classification Concept.

Cumulative Defect Removal Effectiveness Concept *037 April 1, 2003

The cumulative defect-removal percentage, of a defined series of defect removal processes.

For example, a series of specification defect-removal stages, plus various testing stages.

A practical example: Specification Quality Control has a single-pass effectiveness of 60%[logic bugs]-88%[interface specification defects] but cumulative logic bug removal effectiveness for a series of Specification Quality Control (SQC) processes has been noted at 95%, before any testing stages are necessary

Source: IBM and Sema Ltd. UK [in GILB93 ].

The term could also refer to any other forms of ‘cumulative effectiveness, outside of defect removal.

Cycle-Constraint: Concept *039 . July 23, 2001

A planning constraint on an evolutionary project cycle of any kind.

Note: Typically, expressed in a planning policy (example below), and requiring a cycle to be planned within certain time or financial limits.

For Example:

Two Percent Money Limit:

Type: Generic Budget Constraint.

Description: A result cycle shall use no more than 2% of total budget.

Cycle Priority: Concept *040 . July 23, 2001

The calculated relative (to other potential cycles) importance of a specific planned Evolutionary delivery cycle.

Usage:

This is usually done using the benefit/cost ratio (also known as the quality-to-cost ratio) expected/estimated at the next cycle. This may be estimated using an Impact Estimation table. The higher the benefit/cost ratio, the greater the priority. Any specific interesting set of quality and cost factors, instead of all the specified factors, may be selected for a more-specific evaluation of priority.

For example, the ratio of Usability to Capital Cost for [Next Years Deliveries, Europe] could be chosen to give priority to any step content best serving those narrower interests.

Data Concept *319 April 17, 2003

Data is any form of signal, which humans or machines can usefully distinguish from other signals. Data is interpreted by some sensing agent, a reader, or a computer, which tries to convert it into useful information.

Data can be viewed as a necessary system resource. Data can also be viewed as a process input and as a process output. Data can be viewed in terms of its function (‘to warn’, ‘to give costs’), volume (bits), and in terms of both cost (cost to acquire, cost to store, cost to keep updated) and performance characteristics (accuracy, updatedness, credibility, precision, correctness).

Notes:

1. Data is a primary form of input and output to intellectual, and computer-controlled, processes. Data includes {characters, symbols, words, expressions, statements, diagrams}.

2. Data is not random meaningless signals. It is organized for analysis, or for use to help make decisions.

Example:

If “Stealth” = Aircraft Name.

The quote is used to express the idea of a symbol string, the data “stealth”. It can for example be used in a logical expression.

Related Concepts [Data *319]:

Resource *199

Process Input *178

Process Output *179

Keyed Icon [Data *319]: “ ”“Double Quotes” around the data string.

Type [Data *319]: System Component.

Dataware: Concept *576 July 12, 2002

Dataware includes any data which can be or is in fact processed by a computer.

Related Concepts [Dataware, *576]

  • Planware, *577 Planware is plans (information, data) for humans, not computers.
  • Infoware, *578 Infoware is information of any kind, a small subset of which might be used by computers
  • Documentation, *579 documentation is primarily for human not computer consumption
  • Logicware *575 is the ‘active’ logic directing computers in their actions. All Logicware is thus also dataware (since it is readable by a computer). But all dataware is not necessarily logicware.

DDP Concept *041 November 13, 2002

Abbreviation for Defect Detection Process.

Debugging Concept *293 June 5, 2003

A process of removing identified faults (bugs) from a system.

Notes:

1. A system is not mere specifications of itself, or a ‘mock up’ prototype. The ‘debugging’ process should include fault-consequent revalidation (in software called ‘regression testing’) that the fault ‘removal’ process has ‘succeeded’, and hopefully that it has not injected additional identifiable faults inadvertently.

2. The implication is that some QC processes on systems (for example, testing, field trials, user complaints, service/maintenance or repair analysis) have identified some faults, and ‘debugging’ means removing the faults, which were identified by that process. The debugging process is well downstream of the corresponding SQC processes of Editing and Edit Auditing, which deal with fixing defects (in specifications), not faults (in systems).

[Editor Note to Publisher: This Figure had to be assembled in parts as it could not be pasted special without crashing Powerpoint and running out of memory in Word?????? Figure in Powerpoint is complete – See Debugging *293]

Type [Debugging *293]: Process.

Decision-maker Concept *237 January 27, 2003

A decision-maker is a person or group, who will make a specific defined decision.

Synonyms [Decision-maker *237]:

Related Concepts [Decision-maker *237]:

Type [Decision-maker *237]: Role [Stakeholder].

DefaultConcept*447 May 3, 2003

A default specification is a term to be used as a value when none is explicitly specified.

Notes:1. The rationale for a default is to save specification effort, and to simplify specification, where possible.

Example:

Scale: Time to <correctly> carry out a defined [ Task , Default = Average Task ].

which in application to this statement (which has no ‘Task’ specification qualifier):

Goal: 66 seconds.

would automatically mean the same as if you wrote:

Goal [ Task = Average Task ]: 66 seconds

But, you can override the default option with a statement like this:

Goal [ Task = Difficult Task]: 100 seconds.

Synonyms [Default *447]:

Type [Default *447]: Specification Concept.

Defect [Specification] Concept *043

See Specification defect *043

Defect Detection Process (DDP) Concept *041 November 20, 2002

The Defect Detection Process (DDP) is part of Specification Quality Control (SQC), which also includes the Defect Prevention Process (DPP). It is the systematic, project-focussed process of identifying and fixing specification defects.

Source: A detailed description of the DDP process can be found in [GILB93] and [WHEELER96].

Notes:

1.The DDP is ‘project oriented’ in that it is primarily concerned with a project’s economics, rather than an organization’s work process economics (that is the DPP concern).

Rationale: This is to avoid the high cost of late defect removal (at test, or in field), or to avoid the high cost of the consequences of malfunctions caused by the defect.

“A stitch in time saves nine”.

2. DDP is not itself concerned with process improvement, but it provides a stream of data, concrete defect examples, and a working environment that can be used to feed into, and to help analyze effects of, a Defect Prevention Process.

Abbreviation: DDP.

Related Concepts:

  • Specification Quality Control (SQC) ( *051)
  • Defect Prevention Process (DPP) ( *042)

Defect Prevention Process Concept *042 January 12, 2003

The Defect Prevention Process (DPP) is a specific IBM-originated process of continuous process improvement. It is part of Specification Quality Control (SQC).

Notes:

1. The DPP process works towards continuous process improvement for on-going, and especially future, projects in a larger organization. It is fed suggestions, and data, on problems, from the Defect Detection Process (DDP), and from other defect-identification sources, like testing and customer feedback.

“An ounce of prevention is worth a pound of cure.”

2. As reported by IBM, in organizations of 100 to 1,000 people, about 200 to 1,000 process changes may be implemented annually. On initial DPP implementation (the first project), 50% of the total number of historical defects may be eliminated in the first year of use and 70% eliminated within 2-3 years.

Sources:

  • Inspired by classical Statistical Process Control ideas [DEMING86], the Defect Prevention Process (DPP) was developed and refined (from 1983 onwards) by Carole Jones and Robert Mays of IBM Research Triangle Park NC with the aim of improving IBM’s processes for software engineering, hardware engineering and administration [MAYS95].
  • A detailed description of DPP can be found in [GILB93: Chapters 7 and 17].
  • DPP was the direct inspiration for IBM assessment process Level 5 (Ron Radice cited in Mays95), US DoD Software Engineering Institute’s Capability Maturity Model, CMM Level 5, and CMMI Level 5.

“I don’t expect perfection, but I do expect that we will always work for it. If we screw a mission up, that means that people who deserve to live will not live. That is going to happen. You know it. I know it. But we will avoid mistakes as much as possible, and we will learn the proper lessons from every one we make. Counter-terrorism is a Darwinian world. The dumb ones are already dead, and the people out there we have to worry about are those who’ve learned a lot of lessons. So have we, and we’re probably ahead of the game, tactically speaking, but we have to run hard to stay there. We will run hard.”

John Clark, Rainbow Six leader in Tom Clancy, Rainbow Six.

ISBN –0-14-027405-7, Penguin, www.penguin.com , page 37

[AWL EDIT NOTE: PERMISSIONS PENGUIN BOOKS LTD 27 WRIGHTS LANE, LONDON W8 5TZ, ENGLAND, MAYBE ADDRESS IS CHANGED TO 80 STRAND

ANYWAY RIGHTS ARE REMOVE THIS NOTE, NOT FOR PUBLICATION]

Abbreviation [Defect Prevention Process *042]: DPP.

Related Concepts [Defect Prevention Process *042]:

  • Plan Do Study Act cycle (PDSA) *168
  • Specification Quality Control (SQC) *051
  • Defect Detection Process (DDP) *041
  • Continuous Process Improvement *424
  • Process Improvement Suggestion *088
  • Process Improvement *114
  • Process Meeting *119
  • Process Change Management Team *118

Type [Defect Prevention Process *042]: Process.

Define (verb): Concept *240 . July 23, 2001.

To ‘define’ is to officially explain a specified concept in writing.

Usage: In ‘Planguage’ the definition would always be represented (cross-referenced) by a unique tag. The tag would be capitalized (‘Tag’, not ‘tag’), both in the master definition, and sometimes when used elsewhere, to reference the concept or specification, as is practiced in this Glossary.

Rationale: Tag capitalization reminds us that it does have a formal definition elsewhere; in a Glossary or a project specification.

Usage: Defined terms in Planguage, as opposed to a project, would also have an asterisk ‘*-number’ associated with their concept definition, as does this concept *240..

Defined Term: Concept *151 (Term) 2/4/03

Same as Term

Definition Concept *044 May 25, 2003

‘Definition’ or ‘Defined As’ is a parameter that is used to define a tagged term.

Notes:

1. The tagged term could then be re-used anywhere else within scope, and would always have this precise definition.

2. Any tagged statement is, in practice, a definition of that tag, so the use of the ‘Defined’ parameter is to make it explicit that the statement is intended as a reusable definition.

Example:

The following are equivalent definitions of the term, Trained:

Trained: Defined As: At least 30 hours classroom, and 'passed' practical exam.

Trained: At least 30 hours classroom, and 'passed' practical examination.

Trained: Def: At least 30 hours classroom, and 'passed' practical examination.

Trained: Definition: At least 30 hours classroom, and 'passed' practical examination.

Trained = At least 30 hours classroom, and 'passed' practical examination.

Examples:

Reliability :

Scale: Hours to <complete> defined [ Task : Default = Most Complex Task ].

Fail [USA ]: 5 hours. “ Most Complex Task is suitable default for a Fail specification.”

Goal [ Europe , End Next Year ]: 10 hours.

Most Complex Task : Defined As: The work task, which normally takes most employees longest clock time to complete on average.

Abbreviations [Definition *044]:

  • Def

Synonyms [Definition *044]:

Keyed Icons [Definition *044]: ‘:’ or ‘=’

“Whatever follows the icon symbol is a definition of the tag or parameter to the left of the symbol. ‘=’ is less commonly used.”

Type [Definition *044]: Parameter.

Degree of Target Fulfillment: Concept *191 . April 1, 2002

This is the degree, expressed as % of a [qualified] Target level (100%) , which it has been met, in relation to a defined Benchmark level (0%).

Synonym: ( *191.syn.target level fulfillment.) ‘degree of target level fulfillment’.

Usage: The plan fulfillment can be real, estimated, or hypothetical. It is used in Impact Estimation .

For example:

50% means that half of the way to the target value is accomplished.

‘Minus 50%’ would be a corresponding distance (to +50%) in the opposite direction (a negative effect).

Delivered Value Concept *371 January 14, 2003

Delivered value is the value delivered by a set of delivery steps to a stakeholder group, as a consequence of changing the system attributes.

Related Concepts [Delivered Value *371]:

Type [Delivered Value *371]: Metric.

Delivered Level Concept *533 January 3, 2003

For a scalar attribute, the Delivered Level is the numeric value on a scale of measure ‘delivered’ by an Evo step (that is, the resulting level after system enhancement).

A delivered level is a Past benchmark. It is a result of project measurement of progress towards a required Goal/Budget level.

Rationale: The reason for this term, instead of a simple ‘Past’ is to emphasize the series of Evo deliveries on a particular project, and distinguish them from other Past levels benchmarked in the project.

Example: O--<----•-------•[Step 22]------->------>

Example:

Availability:

Scale: % Uptime.

Delivered Level [Release 1.0]: 99.90%, [Release 1.5]: 99.95%.

Goal [Release 2.0]: 99.98%.

Related Concept [Delivered Level *533]:

Keyed Icon [Delivered Level, *533]:“A bullet point”.

Type: Parameter, Benchmark.

Delivery Cycle Concept *049 January 2, 2003

A delivery cycle contains the initial operational implementation of an Evo Step, and its handover to stakeholders.

A delivery cycle is a subset of a Result Cycle. A delivery cycle involves implementation activities such as training, installation and field-testing.

Figure G.x: Diagram shows the component cycles of a Result Cycle.

Note: The type and size of system change involved in a delivery cycle can vary, but is usually subject to project-defined step constraints on resource utilization. Usually, both financial cost and delivery frequency must be between 2% and 5% of project total budgets for cost and time respectively.

Delivery as a synonym of Delivery Cycle *049

Demand Constraint. Concept *461 . July 17, 2002 February 8, 2003

A demand is a constraint of type ‘You must do X’.

Type: non-scalar Constraint Requirement, parameter.

Domain: CE.Planguage.requirements.constraints.constraints.demand

Synonyms: ‘Do’ (Constraint), insistence, law, rule, regulation, non scalar constraint, a ‘must’, demand .

Related Concepts:

Examples [Demand constraint]:

D1: Constraint: Resident workers in country of export shall be used wherever possible.

D2 Constraint: [IT Projects, In House] Commercial Off The Shelf Software shall be used exclusively.

D3: Constraint: Products and Services from our Corporation, Our customers and Partners are preferred. <- Corporate Policy 5.4

Dependency Concept *189 February 5, 2003

A ‘dependency’ is a reliance of some kind, of one set of components on another set of components.

Notes:

1. Any given component can be part of numerous dependencies (either having one or more dependencies, and/or having one or more dependencies placed on it).

2. The reliance involved in a dependency can be of many kinds. For example, there can be dependency for operation, for success, or for failure avoidance.

3. Qualifiers specify implied dependencies.

4. The parameter, ‘Dependency,’ or its synonym, ‘Depends On,’ is used to explicitly specify a dependency.

Examples:

Z [T]: YY.“Only if T is true, does Z have a value of YY.”

A: Depends On: B.“If B is not true then A is not true.”

Tag A:

Dependency: XX.“Tag A has a dependency on XX.”

Example:

Goal [Contract Beta]: 60%.

This means that the Goal level requirement of ‘60%’ is valid as a Goal, if and only if, ‘Contract Beta’ is ‘in force’. The Goal has an implied dependency on the qualifier, ‘Contract Beta’.

Example:

Dependency: The satellite must be operational for the phone to operate. <-Catherine.

Example:

Dependency XX: Design Idea XX Reliability [USA, If Patent PP].

Example of dependency of an objective (Reliability [USA]), on both a design idea (Design Idea XX) and a condition (Patent PP):

= ‘impacts’.

This is a ‘weak’ dependency statement because we have no specification of whether the dependency is trivial or critical in degree. A numeric impact estimate could be used to give us that information, later, if we wanted it.

Example:

Tag: Refugee Transport.

Type: Function.

Description: Moving refugees back to home villages.

Source: Charity Aid Manual [March, Last Year].

Depends On: The mode of transport will be determined by safety and cost factors.

“Or the equivalent:

Dependency: The mode of transport will be determined by safety and cost factors.”

Example:

Contract Beta: Depends On: Conglomerate Corp [Our Customer, USA].

This means that if ‘ Conglomerate Corp [ Our Customer , USA ]’ is not true, then ‘ Contract Beta ’ is not ‘true’.

Rationale [Dependency *189]: To promote awareness of relationships, ensure more realistic planning, and provide the ability to identify reliance, and therefore cope with any associated risks.

Synonym [Dependency *189]:

Related Concepts [Dependency *189]:

Type [Dependency *189]: Parameter [Relationship].

Depends On: Concept *189 . July 24, 2001

This parameter expresses an explicitly defined dependency.

Type: Planguage parameter.

Synonym: Dependency (which can be used as the Parameter if you prefer).

Format:

A: Depends On: B

If B is not true then A is not true.

A Tag.

Dependency XX. “A Tag Depends On XX”

Example:

Contract Beta: Depends On: Conglomerate Corp [Our Customer, USA].

This means that if “Conglomerate Corp [Our Customer, USA]” is not true, then “Contract Beta” is not ‘true’.

‘Implicitly defined dependencies’ use qualifiers, rather than explicit parameters like Depends On.

Deployment Concept *358 March 8, 2003

‘Deployment’ means actually delivering an Evo step to a set of stakeholders. Deployment is the last stage of a Delivery Cycle.

Figure [Deployment *358]: Deployment is the last stage of the Delivery Cycle.

Notes:

1. An Evo delivery cycle can consist of these tasks:

  • Planning the delivery cycle including deployment
  • Training Evo step recipients ready to use the upgraded system
  • Upgrading the on-site system

(for example, upgrading software, database and/or hardware)

  • Upgrading of supplier support activities to support the upgraded system

(such as help desk, maintenance services, spare parts supply)

  • Carrying out field trials of the upgraded system, before scaling up and/or ‘going live’
  • Evaluating field trials, and making decisions about full-scale deployment
  • Deployment: Handing over to users/customers/stakeholders, operations, data gathering: achieving full scale deployment

Note, these are just examples. The actual delivery cycle tasks depend on exactly what is being deployed, the scale of the deployment, and the risks involved.

Related Concepts [Deployment *358]:

Type [Deployment *358]: Process.

Derived (adjective). Concept *449 July 30, 2001

Something resulting from processing other information according to defined rules.

Note 1. A derived requirement is a specific requirement obtained by a generic requirement applied to a local range. For example: if a Generic Constraint says: we shall always be better in reliability than competitors, then the exact specification, for example:

Reliability:

Scale: Mean Time to Fail.

Past [Competitor X, Current Product] 20,000 hours.

Goal [Our New product] 30,000 hours.

The Goal level is the derived requirement.

Derivative Source. Concept *450 July 30, 2001

The source of the Derived ( *449) specification or plan.

Synonym:

  • Derivation, 450.

Warning this term (derivation) should be avoided because it can also mean the Derivative (452) and the act of deriving. It is uselessly ambiguous!

Note1. The ‘source’ implies the resource and the rule for conversion into the derivative.

Derived Constraint. Concept *451 . July 30, 2001

A specific local constraint derived from a Generic ‘template’ Constraint or Global ‘wide scope’ Constraint.

Derivative. Concept *452 . July 30, 2001

The thing derived from its Derivative Source. ( *450).

Note 1. Source is the initial information or resource, and some rules or process for derivation.

Descendant. Concept *268 .DescendantJuly 25, 2001

An artifact descended from another artifact; immediately, or via several levels of process.

A Kid is always a descendant of a Parent . A design could be the descendant of a set of requirements.

Description Concept *416 18 April 2004

A description is a set of words and/or diagrams, that describe, and partially define, a component.

The parameter ‘Description’ (or synonyms, Detail, Detailed Description) is used to specify description.

Notes:

1. A description will convey the essence of a concept, or of a specification, but the full definition of the element may well require many other parameters to define it fully (from all interesting viewpoints), including implied or inherited definitions from other system components.

2. Models, real systems and prototypes can also provide a form of ‘description.’

Example:

Mechanical Power :

Type: Function.

Assumption: At least 100 horsepower.

Constraint: Product Cost is lower than €500.

Risk: Last of European Commission Development Funding .

Version: March 1, This Year .

Description: The mechanical component that will provide all mechanical power to the system.

Note that the function description is only one part of the full function definition of ‘Mechanical Power’.

Synonyms [Description *416]:

Detail [ *416]

Detailed Description [ *416].

Type [Description *416]: Parameter.

Design Constraint Concept *181 May 5, 2003

A design constraint is an explicit and direct restriction regarding the choice of design ideas. It either declares a design idea to be compulsory (Mandatory Design) or to be excluded (Prohibited Design).

Design constraints are dictated from an earlier system development stage (a higher level or a more specialized level). For example, the system architects pass on a number of design constraints, within the architecture specifications, to the system engineers.

A design constraint is a binary requirement. It can be a generic constraint or involve specific design(s).

Examples:

================ Prohibited Designs ==========

P1 : Constraint: Products and services of direct competitors shall be avoided.

P2 : Constraint: No software product version shall be released for sale until at least 3 month field trial has completed reporting no major faults outstanding. <- Technical Director’s Policy 6.9 .

P3 : Constraint [ Europe ]: No goods will be shipped without advance payment or bank guarantee.

============= Mandatory Designs ==============

M1 : Constraint: Resident workers in country of export shall be used wherever possible.

M2: Constraint [ IT Projects , In House ]: Commercial Off The Shelf Software shall be used exclusively.

M3 : Constraint: Products and Services from Our Corporation , Our Customers and Partners are preferred. <- Corporate Policy 5.4.

M4 : Constraint [ Programming ]: Use Java as Programming Language .

Notes:

1. Some people use the term ‘Design Constraint’ to mean anything that constrains the choice of design. However, within Planguage, the term is more restricted. It is a direct constraint on design ideas themselves; directly referring to design ideas, generically or specifically. All other types of requirements ‘constrain’ our choice of design, but not as directly as a design constraint.

Indirect Constraints:

A Resource Constraint determines resource, and so impacts optional design.

A Performance Constraint determines performance, and so impacts optional design.

A Function Constraint determines function, and so impacts optional design.

A Condition Constraint determines conditions, and so impacts optional design.

Direct Constraints:

Design Constraints determine design directly, by specifying a mandatory design or a prohibited design.

All requirement types: targets and constraints - have some potential effect on our design choices. But, design constraints are ‘direct’ in the sense that they make specific design decisions.

Example:

Spruce Goose :

Type: Generic Design Constraint.

Definition [If Wartime ]: A troop transport plane may not use scarce <metal alloys>.

Howard Hughes’ airplane, ‘The Spruce Goose’, had this design constraint before the end of the Second World War. He made the plane largely of ‘spruce’ wood.

2. Only designs that are ‘design constraints’ should be allowed within requirement specifications. All optional design ideas, designs you can swap out if you find a better one, should be specified in design specifications. This is so that each level of design responsibility knows what it is free to do, and not free to do.

Synonyms [Design Constraint *181]:

  • Architectural Constraint *181
  • Design Restriction *181
  • Constrained Design: Informal Use
  • Required Design: Informal Use
  • Solution Constraint: Informal Use

Related Concepts [Design Constraint *181]:

Keyed Icon [Design Constraint *181]:

[< Design Idea Tag> ]“The same icon as for a design. Alludes to a rectangle. [____].”

[Editor Note to Publisher, the underline MUST be included in the above term with Design Idea tag. “ Design Idea Tag ” IS ALSO A USER DEFINED TERM, LIKE OTHER UNDERLINED TERMS]

Drawn Icon [Design Constraint *181]: A rectangle within square brackets.

Type [Design Constraint *181]: Constraint.

Design Content Rules *593 July 20, 2002

Design rules state expected design practices.

Design (content) rules give advice on best practices, and recommended practices, when designing (or architecting or design engineering, or finding means or strategies). Deviation from design rules should be the basis for a design review.

Unjustified violation of design rules are classified as design defects. These should not be confused with design specification defects, which are about how clearly a design is written up – not about its content or essence.

The density of design defects should be the basis for quantification of design quality. It should also be the basis for Entry to other processes of a design spec, and Exit from design processes of a design specification.

Related Concepts [Design Rules, *593]

  • clarity rules [Design Idea] *129 rules about how articulate a design idea
  • design specification *586 – the spec which needs to be both written and judged according to the design rules.
  • review criteria *541 – Design Rules are one class of Review criteria

Design Engineering Concept *501 July 18, 2003

Design Engineering is an iterative process of determining a set of designs, with rigorous attention to quantified and measurable control of their impact on requirements.

The design engineering process implies the matching of potential and specified design ideas with quantified performance requirements, quantified resource requirements, and defined design and condition constraints.

Notes:

2. The design engineering process can be subdivided into the following sub-processes:

a. design requirements entry: all relevant requirements to the design task are complete, clear, quantified, testable, validated by stakeholders, quality controlled, reviewed, and have thus obtained formal entry into the design process.

Related Concepts [Design Engineering *501]:

Type [Design Engineering *501]: Discipline [Systems Engineering].

Design Idea Concept *047 January 7, 2004

A design idea is a concept that is intended to satisfy some requirements.

A set of design ideas is usually needed to solve a ‘design problem’.

Notes:

1. A design specification is a written definition of a specific design idea. A template for design specification is given in Figure 7.6.

2. A design idea is not usually a requirement. A design idea can, in principle, be changed at any time for a ‘better’ design idea (without having to ask the permission of any stakeholders because the system designers are responsible for the proposed design ideas). A ‘better’ design meets the requirements by giving more performance and/or less cost.

Requirements are inputs into a design process; design ideas are the outputs.

Note: A design can be a requirement if it is a design constraint. That is, a specific design is stated as mandatory or prohibited in the requirements.

3. A satisfactory design idea can have some negative performance scalar impacts, and still be acceptable overall. As long as the negative impacts (negative side effects) of a design idea do not prevent us from reaching all the required Goals levels, the design idea can be used.

Synonyms [Design Idea *047]:

Related Concepts [Design Idea *047]:

Keyed Icon [Design Idea *047]:->@ or ->.@

This icon symbolizes Impact (->) on a target (@) which is what design ideas ‘do’.

Graphic Icon [Design Idea *047]: A lying-down rectangle. (The standing rectangle is a document icon.)

Type [Design Idea *047]: Parameter, Design.

Design Problem:( Concept *048 ) March 15, 2003

A design problem is expressed as a requirement specification that includes a ‘complete set’ of valid targets and constraints, together with updated information about the degree of satisfaction in the design or the implementation. A design problem is the ‘set of gaps’ (to meet required levels) that remain to be designed for.

Note 1. We assume that the designer does not yet contain or have access to sufficient design solutions to reach all their targets, within all specified constraints, otherwise there would be no ‘problem’ remaining.

Note 2. Under Evolutionary Project Management, the design problem will evolve as the project progresses. Each new design idea, when implemented at an Evo step, will have a set of cumulative impacts on different requirements. The then remaining set of unsatisfied requirements (‘gaps’) become the new ‘design problem’.

Note 3.

On the notion of a ‘complete set’ of requirements in problem definition.

A simplified design problem could be formulated using one or a few requirements or constraints, just to see if that were technically or economically feasible at all. But the real design problem must be solved using all valid requirements. If this is impossible, then perhaps some of the requirements need to be realistically ‘relaxed’ to allow some of the others to be satisfied at all.

Short form: Problem.

Keyed icon [Design Problem, *048]: -----<===>---> (The gap between < a past and > a target is an iconic symbol of a design problem)

O------------<-----------|=====The Gap===>------->

The progress from the Benchmark (<) to the current level (|) leaves a Gap (==) to the Target (>). This illustration brings in the idea that there has been some progress (‘<-------|’) since initial requirements were specified (‘-<-‘) , in delivering some degree of requirements target satisfaction using some design ideas. The gap (‘|====>” represents the remaining problem with this particular dimension of a requirement.

Synonyms: Design Target, residual system requirements, design gap, gap *359 (a single instance of a gap amongst many which constitute the total design problem).

Related Concepts [Design Problem *048]:

Type [Design Problem *048]:Engineering Concept.

Design Process Concept *046 July 18, 2003Btg

The design process is the act of searching for, specifying, evaluating and selecting design ideas, in an attempt to satisfy specified stakeholder requirements.

Design is finding a set of solutions (design ideas) for a set of defined requirements.

Overview of the Design Process

  • Analyze the Requirements
  • Find & Specify Design Ideas
  • Evaluate the Design Ideas
  • Select Design Ideas & Produce Evo Plan

Design can be carried out in several ways. It can be based on tradition, on intuition, on dogma, on principles or heuristics. It can also be based on multidimensional quantified logic – this latter we would call ‘engineering’ or ‘systems engineering’.

“Design comes about entirely from the playing out of the evolutionary algorithm.”

Blackmore in ‘The Meme Machine’ (See page 205)

Notes:

1. The design process can be subdivided into the following sub-processes:

a. Acquire stakeholder requirements.

b. Identify candidate designs

c. Tailor candidate designs to current purpose

d. Decide on a finite set of designs.

e. Do design review.

f. Implement designs in development system and test their validity.

g. Revise Design if necessary.

h. Implement designs in final system.

“Heuristic: At some point in the project, freeze the design. …..

This rule of thumb recognizes that a point is often reached in design where the character of a project, and hence the appropriate allocation of resources, changes from seeking alternative solutions to perfecting a chosen solution. …. After this point is reached, a major design change runs the unacceptable risk of introducing a fatal flaw because insufficient resources remain to evaluate all of its ramifications.” Source: Koen03, p.35

This quotation refers to b. (Identify) and c. (Tailor) above. It reminds us that the design process is not merely one of finding a design, and analyzing it. The selected design is likely to be generic in nature, or was applied in a different set of circumstances than the current project. So, we must expect to ‘perfect the chosen solution’ so that it better fits the current requirements and environment.

2. The reader might like to compare this simple design process with the corresponding design engineering process ( *501 note 2). The design engineering process is characterized by rigorous use of quantified information. It takes a clearer position on ‘how’ to design. The design process decomposition above specifies ‘what’ is to be done, but does not specify ‘how’.

Related Concepts [Design Process *046]:

Type [Design Process *046]: Process.

Design Specification Concept *586 May 29, 2003B

A design specification is the written specification of a design idea.

A set of design specifications is the main output of a design engineering process.

A specific set of design specifications, when implemented, will, to some degree, meet the stated requirements.

Notes:

1. A set of design specifications attempts to solve a design problem. Identification and documentation of the individual design ideas, and their potential contribution towards meeting the requirements, helps selection of the ‘best’ design ideas for implementation.

2. The design engineering process uses the requirement specification as input. The design engineering process output is a set of design (solution) specifications (of design ideas). These design specifications might also contain information about their expected attributes for meeting requirements. This ‘expected attributes’ information of a design specification might be in the form of an Impact Estimation table or, it can be as simple as an assertion of impacts on requirements, referenced by their tags (see example below).

Example:

Engineer Motivation :

Gist: Motivate, using free time off.

Type: Design Idea.

Impacts [Objectives]: { Engineering Productivity , Engineering Costs }.

Impacts [Costs]: { Staff Costs , Available Engineering Hours }.

Definition: Offer all Engineers up to 20% of their Normal Working Hours per year as discretionary time off to invest in Health , Family and Knowledge ( Studies , Write Papers , Go to Conferences ).

Source: Productivity Committee Report 1.4.3 .

Implementor: Human Resources Director .

Template [Design Specification *586]: Design Specification Template.

Abbreviations [Design Specification *586]:

Synonyms [Design Specification *586]:

  • Technical Design: Informal use
  • ‘The Design’: Informal use

Related Concepts [Design Specification, *586]:

Keyed Icon [Design Specification *586]: []->@

This icon can be interpreted as a specification, ‘[]’ which impacts, ‘->’ target, ‘@’.

Type [Design Specification *586]: Parameter, Specification.

Design Target: Concept *338 March 15, 2003

A Design Target is the specific target level, including qualifier, of an attribute requirement that is being worked towards, in the design or implementation process.

Usage 1. The designer uses a set of such design goals, including budget targets, as well as constraint information, to decide if they have found good enough design ideas to satisfy the performance requirements, within the constraints specified.

Keyed icon [Design Target, *338 ] :----> <level spec> [<qualifiers>].

The target level plan (or other target symbols) symbol, coupled with the qualifier

Example:

O-------------------->6,000 Hours MTBF [Release 6.0, US Market]----->. Reliability

Example:

Fail [End Next Year] 30. “a design constraint”

Goal [Within 6 Months After Launch] 60. “a design target”

The target is not merely the ‘60’ but includes the [qualifier] information.

In addition, the Fail and Goal specification both give critical information about the priority of the target (design survival point (Fail) and success point (Goal)).

Usage 2. It is normal engineering practice for a designer to apply a performance target level with a built in safety factor, as the level they try to design for; for example two times the nominal specified level might be applied as the safety factor target. The Impact Estimation process makes use of this safety factor concept.

Usage 3. A design target may be specified using one of the target specification parameters {Goal, Stretch, Wish}. This applies to performance and budget targets.

Example:

Stretch [Next Release ] 66.5 hours.

Related Concepts [Design Target *338]:

Benchmark *007

Performance Target *439

Qualifier *124

Budget Target *481

Condition Constraints *498

Type [Design Target *338]: Requirement Level, Target

Design To Cost Concept *472 July 17, 2003

‘Design To Cost’ is an engineering strategy of consciously selecting design ideas, which will allow you to stay within any and all resource budgets.

Related Concepts [Design To Cost *472]:

Type [Design To Cost *472]: Design Strategy, Process.

Designer Concept *190 May 6, 2003

A designer is a person or group who specifies design ideas, in an effort to satisfy specified requirements.

Notes:

1. This is a generic term. More specific terms include systems engineer, planner, or systems architect.

Synonyms [Designer *190]:

Related Concepts [Designer *190]:

Type [Designer *190]: Role.

Development Cycle Concept *413 December 27, 2002

A development cycle is an optional backroom cycle, within the result cycle of Evo. It is concerned with acquiring/purchasing and developing, any products required for the production and/or delivery cycles.

For example, any new systems development would be carried out within this cycle.

Type: Process.

Deviation Concept *475 November 7, 2002

Deviation is the amount (estimated or actual) by which some attribute differs from some specific benchmark or target. Deviation is usually expressed numerically using either absolute or percentage difference.

Synonym: Variance.

Keyed Icon: ±

Type: Systems Engineering concept.

Domain: Systems Engineering.

Diagram: Concept *228 . July 26, 2001

A set of icons, symbols and terms, which pictorially explains how something works, or tries to clarify the relationship between parts of the whole.

Dialect;: Concept *204 . July 26, 2001

A ‘Dialect’ is a local variation in Planguage symbols or terminology due to local culture, habit, traditions or language variation.

Local culture can be a project, a division, a company, a charity, a national language group: any group which feels the need for variation or specialization in relation to a defined set of Planguage .

Type: Planguage class.

Synonym: Planguage dialect, local (Planguage) dialect, project (Planguage) dialect

Direct Constraint Concept *510 . November 21, 2001

Any constraint which is specified in the format of a constraint, and is intended to directly constrain performance, function, costs or design.

Type: Constraint.

Domain: Requirement.constraint.direct.

Related Concepts:

  • Indirect Constraint, *511. Any other (than direct constraint format) specifications which have the effect of restricting the solution space, or designer’s choice. This includes Goal (all targets) , Authority (all priority-giving parameters) and [qualifiers] for example.

Do [PDSA] Concept *170 January 21, 2003 B

Do [PDSA] is part of the ‘Plan Do Study Act’ Cycle (See Plan Do Study Act Cycle *168). It involves implementing (Do…ing) what you have planned, that is, carrying out the ‘experiment’ to see how your plan measures up to reality.

In Evo, it is the step implementation.

Related Concepts [Do [PDSA] *170]:

Keyed Icon [Do [PDSA] *170]: There is no keyed icon specification for Do [PDSA].

Icon [Do [PDSA] *170]: Do is the north side of the rectangular process symbol.

The four corners of the process Drawn Icon stand for the Shewhart process-cycle definition of ‘Plan Do Study Act’.

Type [Do [PDSA] *170]: Process.

Domain [Do [PDSA] *170]: SPC.

Document: Concept *180 . March 13, 2003 B 23:05

A document is a readable instrument for containing and conveying ideas of any kind.

Related Concept

Note 1. A document may be printed on paper or stored electronically and displayed on a screen or on paper. Document types include absolutely any readable information including machine-intelligible artifacts like computer source code and test scripts. A document does not have to be easily readable by unaided humans.

Note 2. All ‘documents’ are not necessarily any kind of system ‘documentation’ (specification), in the conventional (“stuff designed to describe something”) sense of the word. Nor is all ‘documentation; in the form of documents. For example a real machine, prototype, or pilot organization, can be used as ‘documentation’ of something. But this information (that machines or organizations have) is not in the form of a written document.

Icon [ *180, Document] : standing rectangle (a standing sheet of paper), the bent paper corner in the lower right corner is a nice and desirable touch for intuitive clarity, but is optional. It is found in Microsoft Basic shapes.

Keyed Icon [ *180, Document] : [] (made by [ & ], looks like upright page)

Tyoe [ *180, Document] : <?>

Documentation: Concept *579 . July 12, 2002

Documentation is written information that teaches people how to use systems.

Documentation refers to descriptions of systems for people, such as analytical documentation, instructional documentation (courseware), operational documentation.

Related Concepts [ *579 Documentation].

  • specification *137 Documentation is a class of specification, teaching people how to use a system.
  • planware *579 a class of information about human intentions (like design, requirements)
  • dataware *576 data intended for computer consumption, not human instruction
  • data *319 any signal which can be sensed, but not just those for human instruction
  • infoware *578 documentation is a class of infoware.

Domain Concept *374 March 5, 2003 A tg

A domain is a major field of influence or responsibility for a defined subject.

Notes:

1. Domains are declared for many reasons. These include:

  • Domain classification can be used to assign responsibility for specifications of a certain domain type, to stakeholders who are interested or responsible for those domains.

  • Domains can be used to understand who is the relevant authority for change or approval.

  • Domains can be used to focus attention on any interesting set of ideas for learning or exposition purposes.

“A field or sphere of activity or influence” (Webster’s)

Synonyms [Domain *374]:

Related Concepts [Domain *374]:

Type [Domain *374]: Specification Type.

Downstream Concept *052 November 21, 2002

Relative to an given process, ‘downstream’ refers to any processes, which are carried out later, and implies that they are impacted in some way by that upstream process.

Usage: ‘Customer use’ is downstream from ‘pilot testing’.

Rationale:

Interest in the downstream concept stems from two ideas:

1. The costs of fixing defects, which get injected upstream, become, on average, one or two orders of magnitude worse when we encounter them downstream during test or in the field.

2. The value of both ‘early quality control’ and of’ process improvement in upstream development stages’, is a function of the potential downstream damage, which apparently-small upstream defects can cause. (Compare to the ‘Butterfly Effect’ in Chaos Theory).

Parameter: Downstream. Long form = Downstream From

Keyed Icon: <~ A <~ B means A is downstream of B

Notice similarity with source arrow. Upstream is source or downstream pollution.

Example:

Goal [Processes <~ Systems Test] 99.5% “means the Goal level is for processes downstream from Systems Test.”

Type: Parameter [Relationship].

Domain: Process.

DPP Concept *042 November 13, 2002

Abbreviation for Defect Prevention Process.

Drawn Icon Concept *085 February 27, 2003 tg

A drawn icon is a defined graphic symbol, or pictorial representation of a Planguage concept, constructed by drawing, rather than keying.

Keyed Icons are a sub-class of icons. They are constructed entirely by keying keyboard symbols.

For example:

A process

A system

Related Concepts [Drawn Icon *085]:

Type [Drawn Icon *085]: Symbol.

Due Concept *554 March 7, 2003

‘Due’ is a specification parameter indicating when some aspect of a specification is due.

Example:

Due [Sample A]: End of January Next Year <- Contract Section 3.5.6 [Supplier X].

Synonyms [Due *554]:

Type [Due *554]: Parameter.

Historical Note: The idea of ‘Due’ as a parameter was from an unpublished note by Jens Weber, Damlier Chrysler, Frankfurt.

During Concept *314 February 5, 2003

‘During’ is a specification parameter used when specifying events (including Evo steps and tasks) to indicate a time dependency for events that must be carried out concurrently (that is, done in parallel).

Example:

Step33: Step: {A || B During C}. “Do A, B and C concurrently.”

Step34: Step: {C [If not B||C [Step33]}. “Do step C if B was not in fact done during step C in Step33.”

The choice of using the keyed icon ‘||’ or ‘During’ is a matter of taste. Both are shown here for the sake of example.

Keyed Icon [During *314]: || as in A||BA is done in parallel with B.”

Type [During *314]: Logical Operator.

Dynamic Concept *465 February 25, 2003

Dynamic means something happening in real time.

Antonyms [Dynamic *465]:

  • Passive
  • Static

Type [Dynamic *465]: Adjective.

Edit [SQC] Concept *288 November 20, 2002

The Edit sub-process of SQC primarily attempts to correct a specification by removing identified defects. The Edit process includes any defined Edit process activity, such as sending messages to other specification owners about possible problems with their specification.

Notes:

1. The specification writer (an SQC team member and also a checker themselves), usually carries out the Edit sub-process on their own. If the specification writer is not available, then someone else undertakes the editing task, and they are the editor.

2. The primary input to editing is the Editor Advice Log, which is produced by the SQC team during the Specification Meeting. Secondary inputs are all documents, which participated in the SQC Checking process, and any notes (‘scratchings’), which checkers made but chose not to formally log.

3. The editor reads the issues in the Editor Advice Log and makes corrections wherever they find and agree that there are defects requiring correction in the main specification. They can choose to correct far more defects than were reported, based on the stimulus of the sample of defects presented to them. They can also choose to not fix things, which they judge are not major defects. They should somehow try to bring the specification to an exit-able defect level.

4. Where the authors or process owners of any other documents involved in the SQC are concerned, other reasonable action has to be taken, such as sending out change requests. The editor is at liberty to search (and take appropriate action) for other defects, not reported, anywhere in the specification set.

5. The Edit process is reviewed, and ultimately approved, by the team leader in an SQC sub-process called ‘Edit Audit.’ More detail can be found in [GILB93] (See ‘Editing’ and ‘Follow up’).

Type: Process.

Domain: SQC.

Edit Audit [SQC] Concept *289 November 20, 2002

Edit Audit is an SQC sub-process, carried out by a team leader, to verify that reasonable and complete editing has been done.

Note: Edit Audit will try to make sure that valid main specification rules, the editor advice log, relevant editing and specification procedures, and main specification sources have been reasonably heeded when editing the specification.

Synonym: ‘Follow up’.

Related Concepts:

Type: Process.

Editor Concept *277 November 20, 2002

During the Edit sub-process of SQC, an ‘editor’ is a person who evaluates issues (and other Editor Advice Log information) and takes appropriate action on them.

Note: The appropriate action might include correcting something if the issues are defects, or sending change requests to other document owners if action needs to be taken at that level.

Type: Role.

Domain: SQC.

Editor Advice Log Concept *296 November 20, 2002

An Editor Advice Log is written formally by a scribe at an SQC Specification Meeting. It is based on oral reports from checkers.

Notes:

An Editor Advice Log contains three types of items: issues, improvement suggestions, and questions of intent for the specification writer. The log is written with no debate, discussion or consensus, irrespective of other teammates’ opinions. It is written in a ‘brainstorming’ mode (volume now, analysis later).

The log is the primary input to the Edit sub-process, where the editor (usually the writer and owner of the specification) seriously evaluates each item. The editor makes all possible corrections to their specification, according to best available rules and sources, in all parts of the specification, not just the sample or chunk reported on during the Specification Meeting.

An Editor Advice Log is only written when the Specification Meeting entry process decides it is worthwhile. It would not be worthwhile if too many or too few major defects were found in checking. Nor would it be worthwhile if the checking process had not been done properly, such as at ‘too fast a checking rate.’ In cases, where ‘no logging’ is chosen, there is the option of giving the specification writer/editor the ‘scratchings’ (informal notes made by checkers during their checking work). This is a practical way of giving the specification writer /editor some advice without taking any time for writing a formal log. There is even an additional option of doing a partial log as a sample of issues for the writer/editor, without necessarily logging all the discovered issues. This can then be supplemented by the ‘scratchings’.

Synonyms: Issue Log, Author Advice Log.

Type: process output specification.

Domain: SQC.

Effect Concept *441 July 26, 2001

The result (‘the effect’) of using a system performance attribute (the ‘cause’) .

Formally:

  • the differential value to a defined stakeholder,
  • caused by a defined level of a defined system attribute,
  • acting on a defined stakeholder,
  • in a defined stakeholder environment.

More simply and less formally: an effect is the stakeholder joy from a system performance attribute.

Notes:

Note 1. The effect is the result of using a system performance attribute created in one system, as input to another system or process. It is an output or performance attribute of that second system or process.

Instances:

  • how does 99.98% availability effect a stakeholder who has been accustomed to 95% availability, and is quite satisfied with that level for their purposes. The stakeholder would not pay anything more for an increase beyond 95% availability?
  • in a second case, another stakeholder with the same old and new system situation as above, but with different ‘customers’ might be losing 5% of their business because of the lack of availability, and would be willing to pay what it was worth, in increased sales ability, to get higher availability.

(S1)------P<-------> Q Q ----------|P-------->(S2)------e1<------E1<-----E2<----->PL

A level of performance P is produced for quality q in system S1. This performance level (P) is used in system S2 and results for some stakeholder (1) in the effect E1 (like more sales) and for another stakeholder (2) in a different effect ‘E2’. The effect could be stated in direct terms (€ Sales) or relative to some stakeholder benchmark like % increase in sales over e1)

Keyed Icon: any benchmark or generic level of performance. For example

O----|---->, or O-----<-----<<----->

Source: of concept Kai Gilb, End 2000

Effectiveness Concept *053 April 26, 2003

Effectiveness is a measure of how good the current attributes of a system are at delivering the stakeholders’ current demands of the system.

Effectiveness is a raw measure of impact, and does not contain information about the costs of making that impact (performance in relation to cost is the role of an efficiency measure).

In ISO 9000:2000 ...

Effectiveness - extent to which planned activities

are realized and planned results achieved.

Efficiency - relationship between the result achieved

and the resources used.

Notes:

1. Several ‘measures of effectiveness’ can be defined. Actual achievement of benefits compared to expected benefits is one possible measure.

Related Concepts [Effectiveness *053]:

  • Performance *434
  • Measure of Effectiveness *486: See also [SPROLES02].
  • Benefit *009
  • Measure of Performance *482: A measure of performance (MOP) considers only the effectiveness of a set of performance attributes: A Sum of Performance for a delivered Evo Step can be used as such a measure. See also [SPROLES02].
  • Sum of Performance *008
  • Efficiency *054

Type [Effectiveness *053]: Metric.

Efficiency Concept *054 April 28, 2003 tg

Efficiency is ‘effectiveness’ in relation to cost.

Example:

The defect detection efficiency of the Specification Quality Control (SQC) process is about ‘one major defect found and fixed’ per ‘work-hour invested’. This compares well to the downstream testing and rework processes (debugging), which are an order-of-magnitude less efficient, and even more, the downstream field rework costs, which are two orders of magnitude less efficient.

Sources: [GILB93, WHEELER96].

Notes:

1. A benefit to cost ratio or a performance to cost ratio would be a measure of efficiency.

Synonyms [Efficiency *054]:

  • Cost Effectiveness *054

Related Concepts [Efficiency *054]:

  • Effectiveness *053
  • Performance to Cost Ratio *010

Type [Efficiency *054]: Metric.

Efficiency (noun adjective): Concept *394 April 1, 2003

The noun adjective ‘Efficiency’ can be used to refer to any set of Performance to Cost Attribute ratios .

For example: ‘Efficiency Attributes, Efficiency Requirements, Efficiency Benchmarks, Efficiency Targets, and Efficiency Records.

Type [Efficiency (noun adjective) *394]: noun adjective, metric concept.

Effort: Concept *368 . July 26, 2001

Human-energy task cost.

The human resources needed to accomplish something.

Related concepts:

  • Resources (which is much broader in the set of possible resources than Effort. Effort is intentionally narrowed to human effort).,
  • Engineering Hours (a common measure of effort).,
  • Work hours (a measure of effort, and a politically correct form of the traditional ‘man hours’)

Type: quantification concept.

Scale:

Effort: Scale of measure: the defined [type of effort, default = engineering hours] needed to accomplish a defined [task].

Usage Example:

HP does Platform Development ‘Product Portfolio Planning’ by defining a ‘target effort savings’, meaning “the platform will reduce product investment by X engineering months”

[JANDOUREK96 , page 61]

Keyed icon: the resource icon with any useful benchmark and target icons. For example:

------p<------>>m---]c--->O

p = Past level of the effort, m = Fail limit of the effort, c = a limit constraint,

------>O is the resource scale, defined in terms of human effort.

In ISO 9000:2000 ...

Efficiency - relationship between the result achieved

and the resources used.

Element Concept *022 February 5, 2003

An element is any identifiable individual part of any set.

Note: An element can itself be composed of other elements. It can be complex: element does not imply elementary (See Elementary *055).

.

Synonyms: *022

Type: structure descriptor.

Note 1. An element can itself be composed of other elements. It can be a Complex element.

Element does not imply Elementary ( *055).

Keyed Icon: *022

X {y}. meaning y is included in X

Related Concepts *022

  • Consists Of *616
  • Includes *391 Includes can give a partial list of contents.

Type: Specification Object

Elementary Concept *055 February 1, 2003

An ‘elementary’ component is not decomposed into sub-components.

Notes:

1. A component can be elementary because it is unable to be decomposed into sub-components, or because there is no declared intent to decompose it.

2. The decision to sub-divide a complex concept into elementary concepts is a practical and economic matter. It depends on:

  • the size and complexity of a project,
  • the need for precise control over system attributes,
  • the risks taken if specification detail is inadequate,
  • engineering culture,
  • intellectual ability to decompose,
  • other factors

Even when an initial decision is made about having no further decomposition of an idea, later events and opportunities, or later more detailed phases of systems engineering, may cause a concept to be decomposed into elementary concepts.

The reverse can be true too. Initial decomposition may seem unnecessarily detailed or unnecessarily constraining. So, the concept may be simplified from a complex concept back to an elementary concept.

3. The essential characteristic of scalar attributes, which tells us if they are elementary, is the number of defined scales of measure. There is only one distinct Scale for each elementary concept.

4. Elementary concepts are directly measurable or testable. You can only test or measure a complex concept by way of testing and measuring the set of its elementary concepts. A complex concept is not the ‘sum,’ but the ‘set’ of its elementary concepts.

5. Normally an elementary statement can have its own distinct ‘tag’, and can be treated {developed, tested, costed, quality controlled} relatively independently of any other elementary statement.

Related Concepts [Elementary *055]:

Type [Elementary *055]: Adjective.

Ends: Concept *316 . August 17, 2001tg2013

‘Ends’ is a Planguage parameter that specifies a condition that a defined term has completed successfully (is true).

Type: Planguage parameter.

Usage: to indicate sequential priority in planning time consuming events such as Evo steps.

Related Concepts:

  • Starts 315 Icon ‘*’
  • Before *312 Icon =>
  • After *313 Icon =>
  • In Process *113 ^

Examples:

Peace [X Starts Before A Ends] … meaning X must be started before A ends or completes successfully.

Peace [X * => A •] same as above iconically

A* A Starts

A• A Ends

A^ A is in Process (after * and before •)

A^ => B• A is in Process Before B Ends

Step23: XX [XX After A Ends] ... meaning XX will only start when A is completed.

Keyed icon [Ends]: ‘•’

Examples of ‘’ (Icon for Ends)

X [X => A ]

Meaning X must be started before (=>) A ends or completes successfully (•).

Step23: XX [A ]

Meaning XX is only to be planned to start when A is completed [A•].

‘A Ends’ (A•) is a condition for XX to be ‘true’ as a step plan.

It is implicit in Evo planning that reference to a function, or a design idea, specification implies the implementation of that function or design idea. It is obvious that a complete and correct implementation of that specification is a condition for ‘Ends’.

End: Concept *100 . July 26, 2001

Future requirement or objective. Desired end state.

Generic synonym for *100.Objective.

Related Concepts: Means, *047 (the way to reach the ends).

@ Keyed Icon (same as Objective @, *100).

Note for the more-specific concept of Goal or Target, use the set of target icons like

------|--->>--->---->.

“Think well to the end”

“Consider first the end”

Quoted in Gelb: How to Think Like Leonardo da Vinci, p. 243

Engineering Concept *224 June 28, 2003

Engineering is

  • an Evolutionary Process,
  • using practical Principles,
  • in order to determine,
  • and identify the Means to deliver,
  • the best achievable Performance and Cost levels balance,
  • for optimal Stakeholder satisfaction,
  • in a complex risk-filled environment.

"The Engineering Method is the use of heuristics to cause the best change in a poorly understood situation within the available resources"

"Engineering is a risk-taking activity. To control these risks, engineers have many heuristics:

1. They make only small changes in what has worked in the past,

2. They try to arrange matters so that, if they are wrong, they can retreat, and

3. They feed back past results in order to improve future performance."

"Engineers cannot simply work their way down a list of steps, ... but ...

they must circulate freely within the proposed plan ..."

Prof. Billy V. Koen, Univ. of Austin, Texas [KOEN84, KOEN03]

Notes:

1. Here is my rephrased version of Koen's definition of engineering:

(It is a variation on my definition above).

"Engineering is the use of principles in a systematic way,

to find designs,

that deliver the value requirements,

within resource constraints,

under conditions of uncertainty".

Some Comments on this Definition:

  • 'Principles' are rules of thumb that guide the choices and actions of engineers. Principles are not rigid laws. They reflect the experience learned from previous engineering projects. I see professional codes of conduct playing a part as well.

  • 'In a systematic way' must include brainstorming, and testing random insights.

  • 'Deliver' implies a process that continues beyond design stages to project delivery stages. Success is determined by successfully meeting all the specified and agreed requirements.

  • 'Conditions of uncertainty' exist because we must deal with combinations of designs, being applied into ever-changing environments. The results are 'complex to predict' and the resulting risk has to be handled.

2. I want to make it clear that whenever I use the term engineering, I mean to imply the use of quantification and measurement as a basic tool, rather than more intuitive methods.

Related Concepts [Engineering *224]:

  • Systems Engineering *223

Type [Engineering *224]: Process.

Entity Concept *645 January 7, 2004

Entities exist. An entity is a real thing.

An entity is real in the sense that it has provable existence, and it has performance and cost attributes. An entity can be natural or human made. It can be conceptual or physical.

Notes:

Synonyms [Entity *645]:

  • thing

Related Concepts [Entity *645]:

Type [Entity *645]: Systems Engineering Concept

Entry Condition Concept *056 February 22, 2003 tg

An entry condition is a written part of a work-process standard. Entry conditions are usually found in sets. The relevant set of entry conditions is evaluated in an entry process. They are used to determine if there is entry permission to a task process.

Notes:

1. Entry conditions are used to decide if it is economic and safe to enter the main task of a process. They are designed to:

  • prevent entry into a task process if it would be failure-prone
  • cause us to remove obstacles to successful task process execution
  • provide a ‘standard,’ which we can continuously update whenever we get experience or knowledge to improve our productivity.

2. All the entry conditions must normally be met for permission to enter into the main process task.

Example:

Entry Condition 1: The requirement specification shall have exited from SQC with a maximum estimated remaining major defects/page of less than one.

3. For any work process, there are usually several entry conditions, which should apply. They can be grouped in sets into ‘generic’ and ‘specific’ entry conditions.

4. Entry conditions are one type of work process standard. They are one means of ‘process improvement’ since they provide a mechanism for ‘organizational learning’. (Any experiences of conditions that warn of impending problems can be noted in the form of entry conditions. They are then available to anyone in an organization, even those people, who have not personally had the ‘bad’ experience, which may have led to the establishment of the entry condition.)

5. Note: Nov 1 2003 Gate is a generic word for both Entry and Exit conditions. <-McConnell

Type [Entry Condition *056]: Condition [Process].

Entry Process Concept *057 February 22, 2003tg

An entry process involves evaluating any applicable entry conditions for a process. The process itself is defined by a main task. When all entry conditions are met, the main process task may officially commence.

Notes:

1. The purpose of an entry process is to help to avoid failed (or uneconomic or time wasting) execution of the main task. We need to work to remove any entry condition failures. Otherwise, waiving or ignoring failed entry conditions is a possibility, with determinable risks.

2. When referring to the SQC Entry Process (or any other specific named Entry Process), capitals may be used, to distinguish it from the basic ‘entry’ concept, which applies to all processes.

Abbreviation [Entry Process *057]: ‘E’ <- IBM convention originated by Ron Radice/Watts Humphrey. (Abbreviation for a process control cycle is ETVX or ETX: ‘Entry Task Validation eXit’.)

Keyed Icon [Entry Process *057]: […]

Example:

[Design Process]

Type [Entry Process *057]: Process.

Environment Constraint: Concept *491 Oct 27 2001 2107 London

A Environment constraint is any system constraint that is not a focus system constraint.

Environment constraints are particularly intended to describe constraints on the life cycle of a product or system, such as:

  • design and architecture phases
  • construction and acquisition phases
  • implementation phases
  • operational use phases
  • shut down phases

Constraints are of four basic types:

  • function constraints
  • performance constraints,
  • resource constraints and
  • Environment constraints.

Environment constraints can be expressed as binary constraints or as scalar constraints.

Synonym: non-focus system constraint, environment system constraint.

Related Concepts:

  • Environment system *493
  • Focus system *492
  • Binary Constraint *467. A constraint which is formulated in terms which are binary (true/untrue) in nature.). These are of two types veto and demand.
  • Demand Constraint *461
  • Veto Constraint *462
  • Constraint *218
  • Scalar Constraint *468
  • Performance Constraint *438
  • Resource Constraint *478
  • function constraints *469

Type: Constraint

Environment System: *493 August 17, 2003

An environment system is any system related to a defined Focus System.

For example it could be a development process or development tool for a product (designated as the defined focus system).

Synonyms [Environment System *493]:

  • Enabling Systems <-MIL-STD-499B

Related Concepts [Environment System *493]:

Type:???

Error Concept *274 January 13, 2003

An ‘error’ is something done incorrectly by a human being.

Error/Slip (Specification Issue) Specification Defect Fault/Bug/System Defect Malfunction

Notes:

1. Errors are usually committed unintentionally; they are often forced to happen by ‘bad’ work processes (Statistical Process Control Theory [DEMING86, JURAN64 &74]).

2. Human errors in specification processes lead to defects in specification or evaluations.

For example, errors in systems engineering processes result in (written) engineering and contractual specification defects.

3. SQC is a means of checking specifications to discover whether errors have been made. Any suspected violation of any applicable specification rule is logged as an issue.

To err is human.

Saying, and similar to Plutarch (A.D. 46-120) “For to err in opinion, though it be not part of wise men, is at least human.”

Synonyms [Error *274]:

Related Concepts [Error *274]:

Essential Objective: Concept *231 . January 8, 2003

Essential objectives are Objectives objectives are the ones which are capable of influencing the Fundamental objective when they are reached or implemented (See Keeney ). Compare with ‘Controllable’ .

The effect of essential and controllable properties on the identification of fundamental objectives

[after basic ideas of KEENEY92, p.84].

Estimate Concept *058 March 16, 2003

An estimate is a numeric judgment about a future, present or past level of a scalar system attribute.

This includes all performance and cost attributes.

Notes:

1. Estimates are usually made where direct measurement is:

  • impossible (future), or
  • impractical (past), or
  • uneconomic (current levels).

2. An estimate is usually extrapolated from available information, and past experience.

3. An estimate can be made for numeric facts from the past (benchmarks), even if precise past data is not available.

4. Estimates are made about any scalar system attribute: cost levels, resource availability, quality levels, savings and other dimensions of systems.

Keyed Icon [Estimate *058]: # “The same icon as Cell. This icon is symbolic of an Impact Estimation table. In the USA, this icon is the ‘number’ symbol.”

Type [Estimate *058]: Metric.

Estimate, To Concept *059 March 18, 2003

In Planguage, to ‘estimate’ is:

  • the process of arriving at a judgement,
  • by guessing the probable numeric value,
  • of a numeric attribute level;
  • using other methods than immediate measurement.

Estimate: “to judge or determine generally but carefully (size, value, cost, requirements, etc.); calculate approximately”

Source: Webster’s New World Dictionary.

Estimation is not to be confused with Quantification or Measurement.

Figure *059: The relationship between four engineering process concepts.

Related Concepts [Estimate, To *059]:

Type [Estimate, To *059]: Verb.

Estimated Remaining Defects: Concept *060 . July 26, 2001

This is an estimate of defect density remaining in a specification at any given time.

Usage 1. The estimate is based on

  • defects found (using knowledge of % defect-finding effectiveness) and
  • defects attempted removed (using knowledge of % effectiveness of the correction process).

Usage 2: The defect density is usually expressed in Major defects per Logical Page.

EXAMPLE OF ESTIMATING REMAINING DEFECTS

For example,

if the defect detection process had a historic and stable effectiveness of 80%, and

you found 80 Major defects, then

you might estimate that there are a total of 100 Majors,

of which you found 80 and 20 Major defects you did not find.

If you correct the 80 you found then

20 not found remain (plus and minus some uncertainty factor of about 30% of the total remaining).

If you historically fail to correct 25% of what you try to correct, then

to the 20 you did not find or fix

you need to add 20 (25% of 80 correction attempts) you failed to correct correctly.

This gives a total estimate of 40 Major defects remaining (20 never found and 20 not fixed correctly),

after you find 80 and try to correct them.

I have found that this method works well regularly, and can be confirmed by an SQC process that manages to find a predicted number of defects (for example 80% of the 40 remaining in the example above, i.e. about 24 Majors), at various clients. It gives the right order of magnitude, even when there is little history, and conditions are somewhat unstable. If this seems too complicated, then use the following rule of thumb, which will make you ‘humble’.

For every defect you find and fix there remain that many more in the system.

If that doesn’t work for you, try Gerald M. Weinberg’s Principle, (Psychology of Computer Programming)

“There is always one more bug remaining”

(Even after you think you have removed the last bug).

Evaluation Effort [Specification Defect Density] Concept *061 November 21, 2002

This is the cost (in work hours) of determining the quality level (Remaining major defects per page) of a specification.

Notes:

1. The process to do the evaluation is assumed to be SQC, but other processes to determine the quality level could be used.

2. Use of sampling will dramatically reduce the evaluation cost, time and effort, at the expense of a mild decrease in accuracy and credibility.

Rationale: The reasons for collecting data on the cost of SQC are as follows:

  • to ensure that SQC is cost-effective; and that the savings sufficiently outweigh the

evaluation costs

  • to reduce the costs to a minimum, and
  • to motivate us to use inexpensive methods such as sampling.

Type: Metric.

Domain: SQC.

Event Concept *062 May 27, 2003

An event is a specified occurrence.

Examples:

  • President Inaugurated
  • Process Begun
  • Process Ended
  • Task Started
  • Task Interrupted
  • Contract Signed

Notes:

1. ‘Event’ is not used here in the ‘organized occasion’ sense of the term. In other words, it is not used in the sense of a ‘wedding’ or a ‘gala opening of a building’ being an ‘event.’

2. An event is not the ‘carrying out’ of an activity, such as performing a task, a process, or some systems engineering implementation (like implementing an Evo step).

3. An event must be clearly distinguishable from the non-occurrence of the event. It must be reliably observable, testable, or measurable in the real world. Consequently, events must be precisely defined – unambiguously.

However, the occurrence of an event is not the same as our measurement of it. An event occurs whether or not it is immediately detected or measured.

4. An event usually results in some measurable change in a status. If a specific event has occurred, then any status associated with the event will have changed. By evaluating the relevant event condition, the setting of a status can be determined.

5. An ‘event condition’ can be defined as a qualifier condition – the event must have happened for the qualifier condition to be true.

Examples:

First Sale : Event: We make our first sale of refrigerators to the USA.

Goal [ First Sale ]: 99% Or Better.

Past [ Last Year , Europe , First Flight ]: 98%.

First Flight : Type: Event. Description: Successful first flight <officially logged>.

6. To attempt a more detailed definition2With thanks to Don Mills, NZ: An event is an occurrence (a set of circumstances, which include changes in status), localized in space and time, which results from some activity, and which is significant as an indicator of progress, or as a stimulus (acts as a trigger) for other activity.

7. An event can be defined in time and space (theory of relativity), but it can be conceived of, specified, and defined, without time and space co-ordinates.

Synonyms [Event *062]:

  • Happening
  • Occurrence
  • Point in space-time

Related Concepts [Event *062]:

Type [Event *062]: Parameter, Scope Concept.

Evidence Concept *063 January 20, 2003

Evidence is the historic facts, which support an assertion. The evidence usually will have been the basis for making an assertion.

In Impact Estimation, evidence is required for each impact estimate. Where there is no evidence, it should be clearly stated that there is none.

Examples:

Design B Goal 1.

Scale Impact: 10 minutes.

Evidence: Of 100 surveyed customers last year, 30 agreed there was this level of

impact on Goal 1 Marketing Report A123.

Record [GB, 2000]: 60 Hours? R. Branson, ‘Losing My Virginity’.

#. Branson claims to have beaten previous record of 59 hours slightly.

‘#.’ gives the evidence for the uncertain (?) estimate of 60 Hours.

Keyed Icon:#<- “source (<-) of the estimate (#).”

Type: Parameter, Systems Engineering concept.

Domain: Impact Estimation.

Evo Concept *355 June 5, 2003

Abbreviation for Evolutionary Project Management *355 and Evolutionary *196.

Readers will have to bear with me that I use this abbreviation for both ‘Evolutionary Project Management’ and ‘Evolutionary.’ The underlying concept is the same <- TG.

Evo Plan Concept *322 May 26, 2003

An Evo plan is a set of sequenced and/or a set of yet-to-be sequenced Evo steps. The current planned sequence of delivery of any of the steps should be reconsidered after each Evo step has actually been delivered, and the feedback has been analyzed. Many factors, internal and external, can cause a re-sequencing of steps and/or the insertion of previously unplanned additional step(s) and/or the deletion of some step(s).

It is the identification of the next Evo step for delivery that should be our focus for detailed practical planning. After all, at an extreme, the other planned steps may never be implemented in practice.

Notes:

1. For the Evo steps, an Evo plan is likely to specify only the tag names. Detailed specification of an Evo step will be held in its step specification.

2. An Impact Estimation table may be included in an Evo plan. Such a table would hold the estimates for the impacts of each of the Evo steps, and the feedback after delivery of each of the Evo steps. The progress made could then be tracked against the Evo plan.

3. An individual Evo step can be ‘rolled out’ across a system. That is, the design ideas making up the Evo step are developed,. Then production and delivery is repeated over several Evo steps; with delivery to different parts of the system for each step. In such cases, the Evo plan is likely to be the place where the details of the impacts of the repetition of step delivery are held.

Synonyms [Evo Plan *322]:

  • Evolutionary Plan *322
  • Evolutionary Delivery Plan •322

Related Concepts [Evo Plan *322]:

  • Evolutionary Project Management (Evo) *355
  • Evolutionary *196

Type [Evo Plan *322]: Specification Concept.

Evo Step Concept *141 May 11, 2003

An Evo step (‘evolutionary step’ or, simply ‘step’) is a ‘package of change’, containing a set of design ideas, that on delivery to a system, is intended to help move the system towards meeting the yet-unfulfilled system requirements.

Evo steps are assumed to be small increments, typically a week in duration or 2% of total budget. There are two purposes for Evo steps: to move us towards the long-range requirements, and to learn early from stakeholder experience (with a view to changing plans and designs early).

Notes:

1. Evo Step Content: A step will contain the ‘means’ for meeting specified ‘ends’ (requirements). It will contain some combination of design ideas, which aim to achieve the requirements.

2. Dynamic Step Sequencing: Evo is conceptually based on the Plan Do Study Act cycle. An Evo plan for a project consists of a planned series of Evo steps sequenced in order for delivery. Step sequencing for delivery can be roughly sketched or planned in actual time-sequence. Step sequencing always remains finally contingent upon actual feedback results, and on external considerations, such as new requirements, changing priorities, or new technology. The step delivery sequence is determined dynamically, after the previous step results are analyzed (Study Phase) and a decision is made about the next step (Act Phase). Selecting the next step for delivery is the main focus of Evo planning activity.

3. Step Priority: Steps with the highest stakeholder-value-to-cost ratios or performance-to-cost ratios ought to be scheduled for early delivery. Step dependencies have also to be considered.

4. Step Size: A step is typically, but not unconditionally, constrained to be between 2% and 5% of a project’s total financial budget and total elapsed time. Why? Well, because 2% to 5% is a reasonable amount of resource to gamble, if you are not absolutely sure whether a step will succeed.

5. Step Specification: An evolutionary step specification is the written description of the step content; that is, specification of the list of design ideas involved.

6. Step Lifecycle Location: A step is developed and delivered within a result cycle: any necessary step development occurs as part of the development cycle, any step production required occurs as part of the production cycle, and step delivery takes place as part of the delivery cycle.

7. Step Content Reuse: It is possible for the same step content to be repeated in several different steps (that is, in effect a ‘roll-out’ across a system, over time, such as to different countries or states or branch offices). In such cases, the step specifications will differ only in the qualifiers. For example, Step 1: Function XX [California], Step 2: Function XX [New York], and so on.

Figure *141: Evo Step packaging. Delivery-specified Evo Steps: same underlying step specification, but two different times and places.

Synonyms [Evo Step *141]:

  • Step *141
  • Evolutionary Step *141
  • Build, Increment, Installment, Release: Near synonyms depending on whether there is use of feedback and dynamic change [ROYCE98]

Related Concepts [Evo Step *141]:

  • Evo Step Specification *370
  • Evo Plan *322
  • Evolutionary *196
  • Evolutionary Project Management (Evo) *355

PDSA Cycle *168: See also the individual Plan, Do, Study, Act components

Example:

S23: Step [<Time, Place, Event to be determined>]: F1, F2 [Europe], D3 [China].

The main difference between an Evo step package (above example with undetermined qualifier) and a delivery-specified Evo step is that the latter has been assigned a sequence or timing and a place of application qualifier. The Evo step package is just a specification of the step contents. An Evo step package can be deployed in multiple times and places. You could say that an Evo step package is a reusable specification. For example, every week it could be to different countries.

Keyed Icon [Step *141]: ->or ->:) “Symbolizing ‘Impact on stakeholder’.”

Note: The symbol is sometimes automatic ‘correction’ for the colon and right parenthesis keyed symbols, in Microsoft Word.

This above drawn icon is a series of any number of steps, each one representing an Evo step. I have used this for decades as a graphic icon for a set of evo steps.

A hierarchical set of evo steps (above). The left most can for example represent ‘years’, the middle one ‘months’ or ‘quarters’, and the rightmost steps ‘weeks’ or elementary steps.

[Editor Note to Publisher: Please correct Months on redrawing. Thanks]

And we can add specification in the form of tags of function, design and qualifiers.

Add lines or arrows to indicate step and sub-step relationships.

Type [Evo Step *141]: Specification Object, Parameter.

Evo Step Specification Concept *370 May 29, 2003

An Evo step specification is the formal written definition of the content of an Evo step .

Notes:

1. Outline Evo step specifications are produced towards the end of the initial design engineering process (that is, prior to evolutionary project management (Evo) commencing) as part of producing an Evo plan. The main concern at this stage is that there is sufficient information to enable the next step to be selected from the potential candidates.

During Evo, additional outline step specifications will be written as additional step possibilities are identified.

2. Detailed Evo step specification occurs within Evo, once the step has been selected as being the next for implementation.

3. An Evo step specification can differ from the reality of the delivered step content.

Template [Evo Step Specification *370]: Evo Step Specification.

Synonyms [Evo Step Specification *370]:

  • Step Specification *370
  • Evolutionary Step Specification *370

Related Concepts [Evo Step Specification *370]:

  • Design Engineering *501
  • Evolutionary Project Management (Evo) *355
  • Evo Step *141

Type [Evo Step Specification *370]: Design Component.

Evolutionary Concept *196 March 20, 2003

The ‘evolutionary’ concept implies association with Evolutionary Project Management; an iterative process of change, feedback, learning and consequent change. Evolutionary processes need to be carefully distinguished from other processes – those that do not iterate, do not learn from experience, and do not cater for change.

Abbreviation [Evolutionary *196]:

  • Evo *196: Readers will have to bear with me that I use this abbreviation for both ‘evolutionary’ and ‘Evolutionary Project Management.’ The underlying concept is the same <- TG.

Related Concepts [Evolutionary *196]:

Plan Do Study Act Cycle *168

Type [Evolutionary *196]: Adjective.

Evolutionary Project Management Concept *355 June 5, 2003

A project management process delivering evolutionary ‘high-value-first’ progress towards the desired goals, and seeking to obtain, and use, realistic, early feedback.

Key components include:

  • frequent delivery of system changes (steps)
  • steps delivered to stakeholders for real use
  • feedback obtained from stakeholders to determine next step(s)
  • the existing system is used as the initial system base
  • small steps (ideally between 2%-5% of total project financial cost and time)
  • steps with highest value and benefit-to-cost ratios given highest priority for delivery
  • feedback used ‘immediately’ to modify future plans and requirements and, also to decide on the next step
  • total systems approach (‘anything that helps’)
  • results-orientation (‘delivering the results’ is prime concern)

Figure *355: Conceptual view of Evo [HUMMEL02]. Notice that the design changes over time: it does not just get ‘incremented’. Of course, it is not a requirement that the design has to fundamentally change at each step! Compare with Figure *318 in Incremental Development *318.

[Editor note to Publisher: Please replace ‘Core Increment’, ‘2 nd Increment’, ‘3 rd Increment’, ‘Final System’ with ‘Step 1’, ‘Step 2’, ‘Step 3’, ‘Step 4’. Thanks]

Abbreviations [Evolutionary Project Management *355]:

Synonyms [Evolutionary Project Management *355]:

  • Evo Management *355
  • Evolutionary Delivery Management *355
  • Rapid Delivery Management (Acronym: RDM), Result Delivery (These synonyms are used within Jet Propulsion Labs. [SPUCK93]
  • Synch-and-stabilize or Milestone Approach (These synonyms are used within Microsoft [CUSUMANO95].

None of them are perfect synonyms, but since each author and company has a long list of extremely similar features that make up these processes, they are close enough.

Type [Evolutionary Project Management *355]: Method.

Historical Note: Evolutionary Project Management had an early large-scale documented use in the Cleanroom techniques used by Harlan Mills within IBM in the 1970s [MILLS80]. [LARMAN03] gives a comprehensive history of the method.

.

Except Concept *389 July 12, 2003

‘Except’ is a parameter, which means that the following term or expression is an exception from the previous term or expression.

Example:

Goal [Europe Except {Denmark, France, Luxembourg}]: 20%.

Keyed Icon [Except *389]: -

Type [Except *389]: Logical Operator.

Exit [SQC] Concept *290 November 20, 2002

Exit is the name of an SQC sub-process. The SQC team leader checks a set of defined SQC exit conditions, and decides whether to allow the specification to exit, based on the exit condition status; or whether to take other action, as a result of unsatisfied exit conditions.

Note: The maximum recommended level of estimated remaining major defects per page in the specification – an SQC measurement - is an important exit condition; but not the only one usually.

Synonym: SQC Exit.

Related Concepts:

Type: Process.

Domain: SQC.

Exit Condition Concept *064 February 22, 2003

An exit condition is a written part of a work-process standard. Exit conditions are usually found in sets. The relevant set of exit conditions is evaluated in an exit process. They are used to determine if there is exit permission from a task process. All the generic and specific exit conditions must normally be met, in order to exit from a process, thus releasing work products to the other ‘downstream’ processes.

Examples:

Exit 33 : The remaining quantity of major defects (potentially costly rule violations) in a document may be calculated (based on defects found and fixed) to determine if it is wise to release (exit) an engineering or management specification.

We can decide this by considering the alternative cost consequences (compared to exit ‘now’) of the remaining defects, in later test and field use phases.

At stages later than specification, major defects are one and two orders of magnitude more expensive to deal with.

Exit 13 : The system design must arguably have a complete set of designs to reach all performance targets, within resource targets and generic constraints, considering acceptable risk (negative uncertainty), credibility and safety margin.

Related Concepts [Exit Condition *064]:

Type [Exit Condition *064]: Condition [Process].

Exit Process Concept *065 February 21, 2003

An exit process involves evaluating any applicable exit conditions for a process. Only when all exit conditions are met, can the main process task officially terminate and any process output be released to the next process.

Notes:

1. If any conditions fail, the exit process includes work to improve exit condition status to the required level. If all conditions are OK, then a process product can be released to its customer, and the process is officially completed.

Abbreviation [Exit Process *065]: X “As in ‘eXit.’”

Related Concepts [Exit Process *065]:

Keyed Icon [Exit Process *065]: [ ]or ^[ ]->

Examples:

[Requirements] Maximum 1 estimated remaining major defect/page.

[Design] Achieved Jan 23rd.

^[Requirements] “This is a reference to the Requirements Process alone, not the exit.”

[ Test Planning ] “This is entry to test planning reference.”

[ Installation ] “This is a reference to the Installation process Exit”

Goal [IF [ Acceptance Test ] , Initial Delivery ]: 60% “The condition is that the Acceptance Test has Exited.”

Type [Exit Process *065]: Process.

Explicit Parameters: Concept *378 . July 27, 2001

Parameters in a specification that are defined by direct use of their defined parameter name.

For example:

Scale: Probability of [Fault].

Goal [Fault = Show Stopper]. “all 3 terms {Scale, Goal, Fault} are Explicit Parameters’

The ‘Scale’ is an explicit generic Planguage parameter. ‘Fault’ is another explicit parameter, project defined (see *377 Generic Term for example of definition), for the generic term ‘Fault’ (identified in the ‘Scale’ specification).

The alternatives to ‘explicit parameter use’ would be:

defining a parameter by ‘default’ (Default Value *447) or

using ‘sequence of definition’ (1 st , 2 nd , 3 rd ), see Scale Qualifier: Concept *381 and Scale Variable *446 , or

simply by recognizing the parameter as having a unique definition (‘Show Stopper’, example above, defined once) and belonging to a particular generic term (like ‘Fault’).

Explicit parameters are a device for making specification more obvious to the reader.

Explosion: Concept *066 . July 27, 2001

Explosion is a ‘dramatic’ word for ‘hierarchical decomposition of complex specifications into useful, more elementary, detail’.

Antonyms: implosion, synthesis (Descartes), aggregating

Synonyms: decomposition, detailing, breaking down into sub-components, elementing (concocted for fun July 27, 2001 Tg)

Also known as Cartesian Analysis (René Descartes, French Philosopher).

Expression Concept *302 June 1, 2003

A Planguage ‘expression’ is part or all of a Planguage ‘statement’: it is one or more related Planguage components of any kind.

Expressions are defined by one or more Planguage terms.

Expressions are comprised of Planguage language concepts. These concepts include: {parameters, icons, tags, qualifiers, sources, fuzzy terms}.

For example (below), a ‘term’ (in this case a ‘tag’), ‘Adaptability’ is described by a set of three ‘statements’. Each statement, using one or more ‘expressions’ is a ‘definition’ of the tag. The ‘expressions’ themselves are composed of ‘terms’.

Adaptability :

Ambition: Ability to make changes quickly and cheaply from Customer’s point of view.

Scale: Calendar days needed from <customer request> to <successful first delivery>.

Next Year : Goal [ End of Next Year ]: 7 days “Half of our present adaptability time” <- Sales Plan .

Adaptability’ itself, once defined, can be reused as a term in another expression (below).

MTBF : Goal [ Adaptability , Next Year ]: 6,000 hours.

Related Concepts [Expression *302]:

  • Statement *140: See diagram showing how Expression relates to Statement.
  • Term *151
  • Definition *044: A definition can comprise one or more statements.

Keyed Icon [Expression *302]: ‘ ’ “Single quotes can be used round a set of terms to identify them as forming a single expression.”

Type [Expression *302]: Specification Concept.

Expression Quotes: Concept *329 . July 27, 2001

Expression quotes are ‘single quotes’ at the beginning and end of an expression. They are used to make it clear that this is a single expression, using a set of related terms.

Rationale: They are useful when the expression is complicated and some doubt could arise as to the expression.

Note, these are quite distinct from the “double quotes ” used to place comments anywhere in Planguage , and to express Data.

Goal [‘Time = After 2002 [Europe, IF Peace]’, GB] 60% “these are double quotes”.

Usage:

An alternative way of doing this is to define the complex expression:

Peacetime: Time = After 2002 [Europe, IF Peace]

And use it through its tag, instead of an expression in single quotes:

Goal: [Peacetime, GB] 60% .

External Concept *497 May 9, 2003

When describing the relationship amongst objects, external is an adjective, which applies to any object outside the scope of a given object.

Examples:

  • External stakeholders of a system
  • The influences of the external environment on a system

Notes:

1. ‘External’ is used with regards the ‘place’ scope of an object, rather than the ‘time’ or ‘event’ scope. ‘Where’ does an object stand with regard another object: within its extent of influence (internal) or outside it (external)?

2. If an object is external (outside the scope) of an object, it means it is not under the control in any way of the given object. This does not mean that no influence whatsoever can be exerted, but any influence is definitely not direct or totally predictable.

3. Some objects are more remote than others.

Related Concepts [External *497]:

Type [External *497]: Adjective.

External Stakeholder: Concept *495 October 27 2001

External stakeholders are stakeholders which are directly impacted by, or which use, a defined focus system.

For example: a product customer or user is an external stakeholder in relation to that product (a defined focus system).

Related Concepts:

Type: relation concept.

Facilitator: Concept *236 . July 27, 2001

A person or group who assists others in carrying out a work process, such as quality control or setting objectives; by virtue of their being especially trained, qualified, and knowledgeable in that process.

Fail Concept *098 May 5, 2004

‘Failure’ signals an undesirable and unacceptable system state.

A Fail parameter is used to specify a Fail level constraint; it sets up a failure condition.

A Fail level specifies a point at which a system or attribute failure state begins. A single specified number (like Fail: 90%) is the leading edge of a Failure Range.

Notes:

1. Failure ranges can be arbitrarily stipulated by a stakeholder. They might be stated in a contract. They are specified so as to keep designers and implementers aware of the levels at which stakeholders are likely to experience failure, or to contractually declare some degree of failure.

2. A failure range maps an extent of unacceptable levels. The failure range is better than ‘catastrophic’ levels, and worse than ‘acceptable’ levels. In other words, the failure range extends from the defined Fail level in the direction of ‘worse’ until a Survival level (or Catastrophe level) is reached.

3. The purpose of the ‘Fail’ concept is to inform us that we need both to design for, and operate at, more acceptable levels.

Example:

Fail [Euro Release]: 99.5%.

For example, a state of failure can result from issues such as safety problems, operator discomfort, customer discomfort, loss of value, and loss of market share. Failure levels cause problems, even temporary system loss, but they are not immediately critical to a system’s continued survival. The assumption is that it is possible to get the system out of a failure range.

4. Fail levels do not represent total failure. That role is defined by catastrophe levels. However, system development should keep going until, at least, the actual system levels are better than the specified failure levels. Otherwise, they are delivering some degree of failure to some stakeholder; that is, the system or attribute will at some stage fail in some sense.

5. A Fail constraint specification means that some defined stakeholder has stated the level at which the attribute’s numeric value becomes unacceptable to them. Any level equal to or worse than the Fail level, is outside the ‘acceptable’ range for that stakeholder.

6. A systems engineer should document why a specific Fail level was chosen (using Rationale or similar), and the likely impacts (using Impacts) and consequences of any failure (using Risks), so that risk analysis and prioritization can be carried out.

Example:

Learning Time :

Scale: Mean Time to Learn defined [ Task ] by defined [ Operator ].

Fail [ Outgoing Call , Beginner ]: 3 minutes <- Marketing Requirement 3.4.5 .

Risk: If the Mean Time is not lower, then Competitor Products will be perceived as better and we will lose <market share> <- Marketing Planner [ Andersen ].

Fail [ Address List Update , Professional User ]: 30 seconds <- Marketing Requirement 3.4.6 .

Authority: External Consultants . “Outside consultants tell us we will be rated badly if we fail to beat this level.”

Goal [ Average Task , Average User ]: 25 seconds <- Marketing Requirement 3.4.7 .

Rationale: Marketing believes this will make us best in the Market .

The local parameters, Risk, Authority and Rationale can be used to explain why scalar levels have been set at specific levels. Note that the Source(s) of information (format: ‘B <- Source of B’) give indirect authority for the specification levels. (The Goal specification is included here to give a more realistic specification example.)

Synonyms [Fail *098]:

Related Concepts [Fail *098]:

  • Survival *440
  • Catastrophe *602
  • Range *552: See ‘Failure Range’
  • Must Do *539: Historical usage only

Keyed Icon [Fail *098]: !

“In context on scalar arrows: ---!--->O---!--->

A Failure Range would use multiple Fail icons: ----!!!!!!--->-> ”

Type [Fail *098]: Constraint, Parameter.

Failure Range. Concept *546 May 29, 2003

A failure range is a scalar range where some stakeholders will not tolerate the attribute levels. They find the levels unacceptable.

A failure range lies between Acceptable Ranges and Catastrophe Ranges.

Related Concepts:

Notes:

1. The range is primarily defined by a stakeholder, but can also be a range described by target and constraint requirements for a system, which are relating to the stakeholders’ ranges, perhaps as compromise requirements for a set of stakeholder ranges. (Insight due to Kai Gilb May 2002)

Keyed Icon [Failure Range, *546] !!!!!!! 2 or more ‘!’.

Synonym[Failure Range, *546]:

`• Fail Range *546

Type [Failure Range, *546]: Scalar concept

False *626 February 16, 2003

Predefined State. Same as Off.

Related To:

Fault Concept *339 June 5, 2003

A fault is a defect in a real system, which if ‘provoked’ by an agent or specific data, can result in a system malfunction.

Notes:

1. ‘Bug’ is a common synonym for ‘Fault’.

Example:

A geological fault is a defect in the earth. If the fault is provoked, the result can be an earthquake (a malfunction).

Figure *339: From error to malfunction [Editor Note to Publisher: See Figure *274, which is the same.]

2. Figure *339 tracks the chain of events leading to a malfunction: a human engineer makes an error. This may be detected as a specification issue, which in turn, may be classified as a specification defect (which then may, or may not, be fixed). Alternatively, maybe the problem is not detected as an issue, and the error simply becomes a specification defect. A specification defect is in the system specification used to implement the system, it may become an actual fault in the implemented system. If the fault is then hit (provoked), a malfunction of some kind may well result.

Synonyms [Fault *339]:

Related Concepts [Fault *339]:

Type [Fault *339]: Problem, Feedback.

Feature: Concept *519 January 23 2002

A feature is a class of stakeholder perceptible characteristics of a system, which are useful for comparing against competitive product, service or system benchmarks.

The point being to help stakeholders see that this system is equal, better or different from others. A feature can be performance attributes (easy to learn), cost attributes ( cheap to acquire) , functions (can send SMS) , or designs (uses titanium cover) . Features for one set of stakeholder (like repair services) will be different for another set of stakeholders ((like consumers)

Usage: in presenting proposed products or services or real ones. It has a positive connotation.

Related Concepts [Feature *519]

  • function *069 not all functions are worth listing as features.
  • design *047 not all designs would be intelligible to the stakeholders as features ( too technical)
  • performance *434 or quality *125 attribute, not all performance or quality attributes would be features. It depends on their levels compared to benchmark products or systems.
  • cost attribute *187 not all cost attributes would be features. It depends on their levels compared to benchmark products or systems.

Fix Probability Concept *067 November 21, 2002

The Fix Probability is the probability that an attempt to correct (fix) a specification defect, or system fault, will succeed.

Notes:

1. This probability should be based on past data concerning ability to remove defects.

For example, IBM reported a 5/6 ‘fix probability’ for defects found by Inspection (SQC) in software engineering documents <- [M. Fagan, IEEE Transactions on Software Engineering. Vol. SE-12, No. 7, July 1986].

2. Higher than 82% fix probability has been recorded at NASA and IBM [(IBMSJ-1-94, Kan]. Under the condition that rigorous quality control of the each fix is carried out. The level is closer to ~99.9%.

Focus System *492 August 17, 2003

A focus system is the system, or product, we have decided to focus our attention on. All other systems related to it are ‘Environment’ systems.

The purpose of this concept is to allow us to define a focus on one particular element of a set of related systems.

For example if we are doing a project to develop a product, then that product is likely to be a focus system. All other related engineering and management processes and tools needed to do the project are the environment systems for the focus system.

Synonyms [Focus System *492]:

System of Interest <- Mil-Std-499B

Related Concepts [Focus System *492]:

  • Environment System (Enabling Systems <-MIL-STD-499B) *493

Type: ???

Form Concept *068 February 26, 2003

A form is a written document (electronic or paper) that guides people to give specific data with specific content in specific formats, in specific presentation sequences. It is a ‘work process standard’ for data collection. It is also an implicit ‘procedure’ for data collection.

Notes:

1. A form is something intended for direct data collection. It is usually fixed in format and appearance.

2. If an electronic form is enhanced with user dialogue; and has varied choices and computer presentation, then it becomes less of a ‘form’ and more of a human-computer dialogue.

Related Concepts [Form *068]:

Type [Form *068]: Tool [Data Collection].

Frontroom Concept *343 January 2, 2003

Frontroom is an adjective or noun, referring to a conceptual place, used to describe any project management processes or activities, in Evo, that are visible to the Evo step recipients.

Usage: Typically, used to refer to the delivery cycle part of the result cycle. The frontroom is where the step is delivered to the stakeholders.

The frontroom is where stakeholder-level results of the step integration can be tested and measured.

Illustration compliments of Simon Porro, Eindhoven, SPI Partners, 2001. (Permission Granted)

Related Concepts [Frontroom *343]:

  • Backroom *342.
  • Recipients ( *341): the targets of frontroom implementation activity.

Type: Adjective, Noun.

Function (adjective) *556 June 22, 2002

A function adjective is used to restrict the modified noun (constraint as in function constraint) to the function area.

Function, To Concept *557 March 18, 2003 B

‘To function’ means to carry out the defined functions of a system under the defined conditions, at least at survival level or better, for performance and cost.

Type [Function, To *557]: Verb.

Function Concept *069 April 19, 2003 B

A function is ‘what’ a system does.

A function is a binary concept, and is always expressed in action (‘to do’) terms (for example, ‘to span a gap’ and ‘to manage a process’).

Notes:

1. A function has a corresponding implied purpose. For example ‘to span a gap’ usually has as an implied purpose to enable something to get from point A to point B over the gap.

2. Function is a fundamental part of a system description: a system consists of function attributes, performance attributes, resource (cost) attributes and design attributes. All attributes exist with respect to defined specified conditions.

3. All the system attributes must be described together, in order to fully understand a real world system. Function is a ‘pure’ concept, which cannot exist in the real world alone. Functions need to have associated with them, the relevant performance and resource attributes.

Further, functions can only exist and successfully interact with the real world if they have certain minimal levels of such attributes, for example, levels of availability.

4. Function is a system attribute that is expressed without regard to the related performance, cost and design. A function needs to be clearly distinguished from design ideas. Design ideas are a real world method for delivering all the function, performance and cost attributes of a system.

5. Function itself is binary. Function in a system is either implemented or not. It can be tested as present or not. Any real implemented function will have some associated performance and cost attributes – whether we planned for them or not. Once a design with the required functionality is specified (or later implemented), we need to consider whether that particular design has satisfactory performance and resource (cost) attributes. In other words, we control these scalar attribute’s levels mainly by specifying appropriate design options, which deliver the required performance and cost levels.

6. A function can often be decomposed into a hierarchical set of sub-functions. For specification clarity, prefixes such as ‘sub-‘, ‘supra-‘ or, ‘family’ relationships (such as kid, parent, sibling) can be used to express the relationships amongst the different functions. Alternatively, the parameters, Includes, Is Part Of and Consists Of can be used.

7. I have intentionally chosen the term ‘function’ as the adjective for ‘function’ (for example, in ‘function specification’ and ‘function requirement’), rather than the more common ‘functional.’ It is the ‘requirement for function’ that is being expressed, rather than ‘making the requirements functional.’ The logic of this choice is the same as for choosing ‘quality’ (for example, in ‘quality requirements), rather than ‘qualitative.’

Related Concepts [Function *069]:

Drawn Icon [Function *069]: An oval (A circle would also be considered a function.)

Keyed Icon [Function *069]: O or parenthesis, ( )

In context: ----->(<Function Tag>)---->

Example: --------->O------> (a function with attached performance and cost attribute scales).

This describes a system, the function keyed icon, ‘O’, is combined with two scalar arrows.

Type [Function *069]: Attribute, Parameter.

Function Baseline. Concept *489 . May 6, 2004

A function baseline is an analytical statement of system functionality.

Usage:

It can be used to state the results of systems analysis of existing systems.

It can be integrated with future comparable functional requirements, so that it is easier to see the proposed functional changes. It is analogous to the scalar baselines.

Related Concepts [ *489]:

Example: a pure baseline without a requirement

Function X:

Type: Function Baseline.

PG: Baseline [2001, Product Y] {Game 1, Game 2}.

Example: a baseline mixed with a requirement

Function X:

Type: Function Requirement.

Baseline [2001, Product Y] {Game 1, Game 2}.

Description [201x, Product Y] {Game 1b, Game 3}.

Type [ *489]: specification.

Function Constraint Concept *469 March 30, 2003B

A function constraint is a requirement, which places a restriction on the functionality that may exist in a system.

A function constraint is binary: it specifies that a specific function must be, or must not be, present. The implication is that some kind of failure will result if a function constraint is not met (such as contract penalties).

Examples:

No New Games :

Type: Function Constraint.

Rationale: No new games of any kind will be available on the new product.

Definition: No functionality, required solely for a New Game , is to be developed.

Support for Old Games [ Release 1 ]:

Type: Function Constraint.

Rationale: All available games from our older product will be available to any customer on request. Some customers would be upset at losing the existing games.

Definition: Functionality to support Old Games must be included.

Synonyms [Function Constraint *469]:

  • Function Restraint *469

Related Concepts [Function Constraint *469]:

Keyed Icon [Function Constraint *469]: [O]

or [ (Function Tag)] or (underlined) [ (Function Tag)]

Type [Function Constraint *469]: Constraint.

Function Design Concept *521 April 23, 2003

Function design is a design primarily aimed at satisfying specified function requirements.

A specified function design has two characteristics, which we primarily select it for:

  • function requirement satisfaction, and
  • satisfactory consequent levels of performance and cost attributes

Example:

Cross River:

Type: Function Requirement.

Definition: Move people and goods from one shore to the opposite shore of a river.

Function Design Ideas [Version 1]: {Build a Bridge, Use a Boat, Swim Over “minimal design”, Take Route ‘Around’ the River, Fly Over}.

Consideration of potential design ideas: Function Design Ideas [Version 1] shows selecting on function satisfaction: some function designs, which satisfy the function requirement.

Function Design Ideas [Version 2]: {{Build a Bridge and/or Use a Boat}, Not {Swim Over, Take Route ‘Around’ the River or Fly Over}}.

Function Design Ideas [Version 2] shows further selection using knowledge of performance and resource (cost) attributes: The function designs that look most promising for the system.

Notes:

1. The final real performance and cost levels delivered is dependent on the specific design chosen (for example, exactly what specific design of bridge, or specific type of boat).

Functional design necessarily narrows the remaining design scope to some degree. It can even narrow the design scope to a set of function designs without actually taking a final choice of specific design (for example, Build a Bridge and/or Use a Boat – without yet saying exactly which type). The final design specification would then be left to a downstream design process.

This delay might be justified by their more specialized knowledge downstream, or justified by the advantage of putting off the decision due to changed technology/market conditions/costs, or due to an advantage of making the decision in the context of many other system/project-wide decisions (avoiding sub-optimization).

2. Any function design in its real implementation (as opposed to pure function specification), will impact many of our non-function requirements (performance requirements, resource (cost) requirements, condition constraints or design constraints). This multiple impact is inevitable whether we like it or not. We cannot, it seems, only design for one pure requirement dimension without having some effects on the others.

When a design is primarily specified for non-function purposes (like improving a quality level), it might inadvertently impact existing functionality as a side effect. This might possibly be acceptable. It might introduce new function, modify old function, or make existing function inaccessible totally or practically.

3. The key reasons for considering function design, as a distinct design type, is that:

  • you can narrow the function design scope gradually
  • you become more conscious of the side effects on performance and cost
  • you become more conscious of the necessity of choosing function design alternatives on the basis of their impacts on performance and cost.
  • you can separate the design rationale for the function, from consideration of the other attributes.

Related Concepts [Function Design *521]:

Type [Function Design *521]: Design [Function].

Function Requirement Concept *074 May 6, 2004

A function requirement specifies that the presence or absence of a defined function is required.

A function requirement is binary, and can either be a specific function target or a generic function constraint.

Example:

Voice Recognition :

Type: Function Requirement.

Definition: The ability to recognize a human voice in terms of vocabulary and individual voiceprints.

Step 1: Step: Voice Recognition [Europe, If Company C has this function on the market].

Voice Recognition is defined as a function. It is then ‘required’ to be delivered in Evo step ‘Step 1’, only in ‘Europe’ and only if ‘Company C has this function on the market’ . A specific design to implement Voice Recognition at specified performance levels and costs needs to be specified.

Notes:

1. Do not include technical design ideas in function requirements. Designs are quite different from functions. If designs are mandatory, then they should be specified as design constraints. A function is an abstract concept specifying activity of some kind, which is implemented by a design. For example: An accounting application (a design) provides a solution to support Maintaining Accountancy Information (a defined function).

2. Distinction should be made between a function target and a function constraint. A function constraint implies that a function must be present or absent (subject to its qualifier conditions) in a system, or a penalty of some kind will be incurred.

3. By default, if there is no information that a function requirement is actually a function constraint, or ‘Type: Function Constraint’ specification, a function requirement is assumed to be a function target.

4. To authority levels, which are lower than the one that specified it, a function target does become mandatory. If a lower authority disagrees with a requirement they have to take the issue up with the higher authority.

5. A function requirement is satisfied by any design, which meets the function description. For example, {transport via a bridge, transport by air, transport across water} all meet the function requirement ‘to transport people from shore to shore of a river’. Note, in this example, the designs are high-level and are actually functions. They can be termed ‘function designs.’ A lower, more specific level of design {by public transport over a bridge, by hot-air balloon, by canoe} can also be considered.

At the early rough stages of design, function requirements are best satisfied by rough function designs (like ‘bridging the river’). At the latter stages of design, specific designs are better, like ‘rope bridge.’ The issue is that the more specific a design is, the less freedom of design choice remains, but the greater the knowledge of its attached performance and resource attributes. For example the quality attributes of a software package selected to satisfy the function requirement, like reliability and portability.

Related Concepts [Function Requirement *074]:

Drawn Icon [Function Requirement *074]: Any oval shape.

Keyed Icon [Function Requirement *074]: (Function Tag) “The parentheses symbolizes the oval icon.”

An alternative is O.@ “A Function Target.”

Examples:

Example 1: (Voice Recognition).

Example 2: (Voice Recognition) -> Speech Input Quality.

Speech Input Quality is a performance attribute impacted by the function requirement Voice Recognition .

Type [Function Requirement *074]: Requirement.

Function Target Concept *420 May 6, 2004

A function target is a specific qualified function requirement type.

A function target is specific testable function, it is not generic, nor is it a function constraint.

Example:

Propulsion Capability :

Type: Function Target. “Could also be called a Function Requirement.”

Description [Europe, Release 8.0]: A means to mechanically drive the vehicle around in three dimensions.

Basic definition of a function target.

Example:

Step 22 :

Type: Evo Step.

Dependency: Step 23 completed successfully.

Step Content: Propulsion Capability [ Version = Prototype , Capability = Surface Movement , Means = Electrical-Powered ].

Test: {Rough Terrain, Novice Driver}.

Exploitation of the function target specification by referencing its tag in an Evo step plan, with suitable qualifiers. Notice how the qualifiers make the generic function somewhat more specific.

Related Concepts [Function Target *420]:

Keyed Icon [Function Target *420]: O.@

Type [Function Target *420]: Parameter, Target.

Fundamental Constraints: Concept *426 July 28&29, 2001

A ‘given’.

Fundamental Constraints are constraints that are handed down to us from higher authority. They are fundamental if we choose not to question them, but to heed them without question or alteration.

Note 1.: fundamental constraints are of various, and potentially conflicting, authority. The conflicting authorities can be ignorant of one another. There can be various degrees of power behind the various authorities.

Note 2. What are ‘non-fundamental’ constraints?

  • anything which is specified but ignored with reference to higher priorities.

For example: a Corporate quality constraint (like minimum 99.9% availability) which is ignored because the current customer contract has a Limit of 99.98% availability.

  • anything which is specified as a constraint by one stakeholder, but is, or might be, explicitly overridden by another higher priority constraint or requirement.

For example: a constraint on use of methods or processes which could be overturned by national law or international considerations. Maybe only if you ventured into these other market areas.

Keyed Icon [Fundamental Constraint] ----[---------]------ the square brackets.

Identical to the keyed icon for ‘Limit’ (a clear Fundamental Constraint).

Compare to -----[----------]----- Generic constraints icons ( *245).

Example:

R---------FC [------------------------->PL-------->O

R= a resource for example Engineering Hours. FC = a Fundamental Constraint, for example ‘maximum Legal Overtime Hours per Engineer per month’. PL = a Planned Level of Engineering Hours.

Related concepts:

Strategic Constraints, support Fundamental constraints. They are set at ‘our’ level of responsibility.

Means Constraints. They are set by instances who are supporting ‘our’ level of strategic constraints.

Note: The {Fundamental, Strategic, Means} set is identical to the use of those terms for requirements and objectives in general.

Limit parameter constraint is typically more fundamental than even a ‘Fail’ level objective.

constraints are binary constraint borders. A constraint may, or may not, also be ‘fundamental’.

Global Constraints: constraints which are system-wide, as opposed to only applying to specified sub-components. These can be ‘fundamental’ or not.

Fundamental Objectives: ‘givens’ as objectives.

Fundamental Objective. Concept *229 November 23, 2001 (+Churchill)

Fundamental objectives are ‘givens’. They are what we are trying to support and impact by reaching ‘strategic objectives’. They form the top level of a relative hierarchy of objectives. They are the given objectives handed down to ‘us’ from above.

Note 1. All lower-than-fundamental level objectives are part of ‘the design’ to reach these fundamental objectives.

Note 2. The ‘us’ (in above definition) is a defined level of the development hierarchy which receives fundamental objectives (from our ‘masters’). It is a level which defines and works towards our strategic objectives, in order to satisfy those fundamental objectives.

Related Concepts:

  • Means Objectives: We may define some objectives that we believe will help us reach our strategic objectives; these are called ‘means objectives’.
  • Strategic Objectives: objectives which are strategies for reaching the fundamental objectives.

Rationale 1: The concept of fundamental objectives is useful because it helps us organize various priorities of objectives. The fundamentals are the ones we cannot question; just serve.

Synonym: (almost) Fundamental Requirement. Not fully, since objectives do not contain the concept of constraints, and requirements do. So a Fundamental Constraint is a Requirement but not an objective.

Keyed Icon [Fundamental Objective *229] any requirements or objectives icons can be used to represent a fundamental objective. If you want a direct iconic representation of the ‘Fundamental’ then I suggest [@] a totally constrained ‘[…]’ goal ‘@’.

Quotation

“The fundamental objectives hierarchy specifies in detail the reasons for being interested in a given problem. For each of the fundamental objectives, the answer to the question ‘Why is it important?’ is simply ‘It is important.’ ”

Source: [KEENEY92 page 78]

Type: Requirements.fundamental, a hierarchy class

The term ‘fundamental objective’ was coined by Keeney [Keeney92].

“I would say to the House, as I said to those who have joined this government, that I have nothing to offer but blood, toil, tears and sweat. We have before us an ordeal of the most grievous kind…. You ask, what is our policy. I will say it is to wage war, by sea, land and air, with all our might and with all the strength that God can give us: to wage war against a monstrous tyranny, never surpassed in the dark, lamentable catalogue of human crime. That is our policy. You ask, what is our aim? I can answer in one word: It is victory, victory at all costs, victory in spite of all terror, victory, however long and hard the road may be; for without victory, there is no survival.”

Winston Churchill, War Papers II, p. 22. From his address to the Commons 1940 after forming his first government. In Jenkins, Churchill, p.591.

The fundamental objective is survival. Victory is the strategic objective. War is the means objective. “blood, toil, tears and sweat.” Is one resource.

Funder: Concept *344 .Funder. July 28, 2001

One who provides money, or other resources, for a project.

Fuzzy Concept *080 January 9, 2003

A specification, which is known to be somewhat unclear, potentially incorrect or incomplete, is called ‘fuzzy’. It should be clearly declared as ‘fuzzy’.

The keyed icons ‘< >’ are used to explicitly mark any fuzzy specifications.

Example:

Scale: <define units of measure>.

Note: This is a template with a hint in fuzzy brackets.

Goal [<Europe>, <2005>]: <66%>.

Rationale: The idea is to avoid forgetting to improve specifications, and to avoid misleading other people into thinking you have done your potential best, when you know better should be done, when you have time and information, in order to define specifications at the necessary quality level.

Notes:

1. The obligation to mark dubious specifications with fuzzy brackets is typically adopted as a generic specification rule.

2. In general a fuzzy term or expression should be enclosed in <fuzzy brackets>, but alternative notations (such as ‘??’) can also be used.

3. Fuzzy brackets are used in electronic templates to indicate something to be filled out, and usually to give a hint as to what should be filled out. Example above.

Keyed Icon [Fuzzy *080]: < fuzzy term >

4. A fuzzy specification essentially amounts to a declaration by the writer that the specification is defective at that point.

Type: Specification Concept, Keyed Icon.

Gaming: Concept *241 . July 28, 2001

Conscious manipulation of requirements or evaluations so as to achieve special aims.

Source: Keeney92, page 96.

Gap Concept *359 March 5, 2003

For a scalar attribute, a gap is the range from either:

  • an impact estimate, or a specific benchmark (usually the current level),
  • to a specific target (or occasionally, to a specific constraint).

Note: In general the larger the gap, the greater the need to deal with it (‘higher priority’) in order to reach the target or constraint. Of course large gaps could be easy and some small gaps could be difficult, so that is why this paragraph says ‘ in general’.

When a gap no longer exists for a specific scalar attribute, then that attribute ceases to have ‘claim on project resources’ (priority). It then has no priority.

Synonym [Gap *359]:

Related Concepts [Gap *359]:

  • Range *552
  • Design Problem *048: A gap defines a new design problem.

Keyed Icon [Gap *359]: === “Any length of two or more ‘=’.”

In context, along a scalar arrow ---<••••|====>---->O---<••••••|=======>------>

where ‘|’ is the current benchmark level and ‘•••’ represents a range already achieved.

Type [Gap *359]: Scalar Design Data.

Generate . Concept *392 Spawn/Create/Generate/Produce. Aug 8th, 2001

‘Generate’ is a relationship concept. It relates things that produce other things.

Keyed Icon [Generates, *392] {

Example: ‘A { B’ means ‘A Generates B’.

Note [Keyed Icon Example]. There is an implication that the Generator (A) continues to exist after it has generated ({) something (B). This is distinctly different from ‘A=> B’ (or A Before B) which states that A proceeds B. But it does not mention responsibility for creation, nor is there any implication that A exists after ‘=>’.

Note Antonym ( ‘}’, *393) : A}B = ‘A is condensed into B’ ..

Usage [Generates Icon] the format a {b, c} can be used to indicate a set of one or more components {b and c} which are spawned from ‘a’. Example:

Mom {Alex, Andy, Andrea}. The use of the ‘set’ parenthesis is entirely natural.

Synonyms: Spawns, Creates, Explodes Into, Produces.

Antonym: *393 Compress/Condense/Reduce To/ Simplify/Combined/Summarize

Examples:

Mother { Children

Mother Generates Children

Inventor { {Product, Patent} Note: not = to ---> Inventor {Product, Patent}

Process Owner { Process Improvement

Team {John, Abdul, Aaron, Solveig} { Product {Software, Hardware, Training}.

Goal [IF Plant { Toxic Waste] 6,000.

Example note:

  • Inventor { {Product, Patent} means Inventor actively generates {Product, Patent}
  • Inventor {Product, Patent} means that Inventor is the Name Tag of the set of things known as {Product, Patent}

Related Concepts:

*393 Compress/Condense/Reduce To/ Simplify/Combined/Summarize

Generic Concept *081 January 11, 2003

Generic means applicable to any individual component of a group of components within a defined scope.

Generic means general, as opposed to specific. ‘Generic’ things are often ‘reusable’ (with local tailoring that makes them more specific) in a variety of situations.

Notes:

1. We use the adjective ‘generic’ when we refer to any systems engineering specifications (for example, rules, processes, conditions and, requirements specifications), which can be used, perhaps with tailoring, in many different kinds of specification processes and/or specifications. For example: generic rules, generic exit conditions, generic development process, and generic constraints.

2. The main idea behind ‘generic’ things is reuse. We want to reuse methods, rules, and any form of engineering and management wisdom. The alternative is to have repetition of methods and ideas, which are in fact common in many areas. This would lead to problems in consistency, learning and updating. It would also increase unnecessary bureaucracy: instead of having to write, learn and maintain multiple versions of essentially the same thing, we do it once.

Related Concepts [Generic *081]:

Type: Adjective, Scope.

Generic Attribute Level Icon:( Concept *251 ) July 29, 2001

A neutral graphic symbol, (---|---) for a numeric level of a performance or cost attribute.

Usage: The generic symbol is used in place of unknown, undetermined or uninteresting specific symbols of attribute priority or character; such as any benchmark (example ---<<--) or target (example ---->---).

Rationale: to avoid being more specific about the benchmark or target type.

Type: generic icon specification convention. {Planguage.Attribute Level Icon Point.Keyed Icon}

Related Concept: *252 Attribute Level Icon Point.

Usage 2. The vertical line(‘|’) can be used in both keyed and icons. It can be used at one or more points on the attribute arrow lines (---->O---->) to indicate levels of the attribute.

(O----|-----|-->).

It can be used to indicate ‘no specific type’ of benchmark or target.

Or it can be used with a supplementary text indicating type of attribute level, such as ‘Goal’ or ‘Wish’ level.

Example:

O----|Goal [SF, Next Year] 30%-->

Generic Constraint: ( Concept *245 ) July 29, 2001

A generic constraint applies to a defined scope. It is tailored in interpretation or specification at the detailed level.

For example:

  • 1) a corporate policy constraint which applies to all corporate projects:

Corporate Quality 2. All quality levels shall be clearly better than our competitors.

Note that the precise quality levels needed will depend on the competitor levels, which will be unknown initially and will vary in time. So this constraint requires tailoring; and is dynamically changing through system lifetime.

  • 2) a contractual requirement which applies to the entire contracted project.

Contract 2.3.4: all system components must be legal import in all European Markets.

  • 3) a legal constraint which applies to products made in your country.

Euro Law 2001-3.4-334: No components, including imported components can use illegal Child Labor, even if assembled in another country by a supplier or customer.

Type: Requirements class, parameter, {requirement.constraint.generic}

Synonyms:

  • ‘system level requirement’,
  • constraint (often used as a short form of Generic Constraint; while specific ( *136) constraints are then referred to as ‘requirements’).
  • Derivative Source ( *450): a Generic Constraint’s generic name!

Keyed icon [Generic Constraint, *245] : ---X {----}Y---

(a conscious reuse of ‘set’ parenthesis)

The set parenthesis (‘{…}’) can be used singly, or together, when placed on an attribute arrow icon scale (--{----->).

Note 1. Icons: there is no conflict with use of { } for other reasons ( set , spawns, combines) because the Generic Constraint icon is only used on an attribute scale (---->).

Note 2. Icons: compare the use of ----[----]---- as keyed icons for Limit, which is a Fundamental Constraint.

Note 3 Icons: The simultaneous existence, as a requirement specification, of both Fundamental Constraints and Generic Constraints is quite possible. One Constraint specification can even be both (Fundamental and Generic). They might even apply simultaneously (Time qualifier)and with same qualifiers otherwise (Place, Event)

----------F1[-------GC1{---------GC2{-----------}GC3-----------}GC4-----------]F2------->

In specific instances, the icons of specific synonyms such as Fail (->>) and Goal (->) can be applied to express Generic Constraints..

The open side’ (this side}’ or ‘ {this side)’, is the direction of acceptable attribute levels. ----NO {-----OK-----}NO-------

Rationale [Generic Constraint]: this classification is used to emphasize the fact that the actual practical constraint applied at the local level of specification will need to be tailored to that specific level. It will have to be ‘generated’ depending on the Generic Constraint specification, and the corresponding local context. This is the ‘derived constraint’ (a specific local constraint derived from a generic constraint).

Notes:

Note 1. Consequence Analysis. Generic constraints are generally (not always) set by powerful stakeholders and are generally not subject to much negotiation. Of course they can be in conflict with each other, and with any other requirements specifications or system environment realities. So they need to be examined in terms of their design consequences, costs and qualities. If necessary, some feedback, to the stakeholders concerned, will be necessary, and may result in modification, ignoring or removal of the constraint.

Note 2. Outer Border. A generic constraint is a specification, which ‘draws a border’ regarding requirements or design, but which allows more-specific requirements (which can be specific constraints on requirements or design) to be specified inside that border.

Note 3. Probably Global . Generic constraints usually consider interests, which are broader or more fundamental than a specific project or product (or other ‘lower level’ or ‘shorter-term’ perspectives). For example interests of a product line, or national laws and customs. To the degree they have wide application, they are also classified as Global.

Note 4. Conflict Analysis . In cases of a conflict between any generic constraint and any other specification, a generic constraint probably has a priority which is higher than any conflicting specific requirement or design. But this entirely depends on the exact nature of the information about the requirements which determine priority {Authority, Source, Priority, qualifiers [such as when, where and event conditions] }. To the degree which it does have priority over others, it is also classed as a Fundamental Constraint.

Related Concepts [Generic Constraint]: ‘applies to defined scope, and will be tailored locally’

  • Constraint , *218.
  • Requirement,
  • Fundamental Constraints. Of basic unquestionable authority and priority.
  • specific constraint.,
  • Global Constraint. *245: of wide scope, entire defined system scope, local tailoring not generally necessary.
  • Generic ( *081), defined scope, reusable, tailored, local interpretation.

Sub-categories [Generic Constraint]:

The potential Generic Constraint sub-categories are entirely open to the needs of the project. But there are some categories which are typical and frequent. These are the same as for any constraint, including specific constraints and global constraints.

Examples:

Function, Performance and Cost:

which mirror the three main other categories of requirements. The distinction here is that the Generic Constraint specifications are defined a level outside of the specific areas that they impact.

Other categories: Legal, National, Market area, Competitive, Partnerships, Product Line Architecture, Design ( *181) , Interfaces, Cultural, Ethical, System Component Constraints, Financial, Large Customer constraints, System-wide, Corporate Policy, Standards, and as many more possibilities, as you find useful.

Example:

Corporate Reliability:

Type: Generic Quality Constraint.

Scale: Mean Time Between Failure (MTBF).

Limit [All Corporate Branded Products] 30,000 hours <- Corporate Quality Policy.

This would make invalid any attempt to specify, as a specific quality requirement (example below):

Product Reliability:

Type: Quality Requirement.

Scale: MTBF .

Goal [ Product XX ] 20,000 hours <- Customer Contract.

Wish [ Product Next Generation ] 40,000 hours <- Marketing Long Term Plan.

The above requirement would have to be adjusted to the minimum of 30,000 hours MTBF in order to satisfy the corporate minimum quality

(the Generic Quality Constraint, which due to the qualifier, and the ‘Limit’ parameter, has higher priority, and could also be classed as a Fundamental Constraint)

for Product XX and not hurt their brand image

But, the specific requirement for ‘ Product Next Generation ’ would not need to be adjusted to comply with the current corporate generic requirement, as it is an improvement (40k>30k) over the corporate criteria.

We could explain this adjustment to people who might not otherwise understand why we had increased the specification beyond the customer’s wish.

Example:

Product Reliability:

Type: Quality Requirement.

Scale: MTBF.

Goal [Product XX] 30,000 hours <- Customer Contract & Corporate Reliability.

Constraint: Corporate Reliability.

Stakeholder: Corporate Quality Director.

Figure: three simultaneously applicable generic constraints, leave onearea of common “OK” territory for more specific decisions to be made, such as specific requirements and designs.

Some other examples.

GF1: Type: Generic Function Constraint:

Defined: The product must be a mobile telephone; and not wander into replacing or supplementing computers or entertainment or automated guidance systems.

Rationale: this would impact other of our business areas and partnership agreements with Company X and Company Y. <- Corporate Product Policy Feb 20 2005. Paragraph 33.4

GF2: Type: Generic Function Constraint:

Defined: The Mission is strictly limited to scientific exploration of our own planet, and must not deal with other planets or solar systems.

Rationale: this is NASA and JPL territory.

GSC1: Type: Generic System Constraint:

Defined: No aspect of the system can threaten sister company products, or national laws in any way: this includes quality, costs, targeted markets, technology selection and manufacturing and disposal processes; but is not limited to the foregoing list of potential specific concerns.

Rationale: Company Product Development Policy <-- CDP Feb 20 20051, 3.44.

Illustration text: Architects make system-wide decisions, which must be respected by all other engineers. For example, ‘system interfaces’ to enable safe, fast {change, tailoring, extension, development steps}. These are generally both generic constraints, and fundamental constraints. Design engineers try to reach quality targets, within the specified cost requirements, for specific subsystems.

Case:

Design constraints ( *181) may also be a type of generic constraint.

For example, on Howard Hughes’ ‘Spruce Goose’ aircraft (which was on public display in Long Beach, California) he was given a wartime design constraint, due to wartime metal shortages, of minimizing use of metal in the plane’s design**.

So he mainly used wood (‘spruce’). He respected his design constraints. The wingspan was about 2.5 times that of a jumbo jet. Yes, it flew; once!

** My father, Tyrell T. Gilb (1916-2001) had the job of the detailed engineering of the plane for Hughes to reduce metal content, he told me. <- TG.

Example:

GC:

Type: Generic Quality Constraint.

All <product> qualities must be <obviously better> than all our <competitors>.

This is a constraint on how low any specific quality level can be planned.

Notice this level varies with the competitors’ qualities.

This statement might also be directly specified as a Fail or a Limit level level specification for all quality requirements. But, more likely a set of different Fail requirements will be set within the framework provided by the generic constraint ‘GC’.

Generic Objectives: Concept *216 . July 29, 2001

A template objective, that is basic to many situations, and can be used as a checklist item to remember to include this objective. It is also a basis for tailoring that objective more precisely to the current situation.

“Whereas strategic objectives are intended to define the concerns of a single decisionmaker for all decision situations, generic objectives attempt to define the concerns of all decisionmakers in a single decision situation.”

Source: Keeney, page 63.

Generic Requirement: Concept *216 July 29, 2001

A generic requirement is one intended for potential use in many systems or sub-systems. It is always reusable, and often tailorable.

Note 1. A template of the requirement is used as the basic start point for tailoring any instance of that requirement more precisely to a specific situation.

Note 2. Checklists of generic requirements are useful to ensure that they are used wherever relevant.

Note 3. It can be of several types including constraint and template.

Note 4. One powerful tactic for specification of a generic requirement is to use Scale Qualifiers.

Example [2 scale qualifiers]:

Scale: hours for [User Type] to successfully complete [Task].

The term ‘generic objective’ was coined by Keeney [KEENEY92].

“Whereas strategic objectives are intended to define the concerns of a single decision maker for all decision situations, generic objectives attempt to define the concerns of all decision makers in a single decision situation.”

Source: [KEENEY92 page 63]

Synonym: Generic Objective, template requirement.

Keyed Icon: <@> (Fuzzy Requirement).

Type: requirements hierarchy class. {Requirement.generic}

Generic Standard (adjective): Concept *150 . July 29&30, 2001

A 'generic' standard is an example, model, specification, form, or template of a work process standard, which can then be tailored, or applied without tailoring, by their user to suit their purposes.

Synonym: Work Process Standard, *138 (sometimes equivalent, see below).

Note 1. There are generic standards for forms, for meters, policies and other useful artifacts in this book.

Note 2. Generic standards are intended to be used (read, applied, taught from) directly by an organization.

Related Concepts:

Template, *254: An example or ‘model’ of something, which can be used to help people to tailor, or make something, based on that model. A template can be for something other than a ‘standard’. A generic standard can be presented in a form other than a template (for example a form or list or model). Generic templates are intended to be ‘filled out’ or ‘copied’, or more or less copied, with small modifications locally, and used by a local user. They are but one type of generic standard.

Work Process Standard, *138: A work process standard is an ‘official’ written specification that guides a defined group of engineers in doing a process. It is a best-known practice.

Generic Term: Concept *377 . July 30, 2001

A generic term is a Term in a Specification that needs further definition, there or elsewhere.

Related Concepts:

Specific ( *136): ‘Specific’ means applicable to a limited, specified set of things.

Generic ( *081): Generic means applicable to a large group or set of things. It implies that the things are ‘reusable’ in a variety of situations. Needs further definition.

Term ( *151): A set of words and/or symbols (including icons) with a Planguage-defined meaning.

For example (1), Scale Qualifiers ( *381) are one example of generic terms: this could be a Generic Standard ( *150) – a template for a ‘User Reaction’ definition.

User Reaction:

Scale: Probability that defined [People] will report defined [Faults] within defined [Time Limits].

Then somewhere, just here locally, or in a more global Project Glossary, we define the Generic Terms

For example (2): ( and these could also be either Generic Standards, or specific to the project. ‘….’ Indicates a ‘list of more detail’, which we choose not to show here.

People: Defined: The class of customer, {Customers (Default), Trial Users, …}.

Faults: Defined: The class of Faults, {Show Stoppers, Help Problems, … }.

Time Limits: Defined: Time from Fault occurred until report received and logged by us. {n Hours, N Days, Same Day}.

In the example (1) ‘defined [People]’ and two other similar qualifiers in the Scale Specification, are Generic Terms. That means, they need further definition.

They are defined in example (2), and a set of known values for each is listed in the {Set Parenthesis }. Even this definition (2) is a Generic Term, because it needs further definition to pick the exact class or time.

One People class (2), (‘Customers (default)’ ) is identified as the ‘Default Value’ ( *447) .

The use of these terms is illustrated by the example (3): using Scale Variables ( *446)

User Reaction:

Scale: Probability that defined [People, Default: Customers] will report defined [Faults] within defined [Time Limits].

Fail [Customers, Show Stoppers, 24-Hours] 90%

Goal [ People = Trial Users, Faults = Help, Time Limits = 1 hour] 99%

Wish [ Faults = Show Stoppers, Same Day] 95%

Note [Illustration 3].

We have illustrated defining the Specific Terms by simply using defined Term Classes (‘{Show Stoppers, Help Problems}’), and even doing so (3, Fail) in the same sequence (‘People (Faults (Time Limits’)) in which the Generic Terms were specified, in the Scale specification (1 above).

We also illustrated (3, Wish & Goal) the use of Explicit Parameters (example ‘Faults =’) for defining Specific Terms (example ‘Help’).

Reliability:

Type: Quality Requirement.

Scale: Mean Time Between Failure from defined [Event Beginning] to defined [Event Ending] for defined [System] under defined [Circumstances].

Meter: defined [Test Circumstances {Development, Acceptance Test, Operation}] <specify or refer to test procedure or protocol or standard>

Goal [<when, where, which circumstances>] <a level such as 30,000 hours> ( <Source.>

Authority: <which levels of management, or customer contract, determine the level?>

This is a simple example of a generic template for a quality requirement. The terms in <fuzzy> are template ‘hints’. Instructions as to what to fill out. The intent is that they be removed from an electronic template when used. Both the Scale Qualifiers (like ‘Event Beginning’) and the hints (like <when>) are Generic Term examples.

Gist∑ Concept *157 January 3, 2003

A Gist parameter is used to state the essence, or main point, of a specification. A Gist is a summary of the detailed specification.

Rationale:

A good Gist serves two purposes:

  • it helps a planning group to agree on the summary of a specification, before they spend more time formulating the specification in greater detail.

  • it summarizes a detailed specification. This serves several purposes:

. readers can quickly grasp the subject matter

. readers can decide to avoid the detail

. presenters can refer to a specification by using just its tag name and Gist (A reader who needs more detail can ‘drill down’ to the detail using the tag name).

Examples:

Gist: All the functions related to transportation of people.

Software Interfaces:

Type: Architecture.

∑: The total set of software interfaces needed for this project.

Notes:

1. The detailed specification may already exist, or it may be made on the basis of an agreement about the Gist.

2. When summarizing a scalar specification, use the more specific parameter ‘Ambition.’

Synonym [Gist *157]: Summary *157.

Related Concept [Gist *157]: Ambition *423.

Keyed Icon [Gist *157]: ∑

“Greek Summa, mathematical summary symbol.”

Type: Parameter.

Global Concept *375 January 11, 2003

‘Global’ is an adjective used to specify that something applies to all (each individual component) of the set of components within the specified scope.

Notes:

1. A global specification applies across all the components within its declared scope.

For example: a Reliability specification declared as global for a system will have implications for all system components which contribute to the system reliability.

Related Concepts [Global *375]:

  • Local *376
  • Inherited *516 “Global specifications lead to inherited specifications.”

Type: Adjective, Scope.

Global Constraint Concept *245 . July 30, 2001

A Global Constraint applies for a defined system scope, unless overridden by higher priority specifications.

Type: requirements class, parameter. {Specification.Requirement.Constraint.Global}.

Notes:

Note 1:Even a global constraint is limited in effect by all its attached priority information {Qualifiers, Authority, Scope ( *419)}. For example, a global constraint may be relative to a defined set of stakeholders. It is not absolute for the universe of all stakeholders. This is part of the system scope in its definition. For example, the constraint may apply only to ‘User = School Teachers’.

Note 2: A global constraint only has a level of authority which is specified, or implied (by Sources for example) in its Scope. It must compete for priority with Authority, and other priority-determining specifications, throughout its scope. It does not have higher priority automatically, just because it is global in scope.

Note 3: a global constraint may apply to a wider systems area than other constraints and other requirements. But the areas it applies to are defined by qualifiers or other suitable parameters describing it. For example by Depends On, Impacts, Authority.

Synonym: system level requirement, constraint (often used as a short form of Global Constraint, local constraints are then often referred to as ‘specific requirements’).

Keyed Icon: ---X [----]Y--- . X and Y are tags of Global Constraints.

In specific instances the icons of specific synonyms such as Fail (->>) and Goal (->) can be applied.

The qualifier parenthesis (‘[…]’) can be used singly or together when placed on an attribute arrow (‘->, ‘----’)..

The open side ‘this side]’ or ‘ [this side’ is the direction of acceptable attribute levels. The

Notes: (continued)

4. Global Constraints are often set by powerful stakeholders and are then generally not subject to much negotiation. Of course they can be in conflict with each other, and with business needs, so they need to be examined in terms of their design consequences, costs and qualities. If necessary, some feedback, to the stakeholders concerned, will be necessary, and may result in modification, overriding or removal of the constraint.

5. A Global Constraint is a specification, which ‘draws a border’ regarding requirements or design, but which allows more specific requirements (which can be specific constraints on requirements or design) to be specified inside that border. For example: ---GC[----->>Fail-------->O

6. Global Constraints usually consider interests, which are broader or more fundamental than a more-local project or product (or other ‘lower level’ or ‘shorter-term’ perspectives). For example, interests of a product line, company policy or national laws and customs.

7. In cases of a conflict between any Global Constraint and any other specification, a Global Constraint usually has a priority, which is higher than any conflicting specific requirement or design. But the qualifiers and other parameters such as Authority will determine its real priority in particular instances.

Related Concepts [Global Constraint]: ‘defined system scope’.

  • Constraint *218, “All project components” for example.
  • Generic Constraint, *245: ‘A generic constraint applies, and must be tailored locally, to a defined class or group.’ . “All Quality specifications” for example.
  • Requirement,
  • Fundamental Constraints. Of basic unquestionable authority and priority.
  • Local Constraint.
  • Local ( *376) specification. ,
  • Scope ( *419), Global Scope ( see *419), Local Scope (see *419)

Sub-categories [Global Constraint]:

The potential Global Constraint sub-categories are entirely open to the needs of the project. But there are some categories, which are typical and frequent.

Examples:

1. Performance/Quality and Cost constraints.

The distinction here is that the Global Constraint specifications have wider scope than any of the non-Global Constraint specifications.

2. Other Global Constraint categories: Legal, National, Market area, Competitive, Partnerships, Product Line Architecture, Design, Interfaces, Cultural, Ethical, System Component Constraints, Financial, Large Customer constraints, System-wide, Corporate Policy, Standards, and many more possibilities, as you find useful. Again the distinction is wide scope.

Example:

Corporate Reliability:

Type: Global Quality Constraint.

Scale: Mean Time Between Failure (MTBF).

Fail [All Corporate Branded Products] 30,000 hours <- Corporate Quality Policy.

This would make invalid any attempt to specify, as a local quality requirement:

Product Reliability:

Type: Quality Requirement.

Scale: MTBF.

Goal [Product XX] 20,000 hours <- Customer Contract.

Wish [Product Next Generation] 40,000 hours <- Marketing Long Term Plan.

The above requirement would have to be adjusted to the minimum of 30,000 hours MTBF in order to satisfy the corporate minimum quality (the Global Quality Constraint) for Product XX and not hurt their brand image. But, the local requirement for ‘Product Next Generation ’ would not need to be adjusted to comply with the current corporate Global requirement, as it is an improvement over the corporate criteria.

We could explain this adjustment to people who might not otherwise understand why we had increased the specification beyond the customer’s wish.

Example:

Product Reliability :

Type: Quality Requirement.

Scale: MTBF .

Goal [ Product XX ] 30,000 hours <- Customer Contract & Corporate Reliability.

Constraint: Corporate Reliability .

Stakeholder: Corporate Quality Director .

Figure: three simultaneously applicable Global Constraints, leave onearea of common “OK” territory for more specific decisions to be made, such as specific requirements and designs.

Some other examples:

GF1: Type: Global Function Constraint:

Defined: The product must be a mobile telephone and not wander into replacing or supplementing computers or entertainment or automated guidance systems.

Rationale: this would impact other of our business areas and partnership agreements with Company X and Company Y. <- Corporate Product Policy Feb 20 20xx. Paragraph 33.4

GF2: Type: Global Function Constraint:

Defined: The Mission is strictly limited to scientific exploration of our own planet and must not deal with other planets or solar systems.

Rationale: this is NASA and JPL territory.

GSC1: Type: Global System Constraint:

Definition: No aspect of the system can threaten sister company products, or national laws in any way: this includes quality, costs, targeted markets, technology selection and manufacturing and disposal processes; but is not limited to the foregoing list of potential specific concerns.

Rationale: Company Product Development Policy <-- CDP Feb 20 20xx, 3.44.

Illustration text: Architects make system-wide decisions, which must be respected by all other engineers. For example, ‘system interfaces’ to enable safe, fast {change, tailoring, extension, development steps}. Design engineers try to reach quality targets, within the specified cost requirements, for specific subsystems.

Example:

GC:

Type: Global Quality Constraint.

All <product> qualities must be <obviously better> than all our <competitors>.

This is a constraint on how low any specific quality level can be planned. Notice this level varies with the competitors’ qualities.

This statement might also be directly specified as a constraint specification for all quality requirements. But, more likely a set of different constraint requirements will be set within the framework provided by the Global Constraint ‘GC’.

Goal Concept *109 March 15, 2003

A goal is a primary numeric target level of performance.

A Goal parameter is used to specify a performance target for a scalar attribute.

A Goal level is specified on a defined scale of measure with its relevant qualifying conditions [time, place, event].

An implication of a Goal specification is that there is, or will be, a commitment to deliver the Goal level (something not true of a Stretch or Wish target specification).

Any commitment is based on a trade-off process, against other targets, and considering any constraints. The specified goal level may need to go through a series of changes, as circumstances alter and are taken into consideration.

A specified Goal level will reasonably satisfy stakeholders. Going beyond the goal, at the cost of additional resources, is not considered necessary or profitable – even though it may have some value to do so.

Notes:

1. To reach a Goal level is a success to specific stakeholders. It is also a sort of ‘stop’ signal (a red light) for use of project resources on the specific performance attribute concerned: although better levels might be reached, and might be of value to some, they are not called for, under the stated conditions. For example, the additional value gained, given the estimated costs, is not viewed as worthwhile. In economic terms, we have at the Goal level probably reached the point of diminishing return on investment.

2. ‘Goal’ is intentionally not used for resource targets (‘Budget’ is used instead).

3. I now prefer the term ‘Goal’ instead of my traditional ‘Plan’ parameter. ‘Plan’ refers to so many other elements of planning. If an alternative were needed for Goal, I would use the more explicit ‘Planned Level.’

Example:

Glory : “Humpty’s and Alice’s problem, what does ‘glory’ mean?”

Scale: Number of Literature Citations to a defined [ Person’s Work ] during a defined [ Time Span ].

Goal [ Person’s Work = The Academic , Time Span = Each Decade ]: Over 1,000 <- Prof. H G. “That is glory!”

Synonyms [Goal *109]:

  • Plan *109 (historic usage only)
  • Planned Level *109 (historic usage only)
  • Goal Level *109 (see Level *337)
  • Planned Goal *109
  • Target [Intel, 2003]

Related Concepts [Goal *109]:

Keyed Icon [Goal *109]: >

“A single arrowhead, on a performance arrow, pointing towards the future. The same icon as for Budget *480 (which is on a resource arrow, --->--->O).”

In context: O---->---->

“Always use an output arrow from a function oval to represent a performance attribute. The Goal icon is the ‘>’ on the scalar arrow.

If other scalar levels are shown, the positioning of the tip of the icon symbol should reflect the Goal level relative to these other levels.”

Type [Goal *109]: Parameter [Scalar], Target.

Goal Step: ----)--- Concept *620 January 3, 2003

A goal step is an intermediate target level on the way to an agreed goal level.

Synonyms ( *620, Goal Step):

  • Intermediate target
  • Intermediate goal

Keyed Icon ( *620, Goal Step) ‘)‘ (in context -----)--->---->)

Noted this symbol is consistent with other target icons in pointing to right (future)

Domain: Requirements. Targets. Goal Steps

Related Concepts ( *620, Goal Step)

  • Evo step *141
  • Incremental Impact *220
  • Now level *513 ---(----
  • Delivered Level *533 ---•---•---

Grammar: Concept *160 . July 31, 2001

Implicit: Planguage grammar. The system of rules used by Planguage users to form statements and larger constructions or relations from Planguage elements. The rules for Planguage.

Guideline Concept *460 March 13, 2003 D

A guideline is specific written piece of advice, a recommendation, a tip, a hint, a suggestion, or a warning. It can be found in a specification, but is often placed into a set of guidelines, which are more widely available (sometimes held alongside the standards documentation).

Guidelines are not standards; they do not have absolute power. Their qualifiers and other parameters, such as ‘Authority’ and ‘Priority’ can give more information as to their individual priority.

Rationale: We need a term somewhat stronger than a comment, and somewhat weaker than a standard.

Example:

Goal [ USA , Fall Season ]: 60,000 Units .

GP : Guideline [ USA ]: We should normally plan to produce as much as we expect to sell.

Authority [Guideline]: General Sales Policy [ North America ].

Priority [ GP ]: This does not replace actual current production plans, which may consider stock on hand and business downturns, when setting production targets.

Synonyms [Guideline *460]:

Related Concepts [Guideline *460]:

Type [Guideline *460]: Guidance, Parameter.

Handbook Variant;: Concept *201 . July 31, 2001

A variation of the Planguage Handbook made for a particular organization, or language.

High-Level Concept *082 February 1, 2003

‘High-level’ refers to a position in a hierarchy of defined system components, which is ‘high’ (that is, closer to the top than the bottom) relative to the total defined set of those components.

Notes:

1. I would prefer if the term, ‘high-level,’ were not used in specifications because it is too imprecise. Specific reference ought to be made to the component(s) being referenced. For example, rather than specify a ‘high-level authority,’ specify the ‘Divisional Director.’

2. ‘High-level’ does not automatically translate to high priority in system implementation terms.

Related Concepts [High-Level *082]:

Type [High-Level *082]: Adjective [Relationship].

Hierarchical Concept *083 February 1, 2003

Hierarchical is an adjective used to describe ‘belonging to a hierarchy’. The elements of a hierarchy can be organized by some classification into distinct levels, where there is a relationship between the levels. Either the higher levels have some kind of authority or control over lower levels, or decomposition occurs down the hierarchy (the higher-levels can be broken down into their lower-level sub-components).

Notes:

1. Within systems engineering, there are several hierarchical structures of specific interest:

  • organizational/management structure hierarchies
  • process hierarchies
  • system specification hierarchies: The information relating to a system can be arranged in a hierarchy that stretches from the system name at the top hierarchical level, down through the different specification documents, to the individual attributes. For example: hierarchical tag names.

Example:

Hierarchical Tag 1. Hierarchical Tag 2. Local Tag:

The tags serve to locate ‘Local Tag’ in some specification hierarchy.

Type [Hierarchical *083]: Adjective [Relationship].

Historic Level (Of Attributes); Concept *084 . April 20, 2002

A joint term for the two Benchmark level specifications of attributes, Past and Record.

Related Concepts:

. *084={*<Past>. *<Record>}.

Note this does not include Trend and Future, which are benchmarks related to the future and are not in themselves historic .

Host System: Concept *348 . July 31, 2001

A host system receives the evolutionary delivery steps.

Icon Concept *161 February 27, 2003

In Planguage, an icon is a symbol, keyed (Keyed Icon) or drawn (Drawn Icon), that represents a concept. All Icons are graphic or pictorial in nature – they should not use words or national languages.

Related Concepts [Icon *161]:

Type [Icon *161]: Symbol.

Idea Concept *086 March 17, 2003

An ‘idea’ is an intellectual concept of any kind.

A plan, scheme, project, aim <- Webster’s Dictionary.

A plan, scheme, or method <- The American Heritage Dictionary.

Notes:

1. We are primarily interested in attribute ideas, design ideas and project delivery cycle (Evo step) ideas.

Related Concepts [Idea *086]:

Type [Idea *086]: Design Concept.

Ideal Concept *328 March 4, 2004

An ‘Ideal’ specification represents a hypothetical, and perhaps only theoretical, best target for stakeholders, irrespective of considerations, such as cost, available technology, or culture.

An Ideal parameter specifies an ideal level, on a defined Scale, under specified conditions for a scalar attribute.

Ideal is a target requirement, but it is not a committed target level. We might want to move towards it, hold it out as motivation, but we do not expect to reach it in practice. There is an argument that Ideal is also a benchmark type of requirement level.

Example:

Scale: Average distance in meters from average available parking place, or public transportation individual step off site, to nearest available office entrance.

Ideal [ Walking Impaired in Wheelchair ]: Less than 100 meters <- Employee Survey.

Ideal [ Senior Sales Executives & Others often in and out of office]: 50 meters.

Ideal [ Office Staff using Public Transport ]: 200 meters <- City Planning Guidelines .

Past [ People using Public Transport ]: 1,000 meters, [ Drivers Parking ]: 300 meters.

Goal [ New Office ]: 100 meters, [ New Office , People using Public Transport ]: 200 meters.

Ideal specifications document sentiment, but Goal specifications declare the officially adopted target that seems to balance with all other practical, political, and economic considerations.

Notes:

1. The reason we have other target levels, like Goal and Budget, is because they must be established by considering all constraints (such as time, money and technology). Ideal is idealist, and doesn’t have to worry about such mundane things. It can be established without regard or respect for economics or technology.

“The role of an ideal is not so much to be reached, but to focus the allocated time and effort toward achieving it. If indeed an ideal is achieved, a new ‘improved’ ideal should take its place to guide thought and action.” <-KEENEY92, quoting Russell Ackoff (1978) The Art of Problem Solving.

Related Concepts [Ideal *328]:

Keyed Icon [Ideal *328]: >++ “Explanation, more positive than Stretch ‘>+’.”

In context: ------>++------>

Type [Ideal *328]: Parameter [Scalar].

Historical Note: ‘Ideal’ was specified by Tom Gilb in 1996 after reading Keeney’s remarks [KEENEY92, page 210 (7.4)].

If Concept *399 February 5, 2003

‘If’ is a logical operator parameter used in qualifiers to explicitly specify conditions.

Note: The ‘If’ is implied for all terms in a qualifier. However, ‘If’ may be used to communicate a condition more explicitly to the novice reader.

Examples:

Goal: Legal Constraint [USA, If Law 153 Passed]: 99.9%.

Goal: Quality Requirement [If Europe, If Product XYZ Announced]: 60%.

Synonyms [If *399]:

Related Concepts [If *399]:

Keyed Icon [If *399]: ? “A question mark before a condition.”

The ‘?’ may be used before a condition, with a space between them. It should not be used after a condition since it would be ambiguous with uncertainty about the validity of the specification itself.

Examples:

Goal: Legal Constraint [? USA, ? Law 153 Passed]: 99.9%.

Goal: Quality Requirement [? Europe, ? Product XYZ Announced]: 60%.

Type [If *399]: Logical Operator.

Historical Note: Use of ‘Where’ as a synonym was suggested by Don Mills, New Zealand, www.softed.com .

Initiator Concept *424 . July 31, 2001

The Initiator is the person or instance who initiated a specification.

Type: Parameter, specification concept.

Usage: to identify the person or instance who originally initiated a particular specification; for any reason, such as keeping them informed, finding out more about why they did it – or what they specified; to determine if they still have any interest.

Rationale: knowing the initiator identifies a key stakeholder, gives you possibility of finding out the intent and the real deep reason behind the specification. It is a kind of Source and a kind of Authority.

Adaptability:

Initiator: Marketing. <- Market Plan 16 April 5.6.3

Impact Estimate Concept *433 June 6, 2003

An impact estimate is an evaluated guess as to the result of implementing a design idea. In other words, it is a considered, quantified guess of the effect on a specific scalar requirement attribute (performance or resource) of implementing a design idea (or set of design ideas) in a system (or system subset) under stated conditions.

A full impact estimate includes the following: a scale impact, a percentage impact and uncertainty data (known error margins). The additional related information required to support an impact estimate includes the evidence, source(s) and credibility.

Notes:

1. An impact estimate can be positive, neutral or negative (undesirable in relation to stated target levels).

2. Note the distinction between a scale impact (an absolute numeric value on a Scale), and a percentage impact (the percentage improvement estimated to be achieved in moving from the chosen baseline towards the chosen target).

3. An impact estimate is usually concerned with the system improvement,

rather than with stakeholder value (However, this depends on the choice of

requirement attribute: stakeholder value can be tackled, for example,

Financial Saving).

4. An impact estimate is usually on a scalar requirement. However, much more rarely, it can be on a binary requirement of the system (that is on a function requirement, a design constraint or a condition constraint). This is used in situations where an explicit check is considered necessary to help evaluate design ideas.

Abbreviation [Impact Estimate *433]:

  • Impact “Often ‘Impact’ is short for ‘Impact Estimate’. See also Impact *087

Keyed Icon [Impact Estimate *433]: ->.#

Note: the icon is made up of the impact symbol ‘->’ and the estimate symbol ‘#’, with the ‘.’ indicating that it is made up of two concepts.

Related Concepts [Impact Estimate *433]:

Type [Impact Estimate *433]: Scalar Design Metric.

Impact Estimation Concept *283 July 17, 2003

A Planguage method/process to evaluate the quantitative impacts of design ideas on requirements.

Description [Impact Estimation *283]: Chapter 9, “Impact Estimation: How to understand strategies and design ideas.”

Acronym [Impact Estimation *283]:

  • IE

Keyed Icon [Impact Estimation *283]: ->.# “Made up of the impact symbol and the estimate symbol. Note it is the same icon as for Impact Estimate *433

Type [Impact Estimation *283]: Method, Process.

Impact Estimation Table Concept *638 July 11, 2003

An impact estimation table (IE table) is the main output specification of an Impact Estimation process. An IE table shows estimates or actual measurements of the effect of any set of designs (architecture, strategy, solution) on any set of requirements. The emphasis is on the impact of designs on the performance and resource targets.

Notes:

1. An IE table can be used for a variety of purposes. These include:

  • to compare alternative design ideas
  • to select a set of design ideas
  • to determine how complete a design is (how completely a set of design ideas meets the set of requirements)
  • to identify areas where new design ideas are needed
  • to monitor progress of Evo steps towards the requirements

2. An IE table can be a powerful presentation aid. Care must be taken that the level of detail presented is appropriate to the audience.

3. An IE table presents a ‘snapshot’ of how well the set of scalar requirements are being met at a given point in time by the set of designs.

Acronyms [Impact Estimation Table *638]:

Related Concepts [Impact Estimation Table *638]:

Type [Impact Estimation Table *638]: Specification [Design Analysis].

Impacted By Concept *412 January 24, 2003

‘Impacted By’ is used to indicate any other specified items, (such as requirements, objectives, designs, policies, or conditions), which affect, or might affect, a defined specification itself, or what it refers to.

Notes:

1. The purpose of ‘Impacted By’ is to help in risk identification and analysis. We are trying to explicitly identify and document factors, which we believe influence the results. This will hopefully result in specific action or design to keep those impacts from threatening our planned results.

2. The more general purpose of Impacted By, and many other Planguage relationship mechanisms, is to build a ‘web of connections’ between specifications (that is, between system components). This web of connections serves many purposes. Risk management was mentioned above. Other uses are configuration management, system familiarization, quality control, estimation, contracting, prioritization, and reviewing.

Example:

A :

Danger List [ A ]:

Impacted By: { Help Desk Capacity , User Motivation , User Training , Bug Frequency }.

3. ‘Impacted By’ is differs from considerations of Risk/Threat in that both good and bad impacts are considered. With Risk/Threat, we are primarily concerned with the potential for negative impacts.

4. For strong primary intended impacts, the ‘Supports’ icon can be used, A ->> B. meaning A is primarily the way we intend to achieve the requirement/value B.

Related Concepts [Impacted By *412]:

Keyed Icon [Impacted By *412]: ->

Note: Used in the same way as for Impacts *334. B is impacted by A is written A -> B.

Example:

A -> B B is Impacted By A = A Impacts B .”

Type [Impacted By *412]: Parameter [Relationship].

Impact Concept *087 January 20, 2003

An ‘impact’ is the estimated or actual numeric effect of a design idea (or set of design ideas or Evo step) on a requirement attribute under given conditions.

Full impact information includes the following: a scale impact, a percentage impact and uncertainty data (known error margins). The additional related information required to support an impact includes the evidence, source(s) and credibility.

If an impact is estimated, it is an Impact Estimate *433.

Related Concepts [Impact *087]:

Type [Impact *087]: Noun, Scalar Metric Data.

Impacts Concept *334 February 5, 2003

The ‘Impacts’ parameter is used to identify the set of attributes that are considered likely to be impacted by a given attribute (usually another requirement attribute or a proposed design idea).

Notes:

1. ‘Impacts’ can be used to capture Impact Estimation table relationships before actual numeric estimation.

2. ‘Impacts’ differs from ‘Supports’ in that it can be used to identify side effects, including negative side effects, as well as the intended direct positive impacts.

Example:

Design Idea 1: Handbook Impacts {Learning, Development Cost}.

or

Design Idea 1: Handbook -> {Learning, Development Cost}.

Keyed Icon [Impacts *334]: ->

Note: this arrow icon is identical to ‘Until *551’ but the Until icon is only valid in the numeric context ( ‘30 ->60’). The Impacts arrow is only valid in the context of tags referring to things that can impact one another. Example Design A -> Requirement B.

Related Concepts [Impacts *334]:

Type [Impacts *334]: Parameter [Relationship], Verb.

Implementable Specification Concept *294 January 16, 2003

Implementable Specification refers to written specification that translates into real implemented systems. Most all major specification defects are found in implementable specifications. But not all defects in implementable specifications are major.

By definition, major defects are far less likely to be found in ‘background’ specification. But they are possibly there depending on how individuals specify.

It is important to distinguish between these concepts of implementable and background. Authors/writers need to try to make the distinction visually for readers (for example, by using plain text for implementable specifications, and italics for background specification , or specific parameters like ‘Note:’).

Notes:

1. Implementable sections of a specification can be called ‘meat’ and, background sections can be called ‘fat’ {typically – but not necessarily - notes, comments, remarks, background, summary, introduction, references, rationale}.

2. Checkers in SQC should concentrate on carrying out rigorous checking, at optimum checking rates on the implementable specifications. This gives better efficiency in finding major defects

3. When the visual distinction is made, and it is clear what is background and not; then quality control checkers can more easily, and more certainly, decide which defects are major and which are not. If the defects are found in background they are most likely minor. If found in implementable specifications, they are possibly major.

4. Parameters are fairly clearly either implementable specifications (Scale, Goal) or background (Ambition, Gist, Past) if you think about it. But local judgment must always be applied to decide if a specification is potentially major or not.

Implementation Cycle Concept *123 . January 2, 2003

An implementation cycle is part of a result cycle. It consists of the (Evo) development cycle, production cycle and delivery cycle.

Implementation means ‘taking a plan, or an idea, and turning it into reality’.

Notes:

1. An implementation cycle is comparable to a part of Shewhart’s ‘Plan Do Study Act’ cycle (Statistical Process Control Method) ; the ‘Act’ part of it.

2. The emphasis of an implementation cycle within Evo is on ‘contact with reality’ to obtain consequent feedback and enable later adjustment.

3. This can include factory production, software program writing, or any kind or realization of any design idea or prototype. It can include any kind of small change to a larger design.

4. The implementation cycle includes any related, supportive, development cycle process. The ‘development cycle’ is focused on research and development, rather than manufacture (‘the production cycle’) and distribution (‘the delivery cycle’) to customers, users and markets.

‘Implementation cycle’ contrasted with the ‘step’ concept.

Synonym [Implementation Cycle *123]: Implementation *123.

Related Concepts [Implementation Cycle *123]:

Type: Process.

Improvement [of Process]: Concept *088 . July 31, 2001

An ‘Improvement’ is a suggestion for process improvement by SQC Checkers, or any others.

Synonym “Process Improvement Suggestion”, Process Improvement

Domain: CE.DPP. *088

Keyed Icon: [___].->.^[…] ---- decoded: [Improvement].->.^[Process]

(speculative suggestion July 31, 2001.TG. Idea.Impacts.Process)

Type: artifact of Defect Prevention Process (DPP).

Note 1. Process Improvement suggestions are stimulated by current work with standards (procedures, rules, checklists, and forms).

Note 2. Process Improvement suggestions are usually reported and logged at an SQC Spec Meeting, a process meeting or anywhere else.

Note 3. The Improvements report is directed to the Owner of the process.

Note 4. Improvement suggestions need to be analyzed and tried out to find out if they have sufficient value-to-cost impact.

improvement: Concept *009 . July 31, 2001

Synonym for Benefit.

Note: not capitalized (‘i’).

Synonyms: relative improvement ( *009), benefit ( *009), saving ( *429).

Related Concepts:

  • Gap.
  • saving
  • benefit
  • incremental impact +->

Keyed icon [ *009]: O ---- <==|--->

Explanation: a differential ‘gap’ (==) between some benchmark ( ‘-<-‘) and some target (‘|’) – Any target symbol can be used instead of the neutral ‘|’ symbol. (examples >, >>).

Note: incremental impact +-> *220

Type: {requirement type, attribute characteristic}.

“Improvement … is the attainment of a new level of performance that is superior to any previous level.” JURAN74, 16-1.

Includes Concept *391 June 5, 2003

‘Includes’ expresses the concept of inclusion of a set of components within a larger set of components. ‘A Includes B.’ means that B is a sub-component of the component A.

Example:

B: Includes {C, D, E}.

Example:

Bee.WingsWings is a member of supra concept, or parent concept, Bee.”

Bee: Includes {Wings, Legs, Eyes, Sting, Body}.

Bee: {Wings, Legs, Eyes, Sting, Body}. “Includes is implied by the set parenthesis.”

Alternative formats and synonyms for Includes

Related Concepts [Includes *391]:

Keyed Icon [Includes *391]: { }

“In context: X: {A, B} means X includes A and B.”

Type [Includes *391]: Parameter [Relationship].

Incremental Development Concept *318 June 5, 2003

Incremental development means designing a system largely up-front, and then dividing its’ construction, and perhaps handover, into a series of cumulative increments.

Figure *318: Conceptual View of Incremental Project Management [HUMMEL02]. Compare with Figure *355 in Evolutionary Project Management *355

Notes:

1. Incremental Development is defined here in order to contrast it with, and distinguish it from, Evo:

  • Incremental development differs from Evo in that most all of the Incremental Development requirements design effort is up-front. In contrast Evo carries out

requirements and design detailing gradually in each Evo cycle

  • Incremental development is without Evo’s intent of measuring the progress of each (incremental) step fully (for example, measuring delivered performance levels), then learning from these feedback measures and, changing the requirements and/or design accordingly
  • Incremental development is also without the intent of delivering the steps (increments) with the highest ‘value to cost ratio’ or ‘performance to cost ratio’ first.

2. It is unfortunately common practice to say or write ‘incremental’ when the strictly correct term according to the distinctions defined here is ‘evolutionary’. Indeed, all evolutionary processes are also incremental, but they are a subclass deserving distinctive terminology to announce the differences. This ‘lazy’ use of the term is a sure sign of people who do not have deep understanding, or concern for, the value of feedback and change. Beware of their advice or opinions! The US DoD [DOD EVO02], among others, has taken the trouble to carefully distinguish these concepts!

Related Concepts [Incremental Development *318]:

  • Evolutionary Project Management (Evo) *355

Type [Incremental Development *

Incremental Scale Impact Concept *307 November 18, 2002

For a scalar requirement, this is the numeric impact of a design idea relative to the specified baseline level. If there is a negative impact, then the numeric value will be negative.

Scale Impact – Baseline = Incremental Scale Impact

Example:

Consider an objective concerning say, a ‘Customer Response Time’, with a defined Scale of ‘Minutes to Wait’.

If the Baseline was ‘Past: 20 minutes to wait’ and

the Target was ‘Goal: 5 minutes to wait’ and,

the Scale Impact (estimated or actual) of Design Idea X on Customer Response Time was a result of ‘12 minutes to wait’, then the Incremental Scale Impact is 8 minutes (20-12=8).

The Percentage Impact is 8/15 or 53% relative to the Baseline (0%, or 20 minutes) and to the Target (100%, or 5 minutes).

Note: Designs vary in their impact, depending on previous circumstances. The incremental impact is a function of these circumstances. The impact of a design idea is not a constant, irrespective of the circumstances it is implemented in. Percentage Impact is used to convey this in an Impact Estimation table.

Keyed Icon: +.->

Related Concepts:

  • Percentage Impact *306 (Synonyms: %Impact, Incremental Percentage Impact)
  • Scale Impact *403

Type: Numeric Variable.

Domain: Impact Estimation.

Indicator: Concept *195 . July 31, 2001 (

A parameter defining an indicator type, and its condition: Example {red light, flashing}.

Synonym: ‘Sign’ *195

Type: Planguage condition class.

Example:

Goal [Clear] >90% <- IEEE Technical Interface Recommendation PL-967

Clear: Indicator {Any green or flashing panel light, any screen equivalent indicating OK}.

Indirect Constraint:, Concept *511 March 16, 2003

any other specification, except a direct constraint, which indirectly has the effect of constraint.

This can include any other requirement {function, Goal, Wish, Stretch}, and previous and pre-emptive level of architecture or design, and any statement of priority attached to a specification (such as Authority, Source, Stakeholder).

Domain: Requirement.constraint.indirect.

Related Concepts:

  • direct constraint 510. Any constraint which is specified in the format of a constraint and is intended to directly constrain performance, function, costs or design. For example Limit, Fail, Constraint, [qualifiers].

Type: Constraint

Indirect Costs: Concept *250 . July 31, 2001

A resource (money, time, work-hours) needed to produce an input to a system.

Example:

work-hours are needed to produce high quality engineering drawings, which are themselves an input to a manufacturing and purchasing process. The cost of producing the engineering drawings to the required levels of quality is an indirect cost of manufacturing at a given level of efficiency.

Information Concept *320 March 12, 2003

Information is the interpretation an agent gives to data.

Notes:

1. Information includes {interpretation, conclusions, signals to act, basis for decisions}.

2. Planguage is both a way of organizing data (the language element organizes) to make it useful and meaningful, and also a set of processes (the defined processes, rules, and principles) to interpret data into useful information (such as Impact Estimation).

Information can tell us everything. It has all the answers. But they are answers to questions we have not asked, and which doubtless don’t even arise.

Jean Baudrillard (b. 1929), French semiologist. Cool Memories, Ch. 5 (1987; tr. 1990).

Related Concepts [Information *320]:

  • Agent *163
  • Data *319: Raw facts before used by an agent to get information.

Type [Information *320]: Communication Concept.

Infotect: Concept *568 July 12, 2002

The Infotect is

Related Concepts [Infotect, *568]

  • Systect *565. an Infotect is a subordinate design function to systects.
  • Software engineer, *571. A software engineer is a parallel discipline subsidiary to systems engineering and systems architecture. A software engineer is primarily concerned with the process of providing instruction for computers.
  • Systems engineer, *574. A systems engineer could co-ordinate an Infotect if infotecture was a minor part of the system project. But it could be the other way around. An infotecture project for a corporation or organization could spawn supporting sub-projects which might require systems engineering for that subset.
  • Softcrafter, *573. A Softcrafter is usually called a programmer, and unfortunately also called a ‘software engineer’. We use softcrafter to describe the craft of writing, modifying or assembling computer programs. It is not an engineering or architectural discipline, no more than any other craft such as carpentry, electrical work, painter or plumber.
  • Architect, *193. an Infotect is an information system architect.

Infotecture: Concept *569 July 12, 2002

Infotecture is a discipline practiced by Infotects ( *568 see this). It is information systems architecture.

Related Concepts [ *569, Infotecture]

  • Systecture, *564. Systems architecture has, as a subset, ‘infotecture’, and software systems architecture (Software Systecture)
  • Architecture , *192. Infotecture is a specialized architecture discipline limited to information systems of any kind, and not necessarily including computers or software!

Infoware: Concept *578 . July 12, 2002

Infoware encompasses any devices for informing people about ideas. Infoware is information carriers in the widest sense of the word.

This includes anything people can read (test, diagrams, pictures) and any real artifacts which people can learn something from such as: models, prototypes, real systems, people, groups, organizations, any observable part of the universe.

Related Concepts [Infoware, *578] – all these are types of Infoware

  • Dataware, *576
  • Planware, *577 Planware is plans (information, data) for humans .
  • Documentation, *579 documentation is primarily for human instruction about system operation
  • Logicware *575 is the ‘active’ logic directing computers in their actions. Logicware is not primarily Infoware – except to the degree humans access it for information directly. Some logicware is generated by computer software, for computer consumption and is not intended for human instruction – it is not Infoware.
  • information *320 is the interpretation we get from analyzing infoware.

Inherited Concept *516 May 4, 2003

A specification element is termed ‘inherited’ if it applies implicitly to a specific specification.

Inherited specification elements are not directly specified in a statement (that is, they are not local to a given specification), but they are inherited from related specifications, usually those at a higher level (a supra-specification).

Example:

Usability:

Type: Quality Requirement.

Kid Specifications: {Learning, Doing}. “Usability is defined here as consisting of these two qualities.”

Deadline: Time: End of Year.

Then in a different, non-local specification:

Learning: Scale: Time to <learn> System. Goal: 60 minutes.

Doing: Scale: Time to <correctly finish> defined [Average Tasks].

Goal: 5 minutes.

Goal [1 st Release]: 10 minutes.

Type and Deadline are specification elements of the parent specification Usability. They are inherited by the Kid Specifications, Learning and Doing. The Goal [1 st Release] does not inherit the Usability.Time deadline because it explicitly has another overriding specification.

Related Concepts [Inherited *516]:

  • Global *373: Global specifications become inherited specifications where they apply.
  • Local *376: Local specifications at a high specification level can become global to lower specification levels and can therefore be inherited.

Type [Inherited *516]: Specification Concept.

Input Concept *331 June 17, 2003

Input (or system input) is anything, which enters a system.

Notes:

1. Input has two primary uses in Planguage: it is either used to describe a function input (a resource attribute), or to describe a process input (a resource asset).

Synonyms [Input *331]:

Related Concepts [Input *331]:

Drawn Icon [Input *331]:

For a function input (a resource attribute), the icon is an arrow entering the function icon (oval) from the left or west.

Figure *331a: Function inputs, also known as resources (resource attributes)

For a process input (a resource asset), the icon is an arrow entering the top side of the process rectangle.

Figure *331b: Process input

Type [Input *331]: Resource Attribute or Resource Asset.

Input/output axis. Concept *260 . August 1, 2001

The vertical axis of a process rectangle. The top represents inputs to the process (data and/or material). DE below. The bottom represents outputs from the process (data and/or material). DX below. Abbreviation: I/O Axis.

Not co-incidentally the top side also represent the ‘Do ‘ part of the PDSA cycle , and the bottom part represents the ‘Act ‘ part of the cycle.

Inspection Concept *051 November 21, 2002

‘Inspection’ is a synonym for Specification Quality Control (SQC).

Notes:

1. Michael Fagan originated the term ‘Inspection’ in connection with software within IBM. He developed the initial method for quality control of software. It is based on the work of Walter Shewhart, Joseph Juran and others, who used the term for quality control of products (rather than of specifications). Given the confusion in engineering environments over the use of the term ‘Inspection’ (to hardware engineers it means quality control after production of something), I prefer to use the term, SQC.

2. Many people incorrectly equate the Defect Detection Process (DDP) with ‘Inspection.’ They omit the Defect Prevention Process (DPP). This is because they are unaware of the additional developments to Inspection introduced by Mays and Jones [MAYS95].

Synonyms: Specification Quality Control (SQC) *051, Peer Review (one type of, SEI CMM Level 3).

Type: Process.

Domain: SQC.

Integration Concept *357 February 24, 2003 tg

Integration is the process of inserting Evo step components into a system.

It is part of the production cycle (which is one of the three major sub-processes for implementation of an Evo step {development, production and delivery}).

Integration is part of the Production Cycle.

Integration works with developed or acquired step components, and does whatever it takes to integrate them into a system. Deployment within the delivery cycle then moves the system upgrades out to the result stakeholders.

Related Concepts [Integration *357]:

Type [Integration *357]: Process.

Domain [Integration *357]: Evo

Interface Concept *194 March 13, 2003

An interface is an agreed connection and boundary between system components.

Notes:

1. An interface can consist of anything useful: for example a device, a definition, or a language that helps to connect system components.

2. It is the device, or the means, which two system components use to connect with each other, for any purpose.

Related Concepts [Interface *194]:

Type [Interface *194]: System Component [Architecture].

Internal Concept *496 May 9, 2003

When describing the relationship amongst objects, internal is an adjective, which applies to any object inside the scope of a given object.

Examples:

  • Internal stakeholders of a system
  • Internal components of a device
  • Internal modules of an application
  • Internal staff within an organization

Notes:

1. ‘Internal’ is used with regards the ‘place’ scope of an object, rather than the ‘time’ or ‘event’ scope. ‘Where’ does an object stand with regard another object: within its extent of influence (internal) or outside it (external)?

2. An internal object can literally be a physical part of some larger object.

Related Concepts [Internal *496]:

Type [Internal *496]: Adjective.

Internal Stakeholder *494 Oct 27 2001

Internal stakeholders are stakeholders that directly impact a defined focus system. They are related to the environment systems supporting the focus system.

For example a tester is an internal stakeholder for a test process supporting the development of a product (defined as a focus system).

Related Concepts:

Type: relation concept.

Internal Environment diagram (suggested by L. Brodie 18 Nov 2002)

Is Part Of Concept *621 . November 29, 2002

A Parameter which indicates that a specification is a component or element of something else.

Related Concepts *022

  • Consists Of *616
  • Includes *391 Includes can give a partial list of contents.
  • Spawns/Generates *392 Spawns implies active generation, not inclusion or consisting
  • Component *022
  • Element *022

Keyed Icon *621

X {y}. meaning y is included in X

Issue Concept *276 June 4, 2002

An issue is any subject of concern that needs to be noted for analysis and resolution.

Example:

ISS1: Issue: We have not analyzed risks and dependencies yet.

Notes:

1. A specification issue is an element of written specification, which we suspect violates a specification rule. It is noted for later resolution. It will be resolved by being declared to be either a defect (a rule violation) or as requiring no further action.

Example:

“An important distinction is that between ‘risks’ and ‘issues’. Issues can be defined as ‘previously unidentified risks/problems that are perceived to have occurred or are certainly going to occur, the probability of occurrence being 100%. Unlike risks, which may or may not come into play, issues will occur. It is more important to construct complete contingency plans for issues, therefore, since, with an issue, it is certain that an adverse impact on the programme will occur if no action is taken.”

<- Clive Fenton, [ELLIOT02, Chapter 2, Section 5]

Related Concepts [Issue *276]:

Type [Issue *276]: Parameter, Feedback.

Item [SQC] Concept *300 February 25, 2003

An item is a term for whatever gets reported by checkers and then logged by a Scribe during SQC logging.

Notes:

1. In the Specification Meeting an item is a member of the set of {issue {super-major, major, minor, new (as in found ‘new’ during a logging meeting)}, process improvement suggestion, question of intent to the author}.

Type [Item [SQC] *300]: Specification Concept.

Keyed Icon Concept *144 February 25, 2003

A keyed icon is a non-alphabetic and non-mnemonic set of one or more key-able characters that make up a keyed icon symbol, with defined interpretation.

The choice of keyed characters is as closely related as possible to the corresponding icon, and ideally is acceptable to all language cultures.

The keyed icon will normally be combined with tags and other Planguage terms to give complete statements or expressions. For example ‘A <- B’ (B is source for A). A pure icon is a possibility, for example ‘O--->’ indicating a performance characteristic.

Some keyed icons, like many words, are ambiguous in isolation, but are unambiguous in context of other specifications.

Rationale:

[Editor Note to Publisher: Needs correct Appendix Reference Below.]

See Appendix ZZ, ‘Keyed Icons.’

Related Concepts [Keyed Icon *144]:

Type [Keyed Icon *144]: Symbol.

Kid Concept *266 February 23, 2003

The kid is the immediate offspring or subset of any component type with any sub-components (for example, function, process, plan, step or system).

Related Concepts [Kid *266]:

Type [Kid *266]: Role [Relationship].

Kickoff [SQC]: : Concept *286 . August 1, 2001

Kickoff is an SQC sub-process. It usually involves a team meeting to agree on the master plan, and to commit to doing the planned SQC work.

Type: Process.

Domain: SQC

Kin Concept *353 November 13, 2002

Kin specifications are specifications, which derive from an identical set of source specifications.

For example, test plans, source code and user handbooks could all be derived from the same requirements or the same design.

Kin specifications can serve as additional information to perform defect checking in the Specification Quality Control (SQC) process. For example, United Defense in Minnesota reported [personal communication] that their software engineering checked the program code against their test cases, both derived from the same requirements. They reported that they usefully found major defects in both these kin documents.

Type: Relationship Adjective.

Domain: SQC.

Landing Zone Concept *605 May 23, 2003 B

A landing zone is a target range that stretches from just better than a Fail level through the Goal/Budget level to the Stretch Level.

Notes:

1. A landing zone is analogous to a parachute’s landing zone. A range that we realistically hope we can land in somewhere. This avoids the simplified notion of an exact Goal/Budget being the target.

2. For a set of requirements, the overall landing zone is the set of landing zones, which ‘creates a space’ over all the requirement dimensions.

Figure *605a: A simple example showing multi-dimensional landing zones. It is landing within all the landing zones simultaneously that is the aim (Courtesy of Erik Simmons, Intel).

3. The multi-dimensionality of landing zones is an important feature. The space below Goal may seem unacceptable, but when you consider all dimensions at once, sub-par achievement in a single dimension is completely acceptable, if it means optimal system performance.

4. A landing zone covers a success range and an acceptable range.

Figure *605 b Diagram shows the extent of the landing zone for the two types

of scalar attribute, resource and performance

Related Concepts [Landing Zone *605]:

Type [Landing Zone *605]: Scalar Concept.

Historical Note: The source of the Landing Zone concept was Intel, Oregon (via Erik Simmons, 2002).

Language: Concept *373 .August 2, 2001

An {agreed, understood, defined} {written, graphical or oral} means of expressing any ideas, concepts or notions.

We are particularly interested in a specialized language for systems engineering and management, which we call “Planguage” here.

Level Concept *337 March 5, 2003

A level is a defined numeric position on a scale of measure.

Notes:

1. A scalar level applies to either a performance or a resource attribute.

2. A level on a scale of measure indicates one of the following:

  • a benchmark: an actual measurement or estimated level in the past
  • a target: a requirement level
  • a constraint: a limit
  • an estimate of the impact of a design idea

Synonyms [Level *337]:

  • Point *337: A position on a Scale.

Related Concepts [Level *337]:

  • Range *552
  • Goal *109: Goal Level
  • Budget *480: Budget Level
  • Stretch *404: Stretch Level
  • Wish *244: Wish Level
  • Fail *098: Fail Level
  • Survival *440: Survival Level
  • Catastrophe *602: Catastrophe Level
  • Past *106: Past Level
  • Record *127: Record Level
  • Trend *155: Trend Level
  • Limit *606: An extreme boundary of the range of a level

Keyed Icon [Level *337]: |

In context on a Scale: ----|--->

This is the generic attribute level icon. It can be used instead of any of the more specific level icons (for example, ‘>’ for Goal or Budget).

Type [Level *337]: Scalar Concept.

Level of Perception *590 July 16, 2002

The ‘Level of Perception’ is the organizational or process level which a specification is at or related to.

For example, the architectural level is downstream of system level requirements level but is upstream of specialist engineering levels.

The level of perception may be specified in a qualifier: For example:

Goal [Architecture Level] 90%, [Test Level] 96%

Rationale: if the level of perception is undefined, misunderstood or unknown then many systems engineering concepts become undefined, such as what is a requirement and what is a design idea. Such things are relative to the levels of perception.

Life Cycle Concept *600 March 13, 2003 C

The life cycle is the entire duration of existence of a defined system – from inception to retirement or disposal, independently of the specific methods used for development and maintenance.

Note: a system life cycle is not to be confused with a development process. The life cycle concept applies irrespective of choice of development process. If an Evolutionary development process was chosen the slope of the curse might be different and the production/construction phases would be recurrent and would happen earlier.

Type [Life Cycle *600]: Process Cycle.

Limit Concept *606 May 3, 2003

A limit is a numeric level at a border, that is, at an edge of a scalar range (a success range, an acceptable range, a failure range or a catastrophe range). It is specifically used at the edges of ranges associated with constraints: fail limit and survival limit/ catastrophe limit.

Related Concepts [Limit *606]:

  • Range *552
  • Fail *098: Fail Limit
  • Survival *440: Survival Limit
  • Catastrophe *602: Catastrophe Limit

Type [Limit *606]: Scalar Concept.

Local Concept *376 January 11, 2003

‘Local’ is an adjective used to specify that something applies only to a restricted subset of a defined scope.

Example:

Risk: The budgeted human resources are not really available.

Note: This happened on the last 3 projects in this division. <-TG.

In this case the ‘Note’ is local to the above ‘Risk’ specification. This is because it is immediately below, preferably indented, and contains no other indication, such as a qualifier, which could indicate otherwise (Contrast to: “Note [All Software Projects] this happened ….<-TG.”

Example:

TF:

Type: Design.

Description [Telephone.Keypad]: Tactile Feedback.

Rationale: All Competitors have it.

The design idea TF is local to the component, Telephone.Keypad.

Table G.?: Four adjectives concerned with scope classification.

For example: Within a requirement, a term may be defined locally by declaring a tag and stating a definition. It can then be used and reused (by referencing its tag) several times locally. The tag is not intended for reuse outside the scope of that requirement.

Related Concepts [Local *376]:

Type: Adjective, Scope.

Locus *524 March 28, 2003

A ‘locus’ is the integration of all factors/elements that define a scalar level. A locus consists of:

  • a specified scalar level
  • a specified unit of measure
  • a units of measure context.

The objective of all additional information is to improve the clarity and reality of the specification for purposes of getting control over it, and for contracting purposes.

The units of measure ‘context’ can be rich in any useful dimensions and any useful information about the scalar level.

The units of measure context primarily contains:

  • place: geographic location
  • space: any other spatial notions, ‘where’
  • event: any other conditions, particularly events or conditions

The units of measure context secondarily contains:

  • sources: where does the specification come from
  • authority: what power is behind the specification
  • priority: any information helping establish the priority of the specification
  • any other information useful or necessary for understanding the specification

Ill. *524 The scalar locus: all elements of information related to the level of specification are tied together in one related set. Any useful number of dimensions can be applied to the level.

The units of measure ‘context’ can arbitrarily be specified in the following ways:

  • in the Scale specification itself; explicitly and as a Scale Qualifier.
  • in a benchmark, target or constraint specification; explicitly and as a Scale Variable.
  • as separate parameter statements attached to the level specification.

In summary, a simple specification of a number and a unit of measure is normally insufficient to clearly, completely and safely define a scalar level. A number of additional parameters need to be attached to the level, to bring out the exact meaning of the level. This set of attributes is the scalar locus.

Example:

Usability:

Scale: minutes for a defined [Staff] to master a defined [Task].

Goal [Staff =Doctor, Task = Circulation Analysis, Deadline = First Trial release, Market = USA] 60 minutes.

Authority: Regional Hospital Contract paragraph 6.3.2

Example *524: the specified level of 60 minutes needs all the other elements of specification to build the complete set of understanding. This set is the locus of that specification.

Synonym [Locus *524]:

Related Concepts [Locus *524]:

Type [Locus *524]: Metrics Concept

Logging Concept *089 November 20, 2002

‘Logging’ is the writing of notes (logs) according to defined standards with the intention of their later use.

Notes:

1. Within SQC, logging occurs at two points: during specification meetings (when reported issues, process improvement suggestions, and questions of intent are logged), and during process meetings (when suggested process defect causes, and corresponding process improvement suggestions, are logged).

2. Informal voluntary note taking is not logging.

Type: Activity.

Domains: SQC, Systems Engineering.

Logical Page Concept *103 January 8, 2003

A logical page is defined as a defined number of non-background words.

Default Logical page volume: If no other definition is given, use ‘300 non-background words’ per logical page as default.

Rationale: This measure of specification ‘volume’ is used to make sure that varying physical page sizes and physical page content does not cause false specification volume measures. Volume measures are important for establishing checking rates (logical pages per hour) and defect density (majors per logical page).

Note:

1. ‘Non-background is a useful concept because it only pays off to worry about optimum checking rates or defect densities on non- background specification (where potential danger lies in defects).

Abbreviation: LP.

Synonym: Page [in an SQC context].

Related Concepts:

  • Physical Page:

This is one side, facing a reader, of space for textual and/or graphical symbols, of physical or electronic nature. It has clearly defined borders, traditionally rectangular, with any arbitrary quantity of symbols. This is not a Planguage defined term.

Type: metric definition.

Domain: SQC.

Logicware: Concept *575 July 12, 2002

Any information which is intended to control the logical action of a computer.

This includes the obvious; computer programs, any data that in fact controls the computer logic, user parameters which control computer logic.

Related Concepts [Logicware, *575]

  • Dataware, *576 dataware does not necessarily get used to control computer logic.
  • Planware, *577 Planware is plans for humans, not computers.
  • Infoware, *578 Infoware is information of any kind, a small subset of which might be Logicware.
  • Documentation, *579 documentation is primarily for human not computer consumption

Logistics: Concept *242 . . August 2, 2001

The procurement, distribution, maintenance, and replacement of materiel and personnel.

<-American Heritage Dictionary.

Logistics: *242.Logistics.

The procurement, distribution, maintenance, and replacement of materiel and personnel.

<-American Heritage Dictionary.

Lower Level: Concept *090 . August 2, 2001

Something lower in a hierarchy than high-levels.

Related Concepts:

  • High-level ( *082) a position in a hierarchy of defined system elements, which is ‘high’ relative to a defined set of those elements.

Type: Relationship specification.

Domain: System.sub-system.level

Major Defect Concept *091 November 20, 2002

A Major defect is a specification defect (a rule violation), which if not fixed at an early stage of specification, then it’s consequences will possibly grow substantially, in cost-to-fix and/or damage potential. A Major defect has on average approximately an order of magnitude more downstream cost potential than it’s cost to remove immediately.

Rationale: This concept and classification is necessary to help SQC checkers and other QC people to focus on what defects it pays off to find and eliminate in a specification. Without this classification, up to 90% of QC effort might be wasted dealing with minor defects.

Abbreviations: M (Intentionally written with a capital M), Major.

Related Concepts:

Type:

Domain: SQC.

Malfunction Concept *275 January 13, 2003

A system has a ‘malfunction’ when it does something not intended, or not desired, according to its design/construction specification, or according to reasonable stakeholder expectations (even though there may be no official specification about that expectation). Malfunctions are undesired outputs (including no outputs) from a ‘real’ system.

Error/Slip (Specification Issue) Specification Defect Fault/Bug/System Defect Malfunction

Notes:

1. Severity: a malfunction can have any level of severity or impact from catastrophically permanent destruction, to hardly noticeable variability of information or timing. It all depends on the nature of the specification, which is violated. Consequently, to really understand a malfunction, a notion of severity of impact needs to be added. This impact all depends on the environment impacted at the time of malfunction.

2. Human system stakeholders, users or operators may commit errors in connection with real systems (as opposed to specifications of those systems), which lead to system malfunction.

Classes [Malfunction]:

  • System Malfunction: entire system malfunctions.
  • Component Malfunction: a component of a system malfunctions.

Related Concepts [Malfunction *275]:

Type [Malfunction *275]: Risk Analysis

Master Definition Concept *303 May 9, 2003

The master definition of a specification, or specification element is the primary and authoritative source of information about its meaning. The master definition overrides any other (informal, not master) definition that is in conflict with it.

Notes:

1. This glossary contains master definitions, but the definitions themselves may contain explanations of other terms (for example, in the Related Concepts sections), which are less formal, and less authoritative than the master definition for that concept.

2. A master definition should contain full information about the source, authority, version and status, where relevant.

3. It is good practice to only permit a single master definition for a term to exist, and all references concerning the master definition must point to that single definition.

Example:

Master Definition: The primary correct source of a term’s meaning.

Type: Master Definition.

Type [Master Definition *303]: Parameter, Specification Concept.

Master Term : Concept *159 . August 2, 2001

The primary, or only, reference tag to a master definition ( *303).

Materials: Concept *326 . August 2, 2001

‘Materials’ are non-information process-inputs and process-outputs.

Maximum. Concept *537 . March 30 2002

A Maximum specification

is a constraint citing the highest allowable numeric level of a scalar variable in the operational variations of a system.

Usage: the specification is used to define operational characteristics of a system after handover to stakeholders. It can be used to define one type of testing of a system. It may be accompanied by specifications of why (Justification, Source, Authority, Risk for example) and also some specification of the action the system is expected to take if it does fall below that level (Action).

Justification: we could have used another concept for example ‘Fail’ . But this concept makes a distinction between delivered levels (fail) and operational variations and process control of the operational variations of a system. A system could be delivered well above the Fail (or Survival) level but in operation exceed the Fail limit due to circumstances unknown or uncontrolled at the time of system testing and handover. This concept can be used in contracts to distinguish between handover levels and operational levels of performance or cost.

Type: Operational Constraint

Related Concepts:

  • Fail limit *098 specifies failure levels of a system
  • Survival Limit *440 specifies the extreme limit at which a system can survive
  • Minimum *536
  • Catastrophe Limit *602

Parameter: Maximum, Max (abbreviation)

Synonyms: Maximum Operational Level

Keyed Icon [Maximum, *537] ^ (in context scale) example ----^---->

(the same symbol in another context indicates action ^[Process].

Means (Parameter) Concept *044 . August 2, 2001

A parameter placed between a tag and a definition, equivalent to {a colon, Defined, Defined As} for readability.

Bananas: Means: A fruit with a yellow peel , oblong, white colored fruit inside.

Synonym:s

Defined ( *044)

Defined As ( *044)

Colon delimiter. Usually has same effect between a tag and a specification.

Type: Parameter.

Means (Concept): Concept *047 . August 2, 2001

The devices by which Ends are reached.

A Design.

Synonyms:

  • Design Idea ( *047), see ‘Idea’ ( *086).
  • Design (noun) ( *047) A design is a ‘specified, consciously selected, means’ to reach defined ‘ends’.
  • Solution ( *047)
  • Strategy. ( *047)

Process Improvement Suggestion ( *088)

  • Architecture (noun) ( *192). The highest level of design.

Means Objectives ( *215): Objectives , which if attained, serve to help us reach Strategic Objectives.

Related Concepts:

Ends: {Goals Objectives, Aims, Targets, Values}: The purpose of using the ‘means’.

Type: stakeholder value, goal specification concept

Domain: problem solving. Including engineering, architecture, strategic planning.

Rationale: very general and short word which captures the notion in a general way, without necessitating a more-detailed term (like architecture or design). Well understood word by most people.

Keyed Icon [Means, *047]: [] [Means-Tag]

(keyed icon , square brackets symbolizing the rectangle, contains Means tag, underlined).

Note 1. Means can include any means whatsoever, which arguably contribute to reaching defined end state objectives. In particular they can include 'Means Objectives' ( *215), not just Strategies, Design Ideas).

“Perfection of means,

And

Confusion of ends,

Seems to characterize our age”

Albert Einstein

Http://albert.bu.edu

Means Objective: Concept *215 August 2, 2001/April 1, 2003 (added moe mop)

Means objectives are a ‘strategy’, in the format of a performance objective, to meet strategic objectives. They exist only to support meeting strategic objectives.

Note 1. As viewed from the point of view of a defined stakeholder, means objectives are intended merely as a way to reach the higher-priority strategic objectives of that stakeholder.

Note 2. Means Objectives are always relative to a defined level of engineering or management. Your means objectives can become your subordinate’s strategic objectives.

Note 3. The classification ‘means objectives’ is a temporary point of view, not a permanent classification for all points of view.

Rationale: The usefulness of the means objectives concept is to help us keep sight of the objectives we are responsible for (our strategic objectives). Means objectives are secondary, and must not stand in the way of meeting our strategic objectives. So, by classifying something as ‘means objectives’ we recognize that these objectives are not fixed or ‘holy’. They can and should be changed or replaced, as soon as we believe that it would better serve the interests of meeting the strategic objectives. The means objectives are also recognized as being of an equal status and priority to any other strategy specifications, which also are serving the purpose of helping us to reach our strategic objectives.

Related Concepts.

  • Strategic Objectives *214 : the objectives we are responsible for. The ones we hope to serve by reaching the means objectives targets.
  • Strategies: a means objective is a strategy. It is different from other strategies in that it is formulated in terms of performance targets. To reach these performance targets we will need specific strategies.
  • Measure of Effectiveness *486
  • Measure of Performance *482

“With a means objective, the answer to the question ‘Why is it important?’ is always an end that follows from that means.” <- [KEENEY92, page 78]

Keyed Icon [Means Objective, *215]: ->.@ (Impacting.Objective).

Any requirements or objectives icons can be used to represent a means objective.

Synonym: Means Requirement.

Type: Requirements hierarchy class.

Domain: Requirements.Solutions.Means Objectives

The term ‘means objective’ was coined by Keeney [KEENEY92].

Means Constraints: Concept *428 August 2, 2001

Means Constraints are constraints imposed at levels ‘below’ and supporting us. This means that we can therefore overrule means constraints, if we need to in order to better satisfy our strategic requirements.

Note 1. Means Constraints are at the same level (‘below’ us) as are Means Objectives (which are Performance requirements).

Related Concepts:

  • Fundamental Constraints, are above us and outside of our control, givens.
  • Strategic Constraints: are self imposed in our planning process, and can be changed by us.

These are different levels and viewpoints of the same class (constraint) of ideas.

Type: requirement .

Domain: Requirements.Constraints.Means.

Rationale: if we know about these constraints, and classify them as means constraints, then we are aware of their priority as being lower. We can make tradeoff decisions with this knowledge.

Example:

Effort [Tele]:

Scale: Engineering Hours.

Limit [ Department Tele, 1st whole Year of Project] 10,000 Eng. Hours <- Tele dept. Engineering Budget.

Type: Means Constraint [Project XYZ].

Authority: Tele Department Director.

Note that the resource constraint is identified as a means constraint in relation to a specific project.

Means Constraints are at a systems level below or before our own primary area.

Measure (noun) Concept *132 . January 29, 2006

Synonym for the parameter Scale..

Measure, To Concept *386 May 9, 2003

To measure is to determine the numeric level of a scalar attribute under specified conditions, using a defined process, by means of examining a real system.

Notes:

1. Measurement is done on the defined Scale, with respect to specified qualifier conditions.

2. Measuring is done using defined Meters.

Example:

Usability:

Scale: Mean Time To Learn.

Meter [Experts]: Use the upper 5% of our experienced staff in tests.

Meter [Novices]: Use 10% of current year’s intake of new people.

Fail [Experts, Complex Task]: 15 minutes.

Goal [Novices, Simple Tasks]: 10 minutes.

Two different Meter specifications are made in order to make it clear how the two different targets shall be measured.

3. Measuring is distinct from quantification and estimation. Quantification is merely defining an attribute with the help of a scale of measure, and benchmarks and/or target values. Estimation is trying to determine future results based on past data.

Related Concepts [Measure, To *386]:

Type [Measure, To *386]: Verb.

Measure of Effectiveness Concept *486 September 11, 2001

A measure of effectiveness is the quantified impact of a defined measure of performance ( *482, MoP) on a defined system under defined environmental conditions.

Abbreviation: MoE, MOE.

Example: if the Ease of Learning Task X impacts Cost of Training, then the Cost of Training is a measure of effectiveness of the Ease of Learning attribute. The Ease of Learning itself is a measure of performance ( *482).

Related Concepts:

  • Means Objectives *215 Means objectives are MoPs which impact Strategic Objectives (MoEs in relation to means objectives).
  • Strategic Objective *214. Strategic Objectives are the measures of performance we seek by reaching the target levels of a means objective (a Measure of performance in relation to the strategic objective).

Type [Measure of Effectiveness *486]: Metric concept

Measure of Performance. Concept *482 September 11, 2001

A Measure of Performance is a quantitative expression of performance or effectiveness attributes of a system.

The measure of performance expresses the isolated measurable performance of a system, without respect to its knock on effects (measures of effectiveness *486) in other systems.

Synonym:

Related Concepts:

  • Performance *434
  • Scale (Measure) *132
  • Effectiveness. *053
  • Measure of Effectiveness (MOE) *486: the MOE is the resulting effect in another system, and defined environment of an impacting measure of performance.

Abbreviation: MOP, MoP

See SPROELS02

Type [Measure of Performance *482]: Metric concept

Mechanism: Concept *527 Feb 24 2002

A system of mutually adapted parts working together as ... a means by which a particular effect is produced. <-OED

A mechanism is HOW the system does a function ("means").

Providing the service is WHY a system does a function

* The function is WHAT the function does

* A mechanism is HOW the system does a function ("means")

* A process is (part of) HOW the mechanism does a function ("activity"). <- Don Mills, NZ, 2002

Mega-step: Concept *345 . August 2, 2001

An evolutionary ‘step’, or step plan, which includes two or more delivery steps.

Note 1.This includes mega-steps that include other mega-steps, which ultimately contain, or are intended to contain, delivery steps.

Synonym: Complex Step.

Type: Project unit-of-work concept.

Domain: CE.Evo.Step.Mega.

Related Concept:

  • Elementary Steps. Evo steps which are not decomposed into other steps.

Meter -|?|- Concept *093 May 5, 2004

A Meter parameter is used to identify, or specify, the definition of a practical measuring device, process, or test that has been selected for use in measuring a numeric value (level) on a defined Scale.

“… there is nothing more important for the transaction of business than use of operational definitions.”

W. Edwards Deming, “Out of the Crisis” [DEMING86]

Example:

Satisfaction:

Scale: Percentage of <satisfied> Customers.

Meter [New Product, After Launch]: On-site survey after 30 days use for all Customers.

Past [This Year, USA]: 30%.

Meter [Past]: Sample of 306 out of 1,000+ Customers.

Record [Last Year, Euro]: 44%.

Meter [Record]: 100% of Customers.

Goal [After Launch]: 99% <- Marketing Director.

In the above example, the first Meter specification is the one that will be assumed, in default of any other specification, particularly for use in validating the achievement of Goal targets. Both the benchmarks (Past, Record) have local Meter specifications, which tell us more exactly the measuring process used to gather their data. Of course this implies that these benchmark and target numbers are not as comparable as we would like them to be. But that is the way it often is, and our local Meter specifications at least allows us to judge whether this difference is significant for our current purposes.

Notes: on the relationship between Meter specifications and Scale specifications:

Notes1: All Meters are based on whatever their corresponding Scale says.2. The Scale decides ‘what’ we are measuring. The Meter decides ‘how’ we will measure on that scale.3. The purpose of a Scale is to give meaning to numbers on that scale. To decide what is good and bad.4. The purpose of a Meter is to give us feedback about activity (variation) on that scale for a real system.We need to include the notion of Scale Qualifiers, and Target Qualifiers – in order to compare with Meter parameters and conditions.

Example:Call Help Speed:Scale: average time needed for defined [User Types] to successfully complete defined [Tasks] under defined [Conditions].

Meter [User Type=Novice, Task = Help Caller, Conditions = Lingual Challenge]  at least 20 representative call situations with at least 3 extremes of Novice, Lingual Challenge, and Tasks

Goal [User Type=Novice, Task = Help Caller, Conditions = Lingual Challenge]  10 minutes.Lingual Challenge: defined as: the caller has substantial problems explaining or articulating the problem and situation, due to any cause, such as non-native linguist, non domain expert, noise or disturbances.

From this example we can see that:

Conclusion:1. If you are trying to get control of some aspect of a system then all information about that aspect needs to be put into the Scale (or at least in the ‘Scale + Target [Qualifier] ‘combination, to be more precise.2. In particular, if you want control over a real system, you should not rely on the test/Meter specifications themselves to give that control. The designer and architect are not looking at the Meter specifications. They are looking at the Scale +Target information.SO GUIDELINES, PRINCIPLES

Keyed Icon [Meter *093]: -|?|-

“The explanation of the icon is that it is a ‘?’ on top of a Scale icon, -|-|-.”

Synonyms[Meter *093]: Measurement Process ( useful for beginners in the method)., Test Process (useful for technical people). Accounting Process (useful for financial people like CFOs).

Type: parameter, metrics concept.

Meter (noun): Concept *094 . August 2, 2001

A meter is anything defined with the Meter parameter.

Method Concept *547 May 3, 2003

A method is a body of systematic techniques used by a specific discipline.

Related Concepts [Method *547]:

  • Process *113
  • Planguage *030: Planguage is a specification language and a set of methods.

Type [Method *547]: Tool.

Metric Concept *095 May 4, 2003

A metric is any kind of numerically expressed system attribute.

A metric is defined in terms of a specified scale of measure, and usually one or more numeric points on that scale. The numeric points can be expressed with defined terms that can be translated into numbers. For example, ‘Record +10%’.

Normally there will also be other parameters and qualifiers, which add background detail to the metric. For example, Meter and Assumption.

A metric specification encompasses all related elements of specification, not just the Scale of the numeric attribute.

A complex specification, with a set of scales of measure, is also a metric expression. There is no implication that it is elementary (has only a single Scale).

Notes:

1. Metrics are used to express ‘concepts of variability’ clearly – in particular more clearly than mere words [GILB76].

Examples (Metric Expressions):

Scale: Mean Time Between Failures.

Use: Scale: Time to Learn defined [Average Task]. Past: 30 minutes.

Design A: Impacts Requirement B: 30%.

Each of these 3 statements is based on a ‘metrics culture.’

Examples (Non-Metric Expressions):

Reliability

“Easy to learn”.

“Very effective design”.

Each of these 3 expressions is based on a ‘non-metrics culture.’ Nice words – no numbers expressed, defined or implied.

2. The rationale for using metrics includes:

  • to increase clarity and unambiguousness of specifications
  • to increase sensitivity to small changes in specifications and the system itself
  • to enable systems engineering logical thinking about relationships – for example the relation of designs to requirements
  • to provide a better basis for legal contracting about systems
  • to enable evolutionary tracking of progress towards goals
  • to enable a process of learning within projects and engineering and management domains
  • to force engineers to think more clearly and communicate more clearly with others

3. A metric can be used to express the numeric impact of a design on a performance requirement (for example, when using the Impact Estimation method).

Related Concepts [Metric *095]:

Keyed Icon [Metric *095]: -|-|-> “Scale with units” or ---> “Scalar Arrow, a simplified keyed icon without explicit units”.

Several other defined keyed icons can also be used to express a metric (For example, Fail and Goal: O-----!---->---->).

Type [Metric *095]: Numeric Value.

Milestone: Concept *372 . August 2, 2001

A milestone is any defined measure of project progress.

In Evolutionary Project Management the Evo steps successful completion are the normal milestone concept. But any set of Evo steps (Mega-steps) can be used to define interesting milestones. See example below.

Type: Planguage Parameter.

Domain: Project Management.Process Control. Metrics. Milestone.

Keyed Icon: ----|----- (1st draft, not determined) or ^[Process]->Exit

First Release: Milestone :

{Steps: {Internet Option, Card Privacy },

Committee Approved [USA, Europe],

Product Orderable On Website}.

Example of defining a Milestone as a set of conditions.

Case [Microsoft]Microsoft used a large incremental step of about 25% to 33% of a project, and of 6-10 weeks duration as what they called a milestone. The milestone step contains everything necessary of components and quality to, in theory, deliver to customers. Early milestones contain the most critical components[Cusumano95]. We consider the Microsoft milestones to a type of evolutionary mega-step.

Minimum: Concept *536 . March 30 2002

A Minimum is a constraint specification citing the lowest allowable level of a scalar variable in the operational variations of a system.

Usage: the specification is used to define operational characteristics of a system after handover to stakeholders. It can be used to define one type of testing of a system. It may be accompanied by specifications of why (Justification, Source, Authority, Risk for example) and also some specification of the action the system is expected to take if it does fall below that level (Action).

Type: Operational Constraint

Related Concepts:

Parameter: Minimum, Min (abbreviation)

Synonyms: Minimum Operational Level

Keyed Icon [Minimum, *536] _ Underline example ----_---->

Justification: we could have used another concept for example ‘Fail’ . But this concept makes a distinction between delivered levels (fail) and operational variations and process control of the operational variations of a system. A system could be delivered well below the Fail ( or Catastrophe) level but in operation exceed the constraint levels due to circumstances unknown or uncontrolled at the time of system testing and handover. This concept can be used in contracts to distinguish between handover levels and operational levels of performance or cost.

Minor Defect Concept *096 November 20, 2002

A minor defect is a non-major defect. It has no major downstream cost potential.

Notes:

1. A defect which, if not removed at a given time, can be removed later (for example, in test phases or in customer use) at approximately the same cost or penalty.

2. There is little value in dealing with it immediately after it occurs. It can be left to chance, or ignored until it surfaces of its own accord.

3. Minor does not refer to the size of the defect, but to the potential consequences of it downstream.

Abbreviation: m, minor

Related Concept: Major Defect ( *091).

Type:

Domain: SQC.

Mission Concept *097 March 19, 2003

A mission specifies who we are (or what we do) in relation to the rest of the world. It is the highest level of function of a system. The mission should not contain ‘vision’ description (‘We make the best planes in the world’). It is an undramatic statement of the main function of a business or organization.

Mission, like function, intentionally excludes specific levels of attributes in its description.

Examples:

Mission: We make semiconductors.

Mission: We provide business solutions in manufacturing software.

Related Concepts [Mission *097]:

Type [Mission *097]: Function Requirement.

Model. Concept *448 August 2, 2001

A model is an artificial representation of an idea or a product. The representation can be in any useful format including specifications, drawings and physical representations.

Rationale: to convey information about an idea without having to deal with a full scale and real version of it.

Related Concept: Template , *254

  • templates purpose is to give us ideas about possible patterns or ideas.
  • model purpose is to convey information about one or more aspects of a system or product.

Type: engineering concept.

Mode. Concept *485 . September 5, 2001 tg 1653

A mode is a defined type of operation of a system.

Related Concepts:

  • State: *024. A mode (of operation) can be described by may variable, possible, and impossible states.

Synonym:

Type: system analysis viewpoint

Motivating (adjective) Concept *443 July 18, 2002

A ‘motivating’ systems component, is one which causes people to act.

Definition [Formally] motivating defined [Systems Component] is a cause of defined [Stakeholders] for doing defined [Actions].

Usage 1. Motivating Needs: the stakeholder needs which cause them to fund or otherwise support a project or any effort to achieve those needs.

Rationale: if a systems engineer can correctly identify the motivating components, they can derive relevant requirements and designs; and as a result get better funding and support for their efforts.

Type: system component attribute

“By not aligning measurements and rewards, you often get what you’re not looking for.” Jack Welch, p 387 [Welch01].

Must Avoid (Parameter): *098 . August 19, 2002

See Fail (-ure) Limit *098 preferred use.

Must Avoid is a parameter, an abbreviation for the concept ‘Fail limit’ ( *098). It is being kept in the glossary as a synonym for what we would now recommend and prefer as a parameter for the concept: ‘Fail limit’, and the parameter ‘Fail’..

Must Avoid is defined as a level that Must be avoided if possible because there is some type and degree of failure at that level and at numerically worse levels.

Keyed Icon [ *098, Must Avoid] ‘>>’. (Explanation: double Goal level)

Synonym: Fail Level ( *098), Failure level ( *098), Must Avoid Level ( *098).

Parameter Abbreviation: Must (not recommended because of ambiguity and lack of precision).

Type: Scalar Constraint.

Rationale:

  • to keep compatibility with the long term use of Must in Planguage. (in spite of a shift to preferred term Failure Level.
  • to define a point at the beginning of a range of an attribute scale which must be avoided.

Note: the main reason we are keeping Must here is that we have used the concept since 1988. Some literature and some businesses have invested in teaching it, so we want to allow them to avoid optimization to a new term. It replaced ‘Worst’ : ‘Worst Acceptable Case’ before that). We do believe that the Failure Level concept is a more direct description of the concept, and that the Fail icon ‘!’

(----!-->---> for example) is a better icon than >> for a warning limit like Must Avoid, or Failure Point.. Certainly it is a general principle of Planguage that people can choose any term they like, to describe a concept.

Parameter: Must Avoid

Related Concepts:

  • Fail limit *098 synonym
  • Must Do *539 the level just slightly better than the Must Avoid level.

Must Do. Concept *539 May 29, 2003

Synonym of ‘Tolerable’ *539

Need Concept *599 March 17, 2003

A ‘need’ is something desired by a defined stakeholder. The implication is that satisfying that need would have some value for some stakeholder.

A need might not be agreed as a formal requirement, and it might not be prioritized such that it is actually acted upon (designed and implemented).

It is a term often used as a stakeholder view of a problem before requirements specification is carried out.

Related Concepts [Need *599]:

Type [Need *599]: Problem Definition Concept.

Non-Commentary Concept *294 July 17, 2003

‘Non-commentary’ refers to written specification that is not commentary: it is either core specification or background specification. All major specification defects are found in non-commentary. But, not all specification defects in non-commentary specifications are major. By definition, major defects cannot be found in ‘commentary’.

Figure *294: The diagram shows the relationship amongst the different categories of specification.

Notes:

1. Text diagrams or symbols that are secondary to the main specification purpose, and which do not lead to ‘real product’ are ‘commentary’.

2. Non-commentary sections of a specification can be termed ‘meat’ and,

commentary sections can be termed ‘fat’ {notes (like footnotes), comments

(“like this”), remarks (Note), introduction, references (Source)}.

3. Checkers, in SQC, should concentrate on carrying out rigorous checking, at optimum checking rates, on the non-commentary territory. This gives better efficiency in finding defects.

4. It is important to formally distinguish between non-commentary and commentary. Authors/writers need to try to make the distinction visually for readers (for example, by using plain text for non-commentary and italics for commentary). When the visual distinction is made, and it is clear what is commentary and not; then quality control analysts can more easily, and more certainly, decide which defects are major and which are not. They can more quickly scan the commentary and more carefully study and cross reference check the core specification, and then somewhat faster, the background specification.

Related Concepts [Non-Commentary *294]:

Type [Non-Commentary *294]: Specification.

Note Concept *018 May 26, 2003 E

A ‘note’ is a comment or any text that makes any kind of remark related to any statement.

Ways of specifying notes include: italics, the use of “quotation marks”, and the Note parameter (which has a synonym of ‘Comment’).

Example:

Ambition: Main share of the market. “This is just an example of a comment using quotes in a background statement.”

Note: This is an example of the use of the Note parameter.

Notes:

1. Notes must be distinguished from the ‘significant’ core specification (for example, Goal and Scale) and from ‘background specification (for example, Source, Evidence and Gist). The main reason for this being that a defect in Note specification is usually only a minor defect. Any SQC checking should concentrate on the specification that is not Note specification (that is, non-commentary {core and then background}), as that is where the major specification defects will be found.

Example:

Goal [First Release]: 60% <- Marketing Director [June 6]. “Source is background, but good for credibility and SQC.”

Source: The Encyclopedia .

Synonyms [Note *018]

Related Concepts [Note *018]:

Keyed Icon [Note *018]:

“…” “Double quote marks around the note.”

Type [Note *018]: Parameter [Commentary].

Now (Level) ---(----- Concept *513 September 11, 2002

The ‘Now’ level is a scalar attribute level that is being tracked as a system evolves. It is a present moment report. It is a snapshot, or instant picture of the scalar level at a defined point in time, space and event condition. It is conceptually the same as a Past level. The difference is that we are indicating that the level of a real system is still probably at that level as far as we know.

Every time you check how well the product is doing during the development cycle you get a NOW level.

Related Concepts [Now *513]

Past: *106

Benchmark: *007

Goal Step, *620 ---)---

Type: scalar level, Benchmark

Keyed Icon (Now, *513) ----(----

Note consistent with other benchmarks pointing to past , left ways like < and <<

Synonym:

Usage:

  • “ the Now level of our product is 33 minutes.”
  • It is a way of reporting progress during system evolution
  • it is a way of announcing the present status of a system attribute level

Numeric Tag: Concept *110 . 10 January 2003

A term beginning with the ‘asterisk ‘*’ sign, and immediately followed by a number. The Numeric Tag is a human-language-neutral unique tag for each Planguage Glossary-defined term.

Rationale: This *Tag is intended to help identify Planguage concepts unambiguously regardless of local natural language, local business type terminology, company terminology, dialect, spelling, translations, changes in terminology, or any other reason for variation. It is applied to all glossary defined terms and to related symbols, icons and Planguage constructs.

Example: This concept is number 110, so its Numeric Tag is *110.

Synonym: Glossary Concept Numeric Tag

Object Concept *099 January 8, 2004

An object is any system component that can be described in terms of its attributes; functions, performance, and cost; as well as past, present or future attribute states.

An object can be real or conceptual. It is a term we use for systematic building blocks of larger systems – which themselves might be viewed as more-complex objects. Any object can be composed of sub-objects. It is a matter of taste, and relative scope whether we use the term object or system to describe something.

Notes:

1. The object concept is extremely general. ‘Object’ is a description of almost anything.

2. The main difference between our definition, and common use of the term in the software field, is that we explicitly include the notion that an object can be described in terms of its performance and cost attributes. That, central systems engineering idea, is usually totally overlooked in the software world.

3. There is an implication in the use of the term ‘object’ that it is intended to be reused in some way, for example, to be a component of more than one system.

4. ENTITY ->OBJECT ---> ARTIFACT (SEE HIERARCHY DICTIONARY)

Object is a tangible entity; artifactis a man-made object.

Synonyms [Object *099]:

An object is simply a ‘little system’ – a building block of larger systems. Object implies a potential component of a larger system. The only distinction between the synonyms is that object infers something relatively small, compared to a ‘system’.

Given these two terms are mainly used completely distinctly – two concepts have been allocated.

Related Concepts [Object *099]:

Keyed Icon [Object *099]: “Same icons as for System *145.”

[ ----->O----> ]

or

----->(<mission tag>)---->

Example:

---->( Update Address)---->

In this context the mission tag, ‘Update Address’ can serve as the reference name for the object, the performance and cost attributes of the object being implied by the arrows.

Type [Object *099]: Specification Concept.

Objective Concept *100 May 10, 2003

Objective is a synonym of Performance Requirement. See Performance Requirement *100.

Objectivity Concept *388 . August 3, 2001

Being independent of Subjective influences, being a reality outside individual minds. Being closer to some real truth, independent of observers person or culture.

Related Concepts:

  • See extensive discussion under ‘Subjectivity’.

Rationale:

Central point of this: there are degrees of both Objectivity and Subjectivity in all analysis, measurement and estimation processes. We should try to understand their elements, nature and degree. Then we need to hold up these factors in the light of our objectives, or in light of purposes of the analytical process.

Practical application: Planguage contains dozens of parameters and devices to help us communicate and understand the degree of objectivity or subjectivity of any specification.

Objective Function: Concept *619 September 7, 2002

“An objective function maps future sequences of states of the world to the value they have for specific stakeholders, in utility terms. Objective functions have various inputs from which to derive an overall utility value. The inputs can be called the dimensions of the objective function.

The assumed aim is to maximise the utility we get.

Applying our objective function (which could well be no more than a judgment) helps us identify particular sets of states that look highly desirable to us and which we may choose to take as goals. Goals (also known as objectives, targets, "a vision", and so on) are a mental device for creating and communicating plans.”

Source: Dynamic Management for an uncertain worldby Matthew Leitch, 23 July 2002, version 1.1, http://www.matthew- leitch.supanet.com/dynamic

Observability: Concept *176 . March 10, 2002

A component of the system state vector is controllable if there exists a control signal that can bring the system from the current state to a desired state. It is

observable if it is possible to compute or estimate the state from a

finitely long observation of the system output. <-Steve Poppe

Concepts from feedback control theory, controllability, and observability.

Note 1:

The generic term ‘observable’ is intended to cover any means of observing a system including testing, measuring, seeing, sensing, feeling, hearing etc.

Synonym: Observable

Off *626 February 16, 2003

Predefined State. Same as False.

Related To:

On *625 February 16, 2003

Predefined State. Same as True.

Related To:

Open-Ended Concept *101 February 26, 2003

‘Open-ended’ means that a system’s architecture: its interfaces and basic structure are of such nature that most system changes, no matter how unexpected, are relatively easy to handle without major effort.

The more open-ended, the easier the change will probably be.

Note: The degree of open-endedness can be measured by Adaptability metrics such as {Portability, Improvability, Extendability, Connectability}. (See also CE Section 5.6).

Type [Open-Ended *101]: Adjective [System Architecture].

Optimize Concept *417 . July 17, 2002

To optimize a design (‘design optimization’) is to reduce one or more resources, needed to achieve specified levels of performance, or stakeholder values. Or it is to improve the impact of designs in the direction of specified performance targets.

Note 1. The value-to-cost ratio is being increased when optimization, in the design or project evolution process, manages to identify designs, which reduce resources needed to achieve targeted system performance, or stakeholder values.

Note 2. Development process optimization would reduce the development resources {people, time, money} needed to meet product or system requirements.

Note 3. Product design optimization would reduce the resources needed to produce, operate and decommission (i.e. life cycle costs) the product or system, at defined levels of system-or-product values and qualities.

Type: Design process concept.

Operational (adjective). Concept *562 . July 2, 2002

‘Operational’ refers to a state of defined systems and defined states of operation.

Usage:

Operational Requirements

Operational Attributes

Operational Functions

The operational requirements refers to the set of requirements which affect the defined system in defined states of operation.

Related Concepts [Operational *562]

  • Adaptive *563 (adaptive attributes are things like portability, extendibility).

Optimum Checking Rate Concept *126 November 20, 2002

The average rate of checking a specification, which gives the highest productivity (effectiveness).

Note: The optimum checking rate is usually measured in terms of the ‘number of pages or lines per hour, which give the peak ability to identify major defects per page’, (peak effectiveness).

Figure ( *126): Graph showing how varying the checking rate affects the number of defects found [GILB93, Chapter 16].

[Note to Publisher: Bottom caption should say “Checking rate (pages/hour)”, <->delete this at publisher.]

Rationale: This measure is basic to making sure the SQC process is making effective use of people’s time. Without it, most organizations allow their staff to check too quickly, and find too few defects. They have the illusion of effectiveness but they lose out when the defects surface expensively downstream.

Related Concept:

  • Checking Rate ( *015): The rate checkers check a specification, whether optimum or not.

Type: Metric.

Domain: SQC.

Option: Concept *432 . Dec 17, 2001 (spell corr)

The option is a short form of ‘template option’. It defines optional parameters or qualifiers in a model or a template for Planguage.

Note 1. Other uses for the concept are conceivable but not defined yet.

Keyed Icon: parenthesis ( ) around the option.

Scale: <the units of measure>.

(Meter: <the test process description or summary.> )

The Meter statement is optional, the Scale statement is not.

Type: Planguage specification concept [Templates]

Or Concept *514 February 5, 2003

‘Or’ is a logical operator used in qualifiers, or other appropriate specifications, to indicate alternative conditions. If any one ‘Or’ condition is true, then the set of conditions is true.

Example:

Stretch [If Multinational Or Government]: 99%.

Stretch [If Multinational or Government]: 99%.

Stretch [If Multinational OR Government]: 99%.

Stretch [If Multinational | Government]: 99%.

To make a statement read better, the lead capital letter may be dropped, giving ‘or’. It can also be spelled all capitals, ‘OR,’ to emphasize that it is a Planguage logical operator and not a simple text word.

Note: parenthesis, ({Set parenthesis} and (ordinary mathematical parenthesis)), may be used to limit and clarify the extent of a logical expression.

Example:

Goal [ {Europe | USA} & {Trials | Prototypes} ] 60%.

Assumption: (Deployment | Decommissioning), (Profit | Break Even).

Keyed Icon [Or *514]: ‘|’ “As in A|B.”

Type [Or *514]: Logical Operator.

Or Better Concept *550 March 5, 2003

‘Or Better’ is an expression used within a scalar specification to explicitly emphasize that the specified level has a range of acceptable values, rather than being just a fixed, single value. In other words, ‘Or Better’ helps identify the specified level as the beginning of a desired range.

‘Or Better’ is actually implied by a scalar target specification, but it can be useful to be more explicit.

Examples:

Goal [Mechanical]: 60 degrees Or Better.

Planned Level [Electronics]: 60% -> +.

Wish: 60 -> +.

Stretch: 99.90% Or Better.

Survival [Offices]: 35 degrees C Or Better.

Related Concepts [Or Better *550]:

Keyed Icon [Or Better *550]: -> + (a range towards a positive experience number)

Type [Or Better *550]: Expression [Scalar Range].

Or Worse Concept *549 March 5, 2003

‘Or Worse’ is an expression used within a scale specification to explicitly emphasize that the specified level has a range of unacceptable values, rather than being just a fixed, single value. In other words, ‘Or Worse’ helps identify the beginning of a ‘no go’ range.

‘Or Worse’ is actually implied by a constraint specification, but it can be useful to be more explicit.

Examples:

Must Avoid [EU, Next Generation Product]: 50% Or Worse.

Fail [Banking Market]: 20% -> -.

Fail Level: 20 seconds -> -.

-!- [Households]: 20 degrees Centigrade -> -.

Fail, Fail Level and Must Avoid are synonyms *098

Related Concepts [Or Worse *549]:

Keyed Icon [Or Worse *549]: -> -

Type [Or Worse *549]: Expression [Scalar Range].

Output Concept *636 June 27, 2003

An output (or system output) is the result of a system.

Notes:

1. Output has two primary uses in Planguage: it is either used to describe a function output (a performance attribute), or to describe a process output (a resource asset).

2. For intellectual processes, process outputs are always data. For physical processes (such as factory production), this can be extended to include material outputs or products.

Synonyms [Output *636]:

Related Concepts [Output *636]:

Figure *179a: Outputs from a process are data and/or materials

Figure *179b: Function outputs, also known as performance attributes.

Keyed Icon [Output *636]: O or ^[<process name>] <output name>

“The icon is an arrow exiting a function oval, or an arrow exiting out of a process rectangle.”

Type [Output *636]: Performance Attribute or Resource Asset (Asset).

Owner Concept *102 February 5, 2003

A person or group responsible for an object, and for authorizing any change to it.

The parameter, Owner, can be used to explicitly identify ownership.

For example: a system owner, a specification owner, a standard owner, or a process owner.

Notes:

1. An owner is responsible for updating or changing an object, including maintaining its control information (for example, Status, Version, Quality Level, and Location).

2. An owner will ensure the object adheres to any relevant standards.

Related Concepts [Owner *102]:

Type [Owner *102]: Parameter, Role.

Parallel Development Concept *363 February 25, 2003

Any development of more than one Evo step, that takes place at the same time.

Notes:

“‘Partly simultaneous’ development of closely related product variants.

The purpose is to reduce the TBSP (Time Between Successive Products).”

[JANDOUREK96]

Type [Parallel Development *363]: Process.

Parallelity: Concept *104 . August 3, 2001

Having a number of parallel Evolutionary cycles.

These can be any type of Evo cycles frontroom or backroom (concurrent engineering).

Related Concept:

  • Parallel Development, *363

Domain: Project Management.Evo.Step Planning.Parallelity

Parameter Concept *105 March 4, 2003 B J

A parameter is a Planguage-defined term. Parameters are always written with at least a leading capital letter, to signal the existence of a formal definition.

Notes:

1. A parameter is defined as a part of Planguage.

Examples:

  • PastParameter [Scalar, Benchmark]
  • GoalParameter [Scalar, Target]
  • ScaleParameter [Scale of Measure]
  • DefinedParameter [Description]
  • RiskParameter [Risk Analysis]
  • ImpactsParameter [Relationship]
  • AuthorityParameter [Specification Control]
  • NoteParameter [Commentary]
  • VersionParameter [Specification Control]
  • FunctionParameter [Attribute]
  • Function RequirementParameter [Requirement]

2. The master definition of most of the Planguage parameters is found in this Glossary.

See also [GILBWWW (www.gilb.com)] for additional, updated and new parameters.

3. A project or specification author can declare and define tailored parameters (as part of a Project Language – a specific project specification language). These can then be reused anywhere in a specification where they are understood. They may in time be officially adopted by some local dialect of Planguage.

4. Parameters are not user-defined terms. User-defined terms are defined by a project or organization, to describe the target system, organization or project (They are not part of the definition of a specification language).

Synonyms [Parameter *105]:

  • Specification Language Parameter *105

Related Concepts [Parameter *105]:

Type [Parameter *105]: Specification Concept.

Parameter Specification. Concept *325 . August 3, 2001.

A parameter specification is either the ‘Parameter Definition’, or the ‘Parameter Value’. It generally comes after the parameter name, after any [qualifier], and before any source information.

In the examples:

Example Tag:

Scale: Up-time of [defined components] in [defined places] at [defined times].

Meter [Acceptance Test] Contract Condition 6.5 Contract with ABC Dec 24th.

Goal [Software, GB, 2001] 60% Board policy

The parameter specifications, in the example above, are in italics .

Related Concepts:

Parameter Definition. Concept *323 . August 3, 2001.

The parameter definition is a set of words defining the parameter. It is a parameter specification.

Related Concepts:

  • Parameter Specification *325
  • Parameter Value *324

Scale: Up-time of [defined components] in [defined places] at [defined times].

Meter[Acceptance Test] Contract Condition 6.5 Contract with ABC Dec 24th.

Goal [Software, GB,2001] 60% Board policy

The italicized expressions in the example above are parameter definitions.

Parameter Value. Concept *324 . August 3, 2001

The parameter value is a numeric value, which varies along a defined scale, and which specifies the meaning of a given parameter.

Related Concepts:

  • Parameter Specification *325
  • Parameter Definition *323

Scale: Up-time of [defined components] in [defined places] at [defined times].

Meter[Acceptance Test] Contract Condition 6.5 Contract with ABC Dec 24 th .

Goal [Software, GB, 2001 ] 60% Board policy

The ‘ 60 %’ term in the example above is a parameter value of the Goal parameter. All parameter values are also classified as ‘parameter specifications’.

Parent Concept *267 February 21, 2003

A parent is the immediate superior component to a kid.

Related Concepts [Parent *267]:

Type [Parent *267]: Role [Relationship].

Participant: Concept *238 . August 3, 2001.

A person or group who participates actively in a defined process.

Past Concept *106 March 5, 2003

A Past parameter is used to specify historical experience, a ‘benchmark’.

A Past specification states a historical numeric level, on a defined Scale, under specified conditions [time, place, event] for a scalar attribute.

Notes:

1. Past values are stated to give us some interesting benchmark levels for our old system(s) and our competitors’ systems.

2. Even ‘current’ values should be expressed using Past, because immediately they are stated, they are ‘past’ values. Qualifiers will make plain the currency of a specification.

Rationale: If we did not take the trouble to analyze and specify the past values then we might not set reasonable targets. Unintentionally, targets might even be specified worse than they were in the Past.

Synonyms [Past *106]:

Related Concepts [Past *106]:

Keyed Icon [Past *106]: <

“A single arrowhead, normally on a scalar arrow (<---- < ----O--- < ---->), pointing ‘back’ to the past.”

Note the ‘<’ alone in other contexts has other meanings such as: ‘<’ less than, ‘<-‘ (source arrow), ‘<--------‘ (tip of scalar arrow). So either it must be used in an unambiguous context or manner, or there be at least one hyphen, or [qualifier], on either side of the arrowhead to distinguish this icon.

Type [Past *106]: Parameter [Scalar], Benchmark.

Path Plan (Path): Concept *534 . March 30, 2002

A Path Plan is a series of two or more specified levels on a defined scale of measure from defined optional Benchmark levels and including any interesting series of defined constraint and Target levels. The path plan can be used to specify any interesting planned set of intermediary targets before a major target such as a Goal level is reached, and it can include that major target level.

Usage: it is particularly useful for describing our planned levels, and their benchmark/constraint context levels for a series of releases and for a set of evolutionary delivery steps.

Parameter: Path Plan or (abbreviation parameter) Path

Type: Target specifications.

Keyed Icon [Path Plan, *534] <–v->

Example:

Path Plan [New Product, EU Market] {Past [Our Old Product, 2002] 60%, [Step = 1] 62%, [Step = 20] 70%, [Step= 40] 80%, Survival: 50%, Fail [UK, Schools] 70%, Goal [1st EU Wide Release] 85%, Goal [1 Year After 1st EU Wide Release] 95%, Stretch: 97%, Wish [Nordic Business] 99%}.

Path [Next Generation] {Past [New Product] 95%?, Goal [EU] 99%+}. <- Long Term Strategy

Type: scalar requirement specification

Related Concepts (Path Plan *534)

PDSA Cycle: Concept *168 .

See Plan Do Study Act

Percentage Impact Concept *306 January 20, 2003

A percentage impact is an incremental scale impact expressed as a percentage of the required improvement (The required improvement being the scalar distance between a chosen benchmark (0%) and a chosen target (100%)).

A percentage impact is part of an impact estimate and is used in Impact Estimation tables.

Synonyms [Percentage Impact *306]:

  • Incremental Percentage Impact *306
  • Percentage Incremental Impact *306
  • %Impact *306

Keyed Icon [Percentage Impact *306]: %.

Related Concepts [Percentage Impact *306]:

Type [Percentage Impact *306]: Scalar Metric.

Percentage Uncertainty Concept *383 November 18, 2002

Percentage uncertainty is calculated from the scale uncertainty, baseline and target data; and stated together with the percentage impact value.

Percentage Uncertainty can be used to identify risks in using specific design ideas: the numeric ‘best case’ and ‘worst case’ deviations from the Percentage Impact estimate provides important pointers towards the level of risk involved. This can lead to one or more direct actions, if the risk level is judged too high. For example (actions):

  • to specify a design better
  • to change the design itself
  • to get more information about the design impacts
  • to write contract conditions controlling the impact expected
  • to schedule this design for early evolutionary step delivery (so we can see what it really does).

Example:

If Percentage Impact = 30% and Percentage Uncertainty = ±40%, the overall impact in percentage terms is usually stated as 30%±40%. In other words, Percentage Impact is assessed to vary in practice anywhere between –10% and 70%.

Dual System -> Reliability: 30±40% <- Company Experience ranges from –10% to 70%

Keyed Icon: %.±? “Percentage & Uncertainty”

Type: Impact Estimation calculation

Domain: Impact Estimation.

Performance Concept *434 June 5, 2003

System performance is an attribute set that describes measurably ‘how good’ the system is at delivering effectiveness to its stakeholders.

Each individual performance attribute level has a different ‘effectiveness,’ for different stakeholders, and consequently different value or utility.

Performance attributes are scalar and are of three types:

  • Quality: ‘how well’
  • Workload Capacity: ‘how much’
  • Resource Saving: ‘how much saved’

Ill. [Performance]: performance characteristics can be classified into three major types. This is an arbitrary but useful distinction. Others are for example in the quote below.

Performance. A quantitative measure characterizing a physical or functional attribute relating to the execution of a mission or function. Performance attributes include quantity (how many or how much), quality (how well), coverage (how much area, how far), timeliness (how responsive, how frequent), and readiness (availability, mission readiness). Performance is an attribute for all system people, products, and processes including those for development, production, verification, deployment, operations, support, training, and disposal. Thus, supportability parameters, manufacturing process variability, reliability, and so forth, are all performance measures.

Source USA Mil-Std 499B 1994

Notes:

1. The system engineer or system stakeholder can select, define, invent, tailor or develop any number of useful or interesting performance measures, to serve the purposes of their current task, or systems engineering process.

2. Performance is intended to cover absolutely all performance measures. It is not limited to the narrower conventional set of performance measures (for example, throughput speed), but explicitly includes the qualitative measures of performance; which are so weakly represented and too rarely quantified in conventional thinking.

3. Performance is the most general sense of ‘how well’ a function is done. Performance includes

  • ‘quality’ characteristics (such as availability, usability, integrity, adaptability, and portability), and
  • ‘work-capacity’ characteristics (such as storage capacity, maximum number of registered users, and transaction execution speed), and
  • resource saving characteristics (such as cost reduction, and reduced elapse times).

Related Concepts [Performance *434]:

Keyed Icon [Performance *434]: O---> or O+

Note:

Keyed Icon [Resource *199]: --->O or -O

Keyed Icon [System *145 [Not Design]]: {Resource, Function, Performance,

Condition}:

[ --->O---> ] or [ –O+ ]

Type [Performance *434]: Attribute [Scalar].

Performance Constraint Concept *438 February 27, 2003

A performance constraint specifies some upper and lower limits for an elementary scalar performance attribute.

These limits are either levels at which failure of some kind will be experienced, or levels at which the survival of the entire system is threatened.

Fail and Survival parameters are sufficient to specify performance constraints.

Notes:

1. Stakeholders impose constraints. These stakeholders and their motivation should be explicitly documented together with the constraint specification (by for example using Authority, Source, Rationale, or Stakeholder parameters).

Example:

Speed :

Scale: Time in seconds <to react>.

Survival [ Public Places ]: 10 seconds maximum.

Authority: Public Safety Law .

Fail [ All Uses of our Product ]: 5 seconds.

Authority: Our Quality Director . Rationale: time to react to alarm light.

Goal [ Public Places ]: 4 seconds. <- Project Manager .

2. Performance constraint (Survival and Fail) levels usually lie ‘outside’ the performance target (Goal, Stretch, Wish) levels.

3. Why an upper constraint limit for a performance? There are many reasons, which include:

  • To avoid ‘arms race escalation’
  • To avoid unnecessary costs, which would not be valued by a market
  • To avoid costing yourself out of a market
  • To avoid unnecessary cost - contract income is constant when you reach such a limit
  • To avoid ‘gold plating’ and over-engineering
  • To avoid becoming a monopoly and provoking legal reaction
  • To avoid showing your hand to the opposition.

Related Concepts [Performance Constraint *438]:

Keyed Icon [Performance Constraint *438]:

For Survival: O----------[-------------]----->

“One or both icons can be used depending on the numeric limits, which are being specified.”

For Fail: O ----!--------->

Type [Performance Constraint *438]: Constraint [Scalar].

Performance Design: Concept *520 . January 24, 2002

Performance Design is design specification aimed at, or as a side effect, satisfying performance level requirements. By definition this includes capacity requirements, quality requirements and savings requirements.

Note 1: On the multiple effects of any design.

Any design specification, however intended, in reality will impact many of our requirements. This multiple impact is true whether we like it or not. We cannot, it seems, only design on one pure requirement dimension (cost, performance, quality, condition constraint, function) without having some side effects in others.

Type: Design specification

Related Concepts [Performance Design *520].

  • performance *434
  • cost design *522
  • function requirement *074
  • performance {architecture, solution, design idea, and other synonyms of design)
  • design specification *586

Performance Survival limit: Concept *477 . August 31, 2001 tg 1546

A hard constraint on a scalar performance specified by the Survival limit parameter.

Related Concepts:

Type: constraint, requirement

Performance Requirement Concept *100 May 10, 2003

A performance requirement (objective) specifies the stakeholder requirements for ‘how well’ a system should perform.

A performance requirement can be complex or elementary. It is a scalar concept, and at elementary level is defined quantitatively by a set of performance targets and performance constraints.

Figure *100a: A performance requirement (objective) is specified as a set of performance targets and performance constraints.

Typical examples of performance requirements include ‘Usability’, ‘Reliability’ and ‘Customer Satisfaction.’

Performance Requirements are limited to consideration of the performance effectiveness of a system, without regard to the efficiency of it. That is, a performance requirement describes some aspect of the required performance; it does not describe the costs (the resources needed) to get the performance.

Notes:

1. The distinction between use of the terms ‘objectives,’ ‘quality requirements’ or ‘performance requirements’ is often simply dependent on the culture using them. Engineers are more likely to speak about ‘quality requirements’ for a system or product. Managers (of people and organizations) are more likely to think in terms of business/technical ‘objectives’.

2. A performance requirement is a potentially complex, detailed specification. It can consist of a whole hierarchy of performance attributes.

3. For each elementary performance attribute (distinguished by having only one Scale), there can be many performance targets and/or performance constraints.

(Note: this does not mean that the concept behind an elementary performance requirement is not ’really’ somehow complex, and that it is not capable of further sub-setting. It is simply that for the given system, further sub-concepts are not considered to be of interest or use at the current time. So ‘complex’ means ‘complex in terms of whether we have decided to decompose the concept in the current specification’. Not complex in terms of some constant reality.)

Example:

We can generally speak about a performance requirement, ‘ Reliability ’ for a defined system. Reliability may well be specified as elementary (having only one scale of measure). There can be several targets and constraints specified. Here below, is an elementary Reliability performance requirement with a Fail level and two Goal level specifications. Qualifiers distinguish the Goal level specifications from each other.

Reliability: “A Performance Requirement or Objective”

Scale: MTBF.

Fail: 30,000 Hours. “Constraint 1”

Goal [1 st Release]: 40,000 Hours. “Goal 1”

Goal [2nd Release]: 50,000 Hours. “Goal 2”

Of course, the ‘Reliability’ performance requirement could instead be a complex objective (that is, composed of one or more sub-objectives (elementary or complex)). For example, we might be interested in two Scales; ‘Mean Time Between Failure (MTBF)’ and ‘Number of Repeat Occurrences of Faults’. We would specify both of them as sub-requirements of the ‘Reliability’ requirement.

Reliability: {Failure Rate, Repeat Failures}.

4. Additional supporting information can be present in benchmark parameters (Past, Record, Trend).

Example:

Stretch [ Main Markets , Within the Decade ]: 99.998%.

A Performance Target

Security [ Corporate Webservers ]: Elementary Performance Requirement.

Version: 3.1 .

Owner: Tom .

Sponsor: Simon .

Scale: Annual Frequency of defined [ Type of Penetration ] using defined [ Type of [Threat ] used by defined [ Type of Perpetrator ].

Meter [ Acceptance ]: At least 300 representative cases of [ Type of Threat ] <- Contract 2.3.5.

------------------- Performance Targets --------------------------------------------------------------------------

Goal [ Security Type 1 , Next Year ]: <10. <- Official Project Steering Committee Agreement .

Stretch [ Security Type 1 , Next Year ]: 0. <- Technical Director’s Challenge .

------------------- Performance Constraint -----------------------------------------------------------------------

Survival [ Security Type 1 , Next Year and On ]: 60 <- CEO Public Promise of Improvement .

------------------- Benchmark ----------------------------------------------------------------------------------------

Past [ Security Type 1 , Last Year]: 66 <- Annual Executive Security Report [Page 55 ].

------------------- Definitions -----------------------------------------------------------------------------------------

Security Type 1 : Defined As: Type of Penetration = Access , Type of Threat = Remote Terminal , Type of Penetrator = Hacker ].

An Elementary Performance Requirement

Performance Requirement.The extent to which a mission or function must be executed, generally measured in terms of quantity, quality, coverage, timeliness, or readiness.

Source: US Mil-Std 499B 1994.

Synonyms [Performance Requirement *100]:

Related Concepts [Performance Requirement *100]:

  • Requirement *026
  • Performance Target (goal) *439
  • Performance Constraint *438

Keyed Icon [Performance Requirement *100]: @

In context, -----@---->

Same as Target *048

Note for the more-specific concept of performance targets use the set of target icons as follows:

O------>--->+--->?---->

A scalar performance arrow, ‘O------>’ with Goal (‘>’), Stretch (‘>+’) and Wish (‘>?’) icons

For performance constraints, use the set of constraint icons as follows:

O-------[------!--------]---------->

A scalar performance arrow, ‘O------->’ with Survival (‘[‘ and ‘]’) and Fail (‘!’) icons

Type [Performance Requirement *100]: Requirement Attribute.

Performance Target Concept *439 February 27, 2003

A performance target is a stakeholder-valued, numeric level of system performance.

There are three types of performance target:

  • a committed planned level (Goal),
  • an uncommitted motivating level (Stretch), and
  • an uncommitted valued level (Wish).

Notes:

1. The target parameters {Goal, Stretch, Wish} are used to express performance targets.

Example:

Goal [ Main Asian Markets , Next Quarter ]: 60,000 hours.

A Performance Target

2. A performance target is a single required level of performance (such as a Goal specification).

Example:

Goal [USA, Next Release]: 99.50%.

2. In contrast, a performance requirement includes both performance targets