Para No.

Para Title

Sev.

Application Guidance

1.2

Purpose

1.3

Field of application

1

First para. The standard can also be applied incrementally to the system.

4.1.5

architecture

4

The inclusion of “in its environment” in the definition of architecture is inappropriate. Consistent with a system being a bounded entity, a system has an architecture whether viewed in its environment or in isolation. The included words move the definition in the direction of failing to make a clear distinction between problem and solution.

4.1.12

Note 1

concern

2

The note (inappropriate) is inconsistent with the definition (appropriate). Concern (as defined) does not necessarily result in influence, nor is “in its environment” a precondition for a concern.

4.1.15

design, verb

3

The definition is made too broad by the inclusion of “and other characteristics”. For example, the definition of ownership, another characteristic of a system, cannot usefully be regarded as design of the system. Change “and other characteristics” to “and other solution characteristics”.

4.1.16

design, noun

5

The definition is poor in that it is devoid of the concept of levels of abstraction of design. Design is design, whether it is conceptual or in implementable detail or anywhere between. The definition of design (noun) is inconsistent with the definition of design (verb), which does not require an implementable level of detail.

4.1.17

design characteristic

2

The definition is ambiguous, in that it does not preclude an interpretation that includes a required characteristic that is solution-free, e.g. a mass limit or a required function. If that interpretation is intended, all requirements that have been satisfied are design characteristics, as are all characteristics that reflect design decisions. What would be the point of using such a definition? In addition, what is a measurable description? A characteristic can be measurable. But a description? – well, maybe measure the length of a printed sentence. Or the dimensions of a diagram? As well, why measurable? Would a design characteristic that is observable or countable but not measurable, e.g. the number of processors, not be a design characteristic. This is a really, really poor definition.

4.1.18

enabling system

7

The example and note are fine, but the definition is not. “Support” and “enable” have different meanings. An external power supply supports the system it powers by providing power, but it is not an enabling system. By contrast, a production system enables (makes possible) the production phase of the life cycle of the system-of-interest. It is more than just an interoperating system, it is an enabling system. The consequence of this relationship is that, unlike the power supply and the system to be powered, the system-of-interest and an enabling system cannot be designed independently, each against a mutually consistent set of requirements. The internal designs of the system-of-interest and its production system have to be intimately related. This reality is behind the practice of concurrent (simultaneous) engineering, probably the most significant aspect of the evolution of engineering practice over the last 100 years. The ISO/IEC/IEEE 15288:2015 definition of enabling system is a very bad definition.

4.1.23

life cycle

1

The definition is poor in that it assumes aspects of a particular life cycle. For example, not all systems are conceived – some are created by accident but prove to be useful, and not all systems have retirement within the context of planned human activity, e.g. an air traffic control system.

4.1.26

operator

4

To define an operator as an individual or organization that performs the operations of a system defies the Oxford English Dictionary and defies common sense. An operator performs operations on a system. The operator doesn’t carry the load in the trunk of a car from A to B. The operator controls the car to do so. Note 2 is correct, but misleading. The car can be our system-of-interest. The car plus operator can be our system-of-interest and this is a different system (a containing system with respect to both the car and the operator, both of which are system elements). It is common for companies developing products to set their system boundary as the technology plus the operating instructions, but with the operator who executes those instructions outside of the system boundary. In doing so, they accept responsibility for the behavior of the car if it is operated correctly, but do not accept responsibility if it is operated in conflict with those instructions.

4.1.29

problem

2

This definition is aligned to a context other than systems engineering. It is not well matched to the systems engineering use of the word “problem”, meaning something for which a solution is being sought.

4.1.32

product

4

The adoption of the ISO 9000:2005 definition of product as including service is unfortunate. The distinction is quite important in engineering. For example, the types of requirements for a product (something that is produced) and a service (an activity that changes some aspect of the state of the universe) are somewhat different. The organization of requirements in a specification of a product (e.g. a system or software requirements specification) versus a service (e.g. a Statement of Work) needs to be greatly different. The definition is also in conflict with the ISO/IEC/IEEE 15288:2015 definition of project, where the distinction between products and services is maintained (and rightly so), and inconsistent with the (appropriate) use of “products or services” in the standard, e.g. 5.2.1.

4.1.37

requirement

4

This definition of requirement violates the ISO directives in that it conflicts with the OED definition of a requirement. A requirement is not a statement, it is an abstract thing, something that somebody requires. A requirement can exist without being stated. The definition also lacks the concept inherent in requirement of an order or a demand, i.e. something that must be met. Needs can simply exist, without any corresponding requirement, because no decision is made to satisfy a need. For example, customers often need more that they can afford.

4.1.40

risk

9

This is a very poor definition of risk and is a disgrace in an engineering standard. Risk is expected loss, being the integration of the function describing magnitude of loss and the probability of that loss occurring. To define risk in any other way is to preclude sound decision-making in engineering practice that follows the standard.

The inclusion of opportunity as a component of risk is absurd in the extreme. Whenever I see this nonsense in ISO standards, I am reminded of the song titled “The Emperor’s New Clothes” from the 1952 musical film Hans Christian Andersen. The song tells the story of the King and the King’s wife and the King’s subjects, who, as the result of a deception performed on the King, all state that they are seeing a wonderful set of new clothes on the King but none wanting to admit that they cannot see any clothes at all. I see the same lemming-like behavior here in relation to the definition of risk in ISO standards.

4.1.46

system

2

The definition in ISO/IEC/IEEE 15288:2015 of “system” is in fact a definition of an engineered system, not a definition of a system in general. The definition is flawed as a definition of an engineered system by limiting to “for a stated purpose”. Is a system engineered to a known but unstated purpose not a system? The answer is obvious.

4.2

Abbreviated terms – NDI

1

The acronym NDI should be Non-Developmental Item (singular) not Non-Developmental Items (plural)

5.2.1

Systems

2

The reference to “its architecture and its system elements” is confusing and lacks logic, since the identification of the system elements is a part of the (physical) architecture of a system.

5.4.1

System life cycle model

1

The statement “A life cycle can be described using an abstract functional model that represents the conceptualization of the need for a system, its realization, utilization, evolution and disposal” is true, but pre-supposes a particular life cycle. This is an example, not necessarily inherent in the life cycle of a particular system.

5.6

Processes in this Standard

8

The System Life Cycle Processes (Figure 4) lack the crucial System Management Process, which must manage evolution, obsolescence, enhancement, decommissioning, and disposal of the system, beyond the project-related technical management processes shown. The Life Cycle Model Management Process has this planned, but the management is not accomplished.

6.1.1.3 a) 2) NOTE 2

Acquisition process

2

Stakeholder requirements are system requirements. Which system needs to be identifiable.

6.2.2.3 a)

Establish the infrastructure

9

The paragraph lacks the concept that each element of infrastructure is itself a system-of-interest. This paragraph needs to state that the 15288:2015 Technical Management and Technical processes are applied to establishment and maintenance of the infrastructure.

6.3.1.3 a) 4)

Project planning – Activities and tasks

3

The PMI Practice Standard for Work Breakdown Structures referred to is a pretty poor reference, about a 6/10. This document can be improved by replacement of the “bicycle diagram” in the document by an author-redrawn version (available on request).

6.3.1.3 b)

Plan project and technical management

6

The paragraph lacks the concept that the project is itself an enabling system, and in planning the project, it is the system-of-interest. This paragraph needs to state that the 15288:2015 Technical Management and Technical processes are applied to the project system in planning and executing the project.

6.3.1.3 b) 7) NOTE 1

Plan project and technical management

2

The term “Systems Engineering Management Plan” is fading away, as it should do. What is needed is not a plan for doing the systems engineering, not a plan for managing it. The terms Systems Engineering Plan and just “Engineering Plan” are better alternatives. Similar comments apply to the term “Project Management Plan”.

6.3.2

Project assessment and control process

6

This whole process description lacks the concept that the project is itself an enabling system, and in re-planning the project, the project system is the system-of-interest. This paragraph needs to state that the 15288:2015 Technical Management and Technical processes are applied to the project system in assessing and controlling the project, especially Verification and Validation.

6.3.3

Decision management process

7

This whole process description lacks the concept that the project is itself an enabling system, and in project decision-making, the project system is the system-of-interest. The process is mis-categorized as a management process; it is a technical process. For example, deciding whether to use steel or titanium is not managing the engineering, it is doing the engineering. This paragraph needs to state that the 15288:2015 Technical process of Effectiveness evaluation and decision is applied to the project system in making project and technical management decisions.

Alternatively, The Decision management process and the Risk management process may be regarded as “Shared processes”, because they are (or should be) invoked by the Agreement processes, the Organizational project-enabling processes, the Technical management processes and the Technical processes.

6.3.3.3 b) 2) NOTE

Activities and tasks (regarding Decision management process)

5

The note implies that the criteria themselves should be weighted, rather than defined improvements in the criteria from threshold to desired value being weighted. The former practice would create potential for errors in evaluation of one or two orders of magnitude.

The words “as well as weighting factors for all criteria” should be changed to “as well as weighting factors for improvement from threshold to desired value for all criteria”.

6.3.3.3 b) 4) NOTE

Activities and tasks (regarding Decision management process)

3

The last sentence of the note says “These results are used to establish the feasibility of the various trade alternatives”. This is incorrect. The alternatives subject to trade-off study have already been established to be feasible. The criterion for evaluation is expected effectiveness.

6.3.3.3 c) 1) NOTE

Activities and tasks (regarding Decision management process)

3

The note is inadequate in that it does not draw attention to the necessity, in most practical cases, of incorporating in the quantitative evaluation the uncertainty of outcomes with respect to each criterion for each trade alternative.

The note should read: “Alternatives are evaluated quantitatively, having regard to uncertainty, using the selection criteria. The selected alternative generally provides an optimization of, or improvement in, an identified decision, on a balance-of-probabilities basis”.

6.3.4

Risk management process

10

The content of 15288:2015 under “Risk management process” is seriously flawed from start to finish. The start is the use of the word “risk” throughout 6.3.4 with the meaning “threat”. It gets worse from there.

The reader is referred to the book “An Anatomy of Risk” by Royce for sound concepts of risk leading to sound concepts of risk management.

6.3.4.1 NOTE

Purpose (regarding the Risk management process)

8

The absurdity of the ISO Guide 73:2009 definition of risk and associated note was commented on under 4.1.40. The definition and note violate the ISO Directives.

6.3.4.2

Outcomes (regarding the Risk management process)

5

Every decision is made in the presence of some risk, often substantial. The separation of risk management from decision-making (Decision management process, Risk management process) is unfortunate. Risk management is (or should be) integral to decision management – a primary purpose of risk analysis is to inform decision-making.

In using 15288:2015 add: g) All project decisions made are optimum decisions having regard to the risk and opportunity associated with the decision alternatives.

6.3.4.3 a) 2) NOTE 2

Activities and tasks (regarding the Risk management process

3

The statement: “Opportunities, which are one type of risk, …” is absurd. This content of 15288: 2015 violates the ISO Directives.

6.3.5.3 b) 4) NOTE

Activities and tasks (regarding the Configuration management process)

6

The statement “There are generally three major types of baselines at the system level; functional baseline, allocated baseline, and product baseline” is misleading. Only the so-called functional baseline is at the system level, being a baseline of system requirements. Allocated and product baselines are both design baselines and are populated with information relating to design of the system, i.e. information below the system level.

The term “functional baseline” implies a baseline of functional requirements and is often misunderstood. The term should not be used.

The term or concept of “allocated baseline” is not a fundamental of engineering, and should not be afforded the same status as the fundamental baselines of requirements and design. As well, the term needs explanation.

The term “product baseline” needs explanation.

Revise as follows: “There are generally three major types of baselines at the system level; functional baseline, allocated baseline, and product baseline” with “There are generally two major types of baselines with respect to a system: a requirements baseline (sometimes called a functional baseline), and a baseline of all of the information necessary to build the system – a complete design baseline, sometimes referred to as a product baseline. A baseline of design at a single physical level in the system breakdown structure, sometimes referred to as an allocated baseline, may also be defined”.

