Ingeniera de requisitos

En la ingeniera de sistemas y la ingeniera de software,la Ingeniera de requisitos o Ingeniera de requeri-mientos[1] comprende todas las tareas relacionadas conla determinacin de las necesidades o de las condiciones asatisfacer para un software nuevo o modicado, tomandoen cuenta los diversos requisitos de las partes interesadas,que pueden entrar en conicto entre ellos.Muchas veces se habla de requerimientos en vez de re-quisitos; esto se debe a una mala traduccin del ingls.La palabra requirement debe ser traducida como requisi-to, mientras que requerimiento se traduce al ingls comorequest.El propsito de la ingeniera de requisitos es hacer quelos mismos alcancen un estado ptimo antes de alcanzarla fase de diseo en el proyecto. Los buenos requisitosdeben ser medibles, comprobables, sin ambigedades ocontradicciones, etc.

1 ImplicacionesLa Ingeniera de Requisitos implica todas las actividadesdel ciclo de vida dedicadas a:

La educcin (a veces llamada elicitacin, debidoa una mala traduccin de elicitation) de los requi-sitos de usuario.

El anlisis y negociacin de requisitos para derivarrequisitos adicionales.

La documentacin de los requisitos como especi-cacin.

La validacin de los requisitos documentados contralas necesidades de usuario.

As como los procesos que apoyan estas actividades.

2 Fases de implementacinDesde un punto de vista conceptual, las actividades sonde cinco clases.

Obtener requisitos: a travs de entrevistas o comu-nicacin con clientes o futuros usuarios, para sabercules son sus expectativas.

Analizar requisitos: detectar y corregir las caren-cias o falencias comunicativas, transformando losrequisitos obtenidos de entrevistas y requisitos, encondiciones apropiadas para ser tratados en el dise-o.

Documentar requisitos: igual que todas las etapas,los requisitos deben estar debidamente documenta-dos.

Vericar los requisitos: consiste en comprobar laimplementacin de los requerimientos.

Validar los requisitos: comprobar que los requisi-tos implementados sean funcionales para lo que ini-cialmente se construy el producto.

3 Tcnicas principalesLa ingeniera de requisitos puede ser un proceso largo yarduo para el que se requiere de habilidades psicolgicas.Los nuevos sistemas cambian el entorno y las relacionesentre la gente, as que es importante identicar a todos losactores involucrados, considerar sus necesidades y asegu-rar que entienden las implicaciones de los nuevos siste-mas. Los analistas pueden emplear varias tcnicas paraobtener los requisitos del cliente. Histricamente, esto haincluido tcnicas tales como las entrevistas, o talleres congrupos para crear listas de requisitos. Tcnicas ms mo-dernas incluyen los prototipos, y utilizan casos de uso.Cuando sea necesario, el analista emplear una combina-cin de estos mtodos para establecer los requisitos exac-tos de las personas implicadas, para producir un sistemaque resuelva las necesidades del negocio.

3.1 EntrevistasLas entrevistas son un mtodo comn. Por lo general nose entrevista a toda la gente que se relacionar con el sis-tema, sino a una seleccin de personas que represente atodos los sectores crticos de la organizacin, con el n-fasis puesto en los sectores ms afectados o que harn unuso ms frecuente del nuevo sistema.

3.2 TalleresLos requisitos tienen a menudo implicaciones cruzadasdesconocidas para las personas implicadas individuales y

1

2 4 ESPECIFICACIN DE REQUISITOS DEL SOFTWARE

que a menudo no se descubren en las entrevistas o que-dan incompletamente denidas durante la misma. Estasimplicaciones cruzadas pueden descubrirse realizando enun ambiente controlado, talleres facilitados por un analis-ta del negocio, en donde las personas implicadas partici-pan en discusiones para descubrir requisitos, analizan susdetalles y las implicaciones cruzadas. A menudo es tilla seleccin de un secretario dedicado a la documenta-cin de la discusin, liberando al analista del negocio paracentrarse en el proceso de la denicin de los requisitosy para dirigir la discusin.[cita requerida]

Existen dos tcnicas de este tipo que son las ms utiliza-das: Brainstorming (Lluvia de ideas) y JAD (Joint Appli-cation Development, Diseo de Aplicacin Conjunta). Ladiferencia que existe entre ambas tcnicas es que durantela tormenta de ideas se tiene como objetivo generar unagran cantidad de ideas, es desestructurada y la informa-cin que se obtiene puede ser visual, textual coloquial;mientras que en el JAD el taller es ordenado, la infor-macin que se obtiene es visual y su objetivo es generarrequisitos y la interfaz del sistema.[cita requerida]

Durante una sesin de Lluvia de ideas, todos los partici-pantes pueden aportar distintas ideas en un ambiente librede prejuicios. Ningn participante debe juzgar negativa-mente la propuesta de otros, sino que se anotan todas lasideas en una pizarra y sern evaluadas al nal de la sesin.El principio bsico es no descartar de manera apresura-da ningn planteo, de modo que existe la posibilidad deque surjan otras ideas derivadas de la idea original y segeneran varios puntos de vista del problema.[cita requerida]

