RUP : Etapa Requerimientos

de

PROPOSITO
El pr6posito del flujo de trabajo "Requerimientos" es: Establecer y mantener un acuerdo entre los clientes, usuarios y desarrolladores sobre lo que debe hacer la herramienta (software a implementar). Definir los limites (delimitar) del sistema Proveer una base para la planificaci6n del contenido tecnico de la iteraciones. Proveer una base para la estimaci6n de costo y tiempo de desarrollo de la herramienta. Definir una interfaz de usuario para objetivos de los usuario (no de los clinetes). la herramienta, enfocandose en las necesidades y

Como resultado de las actividades de este flujo de trabajo, se desarrolla la visi6n, el modelo de casos de uso, los casos de uso que en conjunto, describen la herramienta a desarrollar. Tambien se construye un glosario y un prototipo de la interfaz de usuario.

ACTIVIDADES
Las principales actividad a desarrollar en este flujo de trabajo son:

a) b) c) d)

"identificad actores y casos de uso", "priorizar los casos de uso", "detallar los casos de uso" "modelar y crear el prototipo de la interfaz de usuario".

IDENTIFICAR ACTORES Y CASOS DE USO El prop6sito de esta actividad es :

a) b) c) d)

Describir

(outline)

la

funcionalidad

de

la herramienta a implementar.

Definir que debe manejar la herramienta y que se debe manejar al exterior de la misma. Definir quien y como sera la interacci6n con la herramienta. Crear el modelo de casos de uso (diagramas de casos de uso).

Los pasos a seguir a fin de obtener resultados son: .1.1ENCONTRAR/IDENTIFICAR ACTORES Es el primer requerimientos paso y de la uno de los ms importantes a fin de herramienta. Cada elemento externo (persona definir los o software

esencialmente) con el cual deba interactuar el sistema se define como un actor. Para ello, pueden resolver las siguientes preguntas: Que grupo de usuarios requieren ayuda de
-1/1-

se

DSI-NC02

la herramienta para realizar sus tareas ? Que grupo de usuarios requieren ejecutar las funciones principales ? Que grupo de usuarios requieren ejecutar funciones administraci6n ? secundarias, como mantenimiento y

Interactua la herramienta con software o hardware externo ?

.1.2ENCONTRAR/IDENTIFICAR CASOS DE USO

Cuales son las tareas principales que cada actor desea ejecutar en la herramienta. Deben los herramienta. El actor el el actores crear, almacenar, cambiar, eliminar o leer datos almacenados por la

necesita actor actor

informaci6n ser informado

de

la herramienta acerca de repentinos o externos ?

Necesita Debe

sobre ciertas ocurrencia en la herramienta ? de inicializaci6n o finalizaci6n de la herramienta ?

ejecutar

tareas

NOTA: Las nuevas herramientas se construyen para proveer apoyo, no solo para guardar informaci6n. Con la respuesta a las anteriores preguntas, se obtiene un flujo de eventos que identifican los primeros casos de uso candidatos. No todos son casos de uso separados; algunos pueden ser modelados como variantes (subflujos) de un caso de uso. .1.3Describir la interacci6n entre actores y casos de uso Tambien es importante identificar la relaci6n entre los actores y los casos de uso, para esto de debe definir una relaci6n de comunicaci6n. .1.4Elaborar el modelo de casos de uso .2Priorizar los casos de uso El prop6sito de esta actividad es: Definir el Definir los conjunto casos de de casos que de uso que representan la funcionalidad central de la herramienta.

uso

tienen gran influencia en la definici6n de la arquitectura del software.

.3Detallar los casos de uso El prop6sito de esta actividad es: Describir el flujo puedan entender. de eventos en detalle, de forma tal que los clientes, usuarios y desarolladores los

A fin de lograr dicho prop6sito, se realizan (para cada uno de los casos de uso identificados) las siguientes tareas : .3.1Detallar el flujo de eventos del caso de uso Partiendo de la descripci6n paso a paso realizada en la actividad "Identificar actores y casos de uso", se
DSI-NC02 - 3 / 2 -

realiza una descripci6n mas detallada del flujo de eventos, la cual debe incluir: C6mo inicia el caso de uso ? El inicio del caso de uso debe describir claramente la senal que lo activa. Por ejemplo, "el caso de uso inicia cuando ...... es activada ..." C6mo termina el caso de uso ? Debe estar claramente descrita la forma c6mo finaliza el caso de uso. Por ejemplo, "cuando .... es lanzada, el caso de uso termina". C6mo es la interacci6n entre el actor y el caso de uso ? Para minimizar el riego de falla, describa exactamente lo que reside al interior de la herramienta; y lo que reside al exterior de esta. Estructure la descripci6n en parrafos, en

