Ingeniera de Requisitos de Software.

Gil, Dely Medina, Betty Prez, Ratzar

La Ingeniera de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. [Pressman, 2006: 155]

Se define como: Conjunto de actividades para descubrir, documentar y mantener un conjunto de requisitos. La Ingeniera de Requisitos es una disciplina que abarca todos los aspectos requeridos para crear y mantener un Documento de Requisitos del Software Es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. [Sommerville, 2005: 82]

Se puede resumir como un conjunto de actividades que tienden un puente hacia el diseo y la construccin, a partir de las necesidades del negocio, usuarios, funciones y restricciones del proyecto, permitiendo establecer con eficiencia los servicios que el cliente requiere de un sistema y las restricciones bajo las cuales opera y es desarrollado.

Buena parte de los problemas que surgen a lo largo del proceso de desarrollo se deben a la carencia de un proceso adecuado de definicin y entendimiento del problema y

a la definicin poco clara de las necesidades del cliente. La importancia de la ingeniera de requisitos se comprueba en enfoques de mejoramiento del proceso como Integracin de modelos de madurez de capacidades o Capability Maturity Model Integration (CMMI), que define la gestin y anlisis de requisitos como unas de las prcticas bsicas a la hora de evaluar el nivel de madurez de un proceso de desarrollo implantado en una organizacin.

Un requerimiento es una caracterstica que el sistema debe tener o es una restriccin que el sistema debe satisfacer para ser aceptada por el cliente. El Levantamiento de requerimientos es la especificacin del sistema en trminos que el cliente entienda, de forma que se constituya en el contrato entre el cliente y los desarrolladores.

La Definicin de Requisitos es una etapa clave en el ciclo de vida del software, teniendo en cuenta: -Su costo es alrededor de 10-15% del costo total del proyecto. -Un error en los requisitos puede ser hasta 100 veces ms costoso que un error en el cdigo. Una equivocacin en la etapa de requisitos se arrastra en las dems fases del ciclo de vida -Los procesos / sistemas complejos implican miles de requisitos (necesidad de gestin y soporte automatizado)

Tipos de Requerimientos

Requerimientos Funcionales
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera el Software provea. En este apartado se debe describir lo que el sistema tendr que hacer, los factores que afectan al producto y satisfacen los requerimientos.

Describen la interaccin entre el sistema y su ambiente independientemente de su implementacin. El ambiente incluye al usuario y cualquier otro sistema externo que interacta con el sistema.

Describen las interacciones entre el sistema y su entorno (usuarios u otros sistemas), sin tener en cuenta cuestiones de implementacin. Se estudian y representan en el Modelo de Casos de Uso.

Requerimientos No Funcionales Los requerimientos no funcionales tienen que ver con las caractersticas que de una u otra forma puedan limitar el sistema como son: el rendimiento (en tiempo y espacio), confiabilidad, interfaces, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Estos pueden ser clasificados en:

1.- Requisitos del Producto: especifican el comportamiento del software como: rapidez de ejecucin, uso memoria RAM, promedio de fallas, portabilidad, y usabilidad. A continuacin se detallan cada uno de los requerimientos del producto:

Usabilidad En este apartado se debe incluir la lista de todos los requerimientos que afecten la usabilidad. Esto debe incluir: el tiempo que se tomar un usuario en aprender a utilizar el sistema y se podra explicar por qu debe ser rpido el aprendizaje, los tiempos medibles de tarea para las tareas tpicas y los requerimientos para concordar con estndares.

Confiabilidad Aqu se deben detallar los requerimientos de confiabilidad del sistema. Describa las caractersticas de confiabilidad explicando la posibilidad del sistema de realizar las funciones para las que fue diseado sin presentar fallos. Entre estos requerimientos puede mencionar caractersticas como la disponibilidad, el porcentaje de fallas mximo, etc.

Seguridad Aqu se deben detallar los requerimientos de seguridad del sistema. Esto incluye si el acceso al sistema ser controlado con nombres de usuario y contraseas, que solo los usuarios con privilegios de administrador podrn acceder a las funciones administrativas y los usuarios normales no podrn.

Eficiencia En este apartado se debe ver reflejado las caractersticas de eficiencia del sistema. Se debe especificar: el tiempo de respuesta para una transaccin (promedio), capacidad (nmero de clientes y transacciones), rendimiento del procesamiento (Ej. transacciones por segundo) y cuando el sistema se ha degradado cul es el modo aceptable de operacin.

Mantenimiento y Actualizacin En este apartado se debe ver reflejado los requerimientos de mantenimiento y actualizacin. La capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el tiempo y la capacidad de actualizacin es la habilidad que se tiene para entregar las versiones del producto a bajo costo a los clientes con un mnimo de 4

tiempo de descarga. Una caracterstica clave para apoyar este objetivo es la descarga automtica de parches o actualizaciones y actualizaciones del equipo del usuario final. Tambin debemos utilizar formatos para archivos de datos que incluyan suficientes metadatos para permitirnos trasformar con seguridad la informacin existente del usuario durante una actualizacin.

Soportabilidad y Operabilidad Especificar los requerimientos de soportabilidad y operabilidad del sistema. La soportabilidad la habilidad de proveer soporte tcnico eficiente y a buen precio y la operabilidad es la habilidad que se tiene de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones).

Restriccin de Diseo En este apartado se debe indicar cualquier limitacin de diseo en el sistema que es construido. Por ejemplo: lenguajes de software, requerimientos del proceso de software, uso de herramientas de desarrollo, componentes comprados, etc.

Requerimientos de Documentacin en Lnea y de Sistemas de Ayuda En caso de que exista se debe describir los requerimientos, para la documentacin en lnea del usuario, sistemas de ayuda, ayuda sobre avisos, etc.

Interfaces En este apartado se definen las interfaces que debe apoyar la aplicacin, como son: las interfaces de usuario, interfaces de software, etc. En caso de que aplique es conveniente hacer referencia a estndares de la aplicacin o corporativos. - Interfaces de Usuario: Se describen las interfaces de usuario que van a hacer ejecutadas por el software.

- Interfaces de Software: Hay que describir las interfaces de software hacia otros componentes del sistema. Pueden ser: componentes comprados, reutilizados o realizados para subsistemas fuera del alcance de este documento. - Interfaces de Hardware: Aqu se describen comentarios de cualquier interfaz de hardware que debe ser apoyada por el software, esto incluye: comportamiento, estructura lgica, etc.

2. Requisitos Organizacionales: se derivan de las polticas, normas y procedimientos en la organizacin del Cliente y en la del desarrollador como: uso de metodologas de desarrollo, lenguajes de especificacin y codificacin

3.- Requisitos Externos: Requisitos de interoperabilidad, legales o jurdicos y ticos. Estos ltimos son importantes para asegurar que el software ser aceptado por usuarios y todos los involucrados (stakeholders). Ejemplo: El sistema no registrar ninguna informacin personal de los clientes salvo su nombre y nmero de referencia respetando lo establecido en la LOPD.

Proceso de Ingeniera de Requisitos.

Esta representado por un conjunto estructurado de actividades de cuya ejecucin se obtiene, valida y mantiene el documento de requisitos del sistema. Las actividades que rigen el proceso de ingeniera de requisitos varan en funcin de la metodologa seguida, el dominio de aplicacin, las personas participantes y la organizacin. Al respecto, se han definido diversos modelos a nivel de toda la Ingeniera de Software, as tenemos para el desarrollo de aplicaciones Web, de escritorio, o sencillamente se ha definido un estndar, pero en general, la mayor parte de estos procesos tienen una similitud y lo nico que buscan es recopilar la mayor cantidad de requerimientos correctos para as conformar una buena estructura que servir de base para el desarrollo de un proyecto.

Proceso de Ingeniera de Requisitos

Otros especialistas presentan este proceso identificando las siguientes dos actividades: Desarrollo de Requisitos, constituida por: Elicitacin, Anlisis,

Especificacin, Validacin Gestin de Requisitos

Ambas formas describen en forma detallada el proceso, para lograr una especificacin ms completa, en este informe presentaremos las actividades del proceso de Ingeniera de requisitos tomando informacin de ambos modelos.

Descripcin de las Fases del Proceso de Ingeniera de Requisitos

Desarrollo de Requisitos.
Fase 1.- Estudio de viabilidad: Este permitir rendir un informe tanto al equipo de desarrollo del proyecto como al usuario o cliente, donde se verificar si el proyecto vale la pena desarrollarlo. Es de vital importancia para la satisfaccin de los objetivos del negocio. Los aspectos que deben ser tomados en cuenta son:

Estimacin sobre si se puede resolver el problema del usuario con las

tecnologas software y hardware disponible Tecnologa: hay tecnologa? se domina? est dentro del estado del arte? organizacin?. Tiempo: llegar al mercado antes que la competencia? Recursos: qu se va a necesitar? est disponible? Financiera: El estudio decide si el sistema es rentable y puede

desarrollarse cumpliendo las restricciones econmicas. Pueden asumir el costo la

Esta muy relacionado con la experiencia disponible en el tipo de proyecto que se pretenda desarrollar (si se han hecho muchos, es ms fcil decidir sobre la viabilidad de una propuesta)

Fase 2.-

Captura y Anlisis: En esta fase el desarrollador o su equipo de

desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se desea construir, adems, se debe identificar cules son los servicios que prestar el sistema, su rendimiento, sus necesidades y restricciones, y cules son los objetivos esperados. El Anlisis de Requisitos se refiere al esfuerzo de analizar los requisitos para detectar y resolver conflictos entre requisitos, descubrir los lmites del software y cmo debe interactuar con su entorno. A continuacin se describe como se detalla las actividades que se realizan en esta fase:

Actividades del proceso de obtencin y anlisis de requisitos: - Elicitacin: Llamada Captura / Descubrimiento de Requisitos. Es una actividad fundamentalmente humana, en la que se identifican los interesados (stakeholders) y se establecen relaciones entre el equipo de desarrollo y los clientes. Para llevarla a cabo el ingeniero debe aprender: De dnde vienen los requisitos, y cmo puede recopilarlos?.

Supone el conocimiento de: El Problema, los detalles del problema especfico del cliente donde se aplicar el sistema, el Negocio, cmo los sistemas interactan y contribuyen a las metas del negocio, las Necesidades y Restricciones de los Beneficiarios del Sistema, Necesidades especficas de la gente que requiere soporte del sistema para su trabajo

Los requisitos se originan a partir de: Objetivos (intereses de negocio, factores crticos de xito): proveen la

motivacin para realizar el software, pero suelen ser ambiguos. Conocimiento del Dominio: permite al ingeniero inferir conocimiento

tcito que los interesados no articulan. Interesados (stakeholders): el ingeniero necesita identificar, representar

y gestionar los puntos de vista de los diferentes tipos de interesados. Entorno operacional: el entorno en el que se ejecutar el software. Entorno organizacional: el ingeniero debe ser sensible a la estructura,

cultura y polticas de la organizacin, as como a los procesos de negocio a los que dar soporte el software.

Tcnicas de obtencin de Requisitos Las Tcnicas de Captura para Requisitos sirven para: Conseguir que los interesados humanos articulen sus requisitos Recopilar el conocimiento sobre los requisitos del sistema.

Entre las tcnicas para Captura de Requisitos ms utilizadas se mencionan:

Entrevistas: Es una de las tcnicas mas utilizadas; estas son utilizadas en todo

tipo de escenarios y hacen parte del conjunto de actividades que desarrollan todas las sociedades. Una entrevista se puede definir bsicamente como una conversacin con un 9

propsito entre dos o ms personas, son ideales para obtener informacin de suposiciones y percepciones, adems sirven para indagar informacin a profundidad sobre un tema en especfico. Estas se catalogan en no estructuradas, estructuradas y semi-estructuradas. Usualmente se considera que las entrevistas son el mejor procedimiento para levantar informacin, pero algunas veces estas limitan la percepcin de nueva informacin; por estar centralizadas en algn tema.

Observacin: Es una de las tcnicas etnogrficas mas usadas, bsicamente

consiste como su nombre lo dice en observar cada uno de los procesos existentes, claro est que no se interviene de manera directa. Al ser una tcnica que involucra personas que tengan un alto grado de anlisis que conlleve a interpretar y a comprender de manera eficaz cada uno de los procesos en los que estn involucradas las personas, esta implica demasiado tiempo y sus costos son muy elevados. Mediante Observaciones los ingenieros de software pueden aprender sobre las tareas de los usuarios haciendo ellos mismos una inmersin en el entorno real de los usuarios y observando cmo cada usuario interacta con su software y con otros usuarios. Escenarios: se usan principalmente para describir y especificar los

procesos actuales y los futuros del negocio, en el cual se incluye la interaccin entre los usuarios y el sistema a desarrollar. Estos estn escritos en lenguaje natural y no abordan la estructura interna del sistema, los escenarios abarcan las posibles interacciones que puede tener los usuarios con el sistema, ya que se basan en dar la descripcin de la vida real. Para que sea efectivos se requiere sea haga uso de ayudas interactivas que se vallan ejecutando gradualmente. Adicional los escenarios sirven para hacer el proceso de validacin y comprensin de requerimientos y en muchos casos se usan como casos de prueba. Los Escenarios son ejemplos de la vida real de cmo puede ser usado un sistema. Deben incluir: Una descripcin de la situacin de partida. Una descripcin del flujo normal de eventos. Una descripcin de lo que puede ir mal. Informacin sobre otras actividades concurrentes. Una descripcin del estado cuando el escenario acaba. 10

EL tipo de escenario ms usado son los Casos de Uso.

Prototipado: La tcnica consiste bsicamente en mostrar a los Stakeholders

modelos de otros sistemas ya desarrollados o de modelos que sirven como gua para identificar la manera que se requiere que interactu un sistema de informacin. Las reacciones al uso de prototipos se captura a travs de entrevistas, observacin, cuestionarios, entre otras. Esta tcnica es principalmente usada para levantar informacin de requerimientos de interfaz. La desventaja que tiene este tipo de tcnica es el alto costo y tiempo para su desarrollo, pero la ventaja es que animar a los Stakeholders a desempear un papel ms activo para la especificacin de los requerimientos.

- Los Prototipos son una herramienta para clarificar requisitos confusos. - Un prototipo en sentido genrico es una implementacin parcial pero concreta de un sistema o una parte del mismo que principalmente se crean para explorar aspectos muy diversos del sistema durante su desarrollo. - El uso de los prototipos en el desarrollo de sistemas de software: Permite probar las interacciones que los usuarios deben realizar. Es til en la fase de recopilacin o anlisis de requisitos porque ampla y

mejora la informacin necesaria para el desarrollo del sistema. - Existe un amplio rango de tcnicas de prototipado para requisitos: - Desde diseos de pantallas dibujados en papel, - Hasta versiones beta de prueba de productos software complejos.

11

 Casos de Uso: son una tcnica para especificar el comportamiento de un

sistema. El sitio en Internet wikipedia.org, define a un caso de uso como: Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor, es una descripcin de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayora de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Segn el autor Sommerville, los casos de uso son una tcnica que se basa en escenarios para la obtencin de requerimientos. Actualmente, se han convertido en una caracterstica fundamental de la notacin UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos

Reuniones: Bsicamente son diferentes tipos de reuniones grupales en el

que se desarrollan, descubren y validan diferentes tipos de requerimientos. Existen muchas formas de hacer talleres de requerimientos que involucren a los Stakeholders de los diferentes departamentos de la organizacin. Al usar diferentes talleres podemos dar pie a que se haga uso de la creatividad y desarrollar requerimientos de manera colectiva, estos talleres son enriquecedores ya que se retroalimentan del conocimiento del grupo de Stakeholders. Para que esta tcnica llegue a ser realmente efectiva, se debe hacer un buen proceso de identificacin de Stakeholders, y se deben contar con talleres debidamente preparados y enfocados.

Las Reuniones sirven para intentar alcanzar un efecto acumulativo o sinrgico de manera que un grupo de personas puede profundizar ms y mejor en sus requisitos que trabajando de forma individual.

Clasificacin y organizacin de Requerimientos : eta actividad toma la

recopilacin no estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en grupos coherentes. - Ordenacin por prioridades y negociacin de Requerimientos: esta actividad tiene como objetivo resolver los requerimientos en conflicto que suelen presentarse cuando

12

existen muchos stakeholders involucrados, ordenando segn las prioridades los requerimientos. - Documentacin de requerimientos: se producen los documentos de requerimientos formales e informales.

Fase 3.- Especificacin: El objetivo es obtener un documento de especificacin de requisitos, en cual se llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o necesidades que debe satisfacer el sistema a desarrollar, adems de sus respectivas restricciones (software, hardware), de tal forma que sirva de base para un contrato entre el cliente y el desarrollador de software.

Fase 4.- Validacin: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron ya en la especificacin. Si la validacin es inadecuada, se propagarn errores al diseo e implementacin, evidentemente, tiene una fuerte repercusin sobre el costo. Hay distintos tipos de comprobaciones en el proceso de validacin de requisitos: - Validez. Comprobar la necesidad de las funciones definidas en la SRS. - Consistencia. Comprobar que no hay restricciones contradictorias o distintas descripciones de la misma funcin. - Completitud. Comprobar que todos los requisitos y restricciones estn incluidos en la SRS. - Realismo. Comprobar que se pueden implementar los requisitos con las tecnologas y plantilla disponible. - Verificabilidad. Comprobar que los requisitos pueden ser verificables con el fin de evitar problemas entre clientes y desarrolladores.

Gestin de Requisitos

13

La gestin de requisitos es el proceso de entender y controlar los cambios en los requisitos del sistema. Ac se realiza la comprensin y control de los cambios de cada uno de los requisitos, sean estos requisitos estables (corresponden al estado del sistema) o voltiles (representan eventos que hacen que el sistema realice una funcin dada). Durante la Gestin de Requisitos se controla los cambios en los Requisitos base y se monitorea la implementacin de Requisitos Los requisitos pueden cambiar y evolucionar, ya que puede haber requisitos variables en funcin del usuario, el cliente no suele ser el usuario y el producto puede evolucionar. Desde un punto de vista evolutivo los requisitos pueden ser: - Estables. Se derivan de la actividad principal del sistema y estn directamente relacionados con el dominio. - Voltiles. Probablemente cambiarn durante el desarrollo del sistema o despus de su entrega. A su vez los voltiles pueden ser: - Mutables. Cambian debido a cambios en el entorno en el que la organizacin opera (e.g. un nuevo sistema de numeracin de signaturas de las bibliotecas). - Emergentes. Aparecen durante el desarrollo del sistema por el mayor entendimiento por parte del cliente. - De consecuencia. Aparecen por la introduccin del sistema. - De compatibilidad. Dependen de los procesos de negocio de la organizacin.

Para el logro de una gestin de requisitos eficiente es necesario ser capaz de: - Identificar los requisitos. - Tener un proceso de gestin del cambio. - Disponer de polticas de traza. - Disponer de soporte CASE

14

Mejores prcticas
En el desarrollo de software, una mejor prctica es un mtodo bien definido que contribuye a una implementacin exitosa del proyecto software. Las organizaciones crean mejores prcticas para que les ayuden a resolver problemas pudiendo disminuir la tasa de fallo de sus proyectos.

- Mejores Prcticas En El Desarrollo De Requisitos

A continuacin se describen una serie de mejores prcticas orientadas al desarrollo de requisitos: - Documentar el alcance y visin del proyecto : permitir tener un mejor entendimiento de los requisitos y asegurar que todas las personas involucradas en el proyecto trabajen hacia la misma meta. - Mantener un glosario del proyecto: facilitar una comunicacin efectiva asegurando un entendimiento unnime. - Uso de tcnicas de obtencin de requisitos de usuario: para facilitar esta tarea. - Involucrar a toda la gente implicada: asegura una validacin temprana del entendimiento de los requisitos. - Desarrollo incremental de requisitos: puede minimizar la cantidad de retrabajo del proyecto.

15

- Captura de requisitos usando casos de uso: ser ms fcil gestionar los requisitos y hacer un seguimiento de los mismos. - Validar requisitos: para mejorar el xito de los proyectos es crtico que se validen los requisitos de forma adecuada. - Verificar requisitos: para asegurar que los requisitos proporcionan una base adecuada para llevar a cabo el diseo, la construccin y las pruebas.

Mejores prcticas en la Gestin de Requisitos

A continuacin se muestran una serie de mejores prcticas relacionadas con la gestin de requisitos: - Priorizar requisitos: para determinar aquellos que se deberan cumplir en la primera versin o producto y aquellos que pueden llevarse a cabo en sucesivas versiones. - Establecer lneas base de los requisitos: para asegurar que cualquier modificacin en los requisitos que cambie la lnea base se trata como cambios de alcance. - Comunicacin abierta: para asegurar que la informacin relacionada con los requisitos se comunica de forma consistente. Una comunicacin abierta tambin implica comunicar a la gente correcta y al conjunto mnimo de personas. - Gestin de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva y eficiente. - Uso de herramientas para la gestin de requisitos : para facilitar la gestin de requisitos. - Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito. - Establecer un plan de mejora de procesos para la ingeniera de requisitos: para cumplir con las necesidades actuales y futuras de forma ms eficiente y con mayor calidad.

16

- Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tienen el conocimiento, entre otros aspectos, de cmo escribir buenos requisitos, etc.

Importancia de la Ingeniera de Requerimientos

Segn la autora Lizka Johany Herrera en su documento de la ingeniera de requerimientos, los principales beneficios que se obtienen de la Ingeniera de Requerimientos (IR) son: 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: es sabido que reparar

errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo. 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, entre otros).

17

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.

18

Bibliografa

Gua Prctica De Gestin De Requisitos. Instituto Nacional de Tecnologas de la Comunicacin Diciembre 2008

Ian Sommerville, Ingeniera de Software. Pearson, 2006. Sptima edicin. Lizka Johany Herrera J. Ingeniera De Requerimientos - Ingeniera De Software. Disponible: http://www.ilustrados.com/tema/1605/Ingenieria-RequerimientosIngenieria-Software.html

Mera Amezquita, Carlos Alejandro, Gua Para Interactuar Con Stakeholders En El Proceso De Ingeniera De Requerimientos - 26/07/2009

Michael Arias Chvez. La Ingeniera de Requerimientos y su importancia en el desarrollo de proyectos de software. Revista Intercedes, Universidad de Costa Rica, 2006 Nicols Davyt Dvila. Ingeniera de Requerimientos: Una gua para extraer, analizar, especificar y validar los requerimientos de un proyecto. Universidad ORT Uruguay, 2003 Roger Pressman, Ingeniera de Software: Un enfoque practico. Mcgraw Hill, 2006

19