EJEMPLO DE REQUISITOS NO FUNCIONALES

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 transaccin 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 lgica y de datos

Los permisos de acceso al sistema podrn ser cambiados solamente por el administrador de
acceso a datos.
El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de
programacin 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, aplicacin 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 contar con manuales de usuario estructurados adecuadamente.
El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario
final.
 El sistema debe contar con un mdulo de ayuda en lnea.
La aplicacin web debe poseer un diseo Responsive a fin de garantizar la adecuada
visualizacin en mltiples computadores personales, dispositivos tableta y telfonos inteligentes.
El sistema debe poseer interfaces grficas 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.
La tasa de tiempos de falla del sistema no podr ser mayor al 0,5% del tiempo de operacin
total.
El promedio de duracin de fallas no podr ser mayor a 15 minutos.
La probabilidad de falla del Sistema no podr ser mayor a 0,05.

Otros ejemplos de requerimientos de producto

El sistema ser desarrollado para las plataformas PC y Macintosh.

La aplicacin debe ser compatible con todas las versiones de Windows, desde Windows 95.
La aplicacin deber consumir menos de 500 Mb de memoria RAM.
La aplicacin no podr ocupar ms de 2 GB de espacio en disco.
La nueva aplicacin debe manejar fuentes del alfabeto en Ingls, Idiomas latinos (Espaol,
Frances, Portugus, Italiano), Arbico y Chino.
La interfaz de usuario ser implementada para navegadores web nicamente con HTML5 y
JavaScript.

Ejemplos de requerimientos no funcionales

organizacionales

El procedimiento de desarrollo de software a usar debe estar definido explcitamente (en

manuales de procedimientos) y debe cumplir con los estndares ISO 9000.
La metodologa de desarrollo de software ser Behaviour Driven Development (BDD) apoyada
en Cucumber.
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.
Debe especificarse un plan de recuperacin ante desastres para el sistema a ser desarrollado.
Cada dos semanas debern 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 gestin de software testing.
Las pruebas de software se ejecutarn utilizando Selenium y Ruby como herramienta y
lenguaje Scripting para automatizacin de software testing.
Ejemplos de requerimientos no funcionales externos

Sistemas de datos mdicos: El nuevo sistema y sus procedimientos de mantenimiento de datos

deben cumplir con las leyes y reglamentos de proteccin de datos mdicos.
El nuevo sistema se acoger a las reglas de las licencias generales pblicas (GNU), es decir
ser gratuito, cdigo abierto en el que cualquiera podr cambiar el software, sin patentes y sin garantas.
Las pginas 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 nmeros de referencia.

Requerimientos no funcionales y requerimientos

funcionales
Los requerimientos no funcionales suelen expresarse de una manera general y sin hacer referencia a
algn modulo, transaccin o caracterstica del sistema, pues sino pasaran a ser requerimientos
funcionales.

Por ejemplo:

El sistema debe asegurar que los datos estn protegidos del acceso no autorizado

Es recomendable acompaar las definiciones de requerimientos no funcionales con criterios de

aceptacin 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 autorizacin de usuarios, en el cual los usuarios deben

identificarse usando un nombre de usuario y contrasea. Slo los usuarios autorizados de esta forma
podrn 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 aceptacin.

Ejemplos de requerimientos funcionales de proceso o

rea de negocio
El sistema enviar un correo electrnico cuando se registre alguna de las siguientes
transacciones: pedido de venta de cliente, despacho de mercanca al cliente, emisin de factura a cliente
y registro de pago de cliente.
Se permitir el registro de pedidos de compra con datos obligatorios incompletos, los cuales
podrn 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
aprobacin 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 envo automatizado de cartas de entrega de rdenes directamente al
almacn.
A cada orden se le asignar un identificador nico, que ser utilizado para identificarla en todos
los procesos subsecuentes que se realicen sobre esta.
Al ingresar ordenes de entrega, toda orden de entrega estar asociada a un pedido de venta.
La facturacin de pedidos de venta se realizara en lotes, por medio de una pantalla de pedidos
pendientes de facturacin, la cual mostrar los pedidos no facturados. Una vez facturados los pedidos no
se mostrarn en esta lista.
El sistema tambin permitir el registro de facturas manuales no asociadas a pedidos, sin
embargo, estas requerirn autorizacin por parte del grupo de Gerentes antes de ser contabilizadas.
El proceso de compras en el sistema abarcar los siguientes pasos y transacciones: Ingreso de
la requisicin, emisin de la solicitud de cotizacin y emisin de la orden de compra.
Los elementos de la solicitud de cotizacin sern los mismos de la requisicin asociada, al igual
que los de la orden de compra. El sistema permitir la emisin de solicitudes de cotizacin y rdenes de
compra parciales.
La contabilizacin de transacciones de facturas de venta y facturas de compra podr
configurarse para realizarse de forma automatizada a su registro, o manualmente en lotes (Proceso
Batch).
El software debe poder emitir los siguientes estados financieros: Balance general, Estado de
ganancias y prdidas, Estado de flujos de efectivo. Adems, debe poder emitir un listado de mayor
general y mayor analtico.
Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de
pedidos configurados, debern pasar por las aprobaciones establecidas en dicho flujo de aprobacin.

Ejemplos de requerimientos funcionales de interfaz

grfica
La solucin validara automticamente el cliente asociado a una orden con el sistema de gestin
de contactos.
El campo de monto acepta nicamente valores numricos con dos decimales.
El campo fecha de transaccin acepta nicamente fechas anteriores al da de hoy (da actual).
El campo nombre acepta caracteres alfabticos nicamente.
El campo direccin acepta caracteres alfabticos, numricos y especiales.
El campo pas consistir en una lista de preseleccin. El pas asociado a una direccin debe ser
previamente registrado en el sistema.
El campo estado, provincia o departamento consistir en una lista de preseleccin. A los
usuarios se les presentar nicamente los estados asociados al pas seleccionado previamente. El
departamento o provincia a seleccionar deber ser registrado en la funcionalidad correspondiente.
El campo material de elemento de la pantalla de requisiciones de compra ser una lista de
preseleccin, que mostrar nicamente los materiales registrados en el maestro de materiales.
El campo fecha contable acepta nicamente fechas que correspondan con periodos contables
que estn abiertos en el sistema.
La pantalla de registro de pago puede imprimir los datos en pantalla a la impresora.
 Se mostrar el nombre, tamao 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 auditora.
Las hojas de clculo aseguraran los datos usando firmas electrnicas.
El sistema permitir elaborar y emitir el reporte regulatorio XX, segn los requerimientos
establecidos en el reglamento y ley aplicable.
Los libros de venta y de compras sern 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 contrasea.
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 ms intentos
fallidos en el ingreso de la contrasea de usuario y cambio de contrasea 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 va 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 aplicacin debe poder utilizarse sin necesidad de instalar ningn software adicional adems
de un navegador web.
La aplicacin debe poder utilizarse con los navegadores web Chrome, Firefox e Internet
Explorer.

Acerca de los requerimientos funcionales

Los requerimientos funcionales deben redactarse de tal forma que el lector pueda entender el
funcionamiento del sistema sin tener conocimientos tcnicos particulares de su funcionamiento.

Lo importante es definir una forma estndar para expresar los requerimientos y ser consistente con la
misma en todos los documentos.
Asimismo, los requerimientos funcionales no necesariamente tienen que definirse en forma de narrativas
escritas, sino que tambin pueden utilizarse diagramas o flujos de procesos, los cuales se incluyen en la
especificacin funcional del software o sistema a desarrollar.

Para identificar y documentar los requerimientos funcionales de software, se siguen dos pasos, en primer
lugar se aplican tcnicas de levantamiento de requisitos, tales como la observacin, entrevistas,
observacin, entre otras.

Luego del levantamiento, se aplican tcnicas de anlisis de requerimientos para revisar la informacin
obtenida en el levantamiento y elaborar la especificacin funcional, algunas de estas tcnicas son la
descomposicin funcional, modelado de procesos, los casos de uso y otras ms.

TECNICAS PARA ANALISIS DE REQUISITOS

Checklists

La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que se realizan
sobre los requerimientos de software, que nos sean presentados de forma escrita.
Una lista de chequeo puede realizar preguntas como:
o Se han especificado los requisitos de hardware y software?
o Se han realizado consideraciones de seguridad?
o El nivel de granularidad del requerimiento se ha incluido?
o Se ha incluido el cdigo de referencia en para identificar el requisito en el desglose de
requerimientos?
o Est escrito el requerimiento en un lenguaje claro y conciso?
o El requerimiento es nico? (no existe duplicidad con otro requerimiento).
o Y muchas preguntas ms.
La lista de chequeo sirve de marco de trabajo y procedimental para revisar el requerimiento,
facilitando su anlisis de forma estructurada.
Los requerimientos se pueden revisar sobre la matriz de trazabilidad de requerimientos o sobre
la definicin del alcance.

7.- Inspeccin

Revisin no destructiva de los requerimientos de software. Por ejemplo:

o Examinar un software visualmente para constatar que las pantallas solicitadas se
encuentran incluidas.
o Verificar la inclusin de los campos necesarios para el ingreso de datos.
o Verificar la existencia de los botones necesarios para iniciar la funcionalidad que ha sido
requerida.
o Verificar que el requerimiento se apega a los estndares definidos para la aplicacin. Por
ejemplo estndares de navegacin entre pantallas y estndares de interfaz grfica.
De forma similar al uso de la lista de chequeo, la inspeccin consiste en tomar el requerimiento
definido en la matriz de trazabilidad o definicin de alcance, leerlo y producir un resultado para su
correccin.
8.- Prototipos

Designed by Freepik

Consiste en elaborar representaciones visuales (interfaz grfica con el usuario) de los

requerimientos de software.
Es una herramienta muy til para validar con los usuarios, clientes e interesados de proyecto que
el diseo funcional corresponde con los requerimientos de software (Que existe entendimiento comn
entre desarrolladores de software y usuarios).
Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar cules son
indispensables y cuales deseables, e identificar riesgos de forma temprana.
Puede enfocarse en toda la solucin o slo en reas especficas.
Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al como
en lugar de en torno al que.
La elaboracin de prototipos conlleva iteraciones entre desarrolladores y usuarios, en los cuales
se van elaborando varios prototipos y sometidos a evaluacin del cliente.