ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

REQUERIMIENTOS NO FUNCIONALES


Enviado por   •  28 de Octubre de 2017  •  Documentos de Investigación  •  4.012 Palabras (17 Páginas)  •  537 Visitas

Página 1 de 17
  1. REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida, concurrencia de usuarios, disponibilidad del sistema y las representaciones de datos que se utilizan en las interfaces del sistema.

Esta sección detalla los requerimientos técnicos no funcionales que debe cubrir toda la arquitectura propuesta.

11.1 PROCESOS DE NEGOCIO

Definiciones funcionales que se deben cumplir. Y o restricciones.

11.2 APLICACIONES

Se definen Requerimientos No Funcionales Manifiestos como aquellas características del sistema que afectan la calidad del servicio y la forma como el sistema se comporta desde el punto de vista del usuario final. Dentro de este grupo se tienen en cuenta los siguientes factores: Desempeño, Disponibilidad, y Usabilidad.

  • Desempeño

Por desempeño se hace referencia a la habilidad del sistema de procesar las operaciones de un usuario individual dentro de unos tiempos de respuesta deseados. Para las aplicaciones del proyecto CORE se definen cuatro operaciones básicas que deben cumplir con tiempos de respuesta deseados.

PROCESO

TIEMPO DE RESPUESTA MÁXIMO ACEPTADO

100 Mbps

Presentación de pantallas con información descriptiva o informativa. (Árboles jerárquicos)

Entre 5 y 10 segundos

Presentación de formularios y pantallas de Administración

Entre 5 y 10 segundos.

Validación y confirmación de datos enviados.

Entre 5 y 15 segundos.



  • Disponibilidad

Por disponibilidad se hace referencia al período en el cual el sistema debe estar en operación para ser utilizado por el usuario final, es decir, la proporción de tiempo que el sistema debe estar en condiciones funcionales. para las aplicaciones del proyecto CORE se requiere una disponibilidad permanente.

  • Usabilidad 

Por usabilidad se hace referencia a la forma como el usuario final debe interactuar con el sistema. Los requerimientos de usabilidad definidos para este sistema son:

Imagen Corporativa.

El sistema debe tener el logo oficial de Salud Vida EPS, además de un icono identificador alusivo al logo y la plataforma usada.

Capacidad de selección, pegado y copiado de texto.

El sistema permite las opciones de edición de texto (selección, copiado y pegado de texto) en las secciones de las diferentes aplicaciones donde no suponga un riesgo de seguridad.

4. REQUERIMIENTOS NO FUNCIONALES OPERACIONALES

Se definen como requerimientos no funcionales operacionales aquellas características que afectan al sistema en tiempo de ejecución pero que pueden no ser visibles directamente por el usuario final. Los requerimientos no funcionales operacionales definidos para las aplicaciones del proyecto CORE son: robustez, escalabilidad, seguridad, e interoperabilidad.

  • Robustez 

Por robustez se hace referencia a la capacidad del sistema de continuar en operación a pesar de la entrada de datos inválidos o fallos en los diferentes componentes que lo conforman.

Tolerancia a datos inválidos.  

La capacidad del sistema para tolerar tipos de datos invalidados se evalúa cuando los datos son ingresados por el usuario en cada uno de los diferentes campos de los formularios.

A continuación se describen las validaciones que debe tener en cuenta el sistema:

  • Verificación de campos obligatorios:

El sistema debe verificar que los datos correspondientes a los campos obligatorios de los formularios fueron ingresados por el usuario final.

  • Verificación de campos numéricos.

El sistema debe verificar que los campos correspondientes a datos exclusivamente numéricos no contengan caracteres de texto o caracteres especiales tales como comas, puntos, asteriscos.

  • Verificación de reglas de negocio.

En algunos casos el contenido de uno o varios campos de los formularios son válidos si cumplen con unas reglas propias del negocio. El sistema debe hacer uso de estas reglas para validar la integridad de la información ingresada.

  • Escalabilidad

