La gestión de requerimientos establece lo que el sistema debe hacer en cuanto a procesos, consultas, reportes, alarmas, interfaces, restricciones de seguridad y algunos otros elementos que la organización necesite, por lo que si no se identifican de manera correcta, el software no proporcionará al usuario la funcionalidad esperada; además si no se determinan de manera completa y clara no se conocerá el alcance ni será posible estimar la dimensión real del proyecto.

Ingeniería de requerimientos


Es la disciplina relacionada con el análisis, documentación y especificación de requerimientos. También proporciona los mecanismos adecuados para facilitar las actividades de análisis, documentación y verificación de éstos. Engloba todas las actividades relacionadas con descubrir, documentar y mantener un conjunto de requerimientos para un sistema empresarial.

El término ingeniería, implica el uso sistemático y repetible de técnicas que son usadas para asegurar que los requerimientos del sistema sean completos, consistentes y relevantes.

La Ingeniería de Requerimientos tiene como objeto principal dar, tanto al cliente como al proveedor (desarrollador), un mecanismo de aseguramiento para ambas partes, donde estén de acuerdo con el alcance funcional y técnico.

Comprende la transformación de una necesidad operacional en una descripción del sistema, los parámetros de desempeño del sistema y la configuración del sistema mediante el uso de un proceso iterativo de análisis, diseño, y prototipos.

Debe tener un complejidad que sea claro tanto para el cliente como para el proveedor (desarrollador), si existiera algo técnico se debe incluir también una explicación para que el cliente no tenga dudas ya que debe estar firmado por ambas partes.

Requerimientos de sistema y de software

Si bien existen diferencias entre Ingeniería de Requerimientos de Sistema y la Ingeniería de Requerimientos de Software solo mencionaremos la más importante para satisfacer a los puristas. Mientras que el origen de los requerimientos de sistema radica en las necesidades del usuario, el origen de los requerimientos de software se origina en los requerimientos y/o especificaciones del sistema.

El cliente es el experto en los procesos de su negocio, por tanto sabe cuáles son sus necesidades de información; por otro lado el proveedor es el experto en los temas de características de los sistemas y especificaciones del software.

El origen del problema

Es común que los requerimientos no se expresen de manera clara ni se documenten de manera apropiada; aunque existen diversas técnicas, notaciones y métodos, no son utilizados de forma correcta por su complejidad, llegan a ser incomprensibles para los usuarios, no representan un estándar entre los grupos involucrados en el desarrollo y algunas veces no reflejan la realidad.

Es un hecho además que los requerimientos cambian, no se actualiza la documentación relacionada y los cambios no son comunicados a todos los grupos involucrados en el desarrollo. Los cambios en requerimientos impactan de manera importante la planeación y arquitectura del proyecto.

De acuerdo con la naturaleza de cada proyecto, existen distintos tipos de requerimientos que a su vez tienen niveles de detalle. La cantidad de requerimientos de un proyecto de software puede ser muy grande y difícil de controlar.

Además, se requiere una alta participación del usuario en el proceso de identificar y validar los requerimientos, para garantizar que sean los correctos y cubran sus necesidades. Es una participación que muchas veces no se tiene.

Jerarquía de requerimientos

¿Por qué definir los requerimientos?

  • Una de las razones más comunes por las que un sistema falla es una mala definición de los requerimientos.
  • El escribir especificaciones de sistema y de software buenas, correctas, completas y medibles es uno de los problemas más comunes en el desarrollo de software.

Para el éxito de un desarrollo de software es esencial una comprensión total de los requerimientos. No importa lo bien diseñado o codificado que esté un programa si no se ha analizado correctamente, defraudará al usuario y frustrara al desarrollador. es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.

Los usuarios por lo general saben lo que requieren pero en muchas ocasiones no saben cómo solicitarlo, mucho menos cómo documentarlo. Para este proceso es necesario que, el usuario cuente con su proceso documentado a nivel manual y a partir de este se lleve a cabo la documentación del requerimiento.

Si bien uno de los puntos principales de los problemas presentados en una implementación es la mala o nula documentación de los requerimientos, es algo que ni el cliente ni el proveedor del software se sientan a detallar adecuadamente.

Por un lado el cliente en ocasiones no exige esto con el fin de ahorrarse tiempo o considerar que sobre la marcha se harán los ajustes necesarios. Por otra parte el proveedor debería exigir este análisis pero se elevarían los costos del proyecto y seguramente no se concluiría la venta.

Se debe buscar un punto intermedio donde por lo menos se asegure el alcance.

Por otro lado cabe mencionar que la identificación de requerimientos no es fácil, debido a que el sistema por desarrollar debe satisfacer las necesidades reales de los usuarios, las cuales muchas veces no son claras, provienen de diversas fuentes y son de diversos tipos, por lo que se requieren habilidades y herramientas tanto técnicas como administrativas por parte de los analistas. Esta es la parte medular para que el sistema brinde la funcionalidad correcta.

La principal relación de los requerimientos con el retraso de los proyectos radica en que algunos aspectos están fuera del alcance original, el cual nunca fue documentado, por lo que se debe implementar un mecanismo formal para justificarlo. Para que no quede lugar a malos entendidos entre los clientes y el equipo de desarrollo.

En caso de existir la necesidad de un ajuste al alcance del proyecto lo más conveniente es que se maneje con un documento llamado “control de cambios” de manera que se documente el tiempo que pudiera retrasar el proyecto y también si va a tener algún costo.

Con respecto al número de requerimientos, entre más grande sea el proyecto, puede ser difícil controlarlos, sobre todo si no se tienen herramientas y mecanismos establecidos, considerando además que se relacionan unos con otros y se relacionan con otros artefactos (planes, código, pruebas) del proceso de ingeniería de software.

Cuando el proyecto es muy grande es cuando más se debe invertir tiempo en el establecimiento del alcance, entre más detallado menor será el riesgo de un fracaso.

Es un hecho además que es muy caro hacer cambios a requerimientos después de que han sido acordados, ya que conllevan a costos relacionados con la especificación, el re-diseño, la re-codificación, el re-probar, la reimplantación, las acciones correctivas, la responsabilidad civil, los costos de desplazamiento, la documentación y el mantenimiento constante.

Lo más conveniente es tener una junta o reunión de evaluación para determinar si los cambios que se requieren pueden esperar para una segunda fase o son necesarios para la puesta en marcha.

Clasificación de los requerimientos

De acuerdo a la funcionalidad

Requerimientos funcionales

Describen lo que el sistema debe hacer, es decir especifican acciones que el sistema debe ser capaz de realizar, sin considerar restricciones físicas. Los requerimientos funcionales especifican el comportamiento del sistema.

Requerimientos no funcionales

Describen únicamente atributos del sistema o atributos del ambiente del sistema y pueden ser por ejemplo: requerimientos de interfaz, de diseño, de implementación, legales, físicos, de costo, de tiempo, de calidad, de seguridad, de construcción, de operación, entre otros.

De acuerdo al nivel de cumplimiento

Requerimiento obligatorio

Es un requerimiento que debe ser implementado.

Requerimiento recomendable

Es deseable que sea implementado.

Requerimiento opcional

No es crítica su implementación.

Responsabilidades de los usuarios

Dentro de las responsabilidades de los usuarios están, instruir a los analistas sobre el negocio y definir el vocabulario de su área, invertir tiempo en proporcionar requerimientos y aclarar dudas, también debe ser específico y preciso sobre las necesidades del negocio y los requerimientos del sistema.

Otros factores que también se deben considerar son tomar decisiones a tiempo sobre los requerimientos, respetando las estimaciones de costo y viabilidad del equipo de desarrollo, fijando prioridades para requerimientos individuales, características del sistema o casos de uso.

Fuente: Lic. Carlos Ignacio Gil Camacho, Elementos mínimos en una organización, previos a la implementación de un ERP-Instituto Politécnico Nacional

Adaptado por la división Consultoría de EvaluandoSoftware.com