Disciplina de Requisitos de RUP

DISCILPLINA DE REQUISITOS DE RUP Esta disciplina explica cómo obtener las solicitudes de los interesados y transformarlas en un conjunto de productos de trabajo de los requisitos que cubran el ámbito del sistema que va a crearse y proporcionen requisitos detallados sobre lo que el sistema debe hacer. La finalidad de la disciplina de requisitos es:      

Establecer y mantener un acuerdo con los clientes y otros interesados acerca de lo que debe hacer el sistema. Proporcionar desarrolladores de sistema con un buen conocimiento de los requisitos del sistema. Definir los límites del sistema (delimitarlo). Proporcionar una base para planificar el contenido técnico de las iteraciones. Proporcionar una base para la estimación del coste y del tiempo en que desarrollar el sistema. Definir una interfaz de usuario para el sistema, centrándose en las necesidades y los objetivos de los usuarios.

Para alcanzar esos objetivos, es importante, en primer lugar, comprender la definición y el ámbito del problema que se intenta resolver con el sistema. Los interesados se identifican y las solicitudes de los interesados se obtienen, se reúnen y se analizan. A partir de ahí se desarrollan los productos de trabajo de los requisitos para describir completamente el sistema (qué va a hacer el sistema) en un esfuerzo que percibe a todos los interesados, incluidos los clientes y los usuarios potenciales, como fuentes importantes de información (además de los requisitos del sistema). La disciplina de requisitos está relacionada con otras disciplinas del proceso.     

La disciplina de Análisis y Diseño obtiene su principal fuente de información de los requisitos. La disciplina de Prueba valida el sistema contra los requisitos (entre otras cosas). La disciplina de Gestión de Cambios y Configuración proporciona el mecanismo de control de cambios para los requisitos. El mecanismo para proponer un cambio es enviar una Solicitud de cambio. La disciplina de Gestión de Proyectos planifica el proyecto y las iteraciones. Los productos de trabajo de los requisitos son importantes fuentes de información para las actividades de planificación de iteraciones. La disciplina de Entorno desarrolla y mantiene los artefactos de soporte que se utilizan durante los requisitos.

Productos de trabajo o artefactos utilizados en la disciplina de Requisitos:          

Visión Modelo de caso de uso Especificaciones suplementarias Especificación de requisitos de software Requisito de software Atributos de requisitos Glosario Guión gráfico Plan de gestión de requisitos Solicitudes del interesado

Ing. MCC Lain J. Cárdenas E.

1

Figura 1. Relación de artefactos en la disciplina de requisitos

Niveles de requisitos: Figura 2. Relación entre niveles de requisitos

     

Necesidad: un requerimiento de un interesado (Stakeholder). Característica: un servicio proporcionado por el sistema, por lo general formulada por un analista de negocios; un objetivo de una característica es cumplir con una necesidad de los interesados. Caso de uso: una descripción del comportamiento del sistema en términos de secuencia de acciones (requisito funcional). Requisito suplementario: otro de los requisitos (por lo general es un requisito no funcionales) que no pueden ser capturados en los casos de uso. Escenario: una secuencia específica de acciones; un camino específico a través de un caso de uso. Caso de prueba: una especificación de entradas de prueba, las condiciones de ejecución y los resultados esperados. Ing. MCC Lain J. Cárdenas E.

2

El artefacto Visión: Este artefacto proporciona una base de alto nivel, a veces contractual, para los requisitos técnicos más detallados que son visibles para los interesados. Especifica en términos de necesidades y características de los interesados y captura la "esencia" de la solución concebida en forma de requisitos de alto nivel y restricciones de diseño que dan al lector una visión general del sistema que se desplegará desde una perspectiva de requisitos de comportamiento. Proporciona información de entrada al proceso de aprobación del proyecto. Comunica los "qué y porqué" fundamentales para el proyecto y es un indicador contra el que deberían validarse todas las decisiones futuras. Otro nombre que se utiliza para denominar este artefacto es el Documento de requisitos de producto. Este artefacto es responsabilidad del Analista de Sistemas quien en coordinación con los usuarios o clientes interesados se revisará y aprobará el documento para una adecuada gestión de los requisitos. El documento de Visión ofrece una visión completa para el sistema de software que se está desarrollando y da soporte al contrato entre la autoridad de financiación y la organización de desarrollo. Cada proyecto necesita una fuente para capturar las expectativas entre los interesados. Personalice este artefacto según sea necesario para las necesidades de su proyecto. En general, es una buena práctica que este artefacto sea breve para poder entregarlo a los interesados lo antes posible y para que los interesados lo puedan revisar y absorber fácilmente. Para ello, deben incluirse sólo las solicitudes y características más importantes para los interesados y evitarse los requisitos detallados. Los detalles se pueden incluir en los otros artefactos de requisitos o en apéndices.

