Make your own free website on Tripod.com
ANALISIS Y ESPECIFICACIONES FUNCIONALES Y NO FUNCIONALES DEL SOFTWARE

REQUERIMIENTOS

Fundamentos del Análisis de Requerimientos
Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software.

Es la etapa más crucial del desarrollo de un proyecto de software.

La IEEE los divide en funcionales y no funcionales:

Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un problema o alcanzar un objetivo.

No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto.

Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.

La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento. El ámbito del programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos elementos de los programas las soluciones alternativas.

Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y comportamiento de los programas en detalles concretos, El que desarrolla el software actúa como interrogador, consultor y el que resuelve los problemas.

El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: “Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir”.

Análisis de Requerimientos
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 de 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

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.

SRS(Software Requeriment Specification)

Este documento es generado a través del estándar IEEE-830(1998) y tiene todas las características de funcionamiento, apariencia y seguridad que debe presentar un sistema desde el punto de vista del cliente, del usuario y del desarrollador. Se constituye por tres secciones. En la primera se especifican las características de la empresa-cliente, de los usuarios y las definiciones generales del sistema; en la segunda, se definen entre otras cosas, las políticas, las necesidades de hardware y de conocimientos previos de los usuarios, así como las dependencias, cuestiones y situaciones que se asumen como cubiertas previamente a la utilización del sistema. En la tercera sección, se sigue una plantilla de contenido que permite detallar con claridad cada una de las funcionalidades del sistema(Tiempo, Costo y Calidad).

Un proyecto comienza con la detección de un problema y oportunidades de mejora dentro de un negocio. Una vez que es sugerido un proyecto el analista de sistemas trabaja rápidamente con los responsables de la toma de decisiones para determinar si es factible. Si es aprobado el proyecto se hace un estudio de sistemas completo. Las actividades del proyecto son calendarizadas mediante graficas. La productividad estará determinada por el manejo efectivo de las actividades calendarizadas.

Cuando se hace un análisis de sistema es necesario dividir el trabajo en secciones. La primera sección que se debe considerar es la recolección de datos. La recolección de datos esta compuesta de las siguientes actividades: realización de entrevistas, administración de cuestionarios, lecturas de reportes de la compañía, presentación del prototipo, observación de las reacciones ante el prototipo.

En el análisis de flujo de datos y decisiones se realizan esquemas de representación que se denominan diagramas de flujo de datos en los que se describen los procesos y la forma en que los datos fluyen entre ellos.

Para la realización de la propuesta se deben tomar en cuenta tres actividades: realización de análisis costo-beneficio, preparación de la propuesta y por ultimo presentación de la propuesta.

Diagramas de Flujos de Datos
Conforme con la información se mueve a través del software, se modifica mediante una serie de transformaciones. Un diagrama de flujos de datos (DFD), es una técnica grafica que describe el flujo de información y las transformaciones que se aplican a los datos, conforme se mueven de la entrada a la salida. El diagrama es similar en la forma a otros diagramas de flujo de actividades, y ha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. También se le conoce como un grafo de flujo de datos o un diagrama de burbujas.

Diccionario de Datos
Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de información. Por tanto, el analista debe disponer de algún otro método para representar el contenido de cada flecha de un DFD.

Se ha propuesto el diccionario de datos como una gramática casi formal para describir el contenido de los elementos de información y ha sido definido da la siguiente forma:

El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, en una especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datos que pueden ser además divididos) se definen en términos de sus componentes; los datos elementales (datos que no pueden ser divididos) se definen en términos del significado de cada uno de los valores que puede asumir. Por tanto, el diccionario de datos esta compuesto de definiciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos [transformaciones].