REQUERIMIENTOS DEL SOFTWARE

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.

Por ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no. es ellos se basan muchos participantes del proyecto para: Planear el proyecto y los recursos que se usarán en él. Son el fundamento del ciclo de vida del proyecto. Planear la estrategia de prueba a la que habrá de ser sometido el sistema. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. 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 líderes de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.* Ingeniería de Requerimientos vs. Especificar el tipo de verificaciones que se habrán de realizar al sistema. analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. 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. Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software. Administración de Requerimientos * El proceso de recopilar. Los requerimientos deben ser: .

Si un requerimiento no se puede comprobar. El ámbito del programa. Como todo contrato o acuerdo entre dos partes Posibles de probar o verificar. Independientemente de lo bien diseñado o codificado que esté.Especificados por escrito. una especificación u otro documento formalmente impuesto. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo) Lo más abstracto y conciso posible. No Funcionales: Condición o capacidad que debe poseer un sistema para satisfacer un contrato. Se . 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. establecido inicialmente durante la ingeniería del sistema. Para evitar malas interpretaciones. La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento. Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos de los mismos. entonces ¿cómo sabemos si cumplimos con él o no? Descritos como una característica del sistema a entregar. * 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. un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo. un estándar. es refinado en detalle. Es la etapa más crucial del desarrollo de un proyecto de software.

El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla. pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir". cuando se ven en su conjunto son extensos y detallados. Esto se logra mediante al clasificar. 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. Lo que nos da a concluir. Puesto que el contenido de comunicación es muy alto. algo nebuloso. El cliente intenta reformular su concepto. indicar la interfaz con otros elementos del sistema y .analizan y asignan a los distintos elementos de los programas las soluciones alternativas. Los requerimientos de un sistema de software. En otras palabras al analizar sus requerimientos. de la función y comportamiento de los programas en detalles concretos. abundan los cambios por mala interpretación o falta de información. que el conjunto de requerimientos de un sistema computacional es complejo. El análisis de requerimientos facilita al ingeniero de sistemas especificar:   la función y comportamiento de los programas. pero las apariencias engañan. El que desarrolla el software actúa como interrogador. y además contienen múltiples relaciones entre sí. 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. Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de requerimientos. consultor y el que resuelve los problemas. estructurar y organizar todo lo que el sistema debe de hacer.

A continuación.Evaluación y síntesis 3.Revisión. la especificación de requerimientos suministra al técnico y al cliente:  los medios para valorar la calidad de los programas.. el analista estudia la especificación del sistema (si existe) y el plan de proyecto. 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.. de forma que se asegure el reconocimiento del problema. Inicialmente. una vez que se haya construido. 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.Especificación 4. establecer las ligaduras de diseño que debe cumplir el programa. El análisis de requerimientos da al diseñador:   la representación de la información y las funciones que pueden ser traducidas en datos.. . Finalmente. debe establecerse la comunicación necesaria para el análisis. * Tareas del Análisis * El análisis de requerimientos puede dividirse en cuatro áreas: 1.Reconocimiento del problema 2.. arquitectura y diseño procedimental.

establecer las características de la interfase del sistema y descubrir las ligaduras del diseño. la especificación se desarrolla conjuntamente entre el cliente y el técnico. Puede parecer innecesario realizar un manual de usuario en una etapa tan . Una vez que se hayan descrito las funcionalidades básicas. Para definir las características y atributos del software se escribe una especificación de requerimientos formal. Además. En un mundo ideal el cliente desarrolla una especificación de requerimientos del software completamente por sí mismo. Cada una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los programas. se especifican los criterios de validación para demostrar una comprensión de una correcta implementación de los programas. El analista debe evaluar el flujo y estructura de la información. En el mejor de los casos. para los casos en los que se desarrolle un prototipo se realiza un manual de usuario preliminar. 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. refinar en detalle todas las funciones del programa.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. Esto se presenta raramente en el mundo real. interfase e información. La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. comportamiento. El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario / cliente.

temprana del proceso de desarrollo. * Obteniendo de la información * Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software. Además. así como cada revisión o cambio que se haga a esta documentación. ligaduras o criterios de validación. Si los requerimientos se enfocan a describir las necesidades del cliente. mediante entrevistas con el cliente o recabando documentación que describa la manera que el cliente desea que funcione el sistema de software. este borrador del manual de usuario fuerza al analista a tomar el punto de vista del usuario del software. Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. 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. Pero de hecho. La revisión de los requerimientos casi siempre produce modificaciones en la función. Por eso es necesario tener archivada una copia de la documentación original del cliente. Es mejor descubrir tales comentarios lo más tempranamente posible en el proceso. Como cada necesidad del . 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". 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. este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente. representación de la información. comportamiento. entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es.

Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. no ambigua. precisa. cada uno de los requerimientos debe cumplirlas.cliente es tratada de diferente forma. * Especificación de Requisitos de Software *(SRS) La especificación de requisitos de software es la actividad en la cual se genera el documento. Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos. usuarios finales. factible. coincide con las necesidades de la empresa. y todo aquel involucrado en la implementación del sistema. En la SRS se definen todos los requerimientos de hardware y software. Para que cada característica de la SRS sea considerada. diagramas. modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores. verificable. describe el alcance del sistema y la forma en cómo hará sus funciones. para que una SRS se considere modificable. modificable. rastreable. personal de pruebas. Las . por ejemplo. es necesario clasificar estas necesidades para saber cuáles de ellas serán satisfechas por el software y cuales por algún otro producto del sistema. cada requerimiento definido en ella debe ser verificable. para que una SRS se considere verificable. analistas de sistema. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema. que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado. cada requerimiento debe ser modificable y así sucesivamente. Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo. definiendo los requerimientos funcionales y los no funcionales. este documento resultante será utilizado como fuente básica de comunicación entre los clientes. consistente. con el mismo nombre. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. La SRS posee las mismas características de los requerimientos: completa. entre otras.

características de la SRS son verificadas en la actividad de Validación. cada uno tiene la potestad de crear su propia plantilla. Existen plantillas creadas para la SRS. existen cierto tipo de requerimientos que se clasifican en esta categoría porque: El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. hay requerimientos que por sus características no pueden ser tratados iguales. bases de datos. Aunque no podemos cambiar el entorno. La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones. sin embargo. sistema de archivos. Clasificación de los requerimientos El clasificar requerimientos es una forma de organizarlos. por lo tanto el entorno se debe de considerar dentro de los requerimientos. La estandarización de la SRS es fundamental pues ayudará. descrita en el punto. El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno. a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados. • Requerimientos del "entorno" El entorno es todo lo que rodea al sistema. además de asegurar que se cubren todos los tópicos importantes. tales como congestión en los dispositivos y errores de entrada de datos. entre otras cosas. . Ejemplos del entorno podemos mencionar: sistemas operativos.

La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. Usualmente se especifica el protocolo.• Requerimientos ergonómicos" Él más conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI (Graphic User Interface). Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior. • 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). el medio para comunicarse y el formato de los datos que se van a comunicar. las actividades de la IR varían tanto en número como en nombres. * Actividades de la Ingeniería de Requerimientos * En el proceso de IR son esenciales diversas actividades. sin embargo. En este documento serán presentadas. los requerimientos ergonómicos son la forma en que el ser humano interactúa con el ser sistema. La interfase es la especificación formal de los datos que el sistema recibe o manda al exterior. el tipo de información. En otras palabras. podemos identificar y extraer cinco actividades principales que son: . estas actividades son aplicadas de manera continua y en orden variado. en un proceso de ingeniería de requerimientos efectivo.

donde P representa un predicado arbitrario. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada). 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 está afectado por el entorno que le rodea. En tales especificaciones. producir un conjunto particular de salida. puede ser vista como un proceso de representación. . Separar funcionalidad de implementación. Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada. Los requerimientos se representan de forma que conduzcan finalmente a una correcta implementación del software. Una especificación es una descripción de lo que se desea. en vez de cómo se realiza (implementa). independientemente del modo en que se realice. el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el que (en vez de cómo).• Análisis del Problema • Evaluación y Negociación • Especificación • Validación • Evolución * Principios de Especificación * La especificación. Baltzer y Goldman proponen ocho principios para una buena especificación: PRINCIPIO #1.