El artefacto Modelo de Caso de Uso: Este artefacto es un modelo de las funciones deseadas para el sistema y su entorno, y sirve como contrato entre el cliente y los desarrolladores. Se utiliza como entrada esencial para las actividades de análisis, diseño y prueba. El Analista de sistemas es el responsable de este artefacto. Las personas siguientes utilizan el modelo de caso de uso:           

El cliente aprueba el modelo de caso de uso. Cuando tenga la aprobación, sabe que el sistema es lo que desea el cliente. También puede utilizar el modelo para discutir el sistema con el cliente durante el desarrollo. Los usuarios potenciales utilizan el modelo de caso de uso para comprender mejor el sistema. El arquitecto de software utiliza el modelo de caso de uso para identificar la funcionalidad arquitectónicamente significativa. Los diseñadores utilizan el modelo de caso de uso para obtener una visión general del sistema. Cuando perfeccione el sistema, por ejemplo, necesita documentación sobre el modelo de caso de uso para ayudarle en ese trabajo. El gestor utiliza el modelo de caso de uso para planificar y hacer el seguimiento del modelado de caso de uso y también del diseño posterior. Las personas externas al proyecto pero dentro de la organización, ejecutivos, y comités directivos, utilizan el modelo de caso de uso para obtener una perspectiva en lo que se ha llevado a cabo. Las personas revisan el modelo de caso de uso para proporcionar la información de retorno apropiada a los desarrolladores de forma regular. Los diseñadores utilizan el modelo de caso de uso como base para su trabajo. Los verificadores utilizan el modelo de caso de uso para planear las actividades de prueba (prueba de caso de uso y de integración) tan pronto como sea posible. Quienes desarrollarán la versión siguiente del sistema utilizan el modelo de caso de uso para comprender como funciona la versión existente. Los escritores de documentación utilizan los casos de uso como base para escribir los manuales de usuario del sistema.

El Modelo de caso de uso debe ser un medio de comunicación que puede servir como contrato entre el cliente, los usuarios y los desarrolladores del sistema sobre la funcionalidad del sistema, que permite: Ing. MCC Lain J. Cárdenas E.

3

 

Que los clientes y usuarios validen que el sistema se convierta en lo que esperaban. Que los desarrolladores del sistema construyan lo que se espera.

El modelo de caso de uso consta de casos de uso y actores. Cada caso de uso del modelo se describe detalladamente, mostrando paso a paso el modo en que el sistema interactúa con los actores y lo que el sistema hace en el caso de uso. Los casos de uso funcionan como hebra unificadora en todo el ciclo vital del software; el mismo modelo de caso de uso se utiliza en el análisis, diseño, implementación y prueba del sistema.

Artefactos contenidos: 

Actor: este artefacto define un conjunto coherente de roles que los usuarios del sistema pueden desempeñar cuando interactúan con este. Una instancia de este artefacto se puede llevar a cabo en un sistema individual o externo.



Caso de uso: este artefacto define un conjunto de instancias de caso de uso, donde cada instancia es una secuencia de acciones que lleva a cabo un sistema que producen un resultado observable de valor para un actor concreto.

El objetivo principal del caso de uso es capturar el comportamiento del sistema necesario desde la perspectiva del usuario final para alcanzar uno o más objetivos deseados. Los casos de uso se utilizan para muchos roles diferentes para muchos objetivos, que incluyen: o o o o

