Está en la página 1de 15

INGENIERA DE REQUERIMIENTOS La ingeniera de requerimientos es una de las partes ms importantes y menos apreciadas de la ingeniera de sistemas y de la ingeniera de software.

Como todas las ramas de la ingeniera relativas a la fabricacin de software su origen es muy reciente y es hasta hace poco tiempo que es reconocida por los principales autores como una disciplina formal. El auge que esta disciplina ha tenido en los ltimos a os se debe a la importante influencia que los requerimientos muestran en las estadsticas de proyectos fracasados o con problemas de tiempo o presupuesto. Lo anterior no slo ha producido mucha literatura sino que ha obligado a los !metodlogos" a concederle un papel muy importante dentro de sus metodologas al proceso de identificacin y captura de requerimientos. #odemos definir la ingeniera de requerimientos como la ciencia y la disciplina encargada de identificar$ documentar$ verificar y administrar los requerimientos de un sistema. En este conte%to$ el mayor ob&etivo de la ingeniera de requerimientos es definir el propsito de un sistema y capturar el comportamiento e%terno del mismo.

Necesidades

Funcionalidades Requerimientos de Software


Managing Software Requirements, D. Leffingwell, AW2000

El modelo que se reproduce arriba permite entender me&or la relacin entre el sistema y el software. En la parte superior de la pirmide se encuentran las necesidades de los clientes y de los usuarios. 'qu se concentra cualquier rea de oportunidad$ problema del negocio$ problema personal o problema operacional que$ si es resuelto por un sistema$ produce un beneficio a la compa a $ de tal forma que se &ustifica su construccin o compra. (n e&emplo de una necesidad de un cliente puede ser) !Necesito disminuir el tiempo de atencin de los clientes que hablan por telfono a mis oficinas. Cuando se identifican necesidades es importante hacer una distincin entre clientes y usuarios que nos ayude a identificarlos en el conte%to de un proyecto$ as como a establecer prioridades y criterios sobre la importancia relativa de cada una de sus necesidades con respecto al aspecto del sistema que estamos anali*ando. (n cliente es cualquier persona que tiene requerimientos sobre el proyecto$ pero que no va a usar el producto de manera directa por e&emplo) el patrocinador$ el gerente de mercadotecnia de la empresa para la que traba&amos$ la persona que paga por un desarrollo a la medida$ el gerente de sistemas de la empresa que va a comprar un desarrollo$ etc.

