REQUISITOS

REQUISITOS Introduccin

Hoja: 1.

En las clases anteriores continuamos el estudio de la asignatura Ingeniera de Software I, concretando ya en los primeros elementos del Flujo de Trabajo Captura de Requerimientos, especficamente la Modelacin del Negocio. Desarrollo De acuerdo con el Proceso Unificado de RATIONAL (RATIONAL Unified Process - RUP), el trmino requerimiento puede definirse como una condicin que el sistema debe cumplir o capacidad que debe tener. El Modelo de Capacidad de Madurez ( Capability Madurity Model - CMM) plantea que el propsito de la Gestin de Requerimientos es establecer un entendimiento comn entre el usuario y el proyecto de software de los requerimientos del usuario que sern abordados por el proyecto de software. El establecimiento y mantenimiento del contrato que se establece con el usuario a cerca de los requerimientos para el proyecto de software est comprendido dentro de la gestin de requerimientos. Tanto los requerimientos tcnicos como los no tcnicos se cubren en dicho contrato, por lo que el mismo constituye las bases para la estimacin, el planeamiento, ejecucin y seguimiento de las actividades del proyecto de software a travs del ciclo de vida del software. Con el objetivo de mantener la consistencia, si los requerimientos del sistema asignados al software son cambiados, entonces las actividades, productos de trabajo y planes del software afectados son ajustados tambin. Los requerimientos existen porque el tipo de producto en construccin exige cierta funcionalidad o calidad o porque el usuario quiere que el producto cumpla con ciertos requerimientos. Tipos de Requerimientos: Funcionales y No Funcionales Mientras ms grande e intrincado sea el sistema en desarrollo, ms tipos de requerimientos aparecen cuando se inicia la recoleccin de estos. Mediante la identificacin de los tipos de requerimientos, los equipos de desarrollo de software pueden separar grandes cantidades de requerimientos en grupos que faciliten su manejo, tambin se logra una comunicacin ms clara entre los miembros del equipo, y en general se mejora el manejo del proyecto en su totalidad. Existen dos grandes categoras en las que pueden clasificarse los requerimientos, estas son: Requerimientos Funcionales Requerimientos no Funcionales

Requerimientos Funcionales Los Requerimientos Funcionales especifican acciones que el sistema debe ser capaz de realizar, sin tomar en consideracin ningn tipo de restriccin fsica. Por lo general se describen mejor a travs del modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los requerimientos funcionales especifican el comportamiento de entrada y salida del sistema y surgen de la razn fundamental de la existencia del producto. Por ejemplo: El producto debe calcular el tiempo dedicado a una orden de trabajo especfica. Este requerimiento describe una accin que deber ser llevada a cabo para que el sistema realice el trabajo para el que se concibi. Los requerimientos funcionales son: Las especificaciones de la funcionalidad del sistema. Acciones que el producto debe realizar: chequear, calcular, almacenar, recuperar, etc. Derivados del objetivo fundamental del producto

Todo lo contrario de una cualidad, como por ejemplo rpido, que no es un requerimiento funcional.

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS

Hoja: 2.

Los requerimientos funcionales describen las acciones que debe llevar a cabo el producto, por esto los mismos deben estar claros y libres de ambigedades. As, cuando sea necesario deben reemplazarse los pronombres por los objetos a que se refieren; conviene leer cuidadosamente cada requerimiento en voz alta, y asegurarse que todos los involucrados comprenden claramente el significado de cada uno. Ejemplo basado en el Caso de Estudio de la Galera de Arte Arte Cubano Requerimientos funcionales: 1. 2. 3. 4. 5. 6. 7. 8. 9. Registrar solicitud de exposicin. Asignar automticamente cdigo a una solicitud. Asignar solicitud a un especialista de arte. Enviar correo a especialista de arte sobre solicitud asignada. Registrar informacin de artista. Consultar en el sistema automatizado de RRHH los especialistas de arte. Registrar resultados de las evaluaciones a las obras de una solicitud. Consultar obras aceptadas que no tienen precio. Registrar precio de venta de obras aceptadas.

