Análisis de requerimientos

Roger S. Presuman
Ingeniería de Software un Enfoque practico
ANALISIS DE REQUERIMIENTOS
En análisis de requerimientos es la tarea que plantea la asignación de software a nivel de
sistema y el diseño de programas (Figura 3.2). El análisis de requerimientos facilita al
ingeniero de sistemas especificar la función y comportamiento de los programas, indicar la
interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe
cumplir el programa. El análisis de requerimientos permite al ingeniero (frecuentemente
llamado analista en este papel) refinar la asignación de software y representar el dominio de
la información que será tratada por el programa. El análisis de requerimientos da al
diseñador la representación de la información y las funciones que pueden ser traducidas en
datos, arquitectura y diseño procedimental. Finalmente, la especificación de requerimientos
suministra al técnico y al cliente, los medios para valorar la calidad de los programas, una
vez que se haya construido.
Tareas del análisis
El análisis de requerimientos puede dividirse en cuatro áreas: 1) reconocimiento del
problema; 2) evaluación y síntesis; 3) especificación, y 4) revisión.
Inicialmente, el analista estudia la Especificación del Sistema (si existe) y el Plan del
Proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los
programas que se usó para generar las estimaciones de la planificación. A continuación,
debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el
reconocimiento del problema.
Las formas de comunicación requerida para el análisis se ilustran en la Figura 3.3. El
analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y
Roger S. Presuman
Ingeniería de Software un Enfoque practico
con la empresa que vaya a desarrollar el software. El gestor del programa puede servir
como coordinador para facilitar el establecimiento de los caminos de comunicación. El
objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el
usuario/cliente.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de
trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar
en detalle todas las funciones del programa en detalle, establecer las características de la
interfase del sistema y descubrir las ligaduras del diseño. Cada una de las tareas sirven para
describir el problema de forma que pueda sintetizarse un enfoque o solución global.
Por ejemplo, un importante suministrador de materiales de fontanería necesita un sistema
de control de inventario. El analista encuentra que los problemas con el sistema manual
actual incluyen: 1) imposibilidad de obtener rápidamente el estado de una componente; 2)
dos o tres días de tiempo medio para actualizar un archivo de tarjetas, y 3) múltiples
Roger S. Presuman
Ingeniería de Software un Enfoque practico
reordenes del mismo vendedor debido a que no hay forma de asociar vendedores con
componentes, etc. Una vez que se han identificado los problemas, el analista determina qué
información va a ser producida por el nuevo sistema y qué datos se le suministrarán al
sistema. Por ejemplo, el cliente desea un informe diario que indique los elementos que se
han tomado del inventario y cuantos elementos similares permanecen. El cliente indica que
los empleados del inventado registrarán el número de identificación de cada pieza cuando
dejen el área de inventario.
Hasta la evaluación de los problemas actuales y de la información deseada (entrada y
salida), el analista comienza por sintetizar una o más soluciones. Un sistema basado en un
terminal en línea resolverá varios problemas, pero ¿fallará en el ámbito perfilado en el Plan
de Software? Parece que se va a necesitar un sistema de gestión de base de datos, pero ¿está
justificada la necesidad de asociatividad del usuario/cliente? El proceso de evaluación y
síntesis continúa hasta que el analista y el cliente creen que el software puede ser
especificado adecuadamente para la fase de desarrollo.
El cliente puede no estar seguro de precisar bien lo que quiere. El que desarrolla el software
puede no estar seguro de que un enfoque concreto sea apropiado para realizar la función y
comportamiento deseado. Por éstas y muchas otras razones, puede presentarse un enfoque
alternativo, llamado construcción de prototipos, para el análisis de requerimientos.
Las tareas asociadas con el análisis y especificación existen para dar una representación del
programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente
desarrolla una Especificación de Requerimientos del Software completamente por sí
mismo. Esto se presenta raramente en el mundo real. En el caso mejor, la especificación se
desarrolla conjuntamente entre el cliente y el técnico.
Una vez que se hayan descrito las funciones básicas, comportamiento, interfase e
información, se especifican los criterios de validación para demostrar una comprensión de
una correcta implementación de los programas. Estos criterios sirven corno base para hacer
la prueba durante el desarrollo de los programas. Para definir las características y atributos
del software se escribe una especificación de requerimientos formal. Además, para los
casos en los que se desarrolle un prototipo se realiza un Manual de Usuario Preliminar.
Puede parecer innecesario desarrollar un manual de usuario en una etapa tan temprana del
proceso de desarrollo. Pero de hecho, este borrador del manual de usuario fuerza al analista
a tomar el punto de vista del usuario del software (particularmente importante en los
sistemas interactivos). El manual permite al usuario/cliente revisar el software desde una
perspectiva de ingeniería humana y frecuentemente produce el comentario: “La idea es
correcta, pero esta no es la forma en que pensé que se podría hacer esto”. Es mejor
descubrir tales comentarios lo más tempranamente posible en el proceso.
Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven
como base para una revisión conducida por el cliente y el técnico. La revisión de los
requerimientos casi siempre produce modificaciones en la función, comportamiento,
representación de la información, ligaduras o criterios de validación. Además, se realiza
una nueva apreciación del plan del Proyecto Software para determinar si las primeras
Roger S. Presuman
Ingeniería de Software un Enfoque practico
estimaciones siguen siendo validas después del conocimiento adicional obtenido durante el
análisis.
El analista
Se han escrito libros enteros dedicados al papel y obligaciones del analista. Atwood
[ATW77] da una descripción práctica del trabajo: “...Se espera que el analista de sistema
analice y diseñe sistemas con un rendimiento óptimo. Esto es, el analista debe producir...
una salida que cumpla completamente con los objetivos de gestión...”. Al analista se le
conoce con distintos nombres: analista de sistema, ingeniero de sistema, diseñador jefe de
sistema, programador analista, etc. Independientemente del título de su trabajo, el analista
debe exhibir los siguientes rasgos de carácter:
• Habilidad para comprender conceptos abstractos, reorganizarlos en divisiones lógicas y
sintetizar “soluciones” basadas en cada división.
• Habilidad para entresacar hechos importantes de fuentes conflictivas o confusas.
• Habilidad para comprender entornos de usuario/cliente.
• Habilidad para aplicar elementos hardware y/o software a entornos de usuario/cliente.
• Habilidad para comunicarse bien en forma escrita y verbal.
• Habilidad para evitar que “los árboles no nos dejen ver el bosque”.
Es probablemente el último rasgo el que distingue verdaderamente a los buenos analistas.
Los individuos que se paran excesivamente en los detalles con frecuencia pierden de vista
el objetivo global de los programas. Los requerimientos del software deben ser descubiertos
de una manera “descendente”; las funciones importantes, interfaces e información deben
comprenderse completamente antes de que se especifiquen los detalles de las capas
sucesivas.
El papel del analista se dibuja en la Figura 3.4. El analista ejecuta o coordina cada una de
las tareas asociadas con el análisis de los requerimientos de software. Durante las tareas de
reconocimiento, se comunica con el equipo del usuario/cliente para establecer las
Roger S. Presuman
Ingeniería de Software un Enfoque practico
características del entorno existente. Luego el analista contacta con el equipo de desarrollo
durante las tareas de evaluación y síntesis, de forma que se definan correctamente las
características del software. Generalmente el analista es responsable del desarrollo de una
Especificación de los Requerimientos Software y también participa en todas las revisiones.
Es importante observar que el analista debe comprender también cada uno de los
paradigmas de la ingeniería de la programación (Sección 1.5) y apreciar las fases y pasos
genéricos de la ingeniería de la programación que se aplican independientemente del
paradigma usado. Muchos requerimientos implícitos (ji ej., diseño para el mantenimiento)
se incorporan en la especificación de los requerimientos, sólo si el analista comprende la
ingeniería del software.