Especificación de requisitos de software
Contenidos
La Ingeniería de Requisitos (ER) se trivializa a menudo como una actividad realizada por analistas bienintencionados antes de que empiecen a hacer el trabajo real de especificar un producto. En este documento presentaremos, en los niveles más altos, los procesos y procedimientos críticos utilizados al ejecutar una Ingeniería de Requisitos efectiva como parte de un proyecto general exitoso.
Se trata de una mirada concisa a una disciplina que, cuando se explora en su totalidad, puede llenar, y de hecho llena, muchos libros. También destacaremos cómo se pueden aprovechar las herramientas de software para alcanzar objetivos de IR que, de otro modo, podrían resultar difíciles. Este documento puede servir de punto de partida para seguir investigando y aprendiendo sobre los múltiples aspectos de la ingeniería de requisitos.
Un estudio de la revista CIO concluyó: “Los analistas informan de que hasta el 71% de los proyectos de software que fracasan lo hacen debido a una mala gestión de los requisitos”. La desafortunada verdad es que los gestores de muchos de esos proyectos probablemente creían que estaban haciendo una buena gestión de los requisitos.
Aunque rara vez se dice con tanta sencillez, la inmensa mayoría de los fracasos de proyectos de software y sistemas se deben en gran parte a que no se da suficiente importancia a la ingeniería de requisitos. En septiembre de 1999, la sonda Mars Climate Orbiter de la NASA, valorada en 125 millones de dólares, quedó destruida cuando intentó entrar en órbita 100 kilómetros demasiado cerca de Marte. El error, ahora notorio, se debió a la incompatibilidad de las especificaciones: el sistema de control de actitud se especificó utilizando unidades imperiales, pero su software de navegación utilizaba unidades métricas. Nunca se insistirá lo suficiente en que para tener éxito es fundamental que los requisitos sean correctos y se utilicen al máximo durante todo el proyecto. Cuando se revisan los informes de fracaso de un proyecto, es frecuente encontrar factores como “Comprensión inadecuada de las necesidades del usuario”, “Alcance poco claro” y “Requisitos cambiantes”, todos ellos aspectos fundamentales de la gestión de requisitos (GR).
Ingeniería de requisitos pdf
Una de las principales razones del fracaso de los proyectos son unos requisitos mal redactados. Resulta sorprendente y triste comprobar el impacto negativo que unos requisitos deficientes pueden tener en el éxito de un proyecto. Contar con requisitos deficientes pone a los proyectos en riesgo de incurrir en importantes sobrecostes, retrasos en los plazos y deficiencias de rendimiento. Para evitar estos efectos negativos y ayudar a prevenir el fracaso de un proyecto debido a requisitos defectuosos, es necesario abordar las siguientes cuestiones:
Para mejorar la calidad de sus requisitos, debe seguir las mejores prácticas basadas en las lecciones aprendidas, tanto buenas como malas, en relación con la obtención, el desarrollo y la gestión de requisitos. Haga el mejor trabajo posible, a la primera. Para obtener algunos consejos útiles que le ayuden a evitar los problemas más comunes en la redacción de requisitos, consulte nuestro documento de Ivy Hooks titulado: “Escribir buenos requisitos”
Otro enfoque consiste en evaluar qué problemas tiene y determinar por qué. Para ello, puede descargar una copia de nuestra Lista de comprobación de factores de riesgo de los requisitos. La columna central enumera los factores de riesgo que pueden relacionarse con el riesgo de la primera columna, que trata de los puntos débiles de los procesos actuales. Comprender los riesgos para el éxito de su proyecto debidos a requisitos defectuosos le ayudará a descubrir áreas problemáticas que debe abordar si desea requisitos de mejor calidad. Encontrará un análisis detallado de los riesgos y los requisitos en mi artículo: Triplique las posibilidades de éxito de su proyecto Riesgos y requisitos (.pdf 211kB)
Proceso de ingeniería de requisitos en ingeniería de software pdf
Cuando se construyen productos complejos, los ingenieros necesitan descomponer los requisitos de alto nivel en trozos más pequeños para: hacerlos más manejables, poder diseñar subsistemas en paralelo y garantizar de abajo arriba que se verifican los requisitos de alto nivel.
Aunque la mayoría de los ingenieros han aprendido todo sobre el modelo V en sus estudios, la habilidad real de desglosar los requisitos de niveles superiores a inferiores es un arte que hay que adquirir, con bastantes trampas que evitar y que podrían crear problemas importantes mucho más adelante en el proceso de desarrollo si no se gestionan bien desde el principio.
Los requisitos del cliente describen a muy alto nivel lo que debe hacer el producto. Estos requisitos pueden proceder de un contrato con el cliente, de los resultados de un estudio de mercado o de una visión del producto.
Para diseñar un producto real que cumpla estos requisitos de alto nivel, los desglosaremos varias veces en requisitos de nivel inferior. Cada desglose sirve para asignar claramente responsabilidades entre subsistemas (por ejemplo, qué funcionalidades deben resolverse en hardware y cuáles en software), así como para detallar los requisitos (por ejemplo, qué significa exactamente “tamaño de un helipuerto”).
¿Qué es la gestión de requisitos en la ingeniería del software?
Aunque proporciona algunas ventajas competitivas, como acelerar la entrega del software, reducir costes y aprovechar más recursos económicos, este modelo de trabajo es muy complejo. Las amenazas, como la distancia geográfica y las diferencias culturales, pueden repercutir negativamente en las actividades y artefactos del proceso de software. Las amenazas no tratadas suelen afectar a la calidad de los requisitos, propagando los defectos a las fases de desarrollo posteriores. Las amenazas globales al desarrollo de software se estudiaron en un gran proyecto real, en el que no se puso en práctica ningún tratamiento especial para mitigarlas. Analizando las graves consecuencias en ese proyecto, se desarrolló una propuesta utilizando un modelo de Léxico y Escenarios para mitigar las amenazas a los requisitos en este modo de trabajo distribuido. La propuesta se aplicó en un nuevo proyecto real de características similares, y la comparación de los resultados de ambos proyectos arroja perspectivas prometedoras en términos de mejora de la calidad de los requisitos y del tiempo de proceso.
