Ing. Rodrigo Cabrera Msc.

Objetivos: Conocer como se empieza un proyecto Analizar los elementos de la investigacin preliminar Describir las pruebas de viabilidad de un proyecto

CONTENIDO Cmo empieza un proyecto Las aplicaciones de sistemas de informacin tienen su origen en casi todas las reas de una empresa y estn relacionados con todos los problemas de la organizacin.

Razones para proponer proyectos Las solicitudes de informacin estn motivadas por uno de los siguientes tres objetivos: Resolver un problema Actividades, procesos o funciones que en la actualidad, o quiz en el futuro, no satisfacen los estndares de desempeo o las expectativas, por lo tanto es necesario emprender una accin que resuelva las dificultades. Ejemplo: Disminuir el nmero excesivo de errores en los datos de entrada eliminando la introduccin manual de los detalles de las ventas. Aprovechar una oportunidad Un cambio para ampliar o mejorar el rendimiento econmico de la empresa y su competitividad. Ejemplo: Captura de una base grande de clientes ofreciendo un nuevo programa que con mayor nmero de vuelos directos y descuentos en el precio del pasaje de un avin. Dar respuesta a directivos Proporcionar informacin en respuesta a rdenes, solicitudes o mandatos originados por una autoridad legislativa o administrativa. Ejemplo: Notificar anualmente a quien corresponda, utilizando para ello los formatos adecuados, los intereses obtenidos por cuentas de ahorros.

Ing. Rodrigo Cabrera Msc.

Razones para iniciar proyectos de sistemas de informacin RAZONES Capacidad Mayor velocidad procesamiento EXPLICACIN

de Uso de la capacidad inherente de la computadora para efectuar clculos, ordenar, recuperar datos e informacin y efectuar repetidamente la misma tarea con mayor velocidad que los seres humanos Incremento en el Proporcionar la capacidad de procesar una cantidad mayor de volumen actividades, tal vez para aprovechar nuevas oportunidades de tipo comercial, frecuentemente como resultado del crecimiento de la empresa que excede las capacidades y procedimientos que fueron claves para alcanzar los logros obtenidos. Recuperacin ms Localizacin y recuperacin de informacin del sitio donde se rpido de la informacin encuentra almacenada. Llevar a cabo bsquedas complejas.

RAZONES EXPLICACIN Control Mayor exactitud y Llevar a cabo los pasos de cmputo, incluido los matemticos, de mejora en la manera correcta y siempre en la misma forma. consistencia de datos Salvaguardar datos importantes y sensibles en una forma que sea accesible solo al personal autorizado.

RAZONES Comunicacin Mejoras en comunicacin

EXPLICACIN

la Acelerar el flujo de informacin y mensajes entre localidades remotas as como dentro de oficinas. Se incluye la transmisin de documentos dentro de las oficinas. Integracin de reas de Coordinar las actividades de la empresa que se llevan a cabo en la empresa diferentes reas de una organizacin a travs de la captura y distribucin de informacin

RAZONES Costos Monitoreo de los costos

EXPLICACIN Seguimiento de los costos de mano de obra, bienes e instalaciones para determinar su evolucin en relacin con lo esperado. Uso de la capacidad de cmputo para procesar datos con un costo menor del que es posible con otros mtodos al mismo tiempo que se mantiene la exactitud y los niveles de desempeo.

Reduccin de costos

Ing. Rodrigo Cabrera Msc.

RAZONES Ventaja Competitiva Atraer Clientes

EXPLICACIN

Modificar los servicios proporcionados y la relacin con los clientes de forma tal que ellos no opten por cambiar de proveedor. Dejar fuera a la Disminuir las posibilidades de que los competidores tengan competencia acceso al mismo mercado como consecuencia de la forma tal que ellos no opten por cambiar de proveedor Mejores acuerdos con Cambios en precios, servicios, condiciones de entrega o los proveedores relaciones entre los proveedores y la organizacin para beneficio de la empresa. Desarrollo de nuevos Introduccin de nuevos productos con caractersticas que utilizan productos o son influenciadas por la tecnologa de la informacin.

