Mis enlaces favoritos nuevo
Mis enlaces favoritos
Curriculum vitae
Album de fotos
Mis aficiones
REQUERIMIENTOS DEL SOFTWARE
REQUERIMIENTOS DEL SOFTWARE
 
imagen
 
INDICE

INTRODUCCION
REQUERIMIENTOS DEL SOFTWARE
CARACTERÍSTICAS DE LOS REQUERIMIENTOS
DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS
CARACTERÍSTICAS DE UN REQUERIMIENTO
FUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOS
TAREAS DEL ANÁLISIS
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)
CLASIFICACIÓN DE LOS REQUERIMIENTOS
ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
PRINCIPIOS DE ESPECIFICACIÓN
MANEJO DE REQUERIMIENTOS
ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO
REQUERIMIENTOS DEL SISTEMA
ESTRATEGIA DEL FLUJO DE DATOS
ESTRATEGIA DEL ANÁLISIS DE DECISIONES
ETAPAS EN LA ESTRATEGIA DEL ANÁLISIS DEL FLUJO DE DATOS
UTILIZACIÓN DE LOS DATOS DE REQUERIMIENTOS
DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE
MÉTODOS DE ANÁLISIS ORIENTADOS AL FLUJO DE DATOS
DIAGRAMAS DE FLUJOS DE DATOS
DICCIONARIO DE DATOS
DESCRIPCIONES FUNCIONALES
MÉTODOS ORIENTADOS A LA ESTRUCTURA DE DATOS
BIBLIOGRAFÍA
ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

INTRODUCCION

¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

* Dificultades para definir los requerimientos *

• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

* Ingeniería de Requerimientos vs. Administración de Requerimientos *

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces debemos de definir que características deben de poseer los requerimientos adecuadamente formulados.

Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo sabemos si cumplimos con él o no?
Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo)
Lo más abstracto y conciso posible. Para evitar malas interpretaciones.


* 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".
Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, que el conjunto de requerimientos de un sistema computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus 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.

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 más 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.

* Obteniendo de la información *

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentación que describa la manera que el cliente desea que funcione el sistema de software.

Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada revisión o cambio que se haga a esta documentación. Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas serán satisfechas por el software y cuales por algún otro producto del sistema.

* Especificación de Requisitos de Software *(SRS)

La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.
Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema.
La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la SRS son verificadas en la actividad de Validación, descrita en el punto.
La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla.
Clasificación de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus características no pueden ser tratados iguales.
La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones.
• Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos que se clasifican en esta categoría por que:
El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestión en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos.
• Requerimientos "ergonómicos"
Él mas conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonómicos son la forma en que el ser humano interactúa con el ser sistema.
• Requerimientos de Interfase
La interfase es como interactúa el sistema con el ser humano o con otros sistemas (el enfoque es prácticamente el opuesto a los requerimientos ergonómicos), La interfase es la especificación formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de información, el medio para comunicarse y el formato de los datos que se van a comunicar.
* Actividades de la Ingeniería de Requerimientos *

En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:
• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución
* Principios de Especificación *

La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta implementación del software.
Baltzer y Goldman proponen ocho principios para una buena especificación:

PRINCIPIO #1. Separar funcionalidad de implementación.
Primero, por definición, una especificación es una descripción de lo que se desea, en vez de cómo se realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un conjunto particular de salida. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En tales especificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el que (en vez de cómo). En parte, esto es debido a que el resultado es una función matemática de la entrada (la operación tiene puntos de comienzo y parada bien definidos) y no esta afectado por el entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al comportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento no puede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en la cual la especificación del que se consigue mediante la especificación de un modelo del comportamiento deseado en términos de respuestas funcionales, a distintos estímulos del entorno.
PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una componente.
Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente especifica. En general, un sistema puede ser modelado como una colección de objetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormente cambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder.
PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es una agente, Los otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementación subsecuente opera exclusivamente sobre la especificación del sistema. La especificación del entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio sistema, en vez de introducir otro formalismo.
PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario. Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los agentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes o indican la necesidad de una posterior elaboración para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificación debe ser operacional.
La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar si una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente. Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datos elegibles, debe ser posible usar la especificación para validar estos resultados. Esto implica que la especificación, aunque no sea una especificación completa del como, pueda actuar como un generador de posibles comportamientos, entre los que debe estar la implementación propuesta. Por tanto, en un sentido extenso, la especificación debe ser operacional.
PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud y aumentable.
Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe es demasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, de alguna situación real (o imaginada). Por tanto, será incompleta. Además, al ser formulad existirán muchos niveles de detalle. La operacionalidad requerida anteriormente no necesita ser completa. Las herramientas de análisis empleadas para ayudar a los especificadores y para probar las especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita el análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, los cuales satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada.
Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de la dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una especificación sea servir como base para el diseño e implementación de algún sistema, no es un objeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones. Tales modificaciones se presentan en tres actividades principales: formulación, cuando se está creando una especificación inicial; desarrollo, cuando la especificación se esta elaborando durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando la especificación se cambia para reflejar un entorno modificado y / o requerimientos funcionales adicionales.
• Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa él ¿Qué? Y no él ¿Cómo?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema.
• Requerimientos de desempeño
Estos requerimientos nos informan las características de desempeño que deben de tener el sistema. ¿Que tan rápido?, ¿Que tan seguido?, ¿Cuantos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeño de un sistema es tan crítico como su funcionamiento.
• Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradación, potabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipo de requerimientos es también muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones críticas que no deben de estar fuera de servicio por periodos prolongados de tiempo.
• Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Que tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de código dentro del sistema, son muy importantes en el proceso de diseño ya que facilitan la introducción y aceptación del sistema en donde será implementado.
• Restricciones de diseño
Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este tipo de normas caen como "restricciones de diseño".
• Materiales
Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los costos de industrialización del sistema.

* Manejo de requerimientos *

De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra:
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este acuerdo son los requerimientos del sistema alojados al software." … ". Este acuerdo cubre requerimientos técnicos y no técnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida." … "Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos que están bajo su responsabilidad estén documentados y controlados"
¿De que manera podemos controlar los requerimientos de software si estos siempre evolucionan con el tiempo?. El CMM nos proporciona las guías para lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa los requerimientos antes de que estos sean incorporados al proyecto de software y cada vez que los requerimientos cambian los planes, productos, y actividades son ajustadas para quedar en línea con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos débenos de tomar en cuenta dos cosas.
• Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y no son impuestos por en su totalidad por presiones externas ajenas al proyecto.
El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no técnicos (Calidad, Costo y Tiempo de entrega) deberán estar especificados de común acuerdo con el grupo de requerimientos del proyecto de software.
• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia uno forzosamente deberán cambiar los demás. Esto es: más contenido técnico implica o más costo, o menos calidad o más tiempo estimado de entrega. De modo que los cambios técnicos deberán ser aprobados por el grupo de requerimientos y este grupo estimará los impactos en tiempo, costo, calidad. El resultado de la estimación es la entrada a los líderes del proyecto para decidir si el cambio se acepta o no.

* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *

Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios, lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensible los fundamentos de todos los aspectos del desarrollo. Para captar las necesidades específicas de los usuarios es indispensable que los documentos que recogen los requerimientos se redacten utilizando métodos pragmáticos.
Se debe utilizar una metodología detallada de definición de los requerimientos de usuario. Organizar entrevistas destinadas a obtener la máxima información posible acerca de los requerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos del proyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un documento de requerimientos generales. Conseguir la participación y confirmación del usuario.
Los gerentes y usuarios del sistema también poseen un papel importante en le diseño del sistema; no es solamente el proyecto del analista. Durante el diseño, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada.
La participación del usuario proporciona al analista una retroalimentación importante conforme avanza en el diseño; además asegura a los usuarios tengan un conocimiento no técnico de lo realizara o no el nuevo sistema.
Esta visión general del diseño de sistemas subraya los aspectos de diseño que se verán mas adelante en el diseño de la salida de sistema.

* REQUERIMIENTOS DEL SISTEMA *

Los Sistemas de Información por computadora normalmente están integrados por muchos componentes. En la mayor parte de los casos, es difícil para los analistas entender todos estos componentes aún mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relación al propósito del sistema sus entradas y salidas de los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar en forma independiente.
Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de información. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información.

* Estrategia del Flujo de Datos *

Cuando se siguen un flujo a través de los procesos de negocio, que es el propósito del análisis del flujo de datos, le indica a los analistas una gran cantidad de datos sobre como sé esta llevando a cabo los objetivos de la compañía. Al manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.
El análisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los hallazgos en los diagramas de flujo de datos.

* Estrategia del Análisis de Decisiones *

La estrategia del análisis de decisiones es un complemento del análisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operación y de las decisiones que deben realizarse para cumplir con los objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, la estrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la opción que toma un supervisor de departamento para aceptar o rechazar pedidos.
La decisión de rechazar pedidos generalmente ocurre con más frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante.

* Etapas en la Estrategia del Análisis del Flujo de Datos *

1. - Estudiar las operaciones y procesos en marcha.
2. - Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas.
3. - Seguir el flujo de datos:
* Proceso
* Almacenamiento
* Recuperación
* Salida
4. - Añadir gradualmente detalles a los niveles inferiores.
Etapas en la Estrategia del Análisis de Decisión
1. -Estudiar los objetivos y decisiones necesarias.
2. - Desarrollar un modelo del proceso de decisión.
3. - Probar el modelo con datos de prueba.
4. - Identificar los requerimientos del proceso para los datos.

* Requerimientos De Entrada *

Es el enlace que une al sistema de información con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son:
• Objetivos del Diseño de Entrada.
• Captura de Datos para la Entrada.

Objetivo del Diseño de Entrada
Consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los procesos necesarios para poner los datos de transacción en una forma utilizable para su procesamiento así como la entrada de los datos se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos ó por personas que los escriben directamente al sistema.
Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasos necesarios, estos son:
• Control de la Calidad de Entrada
• Evitar los Retrasos
• Evitar los errores en los datos
• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso
Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseñador debe controlar la cantidad de datos en la entrada:
- Las Operaciones de preparación y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparación de ingreso de los datos también lo son.
-
La fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para realizar sus tareas.

Evitar los Retrasos:
También conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al diseñar la entrada, una forma de evitarle es utilizar los documentos de retorno.

Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea esta menores serán las oportunidades para cometer errores. Es común encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:
Algunas veces el volumen de transacciones y la cantidad de datos en preparación es algo que no se puede controlar por ello el analista experimentado, evitara diseños para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un día.

Mantener la sencillez del Proceso:
El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo proporcionarán métodos para el control de los errores, la simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que no exista ninguna garantía para el éxito al instalar un sistema complejo y que domine.
Captura de Datos para la Entrada:
En una transacción existen datos importantes y otros que no, el analista debe saber cuales utilizará y cuales en realidad deben formar la entrada. Existen dos tipos de datos:
• datos variables
• datos de identificación
Datos Variables:

Son aquellos que cambian para cada transacción o toman de decisión.
Datos de Identificación:
Estos son los que identifican en forma única el artículo que esta siendo procesado.

* Requerimientos De Salida *

