¡Lo primero, primero!

Clic para la sección anterior: Etapa 0

Los requisitos van primero en todo proyecto IoT bien llevado: antes de los esquemáticos, antes del firmware, antes de la primera línea de código. Has decidido que tu idea de producto se queda, y la tentación ahora es lanzarte directamente a construir. Resiste. La Etapa 1 trata de recoger los requisitos, la base de todo lo que viene después. Puede no sonar tan emocionante como encender un circuito nuevo o escribir código, pero piensa en ello como dibujar el mapa antes de zarpar. Los viajes sin mapa son aventureros, desde luego; simplemente rara vez acaban bien.

En la Etapa 1: Requisitos de stakeholders y de sistema, recogemos la entrada de todos los actores clave y definimos exactamente qué estamos construyendo y por qué: qué debe hacer el producto, las condiciones que debe cumplir y las restricciones que debe obedecer. El tiempo invertido aquí se devuelve después. Cada decisión de diseño, cada línea de código y cada prueba posterior se remontará a estos requisitos: son la estrella polar del proyecto. Avanza sin ellos y arriesgas construir lo equivocado, o descubrir tras meses de trabajo que se pasó por alto una función clave o que una suposición era errónea.

En este capítulo desglosamos qué significa capturar requisitos de stakeholders y de sistema: por qué importa esta etapa, los tipos de requisitos a considerar y cómo documentarlos con claridad. También compartimos ejemplos que muestran cómo fijar los requisitos pronto puede hacer o deshacer un proyecto IoT.

¿Qué son exactamente los requisitos?

Entonces, ¿qué queremos decir con «requisitos»? En términos sencillos, son una descripción detallada de qué debe hacer tu producto y bajo qué condiciones debe hacerlo: el reglamento del proyecto, que captura todo lo que se espera del dispositivo antes de construirlo. Si tu producto fuera una historia, los requisitos serían el esquema de la trama: se aseguran de que todos los elementos clave estén definidos para que la historia se sostenga al final.

Los requisitos vienen en algunas variedades, cada una cubriendo un aspecto distinto del producto:

• Requisitos funcionales: lo que el producto debe hacer: sus funciones y comportamientos.
• Requisitos no funcionales: las cualidades y restricciones del producto: qué tan bien rinde, cuánto dura, etc.
• Requisitos de interfaz: cómo interactuará el producto con otros sistemas y con el mundo exterior.

Repasaremos cada categoría en detalle. Por ahora, recuerda que un buen requisito es claro, específico y verificable. «El dispositivo debería ser genial» no ayudará a tu equipo de ingeniería. «El dispositivo deberá medir temperatura de 0 °C a 50 °C con una precisión de ±0,5 °C» sí: cualquiera que lo lea sabe exactamente qué se espera, y luego puedes probar si el dispositivo lo cumple. Ese es el nivel de claridad al que aspirar.

Requisitos funcionales

Los requisitos funcionales describen las funciones, capacidades y comportamientos específicos de tu producto IoT: lo que el sistema debería hacer. Si alguien pregunta «¿qué hace tu dispositivo?», la respuesta es un resumen de sus requisitos funcionales: las acciones y servicios que el dispositivo proporciona al usuario o a otros sistemas.

Para un dispositivo IoT, los requisitos funcionales suelen incluir:

• Sensorización de datos o acciones: ¿qué datos mide el dispositivo, o qué acciones realiza? (p. ej., mide temperatura, abre una válvula, rastrea la ubicación)
• Precisión y rango de los datos: ¿con qué precisión son las mediciones, y en qué rango? (p. ej., mide temperatura de 0 °C a 50 °C con una precisión de ±0,5 °C)
• Frecuencia o temporización: ¿con qué frecuencia realiza su función —actualizaciones cada minuto, cada hora? ¿con qué rapidez debe responder? (p. ej., una lectura cada 10 minutos, o una respuesta en menos de 2 segundos)
• Manejo de datos: ¿qué pasa con los datos —se envían a la nube, se registran en una tarjeta de memoria, se muestran en una pantalla?
• Modos o funciones específicas: por ejemplo, un modo de alarma cuando se cruza un umbral, autocalibración o actualizaciones de firmware over-the-air.