Fuentes de solicitudes de proyectos Existen cuatro fuentes primarias de solicitudes de proyectos. Los solicitantes dentro de la organizacin son los jefes de departamentos, los altos ejecutivos y los analistas de sistemas. Por otra parte, es probable que las dependencias del gobierno externas a la organizacin tambin soliciten proyectos de sistemas de informacin. De acuerdo con el origen de la solicitud y el motivo para hacerla, las solicitudes buscan ya sea aplicaciones totalmente nuevas o algunos cambios en las ya existentes. MANEJO DEL PROCESO DE SELECCIN La decisin de aceptar o rechazar una solicitud de desarrollar sistemas de informacin puede tomarse de muchas formas diferentes y por distintos miembros de la organizacin. Los analistas de sistemas no son los rbitros finales. Uno de los mtodos ms comunes para revisar y seleccionar proyectos para su desarrollo es por medio de un comit, enmarcado bajo las siguientes denominaciones: Comit Directivo Formado por gerentes importantes de varios departamentos de la organizacin as como por miembros del grupo de sistemas de informacin. Este comit no est dominado por los especialistas en sistemas. Comit de sistemas de informacin Formado por gerentes y analistas del departamento de sistemas de informacin. En este caso todas las solicitudes para servicio y desarrollo se presentan directamente, para su revisin, al comit del departamento de sistemas de informacin. Este comit aprueba o rechaza proyectos o fija prioridades y tambin indican que proyectos son ms importantes, dndoles atencin inmediata.

Ing. Rodrigo Cabrera Msc. Comit de grupos de usuarios Los departamentos o divisiones que contratan sus propios analistas y diseadores, son los que manejan la seleccin de proyectos y se encargan de desarrollarlos. De hecho los departamentos forman sus propios comits de seleccin que tiene el control sobre qu se desarrolla y cuando se implanta. SOLICITUD DE PROYECTO La propuesta de proyecto presentada por los usuarios o analistas ante el comit de seleccin de proyectos es un elemento crtico para emprender el estudio de sistemas. A pesar de que el formato de dicha solicitud cambia de una empresa a otra, existe un acuerdo general sobre la clase de informacin que se debe entender : Cul es el problema Detalles del problema Importancia del Problema Cul cree el usuario que es la solucin En qu forma ser de ayuda un sistema de informacin Qu otras personas tienen conocimiento de este problema y se puede contactar

INVESTIGACIN PRELIMINAR Cuando se va a desarrollar un sistema ya sea por el mtodo de ciclo de vida de desarrollo de sistemas, por la estrategia de desarrollo de prototipos, por anlisis estructurados o por combinacin de estos mtodos, primero es necesario revisar la solicitud del proyecto. La eleccin de una estrategia de desarrollo es un aspecto secundario; lo importante es determinar si la solicitud merece o no la inversin de recursos en un proyecto de sistemas de informacin. Es aconsejable identificar aquellas propuestas de entre todas las que se presenten al comit de seleccin, que traern los mayores beneficios para la organizacin. Realizando lo anterior, los analistas de sistemas llevan a cabo una investigacin preliminar bajo la direccin del comit de seleccin. mbito de estudio La finalidad de la investigacin preliminar es evaluar las solicitudes de proyectos. No es un estudio de diseo ni tampoco incluye la recoleccin de detalles para describir el sistema de la empresa, Ms bien, es la reunin de informacin que permite a los miembros del comit evaluar los mritos de la solicitud de proyecto y emitir un juicio, con conocimiento de causa, con respecto a la viabilidad del proyecto propuesto.

Ing. Rodrigo Cabrera Msc. Objetivos de la investigacin preliminar 1. Aclarar y Qu es lo que se est haciendo? comprender la Qu es lo que se requiere? solicitud del Existe alguna razn diferente a la identificada por el proyecto solicitante? Ejemplo: El usuario justifica una solicitud para el desarrollo de un sistema que sirva para la recepcin de cuentas con base en el deseo de una mayor rapidez de procesamiento. Sin embargo, la investigacin preliminar revela que la necesidad de un mejor control sobre el manejo de efectivo es mayor que la necesidad de rapidez. El problema real lo constituyen los cheques perdidos y no la velocidad de procesamiento, pero el solicitante no ha descrito con claridad este necesidad especifica. Ejemplo: La solicitud de un proyecto para la inscripcin a cursos en realidad pide un nuevo desarrollo o la modificacin del sistema existente? La investigacin para contestar esta pregunta tambin rene detalles tiles para estimar la cantidad de tiempo y nmero de personas necesarias para desarrollar el proyecto. Dado que el costo de muchas mejoras a los sistemas existentes es alto, reciben por parte del comit de seleccin de proyectos la misma consideracin que las solicitudes de nuevos proyectos. Ejemplo: Cules son los costos estimados para el desarrollo del sistema de informacin de pacientes, tal como es solicitado por el jefe del equipo mdico del hospital? Que gastos se necesitan hacer para entrenar al personal mdico y de enfermera as como para implantar el sistema? El sistema propuesto disminuir los costos de operacin? Es probable que disminuya el costo asociado con los errores. Ejemplo: Existe o se puede adquirir la tecnologa necesaria para enlazar los sistemas de procesamiento de palabras de las oficinas con la computadora central? Qu tan prctica resulta la solicitud para permitir que los asistentes administrativos recuperen del sistema central informacin relacionada con las ventas, y la incluyan directamente en los informes escritos preparados por un procesador de textos? Ejemplo: Se debe modificar una propuesta para la instalacin de un sistema de recepcin de pedidos para permitir que todos los vendedores hagan sus pedidos directamente a la computadora o a travs de lneas telefnicas ordinarias. La modificacin mejorara la utilidad del sistema e incrementara los beneficios financieros para la organizacin.

2. Determinar tamao proyecto

el del

3. Evaluar los costos y beneficios de diversas opciones

4. Determinar la viabilidad tcnica y operacional de las diferentes alternativas

5. Reportar los hallazgos a la administracin y formular recomendaciones que esbocen la aceptacin o rechazo de la propuesta

Ing. Rodrigo Cabrera Msc. Mtodos para recogida de datos Los datos recogidos durante las investigaciones preliminares se renen por medio, principalmente de dos mtodos: revisin de documentos y entrevistas a personal seleccionado de la empresa. Revisin de los documentos de la organizacin El primer objetivo que los analistas abordan al conducir la investigacin es aprender acerca de la organizacin que est involucrada en, o que se ver afectada por, el proyecto. Por ejemplo, revisar la propuesta del sistema de inventario significa conocer primero como opera el departamento de inventarios y quines son los gerentes y supervisores. Los analistas aprenden estos detalles por medio del examen del organigrama y el estudio de los documentos que describen los procedimientos de operaciones. Estos ltimos indican cmo debe operar el proceso de inventario e identifican los pasos ms importantes relacionados con la recepcin, manejo y distribucin de los artculos del almacn. Conduccin de entrevistas Los documentos sealan al analista como deberan operar los sistemas pero no incluyen suficientes detalles para tomar una decisin con respecto al merito de la propuesta, y tampoco presentan el punto de vista de los usuarios. Para conocer estos detalles, los analistas hacen uso de la entrevista. Las entrevistas son el mtodo por el que los analistas conocen ms sobre la naturaleza de la solicitud del proyecto y la razn de someterlo a consideracin. Para alcanzar el propsito de las entrevistas, el analista debe asegurarse de recalcar la solicitud y el problema que esta aborda. En otras palabras, las entrevistas deben proporcionar detalles que ms adelante expliquen el proyecto y demuestren si la informacin proporcionada tiene mritos econmicos, operacionales y tcnicos. Es usual considerar en la investigacin preliminar entrevistas solo con los gerentes y el personal de supervisin. ANLISIS DE VIABILIDAD DEL PROYECTO Las investigaciones preliminares examinan la viabilidad del proyecto, la posibilidad de que el sistema sea de utilidad para la organizacin. Se estudian tres pruebas de viabilidad, que son: operacional, tcnica y financiera. Viabilidad operacional Los proyectos nicamente tienen beneficio cuando logran ingresar al grupo de sistemas de informacin que satisfacen los requerimientos de la organizacin. En otras palabras, esta prueba de viabilidad formula la siguiente pregunta: trabajar el sistema cuando est terminado e instalado? Existen barreras importantes para la implantacin?

Ing. Rodrigo Cabrera Msc.

