Uml
Enviado por Programa Chuletas y clasificado en Informática y Telecomunicaciones
Escrito el en 
español con un tamaño de 14,39 KB
CUESTIONARIO “LOS CASOS DE USO”
1.- ¿Qué es un caso de uso?
Es una interacción típica entre un usuario y un sistema de cómputo
2.- ¿Cuáles son las propiedades de los casos de uso?
El caso de uso capta alguna función visible para el usuario
El caso de uso puede ser pequeño o grande
El caso de uso logra un objetivo discreto del usuario
3.- ¿Cómo se obtienen los casos de uso?
Hablando con los usuarios habituales y analizando cada cosa que desean hacer con el sistema. A cada cosa que quieran se le debe poner un nombre y escribir un texto descriptivo breve
4.- ¿Qué son las interacciones con el sistema?
Son cosas que el usuario hace con el sistema. Sirven para la planificación
5.- ¿Qué son los objetivos del usuario?
Es lo que el usuario trata de conseguir. Sirven para considerar formas alternas para el cumplimiento de los objetivos
6.- ¿Cuál es el diagrama que se usa para la representación gráfica de los casos de uso?
El diagrama de casos de uso
7.- ¿Qué es un actor?
Se le llama así al usuario que desempeña ese papel con respecto al sistema. Los actores llevan a cabo casos de uso, un mismo actor puede realizar muchos casos de uso y a la inversa un caso de uso puede ser realizado por varios actores
8.- ¿Qué son los extends y uses?
Son relaciones entre los casos de uso
9.- ¿Cuándo se usan los extends?
Cuando se tiene un caso de uso que es similar a otro pero que hace un poco más. Esto se puede abordar poniendo la conducta normal en un caso y la conducta inusual en cualquier otro lado. La idea es ir preguntándose que puede fallar en cada etapa
10.- ¿Cuándo ocurren las relaciones uses?
Cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar la descripción de tal conducta
11.- ¿En qué radica la diferencia entre extends y uses?
En la intención. En sus vínculos con los actores. En la relación extends los actores tienen que ver con los casos de uso que se están extendiendo, es decir, un actor dado se encargará tanto del caso de uso base como de las extensiones. En las relaciones uses no hay un actor asociado con el caso de uso común.
12.- ¿A qué se llama escenario?
Un escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso
13.- ¿Para qué se usan los casos de uso?
Los casos de uso son una herramienta esencial para la captura de requerimientos, la planificación o el control de proyectos iterativos
CUESTIONARIO CASOS DE USO (2)
“Un instrumento para el modelado de procesos de negocios”
1.- ¿Qué son los casos de uso?
Son una técnica para especificar el comportamiento de un sistema, es decir, una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa.
2.- ¿Qué es un evento?
Es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder
3.- ¿Cuáles son las diferencias entre los casos de uso y los eventos?
Los eventos se centran en describir que hace el sistema cuando el evento ocurre, mientras que los casos de uso describen cómo es el diálogo entre el usuario y el sistema
Los eventos son “atómicos”, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. Un caso de uso puede agrupar a varios eventos.
Lo importante para los eventos es qué datos ingresan al sistema o salen de él, para los casos de uso, el detalle de la información que se intercambia es secundaria
4.- ¿Qué técnicas combinan los casos de uso?
Combina el concepto de evento del análisis estructurado con una técnica de especificación de requerimientos que dice que se deben escribir todos los requerimientos en un manual de usuario. La idea es escribirlos desde la perspectiva de quien usará el sistema no del que lo construirá.
5.- ¿Cómo son los casos de uso con respecto al diseño?
Son independientes del método de diseño y de implementación que se utilice, lo cual da más flexibilidad al método
6.- ¿Qué es un actor?
Es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema. Los actores son externos al sistema
7.- ¿Cuál es la diferencia entre usuario y actor?
Un actor es una clase de rol y un usuario es una persona que cuando usa el sistema asume un rol. Un usuario puede acceder al sistema como distintos actores
8.- ¿Qué es equivalente a los actores?
Los perfiles de usuario
9.- ¿Cuál es el primer paso para utilizar la técnica de casos de uso?
Identificar a los actores
10.- ¿Cómo se representan gráficamente los casos de uso?
Se representan con un óvalo con el nombre en su interior, este nombre debe estar expresado con un verbo en gerundio, seguido por el principal objeto del sistema que es afectado por el caso. El nombre siempre debe estar expresado desde el punto de vista del actor y no del sistema
11.- ¿Cuáles son las características de los casos de uso?
Están expresados desde el punto de vista del actor
Se documentan con texto informal
Describen lo que hace el actor y el sistema, pero se enfocan en la interacción
Se inician por un único actor
Están acotados al uso de una determinada funcionalidad diferenciada del sistema
12.- ¿Cómo diferenciar las funciones del sistema?
Como regla general, una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función.
13.- ¿A qué se refiere con que los casos de uso están documentados en un texto informal?
A que se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema, pero aparece un problema como hacer con un caso de uso para especificar el comportamiento interno si este no es trivial… para eso se usa una notación llamada “Diagrama de Actividad”. Otra limitación es que no hay una sintaxis clara para indicar decisiones e iteraciones.
14.- ¿Qué son las alternativas?
Son las desviaciones del curso normal del caso de uso.
15.- ¿Cuáles son las características de las alternativas?
Representan un error o excepción en el curso normal del caso de uso
Tienen sentido sólo dentro del contexto del caso de uso en el que ocurren
16.- ¿Para qué sirve la modularización de los casos de uso?
Sirve para organizar una especificación de los casos de uso, esto sirve para evitar redundancia y facilitar su comprensión.
17.- Dé las características de las extensiones (relaciones de extensión)
Representan una parte de la funcionalidad del caso que no siempre ocurre.
Son un caso de uso en sí misma.
No necesariamente provienen de un error o excepción.
18.- ¿Son diferentes las alternativas a las extensiones? ¿Por qué?
Si son diferentes, porque las extensiones son casos de uso en sí mismas, mientras que las alternativas no, además, una alternativa es un error o excepción, mientras que una extensión puede no serlo.
19.- ¿Cómo saber si algo opcional es realmente una extensión?
Como regla aproximada se puede pensar que si algo opcional debe ser expresado con más de un paso entonces es 8una extensión.
20.- ¿Cuáles son las características de las relaciones de uso?
Aparecen como funcionalidad común luego de haber especificado varios casos de uso.
Los casos usados son casos de uso en sí mismos.
El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones que son opcionales.
21.- ¿Qué hacer cuando la funcionalidad es común a varios casos de uso pero al mismo tiempo es opcional?
Es mejor que éstas se especifiquen como extensiones, para remarcar así la opcionalidad
22.- ¿Qué es un caso de uso abstracto?
Es un caso de uso que no es implementable por sí solo, sólo tiene sentido cuando es parte de otros casos
23.- ¿Qué es un actor abstracto?
Es el actor que participa de los casos de uso abstractos, que reúne características comunes a todos los actores de los casos de uso que lo usan
24.- ¿Cómo se relacionan los actores concretos con los abstractos?
Mediante la herencia. Los actores concretos heredan al actor abstracto
25.- ¿Cuál es la ventaja que presenta el uso de la herencia?
Que en el análisis de requerimientos se evita la redundancia y se simplifica la especificación y los gráficos de casos de uso
26.- ¿Cuáles son los tipos de casos de uso?
Esenciales o de trazo grueso v/s de implementación o de trazo fino
Casos de uso temporales
Casos primarios v/s casos secundarios
27.- Explique cada uno de ellos
Esenciales o de trazo grueso v/s de implementación o de trazo fino: Al identificar los casos de uso en trazo grueso la idea es ignorar detalles de la interacción entre el sistema y el actor, se incluyen sólo las alternativas más relevantes, es decir, se hace una descripción gruesa. Esto sirve para tomar mejores decisiones con los usuarios sobre qué casos de uso implementar en cada fase. Los casos de uso de trazo fino son aquellos que se especifican una vez que se ha tomado la decisión de implementarlos, acá se incluyen detalles sobre la forma de la interfaz en la descripción del caso, se incluyen otras alternativas, errores o excepciones del sistema. Hay 2 tipos de errores o excepciones, los que provienen de las definiciones del negocio y las que vienen del procesamiento interno del sistema. En el de trazo fino se especifica con más detalle el comportamiento del sistema
Casos de uso temporales: Son los casos de uso en los que una determinada funcionalidad se inicia por el paso del tiempo. Cuando se especifican los casos de uso de trazo fino se debe expresar cuál es el momento del tiempo en el que se inicia el caso.
Casos primarios v/s secundarios: los casos primarios son los que son muy importantes y deben ir siempre, mientras que los secundarios son los que no se corresponden con procesos del negocio, y cuya ejecución sólo es necesaria para que el sistema funcione normalmente
28.- ¿Cuáles son los pasos a seguir para aplicar la técnica de análisis de requerimientos con casos de uso?
Identificar los actores: Identificar todos ellos que son críticos para un buen análisis de requerimientos. Identificar todos los usuarios que tiene el sistema. Este proceso se debe ir repitiendo a medida que se avanza en la descripción de los casos de uso
Identificar los principales casos de uso de cada actor: Nombrar los principales casos de uso de cada actor, sin especificar las acciones dentro de éstos.
Identificar nuevos casos a partir de los existentes: para identificarlos se puede usar la misma técnica para identificar eventos en el análisis estructurado, técnica que está basada en el análisis de 4 situaciones posibles a partir de los requerimientos ya identificados
Variaciones Significativas de casos de uso existentes: si hay 2 casos de uso similares como un único caso en el texto del caso tendremos muchos “SI PASA X, HAGO A, SI NO, HAGO B. Si hay 2 casos de uso con funcionalidad en común, se puede ocupar la relación de uso
Casos de uso Opuestos: hay dos formas de encontrarlos. La primera es buscar la función opuesta a la descrita por el caso. La otra forma es pensar en la negación de la acción principal del caso de uso
Casos de uso que preceden a casos existentes: acá la pregunta que se debe hacer es ¿Qué es lo que tiene que ocurrir antes de este caso de uso?
Casos de uso que suceden a casos existentes: ¿Qué ocurre después de este caso de uso?
Crear descripciones de casos de uso de trazo grueso: se deben ir documentando todos los casos de uso
Definir prioridades y seleccionar casos de la primera iteración: después de documentar los casos de uso es conveniente definir las prioridades de los casos de uso. Para esto suele ser útil usar 3 categorías: imprescindible (son aquellos que si no se implementan, hacen que el sistema no tenga sentido), importante (son los que harían que el usuario se sintiera decepcionado si no se implementan) y deseable (Son aquellos que el usuario querría tener si hubiese tiempo disponible). Al evaluar un requerimiento se debe analizar su costo o complejidad
Escribir los casos de trazo fino y crear prototipos de interfaces: la idea es crear un prototipo visual de la implementación de los casos. Al hacer el prototipo se debe tener en cuenta que no debe ir código en él, y que la idea es que el usuario tenga una idea de cómo se verá el sistema, no que apruebe todas las pantallas
29.- ¿Cuáles son los gráficos a utilizar?
Un gráfico de casos de uso no debe tener más de 15 casos.
Si se debe particional el gráfico se puede hacer por actor.
Si las relaciones de uso y las extensiones entran en el diagrama principal y cumplen la primera regla deben quedarse ahí.
Si las relaciones de uso no entran en el diagrama principal se deben mostrar en gráficos, teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama.
Si hay un caso que es usado por la gran parte de los otros casos, se debe evitar mostrarlo en el gráfico principal.
30.- ¿Cuál es la secuencia que se debe seguir para una especificación de requerimientos utilizando casos de uso?
Ver el propósito del sistema.
Hacer gráficos de casos de uso.
Describir los casos con sus alternativas.
Hacer los prototipos para los principales casos de uso.
1.- ¿Qué es un caso de uso?
Es una interacción típica entre un usuario y un sistema de cómputo
2.- ¿Cuáles son las propiedades de los casos de uso?
El caso de uso capta alguna función visible para el usuario
El caso de uso puede ser pequeño o grande
El caso de uso logra un objetivo discreto del usuario
3.- ¿Cómo se obtienen los casos de uso?
Hablando con los usuarios habituales y analizando cada cosa que desean hacer con el sistema. A cada cosa que quieran se le debe poner un nombre y escribir un texto descriptivo breve
4.- ¿Qué son las interacciones con el sistema?
Son cosas que el usuario hace con el sistema. Sirven para la planificación
5.- ¿Qué son los objetivos del usuario?
Es lo que el usuario trata de conseguir. Sirven para considerar formas alternas para el cumplimiento de los objetivos
6.- ¿Cuál es el diagrama que se usa para la representación gráfica de los casos de uso?
El diagrama de casos de uso
7.- ¿Qué es un actor?
Se le llama así al usuario que desempeña ese papel con respecto al sistema. Los actores llevan a cabo casos de uso, un mismo actor puede realizar muchos casos de uso y a la inversa un caso de uso puede ser realizado por varios actores
8.- ¿Qué son los extends y uses?
Son relaciones entre los casos de uso
9.- ¿Cuándo se usan los extends?
Cuando se tiene un caso de uso que es similar a otro pero que hace un poco más. Esto se puede abordar poniendo la conducta normal en un caso y la conducta inusual en cualquier otro lado. La idea es ir preguntándose que puede fallar en cada etapa
10.- ¿Cuándo ocurren las relaciones uses?
Cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar la descripción de tal conducta
11.- ¿En qué radica la diferencia entre extends y uses?
En la intención. En sus vínculos con los actores. En la relación extends los actores tienen que ver con los casos de uso que se están extendiendo, es decir, un actor dado se encargará tanto del caso de uso base como de las extensiones. En las relaciones uses no hay un actor asociado con el caso de uso común.
12.- ¿A qué se llama escenario?
Un escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso
13.- ¿Para qué se usan los casos de uso?
Los casos de uso son una herramienta esencial para la captura de requerimientos, la planificación o el control de proyectos iterativos
CUESTIONARIO CASOS DE USO (2)
“Un instrumento para el modelado de procesos de negocios”
1.- ¿Qué son los casos de uso?
Son una técnica para especificar el comportamiento de un sistema, es decir, una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa.
2.- ¿Qué es un evento?
Es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder
3.- ¿Cuáles son las diferencias entre los casos de uso y los eventos?
Los eventos se centran en describir que hace el sistema cuando el evento ocurre, mientras que los casos de uso describen cómo es el diálogo entre el usuario y el sistema
Los eventos son “atómicos”, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. Un caso de uso puede agrupar a varios eventos.
Lo importante para los eventos es qué datos ingresan al sistema o salen de él, para los casos de uso, el detalle de la información que se intercambia es secundaria
4.- ¿Qué técnicas combinan los casos de uso?
Combina el concepto de evento del análisis estructurado con una técnica de especificación de requerimientos que dice que se deben escribir todos los requerimientos en un manual de usuario. La idea es escribirlos desde la perspectiva de quien usará el sistema no del que lo construirá.
5.- ¿Cómo son los casos de uso con respecto al diseño?
Son independientes del método de diseño y de implementación que se utilice, lo cual da más flexibilidad al método
6.- ¿Qué es un actor?
Es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema. Los actores son externos al sistema
7.- ¿Cuál es la diferencia entre usuario y actor?
Un actor es una clase de rol y un usuario es una persona que cuando usa el sistema asume un rol. Un usuario puede acceder al sistema como distintos actores
8.- ¿Qué es equivalente a los actores?
Los perfiles de usuario
9.- ¿Cuál es el primer paso para utilizar la técnica de casos de uso?
Identificar a los actores
10.- ¿Cómo se representan gráficamente los casos de uso?
Se representan con un óvalo con el nombre en su interior, este nombre debe estar expresado con un verbo en gerundio, seguido por el principal objeto del sistema que es afectado por el caso. El nombre siempre debe estar expresado desde el punto de vista del actor y no del sistema
11.- ¿Cuáles son las características de los casos de uso?
Están expresados desde el punto de vista del actor
Se documentan con texto informal
Describen lo que hace el actor y el sistema, pero se enfocan en la interacción
Se inician por un único actor
Están acotados al uso de una determinada funcionalidad diferenciada del sistema
12.- ¿Cómo diferenciar las funciones del sistema?
Como regla general, una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función.
13.- ¿A qué se refiere con que los casos de uso están documentados en un texto informal?
A que se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema, pero aparece un problema como hacer con un caso de uso para especificar el comportamiento interno si este no es trivial… para eso se usa una notación llamada “Diagrama de Actividad”. Otra limitación es que no hay una sintaxis clara para indicar decisiones e iteraciones.
14.- ¿Qué son las alternativas?
Son las desviaciones del curso normal del caso de uso.
15.- ¿Cuáles son las características de las alternativas?
Representan un error o excepción en el curso normal del caso de uso
Tienen sentido sólo dentro del contexto del caso de uso en el que ocurren
16.- ¿Para qué sirve la modularización de los casos de uso?
Sirve para organizar una especificación de los casos de uso, esto sirve para evitar redundancia y facilitar su comprensión.
17.- Dé las características de las extensiones (relaciones de extensión)
Representan una parte de la funcionalidad del caso que no siempre ocurre.
Son un caso de uso en sí misma.
No necesariamente provienen de un error o excepción.
18.- ¿Son diferentes las alternativas a las extensiones? ¿Por qué?
Si son diferentes, porque las extensiones son casos de uso en sí mismas, mientras que las alternativas no, además, una alternativa es un error o excepción, mientras que una extensión puede no serlo.
19.- ¿Cómo saber si algo opcional es realmente una extensión?
Como regla aproximada se puede pensar que si algo opcional debe ser expresado con más de un paso entonces es 8una extensión.
20.- ¿Cuáles son las características de las relaciones de uso?
Aparecen como funcionalidad común luego de haber especificado varios casos de uso.
Los casos usados son casos de uso en sí mismos.
El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones que son opcionales.
21.- ¿Qué hacer cuando la funcionalidad es común a varios casos de uso pero al mismo tiempo es opcional?
Es mejor que éstas se especifiquen como extensiones, para remarcar así la opcionalidad
22.- ¿Qué es un caso de uso abstracto?
Es un caso de uso que no es implementable por sí solo, sólo tiene sentido cuando es parte de otros casos
23.- ¿Qué es un actor abstracto?
Es el actor que participa de los casos de uso abstractos, que reúne características comunes a todos los actores de los casos de uso que lo usan
24.- ¿Cómo se relacionan los actores concretos con los abstractos?
Mediante la herencia. Los actores concretos heredan al actor abstracto
25.- ¿Cuál es la ventaja que presenta el uso de la herencia?
Que en el análisis de requerimientos se evita la redundancia y se simplifica la especificación y los gráficos de casos de uso
26.- ¿Cuáles son los tipos de casos de uso?
Esenciales o de trazo grueso v/s de implementación o de trazo fino
Casos de uso temporales
Casos primarios v/s casos secundarios
27.- Explique cada uno de ellos
Esenciales o de trazo grueso v/s de implementación o de trazo fino: Al identificar los casos de uso en trazo grueso la idea es ignorar detalles de la interacción entre el sistema y el actor, se incluyen sólo las alternativas más relevantes, es decir, se hace una descripción gruesa. Esto sirve para tomar mejores decisiones con los usuarios sobre qué casos de uso implementar en cada fase. Los casos de uso de trazo fino son aquellos que se especifican una vez que se ha tomado la decisión de implementarlos, acá se incluyen detalles sobre la forma de la interfaz en la descripción del caso, se incluyen otras alternativas, errores o excepciones del sistema. Hay 2 tipos de errores o excepciones, los que provienen de las definiciones del negocio y las que vienen del procesamiento interno del sistema. En el de trazo fino se especifica con más detalle el comportamiento del sistema
Casos de uso temporales: Son los casos de uso en los que una determinada funcionalidad se inicia por el paso del tiempo. Cuando se especifican los casos de uso de trazo fino se debe expresar cuál es el momento del tiempo en el que se inicia el caso.
Casos primarios v/s secundarios: los casos primarios son los que son muy importantes y deben ir siempre, mientras que los secundarios son los que no se corresponden con procesos del negocio, y cuya ejecución sólo es necesaria para que el sistema funcione normalmente
28.- ¿Cuáles son los pasos a seguir para aplicar la técnica de análisis de requerimientos con casos de uso?
Identificar los actores: Identificar todos ellos que son críticos para un buen análisis de requerimientos. Identificar todos los usuarios que tiene el sistema. Este proceso se debe ir repitiendo a medida que se avanza en la descripción de los casos de uso
Identificar los principales casos de uso de cada actor: Nombrar los principales casos de uso de cada actor, sin especificar las acciones dentro de éstos.
Identificar nuevos casos a partir de los existentes: para identificarlos se puede usar la misma técnica para identificar eventos en el análisis estructurado, técnica que está basada en el análisis de 4 situaciones posibles a partir de los requerimientos ya identificados
Variaciones Significativas de casos de uso existentes: si hay 2 casos de uso similares como un único caso en el texto del caso tendremos muchos “SI PASA X, HAGO A, SI NO, HAGO B. Si hay 2 casos de uso con funcionalidad en común, se puede ocupar la relación de uso
Casos de uso Opuestos: hay dos formas de encontrarlos. La primera es buscar la función opuesta a la descrita por el caso. La otra forma es pensar en la negación de la acción principal del caso de uso
Casos de uso que preceden a casos existentes: acá la pregunta que se debe hacer es ¿Qué es lo que tiene que ocurrir antes de este caso de uso?
Casos de uso que suceden a casos existentes: ¿Qué ocurre después de este caso de uso?
Crear descripciones de casos de uso de trazo grueso: se deben ir documentando todos los casos de uso
Definir prioridades y seleccionar casos de la primera iteración: después de documentar los casos de uso es conveniente definir las prioridades de los casos de uso. Para esto suele ser útil usar 3 categorías: imprescindible (son aquellos que si no se implementan, hacen que el sistema no tenga sentido), importante (son los que harían que el usuario se sintiera decepcionado si no se implementan) y deseable (Son aquellos que el usuario querría tener si hubiese tiempo disponible). Al evaluar un requerimiento se debe analizar su costo o complejidad
Escribir los casos de trazo fino y crear prototipos de interfaces: la idea es crear un prototipo visual de la implementación de los casos. Al hacer el prototipo se debe tener en cuenta que no debe ir código en él, y que la idea es que el usuario tenga una idea de cómo se verá el sistema, no que apruebe todas las pantallas
29.- ¿Cuáles son los gráficos a utilizar?
Un gráfico de casos de uso no debe tener más de 15 casos.
Si se debe particional el gráfico se puede hacer por actor.
Si las relaciones de uso y las extensiones entran en el diagrama principal y cumplen la primera regla deben quedarse ahí.
Si las relaciones de uso no entran en el diagrama principal se deben mostrar en gráficos, teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama.
Si hay un caso que es usado por la gran parte de los otros casos, se debe evitar mostrarlo en el gráfico principal.
30.- ¿Cuál es la secuencia que se debe seguir para una especificación de requerimientos utilizando casos de uso?
Ver el propósito del sistema.
Hacer gráficos de casos de uso.
Describir los casos con sus alternativas.
Hacer los prototipos para los principales casos de uso.