Requerimientos funcionales y no funcionales: SEO

Los requerimientos funcionales y no funcionales es el conjunto de funciones principales o no que

debe realizar cualquier programa, de la misma manera sirve para dar a conocer al cliente las
funcionalidades que realizará el programa. Aquí se nombran dicha funciones en el sistema de
posicionamiento web (SEO)
Requerimientos funcionales
 Mejorar posicionamiento con respecto a empresas competidoras
 Realizar actualización de la página web
 Generar palabras claves de la página web
 Generar posibles URL
 Analizar contenido técnico de la página web (presencia de etiquetas y JavaScript o flash)
 Calcular porcentaje de rebote para determinar la popularidad del sitio web
 Calcular cantidad de palabras claves por página

Requerimientos No funcionales
 El sistema debe contar con una interfaz amigable para el usuario (Interfaz)
 Conocer los objetivos de la empresa
 Realizar mantenimiento al sitio web (software)
 Analizar el tiempo de carga de las principales paginas (desempeño)
 Hacer uso de una base de datos que sostenga la información introducida (software)

REQUISITOS FUNCIONALES
Nombre Base datos
Tipo Requisito
Prioridad Alta
Descripción Cada vez que se cree una nueva cuenta con los datos de
cada usuario se debe almacenar en la base de datos (Sean
en unidad de almacenamiento del pc o servidor)
Entrada Datos ingresados por el usuario
Proceso Guardar datos del usuario
Salidas Registro de datos
Tabla 1: Requisitos Funcionales - Base de datos

Nombre Interfaz de Registro de datos

Tipo Requisito
Prioridad Alta
Descripción El sistema contara con una interfaz amigable e intuitiva para
que el usuario diligencie de manera fácil los datos de su
 registro.
Entrada Información del usuario
Proceso Interfaz de registro
Salidas Datos registrados
Tabla 2: Requisitos Funcionales - Interfaz de Registro de Datos

Nombre Sistema adaptable

Tipo Requisito
Prioridad Alta
Descripción El sistema debe de tener la capacidad de adaptarse a
cualquier dispositivo (computadores, celulares, Tablet).
Entrada Gestor de contenido
Proceso Adaptación al dispositivo huésped
Salidas Utilizar el gestor de contenido en dispositivo huésped
Tabla 3: Requisitos Funcionales - Sistema Adaptable
Nombre Plantilla de interfaz
Tipo Requisito
Prioridad Alta
Descripción El sistema contara con una plantilla, que permiten al usuario
hacer modificaciones y adaptarlas a su gusto
Entrada Plantilla del sistema
Proceso Modelar plantilla por usuario
Salidas Adaptación de la plantilla al gusto del usuario
Tabla 4: Requisitos Funcionales - Plantilla de Interfaz

Nombre Compatibilidad con los navegadores

Tipo Requisito
Prioridad Alta
Descripción El sistema debe ser compatible con los navegadores de
internet actuales (Internet Explorer, Mozilla Firefox, Google
Chrome).
Entrada Gestor de datos
Proceso Compatibilidad con el navegador
Salidas Visualización en el navegador
Tabla 5: Requisitos Funcionales - Compatibilidad con los Navegadores

REQUERIMIENTOS NO FUNCIONALES
Nombre Ataques de seguridad
Tipo Requisito
Prioridad Alta
Descripción El sistema debe de estar en la capacidad de evitar ataques
tales como SQL inyection, Ataques xss, Middleware, Ataques
CSRF, Validación de formularios.
Entrada Ataques SQL inyection, Ataques xss, Middleware, Ataques
CSRF, Validación de formularios.
Proceso Detectar ataque
Salidas Detener ataque
Tabla 6: Requisitos No Funcionales - Ataques de Seguridad

Nombre Operatividad
Tipo Requisito
Prioridad Alta
Descripción El gestor de contenido debe de ser de fácil manejo para los
usuarios que no tiene en conocimiento en el desarrollo de
páginas web
Entrada Idea de la página web
Proceso Diseño y configuración de la página web por parte del usuario
Salidas Página web terminada por el usuario
Tabla 7: Requisitos No Funcionales - Operatividad

Nombre Acceso a cuentas

