ANÁLISIS

 Según el estándar IEEE, el análisis de requisitos es:

1. El proceso del estudio de las necesidades de los usuarios para
   llegar a una definición de los requisitos del sistema, de hardware
   y de software.
2. El proceso de estudio y refinamiento de dichos requisitos. 

La definición de los requisitos debe ser el fruto del trabajo conjunto de las partes involucradas en un
desarrollo:

• Los desarrolladores del software (a través de los analistas),clientes, usuarios.

El análisis de requisitos facilita la especificación de los requisitos esenciales
(funciones, rendimiento, diseño, restricciones y atributos) del software y de sus
interfaces con otros elementos del sistema. Se indica qué hay que desarrollar, no el
cómo, ni el cuándo se desarrolla el software. No se indica ningún detalle del diseño
del software.

• Definir los requisitos del software. Una tarea iterativa de definición y especificación de los
requisitos del software a partir de la información obtenida durante el análisis previo.
• Definir los requisitos de las interfaces con el resto de elementos del sistema (usuarios,
hardware y otro software) y con el exterior.
• Integrar los requisitos en un documento de especificación de requisitos del software (ERS)
o especificación funcional del software (EFS) o análisis de requerimientos. 


Por lo tanto el análisis debe:
• Representar y comprender el ámbito de información del
   sistema.

1. Realizar modelos que representen: La información (análisis de datos).
2. Función (análisis funcional).
3. El comportamiento del sistema (análisis de control).

• Subdividir el problema.
• Definir los requisitos del sistema con independencia de los
detalles de implementación.
• Ayudar al cliente a especificar lo que desea.
• Ayudar a los desarrolladores a entender qué quiere exactamente el cliente.
• Se debe especificar lo que el usuario desea sin considerar cómo se va a desarrollar.
• Debe incluir la definición correcta de los requisitos, pero no más:

1.  Funciones
2. Rendimiento.
3.  Prestaciones.
4. Restricciones de diseño.
5. Atributos.
6. Interfaces externos.

No debe incluir detalles de diseño y gestión de proyectos.

El análisis de requisitos proporciona al analista una representación de la información, y de las funciones que se puede traducir en un diseño de datos, diseño arquitectónico y funcional. 

Por último, la especificación de requisitos suministra al cliente y al analista un medio para valorar la calidad del software una vez que se haya construido. El análisis de requerimientos supone el 15-20% del esfuerzo total del desarrollo del software. El análisis previo supone el 10-15% del esfuerzo total de desarrollo. La fase completa de análisis conlleva aproximadamente el 30% del esfuerzo. La Estructura de una buena ERS (según IEEE) podría ser ésta: 

 Búsqueda y descripción de requisitos funcionales

•  El análisis de requisitos siempre comienza con una comunicación entre dos o más partes 
• . Existe un cliente que tiene un problema al que se le puede dar una solución basada en ordenador
• El analista responde a la petición del cliente y comienza una comunicación. 

El proceso de análisis debería seguir los siguientes pasos: 

• Identificar las fuentes de información relevantes para el proyecto (usuarios)

• Realizar las preguntas apropiadas para comprender sus necesidades.

• Analizar la información recogida para detectar los aspectos que quedan poco claros.

• Confirmar con los usuarios lo que parece haberse comprendido de los requisitos.

• Sintetizar los requisitos en un documento de especificación apropiado. 

El resultado de este proceso es un documento que especifique lo más claramente posible los requisitos que debe cumplir el software. Para obtener la información necesaria, para generar dicha especificación o bien para realizar un análisis de viabilidad, usaremos una serie de técnicas de recogida de información siendo las siguientes las más utilizadas:

• Entrevistas. Es la técnica más empleada y la que requiere una mayor preparación y experiencia por parte del analista. Es similar a una entrevista periodística en la que el desarrollador entrevista uno a uno a los futuros usuarios del software.

 • Desarrollo conjunto de aplicaciones (JAD). Se crean equipos de usuarios y analistas que se reúnen para trabajar conjuntamente en la determinación de las características que debe tener el software para satisfacer las necesidades de los usuarios.

 • Prototipado. Consiste en la construcción de un modelo o maqueta del sistema que permite a los usuarios evaluar mejor sus necesidades.

 • Observación. Consiste en analizar in situ cómo funciona la unidad o el departamento que se quiere informatizar.

 • Estudio de documentación. En casi todas las organizaciones existen documentos que describen el funcionamiento del negocio, desde planes estratégicos hasta manuales de operación. El analista debe estudiar esta documentación para hacerse una idea de la normativa que rige la empresa. También es conveniente que recopile muestras de los impresos que se utilizan, ya que nos permiten conocer datos que se manejan.

 • Cuestionarios. Resultan útiles para recoger información de un gran número de personas en poco tiempo, especialmente en situaciones en las que se da gran dispersión geográfica. • Tormenta de ideas. Consiste en reuniones de cuatro a diez personas (usuarios) en las cuales, se sugieren toda clase de ideas sin juzgarse su validez, por muy disparatadas que parezcan. En una segunda fase, se realiza un análisis detallado de cada propuesta.