En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos 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.
Contenido
[ocultar]
1 Implicaciones 2 Fases de implementacin 3 Tcnicas principales o 3.1 Entrevistas o 3.2 Talleres o 3.3 Forma de contrato o 3.4 Objetivos medibles o 3.5 Prototipos o 3.6 Casos de uso 4 Especificacin de requisitos del software 5 Identificacin de las personas involucradas 6 Problemas o 6.1 Relacionados con las personas involucradas o 6.2 Relacionados con los analistas o 6.3 Relacionados con los desarrolladores o 6.4 Soluciones aplicadas 7 Fuentes
[editar] Implicaciones
La Ingenieria de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
La elicitacin de los requisitos de usuario Al anlisis y negociacin de requisitos para derivar requisitos adicionales A la documentacin de los requisitos como especificacin A la validacin de los requisitos documentados contra las necesidades de usuario As como los procesos que apoyan estas actividades.
Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por 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.
[editar] 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 requisitos 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 fallos. Las entrevistas pueden ser personales o grupales.
[editar] 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.
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.
[editar] 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.
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.
Funcionales: son los que el usuario necesita que efecte el software. Ej: 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). Ej: 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.
Organizaciones que integran la organizacin del analista que est diseando el sistema Organizaciones o sistemas de respaldo Direccin Usuarios
[editar] Problemas
[editar] Relacionados con las personas involucradas
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.
Uso de terminologa ambigua en la redaccin de los documentos de requisitos Sobreespecificacin 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
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.
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.
[editar] Fuentes
McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules, 1st ed., Redmond, WA: Microsoft Press. ISBN 1-55615-900-5. Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8. Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications -Description