Tipo Requisito
gPrioridad Alta
Descripción El acceso a las cuentas debe de ser a través de claves de
mínimo 6 dígitos
Entrada Inicio de sección
Proceso Solicitar clave de acceso
Salidas Iniciar sección
Tabla 8: Requisitos No Funcionales - Acceso a las Cuentas
Nombre Visualización con los navegadores
Tipo Requisito
Prioridad Alta
Descripción El sistema debe poder visualizarse en los navegadores
actuales (Internet Explorer, Mozilla Firefox, Google Chrome).
Entrada Proyecto web en ejecución
Proceso Adaptación al navegador
Salidas Visualizar el proyecto actual
Tabla 9: Requisitos No Funcionales - Visualización con los Navegadores
Nombre Tiempo en visualización
Tipo Requisito
Prioridad Media
Descripción El sistema no debe de tardar más 6 segundos en visualizar el
contenido modificado en el gestor de contenidos.
Entrada Proyecto web
Proceso Modificar contenido
Salidas Cambios realizados en el gestor de contenidos
Tabla 10: Requisitos No Funcionales - Tiempo en Visualización
Nombre Usabilidad
Tipo Requisito
Prioridad Alta
Descripción El sistema debe presentar mensajes de error que permitan al
usuario identificar el tipo de error
Entrada Problema presentado al usuario en alguna parte del proyecto.
Proceso Analizar el problema
Salidas Determinar qué tipo de problema es y visualizar en pantalla
Tabla 11: Requisitos No Funcionales – Usabilidad
Nombre Limitación de plantillas
Tipo Requisito
Prioridad Media
Descripción El sistema solo contara con una plantilla base la cual puede
ser modificada por el usuario
Entrada Plantilla base
Proceso Modificar plantilla base del gestor de contenidos
Salidas Plantilla modificada al gusto del usuario
Tabla 12: Requisitos No Funcionales - Limitación de Plantillas
Requerimientos Funcionales y No Funcionales, ejemplos y tips
El desarrollo de software es una de esas actividades donde tenemos nombres y categorías para todo.
Y me refiero a todo. A veces eso es redundante e inútil, pero a veces hay conceptos que son muy
buenos para conocer y diferenciar. Un ejemplo de ello es la diferencia entre requisitos funcionales
(RF) y no funcionales (RNF). Y dado que los requisitos del sistema de software se clasifican (entre
otras cosas) de esta manera, se deben considerar las siguientes técnicas para una correcta
identificación.

Requerimientos Funcionales

Los requisitos funcionales son declaraciones de los servicios que prestará el sistema, en la forma en
que reaccionará a determinados insumos. Cuando hablamos de las entradas, no necesariamente
hablamos sólo de las entradas de los usuarios. Pueden ser interacciones con otros sistemas,
respuestas automáticas, procesos predefinidos. En algunos casos, los requisitos funcionales de los
sistemas también establecen explícitamente lo que el sistema no debe hacer. Es importante recordar
esto: un RF puede ser también una declaración negativa. Siempre y cuando el resultado de su
comportamiento sea una respuesta funcional al usuario o a otro sistema, es correcto. Y más aún, no
sólo es correcto, sino que es necesario definirlo. Y eso nos lleva al siguiente punto.

Muchos de los problemas en la ingeniería de software (hablando sobre el proceso de desarrollo en sí

mismo) comienzan con especificaciones de requisitos inexactas. Es natural que un Analista de
Negocio (o quien sea que esté definiendo y documentando los requerimientos del sistema) tome
algunas suposiciones como conocimiento universal, o dé por sentado algún comportamiento. Pero
recuerde, también es natural que un desarrollador de sistemas interprete un requisito ambiguo de la
manera más simple posible, para simplificar su implementación. Un claro ejemplo de estos
problemas se puede encontrar en las funciones comunes relacionadas con la Experiencia de usuario:
 Historia de Usuario: Como usuario, quiero que la aplicación sea fácil de usar, de modo que no
tenga que pasar mucho tiempo aprendiendo a usarla.
 ¿Qué significa ser “fácil de usar”?
 ¿Fácil para quién?
 ¿Cómo se mide?
 ¿Cómo lo rastreas?
 ¿Cómo se prueba? ¿Contra qué criterios?
