MARA DE LOS NGELES MARTNEZ MORALES

TRABAJO: INVESTIGACION INGENIERIA DE REQUISITOS

FLORES PREZ JORGE ELIECER

Jefp2508@gmail.com

INTRODUCCION
En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o Ingeniera de requerimientos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al ingls como request. El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc. En un proyecto de desarrollo de software las medidas del xito suelen ser aparentemente muy simples: lograr la satisfaccin del cliente, finalizando el proyecto a tiempo, con el alcance definido y dentro del presupuesto inicialmente previsto; sin embargo los problemas a los que se enfrenta el responsable del proyecto cuando intenta cumplir con todos estos requerimientos es bastante complejo, es por esto que se requiere de un conjunto de soluciones que contribuyan a la consecucin de los objetivos del proyecto con el fin de permitir a la organizacin progresar tecnolgicamente, sin que se convierta en dependiente de las herramientas y de las modificaciones que deben hacerse en ellas. Para poder evitar estos inconvenientes hay que hallar mecanismos o herramientas que permitan que la comunicacin establecida entre el cliente y el profesional de sistemas sea efectiva y convierta lo emitido por el cliente y/o usuario en informacin fiable.

TENICAS QUE SE IMPLEMENTAN EN LAS TAREAS DE REQUSITOS

IMPLICACIONES
La Ingeniera de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

La educcin (a veces llamada "elicitacin", debido a una mala traduccin de "elicitation") de los requisitos de usuario. El anlisis y negociacin de requisitos para derivar requisitos adicionales. La documentacin de los requisitos como especificacin. La validacin de los requisitos documentados contra las necesidades de usuario. As como los procesos que apoyan estas actividades.

FASES DE IMPLEMENTACION
Desde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin. Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

TECNICAS PRINCIPALES
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 todos los actores involucrados, 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.

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.

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 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 requisitos. En sistemas muy complejos stos pueden tener centenares de pginas.

Objetivos medibles
Los requisitos 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 requisitos, 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: 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.

Especificacin De Requisitos De Software

Una especificacin de requisitos del software es una descripcin completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevn que los usuarios tendrn con el software. Tambin contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseo o funcionamiento del sistema (tal como requisitos de funcionamiento, estndares de calidad, o requisitos del diseo). Las estrategias recomendadas para la especificacin de los requisitos del software estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles, contenido deseable, y calidades de una especificacin de requisitos del software. Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efecte el software. Ejemplo: el sistema debe emitir un comprobante al asentar la entrega de mercadera.

No funcionales: son los "recursos" para que trabaje el sistema de informacin (redes, tecnologa). Ejemplo: el soporte de almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual se implantar el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedicin.

Problemas
Relacionados con las personas involucradas Las vas que pueden dificultar la determinacin de los requisitos son:

Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboracin de requisitos escritos Los usuarios insisten en nuevos requisitos despus de que el coste y la programacin se hayan fijado. La comunicacin con los usuarios es lenta Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas tcnicos Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situacin donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya est en marcha. Relacionados con los analistas La correcta redaccin de las Especificaciones de requisitos del Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redaccin hay que evitar:

Uso de terminologa ambigua en la redaccin de los documentos de requisitos Sobre especificacin de los requisitos Escritura poco legible, voz pasiva, abuso de negaciones Uso de verbos en condicional, expresiones subjetivas Ausencia de trminos y verbos del dominio de la aplicacin

Relacionados con los desarrolladores Los problemas posibles causados por los desarrolladores durante anlisis de requisitos son:

El personal tcnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que estn de acuerdo, no dndose cuenta del desacuerdo hasta que se provee el producto final. Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente. El anlisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relacin con la gente y el

conocimiento apropiados para entender las necesidades de un cliente correctamente. Soluciones aplicadas Una solucin aplicada en los problemas de comunicaciones ha sido emplear a especialistas en anlisis del negocio o del sistema. Las tcnicas introducidas en los aos 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo gil de software. Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnologa de la informacin y que permiten la comprobacin de las aplicaciones son:

pizarras electrnicas para bosquejar los algoritmos y para probar alternativas capacidad de capturar la lgica del negocio y los datos necesarios capacidad de generar los prototipos que imitan fielmente el producto final interactividad la capacidad para agregar requisitos contextuales y otro comentarios capacidad para que usuarios remotos y distribuidos operen con el prototipo

Por ltimo, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificacin de requisitos.

CONCLUSION
A pesar de la importancia que tiene la Ingeniera de Requerimientos, ha costado mucho que se le preste la atencin adecuada a esta actividad. An quedan muchos desafos que deben ser mejorados, tales como la integracin de requerimientos funcionales y no funcionales, la evaluacin de especificaciones alternativas, la formalizacin de la SRS, entre otras. Cada actividad y tcnica de la IR utilizada individualmente, dar diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el rea del problema son el mismo. Por esta razn, considero que no existe un modelo de proceso ideal para la IR; encontrar el mtodo o la tcnica perfecta es una ilusin, pues cada mtodo y tcnica ofrece diferentes soluciones ante un problema. En esta investigacin se presentaron una serie de actividades y tcnicas, que no pertenecen a un modelo de proceso en s, sino, que son una alternativa al material publicado por diferentes autores y que, desde mi punto de vista, son las ms importantes. Debemos recordar que la Ingeniera de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de Tomando

en cuenta la magnitud de comunicacin y el trabajo en equipo que debe existir en la IR, considero necesario enfatizar ms en cerrar las brechas que todava existen, incluyendo los siguientes elementos: Factores sociales: involucrar al grupo para compartir sus experiencias. Factores de problemas especficos: el dominio de la estructura y estndares disponibles. Factores organizacionales: tiempo y costo presupuestados. Factores de diseo: por ejemplo, interfaces de usuario Es importante tomarse el tiempo necesario para conocer a nuestros clientes y usuarios, as como su ambiente de trabajo. Esto, tambin ayuda a establecer una buena relacin de trabajo y comunicacin entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definicin de sus requerimientos, pues ellos son los que deciden nuestro destino en el proyecto, deciden si les gustamos o no y adems financian el proyecto. Otro punto a considerar, es la inclusin del trmino "Administracin de Requerimientos" en la dcada de los 90. Con esta nueva visin, se busca encontrar una descripcin ms apropiada de las actividades involucradas, a la vez de enfatizar la importancia de mantener una buena relacin entre los afectados y el equipo del proyecto. Entregar software de calidad, a tiempo y dentro del presupuesto, har que nuestros clientes confen y asegurar el crecimiento y madurez de la relacin de negocio.