DSI-NC02 - 1 / 1 -

Propsito
El prposito 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 planificacin del
contenido tcnico de la iteraciones.
Proveer una base para la estimacin de costo
y tiempo de desarrollo de la herramienta.
Definir una interfaz de usuario para la
herramienta, enfocndose en las necesidades
y objetivos de los usuario (no de los clinetes).
Como resultado de las actividades de este flujo
de trabajo, se desarrolla la visin, el modelo de
casos de uso, los casos de uso que en conjunto,
describen la herramienta a desarrollar.
Tambin se construye un glosario y un prototipo
de la interfaz de usuario.
El documento de visin provee la visin completa
del software a desarrollar y sirve de soporte
contractual entre clientes y desarrolladores. Este
documento es escrito desde la perspectiva de los
clientes enfocndose en las caractersticas
esenciales del software y los niveles aceptables
de calidad.
La visin debe especificar las capacidades
operacionales, perfiles de usuario e interfaz
interoperacional con entidades al exterior de las
fronteras del sistema, donde sea aplicable.
El modelo de casos de uso debe servir como
medio de comunicacin y puede servir como
soporte contractual entre clientes, usuarios y
desarrolladores; proveyendo la funcionalidad (el
cmo) a ser implementada.
El modelo de casos de uso se compone de casos
de uso y actores. Cada caso de uso en el modelo
es descrito en detalle, mostrando pasos a paso la
forma como los actores interactan con el
sistema y cmo responde el sistema.
Actividades
Las principales actividad a desarrollar en este
flujo de trabajo son: "identificad actores y casos
de uso, "priorizar los casos de uso, "detallar los
casos de uso y "modelar y crear el prototipo de
la interfaz de usuario. Todas ellas, acompaadas
de "Capturar el vocabulario comn en la cual se
crea un glosario con los trminos usados en el
negocio.
A continuacin se describen cada una de estas
actividades.
.1Identificar actores y casos de uso
El propsito de esta actividad es :
Describir (outline) la funcionalidad de la
herramienta a implementar.
Definir qu debe manejar la herramienta y
qu se debe manejar al exterior de la misma.
Definir quin y cmo ser la interaccin 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 paso y uno de los ms
importantes a fin de definir los
requerimientos de la herramienta. Cada
elemento externo (persona o software
esencialmente) con el cual deba interactuar
el sistema se define como un actor. Para
ello, se pueden resolver las siguientes
preguntas:
Qu grupo de usuarios requieren ayuda de
R RU UP P : : E Et ta ap pa a d de e R Re eq qu ue er ri im mi ie en nt to os s
Desarrollo de Software I
Notas de Clase No. 2 (DSI-NC02)

Antonio Vlez
antvelez@uvpalmira.edu.co
Universidad del Valle - Palmira

