Hemos discutido previamente las 4 actividades principales de la ingeniería de requisitos.

La ingeniería de requisitos es un proceso de recopilación y definición de los servicios que debe proporcionar el sistema.

Se centra en evaluar si el sistema es útil para el negocio (estudio de viabilidad), descubrir los requisitos (elicitación y análisis), convertir estos requisitos en algún formato estándar (especificación), y comprobar que los requisitos definen el sistema que el cliente quiere (validación).

En la práctica, la ingeniería de requisitos no es un proceso secuencial, es un proceso iterativo en el que las actividades se intercalan.

Por ejemplo, se itera primero en los requisitos del usuario; elicitación, especificación y validación, y se repiten los mismos pasos para los requisitos del sistema.

Al principio del proceso, la mayor parte del esfuerzo se dedicará a la comprensión de los requisitos de negocio y de usuario de alto nivel. Más adelante en el proceso, se dedicarán más esfuerzos a elicitar y comprender los requisitos detallados del sistema.

Algunas personas consideran que la ingeniería de requisitos es el proceso de aplicar un método de análisis estructurado, como el análisis orientado a objetos. Esto implica el análisis del sistema y el desarrollo de un conjunto de modelos gráficos del sistema, como los modelos de casos de uso, que luego sirven como una especificación del sistema.

Aunque los métodos estructurados tienen un papel que desempeñar en el proceso de ingeniería de requisitos, hay mucho más en la ingeniería de requisitos que lo que cubren estos métodos.

El análisis y diseño orientado a objetos se discutirá en otra serie de tutoriales.

Requisitos del usuario y del sistema

Típicamente, los requisitos se presentan en dos niveles de detalle; requisitos del usuario y del sistema, donde el usuario necesita una declaración de alto nivel de los requisitos, mientras que los desarrolladores del sistema necesitan una especificación más detallada del sistema. Por lo tanto, los requisitos del usuario y del sistema sólo se refieren a diferentes niveles de detalle.

Tener diferentes niveles de detalle es útil porque comunica información sobre el sistema que se está desarrollando para diferentes tipos de lectores.

Así, los usuarios finales no se preocuparán por el detalle, necesitan un requisito escrito genérico y abstracto.

Mientras que las personas que están involucradas en el desarrollo, necesitan lo que exactamente debe hacer el sistema.

Probablemente se acabará con muchos problemas y malentendidos si no se tiene una clara separación entre los diferentes niveles de detalle.

Requisitos del usuario

Describe los servicios que el sistema debe proporcionar y las restricciones bajo las que debe operar. No esperamos ver ningún nivel de detalle, o lo que hará exactamente el sistema, Es más de los requisitos genéricos.

Suele estar escrito en un lenguaje natural y suministrado por diagramas.

Discutiremos diferentes formas de especificar los requisitos más adelante en esta serie.

Requisitos del sistema

Los requisitos del sistema significan una descripción más detallada de los servicios del sistema y las restricciones operativas como la forma en que se utilizará el sistema, y las restricciones de desarrollo como los lenguajes de programación.

Este nivel de detalle es necesario para aquellos que están involucrados en el desarrollo del sistema, como ingenieros, arquitectos de sistemas, probadores, etc.

Requisitos Funcionales &Requisitos No Funcionales

Los requisitos del software se clasifican en requisitos funcionales y requisitos no funcionales.

Requisitos Funcionales

Cubre las principales funciones que debe proporcionar el sistema. Cuando se expresan como requisitos del usuario, suelen describirse de forma abstracta.

Sin embargo, los requisitos funcionales del sistema más específicos describen las funciones del sistema, sus entradas, el procesamiento; cómo va a reaccionar a una entrada particular, y cuál es la salida esperada.

Requisitos no funcionales

Son las restricciones de las funciones proporcionadas por el sistema.

Las restricciones, como cuántos procesos puede manejar el sistema (rendimiento), cuáles son los problemas (de seguridad) de los que el sistema necesita ocuparse, como las inyecciones SQL…

La tasa de fallos (fiabilidad), cuáles son los lenguajes y las herramientas que se utilizarán (desarrollo), cuáles son las reglas que hay que seguir para asegurar que el sistema funciona dentro de la ley de la organización (legislativo).

Los requisitos no funcionales suelen ser más críticos que los requisitos funcionales individuales. Los usuarios suelen encontrar formas de evitar una función del sistema que no satisface realmente sus necesidades. Sin embargo, el incumplimiento de un requisito no funcional puede significar que todo el sistema sea inutilizable.

Por ejemplo, si un avión no cumple con sus requisitos de fiabilidad, no será seguro para su funcionamiento, o si un sistema de control integrado no cumple con sus requisitos de rendimiento, las funciones de control no funcionarán correctamente.

Los requisitos no funcionales deben ser medibles

Siempre que sea posible, debemos escribir los requisitos no funcionales de forma cuantitativa, para que puedan ser probados. Se pueden medir cuando se prueba el sistema para comprobar si éste cumple sus requisitos no funcionales.

En la práctica, los clientes de un sistema suelen tener dificultades para traducir sus objetivos en requisitos medibles. No entienden qué número define la velocidad o la fiabilidad requeridas. Para algunos objetivos, como la mantenibilidad, no hay métricas que se puedan utilizar.

El coste de verificar los requisitos no funcionales medibles puede ser muy alto y los clientes pueden pensar que estos costes no están justificados.

Los requisitos no funcionales y funcionales son dependientes

Los requisitos no funcionales a menudo entran en conflicto, interactúan o incluso generan otros requisitos funcionales o no funcionales.

Un requisito de usuario relacionado con la seguridad, como limitar el acceso a usuarios autorizados, puede generar otros requisitos que son funcionales, como la necesidad de incluir facilidades de autenticación de usuarios en el sistema.

La distinción entre requisitos funcionales y no funcionales

En la práctica, es difícil separar los requisitos funcionales de los no funcionales. La distinción no es clara como sugieren sus definiciones.

La separación entre requisitos funcionales y no funcionales

Si los requisitos no funcionales se establecen por separado de los requisitos funcionales, la relación entre ellos puede ser difícil de entender.

Sin embargo, debemos destacar explícitamente los requisitos que están claramente relacionados con las propiedades emergentes del sistema, como el rendimiento o la fiabilidad.

Las propiedades emergentes son propiedades del sistema en su conjunto, más que propiedades que puedan derivarse de las propiedades de los componentes individuales del sistema.