Unidad 1

Procesos de la 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. Qu son los requerimientos? En la definicin que aparece del glosario de la IEEE dice, es: 1. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. Los requerimientos pueden dividirse en 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 las caractersticas 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, estndares, etctera.

Caractersticas de los requerimientos: Las caractersticas de un requerimiento son sus propiedades principales. A continuacin se presentan las ms importantes. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones en el 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. 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. 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 el futuro. 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 remplazados por otras capacidades del producto o del proceso. Importancia de la ingeniera de requerimientos Los principales beneficios que se obtienen de la ingeniera de requerimientos son: 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.

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.
2

1.1 Requerimientos de Proceso La ingeniera de requerimientos, proporciona un mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin, y administrar los requisitos conforme stos se transformen en un sistema operacional. Los requerimientos de proceso se llevan a cabo a travs de siete distintas funciones: inicio, obtencin, elaboracin, negociacin,

especificacin, validacin y gestin.

1.1.1 Inicio

Cmo se inicia un proyecto de software? Es un evento aislado que se convierte en el catalizador para un nuevo sistema o producto basado en computadora? O la necesidad evoluciona con el tiempo? No existen respuestas definitivas para estas preguntas.

En algunos casos, una conversacin informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniera de software. Pero en general, la mayora de los proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Los participantes de la comunidad de negocios (es decir, los gerentes, gente de mercadotecnia, gerentes de producto) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un anlisis preliminar de factibilidad, e identifican una descripcin funcional del mbito del proyecto. Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto. El objetivo es establecer una comprensin bsica del problema, las personas que quieren una solucin, la naturaleza de la solucin que se desea, y la efectividad de la comunicacin preliminar entre el cliente y el desarrollador.
3

1.1.2 Obtencin En verdad parece muy simple preguntarle al cliente, a los usuarios, y otros interesados cules son los objetivos para el sistema o el producto, qu es lo que se debe lograr, de qu forma el producto satisface las necesidades del negocio y por ltimo cmo se utilizar el sistema o producto da a da. Pero no es simple, es muy difcil. Hay una serie de problemas que ayudan a entender por qu es difcil la obtencin de requisitos: Problemas de mbito. El lmite del sistema est mal definido o los clientes/usuarios especifican detalles tcnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema. Problemas de comprensin. Los clientes/usuarios no estn seguros por completo de qu es lo que se necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de cmputo, no comprenden del todo el dominio del problema, tienen dificultades al comunicar necesidades al ingeniero de sistemas, omiten informacin que consideran obvia, especifican requisitos que chocan con las necesidades de otros clientes/usuarios, especifican requisitos ambiguos o inestables. Problemas de volatilidad. Los problemas cambian conforme transcurre el tiempo.

Para ayudar a superar estos problemas, los ingenieros de requerimientos deben realizar en forma organizada la actividad de recopilacin de requisitos.

1.1.3 Elaboracin La informacin conseguida con el cliente durante el inicio y obtencin se expande y se refina durante la elaboracin. Esta actividad de la ingeniera de requerimientos se enfoca en el desarrollo de un modelo tcnico refinado de las funciones, caractersticas y restricciones del software. La elaboracin es una accin del modelado del anlisis y se componen de una serie de tareas del modelado y refinamiento. La elaboracin se conduce mediante la creacin y el refinamiento de escenarios del usuario que describen la
4

forma en que el usuario final (y otros actores interactan con el sistema). Cada escenario del usuario se analiza para obtener clases de anlisis: entidades del dominio del negocio visibles para el usuario final. Se definen los atributos de cada clase de anlisis y se identifican los servicios que requiere cada clase. Se identifican las relaciones y la colaboracin entre las clases y se produce una variedad de diagramas de UML complementarios. El resultado final de la elaboracin es un modelo de anlisis que define el dominio de la informacin, las funciones y el comportamiento del problema.

1.1.4 Negociacin

Dados los recursos limitados del negocio, no resulta inusual que los clientes y usuarios pidan ms de lo que se puede lograr. Tambin es relativamente comn que diferentes cliente o usuarios propongan requisitos que entran en conflicto entre s al argumentar que su versin es esencial para nuestras necesidades especiales. El ingeniero de requerimientos debe conciliar estos conflictos por medio de un proceso de negociacin. Se pide a los clientes, usuarios y a otros interesados que ordenen sus requisitos y despus discutan los conflictos relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares del esfuerzo requerido para su desarrollo y despus se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfaccin. Nota: en una negociacin eficaz no debe haber ni ganador ni perdedor. Ambas partes ganan porque se solidifica un trato con el que las dos pueden vivir.

1.1.5 Especificacin En el contexto de los sistemas basados en computadora (y en software), el trmino especificacin tiene significados diferentes para personas distintas. Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o La especificacin es el producto de trabajo final que genera la ingeniera de requerimientos. Sirve como base para las actividades de ingeniera de software subsecuentes. Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regir su desarrollo. 1.1.6 Validacin La calidad de los productos de trabajo procedentes de la Ingeniera de requerimientos se evala durante un paso de validacin. La validacin de requerimientos examina la especificacin para asegurar que todos los

requerimientos de software se han establecido de manera precisa; que se han detectado inconsistencias, omisiones y errores y que stos han sido corregidos, y que los productos de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto. El mecanismo primario para la validacin de requerimientos es la revisin tcnica formal. El equipo de revisin que valida los requisitos incluye ingenieros de software, clientes, usuarios y otros interesados que examinan la especificacin y buscan errores en el contenido o en la interpretacin, reas que tal vez requieren una clasificacin, informacin faltante, inconsistencias (que es un problema importante cuando se desarrollan productos o sistemas grandes), conflictos entre los requisitos, o requisitos irreales (inalcanzables).

Con frecuencia resulta til examinar cada requisito frente a una serie de preguntas en forma de lista de verificacin. Enseguida se presenta un pequeo subconjunto de las preguntas que deben realizarse: El requisito se puede probar? S es as, Se pueden especificar las pruebas (algunas veces llamadas criterios de validacin) para ejecutar el requisito? Los requisitos estn establecidos de manera clara? stos pueden malinterpretarse? El requisito es rastreable para cualquier modelo de sistema que haya sido creado? La fuente del requisito (por ejemplo, una persona, una regulacin o un reglamento) est identificada? El enunciado final del requisito ha sido examinado por la fuente original o comparndolo con ella? El requisito es rastreable para los objetivos generales del sistema o producto? El requisito est restringido en trminos cuantitativos? La especificacin est estructurada de una forma que conduzca a su comprensin, referencia y traduccin fcil en productos de trabajo ms tcnicos? 1.1.7 Gestin de requerimientos Se sabe que los requerimientos para los sistemas basados en computadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema. La gestin de requerimientos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los equipos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto. Muchas de estas actividades son idnticas a las actividades de la gestin de la configuracin del software (CGS).

Figura 1.1 tabla de rastreabilidad

La gestin de requisitos comienza con la identificacin. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad. En la figura 1.1 se muestra de manera esquemtica una tabla de rastreabilidad, cada una de ellas relaciona los requisitos con uno o ms aspectos del sistema o de su ambiente. Entre las tablas de rastreabilidad tenemos las siguientes: Tabla de rastreabilidad de las caractersticas: Muestra la manera en que los requerimientos se relacionan con las caractersticas del sistema/producto observables para el cliente. Tabla de rastreabilidad de dependencia: Indica la forma en que los requisitos estn relacionados entre s. Tabla de rastreabilidad del subsistema: Establece categoras entre los requerimientos de acuerdo con los subsistemas que gobiernan. Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requerimientos se relacionan con las interfaces internas y externas del sistema. En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requerimientos de forma que se puede buscar con rapidez para entender cmo el cambio en un requisito afectar diferentes aspectos del sistema que se construir.
8

1.2 Requerimientos de los usuarios

