Está en la página 1de 21

1.

INGENIERA DE REQUISITOS El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado Ingeniera de Requerimientos (IR). La meta de la IR es entregar una especificacin de requisitos de software correcta y completa. (ARIAS, S/F). La IR puede ser definida como un conjunto de actividades, donde utilizando tcnicas y herramientas, se analizan problemas y se concluye con la especificacin de una solucin (a veces ms de una). Entonces, la IR se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto determinado. El uso del trmino "ingeniera" implica que se deben utilizar tcnicas sistemticas y repetibles para asegurar que los requerimientos del sistema estn completos y sean consistentes y relevantes. 2. QU ES UN REQUISITO? Un requisito es una descripcin de una condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 3. TIPOS DE REQUISITOS 3.1 Requisitos Funcionales: son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Es importante que se describa el Qu? y no el Cmo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Tipos: 3.1.1 Requisitos del Negocio: se expresan desde la perspectiva de la empresa, describiendo el Por Qu? la empresa o el cliente desea desarrollar la aplicacin y expresan que objetivos, metas o necesidades la empresa espera alcanzar con la implementacin de la aplicacin 3.1.2 Requisitos del Usuario: se expresan desde la perspectiva del usuario, describiendo las necesidades que los usuarios tienen y las tareas que los usuarios realizarn con la aplicacin y expresan lo que el usuario ser capaz de hacer con la aplicacin. Son modelados mediante los casos de uso. 3.1.3 Requisitos del Sistema: estn relacionados a los productos que tienen componentes de hardware y software. Se asume que la aplicacin es parte de un sistema mayor. 3.1.4 Requisitos de Comportamiento se expresan desde la perspectiva del desarrollador, describen los servicios que la aplicacin presta a todos sus usuarios directos y expresan que hace la aplicacin bajo ciertos eventos.

3.2 Requisitos No Funcionales: tienen que ver con 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, entre otros. Tipos:

3.2.1 Restricciones: son las limitaciones que se le imponen al desarrollo la aplicacin, describen: la Plataforma de Desarrollo y Operacin, tiempo mximo de desarrollo, costo mximo del proyecto, entre otros. 3.2.2 Atributos de Calidad: son las cualidades o propiedades de calidad que la aplicacin debe satisfacer. 3.2.2.1 Funcionalidad: la capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales. 3.2.2.2 Fiabilidad: la capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo y condiciones definidas. 3.2.2.3 Usabilidad: es el esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente. 3.2.2.4 Eficiencia: es la relacin entre las prestaciones del software y los requisitos necesarios para su utilizacin. 3.2.2.5 Mantenibilidad: es el esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software. 3.2.2.6 Portabilidad: es la capacidad del software ser transferido entre diferentes entornos.

La calidad de una aplicacin se mide en funcin de sus atributos de calidad y para facilitar su medicin durante la verificacin, deben expresarse cuantitativa o cualitativamente. 3.2.3 Requisitos de Interfaz: expresan las caractersticas de la interaccin Usuario/Sistema o Sistema/Sistema. 3.2.4 Reglas del Negocio: Expresan regulaciones que la aplicacin debe acatar: gubernamentales (leyes, decretos, providencias), de la empresa (polticas, normas, procedimientos, estrategias) y las propias de la aplicacin (estndares y algoritmos). El proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de

llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

4. NIVELES DE REQUISITOS (ADAPTADO DE WIEGERS, 2003) Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que ellos tratan, y se muestran a continuacin:

5. REQUISITOS VS. REQUERIMIENTOS: Los requerimientos son necesidades documentales y aquellas descripciones que hace el usuario de los deseos o necesidades que tiene frente a un producto a los ingenieros o desarrolladores del software, estos requerimientos originan unos requisitos que se deben cumplir para poder llegar a cumplir los requerimientos.

Todo aquello que quiere el cliente, es decir, todo aquello que necesite lo entenderamos por requerimientos, y si hablamos de lo que se necesita para cumplir las peticiones del usuario nos referiramos a los requisitos.

Diferencias:

6. ITERACIN: IMPLEMENTAR Y PROBAR LOS REQUISITOS 6.1 Plan de Iteracin: Es una la a lista de tareas programadas para la iteracin vinculada al requisito de producto que quiere implementar. El equipo debe revisar los requisitos que se han sido programados para la iteracin y se crean los elementos de trabajo (diseo, desarrollo y pruebas) que son necesarias para que se cumpla con el requisito.

6.2 Calcular la Carga de Trabajo Adecuada de la Iteracin: esta genera los siguientes documentos, los cuales resultan tiles a la hora de calcular la cantidad de trabajo que se debe planear para una iteracin: 6.2.1 Estado de Todas las Iteraciones: realiza un seguimiento del rendimiento del equipo en las iteraciones sucesivas. Se utiliza para ver cuntos requisitos y cuntas horas se completaron en una iteracin. 6.2.2 Informacin General sobre los Requisitos: se muestran todos los requisitos por rea e iteracin e importancia. Indicar la cantidad de trabajo en que el equipo complet una iteracin. 6.2.3 Evolucin y Tasa de Evolucin: la evolucin muestra la tendencia de trabajo completado y trabajo restante a lo largo de un perodo de tiempo especificado. La tasa de evolucin indica la tasa de trabajo completado y trabajo requerido en funcin de la duracin de la iteracin. Programar la Demostracin y la Entrega de la Iteracin: Se debe realizar una demostracin de la funcionalidad incremental a los usuarios y entregar el trabajo completado para que se realicen las pruebas de validacin. Se recomienda que se registre los comentarios, experiencias y acotaciones para que sean de utilidad en procesos futuros. En caso de que la demostracin arroje nuevas tareas o requisitos, debern ser incluirlos en los futuros planes de iteracin. 6.4 Realizar el Seguimiento de las Iteraciones: a lo largo de la iteracin, se debe supervisar su progreso mediante los informes descritos anteriormente, para asegurarnos que se desarrolle segn las expectativas.

7. IDENTIFICACIN DE LAS PERSONAS INVOLUCRADAS

Son muchas las personas involucradas en el desarrollo de los requisitos de un sistema, es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto. El conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue:
7.1 Usuario final: son las personas que usarn el sistema desarrollado, el

producto final. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema, y estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario.
7.2 Usuario Lder: son todos los individuos que comprenden el ambiente del

sistema o el dominio del problema en donde ser empleado el software desarrollado, y proporcionan al equipo tcnico los detalles y requisitos de las interfaces del sistema.
7.3 Personal de Mantenimiento: son los responsables de la administracin de

cambios, de la implementacin y resolucin de anomalas.

Su trabajo

consiste en revisar y mejorar los procesos del producto ya finalizado.


7.4 Analistas y Programadores: son los responsables del desarrollo del producto

en s e interactan directamente con el cliente.


7.5 Personal de Pruebas: son los encargados de elaborar y ejecutar el plan de

pruebas para asegurar que las condiciones presentadas por el sistema son las

adecuadas, tambin validan si los requisitos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: los administradores de proyecto, documentadores, diseadores de base de datos, entre otros.

8. PASO A PASO DE LA INGENIERA DE REQUISITOS La IR empieza con la fase de inicio, la cual es una tarea que define el mbito y la naturaleza del problema que debe resolverse. Despus continua con la obtencin, que es una tarea que ayuda al cliente a definir sus necesidades; posteriormente sigue con la elaboracin, que es la fase donde se refinan y modifican los requisitos bsicos. Cuando el cliente ha definido el problema se lleva a cabo la negociacin, donde se define cuales son las prioridades, cuales aspectos son esenciales y en qu momento se requieren. Por ltimo el problema se especifica de alguna manera, y despus es validado y revisado para asegurar que la concepcin del problema que tiene el ingeniero de software coincide con la percepcin del cliente. 9. IMPORTANCIA DE LA INGENIERA DE REQUISITOS Los principales beneficios que se obtienen de la Ingeniera de Requerimientos es que Permite gestionar las necesidades del proyecto en forma estructurada, es decir, 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. Tambin 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 dicha calidad tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, entre otros). Se basa en mejorar la comunicacin entre equipos, dicha 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 IR 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.