(n usuario es un individuo que va a interactuar directamente con el sistema que se va a construir. (na comunidad de usuarios es un grupo de usuarios que tienen el mismo rol dentro del sistema. En el rea de en medio de la pirmide se encuentra la funcionalidad del sistema. La funcionalidad se define como los servicios que el sistema provee para resolver una o ms necesidades de los clientes o usuarios. Es claro que la funcionalidad tiene una relacin directa con las necesidades$ por lo tanto la funcionalidad debe estar e%presada en un lengua&e comn y a un nivel lo suficientemente alto como para ser discutidas con los clientes o usuarios y lograr un comn acuerdo sobre su significado. (n e&emplo de funcionalidad para la necesidad !disminuir el tiempo de atencin.... puede ser) El sistema debe proveer una lista de los productos que ms consume mi cliente. +inalmente$ en la base de la pirmide se encuentran los requerimientos de software. Los requerimientos de software pueden ser) (na capacidad que el sistema necesita para resolver un problema o alcan*ar un ob&etivo. (na capacidad que el sistema debe poseer para satisfacer un contrato$ un estndar$ una especificacin u otra imposicin formalmente documentada. Los requerimientos se derivan de las funcionalidades$ pero son lo suficientemente especficos como para poder derivar cdigo a partir de ellos. (n e&emplo de requerimientos para el caso anterior) !La lista de productos debe desplegarse en una tabla que contenga una columna con el identificador del producto y otra con una breve descripcin". !La lista no debe presentar ms de , productos". !La lista debe estar organi*ada por frecuencia$ siendo el producto ms frecuentemente solicitado el primero de la lista". Los requerimientos tienen una importancia fundamental en un proyecto de software$ las venta&as que una buena especificacin de requerimientos proporcionan incluyen -./) #ermite establecer un acuerdo entre los desarrolladores$ clientes y usuarios acerca del traba&o que se va a reali*ar y sobre los criterios de aceptacin del producto terminado. #ermite establecer una base para la estimacin del proyecto) -tiempo$ costo y recursos/ 0e&ora las caractersticas del producto final como) facilidad de uso$ desempe o$ facilidad de mantenimiento y otras/ #ermite lograr alcan*ar los ob&etivos con la cantidad ptima de recursos.

1in embargo$ el proceso de obtener los requerimientos de un sistema no es un asunto trivial. La influencia de los requerimientos en el fracaso de los proyectos est bien documentada por varios autores -.$ 2/. Las estadsticas muestran que los requerimientos o alguna actividad relacionada con los mismos es identificada como una de las causas principales de fracaso en proyecto de software.

Problemas en la identificacin de re !erimientos


E%isten diversas situaciones que pueden provocar una deficiente identificacin y captura de requerimientos y provocar la catstrofe de un proyecto. La mayora de las veces estas deficiencias estn relacionadas con la falta de importancia que en muchas organi*aciones se le da al proceso de especificacin de requerimientos. Esta falta de importancia puede traducirse en situaciones como las siguientes -./) La presin que muchos clientes e&ercen para reducir o no pagar el tiempo de captura de requerimientos ya que consideran que el verdadero valor se obtiene a trav3s de las actividades de programacin de cdigo.

La falta de cooperacin del cliente para verificar que los requerimientos capturados son correctos y la falta de comprensin de la importancia de las especificaciones. La subestimacin de la importancia que los requerimientos tienen para todo el proyecto. La falta de entrenamiento formal de los analistas en t3cnicas para la identificacin y captura de requerimientos. La prctica errada de muchos gerentes de poner a personal con poca e%periencia y conocimiento para desarrollar software en posiciones clave o de gran responsabilidad donde provocan quiebres al proceso de desarrollo de grandes proyectos.

Es bien conocido que los proyectos que son intensivos en software son ms comple&os en su naturale*a que los proyectos que no lo son. 'dicionalmente$ los problemas para generar una buena especificacin aumentan cuando el tama o o la comple&idad del proyecto aumentan. En este escenario la eleccin de t3cnicas o herramientas adecuadas para especificar requerimientos y la escritura de una especificacin de software adecuada y completa se vuelven muy comple&as. 'nte todos estos retos y dada la importancia que tienen para un proyecto producir una buena especificacin de software$ surge la necesidad de establecer una disciplina que ayude a enfrentar con seriedad la problemtica del desarrollo de requerimientos. La ingeniera de requerimientos debe enfocarse a resolver las preguntas de) 4Cmo deben desarrollarse los requerimientos de un sistema5$ 4Cmo podemos evaluar que los requerimientos de un sistema estn completos5$ 46u3 estndares$ herramientas y m3todos pueden ayudar con el problema de los requerimientos5 La ingeniera de requerimientos se enfoca$ no slo en el anlisis y especificacin de requerimientos de un sistema$ sino tambi3n en la investigacin abstracta de las me&ores formas para desarrollar los requerimientos.

MANAGEMENT

ELICITATION ANALYSIS SPECIFICATION VERIFICATION

7arias ta%onomas han sido propuestas para la ingeniera de requerimientos$ sin embargo la mayora de los traba&os al respecto estn de acuerdo en el modelo que propone 8orfman-./ -9/ o en alguna variacin de este mismo modelo) Elicitacin: Es el proceso mediante el cual el cliente y el analista de un sistema de software descubren$ revisan$ articulan y entienden las necesidades de clientes y usuario y las restricciones del software y de la actividad de desarrollo. Anlisis: Es el proceso de anali*ar las necesidades de los clientes y de los usuarios para llegar a la definicin de los requerimientos del software. Especificacin: Es el desarrollo de un documento que$ de manera clara y precisa$ registre cada uno de los requerimientos del software. Verificacin: Es el proceso de asegurar que la especificacin de requerimientos cumple con las necesidades de los clientes y usuarios$ cumple con los estndares definidos en la organi*acin y es una base adecuada para establecer la arquitectura preliminar del proyecto. Administracin: Es la planeacin y control de las actividades que ocurren durante el proceso de desarrollo de los requerimientos.

Con e%cepcin de la administracin$ las partes se mencionan en el mismo orden lgico en el que se aplican en un proyecto. (n proceso de ingeniera de software debe incluir en la descripcin del flu&o de traba&o de requerimientos$ actividades en cada una de las reas se aladas para logra una apro%imacin m3todica y progresiva a la especificacin del proyecto. Las actividades de administracin de los requerimientos son las mismas que se reali*an en la administracin general de proyectos de software$ la diferencia es que los planes que se formulan y las actividades de control son especficos para el desarrollo de requerimientos. La administracin de requerimientos es una actividad de soporte que ocurre a lo largo de todo el proceso de desarrollo de requerimientos y por lo tanto se coloca de manera vertical en el modelo. E%isten diferentes t3cnicas que pueden aplicarse para lograr los ob&etivos particulares de cada una de las partes de la ingeniera de requerimientos. ' continuacin$ se mencionan algunas de las ms usadas. Elicitacin Como ya hemos visto$ la elicitacin consiste en identificar las necesidades de los usuarios y las restricciones del sistema. 8e acuerdo al modelo de la pirmide de requerimientos podemos considerar que elicitacin del proyecto se queda en el nivel de funcionalidad y de&a para la parte de anlisis el determinar los requerimientos del sistema. La elicitacin es un proceso comple&o$ ya que se enfrenta con algunos sndromes que han sido definidos como las !barreras de la elicitacin" -./. Estos sndromes son situaciones implcitas al proceso de desarrollo de software que complican la administracin y agregan un factor de incertidumbre al proyecto. El s"ndrome de #si$ %ero&&&' Este sndrome es uno de los problemas ms frustrantes y persistentes en un proyecto de software. El sndrome consiste en que por alguna ra*n cuando presentamos el sistema al cliente por primera ve* y en caso de que el sistema sea lo que el cliente espera$ ocurren dos reacciones opuestas y paralelas) #or un lado el cliente est contento y nos felicita por nuestro esfuer*o e incluso menciona situaciones en las que el sistema ser de mucho valor. #or otra parte$ el cliente dice) #ero 4que pasa en esta situacin5$ o 4no sera me&or que esta operacin se hiciera de otra manera5$ o an me&or) 4:o podramos agregar esta funcionalidad5. La causa de este sndrome es parte de la naturale*a msma del software como un proceso intelectual intangible. La reaccin del usuario es parte de la naturale*a humana y ocurre en otras situaciones del da a da$ el motivo es que despu3s de muchos meses de desarrollo ahora es capa* de entender que es lo que el desarrollador quera decir cuando e%plicaba una u otra funcionalidad del sistema. 8e la misma manera que una imagen dice ms que mil palabras$ el producto que presentamos al usuario es mucho ms e%plcito que su especificacin. La manera en la que podemos reducir significativamente el impacto de este sndrome es aplicar t3cnicas que permitan que los ;peros; de clientes y usuarios se produ*can cuanto antes en el proceso de desarrollo. El sndrome de las ruinas enterradas. 8e alguna manera$ la bsqueda de requerimientos es como la bsqueda de ruinas arqueolgicas) !entre ms descubres$ sabes que todava queda mucho ms enterrado". Cuando se identifican los requerimientos en un proyecto de software no es posible llegar a un punto en el cual uno sienta que ha identificado todo lo que haba por encontrar. Este sndrome provoca que los analistas enfrenten continuamente la pregunta de 4sern suficientes los requerimientos identificados para comen*ar el desarrollo5. Esto puede llevar a otro sndrome conocido en la administracin de proyectos como !parlisis por anlisis"$ que consiste en que el proyecto se estanca indefinidamente en un proceso de identificacin de requerimientos que parali*a al proyecto hasta provocar su cancelacin. El Proceso de Elicitacin