10. Registrar venta de obras. 11. Enviar correo a artista sobre la venta de sus obras. 12. Consultar informacin sobre obras registradas que no han sido vendidas. 13. Registrar criterios de evaluacin. Casos de uso como parte de los requerimientos funcionales El trmino caso de uso fue usado por primera vez por Ivar Jacobson en los aos 80 como un instrumento para dividir la complejidad del sistema en varios pedazos ms manejables que facilitaran su comprensin y anlisis, estos deben estar basados en la forma en que el sistema es visto por un usuario. Los casos de uso fueron posteriormente incluidos en UML y son extensamente usados como parte del RUP. De acuerdo con el RUP los casos de uso se derivan del anlisis de los requerimientos enriqueciendo requerimientos funcionales a los que se encuentran asociados, aunque tambin pueden existir asociaciones entre los casos de uso y los requerimientos no funcionales, para aadir descripciones cualitativas o propiedades a las descripciones funcionales que solamente indican qu cosas deben realizarse. Por esto los casos de uso se convierten en un concepto fundamental que debe ser comprendido por los clientes y los desarrolladores del sistema. Los usuarios y otros sistemas con los que el sistema debe interactuar son los actores, ayudan a delimitar el sistema y por tanto dar una imagen ms clara de lo que este debe hacer. Los Casos de uso se elaboran basndose en las necesidades de los actores. Esto asegura que el sistema se convertir en lo que los usuarios esperan. Durante las etapas iniciales del ciclo de vida del proyecto se realiza la captura de los requerimientos y de ellos se derivan los casos de uso del sistema que posteriormente sern expandidos para especificar con ms detalles lo que debe hacerse en cada uno de ellos. En esta etapa estos sirven para realizar el anlisis de riesgos y para crear la lnea base1 del sistema. Posteriormente sern utilizados como el punto de partida para la etapa de diseo y la creacin de los planes de prueba, ya que el sistema ser verificado durante la realizacin de cada caso de uso. En el planeamiento de las iteraciones del proyecto tambin sern empleados para determinar los requerimientos que deben ser satisfechos en cada iteracin. Por ltimo, en las etapas finales servirn de base para desarrollar los manuales de usuarios, guas de entrenamientos o cursos de capacitacin y posibilitarn el pedido del producto basado en unidades, lo que puede suceder si por ejemplo el cliente desea comprar el producto configurado con una mezcla especfica de casos de uso.
1

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS
Requerimientos No Funcionales

Hoja: 3.

Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las caractersticas que hacen al producto atractivo, usable, rpido o confiable, por ejemplo, pudiera desearse que el sistema responda dentro de un intervalo de tiempo especificado o que obtenga los resultados de los clculos con un nivel de precisin dado. En muchos casos los requerimientos no funcionales son fundamentales en el xito del producto. Normalmente estn vinculados a requerimientos funcionales, es decir una vez se conozca lo que el sistema debe hacer podemos determinar cmo ha de comportarse, qu cualidades debe tener o cun rpido o grande debe ser. Estas propiedades no se requieren por ser actividades fundamentales del producto como pudieran serlo el clculo, manipulacin de datos, etc., sino porque el cliente desea que las actividades fundamentales se realicen de cierta forma o tengan determinadas cualidades. Los requerimientos funcionales no alteran la funcionalidad del producto, esto quiere decir que los requerimientos funcionales se mantienen invariables sin importarle con que propiedades o cualidades se relacionen. Los requerimientos no funcionales tambin aaden funcionalidad al producto, pues hacen que un producto sea fcil de usar, seguro, o interactivo demanda cierta cantidad de procesamiento. Sin embargo la razn fundamental de que esta funcionalidad sea parte del producto es brindarle a este las caractersticas deseadas. Los requerimientos no funcionales forman una parte significativa de la especificacin. Son importantes para que clientes y usuarios puedan valorar las caractersticas no funcionales del producto, pues si se conoce que el mismo cumple con la toda la funcionalidad requerida, las propiedades no funcionales, como cun usable, seguro, conveniente y agradable, pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptacin. Los requerimientos no funcionales incluyen: Conjunto de facilidades. Capacidades. Seguridad.

Muchos requerimientos son no funcionales y describen solamente los atributos del sistema o los atributos del ambiente del sistema. Aunque muchos de ellos pueden ser capturados en los Casos de uso, los que quedan fuera de esta clasificacin deben documentarse como parte de las especificaciones suplementarias. Utilizando como base los estudios de Suzanne y James Robertson, los cuales realizaron el anlisis de un gran nmero de especificaciones de requerimientos y extrajeron los requerimientos no funcionales ms comunes, adems de las especificaciones del RUP, se propone a continuacin en este documento las siguientes categoras de requerimientos no funcionales: Apariencia o interfaz externa. Usabilidad. Rendimiento. Soporte. Portabilidad. Seguridad y privacidad. Polticos y Culturales. Legales. Confiabilidad. Interfaz interna. Ayudas y documentacin en lnea.

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS
Hardware. Software. Restricciones en el diseo y la implementacin.