Por escalabilidad se hace referencia a la capacidad del sistema de crecer sin desmejorar la calidad del servicio que presta.

  • Número de Usuarios Concurrentes

Según las especificaciones sobre número de usuarios, se determinó que el máximo volumen concurrente de usuarios debe ser de X.

  • Espacio de almacenamiento requerido

El sistema debe estar en la capacidad de manejar un volumen de datos almacenados de hasta X TB.

ATRIBUTO DE CALIDAD

ID REQ

DESCRIPCIÓN

Concurrencia

RNF_001

Se debe garantizar que los servicios web de consulta o transaccionalidad se ejecuten en forma correcta, sin presentar caídas en el servicio o inconsistencias en la transaccionalidad para al menos XXXX peticiones concurrentes en un minuto.

RNF_002

Se debe garantizar que los aplicativos soporten transacciones en simultáneo de forma correcta, sin presentar caídas en el servicio o inconsistencias para al menos XXXX usuarios concurrentes en una hora

Desempeño

RNF_XXX

Tiempos de Respuesta:

Web services de consultas/transacciones deben cumplir los siguientes tiempos:

  • El 90% de las peticiones deben responder en menos de 2 segundos inclusive.
  • El 95% de las peticiones deben responder en menos de 3 segundos inclusive.
  • El 99.99% de las peticiones deben responder en menos de 5 segundos inclusive.

Petición: Se entiende por transacción la ejecución de un método expuesto por un servicio web

Procesos Batch

Toda transacción o proceso que tenga una duración mayor o igual a 5 minutos se debe ejecutar en background y tener la posibilidad de monitorear el avance por medio de la aplicación.

Se debe tener los siguientes controles para cada ejecución:

  • Registro de inicio del proceso, fecha y hora, y usuario que lanzo la petición
  • Los procesos se deben poder cancelar de forma controlada, realizando roll back de la transacción y se debe almacenar el registro de auditoria de quien lanzo la cancelación.
  • Dependiendo del proceso se debe ejecutar por lotes con una cantidad de registros delimitada, si es posible ejecutarlos en paralelo.
  • Los procesos deben tener reenganche.

Registro de finalización del proceso, fecha y hora, y usuario que lanzo la petición

Disponibilidad

Mantenibilidad

Integridad

Portabilidad

El aplicativo web se debe visualizar de forma correcta en los navegadores:

•        Google Chrome         Versión 52 o superior

•        Mozilla Firefox         Versión 48 o superior

•        Internet Explorer         Versión IE11

Nota: Se debe visualizar en las versiones anteriores de los navegadores.

Los aplicativos deben ser adaptables (Responsive Web Design) en su capa de presentación, para lograr las transacciones desde cualquier dispositivo.

Interoperabilidad

El formato para la transferencia de imágenes debe ser .tif entre aplicaciones

Timeout web services: se debe tener manejo de timeout en la ejecución de los servicios en base de datos, el cual sea configurable desde un archivo de propiedades y tabla de parametrización. Este tiempo debe definirse de acuerdo al timeout que tenga establecido el cliente, en ningún caso puede ser mayor

Tiempo Inicial de Timeout Consultas/Transacciones:         10 Segundos

Las transacciones deben tener reintentos controlados de la siguiente manera:

  • Verificar que el servicio se encuentre disponible.
  • Si no se encuentra disponible debe almacenar las peticiones en base de datos, para luego ser reprocesadas.
  • Si no se encuentra disponible la base de datos, se debe crear un archivo con fecha y hora de la indisponibilidad en el nombre del archivo, por día. Se debe crear un archivo plano donde se registren las peticiones.
  • Sebe revisar cada 30 minutos si el servicio se encuentra disponible y reprocesar las peticiones del archivo.

Nota: No aplica para consultas; se detallarán en la etapa de diseño para los procesos que lo requieran

...

Descargar como (para miembros actualizados) txt (27 Kb) pdf (297 Kb) docx (29 Kb)
Leer 16 páginas más »
Disponible sólo en Clubensayos.com