ANÁLISIS DE REQUERIMIENTOS

Permite especificar las características operacional del software (función, datos y

rendimiento), indica la interfaz del software con otros elementos del sistema y
esteblece las restricciones que debe cumplir el software.

Este análisis puede dividirse en cinco áreas de esfuerzo;

Reconocimiento del problema. El analista estudia la especificación del sistema y

el plan del proyecto del software. El objetivo del analista es reconocer los
elementos básicos del problema tal como lo percibe el usuario/cliente.

Evaluación y síntesis. El analista debe evaluar el flujo y la estructura de la

información, definir y elaborar todas las estructuras del software, entender el
comportamiento del programa en el contexto de los sucesos que afectan al
sistema, establecer las características de la interfaz y descubrir las restricciones
del diseño.

Modelización. El analista crea modelos del sistema en un esfuerzo por entender

mejor el flujo de datos y de control, el procesamiento funcional, el comportamiento
en operación y el contenido de la información. El modelo servirá de pilar para el
diseño del software y como base para la creación de una especificación del
software.

Especificación. Una vez que se ha descrito la información básica, las funciones,

el rendimiento, el comportamiento y la interfaz, se especifican los criterios de
validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software.

Revisión. Se vuelve a evaluar el plan del proyecto del software, para determinar si
las primeras estimaciones siguen siendo validas después del conocimiento
adicional obtenido durante el análisis.

Técnicas para facilitar la especificación de aplicaciones (TFEA)

Este enfoque es partidiario de la creación de un equipo conjunto de clientes y
desarrolladores que trabajan juntos para identificar el problema, proponer
soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de
requisitos de las soluciones.

Existen diferentes enfoques de TFEA, pero todos aplican alguna variación en las
siguientes directrices básicas:

 La reunión se celebra en un lugar neutral, y acuden tanto los clientes como

los desarrolladores.
 Se establecen normas para la preparación y participación.
 Se sugiere una agenda lo suficientemente formal como para cubrir todos los
puntos importantes, pero lo suficientemente informal para estimular el flujo
libre de ideas.
 Se acuerda la elección de un coordinador para controlar la reunión.
 Se utiliza un "mecanismo de definición" que pueden ser hojas de trabajo,
gráficos, carteles o pizarras.

El objetivo es identificar el problema, proponer elementos de solución, negociar

diferentes enfoques y especificar un conjunto preliminar de requisitos de la
solución en una atmósfera que permita alcanzar el objetivo.

Despligue de la funión de calidad (DFC)

Es una técnica de gestión de calidad que traduce las necesidades del cliente en
requisitos técnicos del software.

DFC hace énfasis en entender lo que resulta valioso para el cliente y después
desplegar estos valores a lo largo del proceso de ingeniería.

DFC identifica tres tipos de requisitos:

 Requisito normales: Se declaran objetivos y metas para un producto o

sistema durante las reuniones con cliente. Si estos requisitos están
presentes, el cliente quedará satisfecho.
  Requisitos esperados: Estos son ímplicitos al producto o sistema y
pueden ser tan fundamentales que el cliente no les declara explícitamente.
Su ausencia sería motivo de una insatisfacción significativa.
 Requisitos innovadores: Estas características van más allá de las
expectativas del cliente y suelen ser muy satisfactorias.

En las reuniones con el cliente y se deben tomar en cuenta los siguientes puntos:

 Despliegues de función: Se emplea para determinar el valor de cada

función requerida para el sistema.
 Despliegue de información: Identifica tanto los objetos de datos como los
acontecimientos que el sistema debe producir y consumir. Estos están
unidos a las funciones.
 Despliegue de tareas: Examina el comportamiento del sistema o producto
dentro del contexto de su entorno.

ANÁLISIS DE SISTEMAS

El análisis de sistemas es una de las etapas de construcción de un sistema

informático, que consiste en relevar la información actual y proponer los rasgos
generales de la solución futura.
“En sentido amplio, un sistema es un conjunto de componentes que interaccionan
entre sí para lograr un objetivo común”. Siguiendo esta propuesta, podemos decir
que un sistema es la organización de partes interactuantes e interdependientes
que se encuentran unidas y relacionadas para formar una célula compleja. Con
esto nos referimos a un grupo de elementos que realizan actividades para
alcanzar un objetivo común, ya sea operando sobre los datos, la energía o la
materia para suministrar información. “Los sistemas proporcionan información
tanto de problemas como de oportunidades”. La clasificación y el análisis de las
características de un sistema es un proceso que requiere conocer quién lo realiza,
el objetivo que se pretende alcanzar y las condiciones particulares en las que se
desarrolla. Sin embargo, antes de emprender el análisis de un sistema, conviene
estar al tanto de la clasificación general de los sistemas. De acuerdo a su
constitución, los sistemas se clasifican de la siguiente manera:

 Sistemas físicos o concretos: estos sistemas están compuestos por

elementos tangibles, por ejemplo maquinas, equipos u objetos. En
informática, nos referimos a estos sistemas como el hardware.
 Sistemas abstractos: son sistemas conformados por elementos cognitivos,
por ejemplos los planes, las hipótesis y las ideas. Estos sistemas son
conocidos como software en el campo de la informática. Respecto a su
relación con el medio ambiente los clasificamos como abiertos o cerrados:
 Sistemas abiertos: este tipo de sistemas se intercambia materia, energía o
información con el ambiente.
 Sistemas cerrados: son aquellos sistemas en los cuales el intercambio de
materia, energía o información con ambiente es considerado como nulo.