Hoja: 4.

No existe nada sagrado ni esttico en las categoras que fueron propuestas y se recomienda que se modifiquen y ajusten a las necesidades particulares del proceso de extraccin de requerimientos que se est usando, y que nuevas categoras sea aadidas a medidas que se encuentren. Sin embargo esta lista puede ser usada como gua puede facilitar mucho el proceso si se utiliza de base para la clasificacin. A continuacin se analiza cada una de las categoras con un poco ms de detalle. Requerimientos de apariencia o interfaz externa Este tipo de requerimiento describe la apariencia del producto. Es importante destacar que no se trata del diseo de la interfaz en detalle sino que especifican cmo se pretende que sea la interfaz externa del producto. Atendiendo a este criterio podemos decir, por ejemplo, producto debe ser: Muy legible. Simple de usar. Autoritario, para que los usuarios se sientan confiados. Discreto para que los usuarios no lo noten. Colorido y atractivo para los nios. Interactivo. Profesional o tipo ejecutivo.

Los requerimientos de apariencia se vuelven ms importantes a medida que los productos de software se mueven hacia reas ms orientadas al consumidor. Productos muy sofisticados como las cmaras digitales, cmaras de video u organizadores personales le dan la impresin a los clientes de ser muy fciles de operar, sin embargo contienen un gran nivel de funcionalidad. Si se siente tentado a usar el prototipo para describir los requerimientos de apariencia e interfaz externa del producto, recuerde que el mismo no expresa los requerimientos, sino el resultado de estos. Requerimientos de apariencia tambin pueden ser necesidades de cumplir con normas estndares como por ejemplo las interfaces de sistemas tipo Windows/Apple/Motif, o con los estndares de la empresa para la cual se est desarrollando el software. Requerimientos de Usabilidad Estos requerimientos describen los niveles apropiados de usabilidad, dados los usuarios finales del producto, para ello debe revisarse la especificaciones de los perfiles de usuarios y echarle un vistazo a las clasificaciones de sus niveles de experiencia. Debe conocerse: Qu tipo de personas son?. Qu tipo de producto necesitan para realizar su trabajo?. Qu tipo de requerimiento de usabilidad hara el producto adecuado para ellos?.

Los requerimientos de usabilidad se derivan de una combinacin de lo que el cliente est tratando de lograr con el producto y lo que los usuarios finales esperan del mismo, estos elementos deben tenerse claro antes de escribirlos. Estos requerimientos tambin pueden cubrir otros aspectos como: Porciento de aceptacin por los usuarios.

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS
Productividad ganada con la introduccin del producto. Proporcin de errores (y por consiguiente su reduccin).

Hoja: 5.

Facilidad de uso por personas que hablen otros idiomas distintos al del pas donde el producto fue creado. Accesibilidad para personas discapacitadas. Consistencia en la interfaz de usuario. Documentacin de usuario, material de entrenamiento. (Nunca debe olvidarse!) Facilidad de uso por personas sin experiencia previa con las computadoras

Requerimientos de Rendimiento Imponen condiciones a los Requerimientos Funcionales. Por ejemplo, para una accin especifica pueden definirse parmetros tales como: Velocidad de procesamiento o clculo. Eficiencia. Disponibilidad. Precisin. Tiempo de respuesta. Tiempo de recuperacin. Aprovechamiento de los recursos.

La necesidad de velocidad debe ser genuina, muchas veces se desea que las cosas se realicen rpidamente sin que exista una razn real para esto, por ejemplo para producir un reporte mensual, no hay necesidad de hacerlo rpidamente, por otro lado el xito del producto puede depender de la velocidad, y, en el caso de los sistemas en tiempo real, muchos de los requerimientos de rendimientos son indispensables para su funcionamiento. Requerimientos de Soporte Abarcan todas las acciones a tomar una vez que se ha terminado el desarrollo del software con motivos de asistir a los clientes de este as como lograr su mejoramiento progresivo y evolucin en el tiempo. Pueden incluir: Pruebas. Extensibilidad. Adaptabilidad. Mantenimiento. Compatibilidad. Configuracin. Servicios. Instalacin. Internacionalizacin.

Requerimientos de Portabilidad

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS

Hoja: 6.

