Tecnica Recopilacion de Requerimientos

Repblica Bolivariana De Venezuela
Ministerio Del Poder Popular Para La Educacin Universitaria

Universidad Politcnica Territorial Del Estado Aragua
Federico Brito Figueroa
La Victoria Estado Aragua
PNF en Informtica
Unidad Curricular: Ingeniera de Software II
Prof. Ing. Omar Rosales
1

TCNICAS DE RECOPILACIN DE REQUERIMIENTOS

El descubrimiento de requerimientos es el proceso de recoger informacin sobre el sistema propuesto y
los existentes y extraer los requerimientos del usuario y del sistema de esta informacin. Las fuentes de
informacin durante la fase del descubrimiento de requerimientos incluyen la documentacin, los
stakeholders del sistema y la especificacin de sistemas similares.

Nosotros nos relacionaremos con los stakeholders a travs de entrevistas y de la observacin y se puede
utilizar escenarios y prototipos para ayudar al descubrimiento de requerimientos. Entre los stakeholders
podemos encontrar desde los usuarios finales del sistema hasta los gerentes y stakeholders externos
como los reguladores, quienes certifican la aceptabilidad del sistema.

Adems de los stakeholders del sistema, ya hemos visto que los requerimientos pueden venir del
dominio de la aplicacin y de otros sistemas que interactan con el sistema a especificar. Todos estos se
deben considerar durante el proceso de obtencin de requerimientos. Estas fuentes de requerimientos
(stakeholders, dominio, sistemas) se pueden representar como puntos de vista del sistema, donde cada
uno presenta un subconjunto de requerimientos para el sistema. Cada punto de vista proporciona una
perspectiva nueva en el sistema, pero estas no son completamente independientes. Por lo general
coinciden parcialmente, por lo que tienen requerimientos comunes.

PUNTOS DE VISTA

Un punto clave del anlisis orientado a puntos de vista es que reconoce varias perspectivas y
proporcionar un marco de trabajo para descubrir conflictos en los requerimientos propuestos por
diferentes stakeholders. Los puntos de vista se pueden utilizar como una forma de clasificar los
stakeholders y otras fuentes de requerimientos. Existen tres tipos genricos de puntos de vista:
I. Puntos de vista de los interactuadores: representan a las personas u otros sistemas que interactan
directamente con el sistema.
2. Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema ellos mismos
pero que influyen en los requerimientos de algn modo.

3. Puntos de vista del dominio: representan las caractersticas y restricciones del dominio que influyen
en los requerimientos del sistema.

Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos. Los puntos de
vista de los interactuadores proporcionan requerimientos detallados del sistema que cubren las
caractersticas e interfaces del mismo. Los puntos de vista indirectos es ms probable que proporcionen
requerimientos y restricciones organizacionales de alto nivel.
PNF en Informtica
2

Los puntos de vista del dominio proporcionan restricciones del dominio que se aplican al sistema. La
identificacin inicial de los puntos de vista que son relevantes a un sistema a veces puede ser difcil.
Para ayudar a este proceso, se debera intentar identificar tipos de puntos de vista ms especficos.

Casi todos los sistemas organizacionales deben interactuar con otros sistemas en la organizacin.
Cuando se disea un sistema nuevo, se deben disear las interacciones con los otros sistemas. Las
interfaces ofrecidas por estos otros sistemas ya se han diseado. Estas pueden poner requerimientos y
restricciones en el sistema nuevo. Adems, los sistemas nuevos se pueden tener que ajustar a las
regulaciones y estndares existentes, y estos restringen los requerimientos del sistema.

Se deben identificar los requerimientos no funcionales y de negocio de alto nivel al inicio del proceso
de ingeniera de requerimientos. Las fuentes de estos requerimientos pueden ser puntos de vista tiles
en un proceso ms detallado. Pueden ser capaces de ampliar y desarrollar los requerimientos de alto
nivel en requerimientos del sistema ms especficos. Los puntos de vista de la ingeniera pueden ser
importantes por dos razones.