6.3.5.3.5 b) 5

Activities and tasks (regarding the Configuration management process)

7

A requirement to obtain acquirer and supplier agreement to the establishment of a baseline is usually appropriate for a requirements baseline, but may be wasteful of time and money for a design baseline, “allocated” or “product”, placing a straightjacket on the supplier for no good reason.

Add “where the agreement between the acquirer and supplier so requires”.

6.3.5.3 c) NOTE

Activities and tasks (regarding the Configuration management process),

4

The note is misleading. While it is true that configuration change management provides a uniform method for managing change to a baseline once it is established, through the act of re-baselining, the primary role of configuration change management is to manage change with reference to a baseline once it is established.

Change “Configuration change management provides a uniform method for managing change to a baseline once it is established” to “Configuration change management provides a uniform method for managing change with reference to a baseline once the baseline is established, and for managing acts of re-baselining”.

6.3.5.3 e) 4) plus NOTE

Activities and tasks (regarding the Configuration management process)

4

The paragraph reflects a common misunderstanding that arises from inappropriate use of language.

Replace with:

“Perform an evaluation of the body of evidence to establish whether the system meets its specified requirements.”

NOTE: This is sometimes called a requirements satisfaction audit or functional configuration audit.

6.3.5.3 e) 5) plus NOTE

Activities and tasks (regarding the Configuration management process)

5

The paragraph does not reflect the nature of a physical configuration audit, nor does it reflect what is needed.

Replace with:

“Perform an evaluation to establish whether the system as built and verified as meeting requirements corresponds to its design description”.

NOTE: This is sometimes called a build state-build standard correspondence audit or a physical configuration audit.

6.3.5.3 f) 2) NOTE

Activities and tasks (regarding the Configuration management process)

3

The statement “Master copies of all system elements are generally maintained for the life of the system” is true for software, but generally untrue for physical systems.

Replace the note with: “For software systems, master copies of all system elements are generally maintained for the life of the system”.

6.3.6.3 b) 2) NOTE 1

Perform Information Management

1

NOTE: One needs also to invoke the Configuration Management process, making it clear that an information item may be a Configuration Item.

6.3.7

Measurement process

3

There is much overlap between the Information management process and the measurement process. For example, “The purpose of the Information Management Process is to generate, … information, to designated stakeholders” and under Measurement process “collect … data”.

6.3.8

Quality assurance process

3

There is much overlap between the Quality assurance process and the Verification and Validation processes. Quality management and Verification and Validation should be one and the same thing.

6.3.8.3

Perform product or service evaluations

3

There is much overlap between tasks 1) and 2).

6.4

Technical processes

9

This whole section is on the right track, but lacks a recognition and articulation that the Business or mission analysis process is no more and no less than an application of the problem definition and solution definition principles and methods that apply at any physical level, and are applied recursively at various physical levels. Thus there is redundancy in the present content of the technical processes:

a) Business or Mission Analysis Process;

b) Stakeholder Needs and Requirements Definition Process;

c) System Requirements Definition Process;

d) Architecture Definition Process;

e) Design Definition Process;

f) System Analysis Process.

More importantly, the section is lacking a recognition of, and emphasis on, the essential problem-solving nature of the transformation from the definition of the enterprise/business/mission problem to the definition of requirements on technology items that typically become the subject of contracts for products and services, and the subject of internal organizational development. Such items are typically the systems referred to in the current technical processes:

b) Stakeholder Needs and Requirements Definition Process;

c) System Requirements Definition Process;

d) Architecture Definition Process;

e) Design Definition Process;

f) System Analysis Process;

including enabling systems such as project systems, maintenance systems and production systems.

These relationships are explained in the PPI document with filename: P045-AGB04-003358_OCD_SSDD_SyRS.pdf (available on request).

These relationships are also illustrated in the example documents:

·       PPI-005600-3 Example SSRC CapSyRS 150105.pdf

·       PPI-005603-2 Example SSRC OSD/CONOPS 130530.pdf

·       PPI-005638-2 Example Buoy SyRS 150224.pdf

·       PPI-005604-2 Example Statement of Work SOW – Submarine Emergency Comm. Buoy User Training.pdf,