Por clientes para describir, o como mínimo para aprobar, la descripción del comportamiento del sistema. Por usuarios potenciales para comprender el comportamiento del sistema. Por arquitectos de software para identificar las funcionalidades arquitectónicamente significativas. Por personas que analizan, diseñan e implementan el sistema para comprender el Ing. MCC Lain J. Cárdenas E.

4

o o o o

comportamiento del sistema necesario y para perfeccionar la definición del sistema. Por diseñadores para identificar clases de los flujos de sucesos de los Casos de uso. Por verificadores (que realizan pruebas) como base desde la cual se identifica un subconjunto de los casos de prueba necesarios. Por gestores para planear y valorar el trabajo para cada iteración. Por escritores de documentación para comprender el comportamiento del sistema desde la perspectiva de la secuencia de uso que debe describirse en la documentación (como el manual de usuario del sistema).

Un caso de uso consta principalmente de una especificación textual (denominada Especificación de caso de uso) que contiene una descripción del flujo de sucesos que describen la interacción entre los actores y el sistema. La especificación también suele contener otra información como condiciones previas, condiciones posteriores, requisitos especiales y casos de ejemplo clave. El caso de uso también se puede representar visualmente en UML para mostrar relaciones con otros Casos de uso y actores. Una Especificación de caso de uso puede tener las siguientes propiedades: o o o

o

o o o

o o o

Nombre: El nombre del caso de uso. Descripción breve: Una descripción breve del rol y el objetivo del caso de uso. Flujo de sucesos: Una descripción textual de lo que hace el sistema respecto al caso de uso (no cómo se resuelven los problemas específicos en el sistema). La descripción es comprensible para el cliente. Requisitos especiales: Una descripción textual que recopila todos los requisitos, como requisitos no funcionales, sobre el caso de uso, que no se consideran en el modelo de caso de uso, pero que deben cuidarse durante el diseño o implementación. Condiciones previas: Una descripción textual que define una restricción en el sistema cuando el caso de uso puede empezar. Condiciones posteriores: Una descripción textual que define una restricción en el sistema cuando los Casos de uso han terminado. Puntos de ampliación: Una lista de ubicaciones dentro del flujo de sucesos del caso de uso en el que se puede insertar un comportamiento adicional utilizando la relación de ampliación. Relaciones: Las relaciones, como asociaciones de comunicación, de inclusión, de generalización y de ampliación, donde participa el caso de uso. Diagramas de actividad: Estos diagramas ilustran la estructura del flujo de sucesos. Diagramas de casos de uso: Estos diagramas muestran las relaciones que implican al caso de uso.

Algunos proyectos aplican los casos de uso de manera informal para descubrir requisitos, pero documentan y mantienen estos requisitos en otras formas. La forma de personalizar los casos de uso puede depender del tamaño del proyecto, la experiencia, el conjunto de herramientas, las relaciones con el cliente, etc. 

Paquete de Casos de uso: este artefacto es una recopilación de casos de uso, actores, relaciones, diagramas, y otros paquetes; se utiliza para estructurar el modelo de caso de uso dividiéndolo en componentes más pequeños.

El artefacto Especificaciones Suplementarias: En este artefacto se capturan los requisitos del sistema que todavía no se han capturado en los Casos de Uso del modelo de Casos de Uso. El Analista de sistemas es responsable de este artefacto. Estos requisitos incluyen:  

Requisitos legales y normativos, y estándares de aplicación Los atributos de calidad del sistema que se debe construir, que incluyen la utilización, la fiabilidad, el rendimiento y requisitos de capacidad de soporte Ing. MCC Lain J. Cárdenas E.

5



Otros requisitos como los de los sistemas operativos y entornos, la compatibilidad con otro software, y las restricciones de diseño.