En primer lugar, los ingenieros que desarrollan el sistema pueden tener experiencia con sistemas
similcionalidad al usuario. Para productos software, el departamento de marketing debera conocer que
caractersticas del sistema lo harn ms comercializable para los compradores potenciales.
ares y sugerir requerimientos a partir de esa experiencia. En segundo lugar, el personal tcnico que
tiene que administrar y mantener el sistema puede tener requerimientos que ayuden a simplificar el
soporte del sistema. Los requerimientos de administracin del sistema son cada vez mas importantes
debido a que los costes de administracin del sistema son una proporcin creciente de los costes totales
para un sistema.

Finalmente, los puntos de vista que proporcionan requerimientos pueden venir de los departamentos de
marketing y asuntos externos en una organizacin. Esto es especialmente cierto para sistemas basados
en web, particularmente sistemas de comercio electrnico y productos software empaquetados. Los
sistemas basados en web deben presentar una imagen favorable de la organizacin adems de entregar
funcionabilidades.

Para cualquier sistema no trivial existe un enorme nmero de posibles puntos de vista, y es
prcticamente imposible obtener requerimientos de todos ellos. Por lo tanto, es importante organizar y
estructurar los puntos de vista en una jerarqua. Es probable que los puntos de vista en la misma rama
compartan requerimientos comunes.

Una vez que se han identificado y estructurado los puntos de vista, se debe intentar identificar los ms
importantes y empezar con ellos al descubrir los requerimientos del sistema.

ENTREVISTAS
PNF en Informtica
3

Las entrevistas formales o informales con los stakeholders del sistema son parte de la mayora de los
procesos de la ingeniera de requerimientos. En estas entrevistas, el equipo de la ingeniera de
requerimientos hace preguntas a los stakeholders sobre el sistema que utilizan y sobre el sistema a
desarrollar. Los requerimientos provienen de las respuestas a estas preguntas. Las entrevistas pueden
ser de dos tipos:

1. Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de preguntas.
2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de ]a ingeniera de
requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto,
desarrolla una mejor comprensin de sus necesidades.

En la prctica, las entrevistas con los stakeholders normalmente son una mezcla de estos. Las
respuestas a algunas preguntas pueden conducir a otras cuestiones que se discuten de una forma menos
estructurada. Las discusiones completamente abiertas raramente salen bien; la mayora de las
entrevistas requieren algunas preguntas para empezar y para mantener la entrevista centrada en el
sistema a desarrollar.

Las entrevistas sirven para obtener una comprensin general de lo que hacen los stakeholders, como
podran interactuar con el sistema y las dificultades a las que se enfrentan con los sistemas actuales. A
la gente le gusta hablar sobre su trabajo y normalmente se alegran de verse implicados en las
entrevistas. Sin embargo, no son de tanta utilidad para la comprensin de los requerimientos del
dominio de la aplicacin.

Es difcil obtener conocimiento del dominio durante las entrevistas debido a dos razones:

1. Todos los especialistas de la aplicacin utilizan terminologa y lenguaje especifica de un dominio. Es
imposible para ellos discutir requerimientos del dominio sin utilizar esta terminologa. Normalmente la
utilizan de un modo preciso y sutil, por lo que es fcil que la malinterpreten los ingenieros de
requerimientos.
2. Cierto conocimiento del dominio es tan familiar para los stakeholders que lo encuentran difcil de
explicar o piensan que es tan bsico que no merece la pena mencionarlo.

Las entrevistas no son una tcnica eficaz para obtener conocimiento sobre los requerimientos y
restricciones organizacionales debido a que existen sutiles poderes e influencias entre los stakeholders
en la organizacin. Las estructuras organizacionales publicadas rara vez se corresponden con la
realidad de la toma de decisiones en una organizacin, pero los entrevistados pueden no desear revelar
la estructura real en vez de la terica a un desconocido. En general, la mayora de la gente es reacia a
discutir cuestiones polticas y organizacionales que pueden influir en los requerimientos.

