Requerimientos Funcionales

Los requisitos funcionales definen qué debe hacer un sistema.

Especificación de requerimientos

Los requerimientos...

● se suelen especificar en lenguaje natural,

● se expresan de forma individual (p.ej. esquemáticamente),

● se organizan de forma jerárquica (a distintos niveles de detalle),

● a menudo, se enumeran (para facilitar su gestión),

Especificación de requerimientos

Los requerimientos deben ser...

● claros y concretos (evitando imprecisiones y ambigüedades) p.ej. Uso de

puntos suspensivos, etcétera...
● concisos (sin rodeos ni figuras retóricas).
● completos y consistentes,
Especificación de requerimientos

Los requerimientos deben indicar...

● lo que se espera que haga el sistema (¿qué?),

● su justificación (¿por qué ha de ser así? ¿quién lo propuso?) y,
● en su caso, los criterios de aceptación que sean que sean aplicables (¿cómo
se verifica su cumplimiento?).
Especificación de requerimientos

Los requerimientos funcionales...

● deben estar redactados de tal forma que sean comprensibles para usuarios
sin conocimientos técnicos avanzados (de Informática, se entiende),
● deben especificar el comportamiento externo del sistema y evitar, en la
medida de lo posible, establecer características de su diseño,
● deben priorizarse (al menos, se ha de distinguir entre requisitos obligatorios y
requisitos deseables de los innecesarios).
Especificación de requerimientos

Al expresarse como requerimientos del usuario, los requerimientos funcionales se

describen por lo general de forma abstracta que entiendan los usuarios del sistema.

Sin embargo, requerimientos funcionales más específicos del sistema detallan las
funciones del sistema, sus entradas y salidas, sus excepciones, etcétera.

Los requerimientos funcionales del sistema varían desde requerimientos generales

que cubren lo que tiene que hacer el sistema, hasta requerimientos muy específicos
que reflejan maneras locales de trabajar o los sistemas existentes de una
organización.
Requerimientos No
Funcionales
Los requisitos no funcionales definen cómo debe ser un sistema.
Requerimientos No Funcionales

● Hacen referencia a las propiedades emergentes que surgen de las

funcionalidades del sistema, como ser: fiabilidad, tiempo de respuesta,
capacidad de almacenamiento, etc.
● Pueden ser más críticos que los requerimientos funcionales ya que especifican
el rendimiento del sistema, la protección, disponibilidad, entre otras propiedades.

Si un Requerimiento Funcional no se cumple, el sistema se degrada.

Si un Requerimiento No Funcional no se cumple, el sistema puede inutilizarse.

Propiedades - Requerimientos No
Funcionales
Clasificación de Requerimientos No
Funcionales
Clasificación de Requerimientos No
Funcionales

1. Requerimientos del producto

Estos requerimientos especifican o restringen el comportamiento del software. Los

ejemplos incluyen requerimientos de rendimiento sobre qué tan rápido se debe
ejecutar el sistema y cuánta memoria requiere, requerimientos de fiabilidad que
establecen la tasa aceptable de fallas, requerimientos de seguridad y requerimientos
de usabilidad.
 Clasificación de Requerimientos No
Funcionales

2. Requerimientos de la organización

Son requerimientos de sistemas amplios, derivados de políticas y procedimientos en

la organización del cliente y del desarrollador.

Los ejemplos incluyen requerimientos del proceso operacional que definen cómo se
usará el sistema, requerimientos del proceso de desarrollo que especifican el lenguaje
de programación, estándares del entorno o el proceso de desarrollo a utilizar, y
requerimientos ambientales que definen el entorno de operación del sistema.
Clasificación de Requerimientos No
Funcionales

3. Requerimientos externos

Este término cubre todos los requerimientos derivados de factores externos al

sistema y su proceso de desarrollo. En ellos se incluyen requerimientos regulatorios
que establecen lo que debe hacer el sistema para ser aprobado en su uso por un
regulador, como sería un banco central; requerimientos legislativos que tienen que
seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos
éticos que garanticen que el sistema será aceptable para sus usuarios y el público en
general.
Requerimientos de Dominio
Los requerimientos de dominio se derivan del dominio de la
aplicación.
 Requerimientos de Dominio

● Los requerimientos de dominio se derivan del dominio de la aplicación del sistema

más que de las necesidades del usuario.
● Incluyen terminología especializada del dominio ó referencias a conceptos del
dominio (sistemas, aplicación, ingeniería, ciencias, etc).

El problema con los requerimientos de dominio es que los ingenieros de software no

pueden entender las características del dominio en que opera el sistema. Por lo común,
no pueden indicar si un requerimiento de dominio se perdió o entró en conflicto con
otros requerimientos.
Requerimientos de Usuario
 Requerimientos de Usuario
● Deben describir los requerimientos funcionales y no funciones del sistema de tal
forma que sean comprensibles por los usuarios del sistema sin conocimiento
técnico detallado.

● Es recomendable no utilizar lenguaje técnico, jerga de software ó notaciones

estructuradas o formales.
● Deben redactarse en lenguaje sencillo, formularios y diagramas intuitivos.
● Deben enfocarse en ls recursos principales que deben proporcionar.
Ejemplos
Requerimientos 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 XYZ 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.
 Ejemplos de requerimientos no funcionales
de Producto
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á
Requerimientos no funcionales de producto

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).
Requerimientos no funcionales de Producto

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.
Requerimientos no funcionales
Organizacionales
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 9001.
● 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 gestionarán con una herramienta de gestión de
software testing.
Requerimientos no funcionales Externos
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.