Deben usarse para especificar que el producto de software podr ser usado en diferentes plataformas, por ejemplo: El producto podr ser usado bajo el sistema operativo Linux. Es importante tener en cuenta que el documento de los requerimientos es un contrato que se establece con el cliente, en este caso se est afirmando que el producto ser implementado en algn momento en la nueva plataforma. Podr especificarse tambin las caractersticas de esta as como el tiempo necesario para realizar la transicin. Requerimientos de Seguridad Este es quizs el tipo de requerimiento ms difcil, que provocar los mayores riesgos si no se maneja correctamente. La seguridad puede ser tratada en tres aspectos diferentes: Confidencialidad: La informacin manejada por el sistema esta protegida de acceso no autorizado y divulgacin. Integridad: la informacin manejada por el sistema ser objeto de cuidadosa proteccin contra la corrupcin y estados inconsistentes, de la misma forma ser considerada igual a la fuente o autoridad de los datos. Pueden incluir tambin mecanismos de chequeo de integridad y realizacin de auditoras. Disponibilidad: Significa que los usuarios autorizados se les garantizar el acceso a la informacin y que los dispositivos o mecanismos utilizados para lograr la seguridad no ocultarn o retrasarn a los usuarios para obtener los datos deseados en un momento dado.

Requerimientos Polticos y Culturales Son factores especiales que pudieran hacer el producto no utilizable debido a costumbres humanas, preferencias o prejuicios. La razn fundamental de este tipo de requerimientos aparece cuando se trata de vender el producto en otro pas especialmente con una cultura e idioma diferente al pas en que se produjo. Tambin deben ser considerados los requerimientos polticos que muchas veces pueden resultar algo controversiales, o no muy recomendados, sin embargo existen y por tanto son incluidos en esta categora. Muchas veces no se conoce la justificacin de ellos, pues pueden surgir nicamente de la orden de una persona de alto nivel jerrquico dentro de la sociedad o empresa. Cabe destacar que en este contexto el trmino poltico no se aplica para hacer referencias a la poltica al nivel de pas, sino tambin a escalas menores como es el caso del nivel de empresa, sucursal o departamento, por solo citar algunos. Ejemplos de este tipo de requerimiento son: El producto no debe manejar facturas de la empresa A. El producto no debe contener expresiones que resulten contradictorias a miembros del Grupo de Proteccin Ambiental. En otras ocasiones, sucede que un requerimiento no puede ser introducido en una de las categoras regulares, y se toma como solucin incluirlo en esta. Requerimientos Legales Son los requerimientos que estipulan las formas en que el software cumple con las leyes vigentes. Incluso para el software que se construye para ser usado dentro de una organizacin deben observarse las leyes internas de la institucin para lograr su cumplimiento por parte del sistema. Muchas veces ser necesario acudir a los abogados para la obtencin de estos requerimientos. Tambin ser necesario enunciar el cumplimiento con estndares, como por ejemplo, la norma ISO 2 9000. Requerimientos de confiabilidad
2

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS

Hoja: 7.

Los requerimientos caracterizan la respuesta del sistema ante los fallos o indican cun robusto de este, posibles factores a ser considerados son: Frecuencia y severidad de los fallos. Proteccin contra fallos. Recuperacin. Prediccin de fallos. Tiempo medio entre fallos.

Requerimientos de interfaz Interna Con este tipo de requerimiento se enuncian las diferentes vas de interactuar con el sistema a travs de software, pudiera declararse el soporte de modelos de objetos estndares tales como COM, DCOM, CORBA, etc. Tambin se especifican las interfaces a componentes comprados o reusados de otras aplicaciones, u otros componentes usados que quedan fuera del alcance del documento de especificacin de requerimiento que se este realizando. Requerimientos de Ayudas y Documentacin en lnea. Se incluye en caso de existir requerimientos vinculados al sistema de ayuda, documentacin en lnea, soporte tcnico, etc. En esta seccin debe incluirse tambin las instrucciones de instalacin, fichero README.TXT en el directorio de los instaladores, estilo de etiquetamiento que sern incluidos en el cdigo como es el caso de los enunciados de los derechos de autor, logos corporativos, iconos y otros elementos de la interfaz de usuario que deban mantenerse consistente con el resto de la documentacin. Requerimientos de Software. Debe mencionarse el software del que se debe disponer, por ejemplo: Sistema Operativo Windows 95 o Superior; Maquina Virtual de Java versin 1.3 o Superior; etc. Requerimientos de Hardware. Al igual que en la seccin anterior enunciar aqu los elementos de hardware de que se disponen, por ejemplo: se requiere disponer de un MODEM estndar o una tarjeta digitalizadora de video, etc. Restricciones en el diseo y la implementacin Este tipo de requerimiento especifica o restringe la codificacin o construccin de un sistema, son restricciones que han sido ordenadas y deben ser cumplidas estrictamente . Ejemplos de ellas son: Estndares requeridos. Lenguajes de programacin a ser usados para la implementacin. Uso obligatorio de ciertas herramientas de desarrollo. Restricciones en la arquitectura o el diseo. Bibliotecas de clases.

