Ingeniería de Requisitos

La Ingeniería de requisitos es el proceso de establecer los servicios que el cliente requiere de un sistema y las restricciones bajo las cuales el sistema va a ser desarrollado y debe operar.

Los requisitos del sistema son descripciones generadas durante el proceso de ingeniería de requisitos. Pueden variar desde una descripción de un servicio o una restricción de un sistema, en un alto nivel de abstracción, hasta una especificación funcional matemática detallada.

Los requisitos son importantes principalmente porque permiten alcanzar 2 objetivos:

Pueden ser la base de una propuesta de contrato, por lo tanto debe estar abierto a la interpretación.

Pueden ser la base de un contrato, por lo que debe estar definido en detalle.

A continuación se hace una descripción de quien necesita los requisitos y con qué objetivo:

Cliente: el objetivo del requisito es permitirle saber lo que ha pedido.

Analista: el objetivo del requisito es comunicarse con el cliente y determinar con precisión lo que necesita.

Desarrollador: el objetivo del requisito es permitirle saber que hacer.

Probador de Programas: el objetivo del requisito es permitirle construir pruebas.

Mantenedor: el objetivo del requisito es permitirle comprender el sistema y hacerle las modificaciones correctas

Una Especificación de Requisitos debe contener los siguientes Requisitos:

Abstracta: debe evitar detalles no esenciales.

Completa: debe contener todos los requisitos de la solución.

Correcta: debe llevar a implementaciones aceptables.

Consistente: no debe contradecirse a sí misma.

Detallada: debe describir completamente cada requisito.

Concisa: debe ser tan pequeña como sea posible.

Factible: debe poder ser realizable.

Modificable: debe ser fácil de adaptar y extender.

Precisa: no debe ser ambigua.

Legible: debe ser fácil de leer y comprensible.

Verificable: es fácil verificar que una implementación satisface la especificación.

Los requisitos se clasifican en 3 tipos:

Requisitos de Usuario: es escrito para el cliente. Constituye un enunciado en lenguaje natural más diagramas de los servicios que se espera que el sistema proporcione y sus restricciones de operación.

Requisitos del sistema: Escrito como un contrato entre cliente y contratista. Es un documento estructurado que expone descripciones detalladas de los servicios del sistema, lo que éste debería hacer.

Especificación de diseño de software: escrito para desarrolladores. Es una descripción detallada del software que sirve como base para una implementación o diseño.

Los requisitos también suelen clasificarse desde otra perspectiva en:

Requisitos Funcionales: Servicios que el sistema debe dar y cómo éste debe reaccionar ante entradas específicas o situaciones particulares.

Requisitos No-funcionales: restricciones de los servicios o funciones ofrecidos por el sistema.

Requisitos de Dominio: Pueden ser funcionales o no- funcionales. Provienen del dominio de la aplicación.

Uno de los problemas que surge al elaborar los requisitos, y que también ha sido desarrollado en este trabajo de investigación, está relacionado con la imprecisión de los requisitos. Esto se debe al uso de palabras ambiguas que pueden causar que haya distintas interpretaciones entre los desarrolladores y los usuarios.

En vista de lo anterior, es que surgen los conceptos de completitud y consistencia de los requisitos. Con completo se refiere a que un requisito bebería incluir descripciones de todas las facilidades requeridas. Con consistente se refiere a que no debería haber conflictos entre las descripciones de las facilidades del sistema. Aunque en la práctica es imposible producir un documento completo y consistente para sistemas grandes.

Otros de los problemas que surgen con los requisitos de dominio son:

Comprensibilidad: los requisitos son expresados en el lenguaje del dominio de la aplicación por lo que suelen no ser entendidos por los ingenieros desarrolladores del sistema.

Implicidad: los especialistas del dominio entienden el área tan bien que no piensan que sea necesario hacer explícitos sus requisitos, suelen darlos por hecho.


Los requisitos de usuario son definidos usando lenguaje natural, tablas y diagramas. Esto acarrea problemas que con inherentes al uso del lenguaje natural, entre ellos la falta de precisión, confusión entre requisitos funcionales y no-funcionales, los que tienden a mezclarse y el hecho de que haya varios requisitos en un solo enunciado.

Recomendaciones para la toma de requisitos:

Es importante entregar una explicación junto con los requisitos ya que permite entender el dominio de aplicación de éste. Además, esta explicación es particularmente importante cuando los requisitos tienden a ser cambiados, ya que reduce las posibilidades de que los cambios tengan efectos inesperados. Además para escribir requisitos se sugiere que:

Inventar un formato estándar y usarlo para todos los requisitos.

Usar el lenguaje de una manera consistente.

Usar texto resaltado para identificar partes importantes.

Evitar usar jerga computacional.

El documento de requisitos: constituye el enunciado oficial de lo que se está solicitando a los desarrolladores de un sistema. Incluye requisitos de usuario y requisitos de sistema. Debe incluir una definición y una especificación de requisitos. Debe establecer qué se debe hacer y no el cómo hacerlo. Este documento debe poseer los siguientes requisitos:

Especificar el comportamiento externo del sistema y las restricciones de implementación.

Debe ser fácil de modificar y servir como herramienta de referencia para la mantención.

Debe servir como un elemento de registro acerca de registro del ciclo de vida del sistema.

Debe caracterizar respuestas a sucesos inesperados.

REFERENCIAS

Ian Sommerville. Ingeniería de Software. 6º Edición. PEARSON EDUCACIÓN, México, 2002.