Requisitos de un producto IoT

01 · Punto de partida

Del prototipo al producto

Con los cinco temas anteriores ya sabés qué es un sistema IoT, qué casos de uso existen, cómo se elige una plataforma y cómo se hace el primer dispositivo conectado. Falta decidir qué tiene que cumplir el producto para considerarlo bien hecho. Es una decisión previa al diseño, y la más barata de corregir: cambiar una línea de un documento cuesta minutos, cambiar una placa ya fabricada cuesta semanas y dinero.

Muchos proyectos IoT fracasan no porque la tecnología no funcione, sino porque nadie escribió que «el sensor debe durar tres años con una pila» hasta que se descubrió, con mil unidades instaladas, que duraban cuatro meses. Los requisitos convierten expectativas vagas en compromisos verificables.

Este tema cierra el bloque de fundamentos. A partir del siguiente empezamos con los sensores y la adquisición de datos, y todo lo que veamos se evaluará contra los requisitos que acá aprendés a escribir.

02 · Panorama

Las familias de requisitos

Los requisitos funcionales dicen qué hace el producto («mide la humedad y avisa si baja de un umbral»). Los no funcionales dicen cómo debe hacerlo: con qué autonomía, a qué costo, con qué seguridad. En el IoT los no funcionales deciden el éxito, porque casi cualquier cosa se puede conectar y lo difícil es hacerlo bien durante años.

No todas las familias pesan igual en todos los productos. En un enchufe de venta masiva manda el costo; en una alarma, la confiabilidad; en un sensor agrícola, la autonomía; en un dispositivo médico, la seguridad y la normativa. Una buena práctica es ordenarlas por prioridad al principio, porque cuando choquen se necesita un criterio para desempatar.

03 · Redacción

De un deseo a un requisito medible

Un requisito útil se puede verificar: alguien puede hacer una prueba y responder «cumple» o «no cumple». «Debe ser rápido» o «debe durar mucho» no sirven, porque no hay prueba posible. La fórmula es simple: qué magnitud, en qué condiciones, con qué valor, y cómo se comprueba.

Los números de un requisito no son caprichos: salen de la ficha del caso de uso (tema 3), de los cálculos de energía (tema 4) y de la conversación con quien usará el producto. Y los percentiles ayudan: «en el 95 % de los casos» es más honesto y más fácil de cumplir que «siempre».

04 · Compromisos

Cuando los requisitos chocan

Casi todos los requisitos se contradicen en algún punto. Lo valioso es verlo a tiempo y decidir con conciencia.

Frente a un choque hay tres respuestas posibles: cambiar la tecnología (otra radio, otro chip), cambiar el diseño (decidir en el equipo, enviar menos) o cambiar el requisito (conversar si 3 años de batería eran en realidad 2). La peor es no darse cuenta del conflicto hasta que el producto está fabricado.

05 · Costos

El costo que no se ve

Cuando alguien pregunta «¿cuánto cuesta el dispositivo?», casi siempre piensa en el costo de los materiales. Pero el costo real de un producto IoT es el costo total de propiedad (TCO): todo lo que hay que pagar desde que se diseña hasta que se retira. El hardware es la parte visible, la punta del iceberg.

Dos ideas separan a quien tiene experiencia en productos de quien no. La primera: los costos recurrentes pesan más que los de compra. Un plan de datos de unos pocos centavos por mes, multiplicado por miles de equipos y por años, supera al costo de fabricarlos. La segunda: una visita técnica cuesta como decenas de dispositivos. Por eso un chip más caro que alarga la batería, o un diseño que evita cambiarla, suele ser un ahorro neto.

También cuentan los costos fijos: el desarrollo del firmware, los ensayos, las herramientas de producción y las certificaciones se pagan una sola vez, pero hay que repartirlos entre las unidades que se fabriquen. Con cien unidades pesan más que todos los componentes juntos; con diez mil, casi desaparecen.

06 · Ciclo de vida

Todo el ciclo de vida

Un producto IoT no termina cuando sale de la fábrica. Cada etapa de su vida impone requisitos propios, y olvidarse de alguna es un error caro.

1. Fabricación. Disponibilidad de componentes durante toda la producción, pruebas al final de la línea, carga de claves e identidad únicas.
2. Instalación y alta. Cómo se pone en marcha y se registra el equipo, quién lo hace y con qué herramienta.
3. Operación. Monitoreo de la flota, detección de equipos mudos, respuesta ante fallas, gestión de los datos y de la privacidad.
4. Actualización. Corrección de errores y vulnerabilidades durante años, de forma remota, segura y reversible.
5. Fin de vida. Qué pasa cuando se deja de fabricar o de dar soporte: baja de los equipos, reciclaje de baterías y electrónica, borrado de los datos del usuario.

Una pregunta incómoda pero necesaria: ¿qué pasa si la empresa cierra su servicio? Un termostato que depende de una nube del fabricante se vuelve inútil el día que ese servicio se apaga. Algunos productos prevén un modo local o publican el protocolo para que el equipo siga funcionando. Es un requisito de ciclo de vida que conviene decidir al principio y comunicar con honestidad.

07 · Verificación

Del requisito a la prueba

Los requisitos cumplen su función solo si se conectan con el resto del trabajo. La trazabilidad consiste en poder seguir cada requisito hasta la decisión de diseño que lo satisface y hasta la prueba que lo comprueba, y también en sentido inverso: ¿para qué requisito sirve este componente?

Con esta tabla viva, cualquier cambio queda bajo control: si se propone reemplazar el chip por uno más barato, la tabla muestra de inmediato qué requisitos se ponen en riesgo y qué pruebas hay que repetir. Sin ella, los cambios producen sorpresas.

08 · Analogía con programación

Calcular el costo total en Python

El costo total por equipo se puede calcular con una función. Cada radio tiene un costo extra de hardware, un plan de datos mensual y una duración de batería. A eso se suman los costos del volumen: los materiales bajan al aumentar la cantidad, y el desarrollo de 40.000 dólares se reparte entre todos los equipos. Cada cambio de batería requiere una visita de 30 dólares más 5 de la batería nueva. El programa descompone el costo en seis partes y muestra qué porcentaje es hardware.

import math

NRE = 40000                       # desarrollo, certificación y herramientas de producción (una sola vez)
BOM = {100: 18, 1000: 14, 10000: 11}          # costo de materiales del equipo según el volumen (dólares)
# radio: (costo extra de hardware, plan de datos por mes, años que dura la batería)
RADIOS = {"wifi": (0, 0.0, 1.0), "lora": (4, 0.15, 5.0), "celular": (8, 0.80, 2.0)}
PLATAFORMA_MES = 0.12             # nube y plataforma por dispositivo y por mes
VISITA = 30                       # costo de mandar a alguien a cambiar la batería
BATERIA = 5                       # costo de la batería de reemplazo
SOPORTE_ANIO = 1.2                # fallas, reclamos y reposiciones por dispositivo y por año


def costos(radio, flota, anios):
    hw_extra, plan, autonomia = RADIOS[radio]
    reemplazos = max(0, math.ceil(anios / autonomia) - 1)
    return {
        "hardware": BOM[flota] + hw_extra,
        "desarrollo": NRE / flota,
        "datos": anios * 12 * plan,
        "plataforma": anios * 12 * PLATAFORMA_MES,
        "baterías": reemplazos * (VISITA + BATERIA),
        "soporte": anios * SOPORTE_ANIO,
    }


print("radio     flota  años   hardware  total por equipo   hardware/total")
for radio in RADIOS:
    for flota, anios in [(1000, 5), (100, 5), (10000, 5), (1000, 10)]:
        c = costos(radio, flota, anios)
        total = sum(c.values())
        print(f"{radio:<9} {flota:>5}  {anios:>4}  {c['hardware']:>8.2f}  {total:>16.2f}   {100 * c['hardware'] / total:>9.0f} %")

print()
for radio in ("wifi", "lora"):
    c = costos(radio, 1000, 5)
    print(radio, "- 1000 equipos, 5 años:", ", ".join(f"{k} {v:.2f}" for k, v in c.items()))

Resultado con los valores iniciales: un equipo con Wi-Fi y batería de un año, en una flota de 1000 durante 5 años, cuesta 207,20 dólares, de los cuales el hardware es 14 (7 %): 140 son cambios de batería y 40 es el desarrollo repartido. Con LoRa, que dura cinco años con una batería, cuesta 80,20 (hardware 18, el 22 %): se ahorran 127 dólares por equipo, 127.000 en la flota. Con celular cuesta 193,20 por los 48 dólares de datos y dos cambios de batería. Con solo 100 equipos, el desarrollo pesa 400 dólares por equipo y el total sube a 571,20 con Wi-Fi; con 10.000, el desarrollo baja a 4 dólares y LoRa llega a 41,20 con el hardware en el 36 %.

Dos hallazgos del modelo: el hardware rara vez supera un tercio del costo total, y la elección de la radio decide el costo de la operación más que el precio de los componentes. Un diseñador que solo mira la lista de materiales optimiza la parte menos importante.

09 · Exploración interactiva

