| Version 607 (modified by mvenegas, 12 años ago) (diff) |
|---|
Tabla de Contenido
- Planificación Estratégica Integral
- Proyectos
- Metodología de Desarrollo de Software Libre (MDSL) Versión 2.0
- Propuesta de Solución
- Propuesta de Desarrollo del Proyecto
- Posibles Actores de la Comunidad de Desarrollo de la Aplicación
- Estudio de Factibilidad de Desarrollo del Proyecto
- Descripción de la Aplicación
- Estándares de Desarrollo del Proyecto
- Priorización de Funcionalidades
- Estudio de los Riesgos
- Plan del Proyecto
- Definición del dominio de la aplicación
- Definición del dominio de la aplicación
- Diagramas de Actividades
- Diagramas de Actividades de los Métodos de las Clases de la Aplicación
- Definición de Requerimientos
- Especificación de Requerimientos (Funcionalidades)
- Diagramas de Secuencia
- Diagramas de Estado de las Clases de la Aplicación
- Diseño del Prototipo No-funcional de la Interfaz U/S
- Planes de Pruebas
- Manuales del Sistema
Especificación de Requerimientos (Funcionalidades)
La especificación de requerimientos consiste en describir de manera detallada cada una de las funcionalidades o requerimientos que debe cumplir la aplicación a desarrollar.
1. Casos de Uso para la Gestión de usuario
2. Casos de Uso para el proceso Explicación SItuacional
3. Casos de Uso para el proceso Definición de Políticas Direccionales
Casos de Uso para el proceso Definición de Proyectos Operativos
Especificación de Requerimientos (Funcionalidades)
http://planificacion.cenditel.gob.ve/trac/wiki/EspecificacionRequerimiento/GestionUsuarios
La especificación de requerimientos consiste en describir de manera detallada cada una de las funcionalidades o requerimientos que debe cumplir la aplicación a desarrollar. En esta especificación se debe indicar el flujo de actividades que implica el llevar a cabo cada funcionalidad del sistema.
Para la especificación de los requerimientos de la aplicación se utilizarán diagramas de casos de uso con su respectiva descripción textual.
1. Casos de Uso para la Gestión de Usuario.
1.1 Caso de Uso: Registrar actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Registrar actor planificador. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | |
| Condiciones de salida | Nombre del actor planificador registrado. |
| Flujo básico | 1- El usuario pulsa la opción “registrar actor planificador”. 2- El sistema solicita el nombre del actor planificador, el tipo de usuario a que éste corresponde (para ello presenta las siguientes opciones: Actor Macro, Actor Micro). El sistema muestra las opciones “guardar” y “cancelar”. 3- El usuario ingresa la información solicitada y pulsa la opción “guardar”. 4- El sistema registra la información ingresada. 5- El sistema presenta un mensaje en el que indica que los datos fueron registrados exitosamente y los muestra por pantalla. 6- Si el usuario ingresa la información solicitada y presiona la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario presiona la opción “guardar”, pero omite todos o algunos datos solicitados el sistema presenta por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | La información solicitada en los campos del registro es obligatoria. |
1.2 Caso de Uso: Consultar lista de actores planificadores.
Diagrama
Descripción textual
| Nombre del caso de uso | Consultar lista de actores planificadores. |
| Usuarios | Administrador del sistema, Actor macro, Actor micro. |
| Condiciones de entrada | Actores planificadores registrados. |
| Condiciones de salida | Lista de actores planificadores presentada por pantalla. |
| Flujo básico | 1.- El usuario pulsa la opción “Actores planificadores”. 2.- El sistema presenta una pantalla donde muestra el listado de los actores planificadores registrados y las opciones “modificar” y “eliminar” para cada actor del listado (estas dos opciones serán descritas en los dos casos de uso siguientes). |
| Flujos alternativos | |
| Requisitos especiales | Las opciones "modificar" y "eliminar" se muestran sólo para el caso del administrador del sistema. |
1.3 Caso de Uso: Modificar nombre de actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Modificar nombre de actor planificador . |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | Nombres registrados de los actores planificadores. |
| Condiciones de salida | Nombre del actor planificador modificado. |
| Flujo básico | 1.- El usuario pulsa la opción “Actores planificadores”. 2.- El sistema presenta una pantalla donde muestra el listado de los actores planificadores registrados y muestra las opciones “modificar” y “eliminar” para cada actor del listado. 3.- El usuario pulsa la opción “modificar” para el actor de interés. 4.- El sistema activa el campo “nombre del actor planificador” y presenta las opciones “guardar ” y “cancelar”. 5.- El usuario modifica el nombre del actor planificador y presiona la opción “guardar”. 6.- El sistema registra la modificación. 7.- Si el usuario pulsa la opción “cancelar” luego de modificar el nombre del actor, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 6.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos datos solicitados, el sistema presenta por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales |
1.4 Caso de Uso: Eliminar actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Eliminar actor planificador. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | Exista el registro de actor planificador. |
| Condiciones de salida | Registro de actor planificador borrado. |
| Flujo básico | 1- El usuario pulsa la opción “lista de actores planificadores”. 2- El sistema presenta una pantalla donde muestra el listado de los actores planificadores registrados y muestra las opciones “modificar” y “eliminar” para cada actor del listado. 3- El usuario pulsa la opción “eliminar” para el actor planificador de interés. 4- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar al actor planificador seleccionado? y muestra las opciones “eliminar” y “cancelar”. 5- Si el usuario selecciona la opción “eliminar” el registro del actor planificador es borrado. 6- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
1.5 Caso de Uso: Agregar usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Agregar Usuario. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | |
| Condiciones de salida | Nombre de usuario y contraseña creados para un usuario. |
| Flujo básico | 1- El usuario pulsa la opción “agregar usuario”. 2- El sistema presenta una pantalla donde muestra las opciones “crear cuenta” y “cancelar”, y solicita se indique la siguiente información: el nombre del usuario, dirección de correo electrónico, actor planificador al que pertenece (en este caso el sistema muestra por pantalla una lista con los nombres de los actores planificadores registrados) y el tipo de rol (si el actor ha seleccionado como actor planificador el Actor Micro, entonces se le presentan las siguientes opciones para el rol: Enlace, Supervisor, Sin rol; si el actor ha seleccionado como actor planificador el Actor Macro, entonces se le presentan las siguientes opciones para el rol: Control, Sin rol). 3- El usuario ingresa la información solicitada y pulsa la opción “crear cuenta”. 4- El sistema genera de forma aleatoria una contraseña conforme al tipo de actor planificador y rol que el usuario representa. 5- El sistema registra los datos ingresados y el nombre de usuario y contraseña. 6- El sistema envía a la dirección indicada el nombre de usuario y contraseña. 7- Si el usuario ingresa los datos y presiona la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 5.1- Si el usuario pulsa la opción "crear cuenta" pero omite todos o algunos datos solicitados, el sistema presenta por pantalla un mensaje en el que solicita se indiquen los datos omitidos. 5.2- Si el nombre del usuario ya ha sido registrado, el sistema envía un mensaje en que se solicita se indique un nombre de usuario que no este ingresado en el sistema. |
| Requisitos especiales | La información solicitada en los campos es obligatoria. |
1.6 Caso de Uso: Consultar lista de usuarios.
Diagrama
Descripción textual
| Nombre del caso de uso | Consultar listado de usuarios. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | Usuarios registrados. |
| Condiciones de salida | Lista de usuarios presentada por pantalla. |
| Flujo básico | 1.- El usuario pulsa la opción “usuarios”. 2.- El sistema presenta una pantalla donde muestra el listado de los usuarios registrados y las opciones “modificar” y “eliminar” para cada usuario del listado (estas dos opciones serán descritas en los dos casos de uso siguientes). |
| Flujos alternativos | |
| Requisitos especiales |
1.7 Caso de Uso: Modificar Usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Modificar usuario. |
| Usuarios | Administrador del sistema |
| Condiciones de entrada | Debe existir la cuenta de usuario. |
| Condiciones de salida | Modificaciones realizadas respecto al nombre de usuario y/o contraseña. |
| Flujo básico | 1- El usuario pulsa la opción “usuarios”. 2- El sistema presenta por pantalla la lista de usuarios registrados y presenta las opciones “modificar” y “eliminar” para cada usuario. 3- El usuario pulsa la opción "modificar" para el usuario de interés. 4- El sistema presenta por pantalla los campos activos del registro de usuario y las opciones "guardar" y "cancelar". 5- El usuario realiza la modificación requerida en los datos y presiona la opción "guardar". 6- El sistema registra los datos modificados. 7- Si el usuario pulsa la opción “cancelar” luego de realizar la modificación, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 6.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos de los datos solicitados, el sistema presenta por pantalla un mensaje solicitando que se indiquen los datos omitidos. 6.2- Si la dirección de correo es inválida el sistema presenta un mensaje en el que solicita se indique una dirección electrónica válida. 6.3- Si el nombre del usuario ya ha sido registrado, el sistema envía un mensaje en que se solicita se indique un nombre de usuario que no este ingresado en el sistema. |
| Requisitos especiales |
1.8 Caso de Uso: Eliminar usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Eliminar usuario. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | Debe existir la cuenta de usuario. |
| Condiciones de salida | Usuario eliminado. |
| Flujo básico | 1- El usuario pulsa la opción “usuarios”. 2- El sistema presenta una pantalla donde muestra el listado de usuarios registrados y muestra las opciones “modificar” y “eliminar” para cada usuario del listado. 3- El usuario selecciona la opción eliminar para el usuario de interés. 4- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar al usuario seleccionado? y muestra las opciones “eliminar” y “cancelar”. 5- Si el usuario selecciona la opción “eliminar” el usuario es borrado. 6- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
1.9 Caso de Uso: Registrar fechas para los procesos de planificación.
Diagrama
Descripción textual
| Nombre del caso de uso | Registrar fechas para los procesos de planificación. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | |
| Condiciones de salida | Registro de fechas para los procesos de planificación. |
| Flujo básico | 1- El usuario pulsa la opción “fechas para los procesos de planificación”. 2- El sistema muestra una pantalla donde presenta el nombre de los procesos de planificación y de los subprocesos que los componen, y solicita se indique por cada subproceso la fecha de inicio y fin. El sistema presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa la información solicitada y pulsa la opción “guardar”. 4- El sistema registra la información ingresada. 5- El sistema presenta por pantalla la información registrada y presenta la opción "enviar". 6- Si el usuario pulsa la opción "enviar" el sistema envía a las direcciones de correo registradas las fechas de los procesos de planificación. 7- Si el usuario ingresa las fechas solicitadas y presiona la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos de los datos solicitados, el sistema presenta por pantalla un mensaje en el que solicita se indiquen los datos requeridos. 4.2- Si el usuario ingresa información que no se corresponda con el tipo de dato solicitado el sistema presenta un mensaje en el que indica que la información ingresada es inválida. 4.3- Si el usuario ingresa, para algún proceso de planificación, fechas de fin inferiores a la fechas de inicio, el sistema envía un mensaje en el que se indica que las fechas indicadas son erróneas. |
| Requisitos especiales | Los procesos y subprocesos de planificación son los siguientes: 1)Explicación Situacional: 1.1) Interpretación de la Explicación Situacional, 1.2) Versión Preliminar de la Explicación Situacional, 1.3) Descriptores de la Situación Actual, 1.4) Causas de la Situación Actual, 1.5) Relaciones entre Descriptores y Causas, 1.6) Relaciones entre Causas, 1.7) Seleccionar Posibles Causas Críticas, 1.8) Seleccionar Causas Críticas, 1.9) Describir Causas Críticas, 1.10) Situación Ideal; 2) Definición de Políticas Direccionales del Plan: 2.1) Definición de Necesidades, 2.2) Definición de Posibles Políticas, 2.3) Construcción de Viabilidad a Posibles Políticas, 2.4) Selección de Políticas Direccionales, 2.5) Definición de Posibles Estrategias para Políticas Direccionales, 2.6) Modificación de Posibles Estrategias para Políticas Direccionales; 3) Definición de Proyectos Operativos, 4) Seguimiento y Control del Plan) |
1.10 Caso de Uso: Consultar lista de las fechas de los procesos de planificación.
Diagrama
Descripción textual
| Nombre del caso de uso | Consultar listado de fechas de los procesos de planificación. |
| Usuarios | Administrador del sistema, Actor macro, actor micro. |
| Condiciones de entrada | Fechas de los procesos de planificación registradas. |
| Condiciones de salida | Fechas de los procesos de planificación presentadas por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “fechas de los procesos de planificación”. 2- El sistema presenta una pantalla donde muestra un listado con las fechas de los procesos de planificación y la opción “modificar” para cada fecha (esta opción será descrita en el caso de uso siguiente). |
| Flujos alternativos | |
| Requisitos especiales | La opción "modificar" se muestra sólo para el caso del administrador del sistema. |
1.11 Caso de Uso: Modificar las fechas para los procesos de planificación.
Diagrama
Descripción textual
| Nombre del caso de uso | Modificar las fechas para los procesos de planificación. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | Registro de las fechas de los procesos de planificación. |
| Condiciones de salida | Fechas modificadas. |
| Flujo básico | 1- El usuario pulsa la opción "fechas de los procesos de planificación". 2- El sistema presenta una pantalla donde muestra el listado de las fechas de los procesos de planificación y muestra la opción “modificar” para cada proceso del del listado. 3- El usuario pulsa la opción “modificar” para el proceso de interés. 4- El sistema activa los campos del registro respectivo y presenta las opciones “guardar ” y “cancelar”. 5- El usuario realiza la modificación respectiva y presiona la opción “guardar”. 6- El sistema registra la modificación. 7- El sistema presenta por pantalla la información registrada y presenta la opción "enviar". 8- Si el usuario pulsa la opción "enviar" el sistema envía a las direcciones de correo registradas las fechas de los procesos de planificación. 9- Si el usuario pulsa la opción “cancelar” luego de realizar la modificar, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 6.1- Si el usuario presiona la opción "guardar" y omite todos o algunos de los datos solicitados el sistema presenta por pantalla un mensaje solicitando que se indiquen los datos requeridos. 6.2- Si el usuario ingresa información que no se corresponda con el tipo de dato solicitado el sistema presenta un mensaje en el que indica que la información ingresada es inválida. 6.3- Si el usuario ingresa, para algún proceso de la planificación, fechas de fin inferiores a la fechas de inicio, el sistema envía un mensaje en el que se indica que las fechas indicadas son erróneas. |
| Requisitos especiales |
1.12 Caso de Uso: Ingresar fecha para reporta mensaje de alerta respecto al tiempo que resta para registrar o modificar información en el sistema.
Diagrama
Descripción textual
| Nombre del caso de uso | Ingresar fecha para reporta mensaje de alerta respecto al tiempo que resta para registrar o modificar información en el sistema. |
| Usuarios | Administrador del sistema. |
| Condiciones de entrada | |
| Condiciones de salida | Ingreso al sistema de las fechas para enviar los mensajes de alerta respecto al tiempo que resta para registrar o modificar información en los procesos de la metodología. |
| Flujo básico | 1- El usuario pulsa la opción “Fecha para reportar mensaje de alerta respecto al registro o modificación de información”. 2- El sistema solicita se indique la fecha para cada uno de los procesos de la metodología de planificación en la cual el sistema debe reportar un mensaje de alerta respecto al registro o modificación de información en estos procesos. El sistema presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa las fechas solicitadas y pulsa la opción “guardar”. 4- El sistema registra las fechas. 5- Si el usuario ingresa fechas y pulsa la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario no ingresa todas o algunas de las fechas solicitadas y pulsa la opción “guardar”, el sistema solicita se indiquen las fechas omitidas. |
| Requisitos especiales | La información solicitada es obligatoria. |
1.13 Caso de Uso: Notificar periodo de tiempo restante para registrar porcentaje de información que falta por ingresar al sistema para el proceso actual.
Descripción textual
| Nombre del caso de uso | Notificar periodo de tiempo restante para registrar porcentaje de información que falta por ingresar al sistema para el proceso actual. |
| Usuarios | |
| Condiciones de entrada | I) El porcentaje de información a registrar para el proceso actual debe ser menor que el 100% requerido. II) Debe existir el registro de la fecha en la que se debe generar una alerta para el registro o modificación de información en el proceso actual. |
| Condiciones de salida | Mensaje por correo electrónico dirigido a los usuarios, en el cual se indica el período de tiempo restante para registrar porcentaje de información que falta por ingresar al sistema para el proceso actual. |
| Flujo básico | 1- En la fecha registrada para reportar alerta respecto al registro o modificación de información en el proceso activo el sistema debe enviar un correo electrónico a los usuarios, indicándoles el período de tiempo que les resta para ingresar al sistema el porcentaje de información del proceso actual que resta por registrar. |
| Flujos alternativos | |
| Requisitos especiales | El mensaje por correo electrónico debe ser enviado para cada uno de los procesos de la metodología de planificación que se encuentren activos en el sistema. |
1.14 Caso de Uso: Notificar periodo de tiempo restante para modificar información registrada en el proceso actual.
Descripción textual
| Nombre del caso de uso | Notificar periodo de tiempo restante para modificar información registrada en el proceso actual. |
| Usuarios | |
| Condiciones de entrada | I) Debe existir el registro de la fecha en la que se debe generar una alerta para el registro o modificación de información en el proceso actual. |
| Condiciones de salida | Mensaje por correo electrónico dirigido a los usuarios, en el cual se indica el período de tiempo restante para modificar información registrada en el sistema para el proceso actual. |
| Flujo básico | 1- En la fecha registrada para reportar alerta respecto al registro o modificación de información en el proceso actual el sistema debe enviar un correo electrónico a los usuarios, indicándoles el período de tiempo que les resta para modificar información registrada para el proceso actual. |
| Flujos alternativos | |
| Requisitos especiales | El mensaje por correo electrónico debe ser enviado para cada uno de los procesos de la metodología de planificación que se encuentren activos en el sistema. |
1.15 Caso de Uso: Mostrar estatus del registro de información en el sistema.
Diagrama
Descripción textual
| Nombre del caso de uso | Mostrar estatus del registro de información en el sistema. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | |
| Condiciones de salida | Porcentaje de información registrada en cada proceso presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Avance”. 2- El sistema presenta por pantalla el porcentaje de información registrada hasta ese momento en cada uno de los procesos descritos en la metodología de planificación, y muestra la opción “Ver”. 3- Si el usuario pulsa la opción “Ver” el sistema presenta por pantalla información detalla de los porcentajes de información registrada en cada una de las actividades que componen los procesos de la metodología. |
| Flujos alternativos | |
| Requisitos especiales |
1.16 Caso de Uso: Entrar al sistema.
Diagrama
Descripción textual
| Nombre del caso de uso | Entrar al sistema |
| Usuarios | Actor macro o Actor micro |
| Condiciones de entrada | El usuario debe poseer nombre de usuario y contraseña para entrar al sistema. |
| Condiciones de salida | Acceso al sistema de acuerdo al tipo de usuario. |
| Flujo básico | 1- El usuario accede a la página de entrada al sistema. 2- El sistema solicita que se indique el nombre de usuario y contraseña y presenta las opciones "iniciar sesión" y "olvidó su contraseña" (esta última opción será descrita en el caso de uso siguiente). 3- El usuario ingresa al sistema lo solicitado y presiona la opción "iniciar sesión". 4- El sistema registra los datos ingresados por el usuario. 5- El sistema presenta los servicios de acuerdo al rol del usuario. |
| Flujos alternativos | 4.1- Si el usuario presiona la opción "iniciar sesión" pero no indica todos o algunos de los datos solicitados, el sistema muestra por pantalla un mensaje en el que se solicita se indiquen los datos omitidos. 4.2- Si el nombre de usuario no coincide con la contraseña, el sistema presenta un mensaje por pantalla indicando que el nombre de usuario o la contraseña son incorrectos. |
| Requisitos especiales | Los campos solicitados son obligatorios. |
1.17 Caso de Uso: Solicitar nueva contraseña.
Diagrama
Descripción textual
| Nombre del caso de uso | Solicitar nueva contraseña |
| Usuarios | Actor macro, Actor micro |
| Condiciones de entrada | El usuario debe tener una cuenta creada. |
| Condiciones de salida | Mensaje por correo electrónico con la nueva contraseña. |
| Flujo básico | 1- El usuario pulsa la opción "Solicitar nueva contraseña". 2- El sistema despliega una pantalla donde solicita una dirección de correo electrónico y presenta la opción "generar nueva contraseña". 3- El usuario ingresa la dirección solicitada y pulsa la opción "generar nueva contraseña". 4- El sistema valida la dirección de correo electrónico. 5- El sistema genera aleatoriamente una nueva contraseña y la envía a la dirección de correo indicada por el usuario. |
| Flujos alternativos | 4.1- Si el usuario no ingresa la dirección de correo electrónico y presiona la opción "generar nueva contraseña" el sistema muestra por pantalla un mensaje en el cual pide que se indique dicha dirección. 4.2- Si el usuario ingresa una dirección de correo inválida el sistema muestra por pantalla un mensaje en el que indica que la dirección es inválida. |
| Requisitos especiales | La información sobre el campo solicitado es obligatoria. |
1.18 Caso de Uso: Registrar datos del usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Registrar datos del usuario. |
| Usuarios | Actor macro, Actor micro |
| Condiciones de entrada | |
| Condiciones de salida | Datos del usuario registrados. |
| Flujo básico | 1- El usuario pulsa la opción "datos de usuario". 2- El sistema presenta una pantalla donde muestra las opciones “guardar” y “cancelar”, y solicita se indique la siguiente información: nombres, apellidos, cédula de identidad, correo electrónico, nombre del actor planificador al que representa (el sistema carga de manera automática el nombre del actor planificador al cual está relacionado el usuario). 3- El usuario ingresa los datos solicitados y presiona la opción "guardar". 4- El sistema registra los datos. 5- El sistema presenta un mensaje por pantalla indicando que los datos han sido registrados exitosamente. 6- Si el usuario ingresa los datos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos de los datos solicitados, el sistema presenta por pantalla un mensaje solicitando que se indiquen los datos requeridos. 4.2- Si el usuario ingresa en un campo información que no se corresponda con el tipo de dato solicitado para dicho campo, el sistema presenta un mensaje en el que indica que la información ingresada en el campo respectivo es inválida. |
| Requisitos especiales | I) La información solicitada en los campos del registro es obligatoria. II) La modificación de los datos del usuario se realiza también a través de la opción "editar datos básicos del usuario". |
1.19 Caso de Uso: Consultar datos del usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Consultar datos del usuario. |
| Usuarios | Actor macro, Actor micro |
| Condiciones de entrada | Debe existir el registro de los datos del usuario. |
| Condiciones de salida | Datos a consultar presentados por pantalla. |
| Flujo básico | 1.- El usuario pulsa la opción "datos de usuario". 2.- El sistema presenta por pantalla los datos del usuario. |
| Flujos alternativos | |
| Requisitos especiales |
1.20 Caso de Uso: Modificar datos del usuario.
Diagrama
Descripción textual
| Nombre del caso de uso | Modificar datos del usuario. |
| Usuarios | Actor macro, Actor micro |
| Condiciones de entrada | Debe existir el registro de los datos del usuario. |
| Condiciones de salida | Datos modificados. |
| Flujo básico | 1- El usuario pulsa la opción "datos de usuario". 2- El sistema presenta por pantalla el registro de datos del usuario y presenta la opción "editar" para permitir la modificación de los datos. 3- El usuario pulsa la opción "editar".4- El sistema activa los campos de dicho registro para permitir su modificación, y presenta las opciones "guardar" y "cancelar". 5- El usuario modifica los datos requeridos y pulsa la opción "guardar". 6- El sistema registra los datos. 7- El sistema presenta por pantalla un mensaje indicando que los datos modificados fueron registrados exitosamente. 8- Si el usuario modifica los datos y pulsa la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 5.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos de los datos solicitados, el sistema presenta por pantalla un mensaje en el que solicitando que se indiquen los datos requeridos. 5.2- Si el usuario ingresa en un campo información que no se corresponda con el tipo de dato solicitado para dicho campo, el sistema presenta un mensaje en el que indica que la información ingresada en el campo respectivo es inválida. |
| Requisitos especiales |
1.21 Caso de Uso: Cambiar contraseña.
Diagrama
Descripción textual
| Nombre del caso de uso | Cambiar contraseña |
| Usuarios | Actor macro, Actor micro |
| Condiciones de entrada | El usuario debe tener una cuenta creada.SIPP/Metodologia/Desarrollo/EspecificacionRequerimiento/x5SeguimientoAccionesCentralizadas |
| Condiciones de salida | Contraseña actualizada. |
| Flujo básico | 1- El usuario pulsa la opción "cambiar contraseña". 2- El sistema despliega una pantalla donde solicita: contraseña actual, nueva contraseña y verificación de la nueva contraseña. El sistema presenta la opción "modificar contraseña". 3- El usuario ingresa los datos solicitados presiona la opción "modificar contraseña". 4- El sistema registra los datos. 5- El sistema presenta un mensaje donde indica que la contraseña fue actualizada. |
| Flujos alternativos | 4.1- Si el usuario pulsa la opción "modificar contraseña" y omite todos o algunos datos solicitados, el sistema presenta por pantalla un mensaje en el que solicita se indiquen los datos omitidos. 4.2- Si la contraseña es insegura el sistema presenta un mensaje por pantalla en el cual indica que la contraseña ingresada es insegura, y solicita se indique una nueva. |
| Requisitos especiales | La información sobre los campos solicitados es obligatoria. |
1.22 Caso de Uso: Registrar datos básicos del actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Registrar datos básicos del actor planificador. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | Nombre del actor planificador registrado. |
| Condiciones de salida | Datos básicos del actor planificador registrados. |
| Flujo básico | 1- El usuario pulsa la opción “datos básicos del actor planificador”. 2- El sistema presenta una pantalla donde muestra las opciones “guardar” y “cancelar” y solicita que se indique los siguientes datos: razón social, R.I.F, y domicilio fiscal (dirección, estado, municipio, parroquia y ciudad). 3- El usuario ingresa los datos y presiona la opción "guardar". 4- El sistema registra los datos. 5- El sistema presenta un mensaje en el que indica que los datos fueron registrados exitosamente. 6- Si el usuario ingresa los datos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario pulsa la opción "guardar" y omite al menos uno de los datos solicitados, el sistema presenta por pantalla un mensaje solicitando que se indique dicho datos. 4.2- Si el usuario ingresa en un campo información que no se corresponda con el tipo de dato solicitado para dicho campo, el sistema presenta un mensaje en el que indica que la información ingresada en el campo respectivo es inválida. |
| Requisitos especiales |
1.23 Caso de Uso: Consultar datos básicos del actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Consultar datos básicos del actor planificador. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | Debe existir el registro de los datos que se requieren consultar. |
| Condiciones de salida | Datos a consultar presentados por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "datos básicos del actor planificador". 2- El sistema presenta por pantalla los datos básicos del actor planificador. |
| Flujos alternativos | |
| Requisitos especiales |
1.24 Caso de Uso: Modificar datos básicos del actor planificador.
Diagrama
Descripción textual
| Nombre del caso de uso | Modificar datos básicos del actor planificador. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | Deben existir datos básicos registrados sobre el actor planificador respectivo. |
| Condiciones de salida | Datos básicos del actor planificador modificados. |
| Flujo básico | 1- El usuario pulsa la opción "datos básicos del actor planificador". 2- El sistema presenta por pantalla los datos básicos del actor, activa los campos de este registro para permitir la modificación del mismo, y muestra las opciones “guardar” y “cancelar”. 3- El usuario modifica los campos (o el campo) requeridos y presiona la opción “guardar”. 4- El sistema registra los datos. 5- El sistema presenta un mensaje en el que indica que los datos fueron registrados exitosamente. 6- Si el usuario modifica los campos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario pulsa la opción "guardar" y omite todos o algunos de los datos solicitados, el sistema presenta por pantalla un mensaje solicitando que se indiquen los datos requeridos. 3.2- Si el usuario ingresa en un campo información que no se corresponda con el tipo de dato solicitado para dicho campo, el sistema presenta un mensaje en el que indica que la información ingresada en el campo respectivo es inválida. |
| Requisitos especiales |
1.25 Caso de Uso: Buscar datos de actores planificadores.
Diagrama
Descripción textual
| Nombre del caso de uso | Buscar datos de actores planificadores. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | Debe existir el registro de los datos que se requiere consultar. |
| Condiciones de salida | Datos a consultar presentados por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Buscar datos de actores planificadores". 2- El sistema solicita los siguientes parámetros de búsqueda: estado, ciudad, municipio, actor planificador. El sistema presenta la opción "buscar". 3- El usuario indica el o los parámetros de búsqueda de interés y presiona la opción “buscar”. 4- El sistema presenta por pantalla un listado con los actores planificadores que tienen en su registro de información datos relacionados a los parámetros de búsqueda que han sido ingresados. |
| Flujos alternativos | 4.1- Si el usuario pulsa la opción "buscar" sin indicar algún parámetro de búsqueda el sistema presenta por pantalla un mensaje en el que solicita se indique algún parámetro para realizar la búsqueda. |
| Requisitos especiales |
2. Casos de Uso para el Proceso de Explicación Situacional.
2.1 Casos de Uso para Gestionar Interpretaciones de la Explicación Situacional.
A continuación se presenta la descripción textual de estos casos de uso.
2.1.1 Caso de Uso: Registrar interpretación de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Registrar interpretación de la explicación situacional. |
| Usuarios | Actor micro. |
| Condiciones de entrada | La fecha para el registro o modificación de la Interpretación de la Explicación Situacional debe estar vigente. |
| Condiciones de salida | Registro de la interpretación de la explicación situacional. |
| Flujo básico | 1- El usuario pulsa la opción “Interpretación de la explicación situacional”. 2- El sistema presenta una pantalla donde solicita que se indique la siguiente información para cada una de las siguientes secciones: (a) descriptores de la situación actual (es decir, hechos verificables que manifiestan una situación como problema), (b) causas que originan tales descriptores, (c) cambios de la situación actual que puedan ser alcanzados en función del plan que se pretende construir, (d) cambios ideales que se aspiran alcanzar. En cada sección (a, b, c y d) se presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa datos solicitados en las secciones, y presiona la opción "guardar" por cada sección donde efectúe el registro. 4- El sistema registra los datos y los presenta por pantalla. 5- Si el usuario ingresa datos solicitados en las secciones y presiona la opción “cancelar” en éstas, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en cualquiera de las secciones y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita que se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del formulario se coloque el siguiente mensaje: “Se podrá registrar o modificar la interpretación de la explicación situacional hasta la fecha [aquí hay que colocar la fecha válida para la Interpretación de la Explicación Situacional]”. |
2.1.2 Caso de Uso: Consultar interpretación de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Consultar interpretación de la explicación situacional. |
| Usuarios | Actor micro. |
| Condiciones de entrada | Debe existir información registrada de la interpretación de la explicación situacional. |
| Condiciones de salida | Interpretación de la explicación situacional presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Interpretación de la explicación situacional". 2- El sistema presenta por pantalla la información registrada para las secciones "descriptores de la situación actual", "causas que originan tales descriptores", "cambios de la situación actual" y "cambios ideales". En cada una de esta secciones muestra la opción "actualizar". |
| Flujos alternativos | |
| Requisitos especiales |
2.1.3 Caso de Uso: Modificar interpretación de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Modificar interpretación de la explicación situacional. |
| Usuarios | Actor micro. |
| Condiciones de entrada | I) Debe existir información registrada de la interpretación de la explicación situacional. II) La fecha para el registro o modificación de la interpretación de la explicación situacional debe estar vigente. |
| Condiciones de salida | Modificación de la interpretación de la explicación situacional. |
| Flujo básico | 1- El usuario pulsa la opción "Interpretación de la Explicación Situacional". 2- El sistema presenta por pantalla la información registrada en las secciones "descriptores de la situación actual", "causas que originan tales descriptores", "cambios de la situación actual", "cambios ideales", y muestra la opción "actualizar" para cada sección. 3- El usuario pulsa sobre la opción "actualizar" de la sección de interés. 4- El sistema presenta los datos registrados de la sección de interés, activa los campos de ésta para permitir que se realice la modificación respectiva y presenta las opciones “guardar” y “cancelar”. 5- El usuario modifica la información requerida y pulsa la opción “guardar”. 6- El sistema registra los datos modificados y los presenta por pantalla. 7- Si el usuario modifica los campos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 5.1- Si el usuario omite los datos solicitados en una sección y pulsa la opción “guardar” de esta sección, el sistema muestra por pantalla un mensaje en el que solicita que se indique los datos omitidos. |
| Requisitos especiales |
2.1.4 Caso de Uso: Consultar interpretaciones de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Consultar interpretaciones de la explicación situacional. |
| Usuarios | Actor macro, Actor micro. |
| Condiciones de entrada | Debe existir información registrada de interpretaciones de la explicación situacional. |
| Condiciones de salida | Interpretaciones de la explicación situacional presentadas por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Interpretaciones de la explicación situacional". 2- El sistema presenta por pantalla la información registrada por cada actor micro respecto a sus interpretaciones de la explicación situacional. |
| Flujos alternativos | |
| Requisitos especiales |
2.2 Casos de Uso para Gestionar la Versión Preliminar de la Explicación Situacional.
A continuación se presenta la descripción textual de estos casos de uso.
2.2.1 Caso de Uso: Registrar versión preliminar de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Registrar versión preliminar de la explicación situacional. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para el registro o modificación de la versión preliminar de la explicación situacional debe estar vigente. |
| Condiciones de salida | Registro de la versión preliminar de la explicación situacional. |
| Flujo básico | 1- El usuario pulsa la opción “Versión Preliminar de la Explicación Situacional”. 2- El sistema presenta una pantalla donde solicita que se indique la siguiente información para cada una de las siguientes secciones: (a) descriptores de la situación actual (es decir, hechos verificables que manifiestan una situación como problema), (b) causas que originan tales descriptores, (c) cambios de la situación actual que puedan ser alcanzados en función del plan que se pretende construir, (d) cambios ideales que se aspiran alcanzar. En cada sección (a, b, c y d) se presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa datos solicitados en las secciones, y presiona la opción "guardar" por cada sección donde efectúe el registro. 4- El sistema registra los datos y los presenta por pantalla. 5- Si el usuario ingresa datos solicitados en las secciones y presiona la opción “cancelar” en éstas, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en cualquiera de las secciones y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita que se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del formulario se coloque el siguiente mensaje: “Se podrá registrar y/o modificar la versión preliminar de la situación actual hasta la fecha [aquí hay que colocar la fecha válida para el registro o modificación de la versión preliminar de la explicación situacional]”. |
2.2.2 Caso de Uso: Importar interpretaciones de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Importar interpretaciones de la explicación situacional. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) La fecha para el registro o modificación de la versión preliminar de la explicación situacional debe estar vigente. II) Debe existir registros de interpretaciones de explicaciones situacionales. |
| Condiciones de salida | Información de una interpretación de la explicación situacional registrada como información en alguna de las secciones que componen la versión preliminar de la explicación situacional. |
| Flujo básico | 1- El usuario pulsa la opción "Importar interpretaciones de la explicación situacional". 2- El sistema presenta por pantalla las secciones de información que componen las interpretaciones de la explicación situacional registradas por cada actor micro, y muestra la opción "guardar" en cada una de estas secciones. 3- El usuario selecciona información de la sección de interés y pulsa la opción "guardar". 4- El sistema registra la información en la sección correspondiente de la versión preliminar de la explicación situacional. |
| Flujos alternativos | |
| Requisitos especiales |
2.2.3 Caso de Uso: Consultar versión preliminar de la explicación situacional (por un actor micro).
Descripción textual
| Nombre del caso de uso | Consultar versión preliminar de la explicación situacional. |
| Usuarios | Actor micro. |
| Condiciones de entrada | Debe existir información registrada de la versión preliminar explicación situacional. |
| Condiciones de salida | Versión preliminar de la explicación situacional presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Versión Preliminar de la Explicación Situacional". 2- El sistema presenta por pantalla la información registrada para cada una de las secciones que componen la versión preliminar explicación situacional. |
| Flujos alternativos | |
| Requisitos especiales |
2.2.4 Caso de Uso: Consultar versión preliminar de la explicación situacional (por un actor macro).
Descripción textual
| Nombre del caso de uso | Consultar versión preliminar de la explicación situacional. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir información registrada de la versión preliminar explicación situacional. |
| Condiciones de salida | Versión preliminar de la explicación situacional presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Versión Preliminar de la Explicación Situacional". 2- El sistema presenta por pantalla la información registrada para cada una de las secciones que componen la versión preliminar explicación situacional, y para cada sección muestra la opción "actualizar". |
| Flujos alternativos | |
| Requisitos especiales |
2.2.5 Caso de Uso: Modificar versión preliminar de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Modificar versión preliminar de la explicación situacional. | |
| Usuarios | Actor macro. | |
| Condiciones de entrada | I) La fecha para el registro o modificación de la versión preliminar de la explicación situacional debe estar vigente. II)Debe existir el registro de la versión preliminar de la explicación situacional. | |
| Condiciones de salida | Modificación de la versión preliminar de la explicación situacional. | |
| Flujo básico | 1- El usuario pulsa la opción "Versión Preliminar de la Explicación Situacional". 2- El sistema presenta por pantalla la información registrada para cada una de las secciones que componen la versión preliminar explicación situacional, y para cada sección muestra la opción "actualizar". 3- El usuario pulsa sobre la opción "actualizar" de la sección de interés. 4- El sistema activa los campos de la sección de interés para permitir que se realice la modificación respectiva, y presenta las opciones “guardar” y “cancelar”. 5- El usuario modifica la información requerida y pulsa la opción “guardar”. 6- El sistema registra los datos modificados y los presenta por pantalla. 7- Si el usuario modifica los campos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. | | |
| Flujos alternativos | 5.1- Si el usuario omite los datos solicitados en una sección y pulsa la opción “guardar” de esta sección, el sistema muestra por pantalla un mensaje en el que solicita que se indique los datos omitidos. | |
| Requisitos especiales |
2.3 Casos de Uso para Gestionar Situación Actual.
A continuación se presenta la descripción textual de estos casos de uso.
2.3.1 Caso de Uso: Registrar situación actual.
Descripción textual
| Nombre del caso de uso | Registrar situación actual. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para el registro o modificación de cualquiera de las secciones que componen la situación actual debe estar vigente. |
| Condiciones de salida | Registro de información de la situación actual. |
| Flujo básico | 1- El usuario pulsa la opción "Situación Actual". 2- El sistema despliega una pantalla donde muestra las secciones que componen la situación actual, y para cada sección solicita: (a) Sección de descriptores de la situación actual, el sistema solicita se indique el nombre y acrónimo del descriptor; (b) Sección de causas, el sistema solicita se indique por cada causa a registrar: nombre y acrónimo, tipo al que corresponde, nivel de control que se tiene sobre la misma y el tipo de perspectiva a la cual corresponde la causa; c) Sección de relaciones entre causas y descriptores, el sistema solicita se indique las relaciones entre cada una de las causas y cada uno de los descriptores registrados. Para cada sección (a, b y c) el sistema presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa datos solicitados en las secciones y presiona la opción “guardar” respectiva a cada sección donde efectúe el registro. 4- El sistema registra los datos ingresados y los presenta por pantalla. 5- Si el usuario ingresa datos solicitados en cualquiera de las secciones y presiona la opción “cancelar” de la respectiva sección, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1- Si el usuario omite todos o algunos de los datos solicitados en cualquiera de las secciones, y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita que se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del registro de cada una de las secciones que componen la situación actual se coloque el siguiente mensaje: “Se podrá registrar o modificar información hasta la fecha válida (colocar la fecha respectiva) para la sección correspondiente”. II) La causas se pueden clasificar en los siguientes tipos: “regla”, “acumulación” o “flujo”. III) Los niveles de control que pueden tener los actores planificadores sobre una causan son los siguientes: “bajo control absoluto de los actores planificadores”, “bajo control compartido con otros actores”, o “fuera del control de los actores planificadores. |
2.3.2 Caso de Uso: Consultar situación actual (por parte de un actor micro).
Descripción textual
| Nombre del caso de uso | Consultar situación actual. |
| Usuarios | Actor micro. |
| Condiciones de entrada | Debe existir información registrada de la situación actual. |
| Condiciones de salida | Situación Actual registrada presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Situación Actual". 2- El sistema presenta por pantalla las secciones: "Descriptores de la situación actual", "Causa de la situación actual" y "Relaciones entre descriptores y causas". 3- El usuario pulsa sobre la sección que quiere consultar. 4- El sistema presenta por pantalla la información registrada para la sección respectiva. |
| Flujos alternativos | |
| Requisitos especiales |
2.3.3 Caso de Uso: Consultar situación actual (por parte de un actor macro).
Descripción textual
| Nombre del caso de uso | Consultar situación actual. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir información registrada de la situación actual. |
| Condiciones de salida | Situación Actual registrada presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Situación Actual". 2- El sistema presenta por pantalla las secciones: "Descriptores de la situación actual", "Causa de la situación actual" y "Relaciones entre descriptores y causas". 3- El usuario pulsa sobre la sección que quiere consultar. 4- El sistema presenta por pantalla la información registrada para la sección respectiva y presenta las opciones "modificar" y "eliminar". |
| Flujos alternativos | |
| Requisitos especiales |
2.3.4 Caso de Uso: Modificar situación actual.
Descripción textual
| Nombre del caso de uso | Modificar situación actual. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir información registrada de la situación actual. II) La fecha para registrar o modificar la información de la sección de la descripción de la situación actual que se quiera modificar debe estar vigente. |
| Condiciones de salida | Situación actual modificada. |
| Flujo básico | 1- El usuario pulsa la opción “Situación Actual”. 2- El sistema presenta por pantalla las secciones: "Descriptores de la situación actual", "Causa de la situación actual" y "Relaciones entre descriptores y causas". 3- El usuario pulsa sobre la sección en la cual quiere realizar la modificación. 4- El sistema presenta por pantalla la información registrada para la sección respectiva, y presenta las opciones "modificar" y "eliminar". 5- El usuario pulsa la opción “modificar”. 6- El sistema activa los campos de la sección correspondiente para permitir que se realice la modificación respectiva, y presenta las opciones “guardar” y “cancelar”. 7- El usuario modifica la información requerida y pulsa la opción “guardar”. 8- El sistema registra los datos modificados y los presenta por pantalla. 9- Si el usuario modifica los campos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 7.1- Si el usuario omite todos o alguno de los datos solicitados en cualquiera de las secciones y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita que se indique los datos omitidos. |
| Requisitos especiales |
2.3.5 Caso de Uso: Eliminar descriptor de la situación actual.
Descripción textual
| Nombre del caso de uso | Eliminar descriptores de la situación actual. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para registrar o modificar la información de la sección "Descriptores de la situación actual" debe estar vigente. |
| Condiciones de salida | Descriptor eliminado. |
| Flujo básico | 1- El usuario pulsa la opción “Situación Actual”. 2- El sistema presenta por pantalla las secciones: "Descriptores de la situación actual", "Causa de la situación actual" y "Relaciones entre descriptores y causas". 3- El usuario pulsa sobre la sección "Descriptores de la situación actual". 4- El sistema presenta por pantalla el listado de descriptores registrados y presenta las opciones "modificar" y "eliminar". 5- El usuario pulsa la opción “eliminar" del descriptor que desea eliminar”. 6- El sistema presenta un mensaje por pantalla en el que pregunta al usuario si está seguro de eliminar el descriptor, y muestra las opciones "eliminar" y "cancelar". 7- El usuario pulsa la opción "eliminar". 8- El sistema elimina el descriptor respectivo. 9- Si el usuario pulsa la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
2.3.6 Caso de Uso: Eliminar causa de la situación actual.
Descripción textual
| Nombre del caso de uso | Eliminar causa de la situación actual. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para registrar o modificar la información de la sección "Causa de la situación actual" debe estar vigente. |
| Condiciones de salida | Causa eliminada. |
| Flujo básico | 1- El usuario pulsa la opción “Situación Actual”. 2- El sistema presenta por pantalla las secciones: "Descriptores de la situación actual", "Causa de la situación actual" y "Relaciones entre descriptores y causas". 3- El usuario pulsa sobre la sección "Causa de la situación actual". 4- El sistema presenta por pantalla el listado de causas registrados y presenta las opciones "modificar" y "eliminar". 5- El usuario pulsa la opción “eliminar" de la causa que desea eliminar”. 6- El sistema presenta un mensaje por pantalla en el que pregunta al usuario si está seguro de eliminar la causa, y muestra las opciones "eliminar" y "cancelar". 7- El usuario pulsa la opción "eliminar". 8- El sistema elimina la causa respectiva. 9- Si el usuario pulsa la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
2.3.7 Caso de Uso: Obtener descriptores desde la versión preliminar de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Obtener descriptores desde la versión preliminar de la explicación situacional. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para el registro o modificación de la sección "Descriptores de la situación actual" debe estar vigente. |
| Condiciones de salida | Descriptores de la versión preliminar de la explicación situacional registrados como descriptores de la situación actual. |
| Flujo básico | 1- El usuario pulsa la opción "Obtener descriptores desde la versión preliminar de la explicación situacional". 2- El sistema presenta por pantalla los descriptores registrados en la versión preliminar de la explicación situacional y las opciones "guardar" y "cancelar". 3- El usuario selecciona los descriptores de interés y pulsa la opción "guardar". 4- El sistema registra los descriptores seleccionados en la sección "Descriptores de la situación actual". 5- Si el usuario selecciona o no descriptores registrados en la versión preliminar de la explicación situacional y pulsa la opción "cancelar", el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
2.3.8 Caso de Uso: Obtener causas desde la versión preliminar de la explicación situacional.
Descripción textual
| Nombre del caso de uso | Obtener causas desde la versión preliminar de la explicación situacional. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para el registro o modificación de la sección "Causas de la situación actual" debe estar vigente. |
| Condiciones de salida | Causas de la versión preliminar de la explicación situacional registradas como causas de la situación actual. |
| Flujo básico | 1- El usuario pulsa la opción "Obtener causas desde la versión preliminar de la explicación situacional". 2- El sistema presenta por pantalla las causas registradas en la versión preliminar de la explicación situacional y las opciones "guardar" y "cancelar". 3- El usuario selecciona las causas de interés y pulsa la opción "guardar". 4- El sistema registra las causas seleccionados en la sección "Causa de la situación actual". 5- Si el usuario selecciona o no causas registradas en la versión preliminar de la explicación situacional y pulsa la opción "cancelar", el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
2.4 Casos de Uso para Gestionar Causas Críticas.
A continuación se presenta la descripción textual de estos casos de uso.
2.4.1 Caso de Uso: Registrar relaciones de causalidad entre las causas.
Descripción textual
| Nombre del caso de uso | Registrar relaciones de causalidad entre causas de la situación actual (matriz de interrelación sistémica). |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de las causas. II) La fecha para el registro o modificación de las relaciones de cuasalidad entre causas debe estar vigente. |
| Condiciones de salida | Relaciones de causalidad registradas. |
| Flujo básico | 1- El usuario pulsa la opción “Relaciones de causalidad entre causas ”. 2- El sistema presenta por pantalla una matriz cruzada con las causas que fueron registradas para la situación actual, y solicita se indique el grado de causalidad que ejercen cada una de las causas ubicadas en las filas de la matriz sobre cada una de las causas ubicadas en las columnas de la matriz [el sistema presenta dos opciones para el grado de causalidad: cero (0) que indica que una causa no ocasiona otra, y uno (1) que indica que una causa ocasiona otra]. El sistema presenta las opciones “guardar” y “cancelar”. 3- El usuario selecciona el grado de causalidad entre las causas y pulsa la opción “guardar”. 4- El sistema registra los datos ingresados y los presenta por pantalla. 5- Si el usuario ingresa información y presiona la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 4.1.- Si el usuario no ingresa ninguna relación de causalidad y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indique información a registrar. |
| Requisitos especiales | I) Es necesario que al principio del formulario se coloque el siguiente mensaje: “Se podrán realizar ingresos y/o modificaciones de las relaciones de causalidad entre las causas de la situación actual hasta la fecha [aquí hay que colocar la fecha válida para relaciones de causalidad entre causas]”. II) En la matriz el campo de relación de causalidad correspondiente a una misma causa debe estar bloqueado o anulado, ya que una causa no puede ser productora de ella misma. III) Las causa ubicadas en las filas de la matriz deben denominarse Causas Productoras, y las causas ubicadas en las columnas de la matriz deben denominarse Causas Derivadas. |
2.4.2 Caso de Uso: Consultar relaciones de causalidad entre las causas.
Descripción textual
| Nombre del caso de uso | Consultar relaciones de causalidad entre las causas (matriz de interrelación sistémica). |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir registro de relaciones de causalidad entre causas de la situación actual. |
| Condiciones de salida | Matriz de interrelación sistémica presentada por pantalla. |
| Flujo básico | 1.- El usuario pulsa la opción "Relaciones de causalidad entre causas ". 2.- El sistema despliega una pantalla donde presenta la matriz de interrelación sistémica con los grados de causalidad registrados. |
| Flujos alternativos | |
| Requisitos especiales |
2.4.3 Caso de Uso: Modificar relaciones de causalidad entre las causas.
Descripción textual
| Nombre del caso de uso | Modificar relaciones de causalidad entre las causas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I)Debe existir registro de relaciones de causalidad entre causas de la situación actual. II) La fecha para el registro o modificación de la relaciones de causalidad entre causas debe estar vigente. |
| Condiciones de salida | Modificación de las relaciones de causalidad en la matriz de interrelación sistémica. |
| Flujo básico | 1- El usuario pulsa la opción “Relaciones de causalidad entre causas". 2- El sistema presenta por pantalla la matriz de interrelación sistémica, activa los campos de la matriz para permitir la modificación de la misma, y muestra las opciones “guardar” y “cancelar”. 3- El usuario modifica la información de interés y pulsa la opción "guardar". 4- El sistema registra los datos y los presenta por pantalla. 5- Si el usuario modifica o no información y presiona la opción "cancelar" el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario no realiza ninguna modificación y pulsa la opción "guardar", el sistema no ejecuta ninguna acción. |
| Requisitos especiales |
2.4.4 Caso de Uso: Seleccionar posibles causas críticas.
Descripción textual
| Nombre del caso de uso | Seleccionar posibles causas críticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de las relaciones de causalidad entre todas las causas de la situación actual. II) La fecha para la selección de posibles causas críticas debe estar vigente. |
| Condiciones de salida | Listado de posibles causas críticas. |
| Flujo básico | 1- El usuario pulsa la opción “Seleccionar posibles causas críticas”. 2- El sistema realiza un cálculo en base a la matriz de interrelación sistémica para identificar las posibles causas críticas. 3- El sistema muestra por pantalla el listado de posibles causas críticas. |
| Flujos alternativos | |
| Requisitos especiales |
2.4.5 Caso de Uso: Consultar posibles causas críticas.
Descripción textual
| Nombre del caso de uso | Consultar posibles causas críticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el listado de posibles causas críticas. |
| Condiciones de salida | Listado de posibles causas críticas presentado en pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Posibles causas críticas”. 2- El sistema presenta por pantalla el listado de posibles causas críticas. |
| Flujos alternativos | |
| Requisitos especiales |
2.4.6 Caso de Uso: Seleccionar causas críticas.
Descripción textual
| Nombre del caso de uso | Seleccionar causas críticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el listado de posibles causas críticas. II) La fecha para la selección de causas críticas debe estar vigente. |
| Condiciones de salida | Listado de causas críticas. |
| Flujo básico | 1- El usuario pulsa la opción “Seleccionar causas críticas”. 2- El sistema presenta por pantalla el listado de posibles causas críticas, solicita se seleccione de este listado aquellas causas que se consideren críticas, y muestra las opciones “seleccionar” y “cancelar”. 3- El usuario selecciona las causas críticas y pulsa la opción “seleccionar”. 4- El sistema registra las causas críticas y las presenta por pantalla. 5- Si el usuario selecciona o no las causas críticas y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario no selecciona ninguna causa crítica y pulsa la opción "seleccionar", el sistema solicita se seleccionen causas críticas. |
| Requisitos especiales |
2.4.7 Caso de Uso: Consultar causas críticas (por parte de un actor macro).
Descripción textual
| Nombre del caso de uso | Consultar causas críticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Deben existir el listado de causas críticas. |
| Condiciones de salida | Listado de causas críticas presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Causas críticas”. 2- El sistema muestra por pantalla el listado de causas críticas y sus respectiva descripciones. Para cada causa el sistema muestra la opción “Descripción” (esta opción será descrita en otro caso de uso). |
| Flujos alternativos | |
| Requisitos especiales |
2.4.8 Caso de Uso: Consultar causas críticas (por parte de un actor micro).
Descripción textual
| Nombre del caso de uso | Consultar causas críticas. |
| Usuarios | Actor micro. |
| Condiciones de entrada | Deben existir el listado de causas críticas. |
| Condiciones de salida | Listado de causas críticas presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Causas críticas”. 2- El sistema muestra por pantalla el listado de causas críticas y sus respectiva descripciones. |
| Flujos alternativos | |
| Requisitos especiales |
2.4.9 Caso de Uso: Describir causas críticas.
Descripción textual
| Nombre del caso de uso | Describir causas críticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de las causas críticas. II) La fecha para la descripción de las causas críticas debe estar vigente. |
| Condiciones de salida | Registro de la descripción de las causas críticas. |
| Flujo básico | 1- El usuario pulsa la opción “Causas críticas”. 2- El sistema muestra por pantalla el listado de causas críticas registradas y presenta la opción “Descripción” para cada causa del listado. 3- El usuario pulsa la opción “Descripción” asociada a una causa de interés. 4- El sistema solicita que se indique, para la causa de interés, la información respectiva a las siguientes secciones: a) especificación de la causa, b) metas que se aspiran alcanzar en función de erradicar la causa o para disminuir los efectos de la misma, c) sectores sociales afectados por la causa, d) posibles formas de solución a la causa, e) palabras claves relacionadas a la causa. El sistema presenta por pantalla las opciones “guardar” y “cancelar”. 5- El usuario ingresa datos solicitados en cada sección y presiona la opción "guardar". 6- El sistema registra los datos y los presenta por pantalla. 7- Si el usuario registra o no los datos requeridos para una sección y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. 8- Los pasos 3, 4, 5 y 6 se repiten para cada una de las causas críticas registradas que se requiera describir. |
| Flujos alternativos | 5.1- Si el usuario omite los datos solicitados en cualquiera de las secciones y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita se indique la información requerida para la sección. |
| Requisitos especiales | I) Es necesario que al principio del formulario se coloque el siguiente mensaje: “Se podrá registrar y/o modificar las descripciones de las causas críticas hasta la fecha [aquí hay que colocar la fecha válida para la descripción de causas críticas]”. |
2.4.10. Caso de Uso: Modificar descripción de causa crítica.
Descripción textual
| Nombre del caso de uso | Modificar descripción de causa crítica. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir la descripción de la causa crítica que se requiere modificar. II) La fecha para la descripción de causas críticas debe estar vigente. |
| Condiciones de salida | Descripción de la causa crítica modificada. |
| Flujo básico | 1- El usuario pulsa la opción "Causas Críticas". 2- El sistema presenta el listado de causas críticas y muestra la opción “Descripción” para cada causa de listado. 3- El usuario pulsa la opción “Descripción” para una causa de interés. 4- El sistema presenta por pantalla la información registrada para cada una de las secciones que conforman la descripción de la causa, activa los campos de las secciones para permitir que se realice la modificación en cualquiera de ellas, y presenta las opciones “guardar” y “cancelar”.5- El usuario modifica la información requerida y pulsa la opción “guardar”. 6- El sistema registra los datos y los presenta por pantalla. 7- Si el usuario modifica o no datos y pulsa la opción “cancelar”, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 5.1- Si el usuario omite los datos requeridos en una sección de descripción de una causa y pulsa la opción “guardar” de la sección respectiva, el sistema muestra por pantalla un mensaje en el que solicita se indique los datos omitidos. |
| Requisitos especiales |
2.5 Casos de Uso para Gestionar Situación Ideal.
A continuación se presenta la descripción textual de estos casos de uso.
2.5.1 Caso de Uso: Registrar situación ideal.
Descripción textual
| Nombre del caso de uso | Registrar situación ideal. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para el registro o modificación de la situación ideal debe estar vigente. |
| Condiciones de salida | Información registrada de la situación ideal. |
| Flujo básico | 1- El usuario pulsa la opción “Situación ideal”. 2- El sistema despliega una pantalla donde solicita la descripción de la situación ideal y muestra la opción "guardar". 3- El usuario ingresa la descripción de la situación ideal y presiona la opción "guardar". 4- El sistema registra la información y la muestra por pantalla. 5- Si el usuario ingresa o no la descripción de la situación ideal y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario presiona la opción "guardar" sin ingresar la descripción de la situación ideal, el sistema presenta un mensaje en el que solicita se indique dicha descripción. |
| Requisitos especiales | I) Es necesario que al principio del formulario se coloque el siguiente mensaje: “Se podrá registrar y/o modificar la situación ideal hasta la fecha [aquí hay que colocar la fecha válida para la situación ideal]”. |
2.5.2 Caso de Uso: Consultar situación ideal.
Descripción textual
| Nombre del caso de uso | Consultar situación ideal. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | Debe existir registro de información de la situación ideal. |
| Condiciones de salida | Situación ideal presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Situación ideal". 2- El sistema presenta por pantalla el registro de la situación ideal. |
| Flujos alternativos | |
| Requisitos especiales |
2.5.3 Caso de Uso: Modificar situación ideal.
Descripción textual
| Nombre del caso de uso | Modificar situación ideal. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir registro de información de la situación ideal. II) La fecha para la situación ideal debe estar vigente. |
| Condiciones de salida | Situación ideal modificada. |
| Flujo básico | 1- El usuario pulsa la opción "Situación ideal". 2- El sistema presenta el registro de la situación ideal, activa el campo de este registro para permitir su modificación, y presenta la opción “guardar”. 3- El usuario modifica la información requerida y pulsa la opción “guardar”. 4- El sistema registra las modificaciones y las muestra por pantalla. 5- Si el usuario modifica o no la descripción de la situación ideal y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite la información respectiva a la descripción de la situación ideal y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indique dicha descripción. |
| Requisitos especiales |
2.6 Caso de Uso: Consultar situación objetivo.
Descripción textual
| Nombre del caso de uso | Consultar situación objetivo. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | I) Debe existir el registro de la descripción de todas las causas críticas. |
| Condiciones de salida | Descripción de la situación objetivo por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Situación objetivo”. 2- El sistema despliega una pantalla donde muestra un listado de todas las metas ingresadas en la descripción de las causas críticas. |
| Flujos alternativos | |
| Requisitos especiales |
3. Casos de Uso para el Proceso de Definición de Políticas Direccionales del Plan
3.1. Casos de Uso para Gestionar Necesidades.
A continuación se presenta la descripción textual de estos casos de uso.
3.1.1. Casos de Uso: Registrar necesidades.
Descripción textual
| Nombre del caso de uso | Registrar necesidades. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de la situación actual y de las causas críticas. II) La fecha para la definición de necesidades debe estar vigente. |
| Condiciones de salida | Necesidades registradas. |
| Flujo básico | 1- El usuario pulsa la opción “Registrar necesidades”. 2- El sistema despliega una pantalla donde solicita se indique la necesidad a registrar, así como la causa crítica y los descriptores de esta causa en función de los cuales se plantea la necesidad (para ello el sistema debe mostrar el listado de causas criticas, y una vez el usuario haya seleccionado la causa crítica el sistema debe mostrar el listado de descriptores de la causa seleccionada para que el usuario indique los descriptores a los cuales se asocia la necesidad a registrar). El sistema presenta las opciones "guardar" y "cancelar". 3- El usuario ingresa los datos solicitados y presiona la opción “guardar”. 4- El sistema registra los datos ingresados y los presenta por pantalla. 5- Si el usuario ingresa o no los datos solicitados y presiona la opción “cancelar”, el sistema no ejecuta ninguna acción. 6- Los pasos 1, 2, 3, 4 y 5 se repiten para cada necesidad a registrar. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados, o alguno de éstos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del registro de las necesidades se coloque el siguiente mensaje: “Se podrá registrar o modificar necesidades hasta la fecha [aquí hay que colocar la fecha válida para la definición de necesidades]”. II) Una necesidad puede estar asociada a varias causas y a varios descriptores de las causas. |
3.1.2. Casos de Uso: Consultar necesidades.
Descripción textual
| Nombre del caso de uso | Consultar necesidades. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir el registro de necesidades. |
| Condiciones de salida | Información de la necesidad consultada presentada por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Lista de necesidades". 2- El sistema presenta por pantalla el listado de necesidades, y para cada necesidad presenta las opciones “modificar” y “eliminar”. 3- Si el usuario pulsa sobre algunas de las necesidades el sistema presenta la información registrada para esa necesidad (descriptores y causas críticas) |
| Flujos alternativos | |
| Requisitos especiales | Las opciones “modificar” y “eliminar” serán presentadas por pantalla siempre y cuando la fecha para la definición de necesidades esté vigente. |
3.1.3. Casos de Uso: Modificar necesidades.
Descripción textual
| Nombre del caso de uso | Modificar necesidades. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de necesidades. II) La fecha para la definición de necesidades debe estar vigente. |
| Condiciones de salida | Necesidad modificada. |
| Flujo básico | 1- El usuario pulsa en la lista de necesidades la opción “modificar” para la necesidad que requiere modificar. 2- El sistema presenta por pantalla el registro de información de la respectiva necesidad, activa los campos de este registro para permitir que se realice la modificación y presenta las opciones “guardar” y “cancelar”. 3- El usuario modifica la información requerida y pulsa la opción “guardar”. 4- El sistema registra los datos modificados y los presenta por pantalla. 5- Si el usuario modifica o no los datos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en el registro de la necesidad, o alguno de ellos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales |
3.1.4. Caso de Uso: Eliminar necesidades.
Descripción textual
| Nombre del caso de uso | Eliminar necesidades. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para registrar y modificar necesidades debe estar vigente. |
| Condiciones de salida | Necesidad eliminada. |
| Flujo básico | 1- El usuario pulsa en la lista de necesidades la opción “eliminar” para la necesidad que requiere eliminar. 2- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar la necesidad seleccionada? y muestra las opciones “eliminar” y “cancelar”. 3- Si el usuario selecciona la opción “eliminar” la necesidad es borrada del listado de necesidades. 4- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
3.1.5. Caso de Uso: Buscar necesidades.
Descripción textual
| Nombre del caso de uso | Buscar necesidades. |
| Usuarios | Actor macro. |
| Condiciones de entrada | |
| Condiciones de salida | Registro de la necesidad de interés presentada por pantalla. |
| Flujo básico | 1- El usuario ingresa los parámetros de búsqueda correspondientes a los campos “causas críticas”, "descriptores de las causas críticas", “necesidad”, y pulsa la opción “buscar”. 2- El sistema presenta por pantalla el listado de necesidades que están relacionadas a los parámetros de búsqueda ingresados, y presenta las opciones “modificar” y “eliminar” para cada una de las necesidades del listado. 3- Si el usuario pulsa sobre alguna de las necesidades el sistema presenta por pantalla la información registrada sobre la misma. |
| Flujos alternativos | 1.1- Si el usuario no ingresa ningún parámetro de búsqueda y pulsa la opción “buscar”, el sistema solicita se indique algún parámetro. |
| Requisitos especiales | Las opciones “modificar” y “eliminar” son presentadas por pantalla siempre y cuando la fecha para la definición de necesidades se encuentre vigente. |
3.2 Casos de Uso para Gestionar Posibles Políticas Direccionales.
A continuación se presenta la descripción textual de estos casos de uso.
3.2.1. Casos de Uso: Registrar posibles políticas direccionales.
Descripción textual
| Nombre del caso de uso | Registrar posibles políticas direccionales. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de las necesidades. II) La fecha para la definición de posibles políticas debe estar vigente. |
| Condiciones de salida | Posibles políticas registradas. |
| Flujo básico | 1- El usuario pulsa la opción “Registrar posibles políticas”. 2- El sistema despliega una pantalla donde solicita se indique la necesidad (para ello el sistema muestra el listado de necesidades registradas) para la cual se formulará la posible política. Una vez indicada la necesidad el sistema muestra las causas críticas y las posibles formas de solución asociadas a éstas, a fin de que el usuario haga uso de esta información para indicar los siguientes datos solicitados por cada posible política a registrar: a) posible política, objetivos general y específicos; c) áreas de impacto; d) requerimientos necesarios para materializar la política (en este caso el sistema permite que se puedan indicar tres tipos de requerimientos: políticos (toma de decisiones), cognitivos, y tecnológicos), indicando por cada requerimiento los actores responsables del mismo y el grado de control que tienen sobre éste. El sistema presenta las opciones "guardar" y "cancelar". 3- El usuario ingresa los datos solicitados y presiona la opción “guardar”. 4- El sistema registra los datos ingresados y los presenta por pantalla y muestra la opción “Registrar posibles políticas”. 5- Si el usuario ingresa o no los datos solicitados y presiona la opción “cancelar”, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados, o alguno de éstos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del registro de las posibles políticas se coloque el siguiente mensaje: “Se podrá registrar o modificar posibles políticas hasta la fecha [aquí hay que colocar la fecha válida para la definición de posibles políticas]”. II) Una necesidad puede tener asociada varias políticas. III) El grado de control que tiene los actores sobre los requerimientos necesarios para materializar las posibles políticas debe ser expresados en términos de porcentaje. IV) El usuario debe indicar por lo menos uno de los tres tipos de requerimientos que muestra el sistema para una posible política. |
3.2.2. Casos de Uso: Consultar posibles políticas.
Descripción textual
| Nombre del caso de uso | Consultar posibles políticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir el registro de posibles políticas. |
| Condiciones de salida | Información presentada por pantalla de la posible política consultada. |
| Flujo básico | 1- El usuario pulsa la opción "Posibles políticas". 2- El sistema presenta por pantalla el listado de posibles políticas, y para cada posible política presenta las opciones “modificar” y “eliminar”. 3- Si el usuario pulsa sobre alguna de las posibles políticas el sistema presenta la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales | Las opciones “modificar” y “eliminar” serán presentadas por pantalla siempre y cuando la fecha para la definición de posibles políticas esté vigente. |
3.2.3. Casos de Uso: Modificar posibles políticas.
Descripción textual
| Nombre del caso de uso | Modificar posibles políticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de posibles políticas. II) La fecha para la definición de posibles políticas debe estar vigente. |
| Condiciones de salida | Posible política modificada. |
| Flujo básico | 1- El usuario pulsa en la lista de posibles políticas la opción “modificar” para la política que requiere modificar. 2- El sistema presenta por pantalla el registro de información de la respectiva posible política, activa los campos de este registro para permitir que se realice la modificación y presenta las opciones “guardar” y “cancelar”. 3- El usuario modifica la información requerida y pulsa la opción “guardar”. 4- El sistema registra los datos modificados y los presenta por pantalla. 5- Si el usuario modifica o no los datos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en el registro de la posible política, o alguno de ellos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales |
3.2.4. Caso de Uso: Eliminar posibles políticas.
Descripción textual
| Nombre del caso de uso | Eliminar posibles políticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | La fecha para la definición de posibles políticas debe estar vigente. |
| Condiciones de salida | Posible política eliminada. |
| Flujo básico | 1- El usuario pulsa la opción “eliminar” para la posible política que requiere eliminar. 2- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar la posible política seleccionada? y muestra las opciones “eliminar” y “cancelar”. 3- Si el usuario selecciona la opción “eliminar” la posible política es borrada del listado de posibles políticas. 4- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
3.2.5. Caso de Uso: Buscar posibles políticas.
Descripción textual
| Nombre del caso de uso | Buscar posibles políticas. |
| Usuarios | Actor macro. |
| Condiciones de entrada | |
| Condiciones de salida | Registro de la posible política de interés presentada por pantalla. |
| Flujo básico | 1- El usuario ingresa los parámetros de búsqueda correspondientes a los campos “necesidad”, “áreas de impacto”, “requerimientos”, “posible política” y pulsa la opción “buscar”. 2- El sistema presenta por pantalla el listado de posibles políticas que están relacionadas a los parámetros de búsqueda ingresados, y presenta las opciones “modificar” y “eliminar” para cada una de las posibles políticas del listado. 3- Si el usuario pulsa sobre alguna de las posibles políticas el sistema presenta por pantalla la información registrada sobre la misma. |
| Flujos alternativos | 1.1- Si el usuario no ingresa ningún parámetro de búsqueda y pulsa la opción “buscar” el sistema solicita se indique algún parámetro. |
| Requisitos especiales | Las opciones “modificar” y “eliminar” son presentadas por pantalla siempre y cuando la fecha para la definición de posibles políticas se encuentre vigente. |
3.3. Casos de Uso para Gestionar Políticas Direccionales.
A continuación se presenta la descripción textual de estos casos de uso.
3.3.1. Casos de Uso: Identificar inviabilidad de posibles políticas
Descripción textual
| Nombre del caso de uso | Identificar inviabilidad de posibles políticas |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de posibles políticas. II) La fecha para identificar inviabilidad de posibles políticas debe estar vigente. |
| Condiciones de salida | Políticas inviables presentadas por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Identificar políticas inviables”. 2- El sistema realiza un cálculo en base a los requerimientos necesarios para materializar las posibles políticas y en base al grado de control que se tiene sobre tales requerimientos, para determinar cuales políticas son inviables. 3- El sistema muestra por pantalla el listado de políticas inviables. |
| Flujos alternativos | |
| Requisitos especiales | Una política es inviable si los actores responsables de los requerimientos necesarios para materializar esta política no tienen control sobre todos o algunos de estos requerimientos. |
3.3.2. Casos de Uso: Registrar acciones para construir viabilidad de posibles políticas.
Descripción textual
| Nombre del caso de uso | Registrar acciones para construir viabilidad de posibles políticas |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el listado de posibles políticas inviables. II) La fecha para construir viabilidad a posibles políticas debe estar vigente. |
| Condiciones de salida | Registro de acciones para construcción de viabilidad de posibles políticas. |
| Flujo básico | 1- El usuario pulsa la opción “Registrar acciones para construcción de viabilidad a posibles políticas”. 2- El sistema solicita se indique la posible política inviable (para ello el sistema muestra el listado de posibles políticas inviables), las acciones necesarias para construir la viabilidad requerida, y muestra las opciones “guardar” y “cancelar”. 3- El usuario indica la información solicitada y pulsa la opción “guardar”. 4- El sistema registra la información y la presenta por pantalla. 5- Si el usuario ingresa o no los datos solicitados y presiona la opción “cancelar”, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | Si el usuario omite los datos solicitados, o alguno de éstos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | I) Es necesario que al principio del registro de acciones para construir viabilidad a posibles políticas se coloque el siguiente mensaje: “Se podrá registrar o modificar acciones para construcción de viabilidad a posibles políticas hasta la fecha [aquí hay que colocar la fecha válida para la construcción de viabilidad a posibles políticas]”. II) Una posible política puede tener asociada mas de una acción para construcción de viabilidad. |
3.3.3. Casos de Uso: Consultar acciones para construcción de viabilidad.
Descripción textual
| Nombre del caso de uso | Consultar acciones para construcción de viabilidad. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | Debe existir el registro de acciones para construcción de viabilidad. |
| Condiciones de salida | Acciones para construcción de viabilidad de una posible política presentadas por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Construcción de viabilidad". 2- El sistema solicita se indique la posible política para la cual se quiere consultar las acciones de construcción de viabilidad (para lo cual el sistema muestra el listado de posibles políticas). 3- El usuario indica la posible política de interés. 4- El sistema presenta por pantalla el listado de acciones para construcción de viabilidad de la posible política de respectiva, y muestra las opciones “modificar” y “eliminar” para cada acción. |
| Flujos alternativos | |
| Requisitos especiales | Las opciones “modificar” y “eliminar” serán presentadas por pantalla solo en caso de que el usuario corresponda a un actor macro y si la fecha para construir viabilidad a posibles políticas esta vigente. |
3.3.4. Casos de Uso: Modificar acciones de construcción de viabilidad para una posible política
Descripción textual
| Nombre del caso de uso | Modificar acciones de construcción de viabilidad para una posible política. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de acciones para construcción de viabilidad. II) La fecha para construir viabilidad a posibles políticas debe estar vigente. |
| Condiciones de salida | Acción para construcción de viabilidad modificada. |
| Flujo básico | 1- El usuario pulsa en la opción “modificar” de la acción que requiere modificar. 2- El sistema presenta por pantalla el registro de información de la respectiva acción, activa los campos de este registro para permitir que se realice la modificación y presenta las opciones “guardar” y “cancelar”. 3- El usuario modifica la información requerida y pulsa la opción “guardar”. 4- El sistema registra los datos modificados y los presenta por pantalla. 5- Si el usuario modifica o no los datos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en el registro de la acción, o alguno de ellos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales |
3.3.5. Caso de Uso: Eliminar acciones de construcción de viabilidad para una posible política.
Descripción textual
| Nombre del caso de uso | Eliminar acciones de construcción de viabilidad para una posible política. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de acciones para construcción de viabilidad. II) La fecha para construir viabilidad a posibles políticas debe estar vigente. |
| Condiciones de salida | Acción para construir viabilidad eliminada del sistema. |
| Flujo básico | 1- El usuario pulsa la opción “eliminar” para la acción de interés. 2- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar la acción seleccionada? y muestra las opciones “eliminar” y “cancelar”. 3- Si el usuario selecciona la opción “eliminar” la acción es borrada del listado de acciones para construir viabilidad a la posible política respectiva. 4- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
3.3.6. Casos de Uso: Seleccionar políticas direccionales.
Descripción textual
| Nombre del caso de uso | Seleccionar políticas direccionales. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el listado de posibles políticas direccionales. II) La fecha para la selección de políticas direccionales debe estar vigente. |
| Condiciones de salida | Listado de políticas direccionales. |
| Flujo básico | 1- El usuario pulsa la opción “Seleccionar políticas direccionales”. 2- El sistema presenta por pantalla el listado de posibles políticas direccionales, solicita se seleccione de este listado aquellos políticas que se consideren como potenciales o eficaces para lograr la situación objetivo del plan, y muestra las opciones “guardar” y “cancelar”. 3- El usuario selecciona políticas direccionales y pulsa la opción “guardar”. 4- El sistema registra los políticas direccionales y las presenta por pantalla. 5- Si el usuario selecciona o no políticas direccionales y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario no selecciona ninguna política direccional y pulsa la opción "guardar", el sistema solicita si indiquen políticas direccionales a seleccionar. |
| Requisitos especiales | Es necesario que al principio de la pantalla que presenta el sistema para la selección de políticas direccionales se coloque el siguiente mensaje: “Se podrá seleccionar políticas direccionales hasta la fecha [aquí hay que colocar la fecha válida para la selección de políticas direccionales]” |
3.3.7. Casos de Uso: Consultar políticas direccionales.
Descripción textual
| Nombre del caso de uso | Consultar políticas direccionales. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | Debe existir el listado de políticas direccionales. |
| Condiciones de salida | Listado de políticas direccionales presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción "Políticas direccionales". 2- El sistema presenta por pantalla el listado de políticas direccionales. 3- Si el usuario pulsa sobre alguna de las políticas direccionales el sistema presenta la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales |
3.3.8. Caso de Uso: Buscar políticas direccionales.
Descripción textual
| Nombre del caso de uso | Buscar políticas direccionales. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | |
| Condiciones de salida | Registro de la política direccional de interés presentada por pantalla. |
| Flujo básico | 1- El usuario ingresa parámetros de búsqueda en los campos “necesidad”, “áreas de impacto”, “requerimientos”, “política”, y pulsa la opción “buscar”. 2- El sistema presenta por pantalla el listado de políticas que están relacionadas a los parámetros de búsqueda ingresados. 3- Si el usuario pulsa sobre alguna de las políticas el sistema presenta por pantalla la información registrada sobre la misma. |
| Flujos alternativos | 1.1- Si el usuario no ingresa ningún parámetro de búsqueda y pulsa la opción “buscar” el sistema solicita se indique algún parámetro. |
| Requisitos especiales |
3.4. Casos de Uso para Gestionar Estrategias de Materialización de Políticas Direccionales.
A continuación se presenta la descripción textual de estos casos de uso.
3.4.1. Casos de Uso: Registrar posibles estrategias
Descripción textual
| Nombre del caso de uso | Registrar posibles estrategias. |
| Usuarios | Actor micro. |
| Condiciones de entrada | I) Debe existir el listado de políticas direccionales. II) La fecha para el registro de posibles estrategias para materializar políticas direccionales debe estar vigente. |
| Condiciones de salida | Posibles estrategias registradas. |
| Flujo básico | 1- El usuario pulsa la opción “Registrar posible estrategia”. 2- El sistema solicita se indique la política direccional (para ello el sistema presenta el listado de políticas direccionales) para la cual se planteará la posible estrategia, muestra las necesidades que se abordan con dicha política, solicita se indique la posible estrategia y los actores que plantean la misma (para ello el sistema muestra el listado de actores registrados en el sistema), así como las áreas de impacto y palabras claves asociadas a ésta. El sistema presenta las opciones “guardar”, “cancelar” y "registrar posible estrategia". 3- El usuario ingresa la información solicitada y pulsa la opción “guardar”. 4- El sistema registra la información y la presenta por pantalla. 5- Si el usuario ingresa o no información y pulsa la opción “cancelar”, el sistema no ejecuta ninguna acción. 6- Si el usuario pulsa la opción "registrar posible estrategia" se repiten los pasos 2, 3, 4 y 5 para la nueva estrategia a registrar. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados, o alguno de éstos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | Es necesario que al principio del registro de posibles estrategias se coloque el siguiente mensaje: “Se podrá registrar posibles estrategias hasta la fecha (aquí hay que colocar la fecha válida para la definición de posibles estrategias). |
3.4.2. Caso de Uso: Consultar posibles estrategias.
Descripción textual
| Nombre del caso de uso | Consultar posibles estrategias. |
| Usuarios | Actor micro. |
| Condiciones de entrada | Debe existir el registro de posibles estrategias. |
| Condiciones de salida | Registro de posible estrategia presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Posibles estrategias”. 2- El sistema solicita se indique la política direccional (para ello el sistema presenta el listado de políticas direccionales) para la cual se requiere consultar posibles estrategias. 3- El sistema presenta por pantalla el listado de posibles estrategias registradas para la política indicada, mostrando para cada una de éstas la opción "observaciones", y para las posibles estrategias presentadas por pantalla que hayan sido registradas por el usuario presenta las opciones “modificar” y “eliminar”. 4- Si el usuario pulsa sobre algunas de las posibles estrategias presentadas por pantalla el sistema muestra la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales | Las opciones “modificar” y “eliminar” serán presentadas por pantalla siempre y cuando la fecha para modificar estrategias esté vigente. |
3.4.3. Caso de Uso: Consultar posibles estrategias.
Descripción textual
| Nombre del caso de uso | Consultar posibles estrategias. |
| Usuarios | Actor macro. |
| Condiciones de entrada | Debe existir el registro de posibles estrategias. |
| Condiciones de salida | Registro de posible estrategia presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Posibles estrategias”. 2- El sistema solicita se indique la política direccional (para ello el sistema presenta el listado de políticas direccionales) para la cual se requiere consultar posibles estrategias. 3- El sistema presenta por pantalla el listado de posibles estrategias registradas para la política indicada, mostrando para cada una de éstas la opción "observaciones". 4- Si el usuario pulsa sobre algunas de las posibles estrategias presentadas por pantalla el sistema muestra la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales |
3.4.4. Caso de Uso: Modificar posibles estrategias.
Descripción textual
| Nombre del caso de uso | Modificar posibles estrategias. |
| Usuarios | Actor micro. |
| Condiciones de entrada | I) Debe existir registro de posibles estrategias. II) La fecha para la modificación de posibles estrategias debe estar vigente. |
| Condiciones de salida | Posible estrategia modificada. |
| Flujo básico | 1- El usuario pulsa la opción “modificar” de la posible estrategia que requiere modificar. 2- El sistema presenta por pantalla el registro de información de la respectiva estrategia, activa los campos de este registro para permitir que se realice la modificación y presenta las opciones “guardar” y “cancelar”. 3- El usuario modifica la información requerida y pulsa la opción “guardar”. 4- El sistema registra los datos modificados y los presenta por pantalla. 5- Si el usuario modifica o no los datos requeridos y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario omite los datos solicitados en el registro de la posible estrategia, o alguno de ellos, y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indiquen los datos omitidos. |
| Requisitos especiales | Es necesario que al principio del formulario de la posible estrategia se coloque el siguiente mensaje: “Se podrá modificar posibles estrategias hasta la fecha [aquí hay que colocar la fecha válida para la modificación de posibles estrategias]” |
3.4.5. Caso de Uso: Eliminar posibles estrategias.
Descripción textual
| Nombre del caso de uso | Eliminar posibles estrategias. |
| Usuarios | Actor micro. |
| Condiciones de entrada | I) Debe existir el registro de posibles estrategias. II) La fecha para registrar o para modificar posibles estrategias debe estar vigente. |
| Condiciones de salida | Posible estrategia eliminada. |
| Flujo básico | 1- El usuario pulsa la opción “eliminar” para la posible estrategia de interés. 2- El sistema pregunta al usuario a través de un mensaje ¿Está seguro de querer eliminar la posible estrategia seleccionada? y muestra las opciones “eliminar” y “cancelar”. 3- Si el usuario selecciona la opción “eliminar” la posible estrategia esta es borrada del listado presentado por pantalla. 4- Si el usuario selecciona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
3.4.6. Caso de Uso: Identificar similitud entre posibles estrategias.
Descripción textual
| Nombre del caso de uso | Identificar similitud entre posibles estrategias. |
| Usuarios | Actor micro. |
| Condiciones de entrada | I) Debe existir el registro de posibles estrategias. II) La fecha para registrar posibles estrategias debe haber caducado. |
| Condiciones de salida | Listado de posibles estrategias que guardan similitud entre ellas presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Similitud entre posibles estrategias”. 2- El sistema identifica las posibles estrategias registradas en el sistema que son similares a las posibles estrategias registradas por el usuario en el sistema, y presenta éstas por pantalla. 3- Si el usuario pulsa sobre alguna de las posibles estrategias presentadas por pantalla el sistema muestra la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales | La similitud entre posibles estrategias se identifica en base a las áreas de impacto y las palabras claves registradas para cada posible estrategia. |
3.4.7. Caso de Uso: Identificar similitud entre posibles estrategias.
Descripción textual
| Nombre del caso de uso | Identificar similitud entre posibles estrategias. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de posibles estrategias. II) La fecha para registrar posibles estrategias debe haber caducado. |
| Condiciones de salida | Listado de posibles estrategias que guardan similitud entre ellas presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Similitud entre posibles estrategias”. 2- El sistema presenta las opciones "estrategias similares por política" y "estrategias similares entre políticas". 3- Si el usuario pulsa la opción "estrategias similares por política" el sistema muestra por pantalla para cada política las posibles estrategias que son similares entre ellas, si el usuario pulsa sobre algunas de estas posibles estrategias el sistema presenta por pantalla la información registrada para la misma. 4- Si el usuario pulsa la opción "estrategias similares entre políticas" el sistema muestra por pantalla las posibles estrategias entre políticas que son similares entre ellas, si el usuario pulsa sobre algunas de estas posibles estrategias el sistema presenta por pantalla la información registrada para la misma. |
| Flujos alternativos | |
| Requisitos especiales | La similitud entre posibles estrategias se identifica en base a áreas de impacto y palabras claves registradas para cada posible estrategia. |
3.4.8. Caso de Uso: Registrar observaciones para una posible estrategia.
Descripción textual
| Nombre del caso de uso | Registrar observaciones para una posible estrategia. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | I) Debe existir registro de posibles estrategias. |
| Condiciones de salida | Observación registrada. |
| Flujo básico | 1- El usuario pulsa la opción “Observaciones” en la posible estrategia de interés. 2- El sistema muestra las observaciones registradas hasta ese momento para la posible estrategia, así como los actores que han registrado estas observaciones. Adicionalmente, solicita se indique una nueva observación y presenta las opciones “guardar” y “cancelar”. 3- El usuario ingresa la observación y pulsa la opción “guardar”. 4- El sistema registra la observación y la presenta por pantalla. 5- Si el usuario ingresa o no la observación y presiona la opción “cancelar” el sistema no ejecuta ninguna acción. |
| Flujos alternativos | 3.1- Si el usuario no ingresa alguna observación y pulsa la opción “guardar”, el sistema muestra por pantalla un mensaje en el que solicita se indique alguna observación a registrar. |
| Requisitos especiales |
3.4.9. Caso de Uso: Seleccionar estrategias para materializar políticas direccionales.
Descripción textual
| Nombre del caso de uso | Seleccionar estrategias para materializar políticas direccionales. |
| Usuarios | Actor macro. |
| Condiciones de entrada | I) Debe existir el registro de posibles estrategias. II) La fecha para registrar o para modificar posibles estrategias debe haber caducado. |
| Condiciones de salida | Listado de estrategias para materializar políticas direccionales. |
| Flujo básico | 1- El usuario pulsa la opción “Seleccionar estrategias”. 2- El sistema solicita se indique la política para la cual se requiere seleccionar estrategias (para ello el sistema presenta el listado de políticas ). 3- El usuario indica la política de interés. 4- El sistema presenta por pantalla el listado de posibles estrategias asociadas a la política indicada por el usuario, solicita se seleccione de este listado las estrategias que permitan materializar la política respectiva, y presenta las opciones “guardar” y “cancelar”. 5- El usuario selecciona las estrategias de interés y pulsa la opción “guardar”. 6- El sistema registra las estrategias seleccionadas. 7- Si el usuario selecciona o no estrategias y pulsa la opción “cancelar”, el sistema no ejecuta ninguna acción. |
| Flujos alternativos | |
| Requisitos especiales |
3.4.10. Caso de Uso: Consultar estrategias para materializar políticas direccionales.
Descripción textual
| Nombre del caso de uso | Consultar estrategias para materializar políticas direccionales. |
| Usuarios | Actor macro, actor micro. |
| Condiciones de entrada | Debe existir el listado de estrategias para materializar políticas direccionales. |
| Condiciones de salida | Listado de estrategias para materializar una política direccional presentado por pantalla. |
| Flujo básico | 1- El usuario pulsa la opción “Estrategias por política”. 2- El sistema solicita se indique la política direccional (para ello el sistema presenta el listado de políticas direccionales) para la cual se requiere consultar estrategias. 3- El sistema presenta por pantalla el listado de estrategias asociadas a la política indicada por el usuario. 4- Si el usuario pulsa sobre alguna de la estrategias del listado, el sistema presenta por pantalla la información registrada para la estrategia respectiva correspondiente a los siguientes campos: “política direccional”, “necesidades”, “actores que plantean la estrategia”, “áreas de impacto” y “palabras claves”. |
| Flujos alternativos | |
| Requisitos especiales |