10. ACTIVIDADES DE LA INGENIERA DE REQUISITOS En un proceso de IR efectivo, estas actividades son aplicadas de manera continua y en orden variado, dependiendo del tamao del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero como en nombres. 10.1 Inicio: comienza muchas veces por: Identificar una nueva necesidad de negocios. Descubrimiento de un nuevo mercado. Descubrimiento de un nuevo servicio. 10.2 Obtencin: consiste en la recopilacin de informacin de forma organizada por los Ingenieros.

DE MBITO

DE COMPRENSIN

DE VOLATILIDAD

Limite del sistema mal definido

El cliente no est seguro 100% de que es lo que necesita Tienen otros. dificultades para

Los problemas cambian con el tiempo.

Detalles tcnicos innecesarios, entre otros.

comunicar sus necesidades, entre

10.3

Elaboracin:

Objetivo: desarrollar modelo tcnico refinado de las funciones, caractersticas y restricciones del software. Se alcanzan estos objetivos mediante la creacin y refinamiento de escenarios. El resultado final es un modelo de anlisis que define: 1. El dominio de la informacin. 2. Funciones.
3. Comportamiento del problema.

10.4 Negociacin: clientes, usuarios y otros interesados deben ordenar sus requisitos y luego discutir los conflictos relacionados con la prioridad.

Se deben hacer estimaciones preliminares del esfuerzo requerido para su desarrollo y mediante un enfoque iterativo los requisitos se eliminan, combinan o modifican. 10.5 Especificacin: se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle y pueden ser:

Documento Escrito Conjunto de Modelos Grficos Modelo Matemtico Formal Escenarios de Uso Prototipo Una combinacin de estos.

Se recomienda: SISTEMAS GRANDES Documentos escritos SISTEMAS PEQUEOS Escenarios de uso

La especificacin es el trabajo final que genera la IR.


10.6

Validacin: examina la especificacin para asegurar que los requisitos de

software se han establecido de manera precisa.

ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR

La fuente del requisito est identificada? Cules otros requisitos estn relacionados con ste? El requisito viola alguna restriccin del dominio del sistema? El requisito se puede probar? Se pueden especificar las pruebas?, etc.

10.7

Gestin: es el conjunto de actividades que ayuda al equipo del proyecto a

identificar, controlar y rastrear los requisitos como tambin los cambios a stos en el desarrollo del proyecto, la gestin formal se inicia solo para proyectos grandes. Para esto se desarrollan las siguientes tablas

TABLAS De rastreabilidad de las caractersticas. De rastreabilidad de la fuente. De rastreabilidad del subsistema. De rastreabilidad de la interfaz.

11. CADENA DE VALOR DE LA INGENIERA DE REQUISITOS (IR)

La IR se ubica, junto al Modelado de Negocios, al comienzo de la cadena de valor del desarrollo de software.

La aplicacin de la IR al desarrollo de una aplicacin conduce a: Encontrar y definir las necesidades que tienen los interesados de la aplicacin. Transformar la definicin de necesidades en una descripcin completa y precisa de requisitos, denominada: especificacin de requisitos. Lograr un entendimiento comn, entre clientes/usuarios y

desarrolladores, de los requisitos que debe satisfacer la aplicacin Alcanzar los tres elementos fundamentales de la IR: El PROCESO Cmo hacerlo? LOS PRODUCTOS Qu se hace? El GRUPO Quienes lo hacen?

12. LOS PRODUCTOS DE LA INGENIERA DE REQUISITOS

12.1 El Plan de Gestin de Ingeniera de Requisitos: es un documento de gestin elaborado por el Lder del Proyecto o el Lder del Grupo de Requisitos que describe detalladamente las actividades, tiempos, costos y recursos requeridos en el proyecto para realizar los procesos IR.

12.2 El Prototipo de la Aplicacin: es un programa que exhibe la interfaz grfica de la aplicacin y demuestra su funcionalidad y se elaborada para verificar: los requisitos de los usuarios y de interfaz grfica.

12.3 El Documento de Requisitos (DR): es un documento manual o electrnico que describe y comunica los requisitos de la aplicacin. Es utilizado por dos tipos de audiencias: los clientes, usuarios y gerentes, y los desarrolladores

de la aplicacin. Tambin se les conoce como: Especificacin de Requisitos de Software (ERS) y Especificacin del Sistema (ES). Por lo general, se divide en dos partes: Documento o Seccin de Definicin de Requisitos (DDR) y Documento o Seccin de Especificacin de Requisitos (DER)