Las especificaciones suplementarias son un complemento importante del Modelo de Casos de Uso, puesto que conjuntamente capturan todos los requisitos de software (funcionales y no funcionales) que se deben describir para servir como una completa Especificación de requisitos de software. La especificación suplementaria captura todos los requisitos globales del sistema, no solo los funcionales. Existe la creencia errónea de que todos los requisitos funcionales residen en los productos de trabajo de Caso de uso y que todos los requisitos no funcionales residen en el producto de trabajo de la Especificación suplementaria. Esto no es exactamente así, puesto que algunos requisitos funcionales son aplicables al sistema de forma global (como por ejemplo un requisito de ayuda en línea). De forma similar, algunos requisitos no funcionales sólo son aplicables a un caso de uso determinado (o un flujo dentro de un caso de uso, en cuyo caso el requisito debería adjuntarse al caso de uso, de lo contrario el sistema tendría un diseño excesivo. Es recomendable que las especificaciones suplementarias se organicen de acuerdo con las categorías de requisitos FURPS+.

Requisitos Un requisito se define como "una condición o posibilidad que debe cumplir el sistema". Hay muchas clases diferentes de requisitos. Una de las maneras de categorizarlos se describe como el modelo FURPS+; se utiliza el acrónimo FURPS para describir las principales categorías de requisitos con subcategorías, como se muestra a continuación.     

Funcionalidad (F) Utilización (U) Fiabilidad (R) Rendimiento (P) Soportabilidad (S)

El "+" de FURPS+ le recuerda que debe incluir requisitos como:    

restricciones de diseño requisitos de implementación requisitos de la interfaz requisitos físicos.

Los requisitos funcionales (la F de FURPS+) especifican acciones que debe poder realizar un sistema, sin tener en cuenta las restricciones físicas. Estos requisitos suelen describirse correctamente en un modelo de caso de uso y en Casos de uso. Los requisitos funcionales especifican el comportamiento de salida y entrada de un sistema. Los requisitos que no son funcionales, como los que se listan a continuación, también se conocen a veces como requisitos no funcionales (la U, R, P, S, y el + de FURPS+). Muchos requisitos no son funcionales y sólo describen atributos del sistema o atributos del entorno del sistema. Funcionalidad (F): Los requisitos funcionales pueden incluir:   

conjuntos de características posibilidades seguridad Ing. MCC Lain J. Cárdenas E.

6

Utilización (U): Los requisitos de utilización pueden incluir subcategorías como:       

factores humanos estética coherencia de la interfaz de usuario ayuda en línea y según contexto asistentes y agentes documentación de usuario materiales de formación

Fiabilidad (R): Los requisitos de fiabilidad que se deben tener en cuenta son:     

frecuencia y gravedad del error capacidad de recuperación previsibilidad precisión tiempo medio entre errores (MTBF)

Rendimiento (P): Un requisito de rendimiento impone condiciones a los requisitos funcionales. Por ejemplo, en una acción dada, puede especificar parámetros de rendimiento para lo siguiente:        

velocidad eficiencia disponibilidad precisión rendimiento tiempo de respuesta tiempo de recuperación utilización de recursos

Soportabilidad (S): Los requisitos de capacidad de soporte incluyen:         

comprobabilidad capacidad de ampliación adaptabilidad mantenimiento compatibilidad capacidad de configuración capacidad de servicio capacidad de instalación capacidad de localización (internacionalización)

Requisito de diseño: Un requisito de diseño, a menudo llamado restricción de diseño, especifica o restringe el diseño de un sistema.

Ing. MCC Lain J. Cárdenas E.

7

Requisito de implementación: Un requisito de implementación especifica o restringe la codificación o la construcción de un sistema. Los ejemplos son:     

estándares necesarios lenguajes de implementación políticas de integridad de bases de datos límites de recursos entornos operativos

Requisito de interfaz: Un requisito de interfaz especifica:  

un elemento externo con el que debe interactuar un sistema restricciones de formato, tiempo u otros factores que utilice esta interacción

Requisito físico: Un requisito físico especifica una característica física que debe tener un sistema; por ejemplo,    

material forma tamaño peso

Este tipo de requisito se puede utilizar para representar requisitos de hardware, como las configuraciones de red física necesarias.

Referencias: 

Peter Zielczynski, Requirements Management Using IBM Rational RequisitePro. 1ª edición. IBM Press, 2008.



The Rational Unified Process Product. The browser based online documentation for the RUP. IBM Corporation 2007.

Ing. MCC Lain J. Cárdenas E.

8