El proceso de elicitacin puede describirse en cuatro pasos-</) Identificar el problema. Definir las fronteras de la solucin. Identificar las restricciones impuestas a la solucin. Entender las necesidades de los clientes y usuarios. Identificar el %roblema& El proceso de elicitacin inicia con la identificacin del problema que se va a resolver. Es importante que la definicin del problema sea consensada por el cliente y todos los involucrados en el proceso de desarrollo. La manera ms sencilla de lograr esto es escribir el problema y modificarlo hasta que se logre un consenso. (n formato que puede ayudarnos a identificar el problema es el siguiente -./) El problema de) Descripcin del problema! 'fecta a) Identificar a los usuarios y clientes afectados por el problema! En qu3) Describir el impacto del problema en los afectados y en las actividades del ne"ocio! (na solucin e%itosa es) Indicar la solucin propuesta y listar los principales beneficios! Es comn que en el proceso de identificacin del problema$ la gente pregunte si el problema debe ser slo uno. La respuesta es s$ cada proyecto debe de tener un slo enunciado del problema$ por tanto el enunciado debe ser el de ms alto orden encontrado. (n error frecuente es que los analistas confunden el verdadero problema con los efectos finales o los sntomas que el problema produce$ en estos casos es til preguntar 4por qu3 sucede esto5$ hasta llegar a lo que se puede considerar la ra* del problema o el problema detrs del problema. (na t3cnica til para descubrir el problema detrs del problema son los diagramas de cola de pescado y los diagramas de pareto. Por ejemplo: En un hospital se tiene problemas con el tiempo para generar la factura de los pacientes dados de alta. El departamento de que&as recibe muchas protestas de clientes sobre el tiempo en el que se tardan en entregarles su factura y el departamento de mercadotecnia ha detectado que se registra una fuerte p3rdida de clientes por esta causa. El director del hospital lleg a la conclusin de que es necesario comprar un nuevo sistema de facturacin para evitar seguir perdiendo clientes. (na investigacin en el mercado de E=# para hospitales da como resultado que el presupuesto y el tiempo de implementacin de esta solucin$ la de&an fuera de las necesidades actuales del hospital. El director entonces$ invita a una empresa de consultora y desarrollo para que lo ayude a encontrar una solucin. La empresa comien*a el proceso de elicitacin y descubre que las causas del problema de facturacin son las siguientes) El sistema actual no permite dividir una cuenta en varias facturas. Cuando un paciente quiere reclamar los cargos de su cuenta que cubre su seguro a su compa a aseguradora$ el ca&ero tiene que cancelar la cuenta del paciente y posteriormente crear dos cuentas separadas para facturar. En ocasiones los m3dicos avisan del alta al paciente antes que a la enfermera encargada$ por lo que la enfermera no enva el alta del paciente a la ca&a y la factura se demora. El rea de Laboratorio no est conectada al sistema del hospital por lo que los cargos a la cuenta del paciente se hacen a trav3s del rea de farmacia. 8ebido que estos cargos no se hacen en lnea el ca&ero tiene que hablar a farmacia para saber si el paciente no tiene cargos pendientes. El sistema no permite cambios una ve* que se cierra la factura. En ocasiones algn rea del hospital informa de algn cargo pendiente despu3s de que el ca&ero cerr la factura$ o el cliente nota que su nombre o su direccin estn incorrectos. Esto provoca que la factura tenga que ser cancelada y creada nuevamente.

80 P o r c i e n t o 70 60 50 40 30 20 10 0 1 2 3 4

Contribucin
1.El sistema no permite dividir una cuenta en varias facturas 2.Las enfermeras no pasan las altas de los pacientes inmediatamente 3.El Laboratorio no est conectado al sistema del hospital 4. El sistema no permite cambios una vez que se cierra la factura

Mucho tiempo para realizar una factura

