Respuesta.

Requisitos funcionales describen lo que el sistema debe hacer: operaciones comerciales, procesos, escenarios de usuario, es decir, funcionalidad.

Requisitos no funcionales definen cómo debe funcionar el sistema: restricciones, parámetros de calidad, rendimiento, seguridad, facilidad de uso, etc. Estos requisitos a menudo influyen en la elección de tecnologías, escalabilidad y sostenibilidad de la solución.

¿Por qué es importante diferenciarlos:

• Una clara separación contribuye a una correcta formulación de la tarea para los desarrolladores y testers.
• Permite evitar pasar por alto características críticas (por ejemplo, seguridad, escalabilidad).
• Los requisitos no funcionales no considerados a menudo se convierten en una fuente de fracaso del proyecto.

Características clave:

• Los requisitos funcionales son comportamiento del sistema.
• Los requisitos no funcionales son calidad y restricciones.
• Ambos tipos deben estar claramente documentados y acordados.

Preguntas con trampa.

¿Se incluye "facilidad de uso de la interfaz" en los requisitos funcionales?

No, es un parámetro no funcional (usabilidad). Un requisito funcional es la existencia, por ejemplo, de un botón "Guardar", un requisito no funcional sería la velocidad de su respuesta y la simplicidad de uso.

¿Se pueden ignorar los requisitos no funcionales si no están claramente indicados por el cliente?

No. El analista debe discutir y formalizar incluso los requisitos no funcionales implícitos, de lo contrario, aumenta el riesgo de retraso en el lanzamiento, quejas de los usuarios y costos adicionales.

"El sistema debe ser capaz de procesar 1000 solicitudes por minuto". ¿Es un requisito funcional?

No, es un requisito no funcional: una característica de rendimiento.

Errores comunes y anti-patrones

• Enfocar únicamente en la funcionalidad ("lo principal es que funcione, la velocidad luego").
• Formulación implícita de requisitos no funcionales: "debe ser rápido", "fiable", "seguro".
• Ignorar las pruebas de no funcionalidad.

Ejemplo de la vida real

Caso negativo: El sistema implementó completamente la funcionalidad comercial declarada, pero con alta carga comenzaba a "ralentizarse", ya que no se tuvo en cuenta el rendimiento en absoluto. Ventajas:

• Desarrollo rápido, cumplimiento exacto de los escenarios declarados. Desventajas:
• El sistema no era apto para su operación en condiciones de carga real, la empresa tuvo que rehacer urgentemente la arquitectura.

Caso positivo: El analista junto con el arquitecto y el cliente documentaron en los requisitos la carga máxima, los criterios de respuesta, realizaron pruebas de carga. Ventajas:

• El producto funcionó de manera estable y soportó el crecimiento de usuarios.
• Los planes de desarrollo preveían la escalabilidad. Desventajas:
• En el inicio del diseño se tuvo que dedicar más tiempo a las discusiones y pruebas adicionales.