Los requerimientos del usuario, los del sistema y la especificacin del diseo del software se definen como se muestra a continuacin: Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el diagrama provea y de las restricciones bajo las cuales debe operar. Los requerimientos del sistema establecen con detalle los servicios y restricciones del sistema. ste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Una especificacin del diseo del software es una descripcin abstracta del diseo del software que es una base para un diseo e implementacin detallados. Esta especificacin agrega detalle a la especificacin de requerimientos del sistema. 1.2.1 Redaccin Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: 1. Falta de claridad. Es difcil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y hacerlos fcil de leer. 2. Confusin de requerimientos. No se distinguen claramente los

requerimientos funcionales y no funcionales, las metas del sistema y la informacin para el diseo. 3. Conjuncin de requerimientos. Diversos requerimientos diferentes se expresan de forma conjunta como un nico requerimiento. En el documento de requerimientos es una buena prctica separar los requerimientos del usuario de los detallados del sistema. Por otra parte, los

lectores no tcnicos de los requerimientos del usuario se confundirn con los detalles que slo son relevantes a los lectores tcnicos.

Cuando los requerimientos del usuario incluyen demasiada informacin, restringen la libertad del desarrollador del sistema para proveer soluciones innovadoras a los problemas del usuario y hace que los requerimientos sean difciles de comprender. Los requerimientos del usuario simplemente deben enfocarse a los recursos principales a proveer.

Ejemplos de los requerimientos de los usuarios pueden ser los siguientes puntos: Obtener soluciones a problemas en el trabajo de los usuarios bajo el sistema actual. Una interfaz ms amigable, rpida de aprender y fcil de usar Tiempo de respuesta ms corto al momento de hacer ya sea una consulta o algn movimiento. 1.2.2 Actores involucrados. Los actores en los sistemas de informacin se dividen en cinco grupos: 1. Dueos del sistema. 2. Usuarios del sistema. 3. Diseadores de sistemas. 4. Constructores de sistemas. 5. Analistas de sistemas. A continuacin se exponen cada uno de estos grupos. 1.2.2.1 Dueos del sistema. Para cualquier sistema de informacin grande o pequeo habr uno o ms dueos del sistema, los dueos del sistema tienden a estar interesados en:
10

Cunto costara el sistema? Cul ser el costo/beneficio? Cundo recuperaran la inversin y como la recuperaran?

Y otras, las cuales son de inters econmico primordialmente. Este grupo es que paga por el sistema. 1.2.2.2 Usuario del sistema. Los usuarios del sistema son los que definen los requerimientos del negocio y las expectativas del sistema. Ellos ven a un sistema de informacin en trminos de la funcionalidad que provee a sus trabajos, en que sea fcil de aprender y de utilizar. Usuarios internos: Aquellos empleados del negocio para el cual se est construyendo el sistema y son el mayor porcentaje de usuarios de un sistema. Dentro de este grupo tenemos. Empleados administrativos y de servicios: realizan los procesos del da a da, procesan rdenes, facturas, pagos etctera. Staff tcnico y profesional: son empleados que realizan tareas

especializadas ejemplo. Abogados, ingenieros, cientficos etctera. Supervisores mandos medios y ejecutivos: son los empleados que toman decisiones, ya sea decisiones del da a da (supervisores), de corto plazo (mandos medios) o largo plazo (ejecutivos). Usuarios Externos. El uso de Internet ha permitido extender los lmites de las organizaciones, de forma que se ha generado un aumento de usuarios externos, dentro de los cuales podemos mencionar: Clientes: son cualquier organizacin o persona(s) que compren nuestros productos o servicios. Surtidor o Proveedor: son cualquier organizacin en la cual nuestra compaa compre insumos.

11

Socios: son cualquier organizacin a la cual nuestra compaa compre servicios o de la que sea socio. Empleados: son empleados que trabajan en el camino o en casa.

1.2.2.3 Diseadores del sistema. Son tcnicos especializados que traducen los requerimientos de los usuarios del negocio en soluciones tcnicas. Ellos disean: bases de datos, entradas y salidas del sistema, pantallas, redes y software que se puede adaptar a los requerimientos del usuario. Un diseador del sistema puede pertenecer a algunas de las siguientes especialidades: Administrador de la base de datos. Arquitectos de redes. Arquitectos web. Artistas grficos. Expertos en seguridad. Especialistas en tecnologa.

