Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979.

"Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software

Importancia de la Ingeniería de RequerimientosLos principales beneficios que se obtienen de la Ingeniería de Requerimientos 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 estimación de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.

Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

Mejora la comunicación entre equipos: La especificación 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 ingeniería 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.

Personal involucrado en la Ingeniería de Requerimientos

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas

correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.

Validación de Requisitos

La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:

¿Están incluidas todas las funciones requeridas por el cliente? (completa) ¿Existen conflictos en los requerimientos? (consistencia) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Está cada requerimiento claramente representado? (entendible) ¿Pueden los requerimientos ser implementados con la tecnología y el

presupuesto disponible? (factible) ¿Está la SRS escrita en un lenguaje apropiado? (clara) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) ¿Está claramente definido el origen de cada requisito? (rastreable) ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

INTRODUCCION La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema realmente operacional. Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.

El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: identificación de requisitos, Análisis de requisitos y negociación, Especificación de requisitos, Modelado del sistema, Validación y gestión de requisitos. El propósito de la siguiente producción escrita, es desarrollar más a fondo aspectos que tienen como objetivo primordial finiquitar los detalles finales para el acabado de un sistema software previamente modelado, la inspección, validación, completitud,

detección de conflictos, inconsistencia de requerimientos, así como también la determinación de requerimientos, creación e importancia, Finalizando Así con las métricas para la ingeniería de requisitos.

1-INSPECCIÓN Según Presuman, en su libro “Ingeniería de Software, un enfoque practico” (1998)”

“La inspección también es conocida como revisión técnica formal, y es el punto de vista mas efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los ingenieros de software u otras personas. Para los ingenieros la inspección es un medio efectivo para descubrir errores y mejorar la calidad del software” (p.165)

Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad. La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software

La calidad de un producto de software terminado debe enlazar los siguientes elementos a) “Un enfoque de gestión de calidad”.b) Tecnología de Ingeniería de Software efectiva (métodos y herramientas).c) Revisiones técnicas formales que se aplican durante el proceso del softwared) Una estrategia de prueba multiescalada.e) Un control de la documentación del software y de los cambios realizados.f) Un procedimiento que asegure un ajuste a los estándares de desarrollo de software.g) Mecanismos de medición y de generación de informes

2-VALIDACION La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se evalúa durante el proceso de validación. La validación de requisitos examina la especificación, para asegurar que todos los requisitos de software se han establecido de manera precisa, que se han detectado las inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto. De igual manera Presuman (1998) acota que “La prueba del software es un elemento de un temas mas amplio que suele denominarse verificación y validación” (p.172)

La verificación: Es el conjunto de actividades que asegura que el software implemente correctamente una función especifica. La Validación: Es el conjunto de actividades que aseguran que el software construido corresponde con los requisitos del cliente.

En el proceso de obtención de los requisitos de un sistema de software, la validación constituye una de las tareas más complejas, ya que en muchos casos, se requiere que los clientes-usuarios posean conocimientos y habilidades específicas para poder comprender los modelos resultantes de la Ilicitación y especificación de los requisitos

La Validación de requisitos permite:a) Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere.

b) Los costos de errores en los requerimientos son altos, por lo cual, la validación es muy importante.c) Fijar un error de requerimiento después del desarrollo puede resultar en un costo 100 veces mayor que fijar un error en la implementación.d) El Prototipado es una técnica importante de la validación de requerimientos.

3-COMPLETITUD Galves (2006), al referirse a completitud dice “Es cuando La funcionalidad del sistema satisface todos los requisitos, es decir se hizo lo que el cliente pidió”.

Completitud: Significa que no hay omisiones que comprometan la integridad de los requisitos o No faltan requisitos (propiedad global) No faltan detalles en la especificación de cada requisito (propiedad individual) Es una propiedad difícil de determinar (tan sólo podemos alcanzar una aproximación) Contrastar con el cliente o Comparar con proyectos semejantes. Buscar la visión de conjunto, detectar huecos o partes infra-especificadas Una manera de comprobarlo: para cada requisito, comprobar que están presentes los demás requisitos relacionados La buena organización facilita la detección de faltas o Ejemplo: organización por tipos de requisitos

La IR provee métodos, técnicas y herramientas que ayudan a los ingenieros de requisitos a elicitar y especificar requisitos, asegurando el máximo de calidad y completitud. Sin embargo, el problema de la completitud es una amenaza constante a la calidad de los requisitos y cubre todo el proceso de IR con un gran manto de duda. La completitud es una meta inalcanzable y estimar el grado de completitud logrado en cualquier momento del proyecto es muy difícil. El ingeniero de requisitos se enfrenta con un Universo de Discurso que nunca parece terminar de conocer. Esta situación no es única en el proceso global de desarrollo de software ya que por ejemplo durante las pruebas o durante las inspecciones de software ocurre algo muy similar. El problema de la completitud en la Ingeniería de Software y en la Ingeniería de Requisitos en particular es similar a muchos otros problemas en otras áreas del conocimiento.

4-DETECCION DE CONFLICTOS E INCONSISTENCIA DE REQUERIMIENTOS. Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios. Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que se versión es “esencial por necesidades especiales”. El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus

requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el costo del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.

Razones de inconsistencia Los sistemas de software grandes deben mejorar su actual situación. Es difícil anticipar los efectos que el sistema tendrá en la organización. Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente compromiso de cambios en los requerimientos. Los usuarios finales del sistema y la organización que paga por el sistema tienen requerimientos diferentes. El prototipado es requerido para clarificar requerimientos

5-DOCUMENTO DE REQUERIMIENTOS, CREACION E IMPORTANCIA El documento de requerimientos del software (algunas veces denominado especificación de requerimientos del software o SRS) es la declaración oficial de que deben implementar los desarrolladores del sistema. Debe incluir tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se pueden integrar en una única descripción. En otros, los requerimientos del usuario se definen en una introducción a la especificación de los requerimientos del sistema. Si existe un gran numero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar en un documento separado. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organización que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software. La diversidad de posibles usuarios significa que el documento de requerimientos tiene que presentar un equilibrio entre la comunicación de los requerimientos a los clientes, la definición de los requerimientos en el detalle exacto para los desarrolladores y probadores, y la inclusión de información sobre la posible evolución del sistema. La información sobre cambios previstos puede ayudar a los diseñadores del sistema a evitar decisiones de diseño restrictivas y a los ingenieros encargados del mantenimiento del sistema, quienes tienen que adaptar el sistema a los nuevos requerimientos. El nivel de detalle que debe incluir en documentos de requerimientos depende del tipo de sistema que de desarrolle y del proceso de desarrollo utilizado. Cuando el sistema se desarrolle por un contratista externo, las especificaciones de los sistemas críticos necesitan ser claras y muy detalladas. Cuando haya mas flexibilidad en los requerimientos y cuando se utilice un proceso de desarrollo iterativo dentro de la empresa, el documento de requerimientos puede ser mucho menos detallado y cualquier ambigüedad resuelta durante el desarrollo del sistema. Creación e importancia La importancia de una buena documentación de requisitos radica en que es el único lugar donde se describe la naturaleza exacta del sistema o de la aplicación. Desde el punto de vista del cliente le permite una forma de plasmar en papel de una forma clara, correcta y concisa que es lo que desea por parte del equipo de desarrollo y que no haya problemas de entendimiento.

Desde el punto de vista del analista le permite una seguridad al tener un documento escritos con un conjunto de requisitos que delimitan su acción y por tanto le da una cierta seguridad sobre la aceptación final del software desarrollado Desde el punto de vista del desarrollador le permite una interpretación clara de lo que se requiere de el, sin caer en problemas de interpretación ni en tener que divagar sobre el modo de realización de las diversas funcionalidades. En estos tres puntos reside fundamentalmente el éxito o fracaso de un proyecto de software, la parte inicial y la mas importante es clarificar entre estos tres grupos que es lo que queremos hacer y como queremos que se haga.

6-METRICAS UTILIZADAS EN LA INGENIERÍA DE REQUISITOS.

Galves (2006), refleja varias métricas utilizadas por los ingenieros de sistemas en el proceso de creación de software entre ellas están:

A-) Comienzo del Proyecto de Software. Antes de empezar a planificar un proyecto el desarrollador y el cliente deben ponerse de acuerdo para definir el ámbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar como se llegara a ellos. El ámbito identifica las funciones primordiales del Software y más importante aún, intenta limitar esas funciones de manera cuantitativa.