Existe apoyo suficiente para el proyecto por parte de la administracin, y por parte de los usuarios? Si el sistema es bien visto y utilizado por muchas personas que no ven ninguna razn para efectuar cambios, entonces es probable encontrar resistencia al cambio. Los mtodos que actualmente se emplean en la empresa son aceptados por los usuarios? Si no es as, entonces los usuarios darn la bienvenida a cualquier cambio que permita tener un sistema ms til y operacional. Los usuarios han participado en la planeacin y desarrollo del proyecto? La participacin temprana disminuye, en general, los riesgos del rechazo hacia el sistema y el cambio, de igual manera aumenta las posibilidades de xito de los proyectos. El sistema propuesto causara perjuicios? Producir resultados pobres en algn aspecto o rea?Se perder el control en alguna rea? Se perder la factibilidad de acceso a la informacin? La productividad de los empleados ser menor despus de la implementacin? Los clientes se vern afectados en forma poco favorable?El sistema reducir la productividad de otras reas? Viabilidad Tcnica Entre los aspectos tcnicos que son comunes que aparezcan durante la etapa de viabilidad de la investigacin, se incluyen los siguientes: 1. Existe o se puede adquirir la tecnologa necesaria para poder realizar lo que se pide? 2. El equipo propuesto tiene la capacidad tcnica para soportar todos los datos requeridos para usar el nuevo sistema ? 3. El sistema propuesto ofrecer respuestas adecuadas a las peticiones sin importar el nmero y ubicacin de los usuarios ? 4. Si se desarrolla el sistema Puede crecer con facilidad? 5. Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos? Viabilidad Financiera Las cuestiones econmicas y financieras formuladas por los analistas durante la investigacin preliminar, tienen el propsito de estimar lo siguiente: 1. 2. 3. 4. El costo de llevar a cabo la investigacin completa del sistema El costo del hardware y software para la aplicacin que se est considerando Beneficios en la forma de reduccin de costos o de menos errores costosos El costo si nada sucede (es decir si el proyecto no se lleva a cabo)

SELECCIN DE ALTERNATIVAS Cada vez con mayor insistencia las organizaciones animan a los usuarios para que desarrollen sus propios sistemas, utilizando para ello las poderosas herramientas de software disponibles en la actualidad. Para ciertos tipos de aplicaciones, esta estrategia resulta productiva y tiene 7

Ing. Rodrigo Cabrera Msc. bastante xito. Sin embargo, no es una panacea. Los comits de seleccin de proyectos deben tener una poltica que determine que aplicaciones son adecuadas para su desarrollo por parte de los usuarios y cules no. A menudo las organizaciones clasifican las aplicaciones en dos categoras: proyectos institucionales y proyectos de los usuarios finales. Para ello hacen uso de las siguientes distinciones: Aplicaciones institucionales Afectan las actividades de los consejos corporativos, de varios departamentos o de procesos bsicos de los que depende la organizacin; proporcionan datos o facilidades para cambiar datos almacenados en las bases de datos corporativas o archivos compartidos. Ejemplo: Recepcin de pedidos, manejo de inventarios, personal y pago de nmina, contabilidad, correo electrnico. Aplicaciones de los usuarios finales mbito limitado, producen con frecuencia informacin que permanece dentro del departamento o unidad de trabajo que la genera. Est orientada ms hacia la emisin de reportes y salidas que a procesamiento controlado por entradas. Utilizan lenguaje de cuarta generacin, paquetes de software para computadores personales o sistemas compartidos, que ya estn escritos y que se especializan en la recuperacin y presentacin de la informacin. Ejemplos: archivo histrico de ventas, cotizacin de precios y propuestas de proyectos, calendario de mantenimiento de equipos. TALLER 1. Elaborar un mapa conceptual sobre las razones para proponer proyectos 2. Elaborar un cuadro sinptico sobre las cinco razones para iniciar proyectos de sistemas de informacin. 3. Enumerar las fuentes de solicitudes de proyectos 4. Enumerar las instancias que manejan el proceso de seleccin y revisin de proyectos 5. Elaborar un mapa conceptual sobre los objetivos de la investigacin preliminar 6. Elaborar un mapa conceptual sobre la viabilidad operacional de un proyecto 7. Elaborar un mapa conceptual sobre la viabilidad tcnica de un proyecto 8. Cul es la diferencia entre las aplicaciones institucionales y las desarrolladas por los usuarios finales 9. Consultar en Internet sobre las aplicaciones desarrolladas por los usuarios finales Vocabulario Tcnico Estudio de viabilidad Es virtualmente un diseo preliminar del sistema, pero no proporciona bastante informacin de detalle para la divisin final del mismo en subsistemas.