Una especificación debe abarcar el entorno en el que el sistema opera. por tanto. 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.PRINCIPIO #2. un sistema puede ser modelado como una colección de objetos pasivos y activos. PRINCIPIO #3. PRINCIPIO #4. estímulos adicionales a los cuales los agentes deben responder. responden. Solo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente específica. Se necesita un lenguaje de especificación de sistemas orientado al proceso. Las respuestas pueden causar posteriormente cambios y. Un sistema está compuesto de componentes que interactúan. . En vez de ello. Su comportamiento no puede ser expresado como una función matemática de su entrada. el entorno en el que opera el sistema y con el que interactúa debe ser especificado. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos. En general. llamados agentes. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Una especificación debe abarcar el sistema del cual el software es una componente. 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. debe emplearse una descripción orientada al proceso. Similarmente. a distintos estímulos del entorno.

y por tanto limitan el comportamiento de los agentes o indican la necesidad de una posterior elaboración PRINCIPIO para #6. La especificación del entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio sistema. de los cuales el sistema especificado es una agente. Algunas de estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"). Una especificación de sistema debe ser un modelo cognitivo. Esto es. limitan el ámbito del diseño subsecuente y de la implementación. operacional. pasivos y activos. y las acciones que ejecutan deben modelar lo que realmente ocurre en el dominio. los agentes deben modelar los individuos. esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de objetos que interactúan. Los otros agentes. dado el .Afortunadamente. 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. en vez de introducir otro formalismo. organizaciones y equipo de ese dominio. De hecho. PRINCIPIO #5. Debe describir un sistema tal como es percibido por su comunidad de usuario. en vez de un modelo de diseño o implementación. La especificación de un sistema debe ser un modelo cognitivo. los cuales son por definición inalterables debido a que son parte del entorno. 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. Además. prevenir Una que especificación surjan debe estos ser estados. debe ser posible incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio.

Esta surge de la dinámica de la especificación. al ser formulad existirán muchos niveles de detalle. PRINCIPIO #7. El entorno en el que existe es demasiado complejo para ello. PRINCIPIO #8. Una especificación es siempre un modelo. una abstracción. pero tal degradación debe reflejar los restantes niveles de incertidumbre. y . La especificación del sistema debe ser tolerante con la incompletitud y aumentable. sino un objeto dinámico que sufre considerables modificaciones. deben ser capaces de tratar con la incompletitud. 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.resultado de una implementación sobre algún conjunto arbitrario de datos elegibles. será incompleta. no es un objeto estático precompuesto. Ninguna especificación puede ser siempre totalmente completa. Tales modificaciones se presentan en tres actividades principales: formulación. pueda actuar como un generador de posibles comportamientos. aunque no sea una especificación completa del como. Además. de alguna situación real (o imaginada). en un sentido extenso. desarrollo. los cuales satisfacen la especificación. Los principios anteriores tratan con la especificación como una entidad estática. Por tanto. la especificación debe ser operacional. Esto implica que la especificación. cuando se está creando una especificación inicial. La operacionalidad requerida anteriormente no necesita ser completa. Las herramientas de análisis empleadas para ayudar a los especificadores y para probar las especificaciones. debe ser posible usar la especificación para validar estos resultados. el cual puede ser ejecutado ampliando el rango de comportamiento aceptables. cuando la especificación se esta elaborando durante el proceso iterativo de diseño e implementación. Naturalmente esto debilita el análisis. Una especificación debe ser localizada y débilmente acoplada. entre los que debe estar la implementación propuesta. Por tanto.

potabilidad. • Requerimientos funcionales Estos son los que describen lo que el sistema debe de hacer. • Disponibilidad (en un determinado periodo de tiempo) Este tipo de requerimientos se refiere a la durabilidad. 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 • Entrenamiento servicio por periodos prolongados de tiempo. Es importante que se describa él ¿Qué? Y no él ¿Cómo?. ¿Que tan seguido?. ¿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. • Requerimientos de desempeño Estos requerimientos nos informan las características de desempeño que deben de tener el sistema. . flexibilidad. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos.mantenimiento. ¿Cuántos recursos?. cuando la especificación se cambia para reflejar un entorno modificado y / o requerimientos funcionales adicionales. ¿Qué tan rápido?. degradación. la lógica y gran parte del código del sistema.

• Restricciones de diseño Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares. Este acuerdo cubre requerimientos técnicos y no . • Materiales Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. el manejo de requerimientos involucra: "Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. ¿Qué tipo de usuarios son?." … ". ¿Que tipo de operadores?. son muy importantes en el proceso de diseño ya que facilitan la introducción y aceptación del sistema en donde será implementado. este tipo de normas caen como "restricciones de diseño". * Manejo de requerimientos * De acuerdo con el "Capability Maturity Model" (CMM). Es importante para definir los costos de industrialización del sistema. Este acuerdo son los requerimientos del sistema alojados al software.Este tipo de requerimientos se enfoca a las personas que van usar el sistema. aunque muchas veces no termina en un pedazo de código dentro del sistema. ¿Que manuales se entregarán y en que idioma? Este tipo de requerimientos.

" … "Bajo las restricciones del proyecto. • Los requerimientos técnicos y no técnicos forman un conjunto entre sí. "Para lograr el control de los requerimientos. y no son impuestos por en su totalidad por presiones externas ajenas al proyecto. 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. El acuerdo forma las bases para estimar. o menos calidad o más tiempo estimado de entrega. • Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos. ejecutar y monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida. si cambia uno forzosamente deberán cambiar los demás. 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. El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia. y actividades son ajustadas para quedar en línea con los nuevos requerimientos de software". productos. 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. De modo que los cambios técnicos deberán ser aprobados por el grupo de requerimientos y este grupo estimará los . En otras palabras. para obtener el nivel que requiere el CMM en manejo de requerimientos débenos de tomar en cuenta dos cosas. Esto es: más contenido técnico implica o más costo.técnicos (como fechas de entrega). planear.

Crear un documento de requerimientos generales. 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. 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. Traducir las oportunidades / necesidades en requerimientos del proyecto. 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. además asegura a los usuarios tengan un conocimiento no técnico de lo realizara o no el nuevo sistema. . Durante el diseño.impactos en tiempo. * ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO * Para prosperar en el mercado. calidad. 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. Organizar entrevistas destinadas a obtener la máxima información posible acerca de los requerimientos de los usuarios. a algunos se les pide que revisen los borradores de los informes. Se debe utilizar una metodología detallada de definición de los requerimientos de usuario. no es solamente el proyecto del analista. 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. Comprender el perfil y entorno del usuario. La participación del usuario proporciona al analista una retroalimentación importante conforme avanza en el diseño. El resultado de la estimación es la entrada a los líderes del proyecto para decidir si el cambio se acepta o no. costo. Evaluar el flujo de trabajo.

En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en forma seccionada que la distribuye entre ellos mismos. le indica a los analistas una gran cantidad de datos sobre como sé esta llevando a cabo los objetivos de la compañía. los datos de entrada se procesan. * Estrategia del Flujo de Datos * Cuando se siguen un flujo a través de los procesos de negocio. almacenan. que es el propósito del análisis del flujo de datos. de manera que cada uno pueda trabajar en forma independiente. utiliza. consultan. . Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de información. 2.. 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 la mayor parte de los casos. Al manejar las transacciones y completar las tareas.. es difícil para los analistas entender todos estos componentes aún mismo tiempo.Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información. Se clasifican en dos tipos: 1.Flujo de Datos.* REQUERIMIENTOS DEL SISTEMA * Los Sistemas de Información por computadora normalmente están integrados por muchos componentes. modifica y se emiten.

se maneja de forma diferente a la opción que toma un supervisor de departamento para aceptar o rechazar pedidos. * Estrategia del Análisis de Decisiones * La estrategia del análisis de decisiones es un complemento del análisis del flujo de datos.Seguir el flujo de datos: . de manera que las condiciones y acciones normalmente se conocen como un aspecto importante. Esta estrategia realza el estudio de los objetivos de una operación y de las decisiones que deben realizarse para cumplir con los objetivos. La alternativa que selecciona los gerentes responsables en la toma de decisiones. 3. . La decisión de rechazar pedidos generalmente ocurre con más frecuencia. * Etapas en la Estrategia del Análisis del Flujo de Datos * 1. . la estrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones. en cuanto a una estrategia de precios entre un conjunto de alternativas.Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas. Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial. documenta los hallazgos en los diagramas de flujo de datos. 2.El análisis de flujo de datos que muestra el estudio y el uso de cada actividad. .Estudiar las operaciones y procesos en marcha.

en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son: . Etapas en la Estrategia del Análisis de Decisión 1.Añadir gradualmente detalles a los niveles inferiores. . 4. . -Estudiar los objetivos y decisiones necesarias.Desarrollar un modelo del proceso de decisión. .* Proceso * Almacenamiento * Recuperación * Salida 4. . 3.Identificar los requerimientos del proceso para los datos. 2.Probar el modelo con datos de prueba. * Requerimientos De Entrada * Es el enlace que une al sistema de información con el mundo y sus usuarios.

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 . Existen cinco objetivos que controlan la cantidad de entrada requerida. impresos ó por personas que los escriben directamente al sistema. a enviar los retrasos. • Captura de Datos para la Entrada. 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.• Objetivos del Diseño de Entrada. controlar los errores y mantener la sencillez de los pasos necesarios. Objetivo del Diseño de Entrada Consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos.

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. 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. Evitar los Pasos Adicionales: . 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. 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. Es común encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos.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: . una forma de evitarle es utilizar los documentos de retorno.

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.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. Captura de Datos para la Entrada: En una transacción existen datos importantes y otros que no. el analista debe saber cuáles utilizará y cuales en realidad deben formar la entrada. Existen dos tipos de datos: • Datos variables • Datos de identificación Datos Variables: . Ya sea añadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un día. evitara diseños para la entrada que traigan una mayor cantidad de pasos a seguir.

archivos y bases de datos y procedimientos. los detalles de las transacciones y los datos del proveedor. 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. Datos de Identificación: Estos son los que identifican en forma única el artículo que esta siendo procesado. Las especificaciones de los procedimientos describen . todos de manera que cubran los requerimientos del proyecto. describen sus características: las salidas. transmisión y área para los pasajeros)y como se relacionan unas con otras(donde se conectan entre sí los componentes del sistema. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje. Cuando los analistas formulan un diseño lógico. Los informes y la producción del analista son los componentes de todo el mecanismo que emplea el ingeniero. esto es. 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.Son aquellos que cambian para cada transacción o toman de decisión. escriben las especificaciones detalladas del nuevo sistema. * 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. cuan separadas están las puertas. entradas. o por ejemplo.

en la pantalla de despliegue visual o archivo.métodos para introducir los datos. como lo hizo la determinación de requerimientos. actividad que sigue el diseño lógico. El diseño lógico va de arriba hacia abajo. anterior a los años 70´s. caracterizado por especificaciones tipo novela victoriana que eran difíciles de leer y entender. La cual cabe en tres períodos amplios según Yourdon: 1. En primer lugar se identifican las características generales. . El análisis de sistema convencional. archivos y un sistema en marcha. recopilados durante la investigación. 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. 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. corridas de informes copiados de archivos y detección de problemas. los analistas deben conocer la longitud de campo de un dato específico para establecer cuanto espacio dejar en la información. y casi imposibles de mantener. El diseño físico. conforman las actividades y componentes del sistema. como informes y entradas. los contenidos del sistema pueden cambiar como resultado de un nuevo diseño. Los datos de los requerimientos. procesan los datos. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios. producen los informes y almacenan estos datos en los archivos. en el diseño de la salida por ejemplo. las especificaciones del diseño indican a los programadores que debe hacer el sistema. Los analistas formulan un diseño lógico que apoya los procesos y decisiones. produce programas de software.

2. 3. descripciones de procesos y procedimientos. 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 . reglas. 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. y énfasis en el modelado de las implementaciones actuales de un sistema antes de modelar el nuevo. Aumentando por ende la comunicación entre el analista y el sistema. Obteniendo de está manera mejores resultados que pueda interpretar el analista en forma rápida y precisa. incluyendo a la fase de análisis. diccionarios de datos. Después de relacionarnos brevemente con la terminología básica. Esto se caracterizó por primeras versiones de modelos gráficos. a mediados de los años 80´s. El análisis estructurado clásico. 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. de mediados de los años 70´s. podemos entrar en aspectos relacionados con los cambios del análisis estructurado. en el cual se introducen mejoras sobre todo para modelar sistemas de tiempo real y relaciones de situaciones complejas. El análisis estructurado moderno. Se puede decir adicionalmente que los componentes del análisis estructurado son los siguientes: símbolos gráficos.

modelos esenciales y modelos de implantación. programador. • Limitación para modelar sistemas en tiempo real.interpretativa más rápida y eficiente. 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. diseñador). . aumentando por ende el grado de comunicación entre las especificaciones funcionales y el usuario final (analista. Es por ello que surge una amplia variedad de diagramas que permiten representar las especificaciones funcionales en forma sencilla y rápida. redundancia. ambigüedad e imposibilidad de mantener. división de eventos. Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis estructurado clásico tales como: diagramas de entidad-relación. • El modelo de datos se hacía de una manera primitiva. el analista se volvía cada vez más apuesto y renuente a hacer más cambios. definida entre los modelos lógicos y los modelos físicos. de tal manera que se pudiesen definir los requerimientos del usuario y las especificaciones funcionales del sistema. Entre estos problemas según Yourdon podemos mencionar: • Distinción difusa y poca. Posteriormente. 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. 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. diagramas de transición de estados.

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.• Debido a la cantidad de trabajo requerido. • 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. 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. 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. el analista dejaba a veces de dividir el modelo del sistema en modelos de menor nivel. funciones primitivas. para asegurar que fuesen consistentes y estuviesen completas. 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. 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. y rendimiento al momento que se ponga a correr el sistema. Finalmente. lo cual era bastante tedioso y dejaba por fuera muchos errores que debían de encontrarse. Disminuyendo de esta manera la serie de errores que . quedando por ende. para no perder la secuencia de lo que se está realizando. para así obtener un mejor aprovechamiento. entendimiento. En la actualidad muchas de estas herramientas se están utilizando para facilitar la fase de análisis. Pero para mediados de los 80´s aparecieron las herramientas CASE que trataron de subsanar estos problemas.

Las principales áreas de cambio incluyen lo siguiente según Yourdon: • Cambios de terminología. Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo de los últimos años. si es que ya no se están dando. • La desenfatización del modelado físico actual. • Impacto sobre la industria de software del tercer mundo. y profesionales de la computación en los países del tercer mundo. los niños. sobre todo en los siguientes grupos: los niveles superiores de administración en organizaciones gubernamentales y de negocios.se cometían anteriormente. • Herramientas de modelado en tiempo real. . 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. con la introducción de herramientas más especializadas y fáciles de utilizar. En un futuro no muy lejano se piensa que se darán. • Integración más cercana del modelado de procesos y datos. • Partición de acontecimientos.

diagramas de transición de eventos. reglas. modelos esenciales y modelos de implantación. aunque no todos los analistas tienen acceso a las últimas herramientas de análisis. diagramas de entidad-relación. descripciones de procesos y procedimientos. ya que existía la necesidad de utilizar una notación gráfica para representar los datos y los procesos que los transforman". Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada por computadora). diccionarios de datos. 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. Es por ello que surgen una serie de temas afines tales como: herramientas automatizadas (CASE). elaboración de prototipos. símbolos gráficos. • Impacto de los desastres de mantenimiento. • Integración del análisis estructurado con la inteligencia artificial. * 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. .• Proliferación de las herramientas automatizadas. la cual prevé un buen futuro y muchas mejoras para los sistemas actuales. diagramas de entidad-relación etc. diagramas de estados. Debido a que han estado surgiendo otras técnicas en otras áreas como lo es la orientada a objetos. prototipos. división de eventos.

La entrada puede ser una señal de control transmitida por un transductor. La salida puede encender un sencillo led o producir un informe de 200 páginas. Puede observarse que el modelo puede aplicarse a todo el sistema o solo a un elemento de software. conducen la transformación para producir la información de salida. Una o más entradas. La función global del sistema se representa como una transformación sencilla de la información. un modelo de flujo de datos puede aplicarse a cualquier sistema basado en computadora independientemente del tamaño o complejidad. En efecto. o un método de inferencia basado en regla de un sistema experto. Representadas como flechas con etiqueta.* 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. se modifica mediante una serie de transformaciones. un complejo algoritmo numérico. La clave es representar la información dada y producida por la transformación. representada en la figura como una burbuja. El sistema acepta entrada de distintas formas. aplica un hardware. o un voluminoso archivo de datos almacenado en memoria secundaria. * Diagramas de Flujos de Datos * Conforme con la información se mueve a través del software. y produce una salida en distintas formas. una serie de números escritos por un operador humano. La transformación puede comprender una sencilla comparación lógica. Un diagrama de flujos de datos . un paquete de información transmitido por un enlace a red. software y elementos humanos para transformar la entrada en salida.

conforme se mueven de la entrada a la salida. También se le conoce como un grafo de flujo de datos o un diagrama de burbujas. * Descripciones Funcionales * y datos usados en los procesos . y ha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine. archivos [datos almacenados] [transformaciones]. DeMarco y Gane y Sarson. 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. el diccionario de datos esta compuesto de definiciones de flujo de datos. es una técnica grafica que describe el flujo de información y las transformaciones que se aplican a los datos. Por tanto.(DFD). en una especificación del proceso y en el propio diccionario de datos. Por tanto.. Los datos compuestos (datos que pueden ser además divididos) se definen en términos de sus componentes. El diagrama es similar en la forma a otros diagramas de flujo de actividades. 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. el analista debe disponer de algún otro método para representar el contenido de cada flecha de un DFD. * 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..

de forma que pueden desarrollarse descripciones procedimentales precisas de las funciones representadas dentro de un DFD.junto con frases del lenguaje natural. 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. Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software. el contenido de datos y la estructura de datos. 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). selección y repetición. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta.Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionario de datos). los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. y 4) todos dan una conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa. 3)todos requiere que la estructura de datos se represente usando la secuencia. El inglés estructurado incorpora construcciones procedimentales básicas – secuencia. Como los métodos orientados al flujo de datos. Una de tales notaciones se llama ingles estructurado (también llamado lenguaje de diseño del programa o proceso (LDP)). usando el lenguaje natural o alguna otra notación estilizada. 2)todos suponen que la estructura de la información es jerárquica. * 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 analista describe cada función (transformación) representada. selección y repetición. .

Software Engineering Resources by Roger S. 136-147. McGraw-Hill.".. Un enfoque práctico.. 247.S. Larman. Segunda Edición. C. SENN. pp. McGraw Hill. R. S. pp. P. "Análisis y Diseño de Sistemas de Información". James A.Yourdon (1993) . Roger . Pressman & Associates Edward . Segunda Edición. A.BIBLIOGRAFÍA Senn. "Ingeniería del Software. (1993) . Análisis y Diseño de Sistema de Información. Enero 1990 JAMES A. Mc Graw Hill.Ingeniería del Software.S. 500-511. IEEE Task Force on Requirements Engineering. 217-218. Análisis y Diseño de Sistemas de Información. Abril 2000. Prentice halll . 1992. Graw-Hill. "UML y patrones: Introducción al análisis y diseño orientado a objetos". JAMES A SENN. Mc.Análisis Estructurado Moderno. Mc Graw Hill. Prentice Hall Hispanoamericana. Pressman.