B-) Medición y métricas. Las mediciones y las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. Frecuentemente en la medición surgen las siguientes interrogantes: ¿Cuáles son las métricas apropiadas para el proceso y para el producto? ¿Cómo se deben utilizar los datos que se recopilan? ¿Es bueno usar medidas para comparar gente, procesos o productos? entre otras.

C-) Estimación. La Planificación es una de las actividades del proceso de Gestión de Proyectos de Software. Cuando se planifica un proyecto de Software se tiene que obtener estimaciones: del esfuerzo humano requerido (personas-mes), de la duración cronológica del proyecto (en fechas) y del costo (dólares).

Las muchas técnicas del desarrollo del software tienen en común lo siguiente: Se ha de establecer de antemano el ámbito del proyecto como base para la realización de estimaciones se usan las métricas del software (mediciones del pasado). El proyecto se desglosa en partes más pequeñas que se estiman individualmente. D-) Análisis de Riesgos El análisis de riesgo es algo vital para una buena gestión del proyecto de software y, sin embargo, a pesar de todo, se emprenden muchos proyectos sin que se hayan considerado los riesgos concretos. El análisis de riesgo consiste realmente en una serie de pasos de control de los riesgos tales como:

Identificación de riesgos Solución de riesgos Supervisión de riesgos, etc. Planificación Temporal

La planificación de un proyecto de software no difiere de la planificación de cualquier proyecto de ingeniería por consiguiente: Se identifica una serie de tareas del proyecto Se establecen interdependencias entre las tareas Se estima el esfuerzo asociado con cada tarea Se hace la asignación de personal y de otros recursos Se crea una “red de tareas” Se desarrolla una agenda de fechas.

E-) Seguimiento y Control Si una tarea se sale de la agenda el gestor puede utilizar una herramienta de planificación automática sobre el proyecto para determinar el impacto del error de planificación sobre los hitos intermedios y sobre la fecha final de entrega. De manera que se pueden reasignar los recursos, reordenar las tareas o (como último recurso) modificar los compromisos de entrega para resolver el problema no detectado. De este modo se puede controlar mejor el desarrollo del software

CONCLUSIÓN La ingeniería de requerimientos asume un importante papel en el modelado de un Sistema Informático, en cada una de las etapas del transcurso de la creación del software , unos de los proceso mas importante en el desarrollo, cuenta con actividades claves llamadas “inspecciones” o lo que es lo mismo cerciorarnos o asegurarnos de que se está realizando bien el trabajo , la validación por ejemplo es parte indispensable del proyecto pues consiste en asegurar que el equipo de desarrollo entiende adecuadamente las necesidades del usuario para así desarrollar un sistema que cumpla con sus expectativas. La Completitud refleja que el requerimiento debe estar completamente declarado en un único lugar, sin información faltante y que además debe cumplir con la necesidad declarada por los interesados en el sistema/software. De igual manera el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación, por lo tanto debe estar concisamente declarado, para evitar inconsistencias, debe expresar hechos objetivos, no opiniones subjetivas y poder ser interpretado de una única manera, sin ambigüedades.

REFERENCIAS BIBLIOGRAFICASGÓMEZ, J. P. (2006). Resumen: 4 capítulos de ingeniería de requerimientos. [Documento en línea] Disponible:http://www.monografias.com/trabajos-pdf4/traduccion-4-capitulo-del-libro-requeriments-handbook/traduccion-4-capitulo-del-libro-requeriments-handbook.pdf. [Consulta: 2011 Marzo 01]

Gálvez , J. Módulo No. 1 ingeniería de software .Edic. 3.0[Documento en línea] Disponible: http://inteccolombia.org/PDF/ing%20de%20sistemas/i.s1.pdf [Consulta: 2011 Marzo 01]

PRESSMAN, Roger S. 2006, “Ingeniería del Software: Un enfoque práctico”, Sexta edición, MéxicoDF, Editorial McGraw Hill.MENDOZA, G (2005) Procesos de la Ingeniería de Requerimientos. 6ta edic. Documento en línea] Disponible http://www.mena.com.mx/gonzalo/maestria/ingreq/presenta/procesos_ir/ [Consulta: 2011 Marzo 01]

Wikipedia “La Enciclopedia Libre”.Requerimientos “Sistemas”. [Documento en línea] Disponible: http://es.wikipedia.org/wiki/Requerimiento_(sistemas) [Consulta: 2011 Marzo 01]