Los entrevistadores eficaces tienen dos caractersticas:
PNF en Informtica
4

1. No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y estn dispuestos a
escuchar. Si el stakeholder propone requerimientos sorprendentes, estn dispuestos a cambiar su
opinin del sistema.
2. Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta de
requerimientos o sugiriendo trabajar juntos en un prototipo del sistema. Decir a la gente dime
lo que quieres es improbable que cause informacin de utilidad. La mayora de la gente
encuentra mucho ms fcil hablar en un contexto definido en vez de en trminos generales.
3. La informacin de la entrevistas complementa otras informaciones sobre el sistema de los
documentos, observaciones de los usuarios, etc. Algunas veces, aparte de la informacin de los
documentos, las entrevistas pueden ser la tcnica fuente de informacin sobre los
requerimientos del sistema. Sin embargo, las entrevistas por si mismas tienden a omitir
informacin esencial, por lo que deberan ser usadas al lado de otras tcnicas de obtencin de
requerimientos.

ESCENARIOS

Normalmente, las personas encuentran ms fcil dar ejemplos de la vida real que descripciones
abstractas. Pueden comprender y criticar un escenario de cmo podra interactuar con un
sistema software. Los ingenieros de requerimientos pueden utilizar la informacin obtenida de
esta discusin para formular los requerimientos reales del sistema.

Los escenarios pueden ser especialmente tiles para agregar detalle a un esbozo de la
descripcin de requerimientos. Son descripciones de ejemplos de las sesiones de interaccin.

Cada escenario abarca una o ms posibles interacciones. Se han desarrollado varias formas de
escenarios, cada una de las cuales proporciona diferentes tipos de informacin en diferentes
niveles de detalle sobre el sistema. Utilizar escenarios para describir requerimientos es una parte
fundamental de los mtodos giles.

El escenario comienza con un esbozo de la interaccin y durante la obtencin se agregan
detalles para crear una descripcin completa de esta interaccin. De forma general, un escenario
puede incluir:

1. Una descripcin de lo que esperan el sistema y los usuarios cuando el escenario comienza.
2. Una descripcin del flujo normal de eventos en el escenario.
3. Una descripcin de lo que puede ir mal y cmo manejarlo.
4. Informacin de otras actividades que se podran Ilevar a cabo al mismo tiempo.
5. Una descripcin del estado del sistema cuando el escenario termina.

Es posible llevar a cabo de manera informal la obtencin de requerimientos basada en
escenarios cuando los ingenieros de requerimientos trabajan con los stakeholders en la
PNF en Informtica
5

identificacin de escenarios y en la captura de detalles de dichos escenarios. Los escenarios se
pueden redactar como texto, complementados por diagramas, fotografas de las pantallas, etc.
De forma alternativa, se puede adoptar un enfoque ms estructurado, como los escenarios de
evento o los casos de uso.

CASOS DE USO

Los casos de uso son una tcnica que se basa en escenarios para la obtencin de
requerimientos.

En su forma ms simple, un caso de uso identifica el tipo de interaccin y los actores
involucrados. El conjunto de casos de uso representa todas las posibles interacciones a
representar en los requerimientos del sistema.

