Requisitos de Software
| ||||||
Los requisitos se han convertido en un punto clave en el desarrollo de las aplicaciones informáticas. Un gran número de proyectos de software naufragan debido a una mala definición, especificación o administración de requisitos. Factores tales como requisitos incompletos o mal manejo de los cambios de los requisitos llevan a proyectos completos al fracaso total.
Sumario
Conceptos
El Glosario de Terminología Estándar de Ingeniería de Software (IEEE: Standard Glossary of Software Engineering Terminology) define al requisito como:
- Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo.
- Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente.
- Una representación en forma de documento de una condición o capacidad como las expresadas en 1 o en 2.
El profesor Ian Sommerville
El profesor Ian Sommerville presenta una definición acerca de lo que es un requisito: “Un requisito es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. En el otro extremo, es una definición detallada y formal de una función del sistema.”
Características
Debido a que los requisitos son las necesidades del producto que se debe desarrollar en cualquier proyecto de software, es importante no perder de vista que un requisito debe ser especificado por escrito como todo contrato o acuerdo entre dos partes; posible de probar o verificar para poder comprobar si se cumplió con él o no; consistente que no entre en contradicción con otros requisitos y conciso, o sea, fácil de leer y entender. Además, un requisito deber estar completo, es decir, que proporcione la información suficiente para su comprensión. Y por último no debe ser ambiguo para no causarle confusiones al lector.
Defectos más comunes
A diario, en los proyectos desarrolladores de software, por falta de información o de conocimiento acerca del tema, se cometen errores con respecto a los requisitos. Entre los más comunes se encuentra la implicación insuficiente del cliente, ya que estos no comprenden la importancia de trabajar con rigor en la obtención de los requisitos para garantizar la calidad de los resultados, trayendo consigo a largo plazo problemas en la validación del producto obtenido. Otro de los defectos son los requisitos crecientes y cambiantes. Esto puede incrementar o modificar funcionalidades ya implementadas, desbordando costos y agendas planificadas, generándose también parches de programación que pueden trastocar principios básicos de diseño y degradar la arquitectura del sistema obteniéndose finalmente un producto con serias deficiencias técnicas.
La ambigüedad es una falla habitual de las descripciones de requisitos. Esta crea expectativas diferentes entre las partes del proyecto, y hace que los desarrolladores programen funcionalidades que no se ajustan a lo que los usuarios necesitan (re-programación), ocasionando la pérdida de tiempo en re-codificación, influyendo negativamente en el tiempo de entrega del producto al cliente final.
Es frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que no figuran en la especificación de requisitos, suponiendo que los usuarios lo agradecerán y que en su mayoría quedan programadas pero sin uso, suponiendo un coste de desarrollo innecesario. También es frecuente que el cliente pida funcionalidades que en realidad no añaden funcionalidad al producto, suponiendo un esfuerzo importante de desarrollo.
En ocasiones el cliente tiene tan sólo el concepto general del producto que desea. La tentación en estos casos es partir de una descripción mínima e ir preguntando y revisando a los programadores conforme el desarrollo avanza. Las estimaciones prematuras, basadas en información limitada pueden fácilmente desbordarse en más del doble. Siempre que sea preciso ofrecer valoraciones previas es conveniente ofrecer varias posibilidades, o incluir un porcentaje posible de error probable.
Importancia de los requisitos en el desarrollo del software
Roger S. Pressman expresa que para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado. La parte más difícil en la construcción de sistemas software es decidir precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los requisitos técnicos detallados, incluyendo todas las interfaces con humanos, máquinas y otros sistemas. Ninguna otra parte del trabajo puede perjudicar tanto el resultado final si se realiza de forma errónea. Ninguna otra parte es tan difícil de rectificar posteriormente.
La calidad con que se realice la captura de los requisitos va a influenciar en todo el proceso de desarrollo del software repercutiendo en el resto de las fases de desarrollo del mismo. Una definición eficiente de los requisitos permite mostrar un nivel de disciplina en el proceso de desarrollo, dar un mejor soporte a la Gestión de Cambios y ganar una mayor eficiencia en las pruebas reduciendo el riesgo, mejorando la calidad y permitiendo la automatización. Además contribuye a tomar mejores decisiones de diseño y de arquitectura. También le permite al equipo de desarrollo reducir los problemas de mantenimiento.
Referencias
- P. Brooks, Jr. Frederick. The Mythical Man-Month. : Addison-Wesley. 1995.
- Pressman, Roger S. Ingeniería de Software. : Mc Graw Hill. 1995.
- IEEE 610-1990. Instituto de Ingenieros Eléctricos y Electrónicos. IEEE Computer Dictionary. Software Engineering Terms. 1990.
