Ing. Karina Mero Suárez – UNESUM

Fase de Requerimientos

En esta fase se realiza el recogimiento de las necesidades del cliente y el usuario. Que es lo que desea que el software realice. Hay que tener muy en cuenta que existen requerimientos funcionales y no funcionales.

 Los requerimientos no funcionales hacen relación a las características del sistema que aplican de manera general como un todo, más que a rasgos particulares del mismo. Estos requerimientos son adicionales a los requerimientos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la disponibilidad,mantenibilidad, flexibilidad, seguridad, facilidad de uso, etc.  Los requerimientos no funcionales deberán ser detallados aún más durante la fase de diseño del Sistema de Información.

 

1.1 Atributos de Calidad del Sistema

Desempeño:

  • Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático a los diferentes usuarios a nivel nacional. En este sentido la información almacenada podrá ser consultada y actualizada permanente y simultáneamente, sin que se afecte el tiempo de respuesta.
  • El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios y a los procesos batch con tiempo de respuesta aceptable y uniforme, en la medida de las posibilidades tecnológicas de la PGN, en períodos de alta, media y baja demanda de uso del sistema.

Disponibilidad:

  • Estar disponible 100% o muy cercano a esta disponibilidad durante el horario hábil laboral, con excepción de los días festivos).
  • Operar de la misma manera para todos los niveles de la estructura jerárquica.

 Escalabilidad:

  • El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser  incorporados afectando el código existente de la menor manera posible; para ello deben  incorporarse aspectos de reutilización de componentes.
  • El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial.

Facilidad de Uso e Ingreso de Información:

  • El sistema debe ser de fácil uso  y entrenamiento por parte de los usuarios, así como de fácil adaptación de la entidad con el mismo.
  • El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subprocesos y tareas relacionados, hayan sido terminados y cerrados satisfactoriamente.
  • El ingreso de información al sistema debe diseñarse con transacciones que permitan el ingreso de los datos de forma parcial; es decir, que el tamaño de las páginas de registro (o formularios) de información sean adecuadas de acuerdo con la estabilidad de la red.
  • El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error y comunicarse con el administrador del sistema.

Facilidad para las Pruebas:

  • El sistema debe contar con facilidades para la identificación de la localización de los errores durante la etapa de pruebas y de operación posterior.

Flexibilidad:

  • El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos, de tal manera que la administración del sistema sea realizada por un administrador funcional del sistema.

Instalación: 

  • El sistema debe ser fácil de instalar en todas las plataformas de hardware y software de base definidas por el área de Sistemas, así como permitir su instalación en diferentes tamaños de configuraciones.

Mantenibilidad:

  • Toda el sistema deberá estar complemente documentado, cada uno de los componentes de software que forman parte de la solución propuesta deberán estar debidamente documentados tanto en el código fuente como en los manuales de administración y de usuario.
  • El sistema debe contar con una interfaz de administración que incluya: Administración de usuarios, Administración de módulos y Administración de parámetros. En cada una de éstas secciones deberá ofrecer todas las opciones de administración disponibles para cada uno.
  • El sistema debe estar en capacidad de permitir en el futuro su fácil mantenimiento con respecto a los posibles errores que se puedan presentar durante la operación del sistema.

Operatividad:

  • El sistema debe ser de fácil operación por el área técnica de la Oficina de Sistemas,  y que demande un bajo nivel de soporte de los usuarios del sistema.
  • El sistema deberá poder ser administrado remotamente por las personas encargadas o designadas (este requerimiento dependerá de la arquitectura seleccionada.

Seguridad:

  • La seguridad del sistema debe estar regida por las Políticas de Seguridad Informática de la Comisión Intersectorial de Políticas y Gestión de la Información para la Administración Pública.
  • El acceso al Sistema debe estar restringido por el uso de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al Sistema las  personas que estén registradas, estos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas para cada rol.
  • El control de acceso implementado debe permitir asignar los perfiles para cada uno de los roles identificados.
  • Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar accesos o codificaciones indebidos (no autorizados) a la información y proveer los servicios requeridos por los usuarios legítimos del sistema.
  • El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron.
  • El sistema debe contar con pistas de auditoría de las actividades que se realizan sobre el sistema con niveles razonables para su reconstrucción e identificación de los hechos.

Validación de Información:

  • El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc.

 

Otros Requerimientos No Funcionales

Arquitectura:

  • La solución debe ser 100% Web Based y toda la parametrización y administración debe realizarse desde un navegador.
  • La solución debe operar de manera independiente del navegador que se utilice.
  • La solución debe tener interfaces gráficas de administración y de operación en idioma español y en ambiente 100% Web, para permitir su utilización a través de exploradores o navegadores de Internet.
  • La información de los formularios que corresponda a listas de selección deberá ser parametrizada y administrable.

Backups:

  • El sistema deberá proveer mecanismos para generar backup´s periódicamente de la información que se mantiene en el sistema.  Los backup’s deben ser responsabilidad del administrador del sistema quien deberá crearlos, almacenarlos y recuperar la información en el caso que se pierda información.

Integración:

  • La solución deberá integrarse a la página Web que defina.  Dicha integración corresponde a un link desde la página del sitio Web (Portal), hacia el Sistema de Información  Misional. 

Interoperabilidad:

  • El sistema debe estar en capacidad de interactuar con los otros sistemas y con sistemas de entidades externas a través de la herramienta de middleware seleccionada para el sistema. La Interoperabilidad debe estar regida por la normas de Arquitectura de Integración e Interoperabilidad de la Comisión Intersectorial de Políticas y Gestión de la Información para la Administración Pública.

 Otros Requerimientos:

  • Facilidades y controles para permitir el acceso a la información al personal autorizado de otras entidades del estado a través de Internet,  con el propósito de consultar la información pertinente para cada una de ellas.
  • Facilidades para poder adelantar discusiones electrónicas a través de foros o salas de conversación sobre casos en particular que se adelanten y registrar la participación de los asistentes.
  • Contar con herramientas de software para la administración automática de archivos.
  • Contar con herramientas y características necesarias para su administración, la realización de búsquedas y la posibilidad de realizar consultas de índole general.
  • El diseño gráfico de los sistemas debe responder al diseño oficial de la Procuraduría.
  • El sistema debe propender por el desarrollo de la cultura que minimice el uso del papel. Para ello, hasta donde sea posible, deberá hacer uso de las diferentes características de la tecnología, tales como documentos electrónicos, imágenes digitales, buscando minimizar la sobrecarga de las redes de transporte de datos.
  • Facilidades y controles para permitir el acceso a la información al personal autorizado de otras entidades del estado a través de Internet,  con el propósito de consultar la información pertinente para cada una de ellas.
  • Garantizar que el diseño de las consultas no afecte el desempeño de la base de datos, ni considerablemente el tráfico de la red.
About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Nube de etiquetas

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: