Function vs. Technical and Operational
Specifying functional requirements is tricky: The functional requirement of “reporting subject location in real time” can be interpreted as a 1-Piece or 2-Piece solution, reporting each minute or every 10 seconds, with a precision of 10 meters or 5 kilometers in different probabilities, and the battery will maintain 36, 24 or 6 hours depending on the usage profile. Another functional requirement can be “the equipment should be upgraded”. It is quite clear that upgrading the equipment via remote access is much more “operational friendly” than collecting all equipment and upgrading it in the lab. The communication between the field devices and the back-end servers is an essential aspect of the EM solution, but security and reliability is part of the demand. Those parameters are not EM functional requirements, but a kind of sideways requirement.
All the examples are here solely to help you understand that the separation between functional, operational and technical requirements is artificial. In many cases all aspects of a requirement are connected together without practical distinction. It is crucially important to understand all implications of each requirement, in order to define exactly what you would like to get and be able to test it before your final decision.
As always, as long as you know more, your position in front of your suppliers is better.
Guidelines for writing the requirements
- Know the details of your functional needs. It sounds simple, but it isn’t. This is actually the first phase while working on a new project.
- Be precise with the translation of the functional needs to the technical and operational spec. For example, if there is a functional need to have a home detention capability, you should define the precision of the solution (the apartment borders should be very accurate, or the apartment neighborhood will be good enough); based on that other aspects are then derived, such as secondary verification method, false alarms, RF range configurations, etc.
- It is essential to be familiar with all aspects of the EM solution and also about the market offering, in order to create a realistic tender on one hand and get what you need on the other. For example: Can the GPS solution be based on the back-end server calculations or do you need better performance? What are the legal requirements for alcohol monitoring; is yes/no sufficient, or is an accurate blood alcohol concentration level needed?
- The operators and managers of the EM system should have close communication with the tender writer.
- It is highly recommended to define the new tender requirements based on educated working protocols. For instance, before defining logistics requirements, you should know what your logistics facilities are, how you intend to move the home unit from the warehouse to the installer, how you will change units in case of installation problems, etc.
- Clearly define what the mandatory requirements are. These should be based on your needs, and also on what is achievable. You don’t want to be in a position where you specify a mandatory requirement that no vendor can meet.
- On the other hand, remember that the imminent contract will take place for the next 3-7 years. Many things may be changed. Be open! As an example, API is not necessarily what you need today, but it can be your way achieving other capabilities in the near future. API is also quite a common offering by the vendors. Consider asking for that in the tender.
- Reliability is king – Because of many reasons, the EM solutions do not meet the reliability expectations from technological system. I’ve heard from many EM program managers that as a mandatory requirement they “want the system to work as it should.”
The tender should reflect two aspects regarding reliability: a) There should be reliability requirements that specify concrete targets (e.g. system availability, false alarm rate, water resistance, etc.); and b) You will not be able to check all reliability aspects by the written submission (e.g. application usability, installation, RF coverage, etc.). You should thoroughly test the system before making the final decision.
- Specify each requirement in specific and measurable terms. For example, “A fully charged device should hold for at least 36 hours in the following typical usage scenarios: GPS sampling rate: 60 seconds, communication rate: 300 sec,” instead of “the device should hold for at least 36 hours.”
- Bear in mind the tracking capabilities you need: each element should have a Serial Number (S/N), and a predefined lifetime. Even if you are not paying for a replacement (in the case of a lease contract, or any other guarantee arrangement), there is a huge operational and efficiency differences between a lifetime of 3 years or 2 years for a GPS device, for instance. It is highly recommended to ask for the technical reports about how this lifetime is calculated.
This is only a partial list. If you find it interesting, please reply with your specific needs and I’ll do my best to elaborate.