available on PPI’s Systems Engineering Goldmine website.

The standard would be improved greatly by replacing the first listed processes with:

a) Requirements capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process,

and by 6.4 being expanded to explain the application of these four processes at the Enterprise/Business/Capability system level, and at lower physical levels, including the application to enabling systems at the lower levels.

The explanation would emphasize the concept of an Enterprise/Business/Capability system, the importance of sound and formalized problem definition at this level using the Problem capture and validation process, and the importance of creating requirements on solution elements, such as products and services subject to contract, and elements the subject of internal organizational development, using the Solution architecture definition and Solution detailed design processes.

The Solution architecture definition and Solution detailed design process descriptions would emphasize the invoking of the System analysis process, the Risk management process and the Decision management processes as integral parts of the above processes.

6.4 NOTE 2.

Technical processes

5

The first sentence of the note implies that requirements, critical performance measures and critical quality characteristics are somehow different things. The note should read “requirements, including critical performance values, and any other critical quality characteristics …”

6.4.1.1

Purpose (in relation to Business or mission analysis process)

8

It is inappropriate to muddle up problem definition and solution definition in the one process. Even though they may be done concurrently to some degree, or with iteration between them, the purpose, the activities and the outputs of each are vastly different.

6.4.1.1 NOTE 1

Purpose (in relation to Business or mission analysis process)

5

It is stated that the organization’s strategy is outside the scope of 15288. Why? The statement appears subsequently to be contradicted (in the last sentence of the note). INCOSE co-publishes a Journal of Enterprise transformation that is entirely about the enterprise as an engineered system.

6.4.1.1

Purpose (in relation to Business or mission analysis process)

10

The outcome, “The problem or opportunity space is defined” in 6.4.1.1 is a duplication of the major outcome of the Stakeholder needs and requirements definition process of 6.4.2, here applied at an enterprise level.

It makes no sense to bring half-baked versions of two other processes into a pot and call the contents an additional process.

6.4.1.1

Purpose (in relation to Business or mission analysis process)

10

The outcomes b) to d) are a duplication of the outcomes of the Architecture definition process of 6.4.4, here applied at an enterprise level.

It makes no sense to bring half-baked versions of two other processes into a pot and call the contents an additional process.

6.4.2.1

Purpose (in relation to Stakeholder needs and requirements definition process)

7

The standard says, “The stakeholder requirements are defined considering the context of the system-of-interest with the interoperating and enabling systems”. This is a good statement if the system-of-interest is a technology item, but if it is a business/enterprise/capability system, the enabling systems are a part of the solution.

The sentence should read, “The stakeholder requirements are defined considering the context of the system-of-interest with the interoperating and any enabling systems”.

6.4.2.2 h)

Purpose (in relation to Stakeholder needs and requirements definition process)

2

The listed outcome, “Any enabling systems or services needed for stakeholder needs and requirements are available” doesn’t make sense.

Maybe it was supposed to read, “Any enabling systems or services needed for stakeholder needs and requirements definition are available”.

6.4.2.3. b) 3) NOTE

Prioritize and down-select needs

5

Add to the NOTE that any prioritization and down-selection is done in consultation with (at least) primary stakeholders – stakeholders to whom those doing the Stakeholder needs and requirements definition owe allegiance.

6.4.2.3. b)

Develop the operational concept and other life cycle concepts

2

The note is fine if the system is a technology item, but if it is a business/enterprise/capability system, other life cycle concepts will be a part of the solution.

6.4.2.3. d) 2)

Transform stakeholder needs into stakeholder requirements

3

“such as assurance, safety, security, environment or health” implies that performance is not a critical quality characteristic. Unlikely!

6.4.2.3 e) 2) NOTE

Analyze stakeholder requirements

7

The reference to measures of suitability is quite counterproductive in an international standard. Suitability is only meaningful when defined, since it is a vague conceptual term. The measures of suitability, when defined, are measures of effectiveness that sit alongside other measures of effectiveness, including measures of performance. The language in this note is similar to United States Department of Defense thinking, and serves only to confuse a simple set of basic but enormously powerful relationships.

6.4.2.3 e) 2) NOTE

Analyze stakeholder requirements

7

The note may be mixing up requirements on two different systems – a capability system defined by “stakeholder requirements” and a solution element defined by “system requirements”. It is hard to say!

6.4.2.3
e) 2) NOTE

Analyze stakeholder requirements

7

The use of the word “performance” in this note seems to be at odds with the OED unless the note is intending to refer to non-performance measures of the product (e.g. cost) as performance measures of the project or of the engineering. If that is the intention there is no problem apart from the ambiguity!

6.4.2.3 f) 2) NOTE

Analyze stakeholder requirements

2

The sentence, “Additional traceability to systems making up the system solution facilitates the transition to the System Requirements Definition process” seems totally out of place here – in a section on process of stakeholder requirements definition.

6.4.3.1

Purpose (in relation to System requirements definition process)

10

The statement of purpose here is fundamentally unsound. Stakeholder requirements are system requirements. Which system can be an issue – a capability system or a technology item? If the solution provider cannot through analysis of the stakeholder’s needs transform an initial set of stakeholder requirements into a set of stakeholder requirements suitable for driving development of a solution, the stakeholders should find somebody who can. What seems more likely here is that the process is muddling up problem and solution.

Why does the standard state “the system requirements from the supplier’s perspective”? Is it the stakeholders who have the problem? Put the fox in charge of the chicken house! – No.

6.4.3.2

Outcomes (in relation to System requirements definition process

10

Outcomes a) to d) should have been accomplished in Stakeholder needs and requirements definition. Unless the “system” here is a technology item that is a part of the solution to a business/enterprise/capability system. In which case, the standard, like its predecessor, has a “then a miracle occurs process”, rather than recognizing the essential problem solving nature of the transformation of requirements on a capability system to requirements on elements of the capability solution. An example is stakeholder requirements to create holes in the ground at a minimum rate per day over a period of two years (problem) vs. solution elements of a purchasing infrastructure, a shovel, the stakeholder who will himself operate the shovel, a shed, a lock and a key.

If the latter is the intention then the Architecture definition process, the Detailed design process, and downstream processes achieve this.

6.4.3.3 b) 2)

Define necessary implementation constraints (in relation to System requirements definition process)

2

The note makes no sense. If the note is talking about the same system, and we are defining requirements on the system, how can implementation decisions be allocated from architecture definition at higher levels in the structure of the system? Higher that what?

6.4.3.3 b) 4) NOTE 1

Define necessary implementation constraints (in relation to System requirements definition process)

7

The note says that, “Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system hierarchy.” While the comment is true, it belies the three main and mostly avoidable reasons for this:

·       requirements were created by designers with poor understanding of the technologies in which they were designing;

·       these bad requirements were made worse by poor requirements writing skills;

·       the fate was sealed when no requirements analysis was done at all by the recipient of the requirements, or it was done poorly;

·       requirements were genuinely changing over time (the least likely of the possible reasons).

6.4.3.3 c) 2) NOTE

Analyse system requirements (in relation to System requirements definition process)

3

Language in the note is very loose. A quality measure can be “technical”. Each can be a critical performance parameter.

6.4.4.1

(second sentence)

Purpose (in relation to Architecture definition process)

4

Whilst the statement is true, a great deal of the iteration that occurs is for the wrong reasons and represents avoidable rework.

6.4.4.1 NOTE 2

Purpose (in relation to Architecture definition process)

7

The following sentences in the note are not correct:

·       the contrast between “architecture” and “design” (where does architectural design fit?)

·       an effective architecture is as design-agnostic as possible (total nonsense, as evidenced by the content of a number of standards for architectural design descriptions).

The primary concerns in architecting are:

·       identification of conceptual alternatives that are able to meet all requirements and have potential to be the most overall effective;

·       definition of these alternatives in terms of the key solution elements, the key characteristics of each, and the concept of their interoperation to meet requirements; and

·       characterization of each of such alternatives sufficient for evaluation of and selection between them, to as to choose the best.

The drivers in selection of architecture vary enormously between systems and also with circumstances.