Cuánto cuesta un dispositivo, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior. Elegí la radio, la cantidad de equipos y la vida útil. Las barras apiladas comparan las tres radios con los mismos parámetros, descompuestas en seis partes; la radio elegida va resaltada. Los costos son valores didácticos, no precios de mercado.

Recorrido guiado

1. Con los valores iniciales (Wi-Fi, 1000 equipos, 5 años), calculá. El total es US$ 207,20 y el hardware, apenas el 7 %. La barra naranja de baterías domina: son 4 visitas por equipo.
2. Cambiá a LoRa. El total baja a US$ 80,20 aunque el hardware sea más caro (18 contra 14 dólares). Alargar la batería ahorró más que todo el costo de los componentes.
3. Probá Celular: US$ 193,20. Aparece una barra de datos de 48 dólares y dos cambios de batería. Está cerca del Wi-Fi, pero con otra distribución.
4. Con LoRa, bajá la flota a 100 equipos: el desarrollo pasa a 400 dólares por equipo y el resultado es «Pesa el desarrollo». Con 10.000, ese costo es de 4 dólares y el total cae a US$ 41,20.
5. Con LoRa y 10.000 equipos, el hardware es el 36 % y el resultado dice «Manda el hardware»: recién ahí vale la pena regatear componentes.
6. Con Wi-Fi y 1000 equipos, cambiá la vida útil a 10 años: sube de 207 a 395 dólares. Cada año extra agrega costos recurrentes; el hardware sigue siendo el mismo y su parte baja al 4 %.

10 · Método de trabajo

El documento de requisitos de una página

No hace falta un documento de cien páginas. Una hoja bien armada alcanza para que todo el equipo, y quien contrata, hablen de lo mismo. Completala en este orden:

1. Propósito. En una frase, para quién es el producto y qué problema resuelve.
2. Prioridades. Ordená las familias de requisitos de la más a la menos importante. Esto resuelve los desempates.
3. Requisitos medibles. Para cada familia relevante, escribí números y condiciones.
4. Cómo se verifica cada uno. Prueba, instrumento y criterio de aceptación.
5. Conflictos detectados y la decisión tomada en cada uno.
6. Costo objetivo total por equipo, con el reparto entre compra y operación.
7. Ciclo de vida. Cuántos años de soporte y actualizaciones, y qué pasa al terminar.
8. Supuestos y riesgos. Lo que se da por cierto y habría que revisar si cambia (por ejemplo, la cobertura de la red).

Revisalo con quien usará el producto antes de empezar el diseño y cada vez que algo importante cambie. El objetivo no es la burocracia sino que las sorpresas aparezcan en el papel y no en el campo.

11 · Comprensión

Confusiones frecuentes

12 · Práctica guiada

Predecí antes de comprobar

1. Hacerlo medible

Reescribí estos deseos como requisitos medibles y proponé cómo comprobarlos: (a) «el sensor tiene que aguantar la intemperie»; (b) «la alarma debe sonar rápido»; (c) «tiene que ser fácil de configurar».

2. La punta del iceberg

Un equipo con Wi-Fi y batería de un año cuesta 14 dólares de hardware y 207,20 en total durante 5 años en una flota de 1000. ¿Qué porcentaje es el hardware? ¿Cuál es la parte mayor?

3. El ahorro de una radio de largo alcance

Pasar de Wi-Fi a LoRa baja el total de 207,20 a 80,20 dólares por equipo. ¿Cuánto se ahorra en una flota de 1000, y en qué se basa?

4. El peso del desarrollo

El desarrollo cuesta 40.000 dólares. ¿Cuánto es por equipo con 100, 1000 y 10.000 unidades? ¿Qué conclusión sacás?

5. Disponibilidad

Un servicio promete 99,9 % de disponibilidad anual. ¿Cuántas horas de caída por año admite? ¿Y con 99 %?

6. Requisitos contradictorios

Un cliente pide: «batería de 5 años, una lectura enviada por celular cada minuto y una batería de 2000 mAh». ¿Es posible? Con 0,08 mAh por mensaje, calculá.

13 · Síntesis

Ideas para recordar

¿Listo para el bloque 2?

Antes de avanzar, escribí el documento de requisitos de una página para un producto que imagines (puede ser un sensor de tu casa): propósito, prioridades, cinco requisitos medibles con su prueba, un conflicto detectado y el costo total estimado a cinco años. Si cada requisito se puede comprobar, ya pensás como diseñador de producto.

En el próximo tema empezamos el bloque de sensores IoT y adquisición de datos con los sensores para IoT: temperatura, humedad, presión, luz, movimiento y calidad del aire, qué miden, con qué precisión y a qué costo energético.