En el Joint application development se trabaja directa-mente sobre los documentos a generar, las temticas quese tratan durante las reuniones siguen un esquema y sebusca que la misma sea ordenada y racional. Se deneuna agenda con los puntos principales a tratar durante lajornada. Este tipo de taller tiene el inconveniente de quees muy difcil poder reunir a todas los participantes, escostoso y generalmente es necesaria ms de una reuninpara establecer los requisitos del sistema.[cita requerida]

3.3 Forma de contrato

En lugar de una entrevista, se pueden llenar formularios ocontratos indicando los requisitos. En sistemas muy com-plejos stos pueden tener centenares de pginas.

3.4 Objetivos medibles

Los requisitos formulados por los usuarios se toman co-mo objetivos generales, a largo plazo, y en cambio se losdebe analizar una y otra vez desde el punto de vista delsistema hasta determinar los objetivos crticos del funcio-namiento interno que luego darn forma a los comporta-mientos apreciables por el usuario. Luego, se establecenformas de medir el progreso en la construccin, para eva-

luar en cualquier momento qu tan avanzado se encuentrael proyecto.

3.5 Prototipos y Casos de uso

Un prototipo es una pequea muestra, de funcionalidadlimitada, de cmo sera el producto nal una vez termi-nado. Ayudan a conocer la opinin de los usuarios y rec-ticar algunos aspectos antes de llegar al producto termi-nado.Un caso de uso es una tcnica para documentar posiblesrequisitos, gracando la relacin del sistema con los usua-rios u otros sistemas. Dado que el propio sistema aparececomo una caja negra, y slo se representa su interaccincon entidades externas, permite omitir dichos aspectosy determinar los que realmente corresponden a las enti-dades externas. El objetivo de esta prctica es mejorarla comunicacin entre los usuarios y los desarrolladores,mediante la prueba temprana de prototipos para minimi-zar cambios hacia el nal del proyecto y reducir los costesnales. Esta tcnica se enfrenta a los siguientes peligrospotenciales.

A los directivos, una vez que ven un prototipo, lescuesta comprender que quedamucho trabajo por ha-cer para completar el diseo nal.

Los diseadores tienden a reutilizar el cdigo de losprototipos por temor a perder el tiempo al comen-zar otra vez.

Los prototipos ayudan principalmente a las decisio-nes del diseo y de la interfaz de usuario. Sin embar-go, no proporcionan explcitamente cules son losrequisitos.

Los diseadores y los usuarios nales pueden cen-trarse demasiado en el diseo de la interfaz de usua-rio y demasiado poco en producir un sistema quesirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones ope-rativas con funcionalidades sintetizadas. Los diagramas,en los casos donde se espera que el software nal tengadiseo grco, se realizan en una variedad de documentosde diseo grcos y a menudo elimina todo el color deldiseo del software (es decir utilizar una gama de grises).Esto ayuda a prevenir la confusin sobre la apariencia -nal de la aplicacin.

4 Especicacin de requisitos delsoftware

Una especicacin de requisitos del software es unadescripcin completa del comportamiento del sistema a

6.1 Relacionados con las personas involucradas 3

desarrollar. Incluye un conjunto de casos de uso que des-criben todas las interacciones que se prevn que los usua-rios tendrn con el software. Tambin contiene requisitosno funcionales (o suplementarios). Los requisitos no fun-cionales son los requisitos que imponen restricciones aldiseo o funcionamiento del sistema (tal como requisitosde funcionamiento, estndares de calidad, o requisitos deldiseo).Las estrategias recomendadas para la especicacin delos requisitos del software estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles,contenido deseable, y calidades de una especicacin derequisitos del software.Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita queefecte el software. Normalmente se identican co-mo los requisitos que responden a la pregunta quhace? e.g. El sistema debe emitir un comprobante alasentar la entrega de mercadera.

No funcionales: son los recursos para que trabajeel sistema de informacin (redes, tecnologa). Ej: elsoporte de almacenamiento a usar debe ser MySQL.Normalmente se identican como los requisitos queresponden a la pregunta cmo lo hace? e.g. rpido,fcil etc.

Empresariales u Organizacionales: son el marcocontextual en el cual se implantar el sistema paraconseguir un objetivo macro. Ej: abaratar costos deexpedicin.

5 Identicacin de las personas in-volucradas

Debido a que los cambios que introduce un sistema nuevotienden a afectar a ms de un tipo de usuario, los analistasde requisitos han de tomar en consideracin a todos losimplicados para que se obtengan y depuren sus requisi-tos de la forma ms dedigna posible. Entre las personasimplicadas hay que considerar:

Organizaciones que integran la organizacin delanalista que est diseando el sistema

Organizaciones o sistemas de respaldo