6.4.4.2 c)

Outcomes (in relation to Architecture definition process)

7

Context, boundaries and required external interfaces were defined in requirements analysis. Further definition occurs in architecture definition only to the extent that decisions are made to use externally-provided consumables as a part of the solution, e.g. grid power, or details of required interfaces were not defined in requirements and are therefore discretionary.

6.4.4.3 a) 2)

Prepare for architecture definition (in relation to Architecture definition process)

7

The identification of stakeholder concerns to the extent indicated in the paragraph indicates that the problem was never properly defined in the first place (unless the problem is genuinely changing at a significant rate).

6.4.4.3 a) 4)

Define evaluation criteria … (in relation to Architecture definition process)

7

The definition of evaluation criteria should have been accomplished in requirements analysis. If it wasn’t, the job wasn’t done properly.

6.4.4.3 d) 3)

Partition, align and allocate … (in relation to Architecture definition process)

7

This activity as described is devoid of the concept of deriving by design requirements on system elements within a system solution. Partitioning of requirements is behind a litany of project failures, cost blow-outs and schedule slippages.

6.4.5.1 NOTE 1

Purpose (in relation to Design definition process)

7

The following sentences in the note are not correct:

·       the contrast between “architecture” and “design” (where does architectural design fit?)

·       an effective architecture is as design-agnostic as possible (total nonsense, as evidenced by the content of a number of standards for architectural design descriptions).

The primary concerns in architecting were:

·       identification of conceptual alternatives that are able to meet all requirements and have potential to be the most overall effective;

·       definition of these alternatives in terms of the key solution elements, the key characteristics of each, and the concept of their interoperation to meet requirements; and

·       characterization of each of such alternatives sufficient for evaluation of and selection between them, to as to choose the best.

The drivers in selection of architecture vary enormously between systems and also with circumstances.

6.4.7

Implementation process

8

It is illogical and misleading that the implementation process as currently described includes the decision making on how implementation is to be achieved. What a muddle! The solution to achieving implementation is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the process description Outcomes 6.4.7.2 a) and b), and 6.4.7.3 a) 1), 2) and 3). Emphasize that implementation is performed using an implementation system created, verified and validated in accordance with this standard.

6.4.8

Integration process

8

It is illogical and misleading that the integration process as currently described includes the decision making on how integration is to be achieved. What a muddle! The solution to achieving integration is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the process description Outcomes 6.4.8.2 a), b), c) and d) and 6.4.8.3 a) 1), 2) and 3). Emphasize that integration is performed using an integration system created, verified and validated in accordance with this standard.

6.4.9

Verification process

8

It is illogical and misleading that the verification process as currently described includes the decision making on how verification is to be achieved. What a muddle! The solution to achieving verification is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the process description Outcomes 6.4.9.2 a), b), c) and d) and 6.4.9.3 a) 1), 2) and 3). Emphasize that verification is performed using a verification system created, verified and validated in accordance with this standard.

6.4.10

Transition process

5

The transition process as described assumes a particular type of system – a system installed in an operational location. This international standard is intended to be general in its application, but the description of the transition process is not.

6.4.10

Transition process

8

It is illogical and misleading that the transition process as currently described includes the decision making on how transition is to be achieved. What a muddle! The solution to achieving transition is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the process description Outcomes 6.4.10.2 a), b), c) and 6.4.10.3 a) 1), 2), 3), 4), 5), and the identification element of 7). Emphasize that transition is performed using a transition system created, verified and validated in accordance with this standard.

6.4.10.3 a) 3)

Transition process

7

6.4.10. 3 a) 3), arrange training of operators, is an outcome of the Implementation process, not the Transition process.

Remove the 6.4.10. 3 a) 3) reference to arranging training of operators. Revise the Implementation process description to make it clear that appropriately trained and qualified personnel are an outcome of this process.

6.4.11

Validation process

8

It is illogical and misleading that the validation process as currently described includes the decision making on how validation is to be achieved. What a muddle! The solution to achieving validation is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the process description Outcomes 6.4.11.2 a) and c), and 6.4.11.3 a) 1), 2), 3), 4), 5) and 6). Emphasize that validation is performed using a validation system created, verified and validated in accordance with this standard.

6.4.12

Operation process

8

It is illogical and misleading that the operation process as currently described includes the decision making on how operations are to be achieved. What a muddle! The solution to achieving operations is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

The operations system is inherently the primary end-use system.

Remove from the process description Outcomes 6.4.12.2 a), b), c) and d) and 6.4.12.3 a) 1), 2) and 3). Emphasize that operation is performed using a system created, verified and validated in accordance with this standard.

6.4.12.2 d) and e)

Operations process

7

6.4.12.2 d) and e) are outcomes of the Implementation process, not the Operations process.

Remove 6.4.12.2 d) and e). Revise the Implementation process description to make it clear that appropriately trained and qualified personnel are an outcome of the Implementation process.

6.4.13

Maintenance process

8

It is illogical and misleading that the maintenance process as currently described includes the decision making on how maintenance is to be achieved. What a muddle! The solution to achieving maintenance is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the maintenance process description Outcomes 6.4.13.2 a), b) and c), and 6.4.13.3 a) 1), 2), 3), 4). Emphasize that maintenance is performed using a maintenance system created, verified and validated in accordance with this standard.

6.4.14

Disposal Process

8

It is illogical and misleading that the disposal process as currently described includes the decision making on how disposal is to be achieved. What a muddle! The solution to achieving disposal is a system like any other system, subject to the:

a) Problem capture and validation process;

b) Solution architecture definition process;

c) Solution detailed design process;

d) System analysis process;

e) Implementation process;

f) Integration process;

g) Verification process;

h) Transition process;

i) Validation process;

j) Operation process;

k) Maintenance process;

l) Disposal process;

like any other system.

Remove from the disposal process description outcomes 6.4.14.2 a), b) and c), and 6.4.14.3 a) 1), 2), 3), 5) and 6). Emphasize that disposal is performed using a disposal system created, verified and validated in accordance with this standard.

Annex B (informative)

Table B.1

Example process information items – Business or Mission Analysis Process

7

Add Business Requirements

Add Business Value Model

Annex B (informative)

Table B.1

Example process information items – Stakeholder Needs & Requirements Definition Process

7

Add Stakeholder Value Model

Annex B (informative)

Table B.1

Example process information items – System Requirements Definition Process

7

Add System Value Model

Add System Verification Requirements

Annex B (informative)

Table B.1

Example process information items – Design Definition Process

7

Add System Element Requirements

Add System Element Value Models

Add System Element Verification Requirements

E.4

Process view for speciality engineering

5

The Annex says that, within 15288:2015, the standard calls the “ilities” “critical quality factors”. This is ridiculous! A given “ility” with respect to a given system may be critical. Or it may be important but not critical. Or it may be of low importance, but still justify a requirement. Or it may be of no importance at all, e.g. maintainability for a coin. The same comments could be made for safety.

E.4

Process view for speciality engineering

5

The statement, “These characteristics determine how well the product meets its specified requirements …” is patently incorrect. The design and construction determine how well a product meets its specified requirements.

F.3.1

Functional model

2

The paragraph uses the term “constraint requirements” without defining the term. Every requirement is a constraint (limits the boundary within which a solution must fall). Every constraint is not a requirement (e.g. 24 hours in the day).

F.3.1

Functional model

2

A functional model can also be solution level (internal functions) and can include functionality contributing to satisfaction of non-functional requirements.

F.3.2

Behavioral model

A behavior-model does not have to be functional; a behavior model can be state-based.

F.3.3

Temporal model

3

The text is an example, not a definition. A temporal model for a hearing aid will not have a strategic level, tactical level, operational monitoring level, regulation level, etc.

G.1

Introduction

7

The definition of system of systems, while technically correct, reflects a common misunderstanding brought about by a very poorly chosen name. The distinguishing feature of a so-called system of systems (in systems of systems engineering) is that the system elements are autonomously managed, meaning that the engineer of the system-of-interest cannot just demand behavior or other characteristics of a system element and expect to get it. Eacg system element also itself has end-use, serving human stakeholders. This is made clear in later paragraphs.