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.
|
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.
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.
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.
|