Algunas veces existe confusin sobre si un caso de uso es un escenario o, como sugiere Fowler
(Fowler y Scott, 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de estos
es un hilo nico a travs del caso de use. Si un escenario incluye mltiples hilos, habr un
escenario para la interaccin normal y escenarios adicionales para las posibles excepciones.

Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser
documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en ms
detalle. Los diagramas de secuencia se utilizan a menudo para aadir informacin a un caso de
uso. Estos muestran los actores involucrados en la interaccin, los objetos con los que
interactan y las operaciones asociadas con estos objetos.

UML es un estndar de facto para el modelado orientado a objetos, por lo que los casos de uso y
la obtencin de requerimientos basada en casos de uso se utilizan cada vez ms para la
obtenci6n de requerimientos.

Los escenarios y los casos de use son tcnicas eficaces para obtener requerimientos para los
puntos de vista de los interactuadores, donde cada tipo de interaccin se puede representar
como un caso de uso. Tambin se pueden utilizar conjuntamente con algunos puntos de vista
indirectos cuando stos reciben resultados (como un informe de gestin) del sistema. Sin
embargo, debido a que se centran en las interacciones, no son tan eficaces para obtener
restricciones y requerimientos de negocio y no funcionales de alto nivel de puntos de vista
indirectos o para descubrir requerimientos del domino.

PNF en Informtica
6

ETNOGRAFA

Los sistemas software no existen de forma aislada: se utilizan en un contexto social y
organizacional, y los requerimientos de sistemas software se pueden derivar y restringir segn
ese contexto. A menudo, satisfacer estos requerimientos sociales y organizacionales es crtico
para el xito del sistema. Una razn de por qu muchos sistemas software se entregan pero
nunca se utilizan es que no se tiene en cuenta adecuadamente la importancia de este tipo de
requerimientos del sistema.

La etnografa es una tcnica de observacin que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por si solo en el entorno
laboral donde se utilizara el sistema. Observa el trabajo diario y anota las tareas reales en las
que los participantes estn involucrados. El valor de la etnografa es que ayuda a los analistas a
descubrir los requerimientos implcitos que reflejan los procesos reales ms que los formales en
los que la gente est involucrada.

A menudo, a la gente le resulta muy difcil articular detalles de su propio trabajo debido a que lo
asumen como algo completamente natural. Comprenden su propio trabajo pero no su relacin
con las dems tareas en la organizaci6n. Los factores sociales y organizacionales que afectan al
trabajo, pero que no son obvios para las personas, es posible que s6lo queden claros cuando se
fije en ellos un observador imparcial.

Suchman (Suchman, 1987) utiliz la etnografa para estudiar el trabajo de oficina y observ que
las prcticas del trabajo real eran macho ms ricas, ms complejas y ms dinmicas que los
modelos sencillos supuestos por los sistemas de automatizacin de oficinas.

La diferencia entre el trabajo supuesto y el real fue la razn ms importante de por qu estos
sistemas de oficina no han tenido efectos significativos en la productividad.

La etnografa es especialmente efectiva para descubrir dos tipos de requerimientos:

1. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente ms que
de la forma en la que las definiciones de los procesos establecen que debera trabajar.
2. Los requerimientos que se derivan de la cooperacin y conocimiento de las actividades de la
gente.

La etnografa se puede combinar con la construccin de prototipos. La etnografa suministra
informacin al desarrollo del prototipo de forma que se requieran menos ciclos de refinamiento.
Adems, la construcci6n de prototipos se centra en la etnografa para identificar problemas y
preguntas que se puedan discutir posteriormente con el etngrafo.

PNF en Informtica
7

Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que otras tcnicas
de obtencin de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el
usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o
del dominio. Los estudios etnogrficos no siempre pueden identificar nuevas propiedades que
se deban agregar al sistema. Por lo tanto, la etnografa no es un enfoque completo para la
obtenci6n de requerimientos por s mismo, y debe utilizarse para complementar otros enfoques,
como el anlisis de casos de uso.

CUESTIONARIOS

Es un conjunto de preguntas que deben ser contestadas por escrito por una determinada
poblacin, generalmente esta poblacin es amplia. Segn el contenido de los cuestionarios
podemos clasificarlos en los siguientes tipos: 1. Abiertos: Las respuestas no estn delimitadas,
esto permite mayor libertad de expresin. 2. Cerrados: Se fuerza a respuestas concretas. Un
mismo tipo de pregunta puede formularse para obtener diferente rango de respuestas: Eleccin
exclusiva (respuestas del tipo si/no). Por ejemplo: Cree que existen muchos circuitos
integrados defectuosos? Escala cualitativa (acuerdo/desacuerdo). Por ejemplo: Existen muchos
circuitos integrados defectuosos. Las posibles respuestas son: de acuerdo, totalmente de
acuerdo, no estoy seguro, en desacuerdo, totalmente en desacuerdo. Cantidad, es decir, la
pregunta requiere como respuesta una determinada cantidad. Por ejemplo: De cada 100
circuitos integrados cuntos son defectuosos? Rango o escala cuantitativa, donde la respuesta
es un rango de valores. Por ejemplo: De cada 100 circuitos integrados son defectuosos (05, 6
10, >50, etc.) Seleccin de respuestas limitadas. Por ejemplo: Las causas ms frecuentes de
circuitos integrados defectuosos son: a) Fallo en la impresin de la pista. b) Fallo en la conexin
de las patillas. c) Fallo en el encapsulado de plstico. 3. Mixtos: una combinacin de los
anteriores Los buenos cuestionarios no solo se escriben sino que se disean. Una buena
elaboracin acompaada de una prueba previa, tanto del formato como de las preguntas, son la
base de una recopilacin de datos significativa a travs del cuestionario. Puntos que ayudarn
en la formulacin de un cuestionario: 1. Determinar qu datos necesitan recabarse y qu
personas son las ms calificadas para proporcionarlos. Si hay otros grupos que pueden
proporcionar datos variantes y mayor visin tambin se identificarn. 2. Seleccionar el tipo de
cuestionario a utilizar (abierto, cerrado o mixto). 3. Desarrollar un grupo de preguntas para
incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes,
pueden ser tiles al asegurar respuestas consistentes por parte de quien responda. 4. Examinar el
cuestionario para encontrarle fallos y defectos, como: a) Interrogantes innecesarias. b)
Preguntas que pueden ser mal interpretadas debido a su enfoque o forma de escritura. c)
Preguntas que el sujeto posiblemente no pueda responder, dado que desconoce la respuesta. d)
Preguntas que estn escritas de forma que se escoger la respuesta preferida. e) Preguntas que
se interpretarn de forma diferente dependiendo del marco de referencia de cada entrevistado. f)
Preguntas que no proporcionan opciones adecuadas de respuesta. g) Un ordenamiento no
PNF en Informtica
8