Con esta informacin$ la empresa consultora genera estadsticas de una muestra representativa de facturas y descubre lo siguiente) >a que el ?@A de los pacientes entran por medio de una compa a aseguradora$ el principal problema de facturacin del hospital es la imposibilidad de dividir una cuenta en varias facturas. En la estadstica tambi3n aparece el segundo problema en importancia es la imposibilidad de hacer cambios a una factura cerrada. En este punto$ la empresa consultora$ decide reformular el problema de esta manera) El problema de: Benerar cambios en las cuentas y en las facturas de los clientes. Afecta a: Los clientes en general$ la gerencia del hospital. En qu: Los clientes tienen que esperar hasta una hora para recibir su factura$ lo que provoca que no recomienden al hospital y que eli&an otro hospital para atenderse. na solucin e!itosa es: 0odificar el sistema actual para que permita) Benerar varias facturas a partir de la misma cuenta. =eali*ar cambios a una factura cerrada. "efinir las fronteras de la solucin. (na ve* que se ha alcan*ado un acuerdo sobre el problema que se va a construir$ es necesario definir un sistema que pueda ser construido para resolver el problema. #ara hacer esta tarea debemos comen*ar con establecer las fronteras dentro de las cuales se crear el sistema. (na manera de acotar un sistema es ponerlo en el conte%to de los elementos e%ternos que van a interactuar con 3l. Los elementos e%ternos pueden ser) humanos$ elementos de hardware u otros sistemas. ' estos elementos se les conoce dentro de (0L como 'ctores. En el inicio de un proyecto es conveniente establecer qu3 partes de la solucin forman parte del proyecto de construccin del sistema$ y qu3 partes van a interactuar con el sistema como elementos e%ternos o actores. Esto facilita que los participantes mantengan el enfoque del proyecto y traba&en slo dentro del alcance del mismoC adicionalmente permite administrar de manera correcta las e%pectativas del cliente.

Sistema de ro!ramaci"n de Env#o de aquetes


Sistema de $aptura de edidos

ro!ramador de Emvios

