Asignación de requisitos a componentes

La SP 2.2 en RD establece la necesidad de asociar los componentes del producto con los requisitos que los definen. De manera que los componentes que se van derivando tienen un requisito asociado que los define. 
Por su parte en REQM, en la SP 1.4 se establece la trazabilidad bidireccional de los requisitos hacia las entidades que se obtienen. Lo cual constituye una herramienta fundamental en la evaluación de impacto de los cambios a requisitos. 
¿Cuál es el sentido de cada práctica, si aparentemente ambas llevan una relación de requisitos a componentes?

Asociación de requisitos en RD
Las prácticas de RD tienen que ver con la ingeniería de requisitos. Los requisitos se: identifican, documentan, descomponen, revisan y validan. Desde esta perspectiva la necesidad de asociar los componentes a los requisitos, justifica la existencia del componente en si. Si estamos desarrollando un componente que no tiene una razón de ser no se tendría que trabajar en él. 
La asociación de requisitos permite, a partir de la arquitectura establecida para el producto, determinar qué características de desempeño del producto, restricciones de diseño, forma y función cumple un componente. Esto ya sea de manera compartida, donde cada componente contribuye con una parte de ese requisito en específico, o en su conjunto con todos los componentes. También es importante identificar las dependencias entre asociaciones, de manera que si existe un cambio se puedan identificar todos los componentes que son afectados.
Esta práctica es fundamental en desarrollos que integran componentes no necesariamente de ingeniería de software, donde componentes físicos de ingeniería de sistema cumplen con los requisitos definidos.
Trazabilidad de requisitos en REQM
La trazabilidad de requisitos permite evaluar el impacto de un cambio en los requisitos que están comprometidos. Esta práctica tiene más función de gestión, que de ingeniería, ya que ayuda a la adecuada gestión de los cambios. Permite establecer una asociación de los requisitos fuente a los requisitos de bajo nivel y viceversa. De manera que se pueda identificar si todos los requisitos fuente han sido considerados y si todos los requisitos de bajo nivel están relacionadas con un requisito fuente.
Esta trazabilidad puede considerar también las entidades derivadas de los requisitos como productos de trabajo, componentes, funciones, objetos, interfaces, procesos o individuos. En ciertos casos es importante conocer las dependencias entre entidades al mismo nivel, que podrían ser las interfaces, en este caso se habla de una trazabilidad horizontal. Este tipo de información es fundamental para garantizar las prácticas de PI.
Las herramientas de trazabilidad de requisitos pueden ayudar a cumplimentar ambas prácticas, pero es importante entender la intención de cada una para un adecuado uso de la información.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: