Nombre: Crear Usuario Actor primario: Administrador 2.2 Actor secundario: Servidor

1.1. Escenarios de Casos de Uso

Caso de Uso Crear Usuario

1. Nombre: Crear Usuario

2. Actores

2.1 Actor primario: Administrador

2.2 Actor secundario: Servidor

3. Precondición

3.1 El usuario a crear debe ser empleado dePericom S. A. y se creara siempre y cuando laempresa decida que tendrá acceso a la aplicaciónweb.

3.2 El administrador ingresó correctamente alsistema.

4. Flujo Normal

4.1 El administrador selecciona la opción crearusuario.

4.2 El sistema pide al administrador diligenciarun formulario con los datos completos delusuario.

4.3 El administrador diligencia los datos en elformulario de creación de usuarios.

4.4 El sistema verifica que los datos ingresadoscorrespondan al tipo de dato consecuente ocorrespondiente a lo solicitado en cada campo delformulario de creación de usuario. (ocurreexcepción 5.1).

4.5 El sistema muestra el campo de asignación de contraseña y la confirmación de la misma

4.6 El administrador digita contraseña y la confirma (ocurre una excepción ir 5.2)

4.7 El sistema muestra un botón de guardar datosdel usuario.

4.8 El administrador presiona el botón guardar datos.

4.9 El sistema le muestra un mensaje de creaciónde usuario exitosa al administrador y lesolicitara ingresar al formulario asignar rolde usuario.

5. Flujo excepcional

5.1 Los datos no corresponden al tipo de datosolicitado por el formulario, el sistemalimpiara el campo correspondiente y lesolicitara al administrador ingresarnuevamente el o los datos del usuario acorregir. (Vuelve al punto 4.3)

5.2 Las contraseña no coincide con laconfirmación de la misma por lo tanto (vuelveal paso 4.6)

6. Pos condición

6.1 El usuario es creado parcialmente en elsistema.

7. Dudas

8. Frecuencia de Ocurrencia

8.1 La cantidad máxima de usuarios a creardentro del sistema será de 100 personas, lafrecuencia será determinada por la compañía alingresar personal o en su defecto agregarnuevos usuarios que no tengan acceso a laaplicación.

9. Autores y Fecha de creación

Federico Martínez. 2010-09-15

Caso de Uso Asignar Acceso1. Nombre: Asignar Acceso

2. Actores

2.1 Actores Primario: Administrador

2.2 Actor Secundario: Servidor

3. Precondiciones

3.1 El administrador creo satisfactoriamente el usuario.

4. Flujo normal

4.1 El sistema muestra al Administrador la opción asignar acceso al usuario creado.

4.2 El Administrador escoge la opción asignar acceso.

4.3 El sistema muestra lista de opciones con lasdiferentes funcionalidades a habilitar al usuario.

4.4 El Administrador habilita las funcionalidades a brindar al tipo de usuario.

4.5 El sistema solicita confirmación de las funcionalidades brindadas al usuario.

4.6 El Administrador confirma la solicitud.

4.7 Sistema muestra confirmación de asignación de acceso exitosa.


6. Pos condición

6.1 El acceso es asignado correctamente al usuario creado.

7. Dudas


8.1 La cantidad máxima de usuarios a asignar accesosestá directamente proporcional a la cantidad deusuarios creados y la frecuencia será determinadapor la compañía al ingresar personal o en sudefecto agregar nuevos usuarios que no tenganacceso a la aplicación.



Caso de Uso Ingresar (Sitio Web)1. Nombre : Ingresar

2. Actores:

2.1 Actor Primario: Administrador


3. Precondición

3.1 El usuario debe estar creado en el sistema.

3.2 Debe tener asignado el Rol de administrador y contraseñas de seguridad.

4. Flujo Normal

4.1 El sistema pide nombre de usuario

4.2 El Administrador digita nombre de usuario

4.3 El sistema solicita contraseña

4.4 El Administrador digita contraseña

4.5 El sistema valida nombre de usuario y contraseña (ocurre excepción 5.1)

4.6 El sistema solicita ingresar contraseña de seguridad (código de chequeo)

4.7 El Administrador digita contraseña de seguridad

4.8 El sistema valida contraseña de seguridad (ocurre excepción 5.2)

4.9 El Administrador ingresa a la aplicación webcon su Rol y accesos asignados previamente.

5. Flujo Excepcional

5.1 El nombre de usuario y/o contraseña son incorrectos (vuelve al punto 4.1)

5.2 El Administrador ingresa incorrectamente contraseña de seguridad (código de chequeo), el sistema limpiara el formulario pidiendo datos nuevamente. (vuelve al punto 4.1)

6. Pos condición

6.1 El Administrador ingresa satisfactoriamente a la aplicación web.

7. Dudas


8.1 El administrador ingresara mínimo una vez diaria



Caso de Uso Editar Usuario

1. Nombre: Editar Usuario

2. Actores:

2.1 Actor Primario: Administrador


3. Precondición

3.1 El Administrador deberá ingresarsatisfactoriamente a la aplicación web.


4. 5 Flujo Normal

4.1 El sistema muestra opciones para administrador

4.2 El Administrador selecciona editar perfilusuario.

4.3 El sistema muestra lista de selección deusuarios creados en el sistema.

4.4 El Administrador selecciona usuario a editar.(Ocurre excepción 5.1)

4.5 El sistema muestra la información del usuarioen formulario disponible para modificación de losdatos.

4.6 El Administrador ingresa los datos a modificardel usuario.

4.7 El sistema valida los datos ingresados para quecorrespondan a los campos solicitados. (Ocurreexcepción 5.2)

4.8 El Administrador guarda los datos editados delusuario.

4.9 El sistema muestra la confirmación deedición de usuario exitosamente.


5.1 El administrador selecciona un usuarioerróneamente (vuelve al punto 4.4)

5.2 Datos ingresados erróneamente debe ingresar losdatos correctos (vuelve al punto 4.6)

6. Pos condición

6.1 El Administrador edita satisfactoriamente losdatos del usuario.

7. Dudas


8.1 Esto se determinara de forma semanal debido



Caso de Uso Eliminar Usuario1. Nombre: Eliminar Usuario

2. Actores



3. Precondiciones

3.1 El Administrador deberá ingresar satisfactoriamente a la aplicación web.

3.2 Deberá existir creado el usuario a eliminar.

4. Flujo normal

4.1 El sistema muestra al Administrador la opción eliminar usuario.

4.2 El Administrador escoge la opción eliminar.

4.3 El sistema muestra lista de selección con los usuarios existentes.

4.4 El Administrador seleccionara el usuario a eliminar del sistema.

4.5 El sistema muestra el botón eliminar.

4.6 El Administrador oprime el botón eliminar.

4.7 El sistema solicitara confirmación de eliminación de usuario.(ocurre excepción 5.1)

4.8 El administrador confirma la solicitud.

4.9 Sistema solicita contraseña de seguridad para validación de administrador al eliminar usuarios.

4.10 El Administrador ingresa contraseña de seguridad. (ocurre excepción 5.2)

4.11 El sistema elimina usuario y muestra confirmación de operación exitosa.


5.1 El administrador decide no eliminar usuario (volver al punto 4.3)

5.2 El Administrador ingresa contraseña errada. El sistema cerrara la sesión de Administrador y deberá Ingresar nuevamente. (vuelve a 4.1)

6. Pos condición

6.1 El usuario es eliminado correctamente.

7. Dudas


8.1 Según las estadísticas de la empresa se eliminan 12 empleados al año siendo asi aproximadamente un empleado por mes.



Caso de Uso Importar Datos1. Nombre: Importar Datos

2. Actores

2.1 Actores Primario: Administrador2.2 Actor Secundario: Servidor, Sisgerente

3. Precondiciones


3.2 El Administrador deberá migrar los datos dela base de datos de Pericom S. A. del sistema deinformación SISGERENTE.

4. Flujo normal

4.1 El sistema muestra al Administrador la opción importar datos.

4.2 El Administrador escoge la opción importar datos.

4.3 El sistema activa el subir archivos de migración de la base de datos.

4.4 El Administrador seleccionara los archivos a subir. (ocurre excepción 5.1)

4.5 El sistema muestra la opción filtrar datos, donde “colara” los datos del SISGERENTE y dejara los datos requeridos por la aplicación web.

4.6 El Administrador confirma la solicitud.

4.7 Sistema muestra los archivos de migración filtrada de forma exitosa.


5.1 El administrador selecciona archivos incorrectos a filtrar, el sistema muestra que estos archivos no son válidos. (vuelve al 4.1)

6. Pos condición

6.1 La importación de datos es exitosa.

7. Dudas

7.1 ¿Este proceso sera manual o sincronizaran bases de datos?


8.1 Este proceso se realizara cada 12 horas.



Caso de Uso Cargar Datos1. Nombre: Cargar Datos

2. Actores



3. Precondiciones


3.2 Los datos a cargar en la aplicación web deberán ser filtrados previamente.

3.3 Los datos a cargar deberán ser actualizados máximo 12 horas antes de la carga.

4. Flujo normal

4.1 El sistema muestra al Administrador la opción cargar datos.

4.2 El Administrador escoge la opción cargar datos.

4.3 El sistema muestra los archivos filtrados para cargar al sistema.

4.4 El Administrador seleccionará los archivos y envía la carga de los datos. (ocurre excepción 5.1)

4.5 El sistema solicita el ingreso de la contraseña de seguridad para la confirmación de carga de datos exitosa.

4.6 El Administrador ingresa contraseña de seguridad.(ocurre excepción 5.2)

4.7 Sistema muestra confirmación de carga de datos exitosa.


5.1 El Administrador selecciona archivos filtrados con errores, el sistema mostrara el error. (vuelve al 4.1)

5.2 El Administrador ingresa contraseña errada. El sistema cerrara la sesión de Administrador y deberá Ingresar nuevamente. (vuelve a 4.1)

6. Pos condición

6.1 Los archivos son cargados exitosamente.

7. Dudas

7.1 ¿Este proceso sera manual o sincronizaran bases de datos?


8.1 Este proceso será proporcional a la importación de datos, es decir al realizar el mencionado proceso se realizara esta tarea, cada 12 horas.



Caso de Uso Ingresar (Sitio Web)

1. Nombre : Ingresar

2. Actores:

2.3 Actor Primario: Usuario Interno (Todos funcionarios de Pericom S.A. con accesibilidad alSistema)


3. Precondición


4. Flujo Normal

4.1 El sistema pide nombre de usuario

4.2 El usuario digita nombre de usuario

4.3 El sistema solicita contraseña (ocurre excepción 5.1)

4.4 El usuario digita contraseña

4.5 El sistema valida nombre de usuario y contraseña (ocurre excepción 5.2)

4.6 El usuario ingresa a la aplicación web con sus accesos asignados previamente.


5.1 El usuario olvida su contraseña, da clic enrecordar contraseña y lo remite a un campo dondeingresara su cuenta de correo personal y a estale llegara su cuenta de usuario y contraseñaactivos.

5.2 El nombre de usuario y/o contraseña son incorrectos (vuelve al punto 4.1)

6. Pos condición

6.1 El usuario ingresa satisfactoriamente a la aplicación web.

7. Dudas


8.1 Según las estadísticas de la empresa se eliminan 12 empleados al año siendo asi aproximadamente un empleado por mes.



Caso de Uso Consultar Recorrido (Sitio Web)

1. Nombre : Consultar Recorrido

2. Actores:

2.5 Actor Primario: Gerente

2.6 Actor Secundario: Servidor, Vendedor

3. Precondición

3.1 El Gerente debe ingresar satisfactoriamente al sistema.

4. Flujo Normal

4.1 El sistema muestra opción de consultar recorrido.

4.2 El Gerente selecciona la opción consultar recorrido.

4.3 El sistema muestra listado de selección vendedores activos

4.4 El Gerente selecciona el vendedor a consultar

4.5 El sistema muestra lista de selección recorridos recientes y activos. (ocurre excepción5.1)

4.6 El Gerente consulta estado del recorrido y trabajo del vendedor.

4.7 El sistema muestra el recorrido del vendedorsegún parámetros seleccionados con éxito.


5.1 El sistema muestra un mensaje de recorridos inexistentes (vuelve al punto 4.3).

6. Pos condición

6.1 El Gerente ingresa satisfactoriamente a la consulta de recorrido de vendedores.

7. Dudas


8.1 Se ingresaran 28 veces diarias calculando una vezpor cada usuario logeado en el sistema, esto esmodificable o incrementable si el usuario sedesconecta de la aplicación o se queda sin conexiónde internet.

Caso de Uso Visitar Portal1. Nombre: Visitar Portal

2. Actores

2.1 Actores Primario: Visitante

2.2 Actor Secundario: Sitio Web

3. Precondiciones

3.1 El visitante debe tener conocimientos mínimos de informática básica.

3.2 El usuario debe conocer la existencia del sitio web.

4. Flujo normal

4.1 El visitante digita en el navegador la dirección del sitio web(ocurre excepción 5.1)

4.2 El sitio web se muestra en el navegador 4.3 El visitante visualiza los diferentes servicios

de la pagina e interactúan4.4 El Visitante consultara la pagina con éxito


5.1 El visitante digita erróneamente la dirección desitio web y este no se muestra vuelve al paso 4.1

6. Pos condición

6.1 El visitante visita el portal de forma exitosa 6.2 El visitante es direccionado a otra pagina o una

aviso de pagina no encontrada 7. Dudas


8.1 Según las expectativas de la empresa se espera aproximadamente 50 visitas diarias.



Caso de Uso Enviar Mensaje de Contacto1. Nombre: Enviar Mensaje de Contacto

2. Actores

2.1 Actores Primario: Visitante

2.2 Actor Secundario: Sitio Web

3. Precondiciones

3.1 El visitante deberá acceder a la sección contáctenos.

3.2 El usuario deberá tener conocimientos mínimos de informática básica.

4. Flujo normal

4.1 El portal web mostrara el menú contáctenos.

4.2 El Visitante seleccionara la sección contáctenos.

4.3 El Portal le mostrara un formulario de contacto.

4.4 El Visitante diligenciara el formulario con datos solicitados.

4.5 El portal validara los datos ingresados y solicitara enviar formulario.

4.6 El Visitante enviara la información.

4.7 El portal web mostrara un mensaje de confirmación de recepción de mensaje.


6. Pos condición

6.1 El visitante envió mensaje de contacto a la empresa a través del sitio web.

7. Dudas


8.1 La empresa estima que un visitante se contactara con la misma una vez cada 2 dias.



Caso de Uso Guardar Datos1. Nombre: Guardar Datos

2. Actores

2.1 Actores Primario: Servidor

2.2 Actor Secundario: Usuarios

3. Precondiciones

3.1 Los usuarios deben tener ingresado datos a guardar.

3.2 Los datos Ingresados a guardar serán validados previamente.

4. Flujo normal

4.1 Usuarios activan la opción guardar datos.

4.2 El Servidor envía la información a la base de datos.

4.3 Los Usuarios confirman solicitudes de almacenamiento.

4.4 El Servidor Almacena los datos enviados por los usuarios con éxito.


6. Pos condición

6.1 El Servidor guarda los datos ingresados o manipulados por los usuarios.

7. Dudas


8.1 Este proceso debe ser casi que instantáneo y transparente, es decir a cada transacción de un

usuario o de múltiples usuarios deberá paralelamente guardar los datos en el servidor.



Caso de Uso Validar Datos1. Nombre: Validar Datos

2. Actores

2.1 Actores Primario: Servidor

2.2 Actor Secundario: Usuarios

3. Precondiciones

3.1 Los usuarios deben enviar datos a validar.

4. Flujo normal

4.1 Los usuarios ingresan datos.

4.2 El Servidor procesa el tipo de datos.

4.3 El Servidor compara la integridad y referencia entre los datos ingresados y los datossolicitados de forma predeterminada.

4.4 El Sistema muestra el estado de los datos.

4.5 Los usuarios tendrán como resultado el estado de los datos.

4.6 El Sistema confirma precisión en tipos de datos e información ingresada con éxito.


6. Pos condición

6.1 Datos validados correctamente.

7. Dudas


8.1 Este proceso será proporcional al promedio de usuarios logueados que ingresen en el día al sitio web.



Nota La documentación fue elaborada y corregida por Federico Martínez y Celio Sierra

CASOS DE USO ACCEDER APLICACIÓN MOVIL1. NOMBRE: ACCEDER APLICACIÓN MOVIL2. ACTOR:

2.1 ACTOR PRIMARIO: VENDEDOR2.2 ACTOR SECUNDARIO: SERVIDOR

3. PRECONDICION:

3.1 El usuario a ingresar debe tener asignadousuario y contraseña

3.2 Contar con el dispositivo, la aplicaciónSICMOBILE para el ingreso a dicha cuenta y elingreso correspondiente.

3.3 El dispositivo debe contar con servicios deloperador de telefonía móvil.

4 FLUJO NORMAL:

4.1 El usuario inicia aplicación sicmobile 4.2 La aplicación muestra formulario para ingresar

nombre de usuario y contraseña4.3 El vendedor ingresa el nombre de usuario y

contraseña. (Ocurre excepción 5.1)4.4 La aplicación sincroniza los datos.4.5 Los datos son enviados al servidor4.6 El servidor valida los datos (Ocurre excepción

5.2)4.7 El dispositivo móvil carga la aplicación.

5 FLUJO EXCEPCIONAL:5.1. El vendedor olvida su usuario y/o contraseña, porlo tanto la aplicación se bloquea hasta que se ponga encontacto con el administrador.

5.2. Usuario o contraseña errados (vuelve al punto 4.2)

6 POSCONDICION6.1. El vendedor accede exitosamente a la aplicaciónmóvil

7 DUDAS7.1 Cuanto tiempo permanecerá bloqueada la aplicación

móvil por olvido de la contraseña o por reiteradasequivocaciones en ingreso de los mismos

8 FRECUENCIA DE OCURRENCIA8.1 Minimo cada vendedor ingresara una vez diaria.

9 Autores y fecha de creaciónJorge Rico y Rodrigo Camilo fajardo 2010/9/15

CONSULTAR APLICACION MOVIL1. NOMBRE: CONSULTAR APLICACIÓN MOVIL:2. ACTOR:

2.1 ACTOR PRIMARIO: VENDEDOR

2.2 ACTOR SECUNDARIO: SERVIDOR

3. PRECONDICION:

3.1 El vendedor accedio previamente a la aplicaciónmóvil.

3.2 Los parámetros de consulta deben serconcordantes con la información a solicitar.

4. FLUJO NORMAL:

4.1. El vendedor selecciona la opción consulta4.2. La aplicación muestra formulario de consulta4.3. El vendedor selecciona los parámetros de la

búsqueda4.4. La aplicación se sincroniza con la base de datos

4.5. La aplicación muestra el resultado de la búsqueda. (Ocurre excepción 5.1)

5. FLUJO EXCEPCIONAL

5.1. El resultado de la búsqueda no essatisfactorio, es decir, no hay resultadosconcordantes a los parámetros ingresados.(Vuelve alpunto 4.2) La aplicación muestra un mensaje desolicitud de modificación de los parámetros debúsqueda.

6. POSCONDICION

6.1 Consulta del vendedor exitosa 7 DUDAS

8 FRECUENCIA DE OCURRENCIA8.1 Cada vendedor realizara como minimo 20 consultas

diarias.

8. AUTORES Y FECHA DE CREACIÓN

Jorge Rico y Rodrigo Camilo Fajardo2010/9/15

CONSULTAR AGENCIAS1 NOMBRE: CONSULTAR AGENCIAS2 ACTOR:



3. PRECONDICION:

3.3 El vendedor accedió previamente a la aplicaciónmóvil.


6. FLUJO NORMAL:

6.1. El vendedor selecciona la opción consultar agencias6.2. La aplicación muestra formulario de consultapara seleccionar agencia o agencias a consultar.6.3. El vendedor selecciona los parámetros de la




5.1. El resultado de la búsqueda no essatisfactorio, es decir, no hay resultadosconcordantes a los parámetros ingresados (agencia).(Vuelve al punto 4.2) La aplicación muestra unmensaje de solicitud de modificación de losparámetros de búsqueda.

6. POSCONDICION


10 FRECUENCIA DE OCURRENCIA10.1 Cada vendedor realizara como mínimo 20 consultas

diarias.



CONSULTAR BODEGAS1. NOMBRE: CONSULTAR BODEGAS3 ACTOR:



3. PRECONDICION:

3.5 El vendedor accedió previamente a la aplicaciónmóvil.


4FLUJO NORMAL:7.1. El vendedor selecciona la opción consultar bodegas7.2. La aplicación muestra formulario de consultapara seleccionar bodega o bodegas a consultar.7.3. El vendedor selecciona los parámetros de la




5.1. El resultado de la búsqueda no essatisfactorio, es decir, no hay resultadosconcordantes a los parámetros ingresados (bodega).(Vuelve al punto 4.2) La aplicación muestra unmensaje de solicitud de modificación de losparámetros de búsqueda.

6. POSCONDICION


12 FRECUENCIA DE OCURRENCIA12.1 Cada vendedor realizara como mínimo 20 consultas

diarias.



VALIDAR ACCESO

1 NOMBRE: VALIDAR ACCESO2 ACTOR:

2.1 ACTOR PRIMARIO: APLICACION MOVIL


3 PRECONDICION:

3.1 Deberán existir parámetros ingresados a verificar

4 FLUJO NORMAL:

4.1. La aplicación envía los datos al servidor

4.2. El servidor comprueba los datos ingresados con labase de datos (Ocurre Excepción 5.1)

4.3 El servidor envía respuesta

5 FLUJO EXCEPCIONAL:

5.1. El servidor no se puede sincronizar con la base de datos

6 POSCONDICION6.1 El servidor genera respuesta negativa al hacer la

comprobación de datos

6.2 El servidor genera respuesta positiva al hacer lacomprobación de datos

7 DUDAS8 FRECUENCIA DE OCURRENCIA

8.1 Directamente proporcional al acceso a la aplicaciónmóvil es decir mínimo una vez diaria por cada vendedor


Jorge Rico y Rodrigo Camilo Fajardo 2010/9/15

VERIFICAR EXISTENCIAS

1. NOMBRE: VERIFICAR EXISTENCIAS2. ACTORES:

2.1 ACTOR PRIMARIO: SERVIDOR

2.2 ACTOR SECUNDARIO: APLICACIÓN MOVIL

3. PRECONDICIÓN

3.1 Deben existir parámetros de consultaprevios.

4. FLUJO NORMAL:

4.1 La aplicación envía una solicitud deconsulta con parámetros indexados.

4.2 El servidor verifica la existencia de losparámetros determinados en la búsqueda.

5 FLUJO EXCEPCIONAL:6 POSCONDICIÓN:

6.1 Verificación de datos exitosa

7. DUDAS8. FRECUENCIA DE OCURRENCIA8.1 Se generara cada vez que un vendedor realice un consulta por productos y/o locaciones.


Jorge Rico y Rodrigo Camilo Fajardo 2010/9/

CREAR RECORRIDO

1 NOMBRE: CREAR RECORRIDO

2 ACTOR: 2.1 Actor Primario: vendedor2.2 Actor Secundario: Servidor

3 PRECONDICION3.1El vendedor accedió previamente a la aplicación web

4. FLUJO NORMAL

4.1 El vendedor selecciona la opción crear recorrido

4.2 El sistema muestra al vendedor un calendarioespecificado con fecha y hora para crear y administrarlas citas con los clientes.4.3 El Vendedor seleccionara una cita en específicopor fecha y hora para crear las citas pertinentes.(Ocurre excepción 5.1)4.4 El sistema muestra el formulario con los camposespecíficos para ser diligenciados por el vendedor. 4.5El vendedor diligencia los campos, describe la citaen cuestión y guarda la misma. 4.6El sistema almacena la cita creada. (Ocurreexcepción 5.2)4.7 El sistema muestra mensaje de operación exitosa.

5 FLUJO EXCEPCIONAL:5.1 El vendedor selecciona una hora y fecha ya programadas.(vuelve al punto 4.3)

5.2 El vendedor selecciona una hora y fecha demasiadopostergada (superior a 6 meses).(vuelve al punto 4.3)

6 POSCONDICION6.1 EL vendedor crea su recorrido exitosamente.

7 DUDAS8 FRECUENCIA DE OCURRENCIA

8.1Diariamente.

9 AUTORES Y FECHA DE CREACIÓN


EDITAR RECORRIDO

1 NOMBRE: EDITAR RECORRIDO2 ACTOR:

2.1 Actor Primario: Vendedor2.2 Actor Secundario: Servidor

3 PRECONDICION

3.1 El vendedor accedió previamente a laaplicación web

3.2 Debe existir recorridos creados en el sistema.3.3 Los recorridos deben estar dentro del periodo de

caducidad.

4 FLUJO NORMAL4.1 El vendedor selecciona la opción editarrecorrido4.2 El sistema muestra al vendedor un calendarioespecificado con fecha y hora para administrar las citascon los clientes.4.3 El Vendedor seleccionara una cita en específicopor fecha y hora para editar.4.4 El sistema muestra la cita seleccionada para sereditada o comentada por el vendedor. 4.5El vendedor edita o comenta la cita y guarda lamisma. 4.6El sistema almacena la cita editada. (Ocurreexcepción 5.1)4.7 El sistema muestra mensaje de operación exitosa.5. FLUJO EXCEPCIONAL:

5.1. La cita seleccionada caduco los 6 días para edición. 6 POSCONDICION6.1. Edita exitosamente el recorrido seleccionado7 DUDAS8 FRECUENCIA DE OCURRENCIA8.1. Esta actividad se realizara diariamente.9 AUTORES Y FECHA DE CREACIÓN


CONSULTAR RECORRIDO

1 NOMBRE: CONSULTAR RECORRIDO

2. ACTORES2.1 Actor Primario: Vendedor2.2 Actor Secundario: Servidor

3. PRECONDICION

3.1 El vendedor accedió previamente a la aplicación web3.2 Debe existir recorridos creados en el sistema.

4 FLUJO NORMAL

4.1 El vendedor selecciona la opción consultarrecorrido4.2 El sistema muestra al vendedor un calendariopara definir fecha y hora para solicitar consulta4.3 El Vendedor seleccionara fecha y hora aconsultar. (Ocurre excepción 5.1)4.4 El sistema muestra la cita seleccionada alvendedor. 4.5. FLUJO EXCEPCIONAL:

5.1 El vendedor selecciono una fecha o día festivo o día sin citas creadas. (vuelve al punto4.3)

6 POSCONDICION6.1 El vendedor visualiza correctamente la consulta seleccionada.

7 DUDAS7.1 ¿Cuánto tiempo máximo permanecerán accesibles losrecorridos dentro del modulo de consultas?

8.FRECUENCIA DE OCUERRENCIA

8.1 Esta actividad se realizara minimo una vez diaria.



CASO DE USO CONSULTAR E-MAIL

1. Nombre: CONSULTAR E-MAIL2. Actores:

2.1 Actor Primario: USUARIO2.2 Actor Secundario: SERVIDOR, SERVIDOR WEBMAIL

3. Precondición: 3.1 El usuario debe haber ingresado previamente a la aplicación.

4. Flujo normal:4.1 El usuario selecciona la opción

consultar correo

4.2. El sistema le muestra la bandeja deentrada

4.3. El usuario selecciona el mensaje aconsultar (Ocurre Excepción 5.1)

4.4. El sistema muestra el mensajeseleccionado.

5. FLUJO EXCEPCIONAL:5.1. No existen mensajes de correo en la bandeja

de entrada.6. POSCONDICIÓN:

6.1. El usuario visualiza sus mensajes de la bandeja de entrada.

7. DUDAS:8. FRECUENCIA DE OCURRENCIA:

8.1. Cada vez que el usuario lo desee,dependiendo del área que manipule el correose determinara la ocurrencia, ya que áreasque tengan contacto permanente con áreasexternas deberán revisar su correoconstantemente.

9. AUTORES:Jorge Rico y Rodrigo Camilo Fajardo 2010/9/16

CASO DE USO ENVIAR E-MAIL

10. Nombre: ENVIAR E-MAIL11. Actores:

2.3 Actor Primario: USUARIO2.4 Actor Secundario: SERVIDOR, SERVIDOR WEBMAIL

12. Precondición: 3.1 El usuario debe haber ingresado previamente a la aplicación.

13. Flujo normal:4.1 El usuario selecciona la opción enviar

correo

4.2. El sistema le muestra el formulario deredacción de mensajes de correo electrónico

4.3. El usuario ingresa datos en elformulario

4.3. El usuario oprime botón enviar mensaje

4.4. El sistema muestra la confirmación demensaje enviado.

14. FLUJO EXCEPCIONAL:15. POSCONDICIÓN:16. El usuario envía mensaje de correo electrónico

con éxito. 17. DUDAS:18. FRECUENCIA DE OCURRENCIA:

18.1. Cada vez que el usuario lo desee, dependiendo del área que manipule el correo se determinara la ocurrencia, ya que áreas

que tengan contacto permanente con áreas externas deberán redactar y enviar mensajes de correo electrónico.

19. AUTORES:


CASO DE USO BORRAR E-MAIL

1. Nombre: BORRAR E-MAIL

2. Actores:

2.1 Actor Primario: USUARIO

2.2 Actor Secundario: SERVIDOR, SERVIDOR WEBMAIL

3. PRECONDICIÓN:

3.1 El usuario ingreso previamente a laaplicación.

4. FLUJO NORMAL:

4.1 El usuario selecciona la opciónconsultar correo

4.2. El sistema le muestra la bandeja deentrada

4.3. El usuario selecciona el mensaje aborrar (Ocurre Excepción 5.1)

4.4 El usuario oprime el botón borrar.


5.1. No existen mensajes de correo en la bandejade entrada.

6. POSCONDICIÓN:

6.1. El usuario elimina los mensajes de labandeja de entrada.

7. DUDAS:

8. FRECUENCIA DE OCURRENCIA:

8.1. Cada vez que el usuario lo desee,dependiendo del área que manipule el correo sedeterminara la ocurrencia, ya que áreas que tengancontacto permanente con áreas externas deberán revisary eliminar sus mensajes de correo electronicoconstantemente.

9. AUTORES:


MODIFICAR CONTRASEÑA1. NOMBRE: MODIFICAR CONTRASEÑA2. AUTORES:

2.1 Actor Primario: USUARIO PRIMARIO2.2 Actor Secundario: SERVIDOR

3. PRECONDICION:

3.1 El usuario debe tener cuenta.

3.2 El usuario ingreso previamente a la aplicación.

4. FLUJO NORMAL:

4.1 El usuario selecciona la opción modificar contraseña.

4.2 EL sistema muestra el formulario de modificación de contraseña

4.3 El usuario ingresa la contraseña actual.(Ocurre Excepción 5.1)

4.4 El usuario digita la nueva contraseña4.5 El usuario digita nuevamente la nueva contraseña.

4.6 El usuario envía el formulario con los datos diligenciados

4.7 El sistema muestra mensaje de confirmación de cambio de contraseña.


5.1 El usuario diligencia erróneamente la contraseña actual

6. POSTCONDICION

6.1 El usuario cambia exitosamente la contraseña.

7. DUDAS

7.1 El usuario olvido la contraseña cual es el procedimiento.

8. FRECUENCIA DE OCURRENCIA

8.1 Inicialmente cada vez que un usuario que es creado, por obligación este deberá obligatoriamentecambiar su contraseña.

8.2 Los usuarios registrados con antigüedad deberán por políticas de seguridad cambiar su contraseña mínimo cada 3 meses.

9. AUTORES:


EDITAR PERFIL1. NOMBRE: EDITAR PERFIL2. ACTORES:

2.1 Actor Primario: USUARIO2.2 Actor Secundario: SERVIDOR

3. PRECONDICION:

3.1 El usuario debe tener cuenta.3.2 El usuario ingreso previamente.

4. FLUJO NORMAL:

4.1 El usuario selecciona la opción editar perfil.4.2 El sistema muestra formularios para edición de perfil.

4.3 El usuario selecciona los campos a editar.4.4 El usuario hace las modificaciones correspondientes.

4.5 El usuario rectifica sus datos personales.4.6 El usuario guarda los cambios y actualiza el perfil.

4.7 El sistema muestra mensaje de actualización de datos realizada.

5. FLUJO EXCEPCIONAL:6. POSTCONDICION:

6.1 El usuario modifica perfil con éxito.

7. DUDAS

8. AUTORES: Jorge Rico y Rodrigo Camilo Fajardo 30/09/2010

Nombre: Crear Usuario Actor primario: Administrador 2.2 Actor secundario: Servidor

Documents

Transcript of Nombre: Crear Usuario Actor primario: Administrador 2.2 Actor secundario: Servidor