Ing de req
- 1. Gestiónde Requisitos Enviado por Dayra Iris Hechavarría Rodríguez 1. Introducción 2. ¿Qué es un requerimiento/requisito? 3. Tipos de requisitos 4. Clasificación de los requisitos no funcionales 5. ¿Qué se entiende por Ingeniería de Requisitos (IR)? 6. Actividades de la Ingeniería de Requerimientos 7. Personal involucrado en la Ingeniería de Requerimientos 8. Análisis comparativo de las técnicas de Ingeniería de Requerimientos 9. Importancia de la Ingeniería de Requerimientos 10. Gestión de Requisitos. Principales características 11. Las Herramientas de Gestión de Requisitos 12. Conclusiones 13. Referencias Bibliografías Resumen La Gestión de Requisitos, es el proceso encargado de la identificación, asignación, verificación, y modificaciónde los requisitos a lo largo del ciclo de vida del software. Además es considerada como uno de los procesosmás importantes dentro de la Ingeniería de Requisitos. Con una buena Gestión de Requisitosse logra crear software de buen rendimiento que satisface realmente las necesidades del usuario. En este trabajo se abordan los aspectosteóricosnecesariossobre la Gestión de Requisitos, las características más importantes de la misma y las herramientas más utilizadas para su realización. Se hace referenciaa las ventajas y desventajas de la Reutilización de Requisitos como una buena alternativapara la reduccióndel tiempo del trabajo de los proyectos. Palabras claves:Gestión de Requisitos, Ingeniería de Requisitos. Introducción En la actualidad en la Industria de Software existe una tendencia al crecimiento del volumen y complejidad de los productos, y se exige mayor calidad y productividad en menos tiempo. El proceso de desarrollo de software se encarga de traducir las necesidades del usuario en requerimientosde software (Richard , 1997). Estos requerimientos transformadosen diseño y el diseño implementado en código, el código es probado, documentado y certificado parasu uso operativo. La Ingeniería de Software, se considera la rama de la ingeniería que aplica los principios de la ciencia de la computacióny las matemáticas para lograrsolucionescosto-efectivasalos problemas de desarrollo de software, es decir, permite elaborar consistentemente productoscorrectos, utilizablesy costos-efectivos. Lamisma requiere llevar a cabo variastareas, una de ellas es el análisis de requisitos. El análisis de requisitospermite extraer los requisitosde un producto de software. La Ingeniería de Software es una tecnología que indica "CÓMO" construir técnicamente un software: económico, fiable y que funcione eficientemente. (Jacobson, 2000)(Booch;2000 ) . La ingeniería de requisitoses una disciplina de la Ingeniería de software. Esta disciplina consideradiferentes líneas de trabajo, pero una de las más importanteses la gestión de requisitos, la cual se encarga de proveer la direccióny alcance del proyecto. Losrequisitos deben ser la base de cualquier desarrollo de software. La obtenciónde una especificaciónde requisitosde alta calidad es fundamental para asegurar que el software se corresponde con
- 2. las necesidades del cliente. En el análisis de requisitosse investigala parte del mundo real (también llamado universo de discurso o minimundo) que se vaa modelar para tener en cuenta todas las necesidades de los usuarios finales y así dejarlas documentadas de la forma más completaposible. Desarrollo ¿Qué es un requerimiento/requisito? Normalmente, un tema de la Ingeniería de Software tiene diferentessignificados. De las muchas definiciones que existenpara requerimiento, a continuaciónse presenta la definición que aparece en el glosario de la IEEE. (Richard,1997). (1) Una condicióno necesidad de un usuario para resolver un problemao alcanzar un objetivo. (2)Una condicióno capacidadque debe estar presente en un sistema o componentesde sistema para satisfacer un contrato, estándar, especificaciónuotro documento formal. (3) Una representacióndocumentada de una condicióno capacidad como en (1) o (2). (Richard , 1997) Características de los requerimientos Los requerimientos deben especificarse antesde intentar comenzar la construccióndel producto, sin ellos no podrá ser posible llevar a cabo las etapas de diseño y construcción correctamente. Losmismos pueden verse como una declaraciónabstractade alto nivelde un servicio que el sistema debe proporcionar, como una definición matemática detallada y formal. Los requisitoscumplen una doble funciónya que son la base para una ofertade contrato, por lo tanto deben estar abiertosa la interpretación. Además son la base para redactar el contrato en sí mismo. Los requisitos una vezestablecidosy documentados, sufren cambios continuos, en este sentido, no se trata la obtenciónni el análisis de los mismos, se trata de su gestión, es decir, el seguimiento respecto alos cambios que se generan durante el ciclo de vida del proyecto y las herramientas de gestión de requisitos que auxilian y/o automatizan estas tareas. El uso de herramientas para auxiliar la gestión de requisitosse ha convertido enun aspecto importante de la Ingeniería de Sistemas y el diseño. Considerando el tamaño y la complejidad del desarrollo, las herramientas vienen siendo algo esencial. Las herramientas que los gestoresde requisitosutilizan para automatizar los procesosde Ingeniería de Requisitos han disminuido el trabajoduro en el mantenimiento de requisitos, añadiendo beneficiossignificativosal reducir errores. (Loucopoulos, 1995). Las característicasde un requerimiento son sus propiedadesprincipales. Un conjunto de requerimientosen estado de madurez, deben presentar una serie de característicastanto individualmente como en grupo. A continuaciónse presentan las más importantes. Necesario: Un requerimiento es necesario si su omisión provocaunadeficienciaen el sistema a construir, y además su capacidad, característicasfísicaso factor de calidad no pueden ser reemplazados por otras capacidadesdel producto o del proceso. Conciso: Un requerimiento es conciso si es fácilde leer y entender. Su redaccióndebe ser simple y clara para aquellosque vayana consultarlo en un futuro. Completo:Un requerimiento está completo si no necesitaampliar detalles en su redacción, es decir, si se proporcionala información suficiente para su comprensión. Consistente:Un requerimiento es consistente si no es contradictorio conotro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusionesal lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación, inspección, demostración o pruebas.
- 3. Tipos de requisitos Los requerimientos pueden dividirse en variostipos dentro de ellos, se hará referenciaa los siguientes: Requisitos de usuario Requisitos del sistema Requisitos funcionales Requisitos no funcionales Requisitos de usuario Declaracionesen lenguaje natural y en diversos diagramas de los serviciosdelsistema y de las restriccionesbajo las que debe operar. 1.-El sistema debe permitir representar y acceder a archivosexternoscreadospor otras herramientas. 2. Sentencias muy generales sobre lo que el sistema debería hacer. Requisitos del sistema Un documento estructurado que determina las descripcionesdetalladas de los serviciosde sistema. Escrito como contrato entre el cliente y el contratista. 1.-El usuario deberá poder definir el tipo de un nuevo archivo externo. 2.- Cada tipo de archivo tendráuna herramienta asociada, que se le aplicará. 3.- Cada tipo de archivo se representaráconun icono específico. 4.-El usuario deberápoder definir el icono que representa un tipo de archivo externo. 5.- Cuando el usuario seleccionaun icono que representaun archivo externo, elefecto es aplicar la herramienta asociada con este tipo de archivo al archivo representado por el icono seleccionado. Requisitos funcionales Declaraciónde los serviciosque el sistema debe proporcionar, cómo debe reaccionar a una entrada particular y cómo se debe comportar ante situacionesparticulares. Describen la funcionalidad del sistema, y dependen del tipo de software, del sistema a desarrollar y de los usuarios del mismo. Por lo general se describen mejor a travésdel modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los requerimientos funcionalesespecificanel comportamiento de entrada y salida del sistema y surgen de la razón fundamental de la existenciadel producto. Requisitos no funcionales Los requerimientos no funcionalesson propiedadeso cualidades que el producto debe tener. Restriccionesque afectana los servicioso funciones del sistema, tales como restriccionesde tiempo, sobre el proceso de desarrollo, estándares, etc. Los requerimientos no funcionalestienen que ver concaracterísticasque de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfacesde usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, etc. Algunas propiedadesde los requerimientosno funcionalesque hacen al producto atractivo, usable, rápido o confiable, son las siguientes: Clasificación de los requisitos no funcionales Requisitos del producto: Especificanel comportamiento del producto obtenido, velocidadde ejecución, memoriarequerida, y porcentaje de fallos aceptables.
- 4. Requisitos organizacionales: Son una consecuenciade las políticas y procedimientos existentesen la organización, procesosestándar utilizados, de fechasde entrega, y documentacióna entregar. Requisitos externos: Presentan factoresexternosalsistema y a su proceso de desarrollo, interoperabilidaddel sistema con otros, requisitos, legales, y éticos. Requerimientos de apariencia o interfaz externa Ejemplo: Muy legible, Simple de usar, Profesionalo tipo ejecutivo. Requerimientos de Usabilidad Ejemplo: Facilidad de uso por personas que hablen otrosidiomas distintos al del país donde el producto fue creado, Accesibilidadpara personas discapacitadas, Consistencia en la interfaz de usuario, Documentaciónde usuario. Requerimientos de Rendimiento Ejemplo: Velocidadde procesamiento o cálculo, Eficiencia, Disponibilidad, Tiempo de respuesta. Requerimientos de Soporte Ejemplo: Adaptabilidad, Mantenimiento. Requerimientos de PortabilidadEjemplo: El producto podrá ser usado bajo el sistema operativo Linux . Requerimientos de Seguridad Confidencialidad: La informaciónmanejada por el sistema está protegidade acceso no autorizado y divulgación. Integridad: la informaciónmanejada por el sistema será objeto de cuidadosaprotección contrala corrupcióny estadosinconsistentes. Disponibilidad: Significa que los usuarios autorizadosse les garantizará el acceso a la informacióny que los dispositivoso mecanismos utilizados para lograr la seguridad no ocultaráno retrasarán a los usuarios para obtener los datos deseadosen un momento dado. Requerimientos de confiabilidad :Frecuenciay severidadde los fallos, Protección contrafallos, Recuperación, Predicciónde fallos, Tiempo medio entre fallos. Requerimientos de Software: Ejemplo: Sistema Operativo Windows 95 o Superior; Maquina Virtualde Java versión1.3 o Superior;etc. Requerimientos de Hardware: Ejemplo: se requiere disponer de un MODEM estándar o una tarjetadigitalizadora de video, etc. A pesar de las diferentes característicasque nos brindan los requerimientos, existen dificultadespara recolectar losrequisitos, las cuales no nos permiten elegir los requerimientoscon la calidad necesaria; ya que estospueden relacionarse unos conotrosy a su vezcon otraspartes del proceso. Pero aun así, se plantea que sin el levantamiento de requisitosno se podrían desarrollar procesosque son de vitalimportancia para el desarrollo del software. Los requisitosconstituyenel enlace entre las necesidadesreales de los clientes, usuarios y otrosparticipantesvinculadosal sistema. ¿Qué se entiende por Ingeniería de Requisitos (IR)? La Ingeniería de Requisitos es definida como: La disciplina de la Ingeniería de Software que trata con actividadesy intenta comprender las necesidades exactasde los usuarios del sistema software, para traducir tales necesidades en instruccionesprecisas y no ambiguas las cuales podrían ser posteriormente utilizadas en el desarrollo del sistema. ( Loucopoulos,1995). Ingeniería de Requerimientos es el proceso en el cual se transforman los requerimientos declaradospor los clientes, ya sean hablados o escritos, a especificacionesprecisas, no ambiguas, consistentesy completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones. Es el proceso mediante el cual se intercambian diferentespuntos de vistapara recopilar y modelar lo que el sistema vaa realizar. (Richard, 1997). Ingeniería de Requisitos (IR). Sus Características
- 5. La Ingeniería de Requisitos en una disciplina de la Ingeniería de Software, en ésta, se identifica el propósito del sistema, direccióny alcance. Abarcaun conjunto de actividadesy transformacionesque pretenden comprender las necesidades de un sistema software y convertir ladeclaraciónde estas necesidades en una descripcióncompleta, precisay documentada siguiendo un determinado estándar. La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producciónde software, yaque enfocaun área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificacionescorrectas que describan conclaridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionadosal desarrollo de sistemas. El proceso de Ingeniería de Requisitos tiene como objetivos, descubrir, modelar, validar y mantener un documento de requisitos, utilizando una combinación de métodos, herramientas y actores. Actividades de la Ingeniería de Requerimientos Las actividadesde la Ingeniería de Requisitosmás comunes son: Estudio de Viabilidad Elicitación de Requisitos Análisis de Requisitos Especificación de Requisitos(ERS) Validación de Requisitos Gestión de Requisitos Estudio de viabilidad: El estudio de viabilidad permite decidir si el sistema propuesto es conveniente. Es un estudio rápido y orientado a conocer. Ademástiene en cuenta si el sistema contribuye alos objetivosde la organización, si el sistema se puede realizar conla tecnologíaactual y con el tiempo y el coste previsto, y si el sistema puede integrarse con otrosexistentes. Elicitación de requisitos: Elicitación(o extraccióno determinación)de requisitos, es el proceso mediante el cual los usuarios descubren, revelan, articulan y comprendenlos requisitosque desean. En esta etapa, se trata de descubrir los requisitosy personal técnico trabaja con los clientesy usuarios para descubrir el dominio de la aplicación, los servicios que se deben proporcionar y las restricciones. Puede implicar a usuarios finales, encargados, ingenieros implicados en el mantenimiento, expertosdeldominio, etc. Son los llamados participantes (stakeholders). Análisis de requisitos: El proceso de razonamiento sobre los requisitosobtenidos en la etapa anterior, detectando y resolviendo posiblesinconsistenciaso conflictos, coordinando los requisitosrelacionados entre sí, etc. Especificación de Requisitos (ERS):La especificaciónde requisitos de software es la actividaden la cual se genera el documento, con el mismo nombre, que contiene una descripcióncompletade las necesidadesy funcionalidadesdel sistema que será desarrollado;describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientosfuncionales y los no funcionales. En la SRS se definen todos los requerimientosde hardware y software, diagramas, modelos de sistemas y cualquier otra informaciónque sirvade soporte y guía para fases posteriores. Validación de requisitos: El proceso de confirmación, por parte de los usuarios, de que los requisitosespecificadosson válidos, consistentes, y completos. Gestión de Requisitos: Es el proceso de manejar los requisitos que cambian durante el desarrollo del sistema.
- 6. El proceso de Ingeniería de Requisitos se adapta a los diferentesmodelos de procesos de Ingeniería de Software como pueden ser, de cascada, espiral, prototipazo, transformacional, etc. Validación de Requisitos La validaciónes la actividadde la IR que permite demostrar que los requerimientosdefinidos en el sistema son los que realmente quiere el cliente; además revisaque no se haya omitido ninguno, que no sean ambiguos, inconsistenteso redundantes. En este punto es necesario recordar que la ERS debe estar libre de errores, por lo tanto, la validacióngarantiza que todoslos requerimientos presentesen el documento de especificaciónsigan los estándares de calidad. No debe confundirse la actividad de evaluaciónde requerimientoscon la validaciónde requerimientos. La evaluaciónverifica las propiedades de cada requerimiento, mientras que la validaciónrevisael cumplimiento de las característicasde la especificaciónde requisitos. Durante la actividadde validación pueden hacerse preguntas en base a cada una de las característicasque se desean revisar. La validaciónde requerimientoses importante pues de ella depende que no existan elevadoscostosde mantenimiento para el software desarrollado. Personal involucrado en la Ingeniería de Requerimientos Realmente, son muchas las personas involucradasen el desarrollo de los requerimientosde un sistema. Es importante saber que cada una de esas personastienen diversosinteresesy juegan rolesespecíficosdentro de la planificacióndel proyecto;elconocimiento de cada papel desempeñado, asegura que se involucrenalas personas correctasenlas diferentes fases del ciclo de vida, y en las diferentesactividadesde la IR. No conocer estosinteresespuede ocasionar una comunicaciónpoco efectivaentre clientesy desarrolladores, que a la vez traeríaimpactos negativostanto en tiempo como en presupuesto. Los rolesmás importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionadoscon la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesosespecíficosque debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfacesy los manuales de usuario. Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionanal equipo técnico losdetalles y requerimientosde las interfacesdel sistema. Personal de Mantenimiento:Para proyectosque requieranun mantenimiento eventual, estas personas son las responsablesde la administración de cambios, de la implementación y resoluciónde anomalías. Su trabajo consiste en revisar y mejorar los procesosdel producto yafinalizado. Analistas y programadores: Son los responsablesdel desarrollo del producto en sí; ellos interactúan directamente conel cliente. Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebaspara asegurar que las condicionespresentadaspor el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacenlas necesidadesdel cliente. Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, puedenser:administradores de proyecto, documentadores, diseñadoresde base de datos, entre otros. Análisis comparativo de las técnicas de Ingeniería de Requerimientos En la Ingeniería de Requisitosse describen técnicasque permiten la capturarequisitosde software, la recopilaciónde la información y en qué casos es adecuada usar cada cual. A continuaciónse hace un análisis de estas técnicas. (Sommerville, 1997).
- 7. Técnica: Entrevistas. Características. Forma de conversación, no de interrogación. Ocupan un lugar preponderante de acuerdo al tiempo que ocupan y el objetivo que tienen. Mayor fuente de información del analista Basadas en un cuestionario rígido o una guía que las orienta hacia puntos bien definidos. Ventajas Se presenta necesidades de formadirecta y se verificasi las preguntas fueroninterpretadas correctamente. Oportunidad para conocer elgrado de aceptacióno no entre los usuarios hacia el sistema que se desea diseñar. Mediante ellas se obtiene una gran cantidad de información correcta a travésdel usuario. Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten combinarse con otrastécnicas. Desventajas La informaciónobtenida al principio puede ser redundante o incompleta. Si el volumen de informaciónmanejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todoslos involucrados. Realización de las Entrevistas Los pasos: Preparación Ejecución Recapitulación ¿Cómo lograr una entrevista exitosa? Acordar una cita por anticipado con las personas que se entrevistarán. Avisar a los entrevistadossobre la naturaleza de la entrevista. Planear una entrevistacomúnpor no más de una hora. Prepararlaconociendo de antemano a los individuos que se van a entrevistar. Familiarizarse con el tema y preparar un conjunto apropiado de preguntas. Durante la entrevista Presentarse, subrayando el tema y la naturaleza del proyecto. Comenzar con preguntas generales que establezcan el marco de trabajo. Continuar con los temas y aspectosque surjan de quienes responden. Asegurarse de encontrar por qué quienes responden creenque es tan importante el tema como para comentarlo. Cuando todos los temas vistosse hayan discutido, realícense otraspreguntas específicas que se crea deban discutirse. Al finalizar, resumir la informaciónrecabadadurante la misma.
- 8. Si se consideraapropiado, indicar que se preparará un resumen escrito de la entrevista. Considerar la posibilidad de continuar con la entrevistaen otro momento. Técnica: Cuestionarios. Características Permiten obtener informaciónde un gran número de personas en corto tiempo, sin que estas deban estar presentes. Son recomendables cuando: Se requiere una pequeña cantidad de información de un gran número de personasen un corto periodo de tiempo. La informaciónse desea consolidar en tablas estadísticas. Usuarios geográficamente dispersos. ¿Cómo desarrollar un Cuestionario? Determinar qué datosse necesitan y qué personas están calificadaspara proporcionarlos. Seleccionar eltipo de cuestionario (abierto, cerrado). Incluir preguntas redundantes, cuando sea necesario, para verificar consistencia. Examine el cuestionario para detectar errores en preguntas que: Puedan ser mal interpretadas. No se puedan responder. Se interpretarán en forma diferente dependiendo de cada entrevistado. No proporcionanopcionesadecuadasde respuesta. No estén ordenadas adecuadamente. Desventajas Informaciónsuministrada por escrito. Los encuestados pueden objetar preguntas, interpretarlas a su formao no tomarlas en serio. Difíciles de diseñar. Antes de aplicar un Cuestionario: Probarlo en un grupo pequeño para detectar otrosproblemas. Analizar las respuestas de prueba para asegurar que el análisis se pueda llevar a cabo con los datos recopilados. Técnica: Lluvia de Ideas Ventajas Los diferentes puntos de vistay las confusionesen cuento a terminología, son aclaradas por expertos. Ayudaa desarrollar ideas unificadas basadas en la experienciade un experto. Desventaja Es necesariauna buena compenetracióndel grupo participante. Técnica: Prototipos El uso de prototipospara recoger requisitoso comprobar si se han entendido perfectamente es una prácticacada vezmás extendida, especialmente en sistemas que suponen un elevado
- 9. grado de interactividad. En este caso los prototiposa evaluar no serán más que maquetas no operativaso especificacionesformalesque un grupo de expertosdeberánevaluar. Ventajas Ayudana validar y desarrollar nuevosrequerimientos. Permite comprender aquellos requerimientosque no estén muy claros y que son de alta volatilidad. Desventajas El cliente puede llegar a pensar que el prototipo es una versióndel software que será desarrollado. A menudo, el desarrollador hace compromisosde implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo. Técnica: Análisis Jerárquico Ventajas Permite determinar el grado de importancia de cada requerimiento Ayudaa identificar conflictos enlos requerimientos. Muestra el orden en que deben ser implementados los requerimientos Desventaja Debe construirse un estándar claro de evaluación, que incluyala participacióndel cliente. Técnica: Casos de Uso Ventajas Representan los requerimientosdesde el punto de vistadel usuario. Identificarequerimientosestancados, dentro de un conjunto de requerimientos. Desventaja En sistemas grandes, toma mucho tiempo definir todoslos casosde uso. El análisis de calidad depende de la calidad conque se haya hecho la descripcióninicial. Técnica: Estudio Estudio de documentación:Enesta técnica se estudia documentacióno estándares que puedan informar sobre las actividadesde las tareasa realizar, puesto que en muchas ocasionesalgunos procedimientosyaestán sujetos a algún tipo de regulación que es preciso tener en cuenta. Estudio de la literatura: Otra valiosa fuente de información, especialmente adecuada si el equipo de desarrollo no tiene mucha experienciaenel dominio de aplicacióndel producto, esbuscar en la literatura ejemplos de productossimilares. En base a las ventajas y desventajas mostradas anteriormente, se hace una comparaciónentre algunas de las técnicas. Entrevistas vs. Casos de Uso: Un alto porcentaje de la informaciónrecolectadadurante una entrevista, puede ser usada para construir casos de uso. Mediante esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los involucrados. Cuando el analista sienta que tiene dificultades para entender una tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles recabadosen un caso de uso. De hecho, durante las entrevistascualquier usuario puede utilizar diagramas de casosde uso para explicar su entorno de trabajo. Entrevistas vs. Lluvia de Ideas: Muchas de las ideas planteadas en el grupo, provienen de informaciónrecopilada en entrevistaso cuestionariosprevios. Realmente la lluvia de
- 10. ideas trata de encontrar las dificultadesque existen para la comprensión de términos y conceptospor parte de los participantes; de esta forma se llega a un consenso. Casos de Uso vs. Lluvia de Ideas: La lista de ideas proveniente del brainstormpuede ser representadagráficamente mediante casos de uso. Las Técnicasde la Ingeniería de Requisitos son de gran importancia, nos permiten conocer lasdiferentesalternativas que existenpara identificar requerimientos. Importancia de la Ingeniería de Requerimientos Los principales beneficiosque se obtienen de la Ingeniería de Requerimientosson Permite gestionar las necesidades del proyecto en forma estructurada:Cada actividadde 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 proporcionaun punto de partida para controlessubsecuentesy actividadesde mantenimiento, tales como estimación de costos, tiempo y recursosnecesarios. Disminuye los costos y retrasos del proyecto:Muchos estudios han demostrado que reparar errorespor un mal desarrollo no descubierto a tiempo, es sumamente caro. Mejora la comunicación entre equipos:La especificaciónde requerimientos representauna forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no seráexitoso. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos(funcionalidad, facilidadde uso, confiabilidad, desempeño, etc.). Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientoscuidadosamente y revisarlosdentro del marco del problema, por lo que se le involucradurante todo el desarrollo del proyecto. Gestión de Requisitos. Principalescaracterísticas La Gestión de Requisitos es un componente vitalen el desarrollo de un proyecto softwareya que es una de las actividadesde la Ingeniería de Requisitos más importantes. Los requisitos se inician cuando empieza un proyecto enlas etapas de análisis y especificaciónde requisitos, posteriormente, dichosrequisitos en el ciclo de vida de un proyecto puedenser modificadospor lo que se establece el concepto de Gestión de Requisitos, que es el tratamiento ycontrol de las actualizacionesy cambiosa los mismos. Debido a que un proyecto informático essusceptible de cambios, habría que proceder a su actualizacióno a la incorporaciónde nuevasfuncionalidades o eliminar otras, esto obliga a mantener controlado y documentado el producto. Los cambiosde requisitosdeben ser gestionados para asegurar que la calidad de los mismos se mantenga, los problemas suscitadospor los cambios de requisitospodrían incurrir en altos costos, siendo el requisito factor crítico de riesgo. Más formalmente el Manejo de Requisitos es una formasistemática de descubrir, organizar y documentar los requisitosdel sistema. Además es el proceso que establece y mantiene un consenso entre el cliente y el grupo del proyecto enel cambio de los requisitos del sistema. El término Gestión de Requisitosincluye: TécnicasparaDescubrimiento/Recogidade Requisitos Recoger las peticionesdel usuario y determinar las verdaderasnecesidades de éste. Técnicasde Análisis Especificacióny verificación
- 11. Manejo de Requisitos Tareas principales de la Gestión de Requisitos. Durante el proceso de la gestión de requisitos, hay que planear algunas actividades, dentro de las que se pueden mencionar las siguientes: la identificaciónde los requisitos, en proceso de gestión de los cambios, las políticas de trazabilidad, la cantidad de informaciónsobre las relacionesentre los requisitosque se mantiene, entre otras. Actividades y su descripción: Recolección: Recoleccióny documentaciónde requisitoses una actividad de comunicacióniterativaentre clientes, gerentesy practicantes, para descubrir, definir, refinar y registrar una representaciónprecisade los requisitosdel producto. Varios métodos son utilizados para la recolecciónde requisitos. Algunosanálisis iniciales como es la agrupación, categorización, priorizaciónson desarrolladosdurante esta actividad. Documentación: Despuésque los requisitos han sido recolectados, hay que analizarlos a detalle y documentarlosen una especificaciónde requisitos. El resultado de la especificaciónde requisitosy de cualquier especificaciónde requisitos de componentes hardware/software derivado sirve como registro de convenio conel cliente y compromiso con el proveedor. Estasespecificacionessonrastreadasutilizando una matriz de trazabilidad de requerimientosy son sujetosa verificacióny gestiónde cambio a travésdel ciclo de vidadel producto. Verificación: Una vezque la especificaciónde requisitosha sido desarrollada, los requisitosson verificados. Laverificaciónde requisitoses un proceso para asegurar que la especificaciónde requisito del producto esuna representaciónexactade las necesidades del cliente. Este proceso también asegura que los requisitossean trazados y verificadosatravés de varias fasesdel ciclo de vida;particularmente en el diseño, implementación y pruebas. Además, todosestos requerimientosdeben ser trazados al diseño, implementación y pruebas para asegurarse que los requerimientoshan sido satisfechos. Gestión de Cambios: Gestión de cambios es un proceso formalpara identificar, evaluar, trazar y reportar cambios propuestosy aprobadosa la especificacióndelproducto. Como el proyecto vaevolucionando, losrequerimientospueden cambiar o expandirse para ajustar algunas modificacionesen el alcance o diseño del proyecto. Unproceso de gestión de cambios proporcionaun rastreo completo y preciso de todoslos cambios que son pertinentes al proyecto. Elproceso delciclo de vida de la Gestión de Requisitos, debe ser flexible y adaptable para reunir las necesidadesdel proyecto. Lascaracterísticasdelalcance e implementación del proceso delciclo de vida de la Gestión de Requisitosen un proyecto, variarádependiendo de algunos factoresclaves. Tamaño y complejidaddel proyecto Experienciadel personal del proyecto Experienciade los clientes del proyecto Dominio de la aplicación El propósito y uso de esta aplicación Las Herramientas de Gestión de Requisitos El uso de herramientas de la gestión de requisitoses alentado para mejorar tanto la productividadcomo la calidad en el desarrollo de un proyecto software. Existenvarias herramientas tanto hechas en casacomo en el mercado que auxilian a las tareasde gestión. Rational RequisitePro, es una herramienta centradaen documentos, que almacena los requisitosasociándolos a documentos(aunque también permite guardarlos directamente en la base de datos), mientras que las otras herramientas están orientadas a requisitos. Se auxilia especialmente en el controlde cambio de requisitos, contrazabilidad para especificacionesde software y pruebas. La herramienta permite el uso
- 12. de Oracle sobre Unix o Windows y también soporta SQL Server sobre Windows. Beneficios de RequisitePro Permite el trabajo en equipo por medio de un repositorio compartido de información. Permite la clasificaciónde requerimientos, en base a las necesidades de cada empresa. Define atributos para todoslos tipos de requerimientosespecificados. Ayudaa manipular el alcance del proyecto mediante la asignación de prioridadde desarrollo a cada uno de los requerimientosplanteados. Permite característicasavanzadasde rastreo, por medio de matrices, que permiten visualizar las dependencias entre requerimientosdentro de un proyecto o endiferentes proyectos. Administración de cambiosmediante el rastreo y la visualizaciónhistórica de los cambios efectuadosal requerimiento, cuándo y quién los realizó. Interactúaconlos demás productosRational para el ciclo de vida, así como con herramientas de Microsoft Office. Ayudaa determinar en formaautomatizada cuántos requerimientostiene el proyecto. Ayudaa determinar responsables y actoresen cada uno de los requerimientos. RequisitePro, permite organizar los requerimientos, establecer y mantener relaciones padre/hijo entre ellos. El uso de una herramienta de gestión de requisitos proporcionaalproyecto: Ahorro en costesde especificacióny de desarrollo minimizando el impacto de errores. Mejora la calidad mediante un adecuado análisis y gestión de los requisitos. Reduce las no-conformidadesdel sistema. Permite controlar la especificación. Permite administrar más fácilmente la especificación. Ayudaa cumplir con estándares de calidad. Permite centralizar toda la información del problema. Proporcionauna trazabilidad completade la especificación, etc. Otras Herramientas de la Gestión de Requisitos en el Mercado Las herramientas seleccionadasproporcionancasi todas las necesidades básicas exigibles. Además, estas herramientas están ampliamente difundidas y son muy reconocidas. Todas las herramientas asumen que la estructurade los requisitos es jerárquica, de forma que un requisito puede estar formado o tener asociadosotros requisitosde nivel inferior, y la mayoríapermite extraer párrafosde ficherosgeneradospor procesadoresde texto comercialesy convertirlosenrequisitos. Otras de las característicascomunesa la mayor parte de las herramientas es la posibilidad de realizar consultas sobre los requisitos en función de determinados valoresde sus atributos. Estas herramientas son: IRqA 3.0, CaliberRM y DOORS IRqA 3.0 es una herramienta de ingeniería de requisitos especialmente diseñada para soportar el proceso completo de ingeniería de requisitos. En IRqA el ciclo de especificacióncompleto incluye lacapturade requisitos, análisis, especificaciónde sistema, validacióny la organización de requisitoses soportadapor modelos estándares. ( Lan A, 1994). CaliberRM es para sistemas grandes y complejosy proporcionauna base de datos de requisitoscon trazabilidad. Se ve a los requisitoscomo parte del proceso al igual de gestión de la calidad del software, las pruebas (testing) y el trazado de defectos(defect tracking). Caliber está basado en internet y maneja referenciade documentos, responsabilidad de usuario, trazabilidad, prioridad y estado entre otrascaracterísticas.
- 13. DOORS a diferenciadel resto de las herramientas, consideralos requisitos como objetosy los documentoscomo módulos. Tiene una orientaciónbasada en objetos, frente a RequisitePro y Caliber-RM, que manejan solamente requisitosy sus atributos. Es una herramienta para organizacionesgrandes que necesitan controlar complejos conjuntos de usuarios y requisitos de sistemas conuna completatrazabilidad. Proporcionabuena visualizaciónde tales documentoscomo jerárquicas, y su lenguaje de extensión permite una gran variedadde soporte de herramientas a ser construidas. Conclusiones Con este documento dejamos claro la importancia que tiene el conocimiento de la Ingeniería de Requerimiento y conella la Gestión de Requisitos .Sin dejar de mencionar que el resultado satisfactorio depende de una intensa comunicaciónentre clientes y analistas de requerimientos. La Ingeniería se encarga de establecer y mantener un acuerdo en qué el sistema debe hacer, demás proporcionaal equipo de desarrollo un entendimiento de los requisitos, hasta definir los límites del sistema. Referencias Bibliografías (Anaya, 2002) Anaya, V., Letelier, P., SmarTTrace:UnaHerramienta para Trazabilidadde Requisitos en Proyectosbasadosen UML, Proceedingsof the V Workshopon Requirements Engineering, pp. 210-224, Valencia, España, Noviembre 2002. (Booch, 2000)Booch, Grady Rombaugh ,james y Jacobson, Ivar (2002.Ellenguaje Unificado de modelado España: AdysonWesley)432 p. (Booch, 2002) Grady Booch. Growing the UML. Software and SystemModeling, (2002). (Charette, 1989)Charette, R. N.: Software Engineering Risk Analysisand Management, McGraw–Hill/Intertext, 1989. (Finkelstein, 2000) Anthony Finkelstein & Wolfgang Emmerich (University College London, Dept. Computer Science.)Paper "The Future of Requirement Management Tools" (Lan A., 1994)RequirementsEngineering ToolVendorsand Freeware Suppliers, 1994. (Loucopoulos, 1995)Karakostas, V. (1995);SystemRequirements Engineering McGraw- Hill, 1995. , Loucopoulos. (Pressman, 2002) Pressman, Roger S.: Ingeniería de Software. Un enfoque práctico. Quinta edición. McGraw-Hill. Madrid. 2002. (Ramesh, 2001)B. Ramesh and M. Jarke. TowardReference Modelsfor Requirements Traceability.IEEETransactionsonSoftware Engineering, Vol. 27, No. 1, pp.58-93, January 2001. (Richard , 1997)IEEE Software Requirement Engineering, SecondEdition. Thay er y Merlin Dorfman, IEEE Computing Society, NewYork, NY. 1997. (Sommerville, 1997)RequerimentesEngineering: A Good Practice Guide. Johm Wiley and Sons, 1997. Autor: Msc. Dayra Iris Hechavarría Rodríguez La Habana, 2012