(na herramienta que nos permite documentar las fronteras del proyecto es el diagrama de conte%to. (n diagrama de conte%to emplea un rectngulo para definir el proceso y utili*a figuras de palitos para representar a los actores -lo cual es un estndar de (0L/. ' este modelo se le conoce como modelo del ne"ocio. El modelo del negocio es una descripcin de los procesos de negocio de una organi*acin. #rovee el entendimiento del negocio del cliente como un todo. #dentificar las $estricciones #mpuestas a la %olucin (na restriccin es una reduccin al grado de libertad que tenemos para generar una solucin. E%isten diferentes tipos de restricciones que pueden presentarse en un proyecto. Cada restriccin puede potencialmente restringir nuestra habilidad para desarrollar una solucin tal y como la visuali*amos. #or lo tanto cada restriccin debe considerarse dentro del proceso de planeacin para anali*ar su impacto y determinar qu3 estrategia se emplear para cumplirla. Como una ayuda al proceso de identificar restricciones se presenta la siguiente lista -</) Econmicas 46u3 restricciones financieras o de presupuesto son aplicables5 4E%iste alguna consideracin de precios de productos5 4E%iste alguna restriccin de licencias5 4(na falla puede interrumpir o da ar las operaciones diarias crticas del negocio5 4#uede este proyecto incurrir o causar perdidas financieras significantes5 4Es este un esfuer*o grande -D E meses o F.@@$@@@ 8ls./5 Pol"ticas 4E%isten cuestiones polticas internas o e%ternas que puedan afectar la solucin5 4E%isten problemas o cuestiones interdepartamentales que puedan afectar la solucin5 4+allar en el proyecto puede da ar la reputacin de la empresa5 4Este problema no ha podido ser resuelto en el pasado5 4E%iste algn participante que se oponga o tenga muchas dudas del proyecto5 E%istirn ms de , personas en el equipo del proyecto o en el !1teering Comitee"5 T(cnicas 4E%iste alguna restriccin en la eleccin de la tecnologa5 4E%iste alguna restriccin para traba&ar con las plataformas o t3cnicas e%istentes5 4Est restringido el uso de alguna nueva tecnologa5 4Es necesario usar algn paquete de software adquirido por el cliente5 4El producto depende de tecnologa e%perimental5 1i lo anterior ocurre$ 4estar involucrado ms de un proveedor o componente crtico5 4E%iste un alto nivel de comple&idad t3cnica involucrado5

Sistemas 4La solucin se construir sobre un sistema e%istente5 41e debe mantener la compatibilidad con alguna solucin e%istente5 46u3 sistemas operativos y ambientes deben ser soportados5 Ambientales 4E%isten restricciones regulatorias5 4E%isten requerimientos de seguridad5 46u3 otros estndares debe respetar el proyecto5 4E%isten restricciones legales o ambientales5 4Est involucrada ms de una empresa5 40s de una empresa ser impactada por el producto5 )alendario * Rec!rsos 4El calendario del proyecto est definido5 41e est restringido a los recursos actuales5 4#ueden usarse e%ternos5 4#ueden e%pandirse los recursos temporal o permanentemente5 4Este proyecto est en busca de un campen5 4Este proyecto est en busca de un lder o administrador5 4El proyecto entrar en un calendario acelerado o comprometido5 4Lo anterior representa una dificultad o problema a largo pla*o5 4Es el primer esfuer*o de esta compa a en proyectos de este tipo5 4'lgn contratista e%terno liderar o producir algn entregable clave5 4Es necesario establecer un plan o asignar responsabilidades5 4El equipo de traba&o carece de alguna habilidad necesaria5 4Los recursos del proyecto estn administrados Gcontrolados por ms de una persona5 4Los miembros clave del equipo se encuentran en departamentos o edificios separados5 4Hay dudas acerca del compromiso o disponibilidad de algn recurso clave5 (na ve* identificadas algunas de las restricciones se volvern requerimientos del sistema que vamos a construir$ otras restricciones afectarn recursos$ planes de implementacin y planes del proyecto. Es responsabilidad del analista entender las fuentes potenciales para cada restriccin y determinar el impacto de cada una en el espacio de la solucin del problema. Entender las necesidades de clientes & usuarios La solucin de un problema comple&o$ normalmente implica satisfacer las necesidades diversos grupos de inter3s. Estos grupos pueden ser divididos en clientes y usuarios) cliente es una persona que tiene influencia sobre los requerimientos del sistema aunque vaya a ser un usuario del mismo$ mientras que los usuarios son las personas o grupos personas que van a interactuar directamente con el sistema. de (n no de

Entender las necesidades de clientes y usuarios es una parte fundamental de la elicitacin de un proyecto. #ara entender las necesidades de estas personas hay que empe*ar por identificarlos. 'lgunas preguntas que podemos hacer para ayudarnos en esta labor son) #$ules sern los diferentes roles or"ani%acionales que usaran el sistema& #'uin va a pa"ar por el sistema& #'u otra persona se ver afectada por las salidas que el sistema produce& #'uin es responsable de evaluar y aceptar el sistema cuando se libere& #'uin ser responsable de darle mantenimiento al sistema& (na ve* que hemos identificado a los clientes y usuarios podemos aplicar varias t3cnicas para identificar cules son sus necesidades. La siguiente seccin describe esas t3cnicas y algunas herramientas que ayudan a entender cules son las necesidades de los usuarios respecto al sistema que se va a construir.

T(cnicas de Elicitacin (na cuestin bsica en Ingeniera de =equerimientos es cmo determinar qu3 es lo que el cliente y los usuarios verdaderamente necesitan. Este proceso ha demostrado en la prctica que es muy comple&o y que puede fcilmente provocar el fracaso de un proyecto. E%isten varias t3cnicas que pueden utili*arse para la elicitacin de un sistema$ sin embargo$ dada la naturale*a social del proceso$ el uso de las mismas debe considerar no slo los aspectos t3cnicos sino los aspectos sociales$ polticos y culturales del proyecto. :ormalmente$ el aspecto social del proceso no es fcil de describir en primera instancia$ requiere una inmersin profunda en el mbito de los individuos$ no es suficiente la simple recoleccin de informacin$ como por e&emplo$ reunir estadsticas de la ocurrencia de ciertas categoras predeterminadas. Intros%eccin La introspeccin es el medio ms obvio y comnmente usado para entender los requerimientos de un sistema. Consiste en estudiar el ambiente del usuario para posteriormente tratar de imaginar qu3 es lo que me gustara que hiciera el sistema si yo estuviera a cargo de hacer el traba&o con su ayuda. Esta t3cnica es til pero hay que considerar que la e%periencia de un analista de sistemas es muy diferente que la e%periencia de los usuarios potenciales del software y por lo tanto es difcil que las conclusiones del analista refle&en la e%periencia de las personas que hacen la tarea da con da. Esto se hace ms evidente en el dise o de la interfa* grfica del usuario$ lo que para un analista es el comportamiento comn de un software$ puede resultar confuso o frustrante para un usuario. Jradicionalmente$ debido a las limitaciones grficas que anteriormente tenan las computadoras$ se creaba una brecha entre el dise o de la aplicacin y las necesidades de uso del usuario$ sin embargo debido a la evolucin de los ambientes grficos el paradigma est cambiando) (a obli"acin del usuario no es aprender a dominar una tecnolo")a* es la tecnolo")a la que debe ayudar al usuario a hacer su traba+o. La e%plosin del Internet ha creado nuevas especialidades como !user e%perience" en las cuales la psicologa y la sociologa son las principales herramientas cientficas. La recomendacin$ cuando se usa la introspeccin$ es apoyarla con la informacin previa que generan otras t3cnicas como por e&emplo la entrevista abierta. En cualquier caso es recomendable validar cualquier duda con un !e%perto de dominio". Los e%pertos de dominio son personas con mucha e%periencia en un rea particular del negocio que es de inter3s para el sistema. #or e&emplo$ en el caso de una lnea de produccin$ el operador de alguna mquina de la lnea puede ser un e%perto de dominio que aporte valiosa informacin para la automati*acin del proceso. Entre+ista Abierta (na de las t3cnicas ms importantes y ms directas para obtener requerimientos es la entrevista abierta. El proceso de reali*ar una entrevista puede parecer trivial en muchos casos$ sin embargo$ debido al factor social que ya hemos mencionado y al ;sndrome del usuario y el desarrollador;$ las entrevistas pueden presentar complicaciones. (na de las principales consideraciones a tomar en cuenta en una entrevista es lograr que la predisposicin del entrevistador no influya en el resultado de la narrativa capturada. Como proveedores de soluciones$ estamos acostumbrados a identificar soluciones al mismo tiempo que escuchamos problemas$ cuando hacemos esto$ tendemos a influenciar las respuestas del entrevistado$ provocando una mala comprensin del problema o una reduccin en el grado de libertad de la solucin. (na entrevista debe considerar preguntas libres de conte%to -Bausse and Keinberg$ .L?L/$ es decir$ preguntas que no influencien las respuestas de los entrevistados hacia las respuestas que queremos or. #or e&emplo) #'uines son los usuarios del sistema& #'u problemas tienen actualmente& #$ules son sus necesidades respecto a la solucin&

Este tipo de preguntas fuer*an al entrevistador a escuchar antes de identificar una solucin potencial$ as mismo permiten al entrevistado e%playarse en la descripcin de la problemtica que enfrenta. Cuando el analista escucha lo que el usuario tiene que decir respecto a sus necesidades$ se produce un me&or entendimiento del problema y por tanto una solucin adecuada. Las preguntas libres de conte%to son una t3cnica similar a la que los profesionales de ventas utili*an como parte de la estrategia conocida como !solution selling". En esta estrategia el vendedor pregunta para obtener informacin sobre la problemtica del cliente antes de ofrecer un producto o un servicio. Cuando el vendedor ha obtenido una visin clara de la problemtica del cliente$ entonces propone algo que tiene sentido para el cliente y entonces la venta se produce ms fcilmente. Pasos para una entre'ista abierta (na entrevista abierta requiere prepararse con anterioridad. (na recomendacin bsica es preparar una gua con preguntas apropiadas que permitan mantener una conversacin fluida a la ve* que ayuden a asegurar que no se olvida tocar ningn tema importante durante la entrevista. La gua no debe seguirse al pi3 de la letra$ simplemente es un apoyo para usarse durante la entrevista. ' continuacin se listan algunos pasos para preparar una entrevista. Investi"ar el bac,"round del usuario y de la empresa antes de la entrevista -evisar las pre"untas antes de la entrevista $onsultar la lista de pre"untas durante la entrevista para ase"urarse de hacer las pre"untas correctas .l final de la entrevista* identificar los dos o tres problemas principales y repetir lo que se entendi para ase"urar la comprensin Al,!nos conse-os !e %!eden a*!darnos d!rante !na entre+ista. No ha"as pre"untas donde se supon"a de antemano que la "ente puede describir actividades comple+as. En "eneral la "ente puede hacer muchas cosas que no puede describir. $uando necesites entender una actividad comple+a separa la pre"unta en varias partes o utili%a otra tcnica como la investi"acin de campo. /a% pre"untas abiertas que le permitan al usuario e0tenderse en sus respuestas y a ti comprender me+or su problemtica. No ha"as pre"untas que influenc)en la respuesta del entrevistado1 #2sted necesita una pantalla para reali%ar esta tarea* verdad& No ha"as pre"untas para controlar la conversacin1 #3odemos re"resar a la pre"unta anterior& No ha"as pre"untas que se respondan as) mismas1 #45 elementos en esta lista son suficientes* verdad& Evita pre"untas que empiecen con #3or qu&. /abitualmente estas pre"untas ponen al entrevistado a la defensiva porque aparentan cuestionar la manera en que hace su traba+o. No esperes respuestas sencillas. $uando las obten"as si"ue pre"untando para descubrir ms ruinas enterradas. No apures al entrevistado para que responda. 6i haces esto probablemente no querr responder tu pr0ima pre"unta. 3or 7ltimo lo ms importante1 Escucha con atencin. )!estionarios Los cuestionarios son otra t3cnica de elicitacin. Consisten en una serie de preguntas que el entrevistador hace de manera secuencial o que se entregan al entrevistado para que 3l mismo conteste. Los cuestionarios tienen la deficiencia de que no utili*an los elementos de interaccin de la entrevista$ por lo tanto se corre el riesgo de que$ dado que la persona a la que se entrevista

tiene diferente historia y por lo tanto diferentes conocimientos y categoras para clasificar los conceptos$ algunas preguntas se malinterpreten o resulten irrelevantes y fuera de conte%to. Gr!%os de Desarrollo de A%licaciones Consiste en involucrar a los usuarios en el proceso de desarrollo mediante talleres o worMshops en los cuales se identifican los requerimientos. En los talleres pueden utili*arse diferentes t3cnicas para ir descubriendo requerimientos como ;Casos de (so;$ ;1tory Noards;$ ;0odelos; o ;#rototipos;. Los grupos de desarrollo tienen el inconveniente de que no son comunidades naturales$ por lo tanto es difcil que los participantes compartan categoras. Otro riesgo en estos talleres es que$ dadas las &erarquas que e%isten dentro de una empresa$ alguno de los participantes puede no sentirse libre para e%presar su opinin o puede sentirse obligado a dar una opinin sobre un punto que desconoce o en el que 3l no es e%perto. Al,!nas recomendaciones %ara cond!cir !n ,r!%o de desarrollo son. Da a todos la oportunidad de hablar. Esto es esencial para que el 8or,shop se considere imparcial. 3rocura que la sesin se manten"a andando. E0iste una tendencia natural a que el 8or,shop se convierta en una sesin de que+as. Identifica los problemas9requerimientos pero no profundices. 2na ve% que se ha identificado un problema9requerimiento avan%a al si"uiente. 3ermanece alerta para reco"er informacin y halla%"os. .l final* resume la sesin y traba+a en "enerar conclusiones Tormenta de ideas Cuando se est conduciendo una sesin de requerimientos es necesario en ocasiones usar alguna herramienta que permita identificar y clasificar necesidades. (na herramienta muy til para lograr esto es la ;tormenta de ideas;. La Jormenta de Ideas consiste en listar todas las ideas sobre un tema que se le ocurren a un auditorio determinado y posteriormente filtrarlas$ desarrollarlas y priori*arlas. (na sesin de este tipo comien*a con la aclaracin del ob&etivo. El ob&etivo es muy importante porque permite mantener en foco la sesin$ sin embargo no debe de ser limitante para la creatividad de las ideas e%presadas$ es ms las ideas ms descabelladas pueden resultar en soluciones innovadoras. Los participantes deben de aportar ideas sin interrupcin y tantas como sea posible$ para lograr esto$ el moderador debe crear un ambiente en el que la creatividad y la apertura de mente tengan un lugar prioritario$ por e&emplo evitando crticas o debates durante la aportacin de ideas. Cuando las ideas comien*an a repetirse y los participantes empie*an a demorarse mucho tiempo entre idea e idea$ es momento de suspender la sesin y pasar a filtrar$ combinar$ ordenar y priori*ar las ideas. 'l hacer esto$ es necesaria la participacin del grupo mediante debates y consensos. El moderador debe de evitar que la discusin se vuelva personal o que los debates se prolonguen demasiado$ esto puede lograrse usando rondas de votacin con prioridades$ en las cuales a los miembros se les da una cantidad de puntos que deben distribuir entre las diferentes opciones$ nunca asignado ms del ,@A de sus puntos a una opcin. 'l final se suman los puntos y la opcin con ms puntos resulta ganadora. Stor*boards El 1toryboard es una t3cnica tradicionalmente usada en el cine para describir una secuencia o una escena. Consiste en ilustrar o animar cmo el sistema enca&a en la organi*acin para anali*ar el comportamiento del mismo. Los storyboard pueden ser tan simples como un par de tra*os hechos a lpi* o tan complicados como el dise o grfico de una pgina de Keb. 1in embargo es recomendable mantenerlos fciles de hacer y de cambiar$ ya que en el fondo debe ser una herramienta barata que ayude a descubrir requerimientos y necesidades por lo tanto su naturale*a ser cambiar. Cuando se tienen ms claros los requerimientos o cuando se requiere un producto para vender una necesidad a un cliente es ms recomendable usar los prototipos y los demos.

An/lisis El anlisis de los requerimientos consiste en estudiar las necesidades de los clientes para plantearlas en t3rminos de un sistema de software. #ara lograr esto$ e%isten diferentes t3cnicas como diagramas de conte%to$ diagramas de flu&o o diagramas de estado. (0L utili*a la t3cnica de Casos de (so para anali*ar las necesidades de los usuarios y estructurarlas a manera de servicios que el sistema debe proveer. :o debe confundirse el anlisis en el conte%to de requerimientos y el anlisis en el conte%to de actividades de anlisis y dise o del sistema. En el paradigma de ob&etos las actividades de anlisis y dise o no son siempre claramente diferenciables porque un diagrama de clases puede implicar el qu3 del sistema y el cmo. #or lo tanto$ en el paradigma de ob&etos$ una clasificacin para las actividades del ciclo de vida de desarrollo que suele usarse es requerimientos$ anlisis y dise o y codificacin. Es%ecificacin La especificacin consiste en la documentacin de las actividades durante el proceso de =equerimientos. 8e acuerdo a la IEEE-./ e%iste una serie de atributos que debe tener una especificacin de software) (laridad)(arencia de ambi*+edad: Cada uno de los requerimientos tiene una sola interpretacin posible. (ompleta: Jodo lo que el software debe hacer est incluido en las especificaciones. Las respuestas a cualquier tipo de datos de entrada en cualquier situacin posible estn incluidas en las especificaciones. (orrecta: Cada uno de los requerimientos representa algo que el sistema requiere. Entendible: Cualquier tipo de lector puede$ fcilmente$ comprender el significado de todos los requerimientos con una e%plicacin mnima Verificable: E%iste alguna t3cnica finita y costeable que puede ser usada para verificar que cada uno de los requerimientos especificados est incluido en el sistema terminado. (onsistente: :o e%isten conflictos entre requerimientos. ,actible: E%iste por lo menos un dise o y una implementacin que satisfacen todos los requerimientos especificados. $astreable: Est escrita de manera que facilita la referencia de cada requerimiento individual. El origen de cada requerimiento est claro. (oncisa: Es lo ms corta posible$ sin afectar otras cualidades de la especificacin. "ise-o #ndependiente: E%iste ms de un dise o e implementacin que satisface correctamente todos los requerimientos del sistema. .odificable: Jiene una estructura y estilo que permiten hacer cambios de una manera fcil$ completa y consistente. /o redundante: Los requerimientos no estn repetidos Precisa: 1e usan cantidades num3ricas cuando es posible con el apropiado nivel de precisin. Los atributos son una referencia contra la cual evaluar un documento de requerimientos y no implican una estricta e infle%ible comparacin. 7erificar una especificacin de una manera demasiado rgida puede llevar a un proceso muy largo y costoso que$ en muchas ocasiones$ no es &ustificable por el tama o y las caractersticas del proyecto. 'dems puede suceder que algunos de los atributos se contrapongan entre s. #or e&emplo$ una especificacin puede ser factible en el sentido de que hay una nica solucin identificada pero no puede ser de dise o independiente porque slo e%iste una solucin identificada. (na especificacin nunca llegar a ser perfecta$ hay que encontrar un balance adecuado entre la calidad de la especificacin y las necesidades del proyecto.

0erificacin E%isten varias t3cnicas para validar una especificacin$ algunas de las ms importantes son) Verificacin a tra's de rastreo: Implica la revisin de la documentacin por parte de un especialista. 'lgunos autores sugieren que el especialista debe invertir en promedio 9@ minutos en revisar una pgina de documentacin. Pruebas de Validacin: 1on pruebas que se hacen el software para comprobar que este cumpla con algn requerimiento especificado en la documentacin. Pruebas de Aceptacin: 1on pruebas que reali*a el cliente antes de declarar su satisfaccin sobre el producto.

Res!men
Hemos visto que el proceso para la obtencin y documentacin de los requerimientos es iterativo. Estas iteraciones$ bsicamente incluyen) .. Entender y obtener el dominio 2. Benerar el modelo de negocios -diagrama de conte%to de casos de uso/ 9. Especificar los requerimientos #asos que se repiten hasta que los requerimientos son satisfactorios$ habi3ndose reali*ado su elicitacin$ anlisis$ especificacin y verificacin en las distintas iteraciones. #ara entender y obtener el dominio se cuentan con t3cnicas tales como) la introspeccin$ la entrevista abierta$ los cuestionarios$ tormenta de ideas$ entre otros. El modelo de negocios se utili*a tempranamente para entender los lmites$ participantes y procesos del problema de sistemas en estudio. 1e obtiene aplicando las t3cnicas mencionadas. La especificacin de requerimientos puede llevarse a cabo por medio de documentar en forma de lista los enunciados de los requerimientos$ o me&or an$ haci3ndolo mediante casos de uso en forma narrativa. Opcionalmente$ puede generarse un prototipo rpido para asegurarse que se hayan entendido bien los requerimientos y validarlos con el cliente.

E-em%lo
8espu3s de reali*ar una entrevista con el due o de la tienda de Instrumentos !Instrumentos 0usicales"$ se reuni la siguiente informacin. El sistema mantiene informacin de los productos en una base de datos. 1e mantiene la siguiente informacin respecto a cada producto) nombre$ precio$ peso$ una descripcin

te%tual y un apuntador -(=L/ a un archivo de su imagen. El sistema tambi3n mantiene el precio de los dos tipos de envo) por aire y por tierra. Cuando un cliente consulta el catlogo en lnea$ cualquier producto desplegado puede grabarse en el !carrito de compras". 8urante una sesin de compras$ la aplicacin despliega una !factura" por los artculos agregados a la canasta hasta ese momento$ que incluye el costo total de la orden -incluyendo costos de envo/. Cuando el usuario acepta la orden$ una orden completa se transmite a la base de datos. El sistema incluye una interfa* grfica que permite al usuario buscar en el catlogo de productos$ ver productos de forma individual$ agregar productos al carrito$ y enviar la orden. La interfa* tambi3n permite borrar artculos del carrito en cualquier momento o vaciar totalmente el carrito. Jambi3n puede mostrar la historia de rdenes del cliente. 1e gener un modelo de negocios$ se discuti con el cliente y se corrigi$ as que la 2P versin del mismo qued)

%!re!ar producto a la canasta

llo!in Mantenimiento de productos

&orrar art#culo de la canasta

llo!out

%dmin 'aciar canasta $liente %brir una cuenta

Enviar una orden

$onsultar historia de "rdenes %tender una orden Empleado env#os

1e reali*aron varias iteraciones para especificar los requerimientos en forma de casos de uso$ como e&emplo se incluye uno de ellos) Nombre del caso de uso) Norrar artculo de la canasta .ctor primario1 Cliente