Niveles de diseño
El diseño de sistema se representa a través de dos fases: el diseño lógico y el diseño físico.
Cuando los analistas formulan un diseño lógico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus características: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto.
El diseño lógico de un sistema de información es como el plano de un ingeniero para armar un automóvil: muestra las características principales(motor, transmisión y área para los pasajeros)y como se relacionan unas con otras(donde se conectan entre sí los componentes del sistema, o por ejemplo, cuan separadas están las puertas.
Los informes y la producción del analista son los componentes de todo el mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje.
El diseño lógico también especifica las formas de entrada y las descripciones de las pantallas de todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las transacciones y los datos del proveedor. Las especificaciones de los procedimientos describen métodos para introducir los datos, corridas de informes copiados de archivos y detección de problemas.
El diseño físico, actividad que sigue el diseño lógico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseño indican a los programadores que debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos.
Utilización de los Datos de Requerimientos:
El alcance del diseño de sistemas se guía por el marco de referencia para el nuevo sistema desarrollado durante el análisis. Los datos de los requerimientos, recopilados durante la investigación, conforman las actividades y componentes del sistema. Los analistas formulan un diseño lógico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos.
En primer lugar se identifican las características generales, como informes y entradas; en el diseño de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato específico para establecer cuanto espacio dejar en la información, en la pantalla de despliegue visual o archivo.
A lo largo de los años hemos visto una evolución de ideas y técnicas en el campo del análisis de sistemas. La cual cabe en tres períodos amplios según Yourdon:
1. El análisis de sistema convencional, anterior a los años 70´s, caracterizado por especificaciones tipo novela victoriana que eran difíciles de leer y entender, y casi imposibles de mantener.
2. El análisis estructurado clásico, de mediados de los años 70´s, a mediados de los años 80´s. Esto se caracterizó por primeras versiones de modelos gráficos, y énfasis en el modelado de las implementaciones actuales de un sistema antes de modelar el nuevo.
3. El análisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelar sistemas de tiempo real y relaciones de situaciones complejas. Aumentando por ende la comunicación entre el analista y el sistema.
En la actualidad las técnicas modernas están siendo fusionadas, para así lograr un mejor método que pueda hacerle frente a las necesidades de las diferentes fases del ciclo de vida del sistema, incluyendo a la fase de análisis. Obteniendo de está manera mejores resultados que pueda interpretar el analista en forma rápida y precisa.
En primera instancia debemos decir que el análisis estructurado según Senn "permite al analista conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente". El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. Se puede decir adicionalmente que los componentes del análisis estructurado son los siguientes: símbolos gráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas.
Después de relacionarnos brevemente con la terminología básica, podemos entrar en aspectos relacionados con los cambios del análisis estructurado.
Podemos decir que para finales de los años 60´s e inicios de los 70´s el análisis estructurado surge de la necesidad de buscar una forma interpretativa más rápida y eficiente, de tal manera que se pudiesen definir los requerimientos del usuario y las especificaciones funcionales del sistema. Pero esto no se daba porque lo que existía eran grandes volúmenes de información que había que leer por completo y que acarreaban una serie de problemas de: monolitismo, redundancia, ambigüedad e imposibilidad de mantener. Es por ello que surge una amplia variedad de diagramas que permiten representar las especificaciones funcionales en forma sencilla y rápida, aumentando por ende el grado de comunicación entre las especificaciones funcionales y el usuario final (analista, programador, diseñador).
Posteriormente, a mediados de los años 70´s estando el análisis estructurado clásico en su apogeo aparecen una serie de dificultades que limitan al analista hacer un buen desempeño de sus actividades. Entre estos problemas según Yourdon podemos mencionar:
• Distinción difusa y poca, definida entre los modelos lógicos y los modelos físicos.
• Limitación para modelar sistemas en tiempo real.
• El modelo de datos se hacía de una manera primitiva.

Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis estructurado clásico tales como: diagramas de entidad-relación, diagramas de transición de estados, división de eventos, modelos esenciales y modelos de implantación. Pero a pesar de esto según Yourdon se siguieron dando más problemas como los siguientes:
• Tras la segunda y tercera correcciones de un diagrama, el analista se volvía cada vez más apuesto y renuente a hacer más cambios.
• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el modelo del sistema en modelos de menor nivel, quedando por ende, funciones primitivas.
• A menudo no se incorporaban en el modelo del sistema los cambios en los requerimientos del usuario sino hasta después de la fase de análisis del proyecto.
Inclusive las correcciones de los diagramas había que hacerlas en forma manual, para asegurar que fuesen consistentes y estuviesen completas; lo cual era bastante tedioso y dejaba por fuera muchos errores que debían de encontrarse. Pero para mediados de los 80´s aparecieron las herramientas CASE que trataron de subsanar estos problemas. Las herramientas CASE (Ingeniería de software auxiliada por computadora) se utilizan para dibujar diagramas de flujo de datos y otros además de llevar a cabo una variedad de labores de revisión de errores.
Finalmente, algunos usuarios tenían dificultades al tratar con los modelos gráficos del análisis estructurado y preferían alguna otra forma de modelar los requerimientos y comportamiento del sistema; es por ello que aparecen las herramientas de generación de prototipos (mediados de los 80´s) que son considerados como una alternativa al análisis estructurado para tales usuarios. También se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo largo de todo el desarrollo del sistema, para no perder la secuencia de lo que se está realizando.
En la actualidad muchas de estas herramientas se están utilizando para facilitar la fase de análisis, e inclusive se están elaborando o fusionando lo mejor de cada una de las técnicas que atienden las necesidades de todas las fases del ciclo de vida del sistema; para así obtener un mejor aprovechamiento, entendimiento, y rendimiento al momento que se ponga a correr el sistema. Disminuyendo de esta manera la serie de errores que se cometían anteriormente, con la introducción de herramientas más especializadas y fáciles de utilizar.
Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo de los últimos años. Las principales áreas de cambio incluyen lo siguiente según Yourdon:
• Cambios de terminología.
• Partición de acontecimientos.
• La desenfatización del modelado físico actual.
• Herramientas de modelado en tiempo real.
• Integración más cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darán, si es que ya no se están dando, los siguientes cambios o pautas en el ámbito total en lo que se refiere a análisis según Yourdon:
• Mayor difusión del análisis de sistemas, sobre todo en los siguientes grupos: los niveles superiores de administración en organizaciones gubernamentales y de negocios, los niños, y profesionales de la computación en los países del tercer mundo.
• Impacto sobre la industria de software del tercer mundo.
• Proliferación de las herramientas automatizadas, aunque no todos los analistas tienen acceso a las últimas herramientas de análisis.
• Impacto de los desastres de mantenimiento.
• Integración del análisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del análisis estructurado va a depender mucho también de que tan rápido pueda ajustarse el mismo a los cambios tecnológicos que se viven hoy en día. Debido a que han estado surgiendo otras técnicas en otras áreas como lo es la orientada a objetos, la cual prevé un buen futuro y muchas mejoras para los sistemas actuales.

* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*

Fue la aparición del diseño y la programación estructurada alrededor de los años 60´s la que dieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar una notación gráfica para representar los datos y los procesos que los transforman". Es por ello que surgen una serie de temas afines tales como: herramientas automatizadas (CASE), prototipos, diagramas de entidad-relación etc.
Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada por computadora), elaboración de prototipos, símbolos gráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas, diagramas de estados, diagramas de entidad-relación, diagramas de transición de eventos, división de eventos, modelos esenciales y modelos de implantación.