DSI-NC02 - 2 / 2 -
la herramienta para realizar sus tareas ?
Qu grupo de usuarios requieren ejecutar
las funciones principales ?
Qu grupo de usuarios requieren ejecutar
funciones secundarias, como
mantenimiento y administracin ?
Interacta la herramienta con software o
hardware externo ?
En algunas ocasiones es difcil encontrar todos
los actores; al momento de identificar los
casos de uso, se pueden identificar nuevos
actores.
.1.2Encontrar/identificar casos de uso
Una vez se ha hecho una identificacin
preliminar de actores, el siguiente paso
consiste en la identificacin de casos de uso
de la herramienta. Los primeros casos de uso
identificados son preliminares, estos pueden
cambiar a travs del tiempo.
La mejor forma de identificar casos de usos
consiste en identificar lo que cada actor
requiere de la herramienta (para qu la
usar). Para cada actor humano se pueden
hacer las siguientes preguntas:
Cules son las tareas principales que cada
actor desea ejecutar en la herramienta ?
Deben los actores crear, almacenar,
cambiar, eliminar o leer datos almacenados
por la herramienta ?
El actor necesita informacin de la
herramienta acerca de repentinos o
externos ?
Necesita el actor ser informado sobre
ciertas ocurrencia en la herramienta ?
Debe el actor ejecutar tareas de
inicializacin o finalizacin de la
herramienta ?
NOTA: Las nuevas herramientas se construyen
para proveer apoyo, no solo para guardar
informacin.
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 interaccin entre actores y casos
de uso
Tambin es importante identificar la relacin
entre los actores y los casos de uso, para sto
de debe definir una relacin de comunicacin.
.1.4Elaborar el modelo de casos de uso
.2Priorizar los casos de uso
El propsito de esta actividad es:
Definir el conjunto de casos de uso que
representan la funcionalidad central de la
herramienta.
Definir los casos de uso que tienen gran
influencia en la definicin de la arquitectura
del software.
.3Detallar los casos de uso
El propsito de esta actividad es:
Describir el flujo de eventos en detalle, de
forma tal que los clientes, usuarios y
desarolladores los puedan entender.
A fin de lograr dicho propsito, 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 descripcin paso a paso
realizada en la actividad "Identificar actores y
casos de uso, se realiza una descripcin ms
detallada del flujo de eventos, la cual debe
incluir:
Cmo inicia el caso de uso ? El inicio del
caso de uso debe describir claramente la
seal que lo activa. Por ejemplo, "el caso
de uso inicia cuando ...... es activada ...
Cmo termina el caso de uso ? Debe estar
claramente descrita la forma cmo finaliza
el caso de uso. Por ejemplo, "cuando .... es
lanzada, el caso de uso termina.
Cmo es la interaccin 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 sta.
Estructure la descripcin en prrafos, en
DSI-NC02 - 3 / 3 -
donde cada uno exprese una accin en el
formato : "Cuando el actor ..., el sistema
.... Tambin se puede enfatizar la
interaccin escribiendo las seales que el
caso de uso enva y recibe del actor, por
ejemplo : "El caso de uso inicia cuando el
operador activa la seal iniciar.
Cmo el caso de uso intercambia datos con
el actor ? Se debe mencionar los
argumentos de las seales (mtodos), por
ejemplo, "el caso de uso inicia cuando el
usuario se autentifica en el sistema a
travs de su nombre y contrasea.
Cuando el caso de uso repite algn
comportamiento ? Este comportamiento se
puede expresar en lenguaje natural,
aunque se pueden utilizar expresiones
como WHILE, IF-THEN-ELSE, 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 el
caso de uso es iniciado, los subflijos se
pueden combinar de mltiples formas :
El caso de uso puede ser iniciado desde
varias partes. Dependiendo de la seleccin
realizada por el actor.
El caso de uso puede ejecutar algn
subflujo de forma ocacional (flujos
alternos).
El caso de uso puede ejecutar varios
subflujos de forma simultnea.
Se identifican tambin las relaciones de
inclusin y extensin entre casos de uso y
las relaciones de generalizacin 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 interaccin entre estos. Ya que
en al actividad de "Identificar actores y casos
de uso se elabor 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 stos no son tenidos en
cuanta en la descripcin 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-condicin especifica una condicin que
se debe cumplir para poder iniciar el caso de uso.
.3.6Describir las pos-condiciones del caso de uso
Una pos-condicin especifica una condicin en la
cual se encontrar el sistema al finalizar el caso
de uso.


.4Crear un prototipo de la interfaz de
usuario
El propsito 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 caractersticas relacionadas con
cada actor.
Se debe describir las caractersticas de cada
uno de los actores humanos relacionados con
los casos de uso.
DSI-NC02 - 4 / 4 -
Vase el capitulo 9 del libro "Presos de la
Tecnologa de Alan Cooper.
.4.2Elaborar el boceto de la interfaz de usuario.

Bibliografa
[1] Rational Software Corp. The Rational
Unified Process. Informacin obtenida de
la versin de evaluacin que provee
Rational Software Corp.
[2] James Rumbaugh, Ivar Jacobson, Gray
Booch. El Proceso Unificado de Desarrollo
de Software. Libro. Addison Wesley.
[3] James Rumbaugh, Ivar Jacobson, Gray
Booch. El Lenguaje Unificado de
Modelamiento - Manual de Referencia.
Libro. Addison Wesley.
[4] Object Management Group. OMG Unified
Modeling Language Specification. Paper.
Disponible en www.omg.org/uml
Otros documentos de interes.
[5] UML Basic : A Introduction to Unified
Modeling Language. Paper. Disponible en
www.therationaledge.com
IMPORTANTE
Las notas de clase "NO SON, NI REEMPLAZAN la
bibliografa del curso. En ellas, solo encontrar
un resumen de los temas tratados, y deben ser
vistas como gua de estudio y/o trabajo.