adecuado de las preguntas o respuestas. 5. Probar previamente el cuestionario en un grupo
pequeo de personas, para detectar otros problemas posibles. As no solamente se describen los
problemas en cuanto a su escritura, espaciado, ortografa, y mtodos de registro de respuestas,
sino tambin proporciona una indicacin del tipo de respuestas que se recopilarn en un grupo
mayor. Si existen muchas respuestas inesperadas, se captarn durante la prueba previa. Hay que
asegurar que la muestra de prueba sea comparable al grupo mayor que recibir el cuestionario.
6. Analizar las respuestas del grupo de prueba para asegurar que el anlisis de los datos que se
busca puede llevarse a cabo con el tipo de datos recopilados. Si estos datos no revelan algo que
los analistas no reconocen y no necesitan verificar, el cuestionario puede no ser necesario en su
forma actual. 7. Realizar cambios finales de edicin, correcciones de mecanografa y ajustes en

la forma; entonces imprimir el cuestionario en una forma limpia y legible. 8. Distribuir el
cuestionario. Cuando sea posible, anotar el nombre de cada persona. Ventajas 1. En su mayora,
los cuestionarios pueden ser contestados con rapidez. Los encuestados pueden completar y
remitir los cuestionarios cuando mejor les convenga. 2. Los cuestionarios ofrecen un medio
relativamente econmico para recoger datos de un amplio nmero de personas. 3. Los
cuestionarios permiten a las personas mantener el anonimato. Por consiguiente, es ms probable
que stas informen de los hechos reales, en vez de decir lo que piensan que su jefe aprobara
que dijera. 4. Las respuestas pueden incluirse en tablas y analizarse rpidamente. Desventajas 1.
El nmero de encuestados es, a menudo, insuficiente. 2. No existe garanta de que los
encuestados respondan o expliquen todas las preguntas. 3. Los cuestionarios suelen ser poco
flexibles. Impiden que el analista de sistemas obtenga informacin voluntaria de las personas o
replantee preguntas que puedan haber sido malinterpretadas. 4. El analista de sistemas no tiene
la posibilidad de observar y analizar el lenguaje corporal del encuestado. 5. No existe una
oportunidad inmediata para aclarar respuestas vagas o incompletas a una pregunta.

