Introduccin

En la actualidad para muchas organizaciones, los sistemas de informacin basados en computadoras son el corazn de las actividades cotidianas y objeto de gran consideracin en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de informacin cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darn a la competencia.

Los Sistemas de Informacin por computadora normalmente estn integrados por muchos componentes. En la mayor parte de los casos, es difcil para los analistas entender todos estos componentes an mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relacin al propsito del sistema sus entradas y salidas de los procesos incluidos.

Requerimientos del sistema

Aspectos a considerar

Antes de iniciar el anlisis para la determinacin de requerimientos se debe considerar que un sistema de informacin se puede definir tcnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar la toma de decisiones y el control en una institucin, ya sea pblica o privada. Los Sistemas de Informacin pueden tambin ayudar a los administradores a analizar problemas, visualizar cuestiones complejas y crear nuevos productos. En el anlisis de los requerimientos se debe considerar todo el entorno de la empresa ya que existen factores que intervienen en los procesos directa o indirectamente

Medio ambiente
Clientes INSTITUCION SISTEMA DE INFORMACION Proveedores

Almacenamiento o Insumo

Procesamiento

Salida o producto

Retroalimentacin

Entidades reglamentadoras

Accionistas

Competidores

La determinacin de los requerimientos es el estudio del sistema actual del negocio a fin de encontrar como trabaja y donde debe mejorase. Los estudios del sistema son el resultado de una evaluacin para conocer cmo funcionan los mtodos actuales o si son necesarios o posibles algunos ajustes; elaborar preguntas en relacin con los sistemas manuales y los computarizados. Dado que los analistas de sistemas no trabajan como gerentes o empleados en los departamentos para usuarios (como mercadotecnia, contabilidad, venta, compra o produccin), no tienen los mismos conocimientos sobre hechos y datos que los gerentes y usuarios de esas reas; por lo tanto un paso inicial en la investigacin es entender la situacin.

La determinacin de los requerimientos de una aplicacin es tan importante para el mtodo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o anlisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

Estrategias para determinar los requerimientos

En

los

grandes proyectos de

sistema

varios

analistas

llevan

cabo

una investigacin 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 informacin. Se clasifican en dos tipos:

1. - Flujo de Datos. 2. - Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de Informacin.

Estrategia del Flujo de Datos Cuando se siguen un flujo a travs de los procesos de negocio, que es el propsito del anlisis del flujo de datos, le indica a los

analistas una gran cantidad de datos sobre como se esta llevando a cabo los objetivos de la compaa. Al manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten. El anlisis 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 Anlisis de Decisiones La estrategia del anlisis de decisiones es un complemento del anlisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operacin 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, las estrategia de anlisis de decisin 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 la opcin que toman un supervisor de departamento para aceptar o rechazar pedidos. La decisin de rechazar pedidos generalmente ocurre con ms frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante.

Etapas en la Estrategia del Anlisis del Flujo de Datos

1. - Estudiar las operaciones y procesos en marcha. 2. Identificar cmo se procesan los datos al manejar transacciones y terminar las tareas. 3. - Seguir el flujo de datos:

* Proceso * Almacenamiento * Recuperacin * Salida

4. Aadir gradualmente detalles a los niveles inferiores. Etapas en la Estrategia del Anlisis de Decisin

1. - Estudiar los objetivos y decisiones necesarias. 2. - Desarrollar un modelo del proceso de decisin. 3. - Probar el modelo con datos de prueba. 4. - Identificar los requerimientos del proceso para los datos.

Requerimientos elementales Requerimientos De Entrada Requerimientos De Salida Requerimientos de almacenamiento

Requerimientos de entrada
Es el enlace que une al sistema de informacin con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son:

Objetivos del Diseo de Entrada. Captura de Datos para la Entrada.

Objetivo del Diseo de Entrada Consiste en el desarrollo de especificaciones y procedimientos para la preparacin de datos, la realizacin de los procesos necesarios para poner los datos de transaccin 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

Captura de Datos para la Entrada:

En una transaccin existen datos importantes y otros que no, el analista debe saber cules utilizar y cuales en realidad deben formar la entrada. Existen dos tipos de datos:

datos variables datos de identificacin

Datos Variables: Son aquellos que cambian para cada transaccin o toman de decisin.

Datos de Identificacin: Estos son los que identifican en forma nica el artculo que est siendo procesado.

Requerimientos De Salida
Niveles de diseo

El diseo de sistema se representa a travs de dos fases: el diseo lgico y el diseo fsico. Cuando los analistas formulan un diseo lgico; escriben las sistema; esto es, describen sus

especificaciones detalladas del nuevo

caractersticas: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto.

El diseo lgico de un sistema de informacin es como el plano de un ingeniero para armar un automvil: muestra las caractersticas principales(motor,

transmisin 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 estn las puertas.

Los informes y la produccin 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 diseo lgico tambin 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 mtodos para introducir los datos, corridas de informes copiados de archivos y deteccin de problemas. El diseo fsico, actividad que y sigue un el diseo en lgico, las

produce programas de software,

archivos

sistema

marcha,

especificaciones del diseo 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.

Utilizacin de los Datos de Requerimientos:

El alcance del diseo de sistemas se gua por el marco de referencia para el nuevo sistema desarrollado durante el anlisis. Los datos de los requerimientos, recopilados durante la investigacin, conforman las actividades y componentes del sistema. Los analistas formulan un diseo lgico que apoya los procesos y

decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseo.

El diseo lgico va de arriba hacia abajo, como lo hizo la determinacin de requerimientos. En primer lugar se identifican las caractersticas generales, como informes y entradas; en el diseo de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato especfico para establecer cuanto espacio dejar en la informacin, en la pantalla de despliegue visual o archivo.

Participacin de los Usuarios:

Los gerentes y usuarios del sistema tambin poseen un papel importante en le diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, 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 participacin del usuario proporciona al analista. Una retroalimentacin importante conforme avanza en el diseo; adems asegura a los usuarios tengan un conocimiento no tcnico de lo realizara o no el nuevo sistema. Esta visin general del diseo de sistemas subraya los aspectos de diseo que se vern ms adelante en el diseo de la salida de sistema.

Prototipo de Sistemas:

Los requerimientos del sistema y las especificaciones de diseo se establecen con claridad y son muy bien entendidas, y los analistas tienen la experiencia para convertir los requerimientos en un sistema eficiente y que trabaje bien. Los prototipos de sistemas pueden desarrollarse para proporcionar la informacin necesaria y producir un sistema adecuado.

Razones para Desarrollar Prototipos de Sistemas:

A pesar de los mejores esfuerzos de los analistas de sistemas, las necesidades de informacin no siempre se establecen correctamente. Esto puede ocurrir por dos razones: Los usuarios pueden saber solo lo que necesitan mejorar el sistema en ciertas reas del negocio, o que deben modificar los procedimientos existentes; por otro lado, conocer que mejor informacin para administrar ciertas actividades.

Mtodos para el Desarrollo de Prototipos:

Los

sistemas

de

prototipo

se

pueden

desarrollar

utilizando

lenguajes

de programacin y mtodos convencionales. El procesamiento y los controles de entrada pueden faltar y la documentacin del sistema normalmente falta en su totalidad. La clave est en las pruebas de las ideas y en proporcionar suposiciones sobre los requerimientos, no tanto en la eficiencia del sistema o en exactitud o perfeccin. En algunos casos cuando el sistema se utiliza en forma muy frecuente en la formulacin de La forma en que se est llevando a cabo el diseo de salida del sistema.

Diseo de la Salida de Sistemas:

A menudo, para los usuarios la caracterstica ms importante de un sistema de informacin es la salida que produce. Si la salida no es de calidad, se pueden convencer de que todo el sistema es tan innecesario que eviten su utilizacin y, por lo tanto, posiblemente ocasionen errores y que el sistema falle.

Diseo Lgico de la Salida:

l termina "salida" se aplica a cualquier informacin producida por un sistema, ya sea impresa, desplegada o verbal. Cuando los analistas disean la salida, seleccionan mtodos para representar la informacin y crean documentos, informes u otros formatos que contienen informacin producida por el sistema. Los mtodos de salida varan a lo largo de los sistemas. Para algunos, como un informe de inventarios de la cantidad de mercanca, el sistema delcomputador, bajo el control del programa, nada mas consulta los datos que se tienen a mano en el almacenamiento, y los ensambla en una forma que sea presentable. Otra salida puede requerir procesamiento sustancial, antes de que este disponible para utilizarlo. Los analistas deben decidir cuando imprimir, desplegar o presentar su salida en forma audible. La salida impresa puede utilizar papel en blanco o formas preimpresas, la salida visual puede utilizar una o mltiples pantallas para desplegar informacin.

Seleccin de los Mtodos de Salida

Los sistemas de informacin ya sean que se desarrollen sobre sistemas pequeos de escritorio o sobre grandes sistemas, utilizan 3 mtodos principales para la salida los cuales se clasifican en:

Impresin Pantalla Despliegue y audio

Requerimientos de almacenamiento
La memoria de la computadora (RAM) es un lugar provisional de almacenamiento para los archivos que usted usa. La mayora de la informacin guardada en la RAM se borra cuando se apaga la computadora. Por lo tanto, su computadora necesita formas permanentes de almacenamiento para guardar y recuperar

programas de software y archivos de datos que desee usar a diario. Los dispositivos de almacenamiento (tambin denominados unidades) fueron

desarrollados para satisfacer esta necesidad. Los siguientes constituyen los tipos ms comunes de dispositivos de almacenamiento: Unidades de:

Disco duro Disquete Compresin ZIP CD DVD

Respaldo

Si la unidad de disco duro se descompone o si los archivos se daan o se sobrescriben accidentalmente, es una buena idea contar con una copia de respaldo de los datos de la unidad de disco duro. Estn disponibles varios programas de respaldo de uso con cintas, disquetes y aun con los medios desmontables. A menudo, la computadora tendr una utilidad de respaldo ya instalada.

Requerimiento de software
FACTORES EN LA CALIDAD DEL SOFTWARE La construccin de software de calidad requiere el cumplimiento de numerosas caractersticas: Eficiencia: La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula. Transportabilidad (portabilidad): La transportabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas fsicos o lgicos.

Verificabilidad: La verificabilidad es facilidad de verificacin de un software; es su capacidad para soportar los procedimientos de validacin y de aceptar juegos de test o ensayo de programas. Integridad La integridad es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso. Fcil de utilizar: Un software es fcil de utilizar si se puede comunicar con l de manera cmoda. Correccin: Capacidad de los productos software de realizar exactamente las tareas definidas por su especificacin. Robustez: Capacidad de los productos software de funcionar incluso en situaciones anormales. Extensibilidad: Facilidad que tienen los productos de adaptarse a cambios en su especificacin. Existen dos principios fundamentales para conseguir esto: diseo simple y descentralizacin. Reutilizacin: Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones. Compatibilidad: Facilidad de los productos para ser combinados con otros.

Determinacin elemental de los requerimientos

Caractersticas de los requerimientos Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad,

caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles 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 difcil de manejar.

 Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Cada requerimiento debe Expresarse de modo adecuado Ser de acceso sencillo Numerarse Acompaarse con pruebas que lo verifiquen Tomarse en cuenta en el diseo Tomarse en cuenta en el cdigo Probarse aislado Probarse junto con otros requerimientos Validarse con las pruebas despus de construir la aplicacin

Definicin de Ingeniera de Requerimientos "Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del

comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software

Los principales beneficios que se obtienen Requerimientos son:

de la Ingeniera de

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de

requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso.

 Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Procesos de la Ingeniera de Requerimientos Requerimientos de Proceso Requerimientos de Usuarios Requerimientos de Anlisis y Negociacin Requerimientos para la Gestin

Requerimientos de Proceso Estos requerimientos existen porque los procesos los usan durante el desarrollo del software. Requerimientos del Usuario Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento tcnico detallado. nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las caractersticas de diseo del sistema. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.

Problemas que se presentan cuando se redacta en lenguaje natural: Falta de claridad Confusin de requerimientos Conjuncin de requerimientos

Pautas sencillas para redactar requerimientos: Inventar un formato estndar y asegurar que todos los requerimientos se adhieren al formato.

 Utilizar el lenguaje en forma consistente. Resaltar el texto para ver las partes claves del requerimiento. Evitar utilizar el lenguaje tcnico de computacin.

Requerimientos para el Anlisis y Negociacin Los requisitos se agrupan en categoras y se organizan en subconjuntos, se analiza cada requisito en relacin con el resto, se examina los requisitos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes/usuario. Para hacer el Anlisis de requisitos se plantean las siguientes cuestiones: 1. Cada requisito es consistente con los objetivos generales del

sistema/producto? 2. Tienen todos los requisitos especificados el nivel adecuado de abstraccin? Algunos requisitos tienen un nivel de detalle tcnico inapropiado en esta etapa? 3. El requisito es necesario o representa una caracterstica aadida que puede no ser esencial a la finalidad del sistema? 4. Cada requisito est delimitado y sin ambigedad? 5. Cada requisito tiene procedencia? Es decir, Existe un origen (general o especfico) conocido para cada requisito? 6. Existen requisitos incompatibles con otros requisitos? 7. Es posible lograr cada requisito en el entorno tcnico donde se integrar el sistema o producto? 8. Se puede probar el requisito una vez implementado?

Proceso de Negociacin Los clientes debern clasificar sus requisitos y discutir los posibles conflictos segn su prioridad. Los riesgos asociados con cada requisito sern identificados y analizados.

 Se efectan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irn eliminando requisitos, se irn combinando y/o modificando para conseguir satisfacer los objetivos planteados.

Requerimientos para la Gestin Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Como en la Gestin de Configuracin del Software (GCS), la gestin de requisitos comienza con la actividad de identificacin. A cada requisito se le asigna un nico identificador, que puede tomar la forma: <tipo de requisito><requisito no.>

Identificadores, segn el tipo de requisito: F D C I S Funcional Datos Comportamiento Interfaz Salida

Matrices que se deben realizar para la Gestin de Requisitos: Matriz de seguimiento de caractersticas: muestra los requisitos identificados en relacin a las caractersticas definidas por el cliente del sistema/producto. Matriz de seguimiento de orgenes: identifica el origen de cada requisito. Matriz de seguimiento de dependencias: indica cmo se relacionan los requisitos entre s.

 Matriz de seguimiento de subsistema: vincula los requisitos a los subsistemas que lo manejan. Matriz de seguimiento de interfaces: muestra cmo los requisitos estn vinculados a las interfaces externas o internas del sistema. Matriz de seguimiento de caractersticas: muestra los requisitos identificados en relacin a las caractersticas definidas por el cliente del sistema/producto. Ejemplo: El problema de Afecta a Cuyo impacto ocasiona Una solucin exitosa debera

Matriz de seguimiento de orgenes: identifica el origen de cada requisito. Ejemplo: Requerimiento Tipo Usuario Origen

Matriz de seguimiento de interfaces: muestra cmo los requisitos estn vinculados a las interfaces externas o internas del sistema. Ejemplo: Requerimiento Interfaz Tipo Usuario Mdulo

ANEXOS

1. PREGUNTAS CLSICAS PARA UNA DETERMINACIN DE REQUERIMIENTOS Cuntos empleados laboran para la organizacin en el rea(s) que se pretende desarrollar el sistema; o sea, cuntos tienen relacin directa con el proyecto que se est investigando. ? Cules son las personas claves en el sistema? Por qu son importantes? Existen obstculos o influencias de tipo poltico que afectan la eficiencia del sistema? Existen manuales de procedimientos, polticas o lineamientos de desempeo documentados oficial o no oficialmente? Si los hay, Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, se respetan dichos procedimientos? Existen mtodos para evadir el sistema?, Por qu se presentan? Qu reas necesitan un control especfico? Qu criterios se emplean para medir y evaluar el desempeo? Por otra parte: Existen actividades que considere podran mejorarse?, De qu manera? Tiene alguna idea de actividades que podran implementarse para mejorar el rendimiento del sistema en general? Determinacin de procesos: Cules son las principales actividades que se realizan en la organizacin y que tienen relacin con el proceso que se est modelando? Descripcin de cada proceso identificado Qu es lo que da inicio a la actividad? Cul es el objetivo de la misma? Cunto tiempo se tarda en realizarla? Qu retrasos ocurren o pueden ocurrir? Qu mtodos se emplean para medir y evaluar el desempeo de esta actividad? Se toman precauciones especficas de seguridad para la proteccin contra

alguna actividad impropia que se pudiera presentar? Qu tan frecuente es el ciclo con el que se desarrolla dicha actividad? De acuerdo al ciclo con el que se presenta la actividad Cul es el volumen de informacin que aqu se procesa? Qu pasos, sub-procesos, o funciones constituyen la actividad? (describir la actividad paso a paso) Existe algn tipo de control desarrollado en el proceso en cuestin? Determinacin de datos (flujos y contenido de los flujos) - hacer la pregunta por cada proceso o actividad identificada De dnde proviene la informacin que se utiliza en esta actividad? (fuentes) Cules son especficamente los datos que recibe esta actividad? (dts de flujos) De qu manera ingresan a este proceso? (flujos) Qu tablas de referencia y diagramas u otros datos intervienen en la actividad? (documentacin involucrada) Qu informacin se genera en esta actividad? (producto de la actividad) El resultado identificado anteriormente producto de los datos que se procesan Hacia qu o quin van dirigidos? -persona o entidad- (destinos) Con qu finalidad la utilizan? Cules datos se conservan o almacenan en este proceso? Y en qu forma quedan almacenados? Existe informacin que se genera pero que no es utilizada nunca por nadie? (partes extraas) Para cada dato identificado: Qu formato posee cada dato que interviene en esta actividad? Para qu es usado? Se interpone algn tipo de seguridad para la verificacin de la veracidad del dato en mencin? Qu tan importante es dicho dato? Por cunto tiempo es importante mantener el dato en el sistema? Por otra parte si el sistema que se est investigando es para el soporte de decisiones se deben, adems de las anteriores, formular otras preguntas para

determinar los requerimientos de las decisiones, un esbozo de las mismas bien podra ser: Qu informacin se usa para tomar la decisin? Cul es la fuente de esa informacin? Qu sistemas transnacionales producen los datos utilizados en el proceso de decisin? Qu otros datos son necesarios y no es posible obtener del procesamiento de transacciones? Qu datos se originan en fuentes externas a la organizacin? Cmo se deben procesar los datos para producir la informacin necesaria? Cmo debe presentarse la informacin. Una vez que se tenga recopilado el conjunto de hechos que se generan con relacin al sistema que que se est analizando, es posible dar una especificacin de requerimientos; despus se puede dar un conjunto de requerimientos que nos servirn para modelar el sistema a travs de un DFD y luego el diagrama E-R.

2.

EL DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE

ste es la declaracin oficial de qu es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificacin detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una nica descripcin. En otros, los del usuario se definen en una introduccin de la especificacin de los del sistema. Si existe un gran numero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organizacin, quienes pagan por el sistema, hasta los ingenieros responsables del software. Una gran variedad de organizaciones han definido estndares para los documentos de requerimientos. El IEEE sugiere la siguiente estructura para los documentos de requerimientos. 1. Introduccin propsito del documento de requerimientos Alcance del producto

 Definiciones, acrnimos y abreviaturas Referencias Resumen del resto del documento 2. Descripcin general Perspectiva del producto Funciones del producto caractersticas del usuario Restricciones generales Suposiciones y dependencias 3. Requerimientos especficos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, sta es la parte ms sustancial del documento, pero debido a la amplia variabilidad en la prctica organizacional, no es apropiado definir una estructura estndar para esta seccin. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeo del sistema, especificar los requerimientos lgicos de la base de datos, las restricciones de diseo, las propiedades emergentes del sistema y las caractersticas de calidad. 4. Apndices 5. ndice Aunque el estndar IEEE no es ideal, contiene una buena ayuda de cmo tratar los requerimientos y evitar problemas. Es muy general para que pueda ser estndar de una organizacin. Sin embargo, se puede transformar y adaptar para definir un estndar que se ajuste a las necesidades de una organizacin en particular. Por supuesto, la informacin que se incluya en un documento de requerimientos debe depender del tipo de software a desarrollar y del enfoque de desarrollo que se utilice.