Direccin

Usuarios.

6 Problemas

6.1 Relacionados con las personas involu-cradas

Las vas que pueden dicultar la determinacin de los re-quisitos son:

Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboracin derequisitos escritos

Los usuarios insisten en nuevos requisitos despusde que el coste y la programacin se hayan jado.

La comunicacin con los usuarios es lenta Los usuarios no participan en revisiones o son inca-paces 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 exigenciasdel consumidor cambian, incluso cuando el desarrollo delproducto ya est en marcha.

6.2 Relacionados con los analistasLa correcta redaccin de las Especicaciones de requisi-tos del Software es imprescindible para el correcto desa-rrollo del proyecto. Por ello, en su redaccin hay que evi-tar:

Uso de terminologa ambigua en la redaccin de losdocumentos de requisitos

Sobreespecicacin de los requisitos Escritura poco legible, voz pasiva, abuso de nega-ciones

Uso de verbos en condicional, expresiones subjetivas Ausencia de trminos y verbos del dominio de laaplicacin

6.3 Relacionados con los desarrolladoresLos problemas posibles causados por los desarrolladoresdurante anlisis de requisitos son:

El personal tcnico y los usuarios nales pueden te-ner diversos vocabularios y pueden llegar a creerincorrectamente que estn de acuerdo, no dndosecuenta del desacuerdo hasta que se provee el pro-ducto nal.

Los desarrolladores pueden intentar encajar el siste-ma en un modelo existente, en vez de desarrollar unsistema adaptado a las necesidades del cliente.

4 8 REFERENCIAS

El anlisis de requisitos se puede realizar a menudopor los ingenieros o programadores, en vez de per-sonal con las habilidades de relacin con la gente yel conocimiento apropiados para entender las nece-sidades de un cliente correctamente.

7 Soluciones aplicadasUna solucin aplicada en los problemas de comunicacio-nes ha sido emplear a especialistas en anlisis del negocioo del sistema.Las tcnicas introducidas en los aos 90 tienden al uso deprototipos, lenguaje unicado de modelado, casos de uso,y el desarrollo gil de software.Otros tipos de herramientas aplicadas para salvar las di-ferencias entre los usuarios y las organizaciones de tecno-loga de la informacin y que permiten la comprobacinde las aplicaciones son:

pizarras electrnicas para bosquejar los algoritmos ypara probar alternativas

capacidad de capturar la lgica del negocio y los da-tos necesarios

capacidad de generar los prototipos que imitan el-mente el producto nal

interactividad la capacidad para agregar requisitos contextuales yotro comentarios

capacidad para que usuarios remotos y distribuidosoperen con el prototipo

Por ltimo, se requieren herramientas que permitan me-dir, de forma objetiva, la calidad de una especicacinde requisitos.

8 Referencias[1] Investigacin IT (28 de octubre de 2013). Requisitos o

requerimientos?. Consultado el 2 de noviembre de 2013.

8.1 Bibliografa McConnell, Steve (1996). Rapid Development: Ta-ming 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 re-quirements throughout the product development cy-cle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8.

Landgraf, Katja (2011) Requirement Managementin Product Development, Symposion PublishingISBN 978-3-939707-84-4

Andrew Stellman and Jennifer Greene (2005). Ap-plied Software Project Management. Cambridge,MA: O'Reilly Media. ISBN 0-596-00948-8.

IEEE Std 830-1998 IEEE Recommended Prac-tice for Software Requirements Specications -Description

59 Texto e imgenes de origen, colaboradores y licencias9.1 Texto

Ingeniera de requisitos Fuente: https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos?oldid=78381222 Colaboradores: En-ric Naval, Baneld, Gabriel Acquistapace, Roberto Fiadone, Isha, Gacq, VolkovBot, Muro Bot, Abel.orian, Mafores, Farisori, UA31,AVBOT, Adelpine, Diegusjaimes, Luckas-bot, Acasson, ArthurBot, Xqbot, Nail2001, Shadow440, EmausBot, ChuispastonBot, Wikitan-virBot, Helmy oved, Addbot, 10xor, Ejfdelgado y Annimos: 44

9.2 Imgenes Archivo:Commons-emblem-question_book_yellow.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/d/dd/

Commons-emblem-question_book_yellow.svg Licencia: CC BY-SA 3.0 Colaboradores: + Artista original: GNOME icon artists, LinfocitoB

9.3 Licencia de contenido Creative Commons Attribution-Share Alike 3.0

Implicaciones Fases de implementacin Tcnicas principales Entrevistas Talleres Forma de contrato Objetivos medibles Prototipos y Casos de uso

Especificacin de requisitos del software Identificacin de las personas involucradas Problemas Relacionados con las personas involucradas Relacionados con los analistas Relacionados con los desarrolladores

Soluciones aplicadas Referencias Bibliografa

Texto e imgenes de origen, colaboradores y licenciasTextoImgenesLicencia de contenido