Although it's impossible for a standard to please all the people all the time, the groups that create them have to come as close as possible. Before it can come up with viable standards for wireless monitoring and control networks, ISA's SP100 committee has to come to grips with requirements, preferences, and expectations.
Requirements vs. Expectations
As part of its call for proposals, ISA's SP100 committee spent a great deal of time discussing the technical requirements that must be covered by its standards. Because I preside over these meetings (I'm co-chair with Richard Sanders from Exxon-Mobil), I decided to offer my perspective on the difference between requirements and expectations.
Successful commercial companies have become very accomplished at quizzing end users (the so called voice of the customer), documenting responses, and assuring everyone that their products suitably address documented requirements (see the tool that Telelogic developed for this process). But what if the system meets all the requirements and still doesn't work?
In the wireless business, a lot of end users say, "Hey! I don't care about frequency, modulation, or even protocol; I just want it to work!" This difficulty is quite common when new technologies emerge from the labs and start showing up in products. End users may expect new products to behave like the old ones, but they soon realize that the new technology actually requires that they rethink the problem. The cell phone didn't just remove the wire from our phones; it changed the way we interact with each other.
At a recent SP100 committee meeting, I asked: How do we address the fact that there may be a mismatch between end-user expectations and requirements? Some suppliers ventured that it may be enough for the product to meet the requirements.
I believe the market will suffer if end users are forced to become experts at specifying their requirements in ways that will allow the suppliers to translate them into system, subsystem, and component specifications. Placing all this responsibility on the end user could be a risk. Clearly, meeting the requirements is necessary, but it doesn't guarantee success.
Preferences
Many times, end users quote what I call preferences rather than true requirements. For example, is it a requirement or a preference if an end user specifies, "All screens shall display the company logo in the lower left corner." Perhaps real requirements come from physics, not users. If an end user specifies that a temperature shall be updated every 10 seconds, when the thermal mass of the measured quantity could result in a temperature that changes every 2 seconds, a supplier would be foolish to sample at 10 seconds.
At SP100, we're trying to build a standard that helps suppliers meet the end users' requirements, preferences, and expectations.