Directriz: Decisiones importantes de requisitos
En esta directriz se describen aspectos importantes a tener en cuenta cuando se personalizan los requisitos del proceso.
Relaciones
Descripción principal

Decidir cómo utilizar los productos de trabajo

Decida qué productos de trabajo se utilizarán y cómo se utilizarán.  Además de identificar qué productos de trabajo se utilizarán, también es importante personalizar cada producto de trabajo que se utiliza para que se ajuste a las necesidades del proyecto.  

La tabla siguiente especifica qué productos de trabajo de requisitos se recomiendan y cuáles se consideran opcionales (por ej., sólo se pueden utilizar en ciertos casos). Para consideraciones adicionales sobre la personalización, consulte la sección de personalización de la página de descripción de los productos de trabajo.

Producto de trabajo Objetivo Personalización (Opcional, recomendada)

Producto de trabajo: Modelo de guión de uso (Producto de trabajo: Actor, Producto de trabajo: Guión de uso, Producto de trabajo: Paquete de guiones de uso)

Los guiones de uso se utilizan para definir requisitos de funcionamiento.

Recomendada para la mayoría de proyectos.

Los guiones de uso son el método que se recomienda para capturar requisitos de funcionamiento.

Producto de trabajo: Guión gráfico

Para los proyectos con requisitos de comportamiento que no se comprenden realmente, se debe tener en cuenta el guión gráfico como medio para obtener requisitos.

Opcional

Se pueden utilizar otras técnicas de obtención de requisitos.

Producto de trabajo: Glosario Garantiza que todas las personas que trabajan en el proyecto utilizan un vocabulario común.

Recomendada para la mayoría de proyectos.

Producto de trabajo: Atributos de requisitos Una base de datos de atributos de requisitos ayuda a asegurar que se dé prioridad, se realice el seguimiento y se rastreen los requisitos correctamente.

Opcional

No obstante, en proyectos que no tengan demasiados requisitos, una base de datos de atributos de requisitos puede no ser estrictamente necesaria.

Producto de trabajo: Plan de gestión de requisitos Describe la información que se va a recopilar y los mecanismos de control que se van a utilizar para medir, informar y controlar los cambios en los requisitos de producto. Se necesita un documento separado si lo justifica la complejidad de gestión de los requisitos o la visibilidad del cliente.

Opcional

Para los proyectos que no tienen demasiados requisitos se puede utilizar una propuesta ligera para la gestión de requisitos que se puede documentar directamente en el plan de desarrollo de software.

Para los demás proyectos, se puede seleccionar y seguir una propuesta más rigurosa, pero crear una descripción breve o no formal. Por ejemplo, el conjunto de atributos de requisitos que recopilar se puede documentar implícitamente por medio de la configuración de las herramientas.

Producto de trabajo: Especificación de los requisitos de software Se utiliza para recopilar el conjunto de todos los requisitos en un documento formal que se proporciona al cliente.

Opcional

En los proyectos menos formales, no se necesita un documento formal.

Producto de trabajo: Solicitudes de los interesados Captura todas las solicitudes efectuadas sobre el proyecto, así como el modo en el que se han tratado dichas solicitudes.

Recomendada para la mayoría de proyectos.

Con el objeto de construir un sistema que satisfaga las necesidades de los interesados, es importante solicitar y revisar sus solicitudes.

En muchos proyectos las solicitudes de los interesados se gestionan, simplemente, como una categoría de Solicitudes de cambio. En otros proyectos, las solicitudes de los interesados sólo se capturan de modo informal.

Producto de trabajo: Especificaciones suplementarias Se utiliza para capturar requisitos no funcionales.

Recomendada para la mayoría de proyectos.

 Producto de trabajo: Visión Captura restricciones de diseño y requisitos de muy alto nivel a fin de que el lector comprenda el sistema que se va a desarrollar.

Recomendada para la mayoría de proyectos.


Decidir qué informes utilizar