Esto no es algo contra los desarrolladores, sino más bien contra el comportamiento humano. Si
usted asume algo, otros pueden asumir algo diferente, y eso está bien. Pero el analista es el
responsable de la documentación, por lo que debe ser el mismo analista el que trate de asegurarse de
que no hay lagunas de comprensión o puntos grises. Esta es también la razón por la que las sesiones
de Pre-Planificación y Presentación de Historias son muy importantes para asegurarse de que todo
el equipo está en la misma página con respecto a los requisitos, su objetivo de negocio y cómo
implementarlos. Volviendo al ejemplo anterior, podríamos dividir el requisito en varios nuevos, más
fáciles de entender, desarrollar, probar, rastrear y entregar. Uno de ellos podría serlo:
 Historia de usuario: Como usuario, quiero que se muestre un tutorial al iniciar sesión por
primera vez, para que pueda ver para qué se utiliza cada opción de la pantalla de inicio.
 Ya sabes qué mostrar, un tutorial.
 Ya sabes lo que hay que comprobar, que explica cada opción en la pantalla de inicio.
 Usted sabe cuando necesita ser mostrado, en el primer inicio de sesión del usuario (puede
explicar más adelante si el tutorial puede ser omitido, mostrado en otros momentos, accedido
desde alguna sección dentro del menú, etc.)
Volviendo a FR, en principio, la especificación de los requisitos funcionales de un sistema debe ser
completa y coherente. Completar significa que todos los servicios solicitados por el usuario y/u otro
sistema están definidos. La coherencia significa que los requisitos no tienen una definición
contradictoria.
Requisitos no funcionales

Se trata de requisitos que no se refieren directamente a las funciones específicas suministradas por
el sistema (características de usuario), sino a las propiedades del sistema: rendimiento, seguridad,
disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo
hace. Alternativamente, definen restricciones del sistema tales como la capacidad de los dispositivos
de entrada/salida y la representación de los datos utilizados en la interfaz del sistema.
Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones
presupuestarias, políticas organizacionales, la necesidad de interoperabilidad con otros sistemas de
software o hardware, o factores externos tales como regulaciones de seguridad, políticas de
privacidad, entre otros.

Existen diferentes tipos de requisitos y se clasifican según sus implicaciones.

 Requisitos del producto. Especifican el comportamiento del producto, como los requisitos de
rendimiento sobre la velocidad de ejecución del sistema y la cantidad de memoria necesaria, los
requisitos de fiabilidad que establecen la tasa de fallos para que el sistema sea aceptable, los
requisitos de portabilidad y los requisitos de usabilidad.
 Requisitos organizativos. Se derivan de las políticas y procedimientos existentes en la
organización cliente y en la organización del desarrollador: estándares en los procesos a utilizar;
requisitos de implementación tales como lenguajes de programación o el método de diseño a
utilizar; y requisitos de entrega que especifican cuándo se entregará el producto y su
documentación.
 Necesidades externas. Se derivan de factores externos al sistema y a su proceso de desarrollo.
Incluyen los requisitos de interoperabilidad que definen la forma en que el sistema interactúa
con los demás sistemas de la organización; los requisitos legales que deben seguirse para
garantizar que el sistema funciona dentro de la ley; y los requisitos éticos. Estos últimos se
imponen al sistema para asegurar que será aceptado por el usuario.

A veces, en la práctica, la especificación cuantitativa de este tipo de requisitos es difícil. No siempre

es posible para los clientes traducir sus objetivos en requisitos cuantitativos. Para algunos de ellos,
como el mantenimiento, puede que no se pueda utilizar ninguna métrica; el coste de la verificación
objetiva de los requisitos cuantitativos no funcionales puede ser muy elevado. Y es por eso que
también es muy importante ser muy cuidadoso al documentarlos. Un analista puede utilizar el
apoyo del equipo de desarrollo y del equipo de pruebas para definir criterios mensurables con el fin
de saber cuándo un requisito puede ser marcado con éxito como “Hecho”.
Al igual que hablamos de requisitos funcionales, la generalización nunca es buena, pero en este caso
es aún más importante. Por qué? Porque el resultado de un desarrollo de requisitos no funcionales
puede no ser explícito para el usuario final.
 Mal ejemplo de RNF: El sistema debe ser seguro.
 ¿Qué tan seguro es “seguro”?
 ¿En qué situaciones?
 ¿Existe una norma a cumplir?
 ¿En qué secciones?
 ¿Qué debe ocurrir si el sistema no puede funcionar tan rápido como se requiere?

