Ejemplos de Requerimientos | Ingeniería de Requisitos

Ejemplos de Requerimientos funcionales:

A continuación se presentan diferentes ejemplos de requerimientos funcionales.

Ejemplos de requerimientos funcionales de proceso o área de negocio:

El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente.
Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.
Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el sistema.
El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas de proyecto.
El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto.
El sistema permitirá el envío automatizado de cartas de entrega de órdenes directamente al almacén.
La pantalla de registro de pago puede imprimir los datos en pantalla a la impresora.
Se mostrará el nombre, tamaño total, espacio disponible y formato de un pen drive o flash drive conectado al puerto USB del computador.

Ejemplos de requerimientos funcionales legales o regulatorios:

El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados.

La base de datos será implementada con trazas de auditoría.

Las hojas de cálculo aseguraran los datos usando firmas electrónicas.

El sistema permitirá elaborar y emitir el reporte regulatorio XX, según los requerimientos establecidos en el reglamento y ley aplicable.

Los libros de venta y de compras serán emitidos en el formato establecido por las autoridades tributarias de dicha materia.

Ejemplos de requerimientos de seguridad:

El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados. Los usuarios deben ingresar al sistema con un nombre de usuario y contraseña.
El sistema enviará una alerta al administrador del sistema cuando ocurra alguno de los siguientes eventos: Registro de nueva cuenta, ingreso al sistema por parte del cliente, 2 o más intentos fallidos en el ingreso de la contraseña de usuario y cambio de contraseña de usuario.
Los integrantes del grupo de usuarios de analistas pueden ingresar solicitudes pero no pueden aprobarlas o borrarlas.
Los integrantes del grupo de usuarios de gerentes pueden ingresar y aprobar solicitudes, pero no pueden borrarlas.
Los integrantes del grupo de usuario de administradores no pueden ingresar o aprobar solicitudes, pero si pueden borrarlas.
Cualquier intercambio de datos vía internet que realice el software se realizará por medio del protocolo encriptado https.

Ejemplos de requerimientos de interfaces externas (Hardware y Software):

El software podrá ser utilizado en los sistemas operativos Windows, Linux y OSX.

La aplicación debe poder utilizarse sin necesidad de instalar ningún software adicional además de un navegador web.

La aplicación debe poder utilizarse con los navegadores web Chrome, Firefox e Internet Explorer.

Ejemplos de Requerimientos no funcionales

Algunos ejemplos de requerimientos no funcionales son:

Comprobabilidad: Grado en que un sistema, software o servicio de TI permite y facilita que sea probado en un determinado contexto.

Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado en un período determinado. También puede definirse el grado en que un sistema está en un estado operable definido cada vez que se necesite.

Extensibilidad: Grado en que la implementación del sistema toma en consideración y facilita su crecimiento en el futuro.

Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una creciente carga de trabajo, por ejemplo mayor número de conexiones o usuarios. No debe confundirse con extensibilidad, que mide la capacidad del sistema de crecer en funcionalidades.

Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al producto (en este caso al software o servicio de TI), con la finalidad de: Desarrollar nuevos requerimientos, Aislar los defectos y sus causas, corregir estos defectos y atender las demandas del entorno cambiante.

Seguridad: Grado de protección de los datos, software y plataforma de tecnología de posibles pérdidas, actividades no permitidas o uso para propósitos no establecidos previamente.

Usabilidad: Definido cómo la facilidad de uso y aprendizaje de un Sistema, Software o Servicio de Tecnología de Información.

Ejemplos de requerimientos no funcionales de producto

Eficiencia

El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio de la herramienta SoapUI aplicada al Software Testing de servicios web.
Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5 segundos.
El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes.
Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en menos de 2 segundos.

Seguridad lógica y de datos

Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a datos.
El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación que incrementen la seguridad de datos.
Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser almacenados en una localidad segura ubicada en un edificio distinto al que reside el sistema.
Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas utilizando el algoritmo RSA.
Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser desbloqueado por un administrador de seguridad.

Seguridad industrial

El sistema no continuará operando si la temperatura externa es menor a 4 grados Celsius.
El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).

Usabilidad

El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones totales ejecutadas en el sistema.
El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.
El sistema debe contar con un módulo de ayuda en línea.
El sistema debe poseer interfaces gráficas bien formadas.

Dependibilidad

El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente accederlo.
El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos.
El promedio de duración de fallas no podrá ser mayor a 15 minutos.

Otros ejemplos de requerimientos de producto

El sistema será desarrollado para las plataformas PC y Macintosh.
La aplicación debe ser compatible con todas las versiones de Windows, desde Windows XX.
La aplicación deberá consumir menos de 500 Mb de memoria RAM.
La aplicación no podrá ocupar más de 2 GB de espacio en disco.

Ejemplos de requerimientos no funcionales organizacionales

El procedimiento de desarrollo de software a usar debe estar definido explícitamente (en manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
La metodología de desarrollo de software será XXXXX.
El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
El proceso de desarrollo se gestionará por medio de una determinada herramienta web para gestionar el proceso de desarrollo de software.
Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre el esfuerzo invertido en cada uno de los componentes del nuevo sistema.
Las pruebas de software se gestionaran con una herramienta de gestión de software testing.

Ejemplos de requerimientos no funcionales externos

Sistemas de datos médicos: El nuevo sistema y sus procedimientos de mantenimiento de datos deben cumplir con las leyes y reglamentos de protección de datos médicos.
El nuevo sistema se acogerá a las reglas de las licencias generales públicas (GNU), es decir será gratuito, código abierto en el que cualquiera podrá cambiar el software, sin patentes y sin garantías.
Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en condiciones de igualdad para personas con discapacidad.
El sistema no revelara a sus operadores otros datos personales de los clientes distintos a nombres y números de referencia.

Requerimientos no funcionales y requerimientos funcionales

Los requerimientos no funcionales suelen expresarse de una manera general y sin hacer referencia a algún modulo, transacción o característica del sistema, pues sino pasarían a ser requerimientos funcionales. Por ejemplo:

El sistema debe asegurar que los datos estén protegidos del acceso no autorizado.

Es recomendable acompañar las definiciones de requerimientos no funcionales con criterios de aceptación que puedan medirse.

Los requerimientos no funcionales pueden a su vez derivar en requerimientos funcionales, tomando como ejemplo el anterior:

El sistema incluirá un procedimiento de autorización de usuarios, en el cual los usuarios deben identificarse usando un nombre de usuario y contraseña. Sólo los usuarios autorizados de esta forma podrán acceder a los datos del sistema.

Escrito de esta forma, el requerimiento pasa a ser funcional. Sin embargo, no todos los requerimientos no funcionales pueden derivarse en requerimientos funcionales, por lo cual es muy importante definir los criterios de aceptación.