Ingeniería de Requisitos

Hace unos días hablábamos de la ingeniería del software y de la importancia de esta para el desarrollo de software de calidad. Pues hoy vamos a tratar una disciplina dentro de la ingeniería del software que es la ingeniería de requisitos.

¿Qué es la ingeniería de requisitos?

Según el libro “Ingeniería del Software” de Ian Sommerville, la ingeniería de requisitos es la primera disciplina que se aplica a la hora de desarrollar un software utilizando la ingeniería del software. Comprende todas las tareas relacionadas con la obtención y análisis de los requisitos de un sistema. Los requisitos son la descripción de los servicios proporcionados por el sistemas y sus restricciones operativas. Estos requisitos reflejan las necesidades de los clientes.

Procesos de la ingeniería de requisitos

Al igual que todas las disciplinas, existen una serie de procesos que hay que cumplir para realizar con éxito esta fase dentro de la ingeniería del software. A continuación describiré lo que hay que realizar en casa proceso y que es lo que se espera como resultado.

• Obtención y análisis de requisitos: Este proceso consiste en obtener y comprender los requisitos de todas las personas involucradas en el proyecto, desde el cliente hasta los usuarios (stakeholders). Esta suele ser la tarea más difícil por las siguientes razones:
  • Los stakeholders a menudo no conocen lo que desean obtener del sistema excepto en términos muy generales. Puede resultarles difícill expresar lo que quieren que haga el sistema.
  • Los stakeholders expresan los requisitos con sus propios términos y con un conocimiento de su propio trabajo. Por tanto, los ingenieros de requisitos, sin conocimiento en el área de los stakeholders, deben arreglárselas para entender esos requisitos.
  • Diferentes stakeholders tienen requisitos distintos que pueden expresar de varias formas.

Entre las técnicas para obtener requisitos yo destacaría las entrevistas, los talleres (reuniones entre los ingenieros de requisitos y los stakeholders) y los prototipos (especie de esqueleto del sistema que se le enseña al cliente para que ir sacando los requisitos).

Una vez que se obtienen los requisitos hay que procesarlos. Para ello, lo primero es clasificarlos y organizarlos en grupos. A continuación, debemos organizarlos pro prioridades y negociar. Como dije antes, un problema es que varios stakeholders tienen necesidades distintas y hay muchas veces en que un requisito se contradice con otro o en la que no es posible implementar todos los requisitos obtenidos. Es por eso que es necesario priorizar y negociar. Finalmente,procederemos a documentar los requisitos.

• Documentación de requisitos: Una vez que acabamos la fase anterior, tenemos que realizar un documento en el que se reflejen todos los requisitos obtenidos. Esto es necesario para que haya constancia de todo y para que no se olvide nada. Además, en muchos casos este documento se utiliza como contrato con el cliente.

Una parte de un documento de requisitos

• Validación de requisitos: Este proceso trata de mostrar que los requisitos obtenidos definen realmente el sistema que el cliente desea. Este proceso es importante ya que algún error en los requisitos puede conducir a unos sobrecostes en el proyecto muy importantes si se tratan de resolver una vez que se comienza a desarrollar el sistema. Sin embargo, si esos errores se encuentran durante la fase de ingeniería de requisitos, los costes son muchísimo menores. Durante el proceso de validación se deben realizar las verificaciones o comprobaciones:
  • Verificaciones de validez: Se trata de comprobar que el sistema realizará lo que quiere que realice el cliente.
  • Verificaciones de consistencia: No deben existir contradicciones entre los requisitos en el documento.
  • Verificaciones de completitud: El documento de requisitos debe contener todos los requisitos que definan todas las funciones y restricciones propuestas por los stakeholders.
  • Verificaciones de realismo: Se debe comprobar que todos los requisitos son posibles de implementar (por ejemplo que no nos pasemos del presupuesto).

Una vez validados los requisitos podríamos decir que hemos acabado la fase de ingeniería de requisitos salvo por un proceso que continúa una vez acabado el sistema.

• Gestión de requisitos: Para sistemas medianamente grandes, los requisitos cambian. Incluso una vez desarrollado el sistema, puede ser necesario añadir nuevos requisitos. Por tanto, debemos gestionar y controlar estos cambios para añadir la nueva funcionalidad al sistema. Para ello, dentro de este proceso se realizan los siguientes subprocesos:
  • Análisis del problema y especificación del cambio
  • Análisis del cambio y cálculo de costes
  • Implementación del cambio

Esto ha sido todo por ahora. Espero que ahora entendáis mejor la fase de ingeniería de requisitos. De todas formas esto ha sido una especie de introducción, al igual que con la ingeniería del software, con la ingeniería de requisitos continuaré aportando información más detallada como por ejemplo técnicas, posibles problemas que se presentan, etc.

El artículo Ingeniería de Requisitos apareció por primera vez en Instinto Binario.