Application of Systems Engineering Standards

There are many systems engineering standards that have evolved as indicated in Relevant Standards. In particular, there are standards that can have an influence on Organizations and their Projects as indicated in Figure 1. Some pitfalls and good practices in utilizing standards are also identified in the article on relevant standards. In this article, several additional factors related to the utilization of the standards are presented.

Standards and their Utilization

Figure 1. Potential Standards Influence of Organization and Project Processes (Roedler 2011) Reprinted with permission of Garry Roedler.

A standard is an agreed, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. Standards are created by bringing together the experience and expertise of all interested parties, such as the producers, sellers, buyers, users, and regulators of a particular material, product, process, or service.

Standards are designed for voluntary use and do not impose any regulations. However, laws and regulations may refer to certain standards and make compliance with them compulsory.

Further, organizations and their enterprises may choose to use standards as a means of providing uniformity in their operations and/or the products and services that they produce. The standard becomes a part of the corporate culture. In this regard, it is interesting to note that the ISO/IEC 15288 standard has provided such guidance and has provided a strong framework for systems engineers as well as systems engineering and business management, as forecast earlier by Arnold and Lawson (2004).

ISO directives state the following:

A standard does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a standard, the user (of the standard) needs to be able to identify the requirements he is obliged to satisfy. The user needs also to be able to distinguish these requirements from other provisions where a certain freedom of choice is possible. Clear rules for the use of verbal forms (including modal auxiliaries) are therefore essential.

Requirements, Recommendations, and Permissions

In order to provide specificity, standards employ verb forms that convey requirements, recommendations, and permissions. For example, the ISO directives specify the following verb usages:

• The word "shall" indicates requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted.

• The word "should" indicates that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred, but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

• The word "may" indicates a course of action permissible within the limits of the standard.

The directive also indicates that standards should avoid the use of "will," "must," etc.

Certification, Conformance and Compliance

In the context of the management system standards (ISO 9001:2000 and ISO 9001:2008 or ISO 14001:2004), “certification” refers to the issuing of written assurance (the certificate) by an independent external body that it has audited a management system and verified that it conforms to the requirements specified in the standard.

Typically, other more specific systems engineering standards are not the subject of certification. They are self-imposed in order to improve uniformity of organization and enterprise operations or to improve the quality of products and services. Alternatively, they may be dictated by legislation, policy, or as part of a formal agreement between an acquirer and a supplier.

Conformance testing, or type testing, is testing to determine whether a product or system meets some specified standard that has been developed for efficiency or interoperability. To aid in this, many test procedures and test setups have been developed either by the standard's maintainers or external organizations, such as the Underwriters Laboratory (UL), specifically for testing conformance to standards.

Conformance testing is often performed by external organizations, which is sometimes the standards body itself, to give greater guarantees of compliance. Products tested in such a manner are then advertised as being certified by that external organization as complying with the standard.

Service providers, equipment manufacturers, and equipment suppliers rely on this data to ensure quality of service (QoS) through this conformance process.

Tailoring of Standards

Since the systems engineering standards provide guidelines, they are most often tailored to fit the needs of organizations and their enterprises in their operations and/or for the products and services that they provide, as well as to provide agreement in a contract. Tailoring is a process described in an annex to the ISO/IEC 15288 standard.

The ISO/IEC 15288 addresses the issues of conformance, compliance, and tailoring as follows:

• Full conformance - A claim of full conformance first declares the set of processes for which conformance is claimed. Full conformance is achieved by demonstrating that all of the requirements of the declared set of processes have been satisfied using the outcomes as evidence.

• Tailored conformance - When this international standard is used as a basis for establishing a set of processes that do not qualify for full conformance, the clauses of this international standard are selected or modified in accordance with the tailoring process.

• The tailored text, for which tailored conformance is claimed, is declared. Tailored conformance is achieved by demonstrating that requirements for the processes, as tailored, have been satisfied using the outcomes as evidence.

• When the standard is used to help develop an agreement between an acquirer and a supplier, clauses of the standard can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with the standard.

• Any organization (e.g., a national organization, industrial association, or company) imposing the standard as a condition of trade should specify and make public the minimum set of required processes, activities, and tasks, which constitute a supplier's conformance with the standard.

References

This article relies heavily on limited sources. Reviewers are requested to identify additional sources.

Works Cited

Arnold, S., and H. Lawson. 2004. "Viewing systems from a business management perspective." Systems Engineering, 7 (3): 229.

Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.

Primary References

No primary references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

Additional References

No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

---

< Previous Article | Parent Article | Next Article (Part 4) > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus