You are on page 1of 4

1.

REQUERIMIENTOS PARA EL ANALISIS Y NEGOCIACION

Durante las dos pasadas dcadas, se han desarrollado un gran nmero de mtodos de modelado. Los investigadores han identificado los problemas del anlisis y sus causas y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de heursticas para solucionarlos. Cada mtodo de anlisis tiene su punto de vista. Sin embargo, todos los mtodos de anlisis se relacionan por un conjunto de principios operativos: 1. Debe representarse y entenderse el dominio de informacin de un problema. 2. Deben definirse las funciones que debe realizar el software. 3. Debe representarse el comportamiento del software (como consecuencia acontecimientos externos). 4. Deben dividirse los modelos que representan informacin, funcin comportamiento de manera que se descubran los detalles por capas jerrquicamente). 5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle la implementacin.

de y (o de

Aplicando estos principios, el analista se aproxima al problema sistemticamente. Se examina el dominio de informacin de manera que pueda entenderse completamente la funcin. Se emplean modelos para poder comunicar de forma compacta las caractersticas de la funcin y su comportamiento. Se aplica la particin para reducir la complejidad. Son necesarias las visiones esenciales y de implementacin del software para acomodar las restricciones lgicas impuestas por los requisitos del procesamiento y las restricciones fsicas impuestas por otros elementos del sistema. Adems de los principios operativos de anlisis mencionados anteriormente, Davis sugiere un conjunto de 6 principios directrices para la ingeniera de requisitos: Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a precipitarse en busca de una solucin, incluso antes de entender el problema. Esto lleva a menudo a un elegante software para el problema equivocado! Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina. Como el concepto de calidad del software se basa a menudo en la opinin sobre la amigabilidad de la interfaz, el desarrollo de prototipos (y la iteracin que se produce) es altamente recomendable. Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer un seguimiento hasta el cliente. Usar mltiples planteamientos de requisitos. La construccin de modelos de datos, funcionales y de comportamiento, le proporcionan al ingeniero del software tres puntos de vista diferentes. Esto reduce la probabilidad de que

se olvide algo y aumenta la probabilidad de reconocer la falta de consistencia. Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la implementacin de todos los requisitos del software. Si se aplica un modelo de proceso incremental, se deben identificar los requisitos que se van a entregar en la primera entrega. Trabajar- para eliminar la ambigedad. Como la mayora de los requisitos estn descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad.

1.3.1

ANALISIS DE LOS REQUERIMIENTOS

El anlisis de los requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo del software (Fig. 11.1). El anlisis de requisitos permite al ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. El anlisis de requisitos del software puede dividirse en cinco reas de esfuerzo: (1) reconocimiento del problema, (2) evaluacin y sntesis, (3) modelado, (4) especificacin y (5) revisin. Inicialmente, el analista estudia la Especificacin 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 planificacin. A continuacin, se debe establecer la comunicacin para el anlisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos bsicos del problema tal y como los percibe el cliente/usuario. La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de esfuerzo en el anlisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la informacin, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las caractersticas de la interfaz del sistema y descubrir restricciones adicionales del diseo. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solucin global. Por ejemplo, un mayorista de recambios de automviles 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 rpidamente el estado de un componente; (2) dos o tres das de media para actualizar un archivo a base

de tarjetas; (3) mltiples 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 informacin va a producir el nuevo sistema y qu informacin se le proporcionar al sistema. Por ejemplo, el cliente desea un informe diario que indique qu piezas se han tomado del inventario y cuntas piezas similares quedan. El cliente indica que los encargados del inventario registrarn el nmero de identificacin de cada pieza cuando salga del inventario.

figura 1.1

Una vez evaluados los problemas actuales y la informacin deseada (entradas y salidas), el analista empieza a sintetizar una o ms 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 informacin, se consideran las arquitecturas bsicas para la implementacin. Un enfoque cliente/servidor parecera apropiada, pero est dentro del mbito esbozado en el Plan del Software? Parece que sera necesario un sistema de gestin de bases de datos, pero, est justificada la necesidad de asociacin del usuario/cliente? El proceso de evaluacin y sntesis contina 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 evaluacin y sntesis de la solucin, el enfoque primario del analista est en el qu y no en el cmo. 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 evaluacin y sntesis de la solucin, 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 informacin.

El modelo sirve como fundamento para el diseo del software y como base para la creacin de una especificacin del software.

You might also like