Ing. Rodrigo Cabrera Msc. Anlisis Es el proceso mediante el cual se definen los problemas existentes en la unidad bajo estudio, con el fin de proponer alternativas de solucin. Dato Son hechos o material original de informacin; es decir son los elementos usados como base de decisin, clculo o medida en un proceso. Mtodo de desarrollo por anlisis estructurado Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. Este mtodo tiene como finalidad superar esta dificultad por medio de la divisin del sistema en componentes y la construccin de un modelo del sistema. Mtodo del prototipo de sistemas El prototipo es un sistema que funciona, no es solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema.

ANLISIS DE REQUISITOS Consiste en producir un documento de especificaciones de requisitos que describa lo que el futuro sistema debe hacer, pero no como debe hacerlo por lo cual tambin se denominan determinacin de requisitos. Es el estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema, de hardware o de software as como su estudio y refinamiento. Requisito Es una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo. Aplicado a los sistemas es lo que debe cumplir o poseer un sistema para satisfacer un contrato. Una norma o una especificacin. La definicin de los requisitos debe ser fruto del trabajo de usuarios y desarrolladores del software, a travs del anlisis, esto es as por las siguientes razones: El cliente no suele entender el proceso de diseo y desarrollo del software, como para redactar una especificacin de requerimientos de software (En adelante ERS). Los analistas no suelen entender completamente el problema del cliente

Ing. Rodrigo Cabrera Msc. LA FASE DE ANLISIS DE REQUISITOS Consta de lo siguiente: Definir los requisitos de software es una tarea iterativa para crear una especificacin preliminar de requisitos, a partir de la informacin obtenida segn las tcnicas de recogida de informacin. Definir los requisitos de interfaces del software con el resto del sistema y el exterior como los usuarios, el hardware, otras aplicaciones. La interfaz con el usuario es crtica para la facilidad de uso. Integrar los requisitos en un documento de especificacin y asignarles prioridades. El usuario tiene papel fundamental en la aprobacin o no de los mismos. As mismo se asigna prioridades en funcin de su importancia.

Otra manera de describir las actividades que se realiza en la fase de anlisis de requisitos es: 1. Extraccin o determinacin de requisitos con lo que los clientes descubren, revelan, comprenden los requisitos que desean. 2. Anlisis de requisitos que consiste en el proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, resolviendo posibles inconsistencias. 3. Especificacin de requisitos que consiste en el proceso de registro de los requisitos, para lo que se puede recurrir al lenguaje natural, grficos, etc. 4. Validacin de los requisitos: los usuarios confirman que los requisitos especificados son vlidos, consistentes, completos. ESPECIFICACIN DE REQUISITOS DE SOFTWARE Para comprender que es una ERS, es necesario definir los siguientes trminos: Especificacin El anlisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema de hardware o de software as como su estudio y refinamiento. Software Es una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo. Aplicado a los sistemas es lo que debe cumplir o poseer un sistema para satisfacer un contrato una norma o una especificacin. La ERS se puede definir como documentacin de los requisitos esenciales del software y de sus interfaces externas. Las dos caractersticas fundamentales de una ERS son: 1. Debe incluir informacin veraz, coherente con las necesidades reales del usuario. 2. Debe comunicar dicha informacin de forma eficaz, es decir de forma que se pueda comprender 10

Ing. Rodrigo Cabrera Msc. El ERS describe lo que hay que desarrollar, no el cmo, el cundo, etc. esto implica:

1. Describir correctamente todos los requisitos del software, sin incluir requisitos innecesarios. 2. No describir ningn detalle del diseo del software, de su verificacin o de la direccin del proyecto.

CARACTERISTICAS DE UNA ERS 1. 2. 3. 4. 5. 6. 7. No ambigua Completa Fcil de verificar Consistente Fcil de modificar Facilidad para modificar el origen y las consecuencias de cada requisito Facilidad de utilizacin durante la fase de explotacin y mantenimiento

No ambigua.- En caso que un trmino es usado en distinto contexto debe incluirse en un glosario, donde se determina la forma exacta de su significado. Completa.-Una ERS est completa si: Incluye todos los requisitos significativos del software Define la respuesta del software, a todas las posibles clases de datos de entrada Est conforme con cualquier estndar de especificacin que se deba cumplir. Estn etiquetados y referenciados en el texto todas las figuras, tablas y diagramas. Tambin deben estar definidos todos los trminos y unidades de medida. Fcil de verificar.- Una ERS es fcil de verificar si y solo si cualquier requisito al que se haga referencia se puede verificar fcilmente. Consistente.-Una ERS es consistente si y solo si ningn conjunto de requisitos descritos en ella son contradictorios o entran en conflicto, se pueden presentar tres tipos de conflicto: 1. Dos o ms requisitos pueden describir el mismo objeto real pero usan distintos trminos. 2. Las caractersticas especificadas de objetos reales pueden estar en conflicto. 3. Puede haber un conflicto lgico o temporal entre dos acciones determinadas.