DSI-NC02 - 4 / 2 -

donde cada uno exprese una acci6n en el formato : "Cuando el actor ..., el sistema ...". Tambien se puede enfatizar la interacci6n escribiendo las senales que el caso de uso envla y recibe del actor, por ejemplo : "El caso de uso inicia cuando el operador activa la senal iniciar". C6mo el caso de uso intercambia datos con el actor ? Se debe mencionar los argumentos de las senales (metodos), por ejemplo, "el caso de uso inicia cuando el usuario se autentifica en el sistema a traves de su nombre y contrasena". Cuando el caso de uso repite algun comportamiento ? Este comportamiento se puede expresar en lenguaje natural, aunque se pueden utilizar expresiones como WHILE, IF-THENELSE, FOR, etc. cuando se dificulte expresar algo, en lenguaje natural. Existen situaciones opcionales en el flujo de eventos ? En ocasiones se le presenta a los actores varias opciones, las cuales pueden ser escritas de la siguiente forma: "El actor puede una de las siguientes opciones: A ... B ... C ..." .3.2Estructurar el flujo de eventos El flujo de eventos de un caso de uso puede ser dividido en varios subflujos. Cuando uso es iniciado, los subflijos se pueden combinar de multiples formas : El caso de uso puede el actor. El El caso caso de de uso uso el caso de

ser iniciado desde varias partes. Dependiendo de la selecci6n realizada por

puede puede

ejecutar ejecutar

algun subflujo de forma ocacional (flujos alternos). varios subflujos de forma simultanea. de inclusi6n y extensi6n entre casos de uso y las

Se identifican tambien las relaciones relaciones de generalizaci6n entre actores.

.3.3Ilustrar las relaciones entre actores y otros casos de uso Se crea el diagrama de casos de uso en donde se muestra los casos de uso, los actores y las relaciones de interacci6n entre estos. Ya que en al actividad de "Identificar actores y casos de uso" se elabor6 un diagrama previo, en esta parte se modifica dicho diagrama con las nuevas consideraciones (modificaciones). .3.4Describir los requerimientos especiales del caso de uso Algunos requerimientos pueden estar relacionados con el caso de uso de manera directa, pero cuando estos no son tenidos en cuanta en la descripci6n detallada, se deben describir como requerimientos especiales (requerimientos no funcionales) del caso de uso. .3.5Describir las pre-condiciones del caso de uso Una pre-condici6n especifica una condici6n que se debe cumplir para poder iniciar el caso de uso. .3.6Describir las pos-condiciones del caso de uso Una pos-condici6n especifica una condici6n en la cual se encontrara el sistema al finalizar el caso de uso.

DSI-NC02 - 5 / 3 -

.4Crear

un

prototipo

de

la

interfaz

de usuario

El prop6sito de esta actividad es: Construir un modelo de la interfaz de usuario que de soporte a las actividades de los usuarios y satisfagan los requerimientos de usabilidad.

Para obtener dicho resultado, se realizan (para cada uno de los casos de uso identificados) las siguientes pasos: .4.1Describir las caracterlsticas relacionadas con cada actor. Se debe describir las caracterlsticas de cada uno de los actores humanos relacionados con los casos de uso.

DSI-NC02 - 6 / 3 -

Vease el capitulo 9 del libro "Presos de la Tecnologla" de Alan Cooper. .4.2Elaborar el boceto de la interfaz de usuario.

Bibliografia
[1] Rational Software Corp. The Rational Unified Process. Informaci6n obtenida de la versi6n de evaluaci6n que provee Rational Software Corp. James Rumbaugh, Ivar Jacobson, Gray Booch. El Proceso Unificado de Desarrollo de Software. Libro. Addison Wesley. James Rumbaugh, Ivar Jacobson, Gray Booch. El Lenguaje Unificado de Modelamiento Manual de Referencia. Libro. Addison Wesley. Object Management Group. OMG Unified Modeling Language Specification. Paper. Disponible en www.omg.org/uml

[2]

[3]

[4]

Otros documentos de interes.

[5] UML Basic : A Introduction to Unified Modeling Language. Paper. Disponible en www.therationaledge.com

lMPORTANTE
Las notas de clase "NO SON, NI REEMPLAZAN" la bibliografla del curso. En ellas, solo encontrara un resumen de los temas tratados, y deben ser vistas como gula de estudio y/o trabajo.

DSI-NC02 - 7 / 4 -