DISCILPLINA DE REQUISITOS DE RUP Esta disciplina explica cmo 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 lmites del sistema (delimitarlo). Proporcionar una base para planificar el contenido tcnico de las iteraciones. Proporcionar una base para la estimacin del coste y del tiempo en que desarrollar el sistema. Definir una interfaz de usuario para el sistema, centrndose en las necesidades y los objetivos de los usuarios.

Para alcanzar esos objetivos, es importante, en primer lugar, comprender la definicin 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 renen 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 informacin (adems de los requisitos del sistema). La disciplina de requisitos est relacionada con otras disciplinas del proceso. La disciplina de Anlisis y Diseo obtiene su principal fuente de informacin de los requisitos. La disciplina de Prueba valida el sistema contra los requisitos (entre otras cosas). La disciplina de Gestin de Cambios y Configuracin 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 Gestin de Proyectos planifica el proyecto y las iteraciones. Los productos de trabajo de los requisitos son importantes fuentes de informacin para las actividades de planificacin 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: Visin Modelo de caso de uso Especificaciones suplementarias Especificacin de requisitos de software Requisito de software Atributos de requisitos Glosario Guin grfico Plan de gestin de requisitos Solicitudes del interesado

Ing. MCC Lain J. Crdenas E.

Figura 1. Relacin de artefactos en la disciplina de requisitos

Niveles de requisitos: Figura 2. Relacin entre niveles de requisitos

Necesidad: un requerimiento de un interesado (Stakeholder). Caracterstica: un servicio proporcionado por el sistema, por lo general formulada por un analista de negocios; un objetivo de una caracterstica es cumplir con una necesidad de los interesados. Caso de uso: una descripcin del comportamiento del sistema en trminos 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 especfica de acciones; un camino especfico a travs de un caso de uso. Caso de prueba: una especificacin de entradas de prueba, las condiciones de ejecucin y los resultados esperados. Ing. MCC Lain J. Crdenas E. 2

El artefacto Visin: Este artefacto proporciona una base de alto nivel, a veces contractual, para los requisitos tcnicos ms detallados que son visibles para los interesados. Especifica en trminos de necesidades y caractersticas de los interesados y captura la "esencia" de la solucin concebida en forma de requisitos de alto nivel y restricciones de diseo que dan al lector una visin general del sistema que se desplegar desde una perspectiva de requisitos de comportamiento. Proporciona informacin de entrada al proceso de aprobacin del proyecto. Comunica los "qu y porqu" fundamentales para el proyecto y es un indicador contra el que deberan 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 coordinacin con los usuarios o clientes interesados se revisar y aprobar el documento para una adecuada gestin de los requisitos. El documento de Visin ofrece una visin completa para el sistema de software que se est desarrollando y da soporte al contrato entre la autoridad de financiacin y la organizacin de desarrollo. Cada proyecto necesita una fuente para capturar las expectativas entre los interesados. Personalice este artefacto segn sea necesario para las necesidades de su proyecto. En general, es una buena prctica que este artefacto sea breve para poder entregarlo a los interesados lo antes posible y para que los interesados lo puedan revisar y absorber fcilmente. Para ello, deben incluirse slo las solicitudes y caractersticas ms importantes para los interesados y evitarse los requisitos detallados. Los detalles se pueden incluir en los otros artefactos de requisitos o en apndices.

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 anlisis, diseo 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 aprobacin, sabe que el sistema es lo que desea el cliente. Tambin 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 arquitectnicamente significativa. Los diseadores utilizan el modelo de caso de uso para obtener una visin general del sistema. Cuando perfeccione el sistema, por ejemplo, necesita documentacin 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 tambin del diseo posterior. Las personas externas al proyecto pero dentro de la organizacin, ejecutivos, y comits 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 informacin de retorno apropiada a los desarrolladores de forma regular. Los diseadores 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 integracin) tan pronto como sea posible. Quienes desarrollarn la versin siguiente del sistema utilizan el modelo de caso de uso para comprender como funciona la versin existente. Los escritores de documentacin 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 comunicacin 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. Crdenas 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 interacta 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 anlisis, diseo, implementacin y prueba del sistema.

Artefactos contenidos: Actor: este artefacto define un conjunto coherente de roles que los usuarios del sistema pueden desempear cuando interactan 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 ms 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 mnimo para aprobar, la descripcin del comportamiento del sistema. Por usuarios potenciales para comprender el comportamiento del sistema. Por arquitectos de software para identificar las funcionalidades arquitectnicamente significativas. Por personas que analizan, disean e implementan el sistema para comprender el Ing. MCC Lain J. Crdenas E. 4

o o o o

comportamiento del sistema necesario y para perfeccionar la definicin del sistema. Por diseadores 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 iteracin. Por escritores de documentacin para comprender el comportamiento del sistema desde la perspectiva de la secuencia de uso que debe describirse en la documentacin (como el manual de usuario del sistema).

