La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas.
El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.
Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente; (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.
Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables?
Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.
No hay comentarios:
Publicar un comentario