* Métodos de Análisis Orientados al Flujo de Datos *

La información se transforma como un flujo a través de un sistema basado en computadora. El sistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanos para transformar la entrada en salida; y produce una salida en distintas formas. La entrada puede ser una señal de control transmitida por un transductor, una serie de números escritos por un operador humano, un paquete de información transmitido por un enlace a red, o un voluminoso archivo de datos almacenado en memoria secundaria. La transformación puede comprender una sencilla comparación lógica, un complejo algoritmo numérico, o un método de inferencia basado en regla de un sistema experto. La salida puede encender un sencillo led o producir un informe de 200 páginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema basado en computadora independientemente del tamaño o complejidad.

La función global del sistema se representa como una transformación sencilla de la información, representada en la figura como una burbuja. Una o más entradas. Representadas como flechas con etiqueta, conducen la transformación para producir la información de salida. Puede observarse que el modelo puede aplicarse a todo el sistema o solo a un elemento de software. La clave es representar la información dada y producida por la transformación.

* 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]...

* Descripciones Funcionales *

Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionario de datos), el analista describe cada función (transformación) representada, usando el lenguaje natural o alguna otra notación estilizada. Una de tales notaciones se llama ingles estructurado (también llamado lenguaje de diseño del programa o proceso(LDP)). El ingles estructurado incorpora construcciones procedimentales básicas –secuencia, selección y repetición- junto con frases del lenguaje natural, de forma que pueden desarrollarse descripciones procedimentales precisas de las funciones representadas dentro de un DFD.

* Métodos Orientados a la Estructura de Datos *

Hemos ya observado que el dominio de la información para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisis orientados a la estructura de datos representan los requerimientos del software enfocándose hacia la estructura de datos en vez de al flujo de datos. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta, todos tienen algunas características en común: 1) todos asisten al analista en la identificación de los objetos de información clave (también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos); 2)todos suponen que la estructura de la información es jerárquica; 3)todos requiere que la estructura de datos se represente usando la secuencia, selección y repetición; y 4) todos dan una conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa.
Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software.



 
BIBLIOGRAFÍA


Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda Edición. McGraw Hill. 1992.

JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill, Enero 1990

JAMES A. SENN, Análisis y Diseño de Sistemas de Información, Segunda Edición, Mc Graw Hill, Abril 2000.

IEEE Task Force on Requirements Engineering. Software Engineering Resources by Roger S. Pressman & Associates
Edward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice Hall Hispanoamericana, S. A., pp. 136-147, 500-511.
Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247.
Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill.
Larman, C. "UML y patrones: Introducción al análisis y diseño orientado a objetos". Prentice halll.
COMENTARIOS
Escribe tus comentarios son de gran utilidad