disciplina de requisitos de rup
TRANSCRIPT
Ing. MCC Lain J. Cárdenas E. 1
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. 2
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. 3
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. 4
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 Por clientes para describir, o como mínimo para aprobar, la descripción del
comportamiento del sistema.
o Por usuarios potenciales para comprender el comportamiento del sistema.
o Por arquitectos de software para identificar las funcionalidades arquitectónicamente
significativas.
o Por personas que analizan, diseñan e implementan el sistema para comprender el
Ing. MCC Lain J. Cárdenas E. 5
comportamiento del sistema necesario y para perfeccionar la definición del sistema.
o Por diseñadores para identificar clases de los flujos de sucesos de los Casos de uso.
o Por verificadores (que realizan pruebas) como base desde la cual se identifica un
subconjunto de los casos de prueba necesarios.
o Por gestores para planear y valorar el trabajo para cada iteración.
o 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 Nombre: El nombre del caso de uso.
o Descripción breve: Una descripción breve del rol y el objetivo del caso de uso.
o 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.
o 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.
o Condiciones previas: Una descripción textual que define una restricción en el sistema
cuando el caso de uso puede empezar.
o Condiciones posteriores: Una descripción textual que define una restricción en el
sistema cuando los Casos de uso han terminado.
o 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.
o Relaciones: Las relaciones, como asociaciones de comunicación, de inclusión, de
generalización y de ampliación, donde participa el caso de uso.
o Diagramas de actividad: Estos diagramas ilustran la estructura del flujo de sucesos.
o 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. 6
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. 7
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. 8
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.