El proceso de Gestin de Requerimientos El Manejo de requerimientos no es ms que un conjunto de tcnicas que estn enfocadas a encontrar, documentar, organizar y seguir los cambios de los requerimientos de un sistema. Permiten tambin establecer un acuerdo entre el cliente y el equipo del proyecto sobre los requerimientos que cambian. La recogida de los requerimientos parece ser una tarea sencilla, sin embargo en la prctica pueden surgir muchas complicaciones, entre ellas:

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS
Roles Papel que desempea cada integrante dentro del ciclo de vida de un proyecto de software: Analista de sistema. Especificador de casos de uso. Arquitecto. Diseador de la interfaz. Los requerimientos no siempre son tan obvios y pueden tener muchas fuentes. No siempre pueden ser expresados claramente con palabras. Existen varios tipos de requerimientos con diferentes niveles de detalle. El nmero de requerimientos puede volverse no manejable si no se controla.

Hoja: 8.

Los requerimientos pueden estar relacionados entre ellos y con las diferentes entregas del sistema en una gran variedad de formas. Los requerimientos tienen propiedades y valores nicos, por ejemplo ninguno es igualmente importante o igualmente fcil de satisfacer. Existen varias partes interesadas y responsables lo que hace que las necesidades entre los diferentes grupos puedan estar interrelacionadas. Los requerimientos pueden cambiar y ser sensitivos al transcurso del tiempo.

Analista de sistema: Conduce y coordina la extraccin de requerimientos y la modelacin de casos de uso, perfilando la funcionalidad del sistema y delimitndolo. Especificador de casos de uso: Detalla toda o parte de la funcionalidad de un sistema describiendo los requerimientos de uno o varios casos de uso.

Arquitecto: Es responsable de identificar los casos de uso y requerimientos arquitectura y contribuir a su definicin.

ms significativos para la

Diseador de la interfaz: Es responsable de realizar el prototipo de interfaz y definir las clases frontera. Documentos para la Gestin de Requisitos Aunque se utilice una herramienta de manejo de requisitos, la descripcin textual es el punto de partida para la mayora de los tipos de requisitos. Existen plantillas estndar de documentos, pero estos deben ser adaptados a las necesidades de cada empresa e incluso de cada proyecto. Tipos de documentos Visin: vista general del sistema, caractersticas principales, opciones importantes, necesidades claves de los clientes, servicios brindados. Glosario: para expresar los requisitos del cliente en trminos consistentes, capta y define los trminos usados en el proyecto. Casos de uso: describe que pasa dentro del sistema y no el cmo ni el por qu. Son buenos para documentar los requisitos funcionales del software.

Asignatura: Ingeniera de Software II.

Curso 2013.

REQUISITOS
Especificacin suplementaria: capta los requisitos no asociados directamente a los casos de uso. Ingeniera de requisitos

Hoja: 9.

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. 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. Fases de implementacin 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. Identificacin de las personas involucradas 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 requisitos 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 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 Sobreespecificacin de los requisitos

Asignatura: Ingeniera de Software II.

Curso 2013.

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

Hoja: 10.

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. JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): Esta tcnica resulta una alternativa a las entrevistas. Es una prctica de grupo que se desarrolla durante varios das y en la que participan analistas, usuarios, administradores del sistema y clientes (IBM, 1997). Est basada en cuatro principios fundamentales: dinmica de grupo, el uso de ayudas visuales para mejorar la comunicacin, mantener un proceso organizado y racional y una filosofa de documentacin WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene), es decir, durante la aplicacin de la tcnica se trabajar sobre lo que se generar. Tras una fase de preparacin del JAD al caso concreto, el equipo de trabajo se rene en varias sesiones. En cada una de ellas se establecen los requisitos de alto nivel a trabajar, el mbito del problema y la documentacin. Durante la sesin se discute en grupo sobre estos temas, llegndose a una serie de conclusiones que se documentan. En cada sesin se van concretando ms las necesidades del sistema.

Asignatura: Ingeniera de Software II.

Curso 2013.