To plan and source for your IoT project, it’s important to agree on a set of requirements. It helps rank what is important and forces your team to make some decisions. By this point you must understand what it is you’re trying to solve with smart technology. Have a basic understanding of the business model behind the project and be ready to move forward.
The difficulty with IoT projects is that there are many moving parts. Whether it’s the capabilities of the device, security, software or data analysis. All components link to one another and that’s why this list of questions can help. There are many approaches for getting to specific requirements. From traditional process flows and architecture to user stories and personas. These methods can help clarify the requirements and can be an addition to this list. Regardless of how you like to structure the answers from this list, it has proven to help to get the ball rolling.
We designed the list to help your team create a workshop around these questions. Brainstorm about these questions with team members from different disciplines to specify requirements. Some companies have used this list to prepare for a meeting. While others use this list to come up with answers collectively.
Data and Events collection
What problem, event or insight is the end user trying to solve?
What insight would be most valuable to the customer?
What recommendation or optimisation using the data would be valuable to a customer?
What data needs to be collected?
How often does it need to be collected?
What types of events, predictions, or “optimisations” can develop from the data?
Does data from the device need to be processed to create desired events, predictions or “optimisations”?
Will data and events be combined across devices?
Who else (users, devices) will subscribe to the data?
Security
What risks or undesirable situations can you foresee to protect the customer? How could your product identify these risks?
What are the consequences when a 3th party accesses the data from the device?
How does the data flow from the device to your data center or application? How do you protect each step in this chain?
What device physical-security needs or risks are there?
Insights and recommendations
What ‘math’ do you need for the insight? Write the equations or describe the logic if you can.
Which notifications, logic, ‘math’, or algorithms remain consistent? And which ones need to be configurable and updated?
What is the time range for implementing adjustments or optimisations?
What devices, users or applications need to subscribe to the analysis of the data from the device?
How will they be notified?
Performance
How much data transmits per period of time (minute, day, month).
What happens if data is not collected?
What happens if data is collected, but not transmitted?
What happens if data is transmitted, but not received by the server?
How quickly does data need to be received by the device or server?
Estimate the amount of data transmitted over a period of time (hour, day).
What are the consequences of data not being collected?
What are the consequences of data being collected but not transmitted?
What are the consequences of the device not being connected?
How quick (in seconds) do alerts or adjustments need to be received by the device?
How quick (in second) do alerts or adjustments need to be received by other subscribers?
How close will the devices collecting data or subscribing to analytics be to each other
Environment and Operating Requirements
What operating conditions will the device and sensor be in? Temperature, moisture, pressure, access, and vibrations are example conditions.
How do you power the device? And what happens if power is lost?
Is the device depending on another device for connectivity, power or measurements?
How will the IoT device connect?
How constant does the connection need to be?
How reliable does the connection need to be?
Costs
What is the budget per device in your business case?
What is the budget per device for operational costs in your business case? Think connectivity, batteries, cloud services.
What are the initial costs of getting the solution operational?
What are the operating costs for ongoing maintenance, depreciation and infrastructure?
What’s next?
Completing the questions hopefully helped to start insightful discussions with your team. Now the real work begins. Distill all the answers in a comprehensive set of requirements. If you still find it difficult, continue to break it down in smaller pieces. For example, get started with a requirement list for the device only. This can help force a decision if you need to buy or build a device. Which can lead to a clearer roadmap. The deliverables should help complete your roadmap and IoT strategy.
The list can also have pointed out that you remain to have uncertainties. Get started by eliminating these first. A great way to verify all the answers on this list is to start a small scale proof of concept. There are so many IoT products out there that let you prototype and test your assumptions. We found the best way to keep your project going is doing it while continuing to plan for a larger scale.