Un ejemplo concreto. Supón que construyes un sensor de temperatura IoT simple para uso doméstico inteligente. Algunos requisitos funcionales podrían ser:

• El dispositivo deberá medir la temperatura ambiente de 0 °C a 50 °C con una precisión de ±0,5 °C.
• El dispositivo deberá tomar una lectura del sensor al menos una vez cada 10 minutos (tasa de actualización).
• Tras cada lectura, el dispositivo deberá transmitir los datos del sensor a un servidor cloud en menos de 30 segundos (latencia de datos).
• El dispositivo deberá parpadear un LED y enviar una alerta si la temperatura supera un umbral definido por el usuario.

Cada uno describe algo que el sistema hace, normalmente redactado como «El dispositivo deberá…» seguido de un comportamiento específico. Ese formato hace que la verificación posterior sea directa: o el dispositivo hace X como se especificó, o no lo hace.

Los buenos requisitos funcionales pintan una imagen clara de las capacidades, para que el equipo de ingeniería sepa exactamente qué implementar. Solo entonces pueden los diseñadores de hardware y software pensar en cómo lograrlo: el qué va primero, y por eso estos requisitos se definen ahora. Sin ellos, puedes acabar con un producto que no cubre lo que el usuario realmente necesita: una elaborada estación meteorológica IoT, digamos, que se envía sin sensor de humedad porque nadie lo escribió. Definir los requisitos funcionales por adelantado captura las funciones imprescindibles antes de que eso ocurra.

Requisitos no funcionales

Los requisitos no funcionales especifican las cualidades, condiciones y restricciones del producto en lugar de sus funciones: qué tan bien rinde, qué tan robusto es y qué límites debe respetar. Establecen las barandillas de la calidad global, y son tan críticos como las propias funciones: mantienen el dispositivo seguro, fiable y práctico en el mundo real.

Consideraciones no funcionales habituales para un dispositivo IoT:

• Consumo de energía y duración de batería: ¿cuánto tiempo debería funcionar el dispositivo con una fuente de energía dada? Por ejemplo, «El producto funcionará con una sola pila AA durante al menos 1 año.» Esto obliga a centrarse en componentes de bajo consumo y una gestión eficiente de la energía.
• Fiabilidad y longevidad: ¿qué robustez debe tener el dispositivo con el tiempo? A menudo se expresa como Mean Time Between Failures (MTBF) o similar: «El dispositivo debería funcionar de forma continua durante al menos 5 años sin un fallo crítico.» Esto influye en la selección de componentes y los márgenes de diseño.
• Seguridad y privacidad: ¿cómo protegerás los datos y la privacidad del usuario? P. ej., «Todas las transmisiones de datos se cifrarán con AES-256» o «Las credenciales de usuario deben almacenarse de forma segura y nunca transmitirse en texto plano.» En el panorama IoT actual, los requisitos de seguridad son esenciales para prevenir brechas.
• Restricciones ambientales y físicas: las condiciones que el dispositivo debe soportar, más los límites de tamaño y peso. «El dispositivo funcionará de −20 °C a +60 °C y será resistente al agua según IP67» asegura que sobreviva a entornos duros; «El dispositivo no pesará más de 100 gramos y cabrá en un espacio de 10 cm × 5 cm × 3 cm» lo mantiene dentro del factor de forma requerido.
• Restricciones de coste: probablemente tengas un coste objetivo: «El coste unitario de fabricación no superará los 50 $.» Esto impulsa compromisos: un componente más barato aquí, una función eliminada allá.
• Cumplimiento regulatorio: muchos productos IoT deben cumplir normas o certificaciones: «El dispositivo debe cumplir las regulaciones CE y FCC para comunicación inalámbrica», o «Debe adherirse a la norma de seguridad ISO 13849» si forma parte de un sistema de máquina. Son requisitos innegociables fijados por normas industriales y de seguridad.

Es una lista larga, pero piensa en los requisitos no funcionales como los atributos de calidad que el producto debe tener. Rara vez aparecen en el folleto de marketing, pero ignorarlos hace fallar al producto de formas menos obvias. Un sensor puede reportar datos perfectamente (¡funcional!) y aun así frustrar a cada usuario porque su batería muere en un día. Un dispositivo puede rendir bien en el laboratorio y aun así caerse al primer ataque porque la seguridad no se incorporó desde el principio.

Definir estas cualidades por adelantado asegura que el producto final no solo sea rico en funciones, sino robusto, usable y viable. Los requisitos no funcionales guían las elecciones de componentes, la arquitectura de software (fiabilidad, seguridad), el diseño mecánico (durabilidad, tamaño) e incluso cómo probarás. Trabajan entre bastidores, pero son esenciales para cumplir las expectativas de los stakeholders y sobrevivir al despliegue en el mundo real.

Requisitos de interfaz

Los requisitos de interfaz definen cómo tu producto se conecta e interactúa con el mundo exterior, física y lógicamente. Las interfaces son los puntos de contacto entre tu dispositivo y todo lo demás: otro hardware, fuentes de alimentación, carcasas, usuarios y sistemas de software. Esta categoría asegura que el dispositivo encaje en su ecosistema previsto y se comunique correctamente dentro de él.

Aspectos cubiertos por los requisitos de interfaz:

• Interfaces eléctricas: cualquier conexión o señal eléctrica. ¿El dispositivo necesita una entrada de alimentación específica (USB-C, terminales de batería)? ¿Emite un voltaje analógico (una señal de 0-5 V) o proporciona una interfaz digital (I²C, SPI, UART) a otro hardware? Un requisito podría ser «El dispositivo tendrá un puerto USB-C para alimentación y conectividad de datos» o «Proporcionará una salida analógica de 0-5 V proporcional a la lectura del sensor.»
• Interfaces de comunicación: cómo habla el dispositivo con la nube, un smartphone u otros dispositivos: redes y protocolos. Por ejemplo, «El dispositivo se conectará a la nube vía Wi-Fi y usará el protocolo MQTT para publicar los datos del sensor», o «Soportará Bluetooth Low Energy (BLE) para comunicarse con una app de smartphone.» Si se necesita una API, especifícala también: «El servicio cloud proporcionará un endpoint REST API para consultar los datos del dispositivo.»
• Interfaces mecánicas: la forma física y el encaje. ¿Qué tamaño puede tener el dispositivo y cómo se monta o encapsula? «La PCB del dispositivo será de 5 cm × 5 cm para caber en una carcasa estándar», o «Tendrá orificios de montaje compatibles con un soporte estilo GoPro.» La protección contra agua y polvo es a la vez un requisito ambiental y una consideración de interfaz mecánica: «La carcasa tendrá grado IP67 de resistencia al agua y al polvo.» El punto es que el dispositivo se integre físicamente donde se supone que debe ir.
• Interfaz de usuario (UI) y controles: elementos con los que interactúa el usuario: botones, pantallas, LEDs. «El dispositivo incluirá un botón físico de reset accesible para el usuario», o «Tendrá un LED indicador que parpadea durante la transmisión de datos.» Estos definen cómo los usuarios obtienen información del dispositivo o le envían comandos.

Fijar los requisitos de interfaz aclara cómo se conectan todas las piezas. Si diseñas un sensor que se acopla a una máquina industrial, un requisito de interfaz mecánica especifica el tamaño y el patrón de orificios para que encaje de verdad. Si el dispositivo va a batería, un requisito de interfaz eléctrica asegura un conector estándar para que el usuario pueda recargarlo fácilmente. Pasa uno por alto y obtienes el resultado clásico: un dispositivo perfectamente bueno al que nadie puede conectarse porque le falta el puerto adecuado.

En resumen, los requisitos de interfaz aseguran que tu dispositivo funcione con su entorno y sus usuarios, ya sea un hogar inteligente, una instalación industrial o una persona con un teléfono. Pasarlos por alto es a menudo la diferencia entre un producto compatible y amigable y uno que causa dolores de cabeza durante la integración.

Involucrar pronto a los stakeholders

¿De dónde vienen todos estos requisitos? No del aire: los recoges de tus stakeholders: todos los que tienen algo en juego en el éxito del producto. Eso incluye a los candidatos obvios, usuarios finales y clientes, pero también a marketing, ventas, ingenieros de distintas disciplinas (hardware, software, firmware), project managers y expertos regulatorios o de cumplimiento. Cada grupo tiene sus propias necesidades y preocupaciones, y los requisitos deberían capturar cada perspectiva crítica.