1.2.2.4 Constructores del sistema. Su rol es la construccin del sistema de acuerdo a las especificaciones dadas por el diseador de sistemas. Un constructor del sistema puede pertenecer a algunas de las siguientes especialidades: Programador de aplicaciones. Programadores de sistemas. Programadores de bases de datos. Administradores de redes. Administradores de seguridad. Webmaster. Integradores de software.

12

1.2.2.5 Analista de sistemas. Es un especialista que estudia los problemas y necesidades de una organizacin para determinar cmo las personas, datos, procesos y la tecnologa de la informacin pueden en conjunto mejorar un negocio. El analista exitoso debe contar con una amplia gama de cualidades. Hay una gran diversidad de personas trabajando como analistas de sistemas, por lo que cualquier descripcin que intente ser general est destinada a quedarse corta en algn sentido. No obstante, la mayora de los analistas de sistemas tienen algunas cualidades comunes, debe ser una persona autodisciplinada y automotivada, con la capacidad de administrar y coordinar los innumerables recursos de un proyecto, incluyendo a otras personas.

1.3 Requerimientos para el anlisis y negociacin

Los requerimientos para el anlisis nos responden a la pregunta Qu se desea que haga el sistema? Ms no Cmo se desea que se realice? El proceso de entender y documentar el que se supone que debe hacer una aplicacin se llama requerimientos para el anlisis. Por lo general los requerimientos de este tipo expresan que se supone que debe hacer, no intentando expresar como lograr que funcione. Por ejemplo, la siguiente afirmacin es un requerimiento para una aplicacin de contabilidad. El sistema debe permitir a los usuarios acceso a sus saldos Lo siguiente no es un requerimiento para una aplicacin: Los estados de cuenta del cliente se almacenaran en una tabla llamada saldos en una base de datos de Access.

La razn por la cual no es un requerimiento es debido a que se refiere a cmo debe de construirse la aplicacin y no a que debe hacer la aplicacin.
13

Existen excepciones a la regla de que los requerimientos se eviten especificar cmo debe de hacerse algo. Por ejemplo, si el cliente del ejemplo anterior podra por alguna razn, querer que los estados de cuentas se almacenen en la base de datos de Access con el nombre indicado.

Es en estos casos en el que la segunda afirmacin se volvera en un requerimiento. La salida de los requerimientos para el anlisis es un documento que se conoce como especificacin de requerimientos o especificacin de requerimientos de software (ERS).

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?
14

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 El cliente y el desarrollador entran en un proceso de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caractersticas del sistema o producto frente al costo y el tiempo de colocacin en el mercado. El objetivo de esta negociacin es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo, tiempo, gente, presupuesto) a las que est sometido el equipo de software. 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.

1.4 Requerimientos para la gestin

Los requisitos del sistema pueden cambiar y el deseo de cambiar los requisitos persiste a lo largo de la vida del sistema. Por ello se documentan cada uno de los requisitos que sufren cambios durante el proceso de anlisis.

15

La gestin de requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. El proceso de gestin de requerimientos debera empezar en cuanto est disponible una versin preliminar del documento de requerimientos, pero se debera empezar a planificar cmo gestionar los requerimientos que cambian durante el proceso de obtencin de requerimientos.

Desde una perspectiva de cambio, los requerimientos se dividen en dos clases:

1. Requerimientos duraderos: Son requerimientos relativamente estables que se derivan de la actividad principal de la organizacin y que estn relacionados directamente con el dominio del sistema. Por ejemplo, en el hospital siempre habr requerimientos que se refieren a los pacientes, mdicos, enfermeras y tratamientos. Estos requerimientos se pueden derivar de los modelos del dominio que muestran las entidades y relaciones que caracterizan un dominio de aplicacin. 2. Requerimientos voltiles: Son requerimientos que probablemente

cambian durante el proceso de desarrollo del sistema o despus de que este se haya puesto en funcionamiento. Un ejemplo seran los requerimientos resultantes de las polticas gubernamentales sobre la sanidad.

Dentro del proceso de gestin se establece 2 etapas importantes:

1. La planificacin de la gestin de requerimientos: La planificacin es una primera etapa esencial del proceso de gestin de requerimientos. La cual

16

tiene un coste elevado. Para cada proyecto la etapa de planificacin establece el nivel de detalle necesario en la gestin de requerimientos.

1.1 La identificacin de requerimientos. Cada requerimiento se debe identificar de forma nica de tal forma que puedan ser remitidos por otros requerimientos de manera que pueda utilizarse en las evaluaciones de rastreo. 1.2 Un proceso de gestin del cambio. Este es conjunto de actividades que evalan el impacto y coste de los cambios. 1.3 Polticas de rastreo. Esta poltica define las relaciones entre los requerimientos, y entre stos y el diseo del sistema que se debe registrar y la manera en que estos registros se deben mantener. 1.4 Ayuda de herramientas CASE. La gestin de requerimientos comprende el procesamiento de grandes cantidades de informacin sobre los

requerimientos. Las herramientas que se pueden utilizar van desde sistemas de gestin de requerimientos especializados hasta hojas de clculo y sistemas sencillos de bases de datos.

2. Gestin de cambio de los requerimientos: Se debe aplicar a todos los cambios propuestos en los requerimientos. La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada. Existen 3 etapas principales en un proceso de gestin de cambio:

2.1 Anlisis del problema y especificacin del cambio. El proceso empieza con la identificacin de un problema en los requerimientos o, algunas veces, con una propuesta de cambio especfica. Durante esta etapa, el problema o la propuesta de cambio se analizan para verificar que esta es vlida.

17

2.2 Anlisis del cambio y clculo de costes. El efecto de un cambio propuesto se valora utilizando la informacin de rastreo y el conocimiento general de los requerimientos del sistema. Coste de hacer un cambio se estima en trminos de modificaciones al documento de requerimientos y, si es apropiado, al diseo e implementacin del sistema.

2.3 Implementacin del cambio. Se modifica el documento de requerimientos y, en su caso el diseo e implementacin del sistema. Debe organizar el documento de requerimientos de modo que pueda hacer cambios en el sin tener que hacer grandes reorganizaciones o redactar nuevamente gran cantidad del mismo. Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe siempre la tentacin de hacer ese cambio al sistema y entonces modificar de forma retrospectiva el documento de requerimientos.

.Algunos ejemplos por los cuales los requerimientos suelen cambiar pueden ser: Cambios tecnolgicos.

Porque al analizar el problema, no se hicieron las preguntas correctas a las personas correctas.

Porque cambi el problema que se estaba resolviendo.

Porque los usuarios cambiaron su forma de pensar o sus percepciones.

Porque cambi el ambiente de negocios

Bibliografa
Sommerville Ian,
18

Libro Ingeniera de Software 6 edicin Ed. Pearson Educacin

Herrera J. Lizka Johany, Ingenieria de Requerimientos Ingenieria del Software, http://www.monografias.com/trabajos6/resof/resof.shtml

Gomez Gallego Juan Pablo, Resumen de 4 primeros captulos de Engineering Requeriments Handbook (Ralph, R. Young ), Universidad Tecnolgica de Pereira, http://es.scribd.com/doc/270431/Ingenieria-requerimientos

guest409adc, Unidad I Procesos de la ingeniera de Requerimientos, http://www.slideshare.net/guest409adc/unidad-i-requerimientospresentation

Gutierrez Daz Jos Fructuoso, Planificacion y Modelado, Instituto Tecnologico de Pachuca. http://es.scribd.com/doc/64434948/Planificacion-yModelado#outer_page_34

Lpez Gonzlez Isis Imelda y Rivera Carrera Amalia Beatriz, Sistema de Control Presupuestal, Instituto Tecnolgico Superior de Misantla, 2009, http://es.scribd.com/doc/52247996/38/Analisis-y-Negociacion-deRequisitos

Snchez Hernandez Miriam Zulma, Unidad I Planificacion y Modelado, http://es.scribd.com/doc/26752264/PlanificaciOn-yModelado-Procesos-de-La-Ingenieria

19

20