MAPAS MENTALES

Generalmente cuando se realiza una entrevista -en este caso nosotros- observamos, escuchamos
y tratamos de tomar notas para recordar y definir lo que estamos escuchando.

Sin embargo frecuentemente sucede que cuando queremos ocupar dicha informacin, nos
cuesta un poco de trabajo darle sentido a esas notas y entenderlas de nuevo. Otro punto en
contra de "tomar notas" es el hecho de que no podemos detallar mucho, pues perdemos parte de
la informacin de la entrevista.

Un mapa mental es una forma de tomar notas ms completas y extensas. Con los mapas
mentales utilizamos smbolos, palabras, imgenes y colores para capturar la esencia del tema
que estamos tratando. Al revisarlo despus, gracias a la informacin personalizada, ser ms
fcil recordar detalles que de otra forma se hubieran perdido al tomar nota de forma
convencional.
PNF en Informtica
9

Los mapas mentales no solo funcionan como una forma de enriquecer las notas que tomamos,
sino que otra de sus funcionalidades es para realizar un resumen sobre lo que entendimos de una
lectura.

LLUVIA DE IDEAS

Es una tcnica de grupo para generar ideas originales en un ambiente relajado. Esta herramienta
creada en el ao 1941 por Alex Osborne, cuando su bsqueda de ideas creativas result en un
proceso interactivo de grupo no estructurado de lluvia de ideas que generaba ms y mejores
ideas que las que los individuos podian producir trabajando de forma independiente. NO
ESTRUCTURADO (Flujo libre) 1. Escoger a alguien para que sea el facilitador y apunte las

ideas. 2. Escribir en un rotafolio o en un tablero una frase que represente el problema y el
asunto de discusin. 3. Escribir cada idea en el menor nmero de palabras posible. Verificar con
la persona que hizo la contribucin cuando se est repitiendo la idea. No interpretar o cambiar
las ideas. 4. Establecer un tiempo lmite. 5. Fomentar la creatividad. Construir sobre las ideas de
otros. Los miembros del grupo de Lluvia de Ideas y el facilitador nunca deben criticar las ideas.
6. Revisar la lista para verificar su comprensin. 7. Eliminar las duplicaciones, problemas no
importantes y aspectos no negociables. Llegar a un consenso sobre los problemas que parecen
redundantes o no importantes. ESTRUCTURADO (En crculo) Tiene las mismas metas que la
Lluvia de Ideas No Estructurada. La diferencia consiste en que cada miembro del equipo
presenta sus ideas en un formato ordenado (ej. de izquierda a derecha). No hay problema si un
miembro del equipo cede su turno si no tiene una idea en ese instante. SILENCIOSA (lluvia de
ideas escritas) Es similar a la Lluvia de Ideas, los participantes piensan las ideas pero registran
en papel sus ideas en silencio. Cada participante pone su hoja en la mesa y la cambia por otra
hoja de papel. Cada participante puede entonces agregar otras ideas relacionadas o pensar en
nuevas ideas. Este proceso continua por cerca de 30 minutos y permite a los participantes
construir sobre las ideas de otros y evitar conflictos o intimidaciones por parte de los miembros
dominantes.

PROTOTIPOS

