The functional view of developing an IoT service

IoT enabled cars

This article is part of our series, “Four keys to developing a winning IoT service.” For more from this series, visit William Dupley.

In the first article of this series, I discussed the first step in developing an effective IoT service. The second key to a successful IoT implementation is to define the functional requirements that the IoT system must deliver to address the business challenges.

Early in my career, I managed a software development group, and we used to kid each other by saying, “You start coding and I’ll go out and find out what the customer wants.” Of course, this is ridiculous. However, unfortunately, it has become an all-too-common behavior. Often programmers fall into the trap of assuming that they know what their users need before they’ve even done the research. Developing a robust functional view minimizes that risk.

Let’s use smart cities as an example. When it comes to smart cities, we have a general idea of the expectations: safer streets, faster commutes, constant monitoring of public spaces, city data that is available for citizens to access, and all while lowering costs and conserving energy. In order to achieve all these goals, we need to identify the function that each IoT application will serve.

IoT Functional Requirements

Functional requirements define the products and features that the IoT system must deliver. There are seven categories of requirements to consider when developing any IoT initiative for private or public institutions.

  1. Feature requirements: What are the high-level expectations of the solution? This is the general goal of the initiative.
  2. Business requirements: This is a description of the new or improved capabilities the user must be able to do as a result of the new system.
  3. Nonfunctional requirements: This defines the service level expectations of the system such as availability, reliability, scalability, security, backup, and disaster recovery.
  4. Functional requirements: This is a description of the functions that the user requires from the system. It should contain a process model, data entities, user stories, and use cases.
  5. System design requirements: This defines the interaction of the IoT system with other systems.
  6. IoT data management requirements: This describes how the data will be ingested and analyzed. The following four areas need to be defined:  
    • Ingestion: how the data will be collected and integrated into one data source
    • Analytics: defines the predictive analytics models and data analysis requirements
    • Communications: who needs to be informed when an alarm is identified
    • Persistence: defines how long the data needs to be retained
  7. Reports and dashboards: This defines the reports and dashboards that users need to rapidly analyze and respond to data collected.

Smart City example

Let’s put these in the context of smart cities. We can use IoT applications to monitor parking on streets and in public parking lots.

  1. Feature requirements: To enable smart parking capability
  2. Business requirements: Enables parking enforcement officers to quickly identify parking offences
  3. Nonfunctional requirements: Service is available 7 days a week, 24 hours a day
  4. Functional requirements: Allows for remote monitoring and advanced analytics to assist in predictive maintenance (see user story description below)
  5. System design requirements: IoT system must work with the existing enterprise resource planning (ERP) system
  6. IoT data management requirements:
    • Ingestion: capture video feeds from intersections, capture license plates of vehicles
    • Analytics: identify drivers and number of vehicles parking illegally or driving recklessly
    • Communication: communicates offence to the police
    • Persistence: data must be retained for 10 years
  7. Reports and dashboards: Dashboard presents the number of vehicles parked on the street or in lots and tracks high traffic time periods.  
People studying IoT (Internet of Things) functional model.

User story example

A user story defines what the software needs to accomplish.  The use cases explain how the software interacts with the user, the benefits of the implementation of the technology, and what the user can learn from the data collected. Here is an example of a manufacturing IoT user story:

Title: Remote monitoring and advanced analytics to assist in predictive maintenance

Contributor:   Jim Anderson

Business Issue:   Reduce Maintenance Costs
When a pump fails it takes several hours to restore production. We need to predict pump failure and proactively repair the pump.  

Process Step: Fluid transfer.

Process KPI: Production downtime.

Functional use cases:  

  1. Monitor pump performance data
  2. Develop a predictive model from the data
  3. Implement real-time alarming capability on performance data
  4. Schedule maintenance call based on an imminent failure

Benefits of User Story: We have over 200 pumps on-site. Last year we experienced 100 hours of production downtime due to pump failures. The cost of that downtime was $1 million. Implementing a remote monitoring IoT system with predictive analytics will enable us to reduce this cost.

End User Experience:  Operations will have real-time warnings in the control room when a pump is predicted to fail. This will enable them to proactively schedule a maintenance call.  

Business Gain assessment: High

Achievability: High

A clear functional view with well-articulated user stories will enable a design group to develop a comprehensive IoT architecture correctly the first time. They will be able to select the best IoT software and develop detailed use cases. By developing a comprehensive functional view, you will be able to ensure that you achieve the desired results at the finish line.

Further reading

Read the rest of the articles in this series.
Part 1: Four keys to developing a winning IoT service: Business View
Part 3: Building the software for a successful IoT service
Part 4: Choosing the correct infrastructure for your IoT service
Part 5: Combining IT and operations for a successful IoT service
Part 6: A pilot project is key to implementing your IoT service

About Futurithmic

It is our mission to explore the implications of emerging technologies, seeking answers to next-level questions about how they will affect society, business, politics and the environment of tomorrow.

We aim to inform and inspire through thoughtful research, responsible reporting, and clear, unbiased writing, and to create a platform for a diverse group of innovators to bring multiple perspectives.

Futurithmic is building the media that connects the conversation.

You might also enjoy
person standing in front of a colour spectrum painted on a wall
Dynamic spectrum sharing could be the 5G solution that wireless operators are looking for