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.
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.