Documente Academic
Documente Profesional
Documente Cultură
Determinacin de requisitos
Una de las primeras actividades de un analista es determinar los requisitos comerciales para
un nuevo
las capacidades del nuevo sistema A continuacin, describe cmo analizar los requisitos
usando requisitos
OBJETIVOS
tcnicas
INTRODUCCIN
(a menudo llamado el sistema tal como es) al nuevo sistema (a menudo llamado el sistema
futuro). La produccin de
sistema existente, define el alcance del proyecto y proporciona el plan de trabajo inicial. El
anlisis toma el
las ideas generales en el sistema las solicitan y las refinan en una definicin de requisitos
detallada
(este captulo), modelos funcionales (Captulo 4), modelos estructurales (Captulo 5) y
comportamiento
modelos (Captulo 6) que juntos forman la propuesta del sistema. La propuesta del sistema
tambin incluye
(Capitulo 2).
El resultado del anlisis, la propuesta del sistema, se presenta al comit de aprobacin, que
decide si el proyecto debe continuar. Si se aprueba, la propuesta del sistema pasa al diseo y
utilizado como entradas a los pasos en el diseo. Adems, los refinancia y define en mucho
ms
La lnea entre el anlisis y el diseo es muy borrosa. Esto es porque los entregables
creados durante el anlisis son realmente el primer paso en el diseo del nuevo sistema.
Muchos de
las principales decisiones de diseo para el nuevo sistema se encuentran en los resultados del
anlisis. Es importante recordar que los productos del anlisis son realmente el primer paso en
el
En muchos sentidos, porque es aqu donde emergen los principales elementos del sistema, el
poco trabajo se ha hecho todava. A medida que el sistema avanza en el proceso de desarrollo
del sistema,
cambios debido a todo el retrabajo que est involucrado. Varios estudios han demostrado que
ms
ms de la mitad de todas las fallas del sistema se deben a problemas con los requisitos.1 Es por
eso que
Los enfoques iterativos de las metodologas orientadas a objetos son tan eficaces: pequeos
lotes de
los requisitos comerciales establecidos en la solicitud del sistema en una lista ms precisa de
requisitos
que pueden usarse como entradas para el resto del anlisis (creando funcional, estructural y
el sistema.
Definiendo un Requisito
debe tener. Durante el anlisis, los requisitos se escriben desde la perspectiva del empresario,
requisitos). Ms tarde en el diseo, los requerimientos del negocio evolucionan para volverse
ms tcnicos,
Queremos enfatizar que no existe una lnea en blanco y negro que divida un requisito
comercial
Lo que hay que recordar es que un requisito es una declaracin de lo que el sistema debe
hacer,
y los requisitos cambiarn con el tiempo a medida que el proyecto avance desde el inicio hasta
la elaboracin
que un sistema debera tener declaraciones detalladas de la manera tcnica en que las
capacidades sern
se relaciona directamente con un proceso que un sistema tiene que realizar o la informacin
que necesita contener.
Por ejemplo, requisitos que establecen que un sistema debe tener la capacidad de buscar
inventario o para informar los gastos reales y presupuestados son requisitos funcionales.
Funcional
que representan la funcionalidad del sistema en evolucin (ver los Captulos 4, 5 y 6).
base de datos, la interfaz de usuario, el hardware y software, y el fsico subyacente del sistema
arquitectura.
1 Por ejemplo, consulte El alcance de las fallas del proyecto de desarrollo de software (Dennis,
MA: The Standish Group, 1995).
abordar cuestiones relacionadas con los requisitos fsicos y tcnicos en los que el sistema
del sistema. Los requisitos de seguridad tratan los problemas con respecto a quin tiene
acceso
tratar cuestiones relacionadas con los factores culturales, polticos y legales que afectan al
son muy importantes para entender cmo debera ser el sistema final. No funcional
los requisitos principalmente afectan las decisiones que se tomarn durante el diseo de un
sistema. Nosotros
Volveremos sobre este tema ms adelante en el libro cuando analicemos el diseo (vanse los
Captulos 9, 10 y 11).
Un rea de desarrollo de sistemas de informacin que se centr en la diferenciacin funcional
y los requisitos no funcionales son la calidad del software. Han habido muchos modelos
diferentes
propuesto para medir la calidad del software. Sin embargo, virtualmente todos difieren
funcionalmente
en la medida en que el software cumple con los requisitos funcionales, es decir, cunto de los
el problema se resuelve con la solucin de software provista. Considerando que, los requisitos
no funcionales
aquellos que el usuario puede ver (externos) y aquellos que el usuario no puede ver (internos).
El externo
Desde la perspectiva del usuario, las dimensiones externas son ms importantes. Si el sistema
es simplemente
no use el sistema En otras palabras, desde la perspectiva de un usuario, para que un sistema
de informacin sea
exitoso, el sistema no solo debe cumplir con la especificacin funcional, sino que tambin debe
cumplir
tambin son importantes Por ejemplo, dado que los sistemas exitosos tienden a ser de larga
duracin y
Otros temas adicionales que han influido en los requisitos del sistema de informacin son los
estos tres temas podran afectar la definicin de los requisitos funcionales de un sistema,
alcanzado para que la empresa sea considerada como un posible proveedor para suministrar el
sistema
La discusin adicional de estos temas est ms all del alcance de este libro.2
McGraw-Hill, 2004). Una buena referencia para los requisitos de seguridad basados en la Ley
Sarbanes-Oxley es D. C. Brewer, Seguridad
Wiley, 2006). Para informacin detallada sobre COBIT, vea www.isaca.org; para ISO 9000, vea
www.iso.org; y para detalles
Otro tema reciente que influye en los requisitos para algunos sistemas es la globalizacin. por
ejemplo, una cadena de suministro de informacin global genera una gran cantidad de
funcionalidades adicionales no funcionales
requisitos. Si los entornos operativos necesarios no existen para una solucin mvil
no es razonable esperar desplegar una solucin basada en alta tecnologa en un rea que no
considere apoyar algunas partes de la cadena de suministro de informacin global con manual,
en lugar de
Los sistemas manuales tienen un conjunto completamente diferente de requisitos que crean
un rendimiento diferente
las preocupaciones son potencialmente primordiales. Un ejemplo simple que afecta el diseo
de las interfaces de usuario
es el uso correcto del color en los formularios (en una pantalla o papel). Diferentes culturas
interpretan
abordar las inquietudes culturales va ms all de simplemente tener una interfaz de usuario
multilinge.
Debemos ser capaces de adaptar la solucin global a las realidades locales. Friedman se refiere
a estos
Definicin de requisitos
sistema para la oficina de un mdico tpico. Observe que contiene funcional y no funcional
incluir elementos como la cantidad de tiempo que se espera para almacenar una nueva cita,
Los requisitos estn numerados en un formato legal o de esquema para que cada requisito
requisitos; dentro de cada uno de esos ttulos, se agrupan por el tipo de no funcional
pueden clasificarse como de alta, mediana o baja importancia en el nuevo sistema, o pueden
etiquetarse con la versin del sistema que abordar el requisito (por ejemplo, versin 1,
necesario por los otros entregables en el anlisis, que incluyen funcionales, estructurales y de
comportamiento
los analistas exactamente lo que el sistema necesita para terminar haciendo. Cuando surgen
discrepancias,
Determinar los requisitos para la definicin de requisitos es tanto una tarea comercial como
una
3 T. L. Friedman, El mundo es plano: una breve historia del siglo XXI, edicin actualizada y
ampliada. (Nuevo
Requerimientos no funcionales
1. Requisitos operacionales
1.3. El sistema debe realizar una copia de seguridad automtica al final de cada da.
2. Requisitos de rendimiento
3. Requisitos de seguridad
Requerimientos funcionales
1. Administrar citas
2. Produce el horario
abordar las verdaderas necesidades comerciales de los usuarios. Poco a poco, la presuncin
cambi para que el
los usuarios, como expertos en negocios, fueron vistos como la mejor posicin para definir
cmo una computadora
el sistema debera funcionar. Sin embargo, muchos sistemas no pudieron ofrecer beneficios de
rendimiento porque
trabajando juntos para determinar los requisitos comerciales. A veces, sin embargo, los
usuarios no
saber exactamente lo que quieren, y los analistas deben ayudarlos a descubrir sus
necesidades. Un conjunto de
las estrategias se han vuelto populares para ayudar a los analistas a hacer anlisis de
problemas, anlisis de causa raz, duracin
anlisis y eliminacin de actividad. Los analistas pueden usar estas herramientas cuando
necesitan guiar el
los usuarios examinan crticamente el estado actual de los sistemas y procesos (el sistema tal
como est), identifican
exactamente lo que necesita cambiar, y desarrollar un concepto para un nuevo sistema (el
sistema futuro).
Aunque estas estrategias permiten al analista ayudar a los usuarios a crear una visin para el
nuevo
sistema, no son suficientes para extraer informacin sobre los requisitos detallados del
negocio
que se necesitan para construirlo. Por lo tanto, los analistas usan un portafolio de
requerimientos-recoleccin
tcnicas para adquirir informacin de los usuarios. El analista tiene muchas tcnicas de las
cuales
para el sistema, y agrega los requisitos al informe de definicin de requisitos. Los requisitos
Para crear una definicin de requisitos, el equipo del proyecto primero determina los tipos de
funcionalidades
puede cambiar con el tiempo). Estas se convierten en las secciones principales del documento.
A continuacin, los analistas
con todo el equipo del proyecto y los usuarios comerciales para verificar, cambiar y completar
la lista y
con el tiempo a medida que se identifican nuevos requisitos y a medida que el proyecto pasa a
fases posteriores del
Proceso unifi cado. Tenga cuidado: la evolucin de la definicin de requisitos debe ser
cuidadosamente manejada.
sigue creciendo y creciendo y nunca terminas. En cambio, el equipo del proyecto identifica
cuidadosamente
Refleja una necesidad comercial real, pero no est dentro del alcance del sistema actual o la
versin actual,
los requisitos (y el alcance del sistema) es una de las partes ms difciles de administrar un
proyecto.
Avison y Fitzgerald nos proporcionan una serie de problemas que pueden surgir con respecto a
la determinacin de
el conjunto de requisitos con los que se tratar.4 Primero, el analista podra no tener
de los requisitos puede ser inadecuado. Esto es especialmente cierto con las tcnicas ligeras
asociado con metodologas giles. Por cierto, algunos requisitos son simplemente
incognoscibles
y los analistas obtendrn una mejor comprensin tanto de los problemas del dominio como de
la tecnologa aplicable.
las metodologas, como el proceso Unifi ed y gil, pueden ayudar en este caso. Cuarto,
verificando
y la validacin de los requisitos puede ser muy difcil. Abordamos este tema en los captulos
(Captulo 6) modelos.
Antes de que el equipo del proyecto pueda determinar qu requisitos son apropiados para un
sistema dado,
es necesario que haya una visin clara del tipo de sistema que se crear y el nivel de
pasos: entender el sistema tal como est, identificar mejoras y desarrollar requisitos
A veces, el primer paso (es decir, entender el sistema tal como est) se omite o se realiza en un
manera superficial Esto ocurre cuando no existe un sistema actual, si el sistema y los procesos
existentes
son irrelevantes para el sistema futuro, o si el equipo del proyecto est usando un RAD o
desarrollo gil
metodologa en la que el sistema tal como est no se enfatiza. RAD ms nuevo, gil y orientado
a objetos
requisitos del sistema, y pasan poco tiempo investigando el sistema actual tal como est.
Las estrategias de anlisis de requisitos ayudan al analista a guiar a los usuarios a travs de los
pasos de anlisis
para que la visin del sistema pueda desarrollarse. Estrategias de anlisis de requisitos y
las tcnicas de recoleccin de requisitos van de la mano. Los analistas usan los requisitos para
reunir
tcnicas para recopilar informacin; las estrategias de anlisis de requisitos impulsan el tipo de
informacin
eso se recoge y cmo se analiza en ltima instancia. Las estrategias de anlisis de requisitos
Para mover a los usuarios del sistema tal como est al sistema futuro, un analista necesita una
solucin slida
identificar problemas con el sistema tal como est y describir cmo resolverlos en el futuro
sistema. La mayora de los usuarios tienen una muy buena idea de los cambios que les gustara
ver, y la mayora
son muy vocales sobre sugerirlos. La mayora de los cambios tienden a resolver problemas en
lugar de
aprovechar las oportunidades, pero esto ltimo tambin es posible. Mejoras del problema
el anlisis tiende a ser pequeo e incremental (por ejemplo, proporciona ms espacio para
escribir el
facilidad de uso. Sin embargo, a menudo proporciona solo pequeas mejoras en el valor
comercial: el nuevo
sistema es mejor que el anterior, pero puede ser difcil identificar beneficios monetarios signifi
el nuevo sistema
Las ideas producidas por el anlisis de problemas tienden a ser soluciones a los problemas.
Todas las soluciones hacen
suposiciones sobre la naturaleza del problema, suposiciones que podran o no ser vlidas.
En nuestra experiencia, los usuarios (y la mayora de las personas en general) tienden a saltar
rpidamente a soluciones sin
considerando completamente la naturaleza del problema Algunas veces las soluciones son
apropiadas, pero
muchas veces abordan un sntoma del problema, no el verdadero problema o la causa raz
misma.5
5 Dos buenos libros que discuten la dificultad de encontrar las causas de los problemas son: E.
M. Goldratt y
J. Cox, The Goal (Croton-on-Hudson, NY: North River Press, 1986); E. M. Goldratt, el Sndrome
de Haystack
Por ejemplo, supongamos que una empresa advierte que sus usuarios informan
desabastecimientos de inventario. El costo de
El desabastecimiento de inventarios puede ser bastante significativo. En este caso, dado que
ocurren con frecuencia, los clientes
podra encontrar otra fuente para los artculos que estn comprando a la empresa. Eso esta en
el
el desafo radica en identificar la causa raz: pocos problemas del mundo real son simples. Los
usuarios
Proponer puede abordar los sntomas o las causas raz, pero sin un anlisis cuidadoso, es difcil
El anlisis de la causa raz, por lo tanto, se centra en los problemas, no en las soluciones. El
analista comienza por
hacer que los usuarios generen una lista de problemas con el sistema actual y luego priorizar el
problemas en orden de importancia. Comenzando por los ms importantes, los usuarios y / o
el
los analistas luego generan todas las posibles causas raz de los problemas. Cada posible causa
raz
son identificados. Si se identifican posibles causas raz para varios problemas, estos deberan
ser investigado primero, porque hay una buena posibilidad de que sean las verdaderas causas
raz que infl uyen
los problemas de los sntomas. En nuestro ejemplo, hay varias causas posibles:
A veces, usar un diagrama jerrquico para representar las relaciones causales ayuda con el
anlisis.
Como muestra la figura 3-2, hay muchas causas posibles que subyacen a las causas de nivel
superior
Anlisis de duracin
cada proceso en el sistema actual tal como est. Los analistas comienzan determinando la
cantidad total
de tiempo, en promedio, lleva a cabo un conjunto de procesos de negocios para una entrada
tpica. Ellos
luego cronometra cada uno de los pasos individuales (o subprocesos) en el proceso comercial.
El tiempo para
Frecuente
Aprobacin de pedido
Tarde
Retrasado
Retraso en el envo
Orden al vendedor
Retrasos en orden
Tratamiento
Grabacin tarda de
Ventas
Grabacin tarda de
Compras recibidas
Manual infrecuente
Reconciliacin de inventario
Problemas con
Controles de inventario
demasiado baja
Reordenar cantidad
Reordenar incorrecto
Nivel y cantidades
FIGURA 3-
completar el paso bsico se suma y se compara con el total del proceso general. UN
diferencia signifi cativa entre los dos, y en nuestra experiencia, el tiempo total puede ser 10
o incluso 100 veces ms que la suma de las partes, indica que esta parte del proceso es
Por ejemplo, supongamos que los analistas estn trabajando en un sistema hipotecario y
descubren
que, en promedio, toma treinta das para que el banco apruebe una hipoteca. Entonces mira
en cada uno de los pasos bsicos del proceso (por ejemplo, ingreso de datos, verificacin de
crdito, bsqueda de ttulos, evaluacin)
Esta es una fuerte indicacin de que el proceso general est muy roto, ya que demora treinta
das
para realizar un da de trabajo.
Es probable que estos problemas ocurran porque el proceso est muy fragmentado. Muchas
diferentes
las personas deben realizar diferentes actividades antes de que el proceso termine. En el
ejemplo de hipoteca,
es procesado.
Los procesos en los que trabajan muchas personas diferentes en partes pequeas de las
entradas son primordiales
proceso fundamental para que menos personas trabajen en la entrada, lo que a menudo
requiere un cambio
los procesos y el personal de reentrenamiento para realizar una gama ms amplia de deberes.
Paralelizacin de procesos
significa cambiar el proceso para que todos los pasos individuales se realicen al mismo tiempo.
Por ejemplo, en el caso de solicitud de hipoteca, probablemente no haya ninguna razn para
que el crdito
el cheque no se puede realizar al mismo tiempo que la evaluacin y el control del ttulo.
Costeo basado en actividad es un anlisis similar; examina el costo de cada proceso principal o
paso
en un proceso de negocios en lugar del tiempo empleado.6 Los analistas identifican los costos
asociados
con cada uno de los pasos o procesos funcionales bsicos, identifique los procesos ms
costosos, y
y materiales para cada entrada. Los costos de los materiales se asignan fcilmente en un
proceso de fabricacin,
el costo por hora del personal. Sin embargo, como recordar de un curso de contabilidad
gerencial,
existen costos indirectos, como el alquiler, la depreciacin, etc., que tambin se pueden incluir
en
costos de actividad.
Benchmarking informal
Para aprender cmo su organizacin puede hacer algo mejor. La evaluacin comparativa
ayuda al
organizacin mediante la introduccin de ideas que los empleados pueden nunca haber
considerado, pero que tienen
procesos que interactan con el cliente). Con benchmarking informal, los gerentes y
los analistas piensan en otras organizaciones o las visitan como clientes para ver cmo
funciona el negocio
proceso se realiza. En muchos casos, el negocio estudiado puede ser un lder conocido en la
industria
6 Se han escrito muchos libros sobre costos basados en actividades. Los tiles incluyen a K. B.
Burk y D. W. Webster,
Costeo basado en actividades (Fairfax, VA: American Management Systems, 1994); D. T. Hicks,
Costeo basado en actividades:
Hacindolo funcionar para pequeas y medianas empresas (Nueva York: Wiley, 1998). Los dos
libros de Eli Goldratt mencionados
previamente (El objetivo y el Sndrome de Haystack) tambin ofrecen ideas nicas sobre el
clculo de costos.
Anlisis de resultados
no. Por ejemplo, considere una compaa de seguros. Uno de sus clientes acaba de tener un
auto
Las compaas de seguro han respondido esta pregunta asumiendo que el cliente desea recibir
el pago del seguro rpidamente. Para el cliente, sin embargo, el pago es solo un medio para
del proceso de negocio ms all de sus lmites tradicionales para incluir no pagar las
reparaciones, pero
Con este enfoque, los analistas del sistema alientan a los gerentes y al patrocinador del
proyecto a
pretender que son clientes y pensar cuidadosamente sobre lo que los productos de la
organizacin y
los servicios permiten a los clientes hacerlo y lo que podran permitir que el cliente haga.
Anlisis de tecnologa
Muchos cambios importantes en los negocios desde el cambio de siglo han sido habilitados por
nuevos
tecnologa por el bien de la tecnologa. Ms bien, el foco est en utilizar nuevas tecnologas
para cumplir con
objetivos de la organizacin.
Eliminacin de actividad
para identificar cmo la organizacin podra eliminar cada actividad en el proceso comercial,
cmo
la funcin podra funcionar sin ella, y qu efectos pueden ocurrir. Inicialmente, los gerentes
son
reacios a concluir que los procesos pueden ser eliminados, pero este es un ejercicio de fuerza y
ellos deben eliminar cada actividad. En algunos casos, los resultados son tontos; no obstante,
los participantes
l o ella sabe que hay un problema por resolver y, por lo tanto, debe buscar pistas
que descubra la solucin. Lamentablemente, las pistas no siempre son obvias (y muchas veces
son
fallado), por lo que el analista debe notar los detalles, hablar con los testigos y seguir las pistas
al igual que
Sherlock Holmes lo hubiera hecho. Los mejores analistas renen los requisitos usando una
variedad de tcnicas y asegrese de que los procesos comerciales actuales y las necesidades
del
el nuevo sistema es bien entendido antes de pasar al diseo. Los analistas no quieren descubrir
ms tarde que tienen requisitos clave equivocados, tales sorpresas al final del proceso de
desarrollo
El proceso de recopilacin de requisitos se usa para generar apoyo poltico para el proyecto
y establecer la confianza y la relacin entre el equipo del proyecto que construye el sistema y
proceso implica que los equipos del proyecto vean a esa persona como un recurso y valor
importante
sus opiniones. Todos los interesados clave (las personas que pueden afectar el sistema o quin
ser afectado por el sistema) debe incluirse en el proceso de recopilacin de requisitos. Los
las partes interesadas pueden incluir gerentes, empleados, miembros del personal e incluso
algunos clientes
y proveedores. Si una persona clave no est involucrada, esa persona puede sentirse
desairada, lo que puede
causar problemas durante la implementacin (p. ej., cmo pudieron haber desarrollado el
sistema?
sin mi opinin?).
recogido. Hay muchas tcnicas para reunir requisitos que varan de preguntar a las personas
preguntas para verlos funcionar. En esta seccin, nos centramos en los cinco ms comnmente
utilizados
tcnicas: entrevistas, sesiones JAD (un tipo especial de reunin grupal), cuestionarios,
documentos
anlisis y observacin. Cada tcnica tiene sus propias fortalezas y debilidades, muchas de
que son complementarios, por lo que la mayora de los proyectos utilizan una combinacin de
tcnicas.
Entrevistas
natural: si necesita saber algo, por lo general le pregunta a alguien. En general, las entrevistas
son
llevado a cabo uno a uno (un entrevistador y un entrevistado), pero a veces, debido al tiempo
limitaciones, varias personas son entrevistadas al mismo tiempo. Hay cinco pasos bsicos para
la entrevista
El primer paso en una entrevista es crear un cronograma de entrevistas que enumere quin
ser entrevistado,
cundo y con qu propsito (ver Figura 3-3). El cronograma puede ser una lista informal que es
utilizado para ayudar a establecer horarios de reuniones o una lista formal que se incorpora al
plan de trabajo. Los
es importante incluir tanto a los gerentes que administran los procesos como al personal que
realmente
realice los procesos para obtener perspectivas de alto y bajo nivel sobre un problema.
Tambin,
los tipos de sujetos entrevistados necesarios pueden cambiar con el tiempo. Por ejemplo, al
comienzo de la
proyecto, el analista tiene una comprensin limitada del proceso comercial tal como est. Es
comn
para comenzar, entreviste a uno o dos gerentes para obtener una vista estratgica y luego
para moverse
a los gerentes de nivel medio que pueden proporcionar informacin amplia y general sobre el
negocio
proceso y el papel esperado del sistema que se est desarrollando. Una vez que el analista
tiene un buen
comprensin del panorama general, los gerentes de nivel inferior y los miembros del personal
pueden llenar el formulario
detalles de cmo funciona el proceso. Como la mayora de las otras cosas sobre el anlisis de
sistemas, este es un
proceso iterativo: comenzando con los gerentes superiores, pasando a los gerentes de nivel
medio, luego al personal
en el camino.
Es bastante comn que la lista de entrevistados crezca, con frecuencia entre un 50 y un 75 por
ciento. Como personas
7 Algunos libros excelentes que abordan la importancia de reunir requisitos y diversas tcnicas
incluyen
Alan M. Davis, Requisitos de Soft ware: Objetos, Funciones y Estados, Revisin (Englewood Cliff
s, NJ: Prentice Hall,
Leffi ngwell y Don Widrig, Managing Soft Ware Requisitos: un enfoque unificado (Reading, MA:
Addison-Wesley,
2000).
8 Un buen libro sobre entrevistas es el de Brian James, The Systems Analysis Interview
(Manchester, Inglaterra: NCC
y preguntas inquisitivas. Las preguntas cerradas son aquellas que requieren una respuesta
especfica. Ellos
son similares a preguntas de opcin mltiple o aritmticas en un examen (vea la Figura 3-4).
Cercado
las preguntas se usan cuando un analista busca informacin especfica y precisa (p.
cuntas solicitudes de tarjeta de crdito se reciben por da). En general, las preguntas precisas
son las mejores.
las solicitudes procesas por da? Las preguntas cerradas permiten a los analistas controlar la
entrevista
y obtener la informacin que necesitan. Sin embargo, este tipo de preguntas no descubren
Las preguntas abiertas son aquellas que dejan espacio para la elaboracin por parte del
entrevistado.
En muchos sentidos, son similares a las preguntas de ensayo que podras encontrar en un
examen (ver
La Figura 3-4 para ejemplos). Las preguntas abiertas estn diseadas para reunir informacin
rica y
tan importante como la respuesta (por ejemplo, si el entrevistado habla solo sobre otros
departamentos cuando
pregunt por problemas, puede sugerir que l o ella son reacios a admitir sus propios
problemas).
se acaba de discutir para aprender ms, y muchas veces se usan cuando el entrevistador
est interesado en el tema en discusin. Muchos analistas principiantes son reacios a usar
sondeos
preguntas porque tienen miedo de que el entrevistado pueda estar fuera de lugar para ser
desafiado o
porque creen que demuestra que no entendieron lo que dijo el entrevistado. Cuando termine
cortsmente, las preguntas de sondeo pueden ser una herramienta poderosa para reunir los
requisitos.
disponible de otras fuentes. Por ejemplo, en lugar de preguntar qu informacin se usa para
realizar una tarea, es ms simple mostrar al entrevistado un formulario o informe (ver la
seccin
Ningn tipo de pregunta es mejor que otra, y generalmente se usa una combinacin de
preguntas
durante una entrevista. En la etapa inicial de un proyecto de desarrollo de SI, el proceso tal
como est puede
no estar claro, por lo que el proceso de entrevista comienza con entrevistas no estructuradas,
entrevistas que buscan
se necesita informacin pero tiene pocas preguntas cerradas para hacer. Estos son los ms
desafiantes
entrevistas para realizar porque requieren que el entrevistador haga preguntas abiertas
A medida que el proyecto avanza, el analista llega a comprender mucho mejor el proceso
comercial.
y necesita informacin muy especfica sobre cmo se llevan a cabo los procesos comerciales
(por ejemplo,
Independientemente del tipo de entrevista que se realice, las preguntas de la entrevista deben
ser
organizados en una secuencia lgica para que la entrevista fluya bien. Por ejemplo, cuando
intentas
para recopilar informacin sobre el proceso comercial actual, puede ser til moverse en lgica
ordenar a travs del proceso o desde los asuntos ms importantes hasta los menos
importantes.
Hay dos enfoques fundamentales para organizar las preguntas de la entrevista: de arriba hacia
abajo
o de abajo hacia arriba (vea la Figura 3-5). Con la entrevista de arriba hacia abajo, el
entrevistador comienza con amplio,
los analistas mezclan los dos enfoques, comenzando con cuestiones generales y generales,
pasando a preguntas especficas,
El enfoque de arriba hacia abajo es una estrategia apropiada para la mayora de las entrevistas
(sin duda es el
para entender los problemas antes de pasar a los detalles porque el entrevistador podra no
tener
importante, el enfoque de arriba hacia abajo permite al entrevistado plantear una serie de
problemas de gran imagen
antes de enredarse en detalles, por lo que es menos probable que el entrevistador se pierda
temas importantes.
Un caso en el que la estrategia de abajo hacia arriba puede preferirse es cuando el analista ya
ha recopilado mucha informacin sobre problemas y solo necesita rellenar algunos agujeros
con detalles.
Las entrevistas ascendentes pueden ser apropiadas si los funcionarios de nivel inferior se
sienten amenazados o
incapaz de contestar preguntas de alto nivel Por ejemplo, cmo podemos mejorar el servicio
al cliente?
podra ser una pregunta demasiado amplia para un empleado de servicio al cliente, mientras
que una pregunta especfica es fcil
responable (por ejemplo, cmo podemos acelerar las devoluciones de los clientes?). En
cualquier caso, todas las entrevistas deberan
nuevo sistema?
FIGURA 3-4
Tres tipos de
Preguntas
Nivel alto:
Muy general
Nivel medio:
Moderadamente especfico
Nivel bajo:
Muy especifico
Cmo
puede pedir
tratamiento
Ser mejorado?
Han ordenado?
Cmo podemos reducir el nmero de
Es importante prepararse para la entrevista de la misma manera que usted se preparara para
dar
una presentacin. El entrevistador debe tener un plan de entrevista general que enumere las
preguntas para
con ellos, y debe identificar segues entre los temas relacionados. El entrevistador debe confi
Son las reas en las que el entrevistado tiene conocimiento para no hacer preguntas que el
el entrevistado no puede responder. Repase las reas temticas, las preguntas y el plan de la
entrevista.
y decida claramente cules tienen la mayor prioridad en caso de que el tiempo se agote.
En general, las entrevistas estructuradas con preguntas cerradas toman ms tiempo para
prepararse
que pueden aletear. Esto es muy peligroso y a menudo contraproducente, porque cualquier
est programado, se debe informar al entrevistado el motivo de la entrevista y las reas que
se discutir con suficiente antelacin para que l o ella tenga tiempo para pensar en los
problemas
un extrao para la organizacin y para los empleados de nivel inferior, que a menudo no se les
pide
sus opiniones y quienes pueden estar inseguros acerca de por qu estn siendo entrevistados.
El primer objetivo es establecer una buena relacin con el entrevistado, para que confe en el
entrevistador
y est dispuesto a decir toda la verdad, no solo dar las respuestas que l o ella piensa
est all y por qu l o ella han elegido entrevistar a la persona; entonces el entrevistador
experiencia, el mejor enfoque es tomar notas cuidadosas: escriba todo lo que el entrevistado
la persona a reducir la velocidad o hacer una pausa mientras escribe, porque esta es una clara
indicacin de que el
para grabar una entrevista. La grabacin asegura que el entrevistador no se pierda importante
3. Preprate para el
Entrevista
Llevar a cabo
Entrevista
puntos, pero puede ser intimidante para el entrevistado. La mayora de las organizaciones
tienen polticas o
la entrevista, luego l o ella puede traer a una segunda persona para tomar notas detalladas.
A medida que avanza la entrevista, es importante comprender los problemas que se debaten.
despus de eso. La jerga debe reconocerse y definirse; cualquier jerga no entendida debe ser
clarifi ed. Una buena estrategia para aumentar la comprensin durante una entrevista es
peridicamente
Resuma los puntos clave que el entrevistado est comunicando. Th es evita malos entendidos
Finalmente, los hechos deben separarse de la opinin. El entrevistado puede decir, por
ejemplo,
Procesamos demasiadas solicitudes de tarjeta de crdito. Esta es una opinin, y es til seguir
esto
con una pregunta de investigacin que solicita soporte para la declaracin (por ejemplo, Oh,
cuntos tienes?
proceso en un da?). Es til verificar los hechos porque las diferencias entre los hechos
y las opiniones del entrevistado pueden sealar reas clave de mejora. Supongamos que el
entrevistado
se queja de un nmero alto o creciente de errores, pero los registros muestran que los errores
han estado disminuyendo Esto sugiere que los errores son vistos como un problema muy
importante que
A medida que la entrevista llega a su fin, el entrevistado debe tener tiempo para hacer
preguntas o
proporcionar informacin que l o ella cree que es importante pero que no fue parte del plan
de entrevista.
esto lleva a informacin no anticipada, pero importante. Del mismo modo, puede ser til
preguntar al
entrevistado si hay otras personas que deberan ser entrevistadas. La entrevista debe terminar
en
tiempo (si es necesario, algunos temas pueden omitirse o se puede programar otra entrevista).
Como ltimo paso de la entrevista, el entrevistador debe explicar brevemente lo que suceder.
c fecha de entrega, pero l o ella debe asegurarle al entrevistado que su tiempo estuvo bien
En general, el informe de la entrevista debe escribirse dentro de las cuarenta y ocho horas de
la entrevista.
A menudo, el informe de la entrevista se enva al entrevistado con una solicitud para leerlo e
informarle
genuinamente quiere sus correcciones al informe. Usualmente hay pocos cambios, pero
la necesidad de cambios significativos sugiere que se requerir una segunda entrevista. Nunca
JAD es una tcnica de recopilacin de informacin que permite que el equipo del proyecto, los
usuarios y la administracin
trabajar juntos para identificar los requisitos del sistema. IBM desarroll la tcnica JAD en
finales de la dcada de 1970, y con frecuencia es el mtodo ms til para recabar informacin
de los usuarios.9
Wiley, 1989); Alan Cline, "Desarrollo de aplicaciones conjuntas para la recopilacin y gestin
de requisitos", http: //
www.carolla.com/wp-jad.htm.
5. Post-Entrevista
Seguir
Propsito de la entrevista:
Comprender los informes producidos para Recursos Humanos por el sistema actual
1. Los datos son demasiado viejos (el Departamento de Recursos Humanos necesita
informacin dentro de los dos das de finalizado el mes;
2. Los datos son de baja calidad (a menudo los informes deben conciliarse con los
departamentos de recursos humanos
base de datos)
Artculos abiertos:
Verificar los clculos utilizados para determinar el tiempo de vacaciones con Mary Skudrna.
Programe una entrevista con Jim Wack (extensin 2337) con respecto a los motivos de la
calidad de los datos
problemas.
Informe de entrevista
Capers Jones afirma que JAD puede reducir el alcance fluencia en un 50 por ciento y evitar que
el sistema
los requisitos son demasiado especficos o demasiado imprecisos, lo que causa problemas
durante las etapas posteriores
JAD es un proceso estructurado en el que de diez a veinte usuarios se renen bajo la direccin
proporcionar ideas u opiniones sobre los temas en discusin para permanecer neutral durante
el
sesin. El facilitador debe ser un experto tanto en tcnicas de proceso grupal como en anlisis
de sistemas
El grupo JAD se rene durante varias horas, varios das o varias semanas hasta que todos los
problemas
en una sala de reuniones especialmente preparada, lejos de las oficinas de los participantes
para que no sean
interrumpido La sala de reuniones se organiza generalmente en forma de U para que todos los
participantes puedan
ver fcilmente el uno al otro. En la parte delantera de la sala (la parte abierta de la U), hay una
pizarra, flip
a otros.
no s la respuesta, dilo.
delante del cuerpo con las yemas de los dedos tocando) indica
un sentimiento de superioridad.
JAD sufre de los problemas tradicionales asociados con los grupos: a veces las personas
son reacios a desafiar las opiniones de los dems (especialmente su jefe), algunas personas a
menudo
si todos participan por igual, entonces cada persona puede hablar por solo cuatro minutos
cada uno
hora y debe escuchar durante el resto de seis minutos, no es una manera muy eficiente de
recolectar
informacin.
Una nueva forma de JAD llamada Electronic JAD, o e-JAD, intenta superar estos problemas
mediante el uso de groupware. En una sala de reuniones de e-JAD, cada participante utiliza
soft ware especial
en una computadora en red para enviar ideas y opiniones annimas a todos los dems. En esto
De esta manera, todos los participantes pueden contribuir al mismo tiempo sin temor a
represalias de las personas
con opiniones diferentes. La investigacin inicial sugiere que e-JAD puede reducir el tiempo
requerido
para ejecutar las sesiones de JAD entre un 50 y un 80 por ciento.11 Un buen enfoque de JAD
sigue un conjunto de cinco pasos.
informacin que pueden contribuir para proporcionar una amplia combinacin de niveles
organizacionales y
para construir apoyo poltico para el nuevo sistema. La necesidad de que todos los
participantes de JAD estn lejos
desde su oficina al mismo tiempo puede ser un problema importante. Es posible que la oficina
necesite ser cerrada
u opere con un personal esqueleto hasta que se completen las sesiones de JAD.
con Groupware, "Journal of Management Information Systems 15, no. 4 (1999): 115 - 142.
Idealmente, los participantes que son liberados de sus deberes regulares para asistir a las
sesiones de JAD
deberan ser las mejores personas en esa unidad de negocios. Sin embargo, sin una gestin
slida
soporte, las sesiones de JAD pueden fallar porque los seleccionados para asistir a la sesin de
JAD son personas que
es menos probable que se pierdan (es decir, las personas menos competentes).
El facilitador debe ser alguien que sea experto en tcnicas JAD o e-JAD y,
idealmente, alguien que tenga experiencia con el negocio en discusin. En muchos casos, el
Las sesiones de JAD pueden durar desde medio da hasta varias semanas, dependiendo del
tamao y
alcance del proyecto. En nuestra experiencia, la mayora de las sesiones de JAD tienden a durar
de cinco a diez das, se extienden
durante un perodo de tres semanas. La mayora de las sesiones de e-JAD tienden a durar de
uno a cuatro das en una semana
perodo. Las sesiones de JAD y e-JAD generalmente van ms all de recopilar informacin y
pasar al anlisis.
Por ejemplo, los usuarios y los analistas colectivamente pueden crear productos de anlisis,
como
Las sesiones de JAD generalmente se disean y estructuran usando los mismos principios que
las entrevistas.
La mayora de las sesiones de JAD estn diseadas para recopilar informacin especfica de los
usuarios, y esto
requiere desarrollar una serie de preguntas antes de la reunin. Una diferencia entre JAD
y la entrevista es que todas las sesiones de JAD estn estructuradas, deben planificarse
cuidadosamente.
En general, las preguntas cerradas rara vez se utilizan porque no activan la apertura
y franca discusin que es tpica de JAD. En nuestra experiencia, es mejor proceder arriba
abajo en las sesiones de JAD al recopilar informacin. Por lo general, se asignan treinta
minutos a
cada tem de la agenda por separado, y los descansos frecuentes estn programados a lo largo
del da porque
Al igual que con las entrevistas, es importante preparar a los analistas y participantes para un
JAD
sesin. Porque las sesiones pueden ir ms all de la profundidad de una entrevista tpica y
generalmente son
conducidos fuera del sitio, los participantes pueden estar ms preocupados acerca de cmo
prepararse. Es importante
que los participantes entiendan lo que se espera de ellos. Si el objetivo de la sesin JAD,
por ejemplo, es desarrollar una comprensin del sistema actual, entonces los participantes
pueden
para un sistema, antes de que lleguen a la sesin JAD pueden pensar cmo lo haran
mejorar el sistema
La mayora de las sesiones de JAD siguen una agenda formal, y la mayora tienen reglas bsicas
formales que defi
comportamiento. Las reglas bsicas comunes incluyen seguir el cronograma, respetar las
opiniones de los dems,
El papel de un facilitador de JAD puede ser un desafo. Muchos participantes vienen a una
sesin de JAD
con fuertes sentimientos sobre el sistema a discutir. Canalizando estos sentimientos para que
la sesin
avanza en una direccin positiva y hace que los participantes reconozcan y acepten, pero
intentar facilitar las sesiones de JAD sin entrenarse en tcnicas de JAD, y la mayora de los
aprendices
El facilitador JAD realiza tres funciones clave. Primero, l o ella asegura que el grupo
se apega a la agenda. La nica razn para desviarse de la agenda es cuando se vuelve claro
el facilitador, el lder del proyecto y el patrocinador del proyecto que la sesin de JAD ha
producido algunos
nueva informacin que es inesperada y requiere la sesin JAD (y tal vez el proyecto)
para moverse en una nueva direccin. Cuando los participantes intentan desviar la discusin
de la
2. Disea un JAD
Sesin
3. Preparndose para un
JAD Session
4. Dirigiendo
una sesin JAD
agenda, el facilitador debe ser firme pero corts en dirigir la discusin hacia la agenda y
Segundo, el facilitador debe ayudar al grupo a entender los trminos tcnicos y la jerga
que rodean el proceso de desarrollo del sistema y ayudan a los participantes a entender el
tcnicas de anlisis especfi co utilizadas. Los participantes son expertos en su rea, o su parte
de
el negocio, pero no son expertos en anlisis de sistemas. El facilitador debe, por lo tanto,
informacin.
Por ltimo, el facilitador registra la entrada del grupo en un rea de exposicin pblica, que
puede ser un
debe permanecer neutral en todo momento y simplemente ayudar al grupo a travs del
proceso. Los
Cuando el facilitador ofrece una opinin sobre un tema, el grupo lo ver como un
parte neutral, sino ms bien como alguien que podra estar tratando de influir en el grupo en
algunos
solucin predeterminada.
Sin embargo, esto no significa que el facilitador no deba tratar de ayudar al grupo a resolver
cuestiones. Por ejemplo, si dos elementos parecen ser iguales para el facilitador, el facilitador
debera
No diga: "Creo que estos pueden ser similares". En cambio, el facilitador debe preguntar:
"Son similares?"
Si el grupo decide que lo son, el facilitador puede combinarlos y seguir adelante. Sin embargo,
si
el grupo decide que no son similares (a pesar de lo que el facilitador cree), el facilitador
debe aceptar la decisin y seguir adelante. El grupo siempre tiene la razn, y el facilitador tiene
sin opinin.
Al igual que con las entrevistas, se prepara un informe posterior a la sesin de JAD que se
distribuye entre las sesiones
asistentes. El informe posterior a la sesin es esencialmente el mismo que el informe de la
entrevista en la Figura 3-6.
Debido a que las sesiones de JAD son ms largas y brindan ms informacin, generalmente
toma una semana o
Cuestionarios
Los cuestionarios a menudo se utilizan cuando hay un gran nmero de personas de las cuales
informacin y opiniones son necesarias. En nuestra experiencia, los cuestionarios son comunes
tcnica con sistemas destinados a ser utilizados fuera de la organizacin (por ejemplo, por
clientes o
cuestionarios en papel. Un buen proceso para usar cuando se usan cuestionarios sigue
cuatro pasos.
Al igual que con las entrevistas y las sesiones de JAD, el primer paso es identificar a las
personas a quienes
cuestionario ser enviado. Sin embargo, no es habitual seleccionar a todas las personas que
podran proporcionar
libros, y la mayora de las escuelas de negocios incluyen cursos que cubren el tema, por lo que
no lo discutimos
aqu. El punto importante en la seleccin de una muestra, sin embargo, es darse cuenta de que
no todos los que
5. Seguimiento post-JAD
1. Seleccionar participantes
un vaso est medio vaco o medio lleno; ellos estn de acuerdo con el
hechos, pero no puede estar de acuerdo con las palabras. En este caso, el
identificar una buena alternativa (por ejemplo, "Supongamos que esta idea
Realmente mejor el servicio al cliente. Cmo podra
situacin.
Alan Dennis
PRCTICO
PROPINA
debe estar escrito con mucha claridad y dejar poco espacio para malentendidos, por lo tanto,
cerrado
las preguntas tienden a ser ms comnmente utilizadas. Las preguntas deben permitir
claramente que el analista se separe
2. Diseando un
Cuestionario
valores precisos (por ejemplo, con qu frecuencia ocurre un problema de red ?: una vez por
hora, una vez por da, una vez
una semana?). Consulte la Figura 3-7 para ver las pautas sobre el diseo del cuestionario.
Tal vez el problema ms obvio, pero que a veces se pasa por alto, es tener un
y usado. Este problema debe abordarse antes de que se distribuya el cuestionario, porque es
Las preguntas deben ser relativamente consistentes en estilo, para que el encuestado no tenga
que
lea las instrucciones para cada pregunta antes de responderla. En general, es una buena
prctica agrupar
preguntas relacionadas para que sean ms simples de responder. Algunos expertos sugieren
que los cuestionarios
debera comenzar con preguntas importantes para los encuestados, para que el cuestionario
El paso es hacer que varios colegas revisen el cuestionario y luego lo prueben con algunas
personas
formas de mejorar las tasas de respuesta. Las tcnicas comnmente utilizadas incluyen una
explicacin clara de por qu
Los analistas de sistemas tienen tcnicas adicionales para mejorar las tasas de respuesta
dentro de la organizacin,
no los devolvieron despus de una semana o dos, as como solicitar a los supervisores de los
encuestados
el plazo del cuestionario Esto garantiza que el proceso de anlisis se realice de manera
oportuna y
los encuestados que solicitaron copias de los resultados los reciben puntualmente.
Anlisis de documentos
Los equipos de proyecto utilizan anlisis de documentos para comprender el sistema tal como
est. En circunstancias ideales,
el equipo del proyecto que desarroll el sistema existente habr producido documentacin
que luego fue actualizado por todos los proyectos posteriores. En este caso, el equipo del
proyecto puede
documentar sus proyectos en el camino, y cuando los proyectos terminen, no hay tiempo para
vuelve atrs y documenta. Por lo tanto, es posible que no haya mucha documentacin tcnica
sobre
los sistemas actuales disponibles, o puede que no contenga informacin actualizada sobre el
sistema reciente
cambios. Sin embargo, existen muchos documentos tiles en una organizacin: informes en
papel,
3. Administrar
El cuestionario
4. Cuestionario
Seguir
Realice una prueba preliminar del cuestionario para identificar preguntas confusas.
FIGURA 3-7
Buen cuestionario
Diseo
Pero estos documentos solo cuentan parte de la historia. Representan el sistema formal que el
organizacin utiliza. Muy a menudo, el sistema real o informal difiere del formal, y estos
las diferencias, particularmente las grandes, dan fuertes indicaciones de lo que debe
cambiarse. por
ejemplo, formularios o informes que nunca se utilizan probablemente deberan eliminarse. Del
mismo modo, cajas o
las preguntas en formularios que nunca se llenan (o se usan para otros fines) deben
reconsiderarse.
Consulte la Figura 3-8 para ver un ejemplo de cmo se puede interpretar un documento.
La indicacin ms poderosa de que el sistema necesita ser cambiado es cuando los usuarios
cree sus propios formularios o agregue informacin adicional a los existentes. Tales cambios
claramente
demostrar la necesidad de mejoras a los sistemas existentes. Para nosotros, es til revisar
ambos
formularios en blanco y completados para identificar estas desviaciones. Del mismo modo,
cuando los usuarios acceden a mltiples
informes para satisfacer sus necesidades de informacin, es una seal clara de nueva
informacin o nueva informacin
416-
Tienes seguro? S
Confusin.
El cliente no incluy
Mas claro.
FIGURA 3-8
Realizando un
Anlisis de documentos
Observacin
La observacin, el acto de observar los procesos que se realizan, es una poderosa herramienta
para reunir
informacin sobre el sistema tal como es, porque permite al analista ver la realidad de una
situacin,
en lugar de escuchar a otros describirlo en entrevistas o sesiones de JAD. Varias
investigaciones
Los estudios han demostrado que muchos gerentes realmente no recuerdan cmo funcionan y
cmo
ellos asignan su tiempo. (Rpido, cuntas horas pasaste la semana pasada en cada uno de tus
le, para no interrumpir a los que trabajan, y para no infl uenciar a los observados. Sin embargo,
es importante entender que lo que los analistas observan puede no ser el da a da normal
mirado. Aunque la prctica normal puede ser romper las reglas organizacionales formales, la
el observador es poco probable que vea esto. (Recuerde cmo condujo la ltima vez que un
coche de polica sigui
se puede utilizar para apoyar o refutar la informacin proporcionada en una entrevista. Por
ejemplo, un analista
podra volverse escptico de alguien que dice usar extensivamente el sistema informtico
existente
admite la informacin que los usuarios proporcionan en las entrevistas. Cuando no lo hace, es
un importante
de cada tcnica y cundo usar cada una (ver Figura 3-9). Un tema no discutido es el de la
ms adecuado para su uso en diferentes etapas del proceso de anlisis, ya sea entendiendo el
tal como est
sistema, identificando mejoras o desarrollando el sistema futuro. Las entrevistas y JAD son
ms til para entender el tal como est, aunque ocasionalmente proporcionan informacin
sobre
Tipo de informacin Tal como est, las mejoras, tal como estn, las mejoras, tal como estn,
las mejoras tal como estn
ser-a-ser
problemas actuales que necesitan ser mejorados Los cuestionarios a menudo se usan para
recopilar informacin
sobre el sistema tal como es, as como informacin general sobre las mejoras.
para obtener no solo hechos y opiniones, sino tambin una comprensin de por qu esos
hechos y
opiniones existen Las entrevistas y las sesiones de JAD son muy tiles para proporcionar una
buena profundidad de riqueza
e informacin detallada y ayudando al analista a comprender las razones detrs de ellos. A
el otro extremo, el anlisis de documentos y la observacin son tiles para obtener hechos,
pero poco
el anlisis de documentos son fcilmente capaces de solicitar una amplia gama de informacin
de un gran
visite cada fuente de informacin individualmente y, por lo tanto, tmese ms tiempo. Las
sesiones de JAD estn en
las diferencias en las opiniones o los hechos suelen ser muy lentas, ya que implican el contacto
Esto puede hacer que el usuario se ponga a la defensiva y dificulte la resolucin de las
diferencias.
Todas las tcnicas presentan problemas de integracin hasta cierto punto, pero las sesiones de
JAD estn diseadas
como lo hace la fuente del confl icto. La integracin inmediata de la informacin es el nico
el beneficio ms importante de JAD que lo distingue de otras tcnicas, y esta es la razn por la
cual
la mayora de las organizaciones usan JAD para proyectos importantes.
los usuarios del nuevo sistema deben dedicarse al proceso de anlisis. En general, se acepta
que, como usuarios
la participacin puede tener un costo significativo, y no todos los usuarios estn dispuestos a
contribuir
El anlisis y la observacin son tcnicas de bajo costo (aunque la observacin puede ser
bastante tiempo
consumidor). El bajo costo no implica que sean ms o menos efectivos que el otro
tcnicas. Las entrevistas y las sesiones de JAD generalmente tienen costos moderados. En
general, las sesiones de JAD
son mucho ms costosas inicialmente, porque requieren que muchos usuarios estn ausentes
de
sus oficinas por perodos significativos de tiempo, y con frecuencia involucran consultores
altamente remunerados.
La mayora de los analistas comienzan por utilizar entrevistas con el (los) gerente (es) principal
(es) para comprender
del proyecto y los problemas de la gran imagen. A partir de estas entrevistas, queda claro si las
grandes
o pequeos cambios son anticipados. A menudo, estas entrevistas se siguen con el anlisis de
documentos
y polticas para obtener una cierta comprensin del sistema tal como est. Por lo general, las
entrevistas vienen al lado de
porque la sesin JAD permite a los usuarios y a las partes interesadas clave trabajar juntos a
travs de un
tcnica de anlisis y llegar a una comprensin compartida de las posibilidades para el sistema
futuro.
Ocasionalmente, estas sesiones de JAD son seguidas por cuestionarios enviados a un conjunto
mucho ms amplio
de usuarios o usuarios potenciales para ver si las opiniones de los que participaron en el JAD
El desarrollo del concepto para el sistema futuro se realiza a menudo a travs de entrevistas
con
administradores, seguido de sesiones de JAD con usuarios de todos los niveles para asegurarse
de que las necesidades clave de
la creacin de prototipos, los casos de uso, las tarjetas CRC de roles con escenarios basados en
casos de uso,
entender algn aspecto del nuevo sistema. En muchos casos, se usan para probar algunos
aspecto tcnico de un requisito no funcional, como conectar una estacin de trabajo cliente a
un
servidor. Si nunca has hecho esto antes, ser mucho ms fcil desarrollar un ejemplo muy
pequeo
sistema para probar el diseo necesario de la conexin desde la estacin de trabajo del cliente
al
servidor en lugar de tratar de hacerlo la primera vez con el sistema en toda regla. Prototipado
de rowaway
Los casos de uso, como se describe en el Captulo 1, son el enfoque fundamental que el
Proceso Unificado
muy til cuando se crea funcional (ver Captulo 4), estructural (ver Captulo 5) y conductual
(ver Captulo 6) modelos. Describimos este enfoque en el Captulo 5. El resto de esta seccin
Mapas conceptuales
Los mapas conceptuales representan relaciones significativas entre conceptos. Son tiles para
enfocando a las personas en el pequeo nmero de ideas clave sobre las cuales deberan
concentrarse.
Un mapa conceptual es esencialmente una representacin de nodo y arco, donde los nodos
representan el
los requisitos individuales y los arcos representan las relaciones entre los requisitos.
Cada arco est etiquetado con un nombre de relacin. Mapas conceptuales tambin han sido
recomendados como
una posible tcnica para soportar los requisitos de modelado para el desarrollo de sistemas
orientados a objetos
y los sistemas de gestin del conocimiento.12 El mapeo conceptual es una psicologa educativa
enfoque para representar los requisitos sobre el enfoque textual tpico (ver Figura 3-1) es
que un mapa conceptual no se limita a una representacin jerrquica. Los mapas conceptuales
permiten las relaciones
La Figura 3-10 muestra un mapa conceptual que retrata la informacin contenida en los
requisitos
definicin que se muestra en la Figura 3-1. Al usar un mapa conceptual para representar los
requisitos en su lugar
puede hacerse explcito. Por ejemplo, los dos requisitos de seguridad Only Doctors Set
Disponibilidad y solo los gerentes pueden Programar horario estn vinculados explcitamente
al registro
el usuario y el analista se centran en la disposicin grfica del mapa, los requisitos adicionales
pueden
ser descubierto. Un problema obvio con este enfoque es que si el nmero de requisitos
se convierte en muchos y las relaciones entre ellos se vuelven complejas, entonces la cantidad
de
los nodos y arcos estarn tan entrelazados que la ventaja de poder ver explcitamente el
es posible aprovechar la fuerza de las representaciones tanto textuales como grficas para
obtener ms
Historias de usuarios
Las historias de usuario, junto con sus historiales y listas de tareas asociadas, estn asociadas
con
enfoques de desarrollo gil. Las historias de los usuarios han demostrado ser muy tiles para
reunir
requisitos de una manera no amenazante que respeta el punto de vista del usuario. Son
Ejemplo de cita ofi ce, una historia basada en requisitos funcionales podra ser:
Como secretaria, quiero poder programar citas para nuestros pacientes para que podamos
Mientras que una historia operativa no funcional basada en requisitos podra ser:
Como secretaria, quiero poder imprimir el horario diario utilizando tecnologa inalmbrica para
que toda la impresin se puede realizar utilizando una impresora compartida sin tener que
lidiar con
Una vez que se escribe la historia, se discute para determinar la cantidad de esfuerzo que
tomar
para implementarlo. Durante la discusin, se crea una lista de tareas para la historia. Si la
historia es
se considera que es demasiado grande, por ejemplo, hay demasiadas tareas en la lista de
tareas; la historia se divide
en mltiples historias, cada una de las cuales se registra en su propia tarjeta de historia y se
asignan las tareas
a travs de las nuevas historias. En muchas tiendas, una vez que se ha identificado un conjunto
de tareas con una historia,
la historia y sus tareas se pegan en una pared juntas para que todos los miembros del
desarrollo
el equipo puede ver los requisitos. La historia se puede priorizar por importancia colocando
una calificacin
en la tarjeta. La historia tambin se puede evaluar para el nivel de riesgo asociado con ella. Los
el nivel de importancia y la cantidad de riesgo asociado con la historia se pueden usar para
ayudar a elegir
para documentar los requisitos es que son muy poco tecnolgicos, de alto toque, fcilmente
actualizables y
muy porttil.
14 Para obtener ms informacin sobre las cartas de historias y las listas de tareas, consulte M.
Cohn, User Stories Applied: For Agile Soft ware
Desarrollo (Boston, MA: Addison-Wesley, 2004); B. Rinzler, contar historias: un camino corto
para escribir mejor
Requisitos de Soft ware (Indianapolis, IN: Wiley, 2009); M. Lippert, S. Roock, H. Wolf, eXtreme
Programacin
en accin: Experiencias prcticas de Real World Projects (Chichester, Inglaterra: Wiley & Sons,
Ltd., 2002);
C. Larman, Agile & Iterative Development: A Manager's Guide (Boston, MA: Addison-Wesley,
2004).
modelos en evolucin que describen el nuevo sistema. Los modelos en evolucin incluyen
modelos funcionales
(ver Captulo 4), modelos estructurales (ver Captulo 5) y modelos de comportamiento (ver
Captulo 6) .15 La
resumen ejecutivo proporciona toda la informacin crtica en una forma muy concisa. Se
puede pensar
a fondo. El resumen ejecutivo generalmente no es ms que una pgina larga. Figura 3-11
proporciona una plantilla para una propuesta de sistema y referencias donde las otras
secciones del
propuesta se describen.
1. Tabla de contenido
2. Resumen ejecutivo
4. Plan de trabajo
El plan de trabajo original, revisado despus de haber completado el anlisis (ver Captulo 2).
5. Anlisis de viabilidad
Un anlisis de viabilidad revisado, utilizando la informacin del anlisis (ver Captulo 2).
6. Definicin de requisitos
Una lista de los requisitos comerciales funcionales y no funcionales para el sistema (este
captulo).
7. Modelo funcional
procesos o funcionalidades externas que el sistema necesita para soportar (vea el Captulo 4).
8. Modelos estructurales
Un conjunto de tarjetas CRC, diagrama de clases y diagramas de objetos que describen los
aspectos estructurales de la
sistema futuro (ver Captulo 5). Esto tambin puede incluir modelos estructurales del sistema
actual tal como est
ser reemplazado.
9. Modelos de comportamiento
matriz que describe el comportamiento interno del sistema futuro (ver Captulo 6). Esto puede
incluir
10. Apndices
Estos contienen material adicional relevante para la propuesta, a menudo utilizado para
respaldar la recomendacin
sistema. Esto podra incluir los resultados de una encuesta de cuestionario o entrevistas,
informes de la industria y
estadsticas, etc.
FIGURA 3-11
Modelo
de Defensa, NASA, IEEE / ANSI y el Laboratorio de Investigacin Naval tienen formatos muy
especficos que deben ser
Revisin (Upper Saddle River, NJ: Prentice Hall, 1993); G. Kotonya y I. Sommerville, Ingeniera
de requisitos
HIPERMERCADO
El Captulo 3 introdujo la determinacin de requisitos para el desarrollo de sistemas orientados
a objetos
caractersticas que debe tener. Si los requisitos no estn completa o correctamente definidos,
el sistema
desarrollado es poco probable que satisfaga las necesidades del usuario. En otras palabras, si
los requisitos
En la entrega de este captulo del caso Patterson Superstore, vemos los requisitos
anlisis y tcnicas de recopilacin de requisitos que los analistas utilizaron para determinar
requisitos para la Versin 1 del Sistema Integrado de Entrega de Clnicas de Salud. Tambin
vemos el
Despus de leer y estudiar este captulo, usted debera ser capaz de:
Describe cmo usar los mapas conceptuales para documentar los requisitos.
Describe cmo usar las fichas y las listas de tareas para documentar los requisitos.
TRMINOS CLAVE
Eliminacin de actividad
Anlisis
Benchmarking
Amplitud de anlisis
Requisitos comerciales
Pregunta cerrada
Mapeo conceptual
Mapas conceptuales
Anlisis de documentos
Anlisis de duracin
Facilitador
Sistema formal
Requerimientos funcionales
Reglas de juego
Sistema informal
Habilidades interpersonales
Entrevista
Notas de entrevista
Informe de entrevista
Horario de entrevista
desarrollo)
Requerimientos no funcionales
Observacin
Pregunta abierta
Anlisis de resultados
Paralelizacin
Integracin de proceso
Pregunta de prueba
Cuestionario
Requisito
Definicin de requisitos
Requisitos
determinacin
Riesgo
Causa principal
Muestra
Escriba
Tarjetas de historia
Entrevista estructurada
Anlisis de tecnologa
Sistema futuro
Entrevista descendente
Entrevista no estructurada
Historias de usuarios
Tutorial
PREGUNTAS
y que contiene?
un sistema futuro?
costeo
cada enfoque?
10. Explicar la diferencia entre un top-down y
cada enfoque?
sesiones?
sesiones
en usarlo?
18. Cules son las tasas de respuesta tpicas para los cuestionarios?
ambos?
22. Explique los factores que pueden usarse para seleccionar la recopilacin de informacin
tcnicas.
tcnicas?
propuesta?
propuesta de sistema?
CEREMONIAS
identificado
tareas que cada uno realiz en el ltimo trabajo que realiz (a tiempo completo,
usado.
J. Encuentra un grupo de estudiantes y ejecuta un sesenta minutos
MINICASES
en el orden correcto.
tu respuesta.
plan de anlisis.
mi sistema ".
se le dio.
a los clientes
su informe antes de las 5:00 ese da. Estaba seguro de que su equipo
asignacin.
Diferentes ciudades, por lo que una encuesta pareca una forma ideal de
reuniendo la informacin necesaria de los empleados.
el cuestionario por correo electrnico tan pronto como sea posible. Ella
tiene solo una tasa de respuesta del 14 por ciento, que est segura