Los prototipos constituyen la manera ms fcil de validar los requerimientos del sistema dado
que el usuario puede trabajar sobre un elemento concreto y no abstracto como son los modelos.
Segn el rea de aplicacin que se est analizando el prototipo puede ser distinto. Por ejemplo,
en el caso de una aplicacin interactiva la descripcin de la funcionalidad podra realizarse
mediante la presentacin de las pantallas, mens, dilogos, etc. En el caso de una aplicacin de
procesamiento de informacin el prototipo podra mostrar la informacin de entrada y la
informacin de salida, sin detallar, necesariamente, el algoritmo asociado. En el caso de una
aplicacin web, el prototipo podra incluir las pginas del sistema con una simulacin de la
navegacin deseada.
PNF en Informtica
10

Cuando se utilizan prototipos para la identificacin de los requerimientos del cliente, e incluye
una funcionalidad mnima de tal manera que el usuario pueda utilizar el prototipo.
Normalmente, durante el proceso de desarrollo, se deben construir varios prototipos. El anlisis
de requerimientos que debe realizarse previo a la elaboracin de los prototipos depender
exclusivamente de la naturaleza del problema a resolver. Es recomendable que los prototipos
sean elaborados exclusivamente para la generacin de un conjunto vlido de requerimientos;
una vez que stos han sido identificados se deben documentar y continuar con el proceso de
desarrollo. Es fundamental encontrar el prototipo adecuado para la presentacin ante el cliente.

DESARROLLO CONJUNTO DE APLICACIONES ( JAD )

Tcnica que se utiliza para promover la cooperacin y el trabajo en equipo entre usuarios y
analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto
a analistas de software. La idea es aprovechar la dinmica de grupos aplicando un proceso de
trabajo sistemtico y organizado, apoyado por elementos visuales de comunicacin y
comprensin de soluciones.

Las razones que sirven de base a JAD son las siguientes:

Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino tambin en
redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos
entrevistados.
Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya que slo el
analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar
defectos.
El JAD propugna una participacin ms profunda de los usuarios en el proyecto, hasta tal
punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema
que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organizacin que las
entrevistas y porque el ambiente o los mtodos de trabajo convencionales en las empresas no
facilitan este tipo de actividades (falta de tiempo, dificultad de coordinacin de tanta gente,
dificultad para convencer a la direccin, etc.). No obstante las empresas que han implantado
este mtodo han informado de importantes ahorros de tiempo en el desarrollo de software, as
como de una mayor satisfaccin de los usuarios con los sistemas construidos

TALLERES DE REQUERIMIENTOS

Los requisitos tienen a menudo necesidades 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, en donde las personas implicadas
PNF en Informtica
11

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 para centrarse en el proceso de la definicin de los requisitos y
para dirigir la discusin.

BOSQUEJOS

Es una revisin breve (expresada tpicamente en palabras y frases en lugar de oraciones
completas) de los puntos principales de un texto, organizada jerrquicamente de tal forma que
los niveles de importancia, al igual que el orden de las ideas, estn claramente indicados.

Se puede crear un bosquejo formal o informal, primero se debes utilizar las diferentes tcnicas
para la generacin de ideas (la redaccin libre, la lluvia de ideas, etctera) y para la
organizacin de ideas (el mapa semntico). Despus puedes hacer el bosquejo. En otras
palabras, no es bueno comenzar por el bosquejo, ya que esto puede restringir y limitar la
exploracin de un tema. Lo que le ayuda a la mayora de la gente es escribir sus ideas en la
forma en que se presentan en lugar de apegarse al orden de las ideas presentadas en un
bosquejo. Es decir, primero inicias la generacin de ideas; una vez que tengas las ideas y el
mensaje, puedes crear el bosquejo con los puntos esenciales que piensas incluir en el texto.

Tecnica Recopilacion de Requerimientos

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tecnica Recopilacion de Requerimientos

Cargado por

Copyright:

Formatos disponibles

Repblica Bolivariana De Venezuela

Ministerio Del Poder Popular Para La Educacin Universitaria

También podría gustarte