Cómo formular requisitos correctamente (ISO 29148)
GeneralEste artículo muestra, mediante un ejemplo ficticio, cómo crear una documentación de requisitos claramente trazable utilizando las funciones de ETRM.
Directrices de la norma ISO 29148
Un error común en ingeniería es mezclar los deseos del usuario con las especificaciones técnicas. Esto da lugar a criterios de verificación poco claros y a costosos ciclos de corrección.
Por ello, la norma ISO 29148 separa estrictamente entre Requisitos de los Stakeholders (mundo del problema) y Requisitos del Sistema (mundo de la solución). En ETRM, utilizamos para ello el cascada digital a través de la nueva función de Red.
1. Los dos mundos de la norma ISO 29148
- Capítulo 3: Requisitos de los Stakeholders (El mundo del problema) ¿Qué quiere conseguir la persona? (Enfoque: Beneficio, cercano a la realidad).
- Capítulo 4: Requisitos del Sistema (El mundo de la solución) ¿Qué debe aportar técnicamente el producto? (Enfoque: Mensurabilidad, cifras, datos, hechos).
2. Ejemplo práctico: "El jardín de la alegría"
Utilizando un sencillo columpio de jardín, mostramos cómo vincular los niveles en ETRM.
Paso A: Definir el origen (#1)
Creamos una estructura basada en la norma ISO 29148, con los requisitos de los stakeholders en el capítulo 3.
- A Lieschen le gustaría columpiarse. Este es el requisito fundamental de los stakeholders.
- Lieschen pesa 25 kg. Aquí utilizamos la etiqueta "Restricción", ya que se trata de una condición de contorno.
- No hay árboles en el jardín. Si no hay árboles disponibles, el conjunto de soluciones se limita a columpios independientes. Por tanto, también es una "Restricción".
- Debe ser seguro. Formulado de forma muy general; dependiendo del diseño, de aquí pueden derivarse distintos requisitos.
Si se fija bien, verá que la numeración de los requisitos no es consecutiva. ¿A qué se debe esto?
El ID del requisito (marcado con el hashtag #) se asigna en el momento en que se crea el requisito en el proyecto. Es único e inalterable. Debido a los desplazamientos dentro de la estructura y a la adición posterior de requisitos, pueden seguirse requisitos que no estén numerados consecutivamente.
Paso B: Derivar y vincular la respuesta técnica
En el capítulo 4 definimos los requisitos técnicos que se derivan de los requisitos de los stakeholders y de las particularidades de la solución técnica. Para reconocer y seguir mejor la relación entre los requisitos de los stakeholders y los del sistema, estos pueden vincularse en ETRM. En la lista de requisitos, la relación padre-hijo se indica mediante flechas. Es decir, si no hay flecha, ¡aún queda trabajo por aclarar!
3. La vista de red
ETRM le ofrece la posibilidad de editar las relaciones entre requisitos mediante arrastrar y soltar o de visualizarlas en una estructura de árbol.
4. Errores metodológicos (No-Gos)
| Error (No-Go) | ¿Por qué está mal? | Solución en ETRM |
|---|---|---|
| Requisitos huérfanos | Requisitos en el cap. 4 sin referencia al cap. 3. | Utilice el filtro "Requisitos no vinculados". |
| Referencias circulares | El #1 necesita al #2 y el #2 necesita al #1. | El editor de red le advierte visualmente de los bucles lógicos. |
| Gold Plating | Características técnicas sin petición del cliente. | Cada requisito del cap. 4 debe tener al menos un "elemento padre" en el cap. 3. |
Conclusión
Gracias a la función de red de ETRM, no es necesario memorizar los ID para comprobar las correlaciones. Las flechas de trazabilidad le muestran de un vistazo si un requisito tiene una base sólida o si está "colgando en el aire".