Formular requisitos correctamente (ISO 29148, EARS)

Los buenos requisitos son la base de resultados verificables. La norma ISO/IEC/IEEE 29148 describe qué hace bueno a un requisito y cómo se relacionan los requisitos en varios niveles. El ETRM refleja ambas cosas: con el perfil de proyecto ISO 29148, los enlaces tipados y la revisión de redacción.

Dos niveles: problema y solución

Nivel	Pregunta	Ejemplo del proyecto de ejemplo
Requisito de stakeholder (espacio del problema)	¿Qué quiere conseguir el cliente o el usuario?	«La batería debe poder cargarse en un punto de carga de 350 kW del 10 % al 80 % en un máximo de 20 minutos.»
Requisito de sistema (espacio de la solución)	¿Qué debe lograr técnicamente el sistema para conseguirlo?	«El BMS debe establecer la corriente de carga admisible en función de la temperatura de celda y del estado de carga según el perfil de carga de 800 V.»
Caso de prueba (prueba)	¿Cómo se verifica que se cumple el requisito?	«Carga rápida 10–80 % a 25 °C en el cargador de pruebas, medir el tiempo de carga.»

Los requisitos de sistema se enlazan al requisito de stakeholder con se deriva de; los casos de prueba, con verifica al requisito que demuestran. Así puede ver en todo momento si cada requisito del cliente está implementado y cada requisito de sistema verificado (Trazabilidad).

Características de un buen requisito

La norma nombra características con las que puede evaluar cada requisito individual:

Característica	Pregunta de control
necesario	¿Faltaría algo importante si se eliminara el requisito?
inequívoco	¿Solo se puede entender de una manera?
completo	¿Contiene toda la información, incluidas condiciones y límites con unidades?
singular	¿Contiene exactamente una afirmación?
factible	¿Se puede implementar con un esfuerzo razonable?
verificable	¿Se puede demostrar objetivamente si se cumple?
correcto	¿Refleja correctamente la necesidad?
neutral respecto a la solución (en el nivel de stakeholder)	¿Describe el objetivo y no una solución concreta?

Obligatoriedad

• debe: requisito obligatorio; desviaciones solo mediante solicitud de cambio.
• debería: recomendación u objetivo. No es vinculante como obligación, por eso la revisión de redacción lo señala.
• puede: opción.
• podría y en lo posible no son vinculantes y por tanto no son verificables.

Plantillas de frases con EARS

EARS (Easy Approach to Requirements Syntax) da a las frases una forma fija. Así se ven la condición, el disparador y la respuesta, y se evita la ambigüedad. En el editor inserta los patrones con Plantilla … y sustituye los marcadores entre ángulos.

Patrón	Plantilla	Ejemplo
General	El <sistema> debe <respuesta>.	El BMS debe medir cada tensión de celda con ±2 mV.
Evento	Cuando <disparador>, el <sistema> debe <respuesta>.	Cuando se reciba una señal de choque, el BMS debe abrir los contactores principales en 50 ms.
Estado	Mientras <estado>, el <sistema> debe <respuesta>.	Mientras la temperatura de celda esté por debajo de 0 °C, el BMS debe limitar la corriente de carga a 0,2 C.
Comportamiento no deseado	Si <evento no deseado>, entonces el <sistema> debe <respuesta>.	Si la resistencia de aislamiento cae por debajo de 500 Ω/V, entonces el BMS debe notificar un fallo de aislamiento.
Opción	Donde <característica presente>, el <sistema> debe <respuesta>.	Donde esté instalada la variante de 800 V, el BMS debe admitir la carga a 350 kW.
Combinado	Mientras <estado>, cuando <disparador>, el <sistema> debe <respuesta>.	Mientras el vehículo esté cargando, cuando la temperatura de celda supere 55 °C, el BMS debe reducir a la mitad la corriente de carga.

Errores típicos

Error	Por qué es un problema	Ayuda en el ETRM
Términos vagos («rápido», «fácil de usar»)	no verificables	revisión de redacción, criterio de aceptación como atributo
Varias afirmaciones en un requisito	no se puede mostrar el cumplimiento parcial	indicación «Varias afirmaciones», dividir
Puntos abiertos («TBD»)	aprobación de contenidos poco claros	indicación «Punto abierto», filtro en la tabla
Requisito de sistema sin origen (gold plating)	esfuerzo sin beneficio para el cliente	cobertura «se deriva de», filtro «Enlace que falta»
Requisito sin prueba	cumplimiento no demostrado	cobertura «es verificado por» en los indicadores
Referencias circulares	ya no se puede seguir el origen	los tipos de enlace jerárquicos impiden ciclos

Más ejemplos de redacción por temas en el catálogo de requisitos.