En estos casos, la aplicación de un requisito no funcional mal definido puede resultar problemática,
costosa y lenta. También porque la mayoría de las veces, una RNF no es algo que el equipo trabaja
aislado en un período fijo de tiempo. El RNF puede ser abordado durante todo el proyecto (e incluso
antes de comenzar o después de la entrega, en la fase de mantenimiento). Una vez más, el ejemplo
anterior podría dividirse en múltiples requisitos que son más fáciles de rastrear e implementar.
 Buen ejemplo de RNF: Todas las comunicaciones externas entre los servidores de datos, la
aplicación y el cliente del sistema deben estar cifradas utilizando el algoritmo RSA.
 Sabes qué tipo de comunicaciones necesitan ser encriptadas.
 Usted sabe qué algoritmo usar y validar.

Los requisitos funcionales y no funcionales deben diferenciarse en el documento de requisitos, ya

sea un SRS, una cartera de productos o cualquier artefacto que utilice. En la práctica, esto puede
resultar difícil. Si se declara un requisito no funcional por separado de los requisitos funcionales, a
veces es difícil ver la relación entre ellos. Si los RNF se declaran con requisitos funcionales, es difícil
separar las condiciones funcionales de las no funcionales e identificar los requisitos que se refieren
al sistema en su conjunto. Se debe encontrar un equilibrio adecuado que dependa del tipo de
sistema o aplicación que se especifique. Por ejemplo, si está trabajando con un Product Backlog,
podría tener Historias de Usuario separadas para RNFs, pero añadir un enlace a ellas en las RFs que
puedan ser impactadas por ellas. Esta es una opción común en la mayoría de los sistemas de
seguimiento de billetes utilizados en la actualidad.

En cualquier caso, tanto los RFs como los RNFs deben estar siempre documentados, incluso si es
difícil establecer la relación entre ellos en los artefactos. Esto ayudará al equipo a reducir las
discusiones de ida y vuelta, ahorrar tiempo y sobre todo, problemas innecesarios con el cliente.

Requerimientos funcionales: Ejemplos

Los requerimientos funcionales de un sistema, son aquellos que describen cualquier actividad que
este deba realizar, en otras palabras, el comportamiento o función particular de un sistema o
software cuando se cumplen ciertas condiciones.
Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas,
descripciones de los flujos de trabajo a ser desempeñados por el sistema y otros requerimientos
de negocio, cumplimiento, seguridad u otra índole.
En este artículo, te presentamos ejemplos de requerimientos funcionales, relacionados con
funciones del negocio, datos que deben ingresarse en las pantallas del sistema (interfaz gráfica),
los relacionados con control de acceso o emisión de reportes requeridos por entes reguladores,
entre otros.

PMOInformatica presenta: 40 Ejemplos de requerimientos funcionales de un sistema.

Como se describen y clasifican los requerimientos funcionales

Los requisitos funcionales de un software se suelen registran en la matriz de trazabilidad de

requerimientos y en la especificación de requerimientos de software, este último, documenta
las operaciones y actividades que el sistema debe poder desempeñar.
Entre los posibles requerimientos funcionales de un sistema, se incluyen: 
 Descripciones de los datos a ser ingresados en el sistema.
 Descripciones de las operaciones a ser realizadas por cada pantalla.
 Descripción de los flujos de trabajo realizados por el sistema.
 Descripción de los reportes del sistema y otras salidas.
 Definición de quien puede ingresar datos en el sistema.
 Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le
sean aplicables.

Al igual que otros tipos de requerimientos de software, como por ejemplo los requerimientos no
funcionales, los requerimientos funcionales se pueden clasificar según su finalidad, como por
ejemplo requerimientos de negocio, requerimientos originados en aspectos regulatorios, de
seguridad, entre otros.

A continuación te presentamos los ejemplos de requerimientos funcionales, clasificados por

distintas áreas:
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.
 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 facturación de pedidos de venta se realizara en lotes, por medio de una pantalla de
pedidos pendientes de facturación, la cual mostrará los pedidos no facturados. Una vez facturados
los pedidos no se mostrarán en esta lista.
 El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin
embargo, estas requerirán autorización 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 requisición, emisión de la solicitud de cotización y emisión de la orden de compra.
 Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al
igual que los de la orden de compra. El sistema permitirá la emisión de solicitudes de cotización y
órdenes de compra parciales.
 La contabilización 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 pérdidas, Estado de flujos de efectivo. Además, debe poder emitir un listado de
mayor general y mayor analítico.
 Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de
pedidos configurados, deberán pasar por las aprobaciones establecidas en dicho flujo de
aprobación.

Ejemplos de requerimientos funcionales de interfaz gráfica

 La solución validara automáticamente el cliente asociado a una orden con el sistema de
gestión de contactos.
 El campo de monto acepta únicamente valores numéricos con dos decimales.
 El campo fecha de transacción acepta únicamente fechas anteriores al día de hoy (día
actual).
 El campo nombre acepta caracteres alfabéticos únicamente.
 El campo dirección acepta caracteres alfabéticos, numéricos y especiales.
 El campo país consistirá en una lista de preselección. El país asociado a una dirección
debe ser previamente registrado en el sistema.
 El campo estado, provincia o departamento consistirá en una lista de preselección. A los
usuarios se les presentará únicamente los estados asociados al país 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
preselección, que mostrará únicamente los materiales registrados en el maestro de materiales.
 El campo fecha contable acepta únicamente fechas que correspondan con periodos
contables que estén abiertos en el sistema.
 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.

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 técnicos particulares de su funcionamiento.
Lo importante es definir una forma estándar 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 también pueden utilizarse diagramas o flujos de procesos, los cuales
se incluyen en la especificación 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 técnicas de levantamiento de requisitos, tales como la observación,
entrevistas, observación, entre otras.

El resultado del levantamiento de requisitos se documenta en el documento de requerimientos de

software. Te compartimos una plantilla a continuación:
> Documento de requerimientos de software

Luego del levantamiento, se aplican técnicas de análisis de requerimientos para revisar la

información obtenida en el levantamiento y elaborar la especificación funcional, algunas de estas
técnicas son la descomposición funcional, modelado de procesos, los casos de uso y otras más.
Referencias

Eriksson, U. Functional vs non functional requirements. Publicado en ReqTest.

Eriksson, U. The difference between functional and non-functional requirements. .
Publicado en ReqTest. 

Ofni Systems. Functional Requirements

ReqView. Documentation Examples

Requerimientos no funcionales: Ejemplos

Presentamos la tercera parte de la serie sobre los requerimientos no funcionales, con algunos
ejemplos que puedan servir de guía en su definición.

Los requerimientos no funcionales representan características generales y restricciones de la

aplicación o sistema que se esté desarrollando.

Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría

ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición con
criterios de aceptación que se puedan medir.

Entre los ejemplos de requerimientos no funcionales presentados, tenemos los referidos a

atributos como la eficiencia, seguridad, dependibilidad y usabilidad del sistema. También
presentamos ejemplos de requerimientos no funcionales organizacionales y externos.

¿Que son los requerimientos no funcionales y como se clasifican?

Si buscas más información sobre el concepto de requerimientos no funcionales, te recomendamos

la primera parte de esta serie Requerimientos no funcionales: Porque son importantes

En un primer nivel, los requerimientos no funcionales pueden clasificarse en requerimientos de

producto, organizacionales y externos, tal como te mostramos en el artículo sobre clasificación
de los requerimientos no funcionales.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de

usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales
pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo, los
requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y legislativos.

Cuando se realizan las fases de levantamiento y análisis de requerimientos, los requisitos no

funcionales se pueden registrar en un documento de requerimientos de software. A continuación
te compartimos una plantilla:

Algunos ejemplos de requerimientos no funcionales

Como mostramos en el artículo sobre clasificación de los requerimientos no funcionales, en
un primer nivel estos pueden clasificarse en requerimientos de producto, organizacionales y
externos.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de

usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales
pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo, los
requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y legislativos.

A continuación presentamos ejemplos de requerimientos no funcionales, clasificados por estas

distintas áreas.

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 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 módulo de ayuda en línea.
 La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada
visualización en múltiples computadores personales, dispositivos tableta y teléfonos inteligentes.
 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.
 La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación
total.
 El promedio de duración 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 aplicación debe ser compatible con todas las versiones de Windows, desde Windows 95.
 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.
 La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español,
