Requisitos y especificación

01 · El punto de partida

De la necesidad al requisito

Un proyecto nace de una necesidad, casi siempre expresada en el lenguaje de quien la tiene: «necesito saber si la vacuna se calentó durante el transporte», «quiero que el sensor dure sin tocarlo». Esa frase no es todavía un requisito: no dice cuánto, cuándo ni cómo se comprueba. El trabajo de especificar es convertir necesidades en requisitos verificables, en cuatro pasos que se repiten y se refinan:

1. Identificar a los interesados: quién usa el producto, quién lo instala, quién lo mantiene, quién lo fabrica, quién lo regula, quién lo paga. Cada uno tiene necesidades distintas, y a veces opuestas (el usuario quiere que no haya que tocarlo, el fabricante quiere un precio bajo).
2. Reunir las necesidades con entrevistas, observación del uso real, productos existentes y normativas aplicables.
3. Traducirlas a requisitos: frases precisas y medibles sobre lo que el sistema debe hacer o ser.
4. Validar con los interesados que esos requisitos expresan lo que querían, y verificar más adelante que el producto los cumple.

Conviene distinguir dos preguntas que se confunden. Validar es preguntar «¿estamos construyendo el producto correcto?» (¿esto resuelve de verdad el problema del usuario?). Verificar es preguntar «¿estamos construyendo el producto bien?» (¿cumple lo que dice la especificación?). Un producto puede pasar toda la verificación y fallar la validación, si los requisitos estaban mal. Por eso los errores en esta etapa son los más caros: un requisito equivocado se propaga a la arquitectura, al código y a las pruebas, y se descubre al final, cuando corregirlo exige rehacerlo todo (la misma economía de la pirámide del tema 47).

El modelo en V resume la idea: cada nivel de la especificación (a la izquierda) tiene un nivel de prueba que lo verifica (a la derecha). Los requisitos del sistema se verifican con pruebas del sistema; las necesidades del usuario, con la aceptación. Si un requisito no se puede probar, el diagrama se rompe en ese punto: un requisito sin una forma de verificarlo es solo un deseo.

02 · Una clasificación útil

Tipos de requisitos y restricciones

Los requisitos se agrupan según qué describen. La clasificación no es un trámite: sirve para no olvidarse de familias enteras, y en los sistemas embebidos son las no funcionales las que más suelen olvidarse y las que más determinan el diseño.

La última fila merece una distinción. Un requisito describe una necesidad que el sistema debe satisfacer, sin imponer cómo. Una restricción es una decisión de diseño que viene impuesta desde afuera (por el cliente, la normativa, la empresa, un componente que ya está comprado) y reduce el espacio de soluciones. Una restricción legítima se anota como tal, con su origen. El error frecuente es el contrario: un requisito disfrazado de solución («debe usar un STM32L4 con RTOS») que nadie justifica y que cierra opciones antes de entender el problema. Ante esa frase conviene preguntar «¿para qué?»: si la respuesta es «para que dure dos años con dos pilas», ese es el verdadero requisito y el microcontrolador queda como decisión del diseño (tema 49).

03 · El arte de escribir poco y claro

Escribir un buen requisito

Un buen requisito tiene cinco cualidades, y las dos primeras son las que más fallan:

• Verificable y medible: contiene una cantidad con su unidad (menos de 200 ms, ±0,5 °C, 2 años) o un criterio de aceptación que se pueda comprobar con sí o no. Las palabras como «rápido», «fácil», «suficiente», «adecuado», «eficiente», «robusto» o «de bajo consumo» no se pueden verificar y deben reemplazarse por números.
• Sin ambigüedad: una sola interpretación posible. «El sistema debe enviar los datos cuando sea necesario» deja la pregunta más importante sin respuesta (¿cuándo es necesario?).
• Atómico: una sola idea por requisito. «Debe medir y registrar la temperatura y enviar los datos» son tres requisitos; si uno no se cumple, no se puede decir cuál.
• Obligatorio o no, de forma explícita: «debe» para lo obligatorio, «debería» para lo deseable. Mezclarlos («podría», «puede») deja sin saber si es un compromiso.
• Identificable y rastreable: con un código único (R-014) que no cambia aunque se reordene el documento, para poder enlazarlo con el diseño y las pruebas.

Existen plantillas que ayudan a la disciplina. Una muy usada es EARS (Easy Approach to Requirements Syntax), que da una forma fija según el tipo de situación:

La Parte 2 del programa y el laboratorio de este tema implementan un revisor automático con cinco comprobaciones sencillas (sin palabras vagas, con una cantidad medible, con «debe» y sin formas débiles, de una sola idea y de no más de 30 palabras) y lo aplican a ocho requisitos. «El sistema debe ser rápido y fácil de usar» obtiene 60 de 100; «el equipo debería tener bajo consumo», 40; «el dispositivo debe medir la temperatura entre −40 °C y 85 °C con un error máximo de ±0,5 °C», 100. Es una herramienta limitada (no entiende el significado), pero detecta en un instante los defectos de redacción más comunes, y ilustra una idea valiosa: la calidad de un requisito se puede chequear.

04 · Hacer cuentas antes de diseñar

Derivar números: los presupuestos

Los requisitos de sistema son pocos y de alto nivel («dos años de autonomía»). El diseño necesita números más pequeños: ¿cuánta corriente media puede consumir el circuito?, ¿cuánta flash hace falta?, ¿cuánto tiempo puede tardar cada etapa? Esos números se derivan con cuentas sencillas, y el conjunto de ellos es el presupuesto del sistema: un reparto del recurso limitado entre los subsistemas. Hacer esas cuentas al principio detecta si el requisito es posible antes de gastar un mes de diseño.

La Parte 1 del programa parte del requisito «el registrador debe funcionar al menos 2 años con 2 pilas AA» (1875 mAh de capacidad nominal) y lo convierte en un número de diseño:

• Energía utilizable: no se aprovecha toda la capacidad nominal (la tensión de corte, la temperatura y la corriente de descarga la reducen); con el supuesto de un 80 %, son 1500 mAh.
• Corriente media máxima: 1500 mAh en 2 años (17 520 h) son 85,62 µA en total.
• Autodescarga: las pilas pierden carga solas (el valor que usamos en los temas de energía, 5,70 µA); quedan 79,92 µA para el circuito.
• Margen de diseño: el diseño debe cumplir con holgura, porque los consumos reales superan a los estimados (el bloque de energía mostró cómo). Con un margen del 50 %, el objetivo de diseño es 79,92 / 1,5 = 53,28 µA.

Con la autodescarga, la vida estimada es de 7,97 años, muy por encima de los 2 exigidos: el requisito es factible con holgura con este reparto. Y la cuenta sirve también al revés: si todo el margen restante (44,24 µA) se dedicara a la radio, y cada reporte cuesta 28 mA × 0,4 s = 11,2 mC, se podría transmitir como máximo un reporte cada 253 s (14,2 por hora). Ese número es una consecuencia del requisito de energía y se le puede dar al cliente: «si necesita reportes más frecuentes que uno cada cuatro minutos, hay que cambiar la batería o la autonomía». Es una conversación mucho más productiva que descubrirlo al final.

El mismo método vale para los otros recursos:

• Memoria de datos: «guardar 30 días de datos» con una medida de 8 bytes cada 60 s son 43 200 registros, 345 600 bytes (unos 337 KB): no cabe en una flash interna de 256 KB, y eso decide si hace falta una memoria externa (tema 41) antes de elegir el chip.
• Tiempo: «alarma en menos de 5 s» se descompone en la cadena medir, procesar, transmitir, con el peor caso de cada etapa (ver sección 8).
• Costo: el costo de materiales máximo se reparte entre el microcontrolador, la batería, la radio, el sensor y la caja.
• Memoria de programa y RAM: un presupuesto de flash y de pila por módulo, que la integración continua vigila (temas 28 y 47).

Y siempre con la misma disciplina: las hipótesis se escriben (80 % utilizable, 3 mA de medición) y se marcan como hipótesis, para reemplazarlas por mediciones apenas haya un prototipo (tema 36). Un presupuesto es un documento vivo: cada vez que una medida real lo contradice, se corrige el presupuesto, o el requisito, o el diseño.

05 · Cómo se usa de verdad

Escenarios y modos de operación

Una lista de requisitos sueltos oculta algo esencial: cómo se usa el sistema a lo largo del tiempo. Dos herramientas lo sacan a la luz:

