Ingeniería de Requisitos: Definición, Atributos y Gestión de Sistemas Adyacentes

Sistemas Adyacentes y su Impacto en el Alcance del Producto

Los sistemas adyacentes son elementos clave que interactúan con el producto o sistema que se está desarrollando. Estos pueden ser:

• Organizaciones, individuos, sistemas informáticos o elementos tecnológicos, o una combinación de estos.

El alcance del producto viene determinado en gran medida por la interacción y las interfaces con los sistemas adyacentes.

Tipos de Sistemas Adyacentes

Se clasifican según su modo de interacción:

• Sistemas Adyacentes Activos: Por lo general, son seres humanos que inician los eventos del negocio con un objetivo en mente.
• Sistemas Adyacentes Autónomos: La comunicación se realiza por medio de flujos de una sola dirección (sin respuesta o unidireccional).
• Sistemas Adyacentes Cooperativos: Presentan un comportamiento esperado y la comunicación se basa en un modelo de pregunta-respuesta.

Atributos Fundamentales de un Requisito de Calidad

Para que un requisito sea útil y efectivo, debe cumplir con los siguientes atributos:

Completo

Debe incluir toda la información necesaria para su comprensión y desarrollo. Los elementos esenciales son: Id. Requisito, nombre, descripción, tipo, fuente, fundamentos, prioridad y criterio de validación.

Rastreable (Trazable)

Debe poder seguirse su origen y su impacto a lo largo del ciclo de vida del proyecto. La trazabilidad se establece desde el Contexto hasta el Requisito Atómico, pasando por el Evento, el BUC (Caso de Uso de Negocio), el PUC (Caso de Uso de Producto) y los Stakeholders.

Consistente

Implica la definición de los términos esenciales y el uso de estos términos de manera consistente a lo largo de toda la documentación.

Relevante

El requisito debe ser necesario para el producto. Existe un peligro significativo: un requisito puede ser preciso, completo y bien definido, pero si es irrelevante, consume tiempo y presupuesto innecesariamente.

No Ambiguo

Permite desarrollar casos de prueba, de tal manera que se puede verificar que el producto entregado cumple con los requisitos originales.

Requisito vs. Criterio de Validación

Un requisito debe ser verificable. El criterio de validación establece cómo se medirá el cumplimiento del requisito:

• Requisito: El producto debe ser amigable.
• Criterio de Validación: La primera vez que alguien usa el producto, debe ser capaz de crear un seminario en los primeros 30 minutos.

Requisito vs. Solución

Es crucial distinguir entre lo que el usuario necesita (requisito) y cómo el sistema lo implementará (solución).

Ejemplo:

• Requisito: El usuario debe conocer la hora.
• Solución: El sistema debe tener un reloj en la barra de menú.

Errores Comunes en la Especificación de Requisitos

El 'Gold Plating' (Los Dorados)

Se refiere a los requisitos innecesarios que aumentan el coste, pero no la utilidad del producto. Esto conlleva un aumento de los riesgos y un desenfoque en los requisitos priorizados.

El 'Scope Creep' (Corrupción del Alcance)

También conocido como el síndrome del lavadero o arrastramiento del alcance. Se refiere a aquellos cambios no controlados en el alcance de un proyecto, generalmente introducidos de manera informal o silenciosa.

Preguntas de Revisión y Verificación

Revisión Formal de Requisitos Ambigüos

Pregunta: Si se plantea el requisito “El producto debe ser amigable” ¿pasaría una revisión formal? ¿Cómo se podría enunciar para él un criterio de validación?

Respuesta: No, debido a que el requisito es ambiguo; la amigabilidad dependerá del usuario. Un criterio de validación adecuado sería: El usuario debe desempeñarse con habilidad con el producto en menos de 1 hora.

Representación del Ámbito de Negocio

Pregunta: Si deseas representar el ámbito del área de negocio cuyos requisitos se deben capturar, ¿qué diagrama usarías? Elabora un ejemplo de dicho diagrama y describe sus elementos.

Respuesta: Para representar el ámbito del área de negocio se usaría un Diagrama de Contexto. En este diagrama están presentes:

• El área de trabajo (el sistema central).
• Los sistemas adyacentes (nodos conectados).
• Los flujos de información de un evento de negocio (uniones entre nodos y el centro).

Características de una Especificación de Requisitos de Software (ERS)

Una ERS de alta calidad debe cumplir con las siguientes características:

• Completa: Un requisito está completo cuando no necesita ampliar detalles en su redacción, ya que proporciona la información necesaria para su comprensión. La ERS no debe contener secciones de tipo "por determinar".
• No Ambigua: Si todo requisito posee una sola interpretación. El uso de términos como "a veces" o "adecuado" introduce ambigüedad en los requisitos.
• Abstracta: El requisito no debe describir ni incluir restricciones de diseño o arquitectura del sistema, sino centrarse en la necesidad del usuario.