3.3 ANALISIS DE REQUERIMIENTOS

3.3 ANALISIS DE REQUERIMIENTOS

En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.

En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.

La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.

¿QUE ES UN REQUERIMIENTO?

• Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
• Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
• Una condición o capacidad que debe ser conformada por el sistema (RUP).
• Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).

• Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar.
• Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitarles son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
• Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto

Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.

En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.

El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y el diseño de programas . 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 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 del 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

El análisis de requerimientos puede dividirse en cuatro áreas:

1.- Reconocimiento del problema

2.- Evaluación y síntesis

3.- Especificación

4.- Revisión.

Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de 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 requeridas para el análisis se ilustran en la Figura 2. El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y 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, establecer las características de la interfase del sistema y descubrir las ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global. 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 mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente y el técnico. Una vez que se hayan descrito las funcionalidades 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 como base para hacer una 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 realizar 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.

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 mas 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 de software para determinar si las primeras estimaciones siguen siendo validas después del conocimiento adicional obtenido durante el análisis.

OBJETIVOS DE NEGOCIO

Ø  El software se desarrolla para satisfacer una necesidad o resolver un problema.

Ø  Se debe comprender bien el fondo del problema desde el punto de vista del Negocio.

Ø  Por ejemplo: "un software que agilice el proceso de etiquetado de conservas", es un objetivo de negocio.

Ø  Es un objetivo ya que no es información detallada, es de alto nivel.

OBJETIVOS DE PROYECTO

Ø  El Software se desarrolla en el contexto de un Proyecto de Software.

Ø  Contemplan: plazos, costos, herramientas de desarrollo, plataformas, entre otros.

Objetivos de Sistema

Ø  Son como requerimientos no verificables, por ejemplo:

Ø  "Tener buen tiempo de respuesta"

Ø  "Que el software tenga una interfaz amigable"

Ø  "Que sea fácil de usar"

En resumen, son características del Sistema.

  Es muy fácil confundir Objetivos de Sistema con Requerimientos, tener bien claro para el certamen