Identifica a tus stakeholders e involúcralos pronto, porque ellos definen cómo se ve el «éxito». Marketing puede decir: «Tiene que costar menos de 50 $ y durar un año con una carga: es lo que nuestros clientes esperan». Los usuarios finales (o una persona representativa) pueden necesitar que la configuración sea simple y el mantenimiento mínimo. El equipo de software puede necesitar una API robusta para integrarse con una plataforma cloud. El experto en seguridad insistirá en cifrado y autenticación. Un responsable de cumplimiento te recordará los límites de emisión de radio de la FCC o las normas de seguridad eléctrica. Todas estas entradas se convierten en requisitos.

Sacar a la superficie estas necesidades ahora es mucho más barato que después. Sesiones de brainstorming, talleres o simples entrevistas con cada grupo de stakeholders construirán una lista completa. No lo hagas en el vacío: un requisito escrito sin la entrada de los stakeholders puede fallar el blanco. Sáltate al equipo de soporte y podrías pasar por alto «El dispositivo proporcionará un mecanismo de reset para restaurar los valores de fábrica», importante para la resolución de problemas. Sáltate a fabricación y podrías especificar un diseño demasiado caro o demasiado difícil de producir en volumen.

La implicación temprana también crea compromiso. Cuando la gente ve sus preocupaciones reflejadas en los requisitos, apoya el proyecto, y surgen menos sorpresas después. Los stakeholders aportan experiencia; usarla ahora ahorra cambios dolorosos más adelante.

A medida que estas entradas se acumulan, la imagen de los requisitos funcionales, no funcionales y de interfaz necesarios toma forma. Esta etapa es esencialmente tender un puente entre una idea prometedora y un producto claramente definido: los deseos difusos («¡Tiene que ser barato! ¡Tiene que ser seguro! ¡Tiene que hacer X e Y!») se convierten en requisitos precisos con los que los ingenieros pueden trabajar, hablando con las personas adecuadas y haciendo las preguntas adecuadas.

La recogida de requisitos es un deporte de equipo. Junta a los actores clave en la sala —literal o figuradamente— y acordad lo que el dispositivo debe hacer. Cuantos más puntos de vista incorpores ahora, menos puntos ciegos arrastrarás a las etapas posteriores.

Documentar y rastrear los requisitos

Una vez recogidos, los requisitos necesitan escribirse con claridad y organizarse. Un registro bien estructurado mantiene a todos en la misma página y asegura que nada se pierda. En la práctica, los equipos usan distintos métodos:

• Documento formal de requisitos: muchos proyectos crean una System Requirements Specification (SRS) o un Product Requirements Document (PRD): un documento estructurado (a veces siguiendo normas como IEEE 29148) donde se lista cada requisito, a menudo con un identificador único (p. ej., REQ-001: El dispositivo hará X). Los documentos formales convienen a sectores donde se necesita trazabilidad estricta: aeroespacial, automoción, dispositivos médicos.
• Backlog ágil (user stories): algunos equipos, especialmente los ágiles, capturan los requisitos como user stories, epics o elementos en una herramienta como Jira o una wiki. Por ejemplo: «Como propietario de una vivienda, quiero que el sensor me avise cuando la temperatura de mi casa supere los 30 °C para poder encender el aire acondicionado.» Una historia así se descompone en requisitos específicos para el equipo de ingeniería (un requisito funcional para una alerta de sobretemperatura, por ejemplo). Los formatos ágiles son más libres, pero los requisitos subyacentes siguen necesitando ser específicos y verificables.

Elijas el formato que elijas, mantén cada requisito inequívoco y verificable. Evita palabras vagas como «óptimo», «amigable» o «suficiente» sin cuantificar; usa números concretos o criterios claros. En lugar de «la batería debería durar mucho», escribe «la duración de batería será de al menos 12 meses con una sola carga y subidas de datos cada hora.» Ese es un objetivo con el que los diseñadores pueden trabajar, sin conjeturas.

Otro hábito útil: etiqueta cada requisito con cómo lo verificarás después: piensa por adelantado en cómo demostrarás que el producto lo cumple. Métodos de verificación habituales:

• Prueba: probar directamente el dispositivo contra el requisito. (P. ej., medir cuánto funciona con una batería para verificar la duración de 12 meses).
• Análisis: usar cálculos o simulaciones. (P. ej., analizar los algoritmos de cifrado contra los requisitos de seguridad, o calcular el consumo para estimar la duración de batería).
• Inspección: verificar observando o midiendo el producto terminado. (P. ej., medir las dimensiones del dispositivo con un calibre contra el requisito de tamaño, o inspeccionar la PCB buscando el recubrimiento conformal aplicado para la estanqueidad).
• Certificación/Demostración: verificar mediante certificación o cumplimiento demostrado. (P. ej., enviar el dispositivo a un laboratorio para certificar que cumple las normas regulatorias FCC/CE, o ejecutar una prueba de entrada de agua para demostrar el requisito IP67).

Etiquetar el método de verificación por adelantado —algunos equipos añaden una columna «Método de verificación» al documento de requisitos— obliga a redactar cada requisito de forma que pueda demostrarse después. También te ahorra el momento en la fase de pruebas en que alguien pregunta: «Espera, ¿cómo comprobamos si logramos este objetivo difuso?».

Por último, mantén el documento de requisitos actualizado. A medida que el proyecto evoluciona puede que refines o añadas requisitos (idealmente no demasiados, si el trabajo inicial fue exhaustivo). Una lista organizada y versionada —incluso una simple hoja de cálculo o un documento vivo— mantiene a todos alineados sobre los requisitos acordados actuales, y ayuda a los nuevos miembros del equipo a ponerse al día sobre lo que el producto debe hacer.

En resumen: no garabatees requisitos en notas adhesivas y esperes lo mejor. Escríbelos de forma clara y estructurada: un documento formal o un backlog bien mantenido. La claridad ahora previene la confusión después, y planificar la verificación pronto allana el camino a una fase de pruebas más suave.

Cerrando la Etapa 1

Una vez más, antes de seguir: cambiar un requisito tarde es como decidir añadir un dormitorio extra después de construida la casa: posible, pero doloroso y caro. En IoT, «doloroso y caro» puede significar un rediseño completo de la PCB porque se olvidó un sensor, o una revisión mayor del firmware porque no se consideró un caso de uso. Puede significar retrasos, sobrecostes o, en el peor caso, un producto que falla a sus usuarios y stakeholders.

Invertir el esfuerzo ahora en capturar requisitos claros de stakeholders y de sistema da al proyecto su plano y hoja de ruta. Los requisitos se convierten en el punto de referencia para todos los implicados:

• Los ingenieros de hardware los usan para elegir componentes y diseñar circuitos que cumplen las especificaciones.
• Los desarrolladores de software y firmware escriben código para implementar las funciones y el rendimiento especificados.
• Los testers crean planes de prueba directamente a partir de los requisitos: cada requisito verificable se traduce naturalmente en uno o más casos de prueba.
• Los project managers hacen seguimiento del progreso marcando los requisitos cumplidos y asegurándose de que nada crítico se cae.
• Los stakeholders obtienen una visión transparente de lo que el producto hará, y de lo que no.

Cuando aparezcan desacuerdos o ideas nuevas más adelante, el documento de requisitos es la estrella polar que mantiene al equipo alineado. Si alguien propone feature creep a mitad del desarrollo, puedes preguntar: «¿Eso está dentro del alcance según nuestros requisitos acordados? Si no, ¿qué sacrificamos para añadirlo?».

Así que tómate el tiempo de hacer bien la Etapa 1. Trae a los stakeholders, piensa bien las funciones y restricciones, escribe todo con claridad y comprueba dos veces que se sostiene. Iterar sobre una especificación es mucho más barato que iterar sobre un dispositivo físico o una base de código. Haz bien esta etapa y preparas el terreno de todas las que siguen.

Con un conjunto sólido de requisitos de stakeholders y de sistema en la mano, estás listo para avanzar hacia el diseño y la construcción de algo que los cumpla. Y al hacerlo, llevas el mapa contigo: lo primero primero, bien hecho.