Editor's note: This is the 18th article in the "Real Words or Buzzwords?" series from SecurityInfoWatch.com contributor Ray Bernard about how real words can become empty words and stifle technology progress.
I’m not really picking on the word “robust” itself, but on how it gets used in descriptions of security products. So, although we’re discussing “robust” in this article, the way the word is misused applies to many other terms.
Google shows that use of the word “robust” over time has been relatively flat for the last 200 years, then its use started climbing after 2000 and is now more than twice any previous level. So, it is a popular word and maybe that’s why it’s showing up in product brochures and most recently in A&E specifications.
Robust is a multi-faceted word whose specific definition should easily be recognized from context. Dictionary.com provides these definitions:
- strong and healthy; hardy; vigorous
- strongly or stoutly built
- suited to or requiring bodily strength or endurance
- rough, rude, or boisterous
- rich and full-bodied
- strong and effective in all or most situations and conditions
In theory, definitions two and six should most easily apply to security products, although in practice the use of robust often reduces the clarity of the message as some examples below will show. In the many fields of product engineering, there are specific definitions for the term “robustness.” For example, the IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990) defines robustness as: "The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions." These conditions are then defined and tested, using standard practices that have evolved for robustness testing. Door lock hardware products, for example, are subject to rigorous testing.
What Are We Really Saying?
Here are some examples taken from security product A&E specification documents, edited just enough to remove company and product names and to assure that you can’t easily find them with an Internet search.
- The unit shall utilize robust buttons.
- Provide robust, industry-leading warranties.
- The software shall be robust and reliable.
- The design shall provide ease of installation, robustness, reliability, and expansion.
- The CPU provided for the Access Control System server shall be reliable and robust in construction.
These examples are typical of the several dozen appearances of “robust” across the 120 specification documents I sampled. In all these documents, “robust” comes very close to being meaningless.
Engineering students are always taught that specifications must be testable. An Internet search for “testable specification” (quotes included), shows that about 4,000 sources across many fields all agree. Maybe it’s because marketing folks don’t attend engineering school that specifications get requirements that aren’t verifiable by observation or testing.
I agree with using words like “robust” and other descriptive language to convey design intent. But then design specifics must immediately follow. Think: specific + ation – the act of providing specifics. For example:
- Provide robust front-panel controls utilizing non-corroding metal buttons with wear-resistant labels above or below, designed to withstand continuous use.
- The software shall have robust communications capabilities so that loss of connectivity to external systems or devices (a) is immediately logged, (b) initiates user notification according to user-specific notification settings, and (c) causes no software malfunction.
Specifications are used by design engineers, consultants, system integrators and end-user customers to support product selection and assure that customer needs will be met. Specifications should convey both design intent and design specifics to facilitate the product evaluation process.
Sadly, the examples above of using the word “robust” are taken from actual specifications that refer to good products in popular use. The specification documents did not do them justice. A lot of hard work goes into designing and developing good products. Why waste everyone’s time, and defeat the purpose of the document, by using words that don’t convey actual product value?
Remember that “robust” and other qualifying terms are intended to convey design intent, and must be followed with design specifics that relate to the experience of the people providing, using, and servicing the deployed technology. Whether or not such terms are meaningless depends entirely on how you, yourself, use them.
About the Author:
Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities (www.go-rbcs.com). He is the author of the Elsevier book Security Technology Convergence Insights available on Amazon. Mr. Bernard is a Subject Matter Expert Faculty of the Security Executive Council (SEC) and an active member of the ASIS International member councils for Physical Security and IT Security.