12.4 Documento de Definicin de Requisitos (DDR): se dirige a los clientes/usuarios y en su contenido identifica, describe, organiza y relaciona los requisitos desde la perspectiva de los clientes/usuarios. Cada requisito es debidamente identificado y documentado usando formatos especiales.

Ejemplo:

12.5 Documento de Especificacin de Requisitos (DER): se dirige a los desarrolladores del sistema y describe grficamente los requisitos contenidos en el DDR usando un lenguaje o notacin de modelado. Existen varios estndares y modelos (plantillas o patrones) que ayudan a elaborar el Documento de Requisitos: El estndar IEEE 830-1993: propuesto por el Institute of Electricaland Electronics Engineers (IEEE) y agrupa los documentos DDR y DER en un slo documento. El estndar ANSI: es una adaptacin del estndar IEEE 830-1993. Adaptacin de Wiegers (2003). Adaptacin de Le Vie (2009). 13. EJEMPLO PRCTICO: AGENCIA DE VIAJES POR INTERNET Actividad de IR: Obtencin. Especificaciones: Cliente: 1. Acceder a la pgina WEB de la agencia. 2. Seleccionar las ciudades de origen y destino, nmero de pasajeros, y las fechas de ida y vuelta. 3. El sistema deber mostrar la lista de vuelos disponibles para la fecha estipulada por el usuario donde seleccionar uno de ellos. 4. Si el usuario est conforme con su seleccin, introducir los datos de su tarjeta de crdito para hacer efectivo el pago y al igual que los datos de los pasajeros.

5. Se debe tener en cuenta que algunos usuarios estn dispuestos a variar sus fechas de viaje, con el fin de obtener tarifas ms econmicas. Ingeniero: 1. Habr que facilitar la bsqueda de vuelos en fechas parecidas y que sean ms econmicos. Por ejemplo, variando un da adelante o atrs tanto la fecha de ida como la de vuelta.

Diagramado:

CONCLUSIONES:
El proceso de Ingera de Requisitos (IR) debe desarrollarse bajo estricta disciplina y tener una conceptualizacin que represente de mejor manera las especificaciones del cliente, teniendo en cuenta que no todas las soluciones con iguales y que los modelos jams sern absolutos. La utilizacin de metodologas para la IR mas que una herramienta son un apoyo. Resulta imprescindible el conocimiento a profundidad de los clientes, usuarios finales y el contexto donde se desenvolver la aplicacin as como tambin la reutilizacin de la experiencia para garantizar la calidad del producto final que rena todas las caractersticas de un buen software, como: fiabilidad, eficiencia, factibilidad, integridad, entre otros. La gestin de los requerimientos ayudar al equipo del proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto y mediante un enfoque iterativo, los requerimientos se eliminan, combinan o modifican de forma que cada parte vaya logrando el grado de satisfaccin deseado. El reconocimiento del papel de la IR, su integracin en el resto del ciclo de vida del producto y la explotacin a nivel de gestin de la trazabilidad de los elementos del producto, es una situacin que debe ser mejorada.

REFERENCIAS

PRESSMAN, R. (2009). Ingeniera del Software: Un Enfoque Prctico (6ta.

ed). McGraw-Hill: Mxico.

GLVEZ, J. (S/F). Mdulo No. 1 Ingeniera de Software (3.0 ed.) [Documento lnea]. Disponible en: http://inteccolombia.org/PDF/ing%20de

en

%20sistemas/i.s1.pdf [Consulta: 14 Junio 2012].

ARIAS, M. (S/F). La ingeniera de requerimientos y su importancia en el 13 Junio

desarrollo de proyectos de software [Documento en lnea]. Disponible en:http://www.latindex.ucr.ac.cr/intersedes10/10-art_11.pdf[Consulta: 2012].

CAPA, A Y LUDEA, S.(S/F). Ingeniera de Requisitos.[Documento en

Lnea]. Disponible en: http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-derequisitos.php [Consulta: 13 Junio 2012].

WIEGERS, K. (2003). Software Requirements (Second Edition). Microsoft

Press: Washington D.C.