La decisión sobre los informes que utilizar depende de las herramientas de informe disponibles para el proyecto. Si hay herramientas de generación de informes disponibles, se recomienda generar informes para productos de trabajo orientados a bases de datos o a modelos como, por ejemplo, Guiones de uso y Actores. Los informes existentes de la configuración de RUP están disponibles en las páginas de descripción de productos de trabajo y agrupados en el producto de trabajo pertinente del navegador de árbol.

Decidir cómo mantener los "requisitos de entrada"

Esta sección sólo se aplica si un documento estándar o de especificación, o un contrato formal impone requisitos al esfuerzo de gestión de requisitos. Se hace referencia al mismo como "especificación de requisitos de entrada".

Durante el esfuerzo de requisitos, se capturan los requisitos en los documentos siguientes: Producto de trabajo: Visión, Producto de trabajo: Solicitudes de los interesados, Producto de trabajo: Modelo de guión de uso, Producto de trabajo: Especificaciones suplementarias.

Decida si se debe mantener la especificación de los requisitos de entrada. ¿Va a volver atrás y actualizar la especificación de los requisitos de entrada cuando descubra que un requisito es incorrecto, erróneo o incompleto? También debe decidir cómo mantener  rastreos o referencias entre la especificación de requisitos de entrada y Producto de trabajo: Guión de uso.

Elija una, o una combinación de varias de las estrategias siguientes:

  • No actualizar la especificación de los requisitos de entrada. Dejar que los Guiones de uso y la Especificación suplementaria especifiquen lo que va a hacer el sistema en lo sucesivo.
  • No actualizar la especificación de los requisitos de entrada, sino mantener la Rastreabilidad de los guiones de uso.
  • Actualizar la especificación de los requisitos de entrada con todos los costes y trabajo implicados.
  • Dejar que la especificación de los requisitos de entrada evoluciones en una Especificación suplementaria que contenga requisitos. Los requisitos de entrada funcionales, simplemente, se transfieren a los guiones de uso.

En la mayoría de proyectos hay un gran número de requisitos incorrectos, erróneos o incompletos, por lo que no tiene sentido mantener la especificación de los requisitos de entrada original. Muy pocos proyectos tienen clientes que deseen pagar el trabajo de actualizar la especificación de los requisitos de entrada con la nueva información revelada durante el modelado del guión de uso.

No se preocupe por este tema demasiado pronto. Al principio de un proyecto, la gente cree en las especificaciones de los requisitos iniciales, sin embargo, después de trabajar hasta el final el área del problema con un guión de uso, muchas personas tienen una idea bastante diferente de la especificación de los requisitos iniciales.

Decidir cómo aprobar guiones de uso

Decida cómo aprobar los guiones de uso. Limitando el número de guiones de uso que debe revisar el cliente formalmente, se puede ahorrar mucho tiempo. Quizá el cliente acepte revisar formalmente sólo un subconjunto de todos los guiones de uso.

Elija una o más de las estrategias siguientes:

  • Todos los guiones de uso pasan revisiones externas formales con representantes que son externos al proyecto.
  • Algunos guiones de uso secundarios se pueden aprobar de modo simplificado, en una revisión formal interna o informal.

Los guiones de uso secundarios son aquellos que son esenciales para el sistema, pero no para la tarea del usuario principal. Por ejemplo, guiones de uso relacionados con la administración y el mantenimiento del sistema, por ejemplo, añadir usuarios al sistema, cambiar su autoridad y hacer copias de seguridad. El sistema no funciona sin estos guiones de uso, aunque no son de interés principal para los usuarios importantes.

La estrategia que utilice depende de la relación con el cliente. ¿Confían en que se ocupe del soporte de los guiones de uso correctamente sin un proceso de aprobación formal? ¿Aunque podría ahorrar mucho tiempo, logrará la calidad correcta del modelo de guión de uso?

Nota: Es posible que una solución al problema sea implicar al cliente en el esfuerzo de los requisitos. Al implicar a los representantes del cliente, ellos pueden aprobar o recomendar a otros clientes y, al implicar al cliente, el proyecto gana credibilidad.

Para obtener más información sobre los niveles de revisión, consulte la Directriz: Niveles de revisión.