:lu+o de eventos t)pico 'ccin del actor 1. El cliente eli!e uno de los productos de la canasta de compras 2. El cliente selecciona eliminar de la canasta

=espuesta del sistema

3. El sistema elimina el art#culo de la canasta ( actualiza el total de la compra. 4. )evuelve el control al caso de uso donde fue invocado.

$ursos .lternativos Lnea 9 El cliente no ha elegido ningn producto de la canasta. El sistema despliega un error y le solicita eli&a un producto. Lnea 9 La canasta est vaca. El sistema despliega un error e%plicando el problema. Los requerimientos no funcionales se documentaron en forma de tabla$ se ane%a una fraccin de ella a continuacin.

Identificador del -equerimiento =. =2

Enunciado del requerimiento El sistema debe procesar solicitudes de compra en menos de , segundos El sistema debe desarrollarse utili*ando la infraestructura tecnolgica e%istente en la empresa -ver 'p3ndice C/ El sistema debe r estar en operacin despu3s de E meses de firmado el contrato.l

3rioridad 'lta 0edia

=9

'lta

1I12IOGRA3A =odrgue* 8ie*$ Bustavo. Ingeniera de =equerimientos. :otas de la clase de 0etodologas de 8ise o de 1istemas 2. Instituto Jecnolgico de Estudios 1uperiores de 0onterrey$ Campus 0onterrey. 2@@.. =ichard H. Jhayer$ 0erlin 8orfman. 1oftware =equirements Engineering$ IEEE .LLQ. Jhe 1tandish Broup$ Chaos =eport$ http)GGstandishgroup.comGvisitorGchaos.htm. 'lan 0. 8avis. #rivate comunications$ .LLE 8ean Leffingwell$ 8on Kidring. 0anaging 1oftware =equirements -' (nifiend 'pproach/. 'ddison Kesley 2@@@.