11

Ing. Rodrigo Cabrera Msc. Fcil de Modificar.-Una ERS es fcilmente si su estructura y estilo permiten que cualquier cambio en los requisitos se pueden hacer de una manera fcil, completa y consistente. La especificacin de requisitos de software debe tener una organizacin coherente y manejable, con una tabla de contenidos, un ndice y referencias cruzadas. No ser redundantes; o sea, que el mismo requisito no aparezca en ms de un lugar de la ERS. Facilidad para identificar el origen y las consecuencias de cada requisito Se dice que una ERS Facilita las referencias con otros productos del ciclo de vida si establece un origen claro para cada uno de los requisitos y si posibilita las referencias de estos requisitos en desarrollos futuros. Se recomienda dos tipos de referencias: 1. Referencias hacia atrs. Los requisitos referencian explcitamente sus fuentes en documentos previos. 2. Referencia hacia adelante. Depende de que cada requisito de la ERS tenga un nombre o numero de referencia nico, que sirva para identificarlo en futuros documentos. Cuando un requisito de la ERS representa una derivacin de otro requisito, se debe facilitar la referencia hacia atrs como hacia adelante. Facilidad de utilizacin durante la fase de explotacin y mantenimiento La ERS debe tener en cuenta la necesidad de mantenimiento, debido a que: 1. El personal que no ha estado relacionado con el desarrollo del software, se encarga del mantenimiento. Cuando las modificaciones son profundas se debe actualizar la documentacin del diseo y requisitos, en este ltimo caso: La ERS debe ser fcil de modificar La ERS deber proveer un registro de las caractersticas especiales de cada componente tales como: su criticidad, su relacin con necesidades temporales y su origen. 2. Gran parte de los conocimientos y de la informacin para el mantenimiento se dan por supuestos en la organizacin del desarrollo, pero suelen estar ausentes en la organizacin del mantenimiento. EVOLUCIN DE LA ERS La ERS necesitara ser cambiada a medida que progrese el producto de software. Dos consideraciones a tener en cuenta en este proceso son: 1. El requisito debe ser especificado de la forma ms completa posible 2. Debe iniciarse un proceso formal para identificar, controlar e informar de cambios proyectados tan pronto como sean identificados. De forma que permita: a. Suministrar una revisin precisa y completa del rastro de las modificaciones. b. Permitir exmenes de fragmentos actuales y reemplazados de la ERS.

12

Ing. Rodrigo Cabrera Msc. ESTRUCTURA PARA LA ERS Se presenta una sugerencia de estructura de la ERS. Cualquier ERS que est bien escrita debera incluir toda la informacin que se expone a continuacin: 1. Introduccin 1.1 Objetivos 1.2 mbito 1.3 Definicin. Siglas abreviaturas 1.4 Referencias 1.5 Visin Global 2. Descripcin General 2.1 Perspectiva del proceso 2.2 Funciones del proceso 2.3 Caractersticas del usuario 2.4 Limitaciones Generales 2.5 Supuestos y dependencias 3. Requisitos especficos 3.1 Requisitos Funcionales 3.1.1 Requisito funcional I 3.1.1.1 Introduccin 3.1.1.2 Entradas 3.1.1.3 Procesamiento 3.1.1.4 Salidas 3.1.2 Requisito funcional 2 3.1.3 Requisito funcional n. 3.2 Requisitos de interfaz externa 3.2.1 Interface de usuario 3.2.2 Interfaces hardware 3.2.3 Interface software 3.2.4 Interfaces de comunicaciones 3.3 Requisitos de Ejecucin 3.4 Restricciones de Diseo 3.4.1 Acatamiento de estndares 3.4.2 Limitaciones de hardware 3.5 Atributos de calidad 3.5.1 Seguridad 3.5.2 Mantenimiento 3.6 Otros requisitos 3.6.1 Base de datos 3.6.2 Operaciones 3.6.3 Adaptacin de situacin Apndices ndice

13