Hablemos un poco sobre Ingeniería de Requerimientos

El término Requirements Engineering es acuñado en 1977 a través de un reporte técnico por parte del TRW Defense and Space Systems Group en Estados Unidos, el cual hace énfasis en la problemática de la “pobre” definición de los requerimientos de software y el alto costo que esto implica en los proyectos.

Investigadores en el área de software comienzan a formular metodologías, herramientas y técnicas para la definición de requerimientos. Esta comunidad va tomando fuerza y es en 1993 cuando surge el primer simposio en Ingeniería de Requerimientos (RE, por sus siglas en inglés).

Anualmente se realiza una conferencia para discutir los problemas relacionados con este tema. La edición número 25 se llevará a cabo este año en Lisboa, Portugal, con la participación de profesionales de la industria y reconocidos autores de libros sobre ingeniería de software, como Ian Sommerville.

Las metas de RE

La ingeniería de requerimientos (RE) es un proceso sistemático y disciplinado para la especificación y administración de éstos con las siguientes metas:

• Entender el problema por el que surge la necesidad del software.
• Conocer los requerimientos relevantes y lograr un consenso entre los stakeholders (personas interesadas en el software que toman decisiones sobre los requerimientos).
• Documentar las necesidades de los stakeholders.

La fase de definición de requerimientos es sumamente importante, ya que se necesita mucha disposición por parte del cliente o usuario, y de paciencia y creatividad por parte de los analistas para lograr buenos resultados.

4 pasos al definir los requerimientos

Las actividades principales del proceso de definición de requerimientos pueden dividirse en cuatro:

1 Extracción

• Consiste en una comunicación intensa con el cliente/usuario para establecer claramente el problema que requiere una solución.
• Diferentes técnicas deben ser usadas en combinación para obtener la mayor cantidad de información.
• Algunas técnicas: entrevistas, cuestionarios, prototipos (en papel) y sesiones de lluvia de ideas, entre otros.

2 Análisis

• Inicia una vez que se cuenta con la información obtenida.
• Usa técnicas de modelado y lenguajes como UML y BPMN para plasmar conceptos que son parte del problema y que formarán parte de la solución.
• Lo ideal es que haya una iteración de las primeras dos actividades antes de pasar a la especificación, aunque pueden repetirse en cualquier momento.

3 Especificación

• El objetivo es documentar los requerimientos en formatos establecidos.
• Los modelos generados en la etapa de análisis también forman parte de la especificación.
• Documentos con el listado de requerimientos funcionales, no funcionales, reglas de negocio, casos de uso y diagramas de estados y clases, por ejemplo, conforman el paquete que especifica el software a ser construido.

4 Validación y verificación

• La información que ha sido documentada en la especificación debe ser validada por el cliente, de forma que esté de acuerdo con lo establecido.
• En caso de que no esté completamente satisfecho, el ingeniero de requerimientos debe negociar posibles extensiones.
• La parte de verificación sucede una vez que se tiene el software en funcionamiento, es decir, hay una estrecha relación entre la verificación y las pruebas, ya que debe confirmarse que el software realiza lo especificado en los documentos.

La administración de requerimientos es ortogonal a las actividades anteriores y comprende cualquier medida que sea necesaria para estructurar los requerimientos, mantener la consistencia después de los cambios y asegurar la implementación.

Todos los integrantes del equipo de desarrollo deben aportar sus conocimientos y experiencia en cada actividad del proceso de levantamiento. Es cierto que un ingeniero de requerimientos tendrá mayor dominio durante esta fase, pero es importante que cada integrante opine y contribuya con preguntas, dudas y cuestionamientos para presentarlas al cliente/usuario.

Cada reunión con el cliente es valiosa y hay que tomar nota de todo lo que menciona. Todo esto debe ser interpretado y plasmado en diagramas, prototipos o alguna otra representación gráfica que permita al equipo ir analizando y consolidando las ideas, a fin de aterrizarlas en una solución que sea factible.

El proceso de levantamiento de requerimientos es iterativo y debe repetirse cuantas veces sean necesarias para refinar aquellos que no son claros, están incompletos o que no han sido validados por el cliente. Pero es cierto que los factores tiempo y presupuesto determinan el momento en que la fase de requerimientos acaba para comenzar el desarrollo. Es por esta razón que la negociación con el cliente tiene que iniciar desde que el equipo ha identificado los requerimientos esenciales y los que pueden omitirse o implementarse en versiones posteriores.