Frances, Portugués, Italiano), Arábico 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 explícitamente (en

manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
 La metodología 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 recuperación ante desastres para el sistema a ser
desarrollado.
 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.
 Las pruebas de software se ejecutarán utilizando Selenium y Ruby como herramienta y
lenguaje Scripting para automatizació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.

Ejemplos de como definir requerimientos funcionales

> Requerimientos funcionales de un sistema de ventas

> Ejemplos de requerimientos funcionales

10 tipos de pruebas no funcionales
Las pruebas no funcionales se enfocan en validar un sistema o aplicación por medio de
sus requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por medio
de comportamientos específicos.

Las características no funcionales de un sistema o aplicación con frecuencia se cuantifican en

escalas variables, como por ejemplo los tiempos de respuesta en pruebas de desempeño.

El ISTQB establece que la omisión de las pruebas no funcionales puede ocasionar problemas de
calidad potencialmente catastróficos luego de la salida a producción, sin embargo, estos tipos de
pruebas son costosos, por lo que deben evaluarse los riesgos antes de comprometer los recursos
del proyecto.

En este artículo te presentamos 10 tipos de pruebas no funcionales, específicamente las pruebas

de usabilidad, seguridad, carga, estrés, volumen, configuración, rendimiento, escalabilidad,
recuperación y mantenibilidad.

10 tipos de pruebas no funcionales

A continuación te presentamos una lista no limitativa de 10 tipos de pruebas no funcionales que

puedes incluir en tu plan de pruebas de software.

1. - Pruebas de carga

Las pruebas de carga consisten en simular demanda sobre una aplicación de software y medir el
resultado. Estas pruebas se realizan bajo demanda esperada y también en condiciones de
sobrecarga (picos en la demanda).

Para ejecutar estas pruebas, se requiere del uso de herramientas de testing que simulen la
carga, como por ejemplo SoapUI.

Las pruebas de carga ayudan a identificar la máxima capacidad operativa de una aplicación, así
como en el identificar cuellos de botella y las causas de posible degradación del desempeño.

Cuando la carga de prueba se eleva por encima de los parámetros esperados, a estas pruebas se
les conoce como pruebas de estrés.
2. - Pruebas de estrés

Son pruebas de carga que se realizan con demandas mayores a la capacidad operativa, con
frecuencia hasta llegar al punto de ruptura.

Este tipo de prueba de software se utiliza para determinar la estabilidad de un sistema o

aplicación, con especial atención en la disponibilidad y manejo de errores cuando se enfrenta a la
sobrecarga.

Al igual que para las pruebas de carga, se requieren de herramientas que simulen la demanda,
SoapUI es una de estas herramientas que permite simular peticiones para servidores de
aplicaciones web.

Aquí te compartimos un Tutorial de SopaUI.

Con las pruebas de estrés se pueden identificar los puntos de ruptura, límites para uso seguro de
la aplicación, confirmar las especificaciones de diseño, identificar las formas en que el sistema
falla, entre otros aspectos.

3. - Pruebas de volumen

Las pruebas de volumen consisten en validar el funcionamiento de la aplicación con ciertos

volúmenes de datos.

Por ejemplo, si se quiere ver el comportamiento de una aplicación con un tamaño de base de
datos específico, se expande el tamaño de base de datos a dichos parámetros y luego e realizan
consultas, procesos o funcionalidades de la aplicación, midiendo su desempeño.

El sujeto de pruebas no está limitado a bases de datos, también se puede usar por ejemplo para
medir el desempeño de una interfaz cuando el archivo de interfaz (un archivo de texto, xml, etc.)
supera cierto tamaño.

El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad,
cuales son los límites máximos de volúmenes de datos para la operación e identificar condiciones
de falla.

4. - Pruebas de configuración

En lugar de probar el desempeño de una aplicación desde la perspectiva de la carga, las pruebas
de configuración se usan para validar que efectos en el desempeño tienen ciertos cambios en la
configuración.

Un ejemplo típico de esta situación es experimentar con diferentes métodos de balanceo de

cargas y ver la respuesta de la aplicación a niveles similares de sobrecarga.
Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente en diferentes
versiones o configuraciones de entornos de hardware y software, como pueden ser diversos
navegadores de internet, versiones de navegadores, entre otros.

5. - Pruebas de usabilidad

En las pruebas de usabilidad, los testers de software se enfocan en validar que tan fácil de usar
es una determinada aplicación.

Las características evaluadas en la usabilidad incluyen:

Facilidad de aprendizaje: Que tan fácil es para los usuarios realizar funciones básicas la primera
vez que utilizan la aplicación.
 Eficiencia: Que tan rápido los usuarios experimentados pueden realizar sus tareas.
 Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando un
usuario pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para usarla con
efectividad la próxima vez, o tiene que empezar a aprender de nuevo.
 Errores: Cuantos errores atribuibles al diseño comete el usuario, que tan severos son y
que tan fácil es recuperarse de los mismos.
 Satisfacción: Que tanto le gusta (o desagrada) al usuario utilizar el sistema.

6. - Pruebas de seguridad

Consiste en probar los atributos o características de seguridad del sistema, si es un sistema

seguro o no, si puede ser vulnerado, si existe control de acceso por medio de cuentas de usuario,
si pueden ser vulnerados estos accesos.

Las pruebas de seguridad también sirven para validar si el equipo de desarrollo de software ha
seguido prácticas de seguridad recomendadas en su programación.

Entre las características de seguridad de un sistema, están la confidencialidad, integridad,

autenticación, autorización y la disponibilidad.

7. - Pruebas de resistencia

Las pruebas de resistencia implican someter a un Sistema o aplicación a una carga determinada
durante un período de tiempo, para determinar cómo se comporta luego de un uso prolongado.

Un sistema informático puede comportarse de forma normal durante las primeras horas, sin
embargo, luego de cierto tiempo, problemas como fugas de memoria suelen ocasionar fallas.

Estos defectos en el desarrollo de software no pueden identificarse bajo pruebas funcionales

normales, por lo que es conveniente involucrar pruebas de resistencia entre los tipos de pruebas
de software.

8. - Pruebas de escalabilidad

Las pruebas de escalabilidad consisten en verificar la capacidad de una aplicación de escalar

cualquiera de sus características no funcionales, como por ejemplo la carga que soporta, número
de transacciones, volúmenes de datos, entre otros.

Al diseñar casos de prueba de escalabilidad, es recomendable considerarlos en bloques

incrementales, dada la dificultad de predecir la carga real que tendrá una aplicación luego de
implementada en producción.
Probar en bloques incrementales significa por ejemplo primero probar con niveles de demanda
bajos, luego incrementar a niveles de demanda medios y finalmente probar con altos niveles de
carga. De esta manera se puede determinar que también escala la aplicación y los problemas que
comienzan a surgir en distintos niveles.

Para que los resultados sean confiables, los ambientes de prueba y su configuración deben
mantenerse constantes.

9. - Pruebas de recuperación

Las pruebas de recuperación se realizan para verificar que tan rápido y que tan bien se recupera
una aplicación luego de experimentar un falló de hardware o software.

Por lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego verificar si la
recuperación ocurre adecuadamente.

Por ejemplo, cuando una aplicación esté funcionando desconectar el cable de red, o en
una aplicación móvil interrumpir la conexión con la red Wi-Fi o con la operadora, para luego
restablecer la conexión.

10. - Pruebas de mantenibilidad

Básicamente consisten en evaluar que tan fácil es realizar el mantenimiento de un sistema o

aplicación. Esto significa que tan fácil es analizar, cambiar y probar estos cambios.

Para realizar esta prueba deben evaluarse la forma en que está implementada la aplicación,
siguiendo buenas prácticas de ingeniería de software. Es decir, que se estén siguiendo los
patrones recomendados de ingeniería de software y que no se estén introduciendo
inadvertidamente anti patrones, esto es, que no se estén cometiendo errores comunes de
programación.
Somerville divide los requerimientos no funcionales en tres grandes tipos: Requerimientos de
producto, requerimientos organizacionales y requerimientos externos.

Requerimientos no funcionales de producto

Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual establece
límites y restricciones sobre lo que los diseñadores (arquitectos de software) e ingenieros de
software pueden hacer.

Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el desempeño y la
confiabilidad, pero otros son más difíciles como por ejemplo usabilidad y adaptabilidad.

Los requerimientos de producto pueden clasificarse en (Sommerville):

 Requerimientos de usabilidad: La usabilidad se define como el esfuerzo que necesita

hacer un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de un
software de aplicación. En tiempos recientes, la usabilidad ha adquirido mucha importancia, en
especial ante la demanda de desarrollo de software para móviles y tabletas.

 Requerimientos de eficiencia: Relacionado con desempeño en cuanto a tiempo de

respuesta, número de operaciones por segundo, entre otras mediciones, así como consumo de
recursos de memoria, procesador, espacio en disco o red.

Una herramienta útil para comprobar la eficiencia de un sistema es SoapUI, que permite hacer
pruebas de carga o estrés sobre webservices. Aquí te compartimos artículos sobre el tema:

 Requerimientos de dependibilidad: Engloba varios atributos

o Disponibilidad: Disposición del sistema para prestar servicio correctamente.
o Confiabilidad: Continuidad del servicio prestado por el sistema.
o Seguridad industrial: Ausencia de consecuencias catastróficas para el usuario o el
ambiente.
o Integridad: Ausencia de alteraciones inadecuadas al sistema.
o Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones a un proceso
sin afectar la continuidad del servicio.

 Requerimientos de seguridad: Capacidades funcionales o no funcionales que debe tener

un sistema para cumplir atributos en el área de seguridad de tecnología de información, seguridad
de datos, seguridad lógica, control de acceso a información (restricciones de acceso), autenticidad
de la información, privacidad, entre otros aspectos.

Considerar los requerimientos de producto es vital para lograr la integración continua de

aplicaciones y el desarrollo de cambios que sean rápidos pero sostenibles en el tiempo.

Este nuevo paradigma es necesario para implementar las nuevas tecnología de información y

aplicaciones de software como la movilidad, internet de las cosas, analítica avanzada de datos
(Big Data), evolución de los sistemas a la nube y tecnología de información escalable.
Requerimientos no funcionales organizacionales

Se derivan de las políticas y procedimientos de la organización como por ejemplo estándares de

procesos o requerimientos de implementación.

Pueden incluir metodologías de desarrollo de software, estándares de programación (codificación)

y herramientas de soporte al desarrollo de software (por ej. Herramientas CASE) que deben
usarse (siguiendo las políticas de la organización), también reportes a la gerencia que deben
proveerse, entre otros.

Las herramientas para la gestión de desarrollo de software que conocemos, se definen como

requerimientos no funcionales organizacionales.
Los requerimientos organizacionales pueden clasificarse en (Sommerville):

 Requerimientos de entorno: Describen el ambiente operativo en el que se debe

desenvolver el sistema.
 Requerimientos operacionales: Procedimientos operativos que describen como será
usado el sistema dentro del contexto de la organización.
 Requerimientos de desarrollo: Lenguaje de programación a usar, estándares de
codificación, patrones (y antipatrones) de diseño y programación, herramientas para gestionar
el desarrollo de software, entorno de desarrollo de software (ambiente de desarrollo), entorno de
pruebas de software (ambiente de pruebas), entre otros aspectos.

Uno de los aspectos que se documentan como requerimientos funcionales organizacionales son

los entorno, específicamente los procedimientos de mantenimiento y administración del
ambiente de desarrollo de software.

Esta administración también incluye los procedimientos para gestionar los ambientes de

pruebas integrales.

Requerimientos no funcionales externos

Estos derivan del entorno organizacional (no entorno técnico) en el cual se desarrolla el sistema y
pueden hacerse tanto sobre el producto (el software desarrollado) o también sobre el proceso de
desarrollo de software.

Este tipo de requerimientos incluyen limitaciones de índole económica, interacción o necesidad del
sistema de inter-operar con otros sistemas, requerimientos regulatorios en el área de salud,
seguridad industrial o protección de datos, requerimientos legales concernientes con licencias,
regulaciones o certificaciones que necesita el producto según la industria en el que se
desempeñe, entre otros.

Somerville a su vez clasifica estos requerimientos en:

Requerimientos regulatorios: Leyes y reglamentos que establecen que debe hacer el sistema y

como debe hacerlo para cumplirlas. El foco de un sistema o nueva funcionalidad puede ser
exclusivamente para cumplir una regulación.
 Requerimientos éticos: Requerimientos que aseguran que el sistema será aceptable para
el usuario, público en general y se adapta a las costumbres de la sociedad en la que se
desenvuelve o a la que presta servicios.
 Requerimientos legislativos: Características que debe cumplir el sistema para cumplir
con la ley, por ejemplo en el área de contabilidad (normas contables y estándares financieros),
requerimientos de seguridad industrial (para sistemas críticos), entre otros aspectos.
Importancia de clasificar los requerimientos no funcionales

El especificar requerimientos no funcionales de forma incompleta o inexacta puede ocasionar el

fracaso de tu proyecto de ingeniería de software.

De hecho no gestionar los requerimientos no funcionales es uno de los errores clásicos en la

gestión de desarrollo de software definida por Steve McConnell.

Lograr clasificar adecuadamente cada requerimiento no funcional identificado es muy importante

para garantizar este proceso.

https://www.youtube.com/user/codigofacilito
https://www.youtube.com/channel/UC4CEqh4d3-6RcyyJxhFCMGg
https://marvelapp.com/.