• Escenarios o casos de uso: historias breves de una situación concreta, con un actor, un objetivo y los pasos. «El operario de logística activa el registrador, lo coloca en la caja y cierra el contenedor; durante el viaje de 9 días el registrador mide, guarda y, cuando hay cobertura, informa; al llegar, el receptor descarga el historial y el registrador se desactiva.» De un escenario salen requisitos que nadie había pensado: ¿cómo se activa?, ¿qué pasa sin cobertura durante 6 días?, ¿cómo se sabe que terminó?
• Modos de operación: los estados de alto nivel del equipo y qué requisitos valen en cada uno. Un registrador tiene, por ejemplo, almacenado (apagado, sin consumo), activo (midiendo y registrando), alarma (transmitiendo con más frecuencia), descarga (entregando el historial) y falla. Un requisito de consumo de 53 µA vale en el modo activo, no en la descarga.

El conjunto de modos es el esqueleto de la máquina de estados de alto nivel que se refinará en la arquitectura (tema 49) y se implementará como se vio en el tema 24. Escribirlo temprano obliga a decidir cosas como «¿de la alarma se vuelve solo al modo activo, o hay que confirmarlo?», que son requisitos aunque nadie los haya enunciado.

06 · Las fronteras del sistema

Interfaces y entorno

Todo sistema vive rodeado de otros: sensores, usuarios, redes, la fuente de energía, otros equipos. Las interfaces son las fronteras con ese entorno, y especificarlas con precisión evita los malentendidos más costosos (el equipo funciona, pero «no habla» con el de al lado). Un registro de interfaces dice, para cada una:

Las interfaces con el usuario y con el instalador cuentan igual: cuántos botones y LED, qué indica cada color y cada patrón de parpadeo (tema 44), cómo se configura, qué mensaje se muestra ante un error. Y el entorno se especifica con las mismas reglas: rango de temperatura (de −30 a 60 °C), humedad, vibración, caídas, interferencia electromagnética, vida útil. Una frase como «debe funcionar a la intemperie» no se puede diseñar ni probar; «debe funcionar de −30 a 60 °C con humedad relativa de hasta 95 % sin condensación» sí. Cada uno de esos rangos condiciona la elección de componentes (el rango de temperatura de la batería, la deriva del cristal, temas 9 y 34) y define las pruebas ambientales (tema 47).

07 · Seguir el hilo

Verificabilidad y trazabilidad

Para cada requisito hay que decidir cómo se verificará, y hacerlo al escribirlo, no al final. Hay cuatro métodos clásicos:

La trazabilidad es el hilo que une cada requisito con los elementos del diseño que lo implementan y con las pruebas que lo verifican, y también al revés, desde cada elemento de diseño y cada prueba hasta el requisito que los justifica. Se lleva con una matriz (una planilla, una base de datos o las etiquetas de una herramienta de gestión) y responde preguntas que de otro modo no tienen respuesta: ¿está probado cada requisito?, ¿hay código que no responde a ningún requisito (funcionalidad no pedida, que cuesta y puede fallar)?, ¿qué pruebas hay que repetir si cambia este requisito?

La Parte 3 del programa revisa una matriz de seis requisitos (medir la temperatura, error de ±0,5 °C, vida de 2 años, alarma en menos de 5 s, 30 días de datos, actualización segura), cinco elementos de diseño y seis pruebas. El resultado: 5 de 6 requisitos tienen diseño y 5 de 6 tienen prueba (83,3 %); al requisito R6 (actualización segura) no le corresponde ningún diseño ni ninguna prueba; el elemento de diseño D5 (una consola de depuración) no responde a ningún requisito; y la prueba T6 tampoco. Cada una de esas cuatro filas es una pregunta incómoda y valiosa: ¿falta diseñar R6 o se olvidó escribirlo? ¿D5 es un exceso o hay un requisito de diagnóstico sin escribir (y entonces hay que escribirlo, tema 44)?

# Una matriz de trazabilidad mínima: se puede mantener en un archivo de texto bajo control de versiones
REQ    = {"R3": "vida de 2 años con 2 pilas AA", "R4": "alarma en menos de 5 s"}
DISEÑO = {"D2": ["R3"], "D3": ["R4"]}                 # elemento de diseño -> requisitos que implementa
PRUEBAS = {"T3": ["R3"], "T4": ["R4"]}                # prueba -> requisitos que verifica

sin_prueba = [r for r in REQ if not any(r in rs for rs in PRUEBAS.values())]
huerfanas  = [t for t, rs in PRUEBAS.items() if not rs]
assert not sin_prueba and not huerfanas, f"requisitos sin prueba: {sin_prueba}; pruebas sin requisito: {huerfanas}"

Una verificación como la del final puede ejecutarse en la integración continua (tema 47) y romper la compilación si un requisito queda sin prueba. Así la trazabilidad deja de ser un documento que se desactualiza y pasa a ser una propiedad que se comprueba.

08 · Cuando los requisitos chocan

Requisitos en tensión, prioridades y cambios

Los requisitos, leídos de a uno, parecen razonables. Leídos juntos, a menudo se contradicen. Detectarlo en el papel es barato; hacerlo con el hardware construido, no. La Parte 4 del programa analiza un caso típico: el registrador debe medir cada 60 s (por energía) y emitir una alarma en menos de 5 s cuando se supera el límite.

• Con medidas cada 60 s el peor caso de latencia de la alarma es 60 + 0,005 + 0,4 = 60,4 s: no cumple los 5 s. Los dos requisitos son incompatibles tal como están escritos.
• Medir cada 2 s todo el tiempo da una latencia de 2,4 s (cumple), pero el consumo sube a 54,44 µA: la vida baja a 2,85 años. Cumple los 2 años, pero supera el objetivo de diseño con margen (53,28 µA): la solución es posible pero sin holgura.
• Medir cada 60 s y cada 2 s solo en una zona de alerta (cuando la temperatura está a menos de 2 °C del límite, un 2 % del tiempo) da 16,55 µA y 7,70 años, con todo dentro del objetivo. Esa solución implica un requisito nuevo que nadie había escrito: el ancho de la zona de alerta depende de la velocidad máxima de cambio de la temperatura (con un supuesto de 0,02 °C/s, en 60 s puede cambiar 1,2 °C; se eligen 2 °C). Es un requisito derivado, que hay que escribir y verificar (¿es realista esa pendiente máxima en un contenedor?).

Esta forma de razonar, leer los requisitos juntos y calcular, es una de las contribuciones más valiosas de la especificación. El resultado puede ser (a) reescribir uno («la alarma en 5 s solo cuando la temperatura esté cerca del límite»), (b) negociarlo con el cliente («¿realmente hacen falta 5 s o alcanzan 60 s?»), (c) aceptar un diseño más costoso. Lo que no se puede es dejar la contradicción sin resolver.

Cuando no cabe todo (el presupuesto, el plazo o el costo no alcanzan), hace falta priorizar. Una clasificación simple y difundida es la de MoSCoW: debe (must: sin esto el producto no sirve), debería (should: importante, pero hay un rodeo), podría (could: deseable si sobra tiempo) y no por ahora (won't: acordado fuera de esta versión). La prioridad se registra junto al requisito, y evita que lo accesorio desplace a lo esencial cuando el calendario aprieta.

Los requisitos cambian: el cliente aprende, el mercado se mueve, una norma se actualiza. El problema no es que cambien sino que cambien sin control. Un proceso mínimo: un cambio se propone por escrito, se analiza su impacto (con la matriz de trazabilidad: qué diseño y qué pruebas toca, cuánto cuesta en tiempo, energía, memoria y costo), se decide quién lo aprueba y se actualizan todos los documentos a la vez. Cada requisito debe poder responder además: ¿por qué existe? Los requisitos sin justificación son los primeros candidatos a eliminarse cuando hay que recortar. Y se anotan los riesgos (¿qué ocurre si la hipótesis de la pendiente máxima es falsa? ¿si la radio consume el doble?) con una acción prevista, porque un presupuesto sin margen es una apuesta.

09 · Comprobar que funciona

Verificación y diagnóstico

La propia especificación se revisa antes de empezar a diseñar. Una revisión con los interesados y con los ingenieros que van a construir y a probar es una de las actividades más rentables de todo el proyecto.

10 · Analogía con programación

Probar el modelo en Python

El programa reúne cuatro piezas del tema: la conversión del requisito «dos años con dos pilas AA» en un presupuesto de corriente, con el reparto entre consumidores y la frecuencia máxima de reportes; un revisor automático de requisitos con cinco comprobaciones y ocho ejemplos; la matriz de trazabilidad con sus huecos; y el análisis de dos requisitos en tensión, la alarma en menos de 5 s frente a la energía.

# Requisitos y especificación: presupuesto de energía derivado de un requisito, revisor de requisitos, trazabilidad y requisitos en tensión.
import re

# ---- Parte 1: de un requisito de vida de la batería a un presupuesto de corriente ---------------------------------------------------------------
CAP_MAH, USABLE, AUTODESC_UA = 1875, 0.80, 5.70                    # 2 pilas AA; SUPUESTO: se aprovecha el 80 % de la capacidad nominal (temperatura, tensión de corte)
VIDA_DIAS, MARGEN = 730, 1.5                                       # requisito: 2 años; margen de diseño del 50 %
horas = VIDA_DIAS * 24
disponible_ua = CAP_MAH * USABLE / horas * 1000
presupuesto_ua = disponible_ua - AUTODESC_UA
objetivo_ua = presupuesto_ua / MARGEN
print("Parte 1: requisito 'vida de al menos 2 años con 2 pilas AA' convertido en corriente media permitida")
print(f"  energía utilizable {CAP_MAH * USABLE:.0f} mAh en {horas} h -> corriente media máxima total {disponible_ua:.2f} µA")
print(f"  menos la autodescarga ({AUTODESC_UA} µA): presupuesto para el circuito {presupuesto_ua:.2f} µA; con margen de {MARGEN}: objetivo de diseño {objetivo_ua:.2f} µA")
def media_ua(i_ma, t_s, periodo_s): return i_ma * t_s / periodo_s * 1000
consumos = {"reposo (sueño profundo)": 2.0, "medir (3 mA, 20 ms cada 60 s)": media_ua(3, 0.020, 60),
            "procesar (4 mA, 5 ms cada 60 s)": media_ua(4, 0.005, 60), "radio (28 mA, 400 ms cada 900 s)": media_ua(28, 0.4, 900)}
total = sum(consumos.values())
for k, v in consumos.items(): print(f"    {k:<36} {v:6.2f} µA")
print(f"    {'total del circuito':<36} {total:6.2f} µA  (objetivo {objetivo_ua:.2f} µA: {'CUMPLE' if total <= objetivo_ua else 'NO CUMPLE'})")
vida_anios = CAP_MAH * USABLE / ((total + AUTODESC_UA) / 1000) / 24 / 365
print(f"  vida estimada con autodescarga: {vida_anios:.2f} años (el requisito pide 2)")
resto = objetivo_ua - (2.0 + consumos["medir (3 mA, 20 ms cada 60 s)"] + consumos["procesar (4 mA, 5 ms cada 60 s)"] + AUTODESC_UA)
reporte_mc = 28 * 0.4
periodo_min = reporte_mc / (resto / 1000)
print(f"  si el resto se dedica a la radio ({resto:.2f} µA), cada reporte cuesta {reporte_mc:.1f} mC: como mínimo un reporte cada {periodo_min:.0f} s ({3600 / periodo_min:.1f} por hora)")

# ---- Parte 2: un revisor automático de la calidad de un requisito -----------------------------------------------------------------------------
VAGAS = {"rápido", "rápida", "rápidamente", "fácil", "suficiente", "adecuado", "adecuada", "adecuadamente", "amigable", "eficiente", "robusto", "robusta",
         "flexible", "óptimo", "óptima", "etc", "apropiado", "apropiada", "normalmente", "generalmente", "grande", "pequeño", "pequeña", "mucho", "poco", "bueno", "buena"}
FRASES_VAGAS = ("bajo consumo", "lo antes posible", "cuando sea necesario", "y/o")
FUERTES, DEBILES = {"debe", "deberá", "deben", "deberán"}, {"debería", "podría", "puede", "pueden", "tendría", "idealmente", "preferentemente"}
def revisar(texto):
    bajo = texto.lower()
    tokens = re.findall(r"[a-záéíóúüñµ°%±]+|\d+(?:[.,]\d+)?", bajo)
    vagas = sorted({t for t in tokens if t in VAGAS} | {f for f in FRASES_VAGAS if f in bajo})
    modales = [t for t in tokens if t in FUERTES]
    debiles = sorted({t for t in tokens if t in DEBILES})
    def inf(t): return len(t) >= 4 and t.endswith(("ar", "er", "ir"))
    compuesto = len(modales) >= 2 or ";" in texto or "además" in tokens or any(inf(tokens[i]) and tokens[i + 1] == "y" and inf(tokens[i + 2]) for i in range(len(tokens) - 2))
    pruebas = {"sin palabras vagas": not vagas, "tiene una cantidad medible": any(t[0].isdigit() for t in tokens),
               "usa 'debe' y no una forma débil": bool(modales) and not debiles, "expresa una sola idea": not compuesto, "no más de 30 palabras": len(tokens) <= 30}
    return 20 * sum(pruebas.values()), pruebas, vagas
EJEMPLOS = ["El sistema debe ser rápido y fácil de usar.",
            "El dispositivo debe medir la temperatura entre −40 °C y 85 °C con un error máximo de ±0,5 °C.",
            "El equipo debería tener bajo consumo.",
            "El firmware debe medir y registrar la temperatura y enviar los datos cuando sea necesario.",
            "El dispositivo debe funcionar con 2 pilas AA durante al menos 2 años.",
            "El sistema debe responder a una orden del usuario en menos de 200 ms.",
            "El sistema debe ser robusto y flexible, etc.",
            "El sistema debe medir la temperatura cada 60 s; además debe guardar 30 días de datos y debe enviar una alarma en menos de 5 s si la temperatura supera el límite configurado por el usuario durante más de 10 minutos consecutivos."]
print()
print("Parte 2: revisor de requisitos (5 comprobaciones de 20 puntos cada una)")
for i, e in enumerate(EJEMPLOS, 1):
    puntos, pruebas, vagas = revisar(e)
    falla = [k for k, ok in pruebas.items() if not ok]
    print(f"  {i}. {puntos:>3} puntos  {e[:70]}{'…' if len(e) > 70 else ''}")
    if falla: print(f"       falla: {'; '.join(falla)}" + (f"  (vagas: {', '.join(vagas)})" if vagas else ""))
promedio = sum(revisar(e)[0] for e in EJEMPLOS) / len(EJEMPLOS)
print(f"  puntaje medio de los 8 ejemplos: {promedio:.1f}")

# ---- Parte 3: matriz de trazabilidad: ¿cada requisito tiene diseño y prueba, y cada diseño y prueba responde a un requisito? ---------------------------
REQ = {"R1": "medir la temperatura", "R2": "error máximo de ±0,5 °C", "R3": "vida de 2 años con 2 pilas", "R4": "alarma en menos de 5 s", "R5": "guardar 30 días de datos", "R6": "actualización segura"}
DISEÑO = {"D1": ["R1", "R2"], "D2": ["R3"], "D3": ["R4"], "D4": ["R5"], "D5": []}
PRUEBAS = {"T1": ["R1"], "T2": ["R2"], "T3": ["R3"], "T4": ["R4"], "T5": ["R5"], "T6": []}
print()
print("Parte 3: trazabilidad entre requisitos, elementos de diseño y pruebas")
for nombre, tabla in (("diseño", DISEÑO), ("pruebas", PRUEBAS)):
    cubiertos = {r for rs in tabla.values() for r in rs}
    sin = [r for r in REQ if r not in cubiertos]
    huerfanos = [d for d, rs in tabla.items() if not rs]
    print(f"  {nombre}: {len(cubiertos)} de {len(REQ)} requisitos cubiertos ({len(cubiertos) / len(REQ) * 100:.1f} %); requisitos sin {nombre}: {sin}; elementos sin requisito: {huerfanos}")

# ---- Parte 4: dos requisitos en tensión: alarma en 5 s y vida de 2 años ------------------------------------------------------------------------------
print()
print("Parte 4: 'alarma en menos de 5 s' frente a 'medir cada 60 s' y a la vida de la batería")
T_CPU, T_RADIO = 0.005, 0.4
for nombre, periodo in (("medir cada 60 s", 60), ("medir cada 2 s", 2)):
    print(f"  {nombre}: latencia de la alarma en el peor caso = {periodo} + {T_CPU} + {T_RADIO} = {periodo + T_CPU + T_RADIO:.3f} s ({'cumple' if periodo + T_CPU + T_RADIO <= 5 else 'NO cumple'} el límite de 5 s)")
radio = consumos["radio (28 mA, 400 ms cada 900 s)"]
medir_rapido = media_ua(3, 0.020, 2) + media_ua(4, 0.005, 2)
total_rapido = 2.0 + medir_rapido + radio
print(f"  medir cada 2 s todo el tiempo: {total_rapido:.2f} µA -> vida {CAP_MAH * USABLE / ((total_rapido + AUTODESC_UA) / 1000) / 24 / 365:.2f} años (cumple los 2 años, pero supera el objetivo con margen de {objetivo_ua:.2f} µA)")
FRAC_ALERTA = 0.02
lento = consumos["medir (3 mA, 20 ms cada 60 s)"] + consumos["procesar (4 mA, 5 ms cada 60 s)"]
adaptativo = 2.0 + (1 - FRAC_ALERTA) * lento + FRAC_ALERTA * medir_rapido + radio
print(f"  medir cada 60 s y cada 2 s solo en la zona de alerta ({FRAC_ALERTA * 100:.0f} % del tiempo): {adaptativo:.2f} µA -> vida {CAP_MAH * USABLE / ((adaptativo + AUTODESC_UA) / 1000) / 24 / 365:.2f} años (dentro del objetivo)")
PENDIENTE = 0.02                                                   # SUPUESTO: la temperatura cambia como máximo 0,02 °C por segundo
print(f"  la zona de alerta debe ser al menos de {PENDIENTE * 60:.1f} °C (lo que puede cambiar la temperatura entre dos medidas lentas de 60 s); se elige 2 °C")

Resultado, parte 1: 1500 mAh utilizables en 17 520 h dan 85,62 µA; descontada la autodescarga de 5,7 µA quedan 79,92 µA; con margen de 1,5, el objetivo de diseño es 53,28 µA. El circuito consume 15,78 µA (2,00 de reposo, 1,00 de medir, 0,33 de procesar y 12,44 de radio) y la vida estimada es de 7,97 años; con el margen restante, la radio podría transmitir como máximo un reporte cada 253 s (14,2 por hora). Parte 2: los ocho requisitos obtienen 60, 100, 40, 40, 100, 100, 60 y 60 puntos (media 70,0). Parte 3: 5 de 6 requisitos tienen diseño y 5 de 6 tienen prueba (83,3 %); R6 no tiene ninguno de los dos, D5 y T6 no responden a ningún requisito. Parte 4: medir cada 60 s da una latencia de alarma de 60,405 s (no cumple 5 s); medir cada 2 s da 2,405 s, consume 54,44 µA y dura 2,85 años; medir lento con zona de alerta del 2 % da 16,55 µA y 7,70 años; la zona de alerta debe ser de al menos 1,2 °C (se elige 2 °C).

Probá cambiar en la Parte 1 el requisito de vida a 5 años o la capacidad utilizable al 60 % y mirá cuánto se encoge el presupuesto; cambiar en la Parte 4 la fracción de tiempo en alerta (FRAC_ALERTA) del 2 % al 30 % y ver cuándo la solución adaptativa deja de convenir; o agregar un requisito nuevo a la matriz de la Parte 3 y ver aparecer el hueco. La lección del programa es que los requisitos se pueden calcular y chequear: unas pocas líneas descubren contradicciones y huecos que en papel quedan escondidos.

11 · Exploración interactiva

El revisor de requisitos

El laboratorio es el revisor de la Parte 2. Elegís uno de los ocho ejemplos o escribís uno propio, y aplica cinco comprobaciones de 20 puntos cada una: sin palabras vagas, con una cantidad medible, con «debe» y sin formas débiles, de una sola idea y de no más de 30 palabras. Marca en rojo lo que falla y explica por qué. Es un revisor superficial: detecta defectos de redacción, no de contenido, y un requisito puede sacar 100 y estar igualmente mal.

Recorrido guiado

1. El ejemplo 1 («debe ser rápido y fácil de usar») saca 60 de 100: usa «debe», es breve y expresa una sola idea según el revisor, pero tiene palabras vagas («rápido», «fácil») y ninguna cantidad. Nadie podría decir si el producto lo cumple.
2. El ejemplo 2 (temperatura entre −40 °C y 85 °C con un error máximo de ±0,5 °C) saca 100: tiene cantidades con unidad, «debe», una sola idea y es corto. Es el modelo.
3. El ejemplo 3 («debería tener bajo consumo») saca 40: tres fallas, la frase vaga «bajo consumo», ninguna cantidad y la forma débil «debería». Compará con el ejemplo 5, «debe funcionar con 2 pilas AA durante al menos 2 años» (100).
4. El ejemplo 4 («debe medir y registrar la temperatura y enviar los datos cuando sea necesario») saca 40: compuesto (tres verbos), con la frase vaga «cuando sea necesario» y sin cantidad. Hay que separarlo en tres requisitos y reemplazar «cuando sea necesario» por un período.
5. El ejemplo 8 (un requisito largo con tres obligaciones, una alarma, un historial y una configuración) saca 60 aunque tiene muchas cantidades: falla porque expresa varias ideas y pasa de 30 palabras. Escribilo como tres requisitos y comprobá que cada uno saca 100.
6. El ejemplo 7 («debe ser robusto y flexible, etc.») saca 60: «robusto», «flexible» y «etc» son palabras vagas y no hay ninguna cantidad. Reemplazalo por criterios comprobables, como los de la sección 3.
7. Escribí uno propio: «El sistema debe enviar la temperatura cada 15 min con un error máximo de ±0,5 °C.» saca 100. Y ahora probá «El sistema debe responder en menos de 1 ms.»: también saca 100, aunque quizá sea irrealizable con el hardware. El revisor mide la forma; la factibilidad se comprueba con las cuentas de la sección 4.

12 · Método de trabajo

Método: especificar con orden

1. Identificá a los interesados (usuario, instalador, fabricante, mantenimiento, regulador) y reuní sus necesidades con entrevistas y observación del uso real.
2. Escribí escenarios de principio a fin (instalar, usar, fallar, mantener, retirar) y de ellos sacá los modos de operación con sus requisitos.
3. Redactá requisitos atómicos y medibles, con «debe», una cantidad y su unidad, un identificador único y la plantilla que prefieras (EARS).
4. Cubrí todas las familias: funcionales, rendimiento, energía, recursos, confiabilidad, ambiente, seguridad informática, mantenimiento, normas. Anotá las restricciones con su origen.
5. Para cada requisito, decidí cómo se verificará (prueba, análisis, inspección, demostración) y con qué criterio de aceptación.
6. Hacé las cuentas: presupuesto de energía con margen, de memoria, de tiempo y de costo. Escribí las hipótesis y marcalas para reemplazarlas por mediciones.
7. Leé los requisitos juntos y buscá contradicciones con números. Resolvelas reescribiendo, negociando o aceptando un diseño más costoso.
8. Especificá las interfaces y el entorno con el mismo rigor: formatos, rangos, unidades, tiempos, errores y condiciones ambientales.
9. Armá la matriz de trazabilidad y verificá que ningún requisito queda sin diseño ni prueba, ni al revés. Si podés, que la integración continua lo compruebe.
10. Priorizá, justificá y controlá los cambios: cada requisito con su porqué y su prioridad, y todo cambio con su análisis de impacto. Validá con los interesados antes de pasar a la arquitectura.

13 · Comprensión

Confusiones frecuentes

14 · Práctica guiada

Ejercicios

1. Reescribir un requisito

Reescribí «el equipo debe ser de bajo consumo y durar mucho» como requisitos verificables, y decidí cómo se verificarían.

2. Presupuesto de corriente

Un sensor con una pila de botón de 225 mAh debe funcionar 3 años. Se aprovecha el 80 % de la capacidad y la autodescarga es de 1 µA. ¿Cuál es la corriente media máxima del circuito y el objetivo de diseño con un margen de 1,5?

3. Cadena de tiempo

Un requisito dice: «la luz debe encenderse en menos de 100 ms tras pulsar el botón». El diseño usa un antirrebote de 20 ms, el pulsador se lee cada 10 ms, el procesamiento tarda 1 ms y la salida 0,1 ms. ¿Cuál es la latencia en el peor caso y cuánto margen queda?

4. Trazabilidad

Un proyecto tiene 12 requisitos y 14 pruebas. Diez requisitos tienen al menos una prueba; tres pruebas no apuntan a ningún requisito. ¿Qué porcentajes salen y qué significan?

5. Memoria de datos

El registrador debe guardar 30 días de datos con una medida de 8 bytes. ¿Cuánta memoria hace falta si se mide cada 60 s? ¿Y si se mide cada 5 min?

6. Requisito o solución

Un cliente pide: «el equipo debe usar un microcontrolador de la familia que ya compramos en grandes cantidades». ¿Es un requisito? ¿Cómo lo registrarías?

15 · Síntesis

Ideas para recordar

¿Listo para el tema siguiente?

Antes de avanzar, tomá un proyecto tuyo y respondé: ¿podés escribir en una página los diez requisitos más importantes, cada uno con un número y un método de verificación?, ¿qué requisito de energía, de memoria y de tiempo cae de ellos y cuánto vale el presupuesto?, ¿hay dos requisitos que, calculados juntos, no caben? Si no podés responder, lo que sigue (elegir el procesador y dividir en módulos) sería diseñar sobre arena.

En el próximo tema usamos esta especificación para diseñar la arquitectura: dividir el sistema en módulos, definir sus interfaces y elegir el microcontrolador con el presupuesto en la mano.