Ingeniería de Requerimientos

Un proceso de desarrollo para crear software de calidad suele ser extremadamente complejo y demandar de muchisimo tiempo es por eso que para realizar algunos proyectos iba directo al grano, luego de escuchar al cliente ponía manos en el teclado y le daba sin parar hasta "terminar" pensando que en que esa era la forma mas rápida y que no era necesario realizar todos los pasos de la ingeniería de software aprendidos alguna vez en la facultad. Tuve que tropezar con la misma piedra varias veces para entrar en razón, esto es lo mismo que si un arquitecto se pondría a construir una casa sin previamente hacer un plano, ver el terreno, saber cuales son los recursos que posee, los riesgos, etc. En fin, asi como el caso análogo terminaría en una casa mas facil de tumbar que las de los dos primeros chanchitos, mis sistemas me rebotarían mil veces hasta llegar a alguna versión que agrade al cliente. Dicha versión saldría seguramente a destiempo y me daría la cabeza contra el piso por no realizar un riguroso análisis de los requisitos.

La ingeniería de requerimientos es el proceso mediante el cual se especifica lo que se desea que el sistema haga. Dicha especificación debe ser clara, consistente y no ambigua. Sirve como acuerdo entre todas las partes involucradas e incluye una descripción completa del comportamiento del sistema, interfaces, rendimiento y limitaciones.

Para todo ello se lleva a cabo un proceso cooperativo e iterativo de, a grandes razgos, analizar el problema, documentar las observaciones y chequear la información obtenida.

Los requerimientos son puntos a tener en cuenta durante la realización del contrato entre el cliente y el grupo de desarrollo. Proporcionan la información de lo que el cliente quiere y lo que el sistema debe realizar. Pueden ser funcionales (cuando describen las funciones que el sistema será capaz de realizar como "realizar pedido" o "calcular multa") o no funcionales (características que pueden limitar el sistema como ser el sistema operativo en el que debera correr) y se los suele categorizar en absolutamente indispensables, deseables y eliminables a fines de ser utiles en caso de recortes de presupuesto o tiempo. Además de funcionales y no funcionales hay veces que se añade una nueva clasificación en requerimientos del dominio, siendo estos los que provienen del dominio de aplicación del sistema y pueden ser describir tanto funciones como limitaciones. Todas estas distinciones en la realidad no son tan claras y la tarea de clasificar los requerimientos suele tornarse muy dificil.

Los requerimientos del usuario son las descripciones de los requerimientos funcionales y no funcionales de manera tal que sean comprensibles por los usuarios finales del sistema. Para esto se trabaja en lenguaje natural junto a algun que otro diagrama sencillo, esto facilita la lectura a cualquier persona no especializada pero trae aparejados problemas como la falta de claridad, la confusión de requerimientos y la conjunción de los mismos (cuando mas de uno se expresa junto a otro). Para minimizar las consecuencias de una descripción en lenguaje natural se trata de usar plantillas estandar y resaltar las partes mas importantes que identifican cada requerimiento.

Los requerimientos del sistema, en cambio, son descripciones mas detalladas y sirven de base para el contrato en la especificación del sistema. Son utilizados por los ingenieros en software como punto de partida para el diseño. Si bien se dice que los requerimientos especifican el "qué hacer" de un sistema, a este nivel de detalle no se puede evitar algun "como hacer", es casi imposible excluir toda la información de diseño. Para generar estos documentos se suele usar lenguaje estructurado (una suerte de mejora del lenguaje natural), PDL (lenguaje de descripción de programa - casi que estas programando -) y algunas que otras veces se especifican las interfaces del sistema.

Como ven, obtener estos requerimientos y especificarlos correctamente no es una tarea fácil y necesita de un procedimiento estructurado e ingenieril. La ingeniería de requerimientos es un proceso que describe todas las actividades que se necesitan para crear y mantener un documento de requerimientos del sistema. Comprende a grandes rasgos cuatro actividades genéricas: Un estudio de factibilidad, la obtención y análisis de requerimientos, la especificación de cada uno de ellos y la post validación.

Para el primer paso, el estudio de factibilidad, es necesario contar con una descripción resumida del sistema, como resultado de este se obtiene un informe acerca de que si es conveniente o no realizar el software y aplicar ingeniería de requerimientos.

Durante la obtención y el análisis de los requerimientos se trabaja con los stakeholders (personas con influencia directa o indirecta sobre el sistema) hay que tener mucho cuidado ya que muchas veces no saben expresar bien lo que desean (Ya me ha pasado :S), o no saben qué se puede y qué no se puede hacer (también me pasó), o diferentes stakeholders tienen distintos requerimientos y no se pueden cumplir todos (tambieén), o que factores políticos de la empresa entren en juego (lamentablemente también me pasó). Para todos ellos el proceso es el mismo: comprensión del dominio, recolección de requerimientos, clasificación, resolución de conflictos, priorización y verificación de los requerimientos obtenidos. La obtención suele darse de tres formas, una es orientada a puntos de vista donde se analiza la óptica de cada stakeholder, por los escenarios ya que suele serles mas facil a un usuario describir situaciones que abstracciones de funciones y muchas veces son descriptas en casos de uso, o por ultimo, los requerimientos pueden ser obtenidos por etnografía que, en facil, sería conociendo el entorno social y organizacional donde el sistema actuará.

La validación de los requerimientos se centra en analizar a cada uno de los obtenidos y comprovar la validez, la consistencia (no deben contradecirse entre si), la integridad (deben estar completos), el realismo o que pueda implementarse y por ultimo deben verificarse junto al cliente y contratista. Para la validación pueden utilizarse métodos como la revisión de los mismos (manualmente comprobando uno por uno y señalando su stakeholder de origen), la construcción de prototipos, generación de casos de prueba (para ver si se puede implementar algun componente) o un análisis de consistencia automático utilizando herramientas CASE.

Además de para crear un documento de especificación, la ingeniería de requerimientos se ocupa del manenimiento de los mismos. Se sabe que las empresas tienen vida, van mutando constantemente y sus requerimientos reflejan los cambios que suceden en el dominio. Esto que también me ha tocado sufrir hace que se puedan distinguir entre requerimientos volátiles y duraderos.

Para una administración adecuada de los requerimientos siempre tienen que tenerse bien identificados cada uno de ellos, tener una política de rastreo para saber de donde provino, un proceso de administración del cambio (con todo lo que implica como los riesgos y la implementación) y todo esto apoyado por herramientas CASE (Ingeniería de Software Asistida por Computadora) ya que en este paso ya no se trata de evaluar un conjunto pequeño de acciones o visiones sino que hay grandes cantidades de información a tener en cuenta.

Como ven, el proceso de ingeniería de requerimientos no es algo arbitrario y simple, sino por el contrario es algo que necesita mucho análisis y cuya importancia radica en el tiempo que luego se puede perder en resolver un problema que podría no haber pasado todas las etapas de desarrollo si estaba bien confeccionado el filtro en los requerimientos.