Un caso de uso consta principalmente de una especificacin textual (denominada Especificacin de caso de uso) que contiene una descripcin del flujo de sucesos que describen la interaccin entre los actores y el sistema. La especificacin tambin suele contener otra informacin como condiciones previas, condiciones posteriores, requisitos especiales y casos de ejemplo clave. El caso de uso tambin se puede representar visualmente en UML para mostrar relaciones con otros Casos de uso y actores. Una Especificacin de caso de uso puede tener las siguientes propiedades: o o o Nombre: El nombre del caso de uso. Descripcin breve: Una descripcin breve del rol y el objetivo del caso de uso. Flujo de sucesos: Una descripcin textual de lo que hace el sistema respecto al caso de uso (no cmo se resuelven los problemas especficos en el sistema). La descripcin es comprensible para el cliente. Requisitos especiales: Una descripcin 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 diseo o implementacin. Condiciones previas: Una descripcin textual que define una restriccin en el sistema cuando el caso de uso puede empezar. Condiciones posteriores: Una descripcin textual que define una restriccin en el sistema cuando los Casos de uso han terminado. Puntos de ampliacin: Una lista de ubicaciones dentro del flujo de sucesos del caso de uso en el que se puede insertar un comportamiento adicional utilizando la relacin de ampliacin. Relaciones: Las relaciones, como asociaciones de comunicacin, de inclusin, de generalizacin y de ampliacin, 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.

o o o

o o o

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 tamao del proyecto, la experiencia, el conjunto de herramientas, las relaciones con el cliente, etc. Paquete de Casos de uso: este artefacto es una recopilacin de casos de uso, actores, relaciones, diagramas, y otros paquetes; se utiliza para estructurar el modelo de caso de uso dividindolo en componentes ms pequeos.

El artefacto Especificaciones Suplementarias: En este artefacto se capturan los requisitos del sistema que todava 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 estndares de aplicacin Los atributos de calidad del sistema que se debe construir, que incluyen la utilizacin, la fiabilidad, el rendimiento y requisitos de capacidad de soporte Ing. MCC Lain J. Crdenas E. 5

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

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 Especificacin de requisitos de software. La especificacin suplementaria captura todos los requisitos globales del sistema, no solo los funcionales. Existe la creencia errnea 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 Especificacin 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 lnea). De forma similar, algunos requisitos no funcionales slo son aplicables a un caso de uso determinado (o un flujo dentro de un caso de uso, en cuyo caso el requisito debera adjuntarse al caso de uso, de lo contrario el sistema tendra un diseo excesivo. Es recomendable que las especificaciones suplementarias se organicen de acuerdo con las categoras de requisitos FURPS+.

Requisitos Un requisito se define como "una condicin 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 acrnimo FURPS para describir las principales categoras de requisitos con subcategoras, como se muestra a continuacin. Funcionalidad (F) Utilizacin (U) Fiabilidad (R) Rendimiento (P) Soportabilidad (S)

El "+" de FURPS+ le recuerda que debe incluir requisitos como: restricciones de diseo requisitos de implementacin requisitos de la interfaz requisitos fsicos.

Los requisitos funcionales (la F de FURPS+) especifican acciones que debe poder realizar un sistema, sin tener en cuenta las restricciones fsicas. 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 continuacin, tambin se conocen a veces como requisitos no funcionales (la U, R, P, S, y el + de FURPS+). Muchos requisitos no son funcionales y slo describen atributos del sistema o atributos del entorno del sistema. Funcionalidad (F): Los requisitos funcionales pueden incluir: conjuntos de caractersticas posibilidades seguridad Ing. MCC Lain J. Crdenas E. 6

Utilizacin (U): Los requisitos de utilizacin pueden incluir subcategoras como: factores humanos esttica coherencia de la interfaz de usuario ayuda en lnea y segn contexto asistentes y agentes documentacin de usuario materiales de formacin

Fiabilidad (R): Los requisitos de fiabilidad que se deben tener en cuenta son: frecuencia y gravedad del error capacidad de recuperacin previsibilidad precisin tiempo medio entre errores (MTBF)

Rendimiento (P): Un requisito de rendimiento impone condiciones a los requisitos funcionales. Por ejemplo, en una accin dada, puede especificar parmetros de rendimiento para lo siguiente: velocidad eficiencia disponibilidad precisin rendimiento tiempo de respuesta tiempo de recuperacin utilizacin de recursos

Soportabilidad (S): Los requisitos de capacidad de soporte incluyen: comprobabilidad capacidad de ampliacin adaptabilidad mantenimiento compatibilidad capacidad de configuracin capacidad de servicio capacidad de instalacin capacidad de localizacin (internacionalizacin)

Requisito de diseo: Un requisito de diseo, a menudo llamado restriccin de diseo, especifica o restringe el diseo de un sistema.

Ing. MCC Lain J. Crdenas E.

Requisito de implementacin: Un requisito de implementacin especifica o restringe la codificacin o la construccin de un sistema. Los ejemplos son: estndares necesarios lenguajes de implementacin polticas de integridad de bases de datos lmites 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 interaccin

Requisito fsico: Un requisito fsico especifica una caracterstica fsica que debe tener un sistema; por ejemplo, material forma tamao peso

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

Referencias: Peter Zielczynski, Requirements Management Using IBM Rational RequisitePro. 1 edicin. IBM Press, 2008. The Rational Unified Process Product. The browser based online documentation for the RUP. IBM Corporation 2007.

Ing. MCC Lain J. Crdenas E.