1.

- PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS

Qu son Requerimientos? Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE . (1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2). Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con 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, etc. Caractersticas de los requerimientos Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Ingeniera de Requerimientos vs. Administracin de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para ingeniera de requerimientos. Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema Boehm 1979. Ingeniera 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 combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos Leite 1987. Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin 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 Ingeniera de Requerimientos Los principales beneficios que se obtienen de la Ingeniera 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 estimacin 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, desempeo, etc.).
2

 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. Fases de implementacin Desde un punto de vista conceptual, las actividades son de 5 clases. Obtener requerimientos: A travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus deseos. Analizar requerimientos: Detectar y corregir las falencias comunicativas, transformando los requerimientos obtenidos de entrevistas y requerimientos, en condiciones apropiadas para ser tratados por el diseo. Documentar requerimientos: Igual que todas las etapas, los requerimientos deben estar debidamente documentados. Verificar los requerimientos: Consiste en comprobar el correcto funcionamiento de un requerimiento en la aplicacin Validar los requerimientos: Comprobar que los requerimientos implementados se corresponden con lo que inicialmente se pretendia.

1.1.- REQUERIMIENTOS DE PROCESO

La definicin de etapas de desarrollo de un proyecto consiste en la identificacin y organizacin de todas las actividades y procesos importantes que intervienen en la bsqueda de una meta u objetivo, estas etapas deben ser definidas en funcin de sus caractersticas e importancia que presenten. Las actividades resultantes deben ser descritas y desarrolladas para conocer sus caractersticas, posteriormente debe de asignarse un nivel de importancia a cada una de ellas considerando aquellas actividades estrictamente necesarias para alcanzar el objetivo deseado. esta prioridad a nivel de importancia debe de ser considerada ms importante dentro de un modo eficaz (llegar al objetivo). Ahora debe de asignarse un rango o nivel aprobatorio para cada actividad que permitir eliminar directamente aquellas que no cumplan con el criterio asignado. Este nivel mnimo ser asignado considerando los niveles ms bajos que hayan sido puestos a las actividades para minimizar su impacto en el resultado final. Planeacin y Control de Procesos Este proceso se refiere a todas aquellas actividades necesarias para organizar y ordenar adecuadamente un proyecto, implica que cada una de las tareas o actividades que componen un proyecto deben estar muy bien definidas con el fin de identificar y conocer todos los aspectos y elementos importantes, y a su vez poder aplicar buenos mtodos de control que permitan llevar a cabo el proyecto de la mejor manera. Los pasos que contempla esta etapa son: Desglosar actividades generales. Analizar y profundizar cada actividad en sub-actividades (mas importantes). Conocer el detalle de cada sub-actividad. Aplicar elementos de control para cada actividad y sub-actividad. Identificar formas de evaluarlas. Consolidar y fortalecer cada actividad (justificar).
3

i.

i. Arquitectura de Tecnologa Se refiere a todos aquellos elementos tecnolgicos que son necesarios para soportar o complementar a las aplicaciones de una empresa. Su objetivo es definir un camino estndar para el uso de tecnologa en las empresas, y que les permita definir las opciones de crecimiento a mediano y largo plazo. Se siguen los siguientes pasos: Identificar plataformas y principios de tecnologa. Definir tecnologa distribucin de los datos y aplicaciones. Relacionar tecnologa distribucin de los datos y aplicaciones.

1.2.- REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCRADOS).

La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. Debido a que los cambios que introduce un sistema nuevo tienden a afectar a ms de un tipo de usuario, los analistas de requisitos han de tomar en consideracin a todos los implicados para que se obtengan y depuren sus requerimientos de la forma ms fidedigna posible. Entre las personas implicadas hay que considerar: Organizaciones que integran la organizacin del analista que est diseando el sistema Organizaciones o sistemas de respaldo Direccin Usuarios Entrevistas Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Los requerimientos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando
4

al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin. Forma de contrato En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requerimientos. En sistemas muy complejos stos pueden tener centenares de pginas. Objetivos medibles Los requerimientos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto. Prototipos Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de uso Un Caso de uso es una tcnica para documentar posibles requerimientos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales. A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio. Los prototipos pueden ser, por ejemplo, diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.

1.3.- REQUERIMIENTOS PARA EL ANALISIS Y NEGOCIACION.

Requerimientos para el anlisis y negociacin Una vez recopilados los requisitos, el producto obtenido configura la base del anlisis de requisitos. Los requisitos se agrupan por categoras y se organizan en sub conjuntos, se estudia cada requisito en relacin con el resto, se examinan los requisitos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes/usuarios. Es corriente en clientes y usuarios solicitar ms de lo que puede realizarse, consumiendo recursos de negocios limitados. Tambin es relativamente comn en clientes y usuarios el proponer requisitos contradictorios, argumentando que esa versin es esencial por necesidades especiales. El ingeniero del sistema debe resolver estos conflictos a travs de un proceso de negociacin. Los clientes, usuarios y el resto de intervinientes debern clasificar sus requisitos y discutir los posibles conflictos segn su prioridad. Los riesgos asociados con cada requisito sern identificados y analizados. Se efectan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el costo del proyecto y en el plazo de entrega.

1.4.- REQUERIMIENTOS PARA LA GESTION

La Gestin de Sistemas se ocupa de integrar, planificar y controlar los aspectos tcnicos, humanos, organizativos, comerciales y sociales del proceso completo (desde el anlisis y el diseo hasta la vida operativa del sistema). Los objetivos principales de la Gestin de Sistemas suelen ser: Planificar y controlar el proceso completo de anlisis, diseo y operacin del sistema dentro del presupuesto, plazo, calidad y restantes condiciones convenidas Controlar la validez de los criterios de diseo Controlar la adecuacin del producto del diseo a los requisitos establecidos en el anlisis Planificar y desarrollar las necesidades de mantenimiento Planificar y desarrollar las necesidades de formacin del personal que va a operar el sistema Planificar la supervisin del funcionamiento del sistema En grandes proyectos de ingeniera, y dentro del mbito de la gestin, el ingeniero de sistemas suele funcionar como asesor del director del proyecto, obteniendo, elaborando y presentando informaciones en un formato adecuado para que ste pueda tomar las decisiones pertinentes.