You are on page 1of 68

CAPTULO 3

Determinacin de requisitos

Una de las primeras actividades de un analista es determinar los requisitos comerciales para
un nuevo

sistema. Este captulo comienza presentando la definicin de requisitos, un documento que


enumera

las capacidades del nuevo sistema A continuacin, describe cmo analizar los requisitos
usando requisitos

estrategias de anlisis y cmo reunir requisitos mediante entrevistas, sesiones de JAD,

cuestionarios, anlisis de documentos y observacin. El captulo tambin describe un conjunto


de alternativas

requisitos-tcnicas de documentacin y describe el documento de propuesta del sistema

eso jala todo junto

OBJETIVOS

Comprender cmo crear una definicin de requisitos

Familiarizarse con las tcnicas de anlisis de requisitos

Comprender cundo usar cada tcnica de anlisis de requisitos

Comprender cmo reunir requisitos mediante entrevistas, sesiones de JAD, cuestionarios,

anlisis de documentos y observacin

Comprender el uso de mapas conceptuales, tarjetas de historias y listas de tareas como


requisitosde documentacin

tcnicas

Comprender cundo usar cada tcnica de recopilacin de requisitos

Ser capaz de comenzar a crear una propuesta de sistema

INTRODUCCIN

El proceso de desarrollo de sistemas ayuda a una organizacin a moverse desde el sistema


actual

(a menudo llamado el sistema tal como es) al nuevo sistema (a menudo llamado el sistema
futuro). La produccin de

la planificacin, discutida en el Captulo 2, es la solicitud del sistema, que proporciona ideas


generales para el

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

entregables de gestin de proyectos revisados, como el anlisis de viabilidad y el plan de


trabajo

(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

sus elementos (definicin de requisitos y modelos funcionales, estructurales y de


comportamiento) son

utilizado como entradas a los pasos en el diseo. Adems, los refinancia y define en mucho
ms

detalle cmo se construir el sistema

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

diseo del nuevo sistema.

En muchos sentidos, porque es aqu donde emergen los principales elementos del sistema, el

El paso de determinacin de requisitos es el paso ms importante de todo el desarrollo del


sistema

proceso. Durante la determinacin de requisitos, el sistema es fcil de cambiar porque

poco trabajo se ha hecho todava. A medida que el sistema avanza en el proceso de desarrollo
del sistema,

se vuelve cada vez ms difcil volver a la determinacin de requisitos y hacer mayor

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 se pueden identificar e implementar en etapas incrementales, lo que permite

sistema para evolucionar con el tiempo.


REQUISITOS DETERMINACIN

El propsito de la determinacin de requisitos es cambiar la explicacin de alto nivel 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

modelos de comportamiento). La expansin de los requisitos conduce finalmente al diseo de

el sistema.

Definiendo un Requisito

Un requisito es simplemente una declaracin de lo que el sistema debe hacer o qu


caracterstica

debe tener. Durante el anlisis, los requisitos se escriben desde la perspectiva del empresario,

y se enfocan en el "qu" del sistema. Porque se enfocan en las necesidades

del usuario comercial, generalmente se denominan requisitos comerciales (y, en ocasiones,


usuario

requisitos). Ms tarde en el diseo, los requerimientos del negocio evolucionan para volverse
ms tcnicos,

y describen cmo se implementar el sistema. Los requisitos en el diseo estn escritos

desde la perspectiva del desarrollador, y generalmente se llaman requisitos del sistema.

Queremos enfatizar que no existe una lnea en blanco y negro que divida un requisito
comercial

y un requisito del sistema, y algunas empresas usan los trminos indistintamente. Lo


importante

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

a la construccin. Los requisitos evolucionan a partir de declaraciones detalladas de las


capacidades del negocio

que un sistema debera tener declaraciones detalladas de la manera tcnica en que las
capacidades sern

implementado en el nuevo sistema.

Los requisitos pueden ser de naturaleza funcional o no funcional. Un requisito funcional

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

los requisitos fluyen directamente en la creacin de modelos funcionales, estructurales y de


comportamiento

que representan la funcionalidad del sistema en evolucin (ver los Captulos 4, 5 y 6).

Los requisitos no funcionales se refieren a las propiedades de comportamiento que el sistema


debe tener,

como el rendimiento y la usabilidad. La capacidad de acceder al sistema usando un navegador


web es

considerado un requisito no funcional. Los requisitos no funcionales pueden influir en el resto

de anlisis (modelos funcionales, estructurales y de comportamiento), pero a menudo lo hacen


de forma indirecta;

los requisitos no funcionales se utilizan principalmente en el diseo cuando se toman


decisiones sobre la

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).

Los requisitos no funcionales describen una variedad de caractersticas con respecto al


sistema:

operacional, rendimiento, seguridad, y cultural y poltico. Requerimientos operacionales

abordar cuestiones relacionadas con los requisitos fsicos y tcnicos en los que el sistema

funcionar. Los requisitos de rendimiento abordan cuestiones relacionadas con la velocidad,


capacidad y fiabilidad

del sistema. Los requisitos de seguridad tratan los problemas con respecto a quin tiene
acceso

al sistema y en qu circunstancias especficas. Requisitos culturales y polticos

tratar cuestiones relacionadas con los factores culturales, polticos y legales que afectan al

sistema. Estas caractersticas no describen procesos comerciales o informacin, pero

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

y requisitos no funcionales. Desde una perspectiva de calidad, la calidad funcional est


relacionada

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

estn asociados con la eficiencia, facilidad de mantenimiento, portabilidad, confiabilidad,


reutilizacin, capacidad de prueba,

y dimensiones de calidad de usabilidad. Como se indic anteriormente, las dimensiones


relacionadas no funcionales son

asociado principalmente con el diseo detallado real y la implementacin del sistema.

Al considerar el cumplimiento con ISO 9000, las dimensiones de calidad se descomponen an


ms en

aquellos que el usuario puede ver (externos) y aquellos que el usuario no puede ver (internos).
El externo

las dimensiones no funcionales incluyen eficiencia, confiabilidad y facilidad de uso, mientras


que las internas

las dimensiones no funcionales incluyen capacidad de mantenimiento, portabilidad,


reutilizacin y capacidad de prueba.

Desde la perspectiva del usuario, las dimensiones externas son ms importantes. Si el sistema
es simplemente

demasiado difcil de usar, independientemente de lo bien que el sistema resuelva el problema,


el usuario 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

las especifcaciones externas no funcionales. Desde la perspectiva de un desarrollador, las


dimensiones internas

tambin son importantes Por ejemplo, dado que los sistemas exitosos tienden a ser de larga
duracin y

multiplataforma, tanto las dimensiones de mantenimiento como las de portabilidad pueden


tener implicaciones estratgicas
para el sistema que se est desarrollando. Adems, dados los enfoques de desarrollo giles
que se utilizan

en la industria actual, el desarrollo de softwares reutilizables y comprobables es crucial.

Otros temas adicionales que han influido en los requisitos del sistema de informacin son los

Ley Sarbanes-Oxley, COBIT (OBJETIVOS DE CONTROL PARA INFORMACIN Y TECNOLOGA


RELACIONADA)

Cumplimiento y Cumplimiento del Modelo de Madurez de Capacidad. Dependiendo del


sistema que se considere,

estos tres temas podran afectar la definicin de los requisitos funcionales de un sistema,

requisitos no funcionales, o ambos. La Ley Sarbanes-Oxley, por ejemplo, exige ms

requisitos funcionales y no funcionales. Esto incluye preocupaciones de seguridad adicionales

(no funcional) y requisitos de informacin especficos que la administracin debe proporcionar


ahora

(funcional). Al desarrollar sistemas de informacin financiera, los desarrolladores de sistemas


de informacin

debe asegurarse de incluir la experiencia de Sarbanes-Oxley en el equipo de desarrollo. Por


otra parte, un cliente

podra insistir en el cumplimiento de COBIT o en que se haya alcanzado un nivel de Modelo de


Madurez de Capacidades especfico

alcanzado para que la empresa sea considerada como un posible proveedor para suministrar el
sistema

consideracin. Obviamente, este tipo de requisitos se suman a los requisitos no funcionales.

La discusin adicional de estos temas est ms all del alcance de este libro.2

2 Una discusin concisa de la Ley Sarbanes-Oxley se presenta en G. P. Lander, Qu es


Sarbanes-Oxley? (Nueva York:

McGraw-Hill, 2004). Una buena referencia para los requisitos de seguridad basados en la Ley
Sarbanes-Oxley es D. C. Brewer, Seguridad

Controles para la Seccin 404 de Sarbanes-Oxley Cumplimiento: Autorizacin, Autenticacin y


Acceso (Indianapolis, IN:

Wiley, 2006). Para informacin detallada sobre COBIT, vea www.isaca.org; para ISO 9000, vea
www.iso.org; y para detalles

sobre el Modelo de Madurez de Capacidad, ver www.sei.cmu.edu/cmmi/.

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

para ser desarrollado, es importante adaptar la solucin al entorno local. O, puede

no es razonable esperar desplegar una solucin basada en alta tecnologa en un rea que no

tener la infraestructura de poder y comunicaciones necesaria. En algunos casos, es posible que


necesitemos

considere apoyar algunas partes de la cadena de suministro de informacin global con manual,
en lugar de

que los sistemas automatizados.

Los sistemas manuales tienen un conjunto completamente diferente de requisitos que crean
un rendimiento diferente

expectativas y preocupaciones de seguridad adicionales. Adems, cultural y poltico

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

Diferentes colores difieren. En otras palabras, en un entorno empresarial global y


multicultural,

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

preocupaciones como glocalization.3 De lo contrario, simplemente crearemos otro ejemplo de


informacin fallada

proyecto de desarrollo de sistema

Definicin de requisitos

El informe de definicin de requisitos, generalmente llamado definicin de requisitos, es un

informe de texto sencillo que simplemente enumera los requisitos funcionales y no


funcionales

en un formato de esquema. La Figura 3-1 muestra una definicin de requisitos de muestra


para una cita

sistema para la oficina de un mdico tpico. Observe que contiene funcional y no funcional

requisitos. Los requisitos funcionales incluyen la gestin de citas, produccin

horarios, y registrar la disponibilidad de los mdicos individuales. Los requisitos no funcionales

incluir elementos como la cantidad de tiempo que se espera para almacenar una nueva cita,

la necesidad de admitir la impresin inalmbrica y qu tipo de empleados tienen acceso a la


diferentes partes del sistema.

Los requisitos estn numerados en un formato legal o de esquema para que cada requisito

est claramente identificado. Los requisitos se agrupan primero en funcionales y no


funcionales

requisitos; dentro de cada uno de esos ttulos, se agrupan por el tipo de no funcional

requisito o por funcin.

A veces, los requisitos comerciales se priorizan en la definicin de los requisitos. Ellos

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,

lanzamiento 2, lanzamiento 3). Esta prctica es particularmente importante cuando se usan


metodologas orientadas a objetos

ya que entregan sistemas de manera incremental.

El objetivo ms obvio de la definicin de requisitos es proporcionar la informacin

necesario por los otros entregables en el anlisis, que incluyen funcionales, estructurales y de
comportamiento

modelos, y para apoyar actividades en diseo. El propsito ms importante de los requisitos

La definicin, sin embargo, es definir el alcance del sistema. El documento describe

los analistas exactamente lo que el sistema necesita para terminar haciendo. Cuando surgen
discrepancias,

el documento sirve como el lugar para la clarificacin.

Determinar los requisitos

Determinar los requisitos para la definicin de requisitos es tanto una tarea comercial como
una

tarea de tecnologa de la informacin. En los primeros das de la informtica, exista la


presuncin de que

3 T. L. Friedman, El mundo es plano: una breve historia del siglo XXI, edicin actualizada y
ampliada. (Nuevo

York: Farrar, Straus y Giroux, 2006.)

Requerimientos no funcionales

1. Requisitos operacionales

1.1. El sistema operar en el entorno de Windows.

1.2. El sistema debera poder conectarse a las impresoras de forma inalmbrica.

1.3. El sistema debe realizar una copia de seguridad automtica al final de cada da.
2. Requisitos de rendimiento

2.1. El sistema almacenar una nueva cita en 2 segundos o menos.

2.2. El sistema recuperar el programa de citas diarias en 2 segundos o menos.

3. Requisitos de seguridad

3.1. Solo los mdicos pueden establecer su disponibilidad.

3.2. Solo un gerente puede producir un horario.

4. Requisitos culturales y polticos

4.1. No se prevn requisitos culturales y polticos especiales.

Requerimientos funcionales

1. Administrar citas

1.1. Paciente hace una nueva cita.

1.2. El paciente cambia de cita

1.3. El paciente cancela la cita.

2. Produce el horario

2.1. Office Manager comprueba el horario diario.

2.2. Office Manager imprime el horario diario.

3. Record Doctor Availability

3.1. Calendario de actualizaciones del mdico

los analistas de sistemas, como expertos en sistemas informticos, estaban en la mejor


posicin para definir

cmo debera funcionar un sistema informtico. Muchos sistemas fallaron porque no lo


hicieron adecuadamente

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

los usuarios simplemente automatizaron un sistema ineficaz existente y no pudieron


incorporar nuevos

oportunidades ofrecidas por la tecnologa.

Por lo tanto, el enfoque ms eficaz es contar con empresarios y analistas

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, costeo basado en actividades, benchmarking informal, anlisis de resultados,


tecnologa

anlisis y eliminacin de actividad. Los analistas pueden usar estas herramientas cuando
necesitan guiar el

usuarios en explicar lo que se quiere de un sistema. Estas estrategias funcionan de manera


similar. Ellos ayudan

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 elegir: entrevistas, cuestionarios, observacin, desarrollo de aplicaciones conjuntas (JAD)


y

anlisis de documentos. La informacin recopilada usando estas tcnicas se analiza


crticamente y

utilizado para elaborar el informe de definicin de requisitos.

Crear una definicin de requisitos

Crear una definicin de requisitos es un proceso iterativo y continuo mediante el cual el


analista

recopila informacin con tcnicas de recopilacin de requisitos (por ejemplo, entrevistas,


documentos

anlisis), analiza crticamente la informacin para identificar los requisitos comerciales


apropiados

para el sistema, y agrega los requisitos al informe de definicin de requisitos. Los requisitos

la definicin se mantiene actualizada para que el equipo de proyecto y los usuarios


comerciales puedan consultarla
y obtener una comprensin clara del nuevo sistema.

Para crear una definicin de requisitos, el equipo del proyecto primero determina los tipos de
funcionalidades

y requisitos no funcionales que recopilarn sobre el sistema (por supuesto, estos

puede cambiar con el tiempo). Estas se convierten en las secciones principales del documento.
A continuacin, los analistas

utilizar una variedad de tcnicas de recopilacin de requisitos para recopilar informacin, y


enumeran el

requisitos comerciales que se identificaron a partir de esa informacin. Finalmente, los


analistas trabajan

con todo el equipo del proyecto y los usuarios comerciales para verificar, cambiar y completar
la lista y

para ayudar a priorizar la importancia de los requisitos que se identificaron.

Este proceso contina durante todo el anlisis y la definicin de requisitos evoluciona

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.

El equipo del proyecto no puede seguir agregando a la definicin de requisitos, o el sistema

sigue creciendo y creciendo y nunca terminas. En cambio, el equipo del proyecto identifica
cuidadosamente

requisitos y evala cules se ajustan al alcance del sistema. Cuando un requisito

Refleja una necesidad comercial real, pero no est dentro del alcance del sistema actual o la
versin actual,

se agrega en una lista de requisitos futuros o se le da una prioridad baja. La administracin de

los requisitos (y el alcance del sistema) es una de las partes ms difciles de administrar un
proyecto.

Problemas del mundo real con la determinacin de los requisitos

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

acceder al conjunto correcto de usuarios para descubrir el conjunto completo de requisitos.


Esto puede llevar a

requisitos que se pierden, tergiversados y / o sobreespecificados. En segundo lugar, la


especificacin

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

al comienzo de un proceso de desarrollo. Sin embargo, a medida que el sistema se desarrolla,


los usuarios

y los analistas obtendrn una mejor comprensin tanto de los problemas del dominio como de
la tecnologa aplicable.

Esto puede causar que se identifiquen nuevos requisitos funcionales y no funcionales.

requisitos actuales para evolucionar o ser cancelado. Desarrollo iterativo e incremental

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

que se ocupan de la creacin de funcional (Captulo 4), estructural (Captulo 5) y conductual

(Captulo 6) modelos.

4 Vase D. Avison y G. Fitzgerald, Desarrollo de sistemas de informacin: metodologas,


tcnicas y herramientas, 4 edicin.

(Londres: McGraw-Hill, 2006)

ESTRATEGIAS DE ANLISIS DE REQUISITOS

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

cambio que traer a la organizacin. El proceso bsico de anlisis se divide en tres

pasos: entender el sistema tal como est, identificar mejoras y desarrollar requisitos

para el sistema futuro.

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

metodologas, tales como desarrollo gradual, creacin de prototipos, creacin de prototipos


desechables, programacin extrema,

y Scrum (ver Captulo 1) se enfoca casi exclusivamente en las mejoras y el futuro

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

y la recopilacin de requisitos ocurre de manera concurrente y son actividades


complementarias.

Para mover a los usuarios del sistema tal como est al sistema futuro, un analista necesita una
solucin slida

habilidades de pensamiento crtico. El pensamiento crtico es la capacidad de reconocer


fortalezas y debilidades

y reformular una idea en una forma mejorada, y se necesitan habilidades de pensamiento


crtico para comprender realmente

problemas y desarrollar nuevos procesos comerciales. Estas habilidades tambin son


necesarias para

examinar los resultados de la recopilacin de requisitos, identificar los requisitos comerciales y

traducir esos requisitos en un concepto para el nuevo sistema.

Anlisis del problema

El anlisis de requisitos ms directo (y probablemente el ms utilizado)

tcnica es el anlisis de problemas. El anlisis de problemas significa pedirle a los usuarios y


gerentes que

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

direccin del cliente; proporcionar un nuevo informe que actualmente no existe).

Este tipo de mejora es muy eficaz para mejorar la eficiencia de un sistema o

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

Anlisis de causa raz

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

(Croton-on-Hudson, Nueva York: North River Press, 1990).

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

inters de la firma para determinar la causa subyacente y no simplemente proporcionar una


reaccin instintiva

como aumentar arbitrariamente la cantidad de inventario que se tiene a mano. En el mundo


de los negocios,

el desafo radica en identificar la causa raz: pocos problemas del mundo real son simples. Los
usuarios

tpicamente proponen un conjunto de causas para el problema bajo consideracin. Las


soluciones que los usuarios

Proponer puede abordar los sntomas o las causas raz, pero sin un anlisis cuidadoso, es difcil

para decir a cul se dirige.

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

se investiga (comenzando con el ms probable o el ms fcil de verificar) hasta que las


verdaderas causas 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:

Es posible que el proveedor de la empresa no est entregando los pedidos a la empresa de


manera oportuna.

Podra haber un problema con los controles de inventario de la empresa.

El nivel de reorden y las cantidades podran establecerse incorrectamente.

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

identificado El punto clave en el anlisis de la causa raz siempre es desafiar lo obvio.

Anlisis de duracin

El anlisis de duracin requiere un examen detallado de la cantidad de tiempo que lleva


realizar

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

Stock-Outs del inventario

Aprobacin de pedido

Tarde

Identificacin del vendedor

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

Reordenar el conjunto de puntos

demasiado baja

Reordenar cantidad

(EOQ) establecido demasiado bajo

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

mal necesitando una gran revisin.

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)

y descubra que la cantidad total de tiempo realmente gastado en cada hipoteca es de


aproximadamente ocho horas.

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,

la aplicacin probablemente se encuentra en los escritorios de muchas personas durante


largos perodos de tiempo antes de que

es procesado.

Los procesos en los que trabajan muchas personas diferentes en partes pequeas de las
entradas son primordiales

candidatos para integracin de proceso o paralelizacin. La integracin del proceso significa


cambiar el

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 actividades

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

enfoca sus esfuerzos de mejora en ellos.

Asignar costos es conceptualmente simple. Los analistas simplemente examinan el costo


directo del trabajo

y materiales para cada entrada. Los costos de los materiales se asignan fcilmente en un
proceso de fabricacin,

mientras que los costos laborales generalmente se calculan en funcin de la cantidad de


tiempo dedicado a la entrada y

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

El benchmarking se refiere al estudio de cmo otras organizaciones realizan un proceso


comercial en

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

el potencial de agregar valor

El benchmarking informal es bastante comn para los procesos comerciales orientados al


cliente (es decir,

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

o simplemente una empresa relacionada.

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

El anlisis de resultados se centra en la comprensin de los resultados fundamentales que


proporcionan valor a

clientes. Aunque estos resultados parecen lgicos, a menudo son

no. Por ejemplo, considere una compaa de seguros. Uno de sus clientes acaba de tener un
auto

accidente. Cul es el resultado fundamental desde la perspectiva del cliente?


Tradicionalmente,

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

el resultado real: un automvil reparado. La compaa de seguros podra beneficiarse


extendiendo su punto de vista

del proceso de negocio ms all de sus lmites tradicionales para incluir no pagar las
reparaciones, pero

realizar las reparaciones o contratar a un taller autorizado para hacerlas.

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

tecnologas. El anlisis de tecnologa comienza haciendo que los analistas y gerentes


desarrollen una lista

de tecnologas importantes e interesantes. El grupo identifica sistemticamente cmo

cada tecnologa podra aplicarse al proceso comercial e identifica cmo el negocio

beneficiara. Es importante tener en cuenta que el anlisis de la tecnologa de ninguna manera


implica adoptar

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

La eliminacin de la actividad es exactamente lo que parece. Los analistas y los gerentes


trabajan juntos

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

debe abordar cada actividad en el proceso comercial.

TCNICAS DE RECOGIDA DE REQUISITOS


Un analista se parece mucho a un detective (y los usuarios de negocios a veces son
sospechosos escurridizos).

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

puede causar todo tipo de problemas.

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

los usuarios que finalmente elegirn usar o no el sistema. Involucrar a alguien en el

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?).

El segundo desafo de la recopilacin de requisitos es elegir la (s) forma (s) de informacin.

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

Una entrevista es la tcnica de recopilacin de requisitos ms comnmente utilizada. Despus


de todo, es

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

proceso: seleccionar a los entrevistados, disear las preguntas de la entrevista, prepararse


para la entrevista,

realizacin de la entrevista y seguimiento posterior a la entrevista.8

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

las personas que aparecen en el programa de entrevistas se seleccionan en funcin de la


informacin del analista

necesariamente. El patrocinador del proyecto, los usuarios empresariales clave y otros


miembros del equipo del proyecto pueden

ayudar al analista a determinar quin en la organizacin puede brindar mejor informacin


importante

acerca de los requisitos. Estas personas se enumeran en el calendario de entrevistas en el


orden en que

ellos deben ser entrevistados.

Las personas en diferentes niveles de la organizacin tienen diferentes perspectivas sobre el


sistema, por lo que

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

miembros, de vuelta a los gerentes de nivel medio, y as sucesivamente, dependiendo de qu


informacin se necesita

en el camino.

Es bastante comn que la lista de entrevistados crezca, con frecuencia entre un 50 y un 75 por
ciento. Como personas

son entrevistados, ms informacin que se necesita y personas adicionales que pueden


proporcionar

la informacin probablemente ser identificada.

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,

1993); Gerald Kotonya e Ian Sommerville, Ingeniera de requisitos (Chichester, Inglaterra:


Wiley, 1998); Decano

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

Hay tres tipos de preguntas de la entrevista: preguntas cerradas, preguntas abiertas,

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.

Por ejemplo, en lugar de preguntar, manejas muchas solicitudes? es mejor preguntar,


cuntos

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

por qu la respuesta es como es, ni descubren informacin que el entrevistador no

Piensa preguntar por adelantado.

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

darle al entrevistado ms control sobre la informacin que se revela durante la entrevista.

A veces, la informacin que el entrevistado elige discutir descubre informacin que es

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).

El tercer tipo de pregunta es la pregunta de sondeo. Preguntas perspicaces dan seguimiento a


lo que

se acaba de discutir para aprender ms, y muchas veces se usan cuando el entrevistador

poco claro sobre la respuesta de un entrevistado. Animan al entrevistado a expandirse o confi

informacin de una respuesta anterior, y sealan que el entrevistador est escuchando y

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.

En general, un entrevistador no debe hacer preguntas sobre la informacin que es fcilmente

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

anlisis de documentos) y pregunte qu informacin se usa. Esto ayuda a enfocar al


entrevistado

en la tarea y ahorra tiempo, porque el entrevistado no necesita describir la informacin

detalle: l o ella solo necesita sealarlo en el formulario o informe.

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

informacin amplia y ms o menos definida. En este caso, el entrevistador tiene un sentido


general del

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

y sondear para obtener informacin importante sobre la mosca.

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,

cmo se aprueba la tarjeta de crdito de un cliente). En este momento, el analista realiza


entrevistas estructuradas,

en el que se desarrollan grupos especficos de preguntas antes de las entrevistas. Usualmente


son ms

preguntas cerradas en una entrevista estructurada que en el enfoque no estructurado.

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,

problemas generales y gradualmente trabaja hacia otros ms especficos. Con la entrevista de


abajo hacia arriba,

el entrevistador comienza con preguntas muy especficas y pasa a preguntas amplias. En la


prctica,

los analistas mezclan los dos enfoques, comenzando con cuestiones generales y generales,
pasando a preguntas especficas,

y luego volviendo a los problemas generales.

El enfoque de arriba hacia abajo es una estrategia apropiada para la mayora de las entrevistas
(sin duda es el

enfoque ms comn). El enfoque de arriba hacia abajo permite que el entrevistado se


acostumbre

al tema antes de que l o ella necesite proporcionar especificaciones. Tambin permite al


entrevistador

para entender los problemas antes de pasar a los detalles porque el entrevistador podra no
tener

informacin suficiente al comienzo de la entrevista para hacer preguntas muy especficas.


Quizs la mayora

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

Comience con preguntas no polmicas y luego pase gradualmente a temas ms polmicos

despus de que el entrevistador haya desarrollado cierta relacin con el entrevistado.

Preguntas cerradas Cuntas rdenes telefnicas se reciben por da?


Cmo hacen los clientes pedidos?

Qu informacin falta en el informe de ventas mensual?

Preguntas abiertas Qu piensas sobre el sistema actual?

Cules son algunos de los problemas que enfrenta a diario?

Cules son algunas de las mejoras que le gustara ver en un

nuevo sistema?

Preguntas de prueba Por qu?

Puedes darme un ejemplo?

Puedes explicar eso con un poco ms de detalle?

FIGURA 3-4

Tres tipos de

Preguntas

Tipos de preguntas Ejemplos

Nivel alto:

Muy general

De arriba hacia abajo

De abajo hacia arriba

Nivel medio:

Moderadamente especfico

Nivel bajo:

Muy especifico

Cmo

puede pedir

tratamiento

Ser mejorado?

Cmo podemos reducir

la cantidad de veces que

los clientes devuelven artculos

Han ordenado?
Cmo podemos reducir el nmero de

errores en el procesamiento de los pedidos (por ejemplo, envo

los productos equivocados)?

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

se le preguntar en el orden apropiado, debe prever posibles respuestas y proporcionar


seguimiento

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 las entrevistas no estructuradas. Algunos analistas principiantes prefieren entrevistas no


estructuradas, pensando

que pueden aletear. Esto es muy peligroso y a menudo contraproducente, porque cualquier

la informacin no recopilada en la primera entrevista requerir esfuerzos de seguimiento, y la


mayora de los usuarios

no me gusta ser entrevistado repetidamente sobre los mismos problemas.

El entrevistador debe asegurarse de preparar al entrevistado tambin. Cuando la entrevista

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

y organizar sus pensamientos. Esto es particularmente importante cuando el entrevistador es

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

son queridos El entrevistador debe parecer un profesional e imparcial, independiente


buscador de informacin. La entrevista debe comenzar con una explicacin de por qu el
entrevistador

est all y por qu l o ella han elegido entrevistar a la persona; entonces el entrevistador

debe pasar a las preguntas planificadas de la entrevista.

Es fundamental registrar cuidadosamente toda la informacin que proporciona el


entrevistado. En nuestro

experiencia, el mejor enfoque es tomar notas cuidadosas: escriba todo lo que el entrevistado

dice, incluso si no aparece inmediatamente relevante. El entrevistador no debe temer


preguntar

la persona a reducir la velocidad o hacer una pausa mientras escribe, porque esta es una clara
indicacin de que el

la informacin del entrevistado es importante. Un problema potencialmente controvertido es


si

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

prcticas generalmente aceptadas sobre la grabacin de entrevistas, por lo que deben


determinarse

antes de una entrevista. Si el entrevistador est preocupado por la prdida de informacin y


no puede grabar

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.

Si el entrevistador no entiende algo, l o ella debe pedir una aclaracin.

El entrevistador no debe temer hacer preguntas tontas, porque lo nico peor

que parecer tonto es ser tonto al no entender algo. Si el entrevistador

no entiende algo durante la entrevista, l o ella ciertamente no lo entender

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

y tambin demuestra que el entrevistador est escuchando.

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

deberan ser abordados por el nuevo sistema, incluso si estn disminuyendo.

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.

En la mayora de los casos, el entrevistado no tiene preocupaciones o informacin adicional,


pero en algunos casos

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.

El entrevistador no debe prometer prematuramente ciertas caractersticas en el nuevo sistema


o una especifi

c fecha de entrega, pero l o ella debe asegurarle al entrevistado que su tiempo estuvo bien

gastado y muy til para el proyecto.

Despus de que la entrevista haya terminado, el analista debe preparar un informe de


entrevista que describa el
informacin de la entrevista (Figura 3-6). El informe contiene notas de la entrevista,
informacin

que se recopil en el transcurso de la entrevista y se resume en un formato til. En

En general, el informe de la entrevista debe escribirse dentro de las cuarenta y ocho horas de
la entrevista.

porque cuanto ms espere el entrevistador, ms probable es que olvide la informacin.

A menudo, el informe de la entrevista se enva al entrevistado con una solicitud para leerlo e
informarle

el analista de clarificaciones o actualizaciones. El entrevistado debe estar convencido de que el


entrevistador

genuinamente quiere sus correcciones al informe. Usualmente hay pocos cambios, pero

la necesidad de cambios significativos sugiere que se requerir una segunda entrevista. Nunca

distribuir la informacin de alguien sin aprobacin previa.

Desarrollo de aplicaciones conjuntas (JAD)

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

9 Se puede encontrar ms informacin sobre JAD en J. Wood y D. Silver, Joint Application


Development (Nueva York:

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

Notas de la entrevista Aprobado por: Linda Estey

Persona entrevistada: Linda Estey,

Director, Recursos Humanos

Entrevistador: Barbara Wixom

Propsito de la entrevista:

Comprender los informes producidos para Recursos Humanos por el sistema actual

Determinar los requisitos de informacin para el sistema futuro


Resumen de la entrevista:

Ejemplos de informes de todos los informes actuales de recursos humanos se adjuntan a


este informe. La informacin que no es

la informacin usada y faltante se anota en los informes.

Los dos mayores problemas con el sistema actual son:

1. Los datos son demasiado viejos (el Departamento de Recursos Humanos necesita
informacin dentro de los dos das de finalizado el mes;

actualmente, se les proporciona informacin despus de un retraso de tres semanas)

2. Los datos son de baja calidad (a menudo los informes deben conciliarse con los
departamentos de recursos humanos

base de datos)

Los errores de datos ms comunes encontrados en el sistema actual incluyen informacin


incorrecta del nivel de trabajo y

falta de informacin salarial.

Artculos abiertos:

Obtenga el informe actual de la lista de empleados de Mary Skudrna (extensin 4355).

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.

Notas detalladas: ver la transcripcin adjunta.

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

del proceso de desarrollo.10

JAD es un proceso estructurado en el que de diez a veinte usuarios se renen bajo la direccin

de un facilitador experto en tcnicas JAD. El facilitador establece la agenda de la reunin y

gua la discusin, pero no se une a la discusin como participante. l o ella no

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

y tcnicas de diseo. Uno o dos escribas ayudan al facilitador grabando notas,

haciendo copias, y as sucesivamente. A menudo, los escribas usan computadoras y


herramientas CASE para registrar informacin

como el procedimiento de la sesin JAD.

El grupo JAD se rene durante varias horas, varios das o varias semanas hasta que todos los
problemas

se han discutido y se recopila la informacin necesaria. La mayora de las sesiones de JAD


tienen lugar

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

grfico y / o retroproyector para uso del facilitador que dirige la discusin.

Desarrollar habilidades interpersonales

Las habilidades interpersonales son habilidades que te permiten desarrollar

relacin con otros, y son muy importantes para

entrevistando. Te ayudan a comunicarte con los dems

eficazmente. Algunas personas desarrollan buenas relaciones interpersonales

habilidades a una edad temprana; simplemente parecen saber cmo

comunicarse e interactuar con otros. Otras personas son

menos afortunados y necesitan trabajar duro para desarrollar sus habilidades.

Se pueden aprender habilidades interpersonales, como la mayora de las habilidades.

Aqu hay algunos consejos:

No te preocupes, s feliz. Las personas felices irradian confi

dencia y proyectar sus sentimientos sobre los dems. Intente entrevistar

alguien mientras sonre y luego entrevista

alguien ms mientras frunce el ceo y ve lo que sucede.

Presta atencin. Presta atencin a lo que la otra persona

est diciendo (que es ms difcil de lo que piensas). Ver


cuantas veces te atrapas con tu mente

en algo ms que la conversacin en cuestin.

Resumir puntos clave. Al final de cada gran evento

tema o idea que alguien explica, repita la tecla

seala al hablante (por ejemplo, Djame asegurarme de que

entender. Los problemas clave son . . . "). Esto demuestra

que consideras importante la informacin,

y tambin te obliga a prestar atencin (no puedes

repite lo que no escuchaste).

Sea conciso. Cuando hable, sea breve. La meta

en las entrevistas (y en gran parte de la vida) es aprender, no

impresionar. Cuanto ms hablas, menos tiempo le das

a otros.

Se honesto. Responda todas las preguntas con sinceridad, y si

no s la respuesta, dilo.

Mire el lenguaje corporal (el suyo y el de ellos). La forma en que

la persona que se sienta o se encuentra transmite mucha informacin. En

en general, una persona que est interesada en lo que eres

diciendo se sienta o se inclina hacia adelante, hace contacto visual, y

a menudo toca su cara. Una persona inclinada

de usted o con un brazo sobre el respaldo de una silla es

desinteresado. Los brazos cruzados indican defensiva o

incertidumbre, y la inclinacin (sentado con las manos levantadas

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

dominan la discusin, y no todos participan. En un grupo de cinco miembros, por ejemplo,

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.

Los participantes de JAD se seleccionan de la misma manera que los participantes de la


entrevista, con base en el

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.

11 Para obtener ms informacin sobre e-JAD, consulte A. R. Dennis, G. S. Hayes y R. M.


Daniels, "Business Process Modeling".

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

El facilitador de JAD es un consultor externo a la organizacin porque la organizacin podra no


tiene una necesidad recurrente de experiencia en JAD o e-JAD. Desarrollar y mantener esta
experiencia

en casa puede ser costoso.

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

los modelos funcionales o la definicin de requisitos.

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

los participantes se cansan fcilmente

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

traer manuales de procedimientos y documentos con ellos. Si el objetivo es identificar mejoras

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,

aceptando el desacuerdo y asegurando que solo una persona hable a la vez.

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

no necesariamente de acuerdo con las opiniones y situaciones diferentes de las suyas

experiencia en anlisis y diseo de sistemas, JAD y habilidades interpersonales. Pocos analistas


de sistemas

intentar facilitar las sesiones de JAD sin entrenarse en tcnicas de JAD, y la mayora de los
aprendices

con un facilitador hbil de JAD antes de intentar dirigir su primera sesin.

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

volviendo a encarrilar al grupo.

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,

minimizar el aprendizaje requerido y ensear a los participantes cmo proporcionar de


manera efectiva el derecho

informacin.

Por ltimo, el facilitador registra la entrada del grupo en un rea de exposicin pblica, que
puede ser un

pizarra, tabla de flip o pantalla de computadora. l o ella estructura la informacin que el

group proporciona y ayuda al grupo a reconocer problemas clave y soluciones importantes. El


facilitador

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

dos despus de la sesin de JAD antes de que se complete el informe.

Cuestionarios

Un cuestionario es un conjunto de preguntas escritas utilizadas para obtener informacin de


individuos.

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

proveedores) o para sistemas con usuarios comerciales distribuidos en muchas ubicaciones


geogrficas.

La mayora de las personas piensa automticamente en el papel cuando piensan en


cuestionarios, pero hoy

se distribuyen ms cuestionarios en formato electrnico, ya sea por correo electrnico o en el

Web. La distribucin electrnica puede ahorrar una cantidad importante de dinero en


comparacin con la distribucin

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

informacin til. El enfoque estndar es seleccionar una muestra, o subconjunto, de personas


que

son representativos de un grupo completo. Las pautas de muestreo se discuten en la mayora


de las estadsticas

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

recibe un cuestionario en realidad lo completar. En promedio, solo del 30 al 50 por ciento de


papel
y se devuelven cuestionarios por correo electrnico. Las tasas de respuesta para los
cuestionarios basados en la web tienden a

ser significativamente menor (a menudo solo del 5 al 30 por ciento).

5. Seguimiento post-JAD

1. Seleccionar participantes

Manejando problemas en sesiones JAD

He realizado ms de cien sesiones de JAD y tengo

aprendido varios "trucos de facilitadores". Aqu hay algunos

problemas comunes y algunas formas de lidiar con ellos.

Dominacin. El facilitador debe asegurarse de que nadie

la persona domina la discusin grupal. La nica forma

lidiar con alguien que domina es frontal. Durante

un descanso, acercarse a la persona, agradecerle por

sus comentarios perspicaces, y le piden a la persona que

ayuda a asegurarte de que otros tambin participen.

No contributivos. Dibujando personas que han participado

muy poco es desafiante porque quieres

para llevarlos a la conversacin para que lo hagan

contribuir de nuevo El mejor enfoque es preguntar directamente

pregunta objetiva que est seguro de que pueden responder.

Y ayuda hacer la pregunta de una manera larga para dar

Es hora de pensar. Por ejemplo, "Pat, s que tienes

Trabaj rdenes de envo mucho tiempo. Probablemente has

estado en el departamento de envo ms tiempo que nadie

ms. Podran ayudarnos a entender exactamente lo que sucede?

cuando se recibe un pedido en el envo? "

Discusiones paralelas. A veces los participantes participan

conversaciones laterales y no prestar atencin a la

grupo. La solucin ms fcil es simplemente caminar cerca


a la gente y seguir facilitando justo en frente

de ellos. Pocas personas continuarn con una conversin secundaria

cuando ests a dos pies de ellos y la totalidad

la atencin del grupo est en ti y en ellos.

Agenda tiovivo. Se produce el tiovivo

cuando un miembro del grupo sigue volviendo al mismo

emitir cada pocos minutos y no lo soltar. Una solucin

es dejar que la persona tenga cinco minutos para divagar

sobre el tema mientras escribe cuidadosamente

cada punto en un grfico flip o archivo de computadora. Esta fl ip

grfico o archivo se publica visiblemente en el

pared. Cuando la persona plantea el problema nuevamente,

interrmpalos, camina hacia el peridico y pregntales qu

para agregar Si mencionan algo que ya est en la lista,

interrumpe rpidamente, seala que est all, y

preguntar qu otra informacin agregar No los dejes

repita el mismo punto, pero escriba cualquier informacin nueva.

Acuerdo violento. Algunos de los peores desacuerdos

ocurrir cuando los participantes realmente estn de acuerdo en los problemas

pero no se dan cuenta de que estn de acuerdo porque son

usando diferentes trminos. Un ejemplo es discutir si

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

facilitador tiene que traducir los trminos en diferentes

palabras y encontrar un terreno comn para que las partes reconocen

que realmente estn de acuerdo.

Conflicto no resuelto. En algunos casos, los participantes

no estoy de acuerdo y no puedo entender cmo determinar

qu alternativas son mejores Puedes ayudar mediante la estructuracin

la cuestin. Pregunte por los criterios por los cuales el grupo

identificar una buena alternativa (por ejemplo, "Supongamos que esta idea
Realmente mejor el servicio al cliente. Cmo podra

reconocer el servicio al cliente mejorado? "). Entonces

una vez que tenga una lista de criterios, solicite al grupo

evaluar las alternativas usndolos.

Conflicto verdadero. A veces, a pesar de todos los intentos, los participantes

simplemente no puedo estar de acuerdo en un problema. La solucion es

posponer la discusin y seguir adelante. Documento

el problema como un problema abierto y la lista de manera destacada en

un cuadro flip. Haga que el grupo regrese a las horas de emisin

luego. A menudo, el problema se habr resuelto por entonces

y no has perdido el tiempo en eso. Si el problema no puede

se resuelva ms tarde, muvelo a la lista de problemas para ser

decidido por el patrocinador del proyecto o algn otro ms

miembro senior de la gerencia.

Humor. El humor es una de las herramientas ms poderosas

el facilitador tiene, y por lo tanto, debe ser usado juiciosamente. los

el mejor humor de JAD siempre est en contexto; nunca contar chistes

pero aproveche la oportunidad para encontrar el humor en el

situacin.

Alan Dennis

PRCTICO

PROPINA

Debido a que la informacin en un cuestionario no puede ser aclarada inmediatamente por un


confundido

encuestado, el desarrollo de buenas preguntas es fundamental para los cuestionarios.


Preguntas sobre cuestionarios

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

hechos de opiniones. Las preguntas de opinin a menudo preguntan a los encuestados en qu


medida
de acuerdo o en desacuerdo (p. ej., Son comunes los problemas de red?), mientras que las
preguntas objetivas buscan ms

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

una comprensin clara de cmo se analizar la informacin recopilada del cuestionario

y usado. Este problema debe abordarse antes de que se distribuya el cuestionario, porque es

demasiado tarde para despus.

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

inmediatamente capta su inters y los induce a responderlo. Quizs el ms importante

El paso es hacer que varios colegas revisen el cuestionario y luego lo prueben con algunas
personas

extrado de los grupos a quienes se enviar. Es sorprendente cmo a menudo es


aparentemente simple

las preguntas pueden ser malentendidas.

La cuestin clave en la administracin del cuestionario es lograr que los participantes


completen el

cuestionario y envalo de vuelta. Decenas de libros de investigacin de marketing se han


escrito sobre

formas de mejorar las tasas de respuesta. Las tcnicas comnmente utilizadas incluyen una
explicacin clara de por qu

el cuestionario se est llevando a cabo y por qu el encuestado ha sido seleccionado,


indicando una fecha

mediante el cual se devolver el cuestionario, ofreciendo un incentivo para completar el


cuestionario
(por ejemplo, un bolgrafo gratis) y ofrece un resumen de las respuestas al cuestionario.

Los analistas de sistemas tienen tcnicas adicionales para mejorar las tasas de respuesta
dentro de la organizacin,

como entregar personalmente el cuestionario y contactar personalmente a los que

no los devolvieron despus de una semana o dos, as como solicitar a los supervisores de los
encuestados

para administrar los cuestionarios en una reunin de grupo.

Es til procesar los cuestionarios devueltos y desarrollar un informe de cuestionario poco


despus

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

comience revisando la documentacin y examinando el sistema en s.

Desafortunadamente, muchos sistemas no estn bien documentados porque los equipos de


proyecto no pueden

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

106 Captulo 3 Determinacin de requisitos

Comience con preguntas no amenazantes e interesantes.

Agrupe los artculos en secciones lgicamente coherentes.


No coloque artculos importantes al final del cuestionario.

No llene una pgina con demasiados elementos.

Evite las abreviaturas.

Evite artculos o trminos tendenciosos o sugestivos.

Nmero de preguntas para evitar confusiones.

Realice una prueba preliminar del cuestionario para identificar preguntas confusas.

Proporcionar el anonimato a los encuestados.

FIGURA 3-7

Buen cuestionario

Diseo

memorandos, manuales de polticas, manuales de capacitacin del usuario, organigramas,


formularios y, de

Por supuesto, la interfaz de usuario con el sistema existente.

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

formatos son necesarios.

Nombre: Buffy Pat Smith

Nombre de la mascota: Buffy Collie 6/6/99


Direccin: 100 Central Court. Apartamento 10

Toronto, Ontario K7L 3N6

Nmero de telfono: 555-3400

416-

Tienes seguro? S

Compaa de seguros: Pet's Mutual

Nmero de pliza: KA-5493243

CLNICA VETERINARIA CENTRAL

Tarjeta de informacin del paciente

El personal tuvo que agregar

informacin sobre el tipo de animal

y la fecha de nacimiento del animal. Esta

la informacin debe ser agregada a la

nueva forma en el sistema futuro.

El cliente cometi un error.

Esto debe ser etiquetado

Nombre del propietario para prevenir

Confusin.

El cliente no incluy

cdigo de rea en el telfono

nmero. Esto debe hacerse

Mas claro.

FIGURA 3-8

Realizando un

Anlisis de documentos

Tcnicas de recopilacin de requisitos 107

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

cursos?) La observacin es una buena manera de verificar la validez de la informacin


recopilada de forma indirecta

fuentes como entrevistas y cuestionarios.

En muchos sentidos, el analista se convierte en antroplogo mientras camina por el

organizacin y observa el sistema de negocios tal como funciona. El objetivo es mantener un


perfil bajo

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

rutina porque las personas tienden a ser extremadamente cuidadosas en su comportamiento


cuando estn siendo

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

t?). Nosotros, lo que ves puede no ser lo que obtienes.

La observacin a menudo se usa para complementar la informacin de la entrevista. La


ubicacin de la persona

La oficina y su mobiliario dan pistas sobre el poder e influencia de la persona en la


organizacin y

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

si la computadora nunca se enciende mientras el analista visita. En la mayora de los casos, la


observacin

admite la informacin que los usuarios proporcionan en las entrevistas. Cuando no lo hace, es
un importante

seal de que se debe tener especial cuidado al analizar el sistema comercial.

Seleccionar las tcnicas apropiadas

Cada una de las tcnicas de recopilacin de requisitos discutidas anteriormente tiene


fortalezas y debilidades.
Ninguna tcnica es siempre mejor que las dems, y en la prctica la mayora de los proyectos
usan una

combinacin de tcnicas. Para nosotros, es importante entender las fortalezas y debilidades

de cada tcnica y cundo usar cada una (ver Figura 3-9). Un tema no discutido es el de la

experiencia de los analistas En general, el anlisis y la observacin de documentos requieren la


menor cantidad

de entrenamiento, mientras que las sesiones de JAD son las ms desafiantes.

Tipo de informacin La primera caracterstica es el tipo de informacin. Algunas tcnicas son

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

comnmente utilizado en las tres etapas. Por el contrario, el anlisis y la observacin de


documentos generalmente son

ms til para entender el tal como est, aunque ocasionalmente proporcionan informacin
sobre

FIGURA 3-9 Tabla de tcnicas de recopilacin de requisitos

Tipo de informacin Tal como est, las mejoras, tal como estn, las mejoras, tal como estn,
las mejoras tal como estn

ser-a-ser

Profundidad de la informacin Alto Alto Medio Bajo Bajo

Amplitud de informacin Bajo Medio Alto Alto Bajo

Integracin de informacin Baja Alta Baja Baja Baja

Participacin del usuario Medio Alto Bajo Bajo Bajo

Costo Medio Bajo a Medio Bajo Bajo Bajo a Medio

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.

Profundidad de la informacin La profundidad de la informacin se refiere a qu tan rica y


detallada es la informacin

es que la tcnica generalmente produce y la medida en que la tcnica es til

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

Ms all de eso. Los cuestionarios pueden proporcionar una profundidad de informacin


media, solicitando ambos hechos

y opiniones con poca comprensin de por qu existen.

Amplitud de la informacin La amplitud de la informacin se refiere al rango de informacin e


informacin

fuentes que se pueden recolectar fcilmente usando la tcnica elegida. Cuestionarios y

el anlisis de documentos son fcilmente capaces de solicitar una amplia gama de informacin
de un gran

cantidad de fuentes de informacin. Por el contrario, las entrevistas y la observacin requieren


que el analista

visite cada fuente de informacin individualmente y, por lo tanto, tmese ms tiempo. Las
sesiones de JAD estn en

el medio porque muchas fuentes de informacin se juntan al mismo tiempo.

Integracin de la informacin Uno de los aspectos ms desafiantes de la recopilacin de


requisitos

est integrando la informacin de diferentes fuentes. En pocas palabras, las diferentes


personas pueden

proporcionar informacin de confl iccin. Combinando esta informacin e intentando resolver

las diferencias en las opiniones o los hechos suelen ser muy lentas, ya que implican el contacto

cada fuente de informacin a su vez, explicando la discrepancia e intentando refinar el

informacin. En muchos casos, el individuo percibe errneamente que el analista es desafiante

su informacin, cuando en realidad es otro usuario de la organizacin quien lo est haciendo.

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

para mejorar la integracin porque toda la informacin se integra cuando se recopila, no


despus.

Si dos usuarios proporcionan informacin de confl iccin, el conflicto se vuelve


inmediatamente obvio,

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.

Participacin del usuario La participacin del usuario se refiere a la cantidad de tiempo y


energa que se desea

los usuarios del nuevo sistema deben dedicarse al proceso de anlisis. En general, se acepta
que, como usuarios

involucrarse ms en el proceso de anlisis, la probabilidad de xito aumenta. Sin embargo,


usuario

la participacin puede tener un costo significativo, y no todos los usuarios estn dispuestos a
contribuir

tiempo y energa Los cuestionarios, el anlisis de documentos y la observacin colocan la


menor carga

en usuarios, mientras que las sesiones JAD requieren el mayor esfuerzo.

Costo El costo es siempre una consideracin importante. En general, cuestionarios, documento

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.

Sin embargo, las sesiones de JAD reducen significativamente el tiempo dedicado a la


integracin de informacin y

por lo tanto, puede costar menos a largo plazo.

Combinar tcnicas En la prctica, la recopilacin de requisitos combina una serie de tcnicas


diferentes.

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

rena el resto de la informacin necesaria para la imagen tal como est.


En nuestra experiencia, la identificacin de mejoras se realiza con mayor frecuencia utilizando
sesiones JAD

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

las sesiones son ampliamente compartidas.

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

el nuevo sistema es bien entendido.

TCNICAS DE DOCUMENTACIN DE REQUISITOS ALTERNATIVOS

Algunos otros requisitos muy tiles: tcnicas de recoleccin y documentacin incluyen

la creacin de prototipos, los casos de uso, las tarjetas CRC de roles con escenarios basados en
casos de uso,

mapeo de conceptos y grabacin de historias de usuarios en historietas y listas de tareas.


Prototipado de rowaway

se describi en el Captulo 1. En esencia, los prototipos desechables se crean para mejorar

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

es muy til para disear interfaces de usuario (ver Captulo 10).

Los casos de uso, como se describe en el Captulo 1, son el enfoque fundamental que el
Proceso Unificado

y el Lenguaje de modelado unificado (UML) para documentar y reunir requisitos funcionales.


Los describimos en el Captulo 4. Las tarjetas CRC de roles con situaciones basadas en casos de
uso son

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

describe el uso de mapas conceptuales que registran historias de usuarios en tarjetas de


historias y listas de tareas.

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

tcnica que se ha utilizado en escuelas, corporaciones y agencias de atencin mdica para


facilitar

aprendizaje, comprensin y creacin de conocimiento.13 La ventaja de la asignacin de


conceptos

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

entre los requisitos funcionales y no funcionales para ser explcitamente representados.

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

del enfoque textual, la relacin entre los requisitos funcionales y no funcionales

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

Los requisitos funcionales de Doctor Availability y Produce Schedule, respectivamente. Esto es


muy
Difcil de representar en una versin de solo texto de la definicin de requisitos. Adems, al
tener

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

las relaciones se perdern Sin embargo, combinando representaciones de texto y


representaciones de mapas conceptuales,

es posible aprovechar la fuerza de las representaciones tanto textuales como grficas para
obtener ms

representa completamente los requisitos.

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

tpicamente capturados usando tarjetas de historias (fichas) y se registran en una lista de


tareas (o desde

Perspectiva de Scrum, en la cartera de pedidos del producto). Se consideran tanto las


historietas como las listas de tareas

ser enfoques ligeros para documentar y reunir requisitos.14 Captura de historias

ambos requisitos funcionales y no funcionales. Por ejemplo, con respecto al mdico

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

satisfacer las necesidades de nuestros pacientes.

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

cables de impresora que conectan todas las computadoras a la impresora.

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

qu requisitos implementar primero. La ventaja de usar tarjetas de historias y listas de tareas

para documentar los requisitos es que son muy poco tecnolgicos, de alto toque, fcilmente
actualizables y

muy porttil.

112 Captulo 3 Determinacin de requisitos

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).

LA PROPUESTA DEL SISTEMA

Una propuesta de sistema rene en un nico documento integral el material creado

durante la planificacin y el anlisis. La propuesta del sistema generalmente incluye un


resumen ejecutivo,
la solicitud del sistema, el plan de trabajo, el anlisis de viabilidad, la definicin de requisitos y
la

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

de como un resumen de la propuesta completa. Su propsito es permitir que un ejecutivo


ocupado rpidamente

lalo y determine qu partes de la propuesta necesita pasar ms

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

Un resumen de toda la informacin esencial en la propuesta para que un ejecutivo ocupado


pueda leerla

rpidamente y decida qu partes de la propuesta leer con ms profundidad.

3. Solicitud del sistema

El formulario de solicitud de sistema revisado (ver Captulo 2).

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

Un diagrama de actividades, un conjunto de descripciones de casos de uso y un diagrama de


casos de uso que ilustran los

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

Un conjunto de diagramas de secuencia, diagramas de comunicacin, mquinas de estado de


comportamiento y un CRUDO

matriz que describe el comportamiento interno del sistema futuro (ver Captulo 6). Esto puede
incluir

modelos de comportamiento del sistema tal como es que ser reemplazado.

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

Propuesta del sistema

Modelo

15 Dependiendo del cliente, se pueden requerir especificaciones mucho ms detalladas; por


ejemplo, el Departamento

de Defensa, NASA, IEEE / ANSI y el Laboratorio de Investigacin Naval tienen formatos muy
especficos que deben ser

seguido. Para obtener ms informacin sobre estas especificaciones ms detalladas, consulte


A. M Davis, Requisitos de Soft ware,

Revisin (Upper Saddle River, NJ: Prentice Hall, 1993); G. Kotonya y I. Sommerville, Ingeniera
de requisitos

(Chichester, Inglaterra: Wiley, 1998); R. H. Th ayer y M. Dorfman (eds.), Soft ware


Requirements Engineering, 2nd Ed.

(Los Alamitos, CA: IEEE Computer Society Press, 1997).

APLICANDO LOS CONCEPTOS EN PATTERSON

HIPERMERCADO
El Captulo 3 introdujo la determinacin de requisitos para el desarrollo de sistemas orientados
a objetos

proyectos. La determinacin de los requisitos del sistema es la actividad ms importante en

el proceso de desarrollo de sistemas. Un requisito es QU debe hacer el sistema o QU

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

estn equivocados, el sistema estar equivocado.

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

requisitos funcionales y no funcionales que se desarrollaron y un borrador inicial del

desarrollando propuesta de sistemas para el proyecto. La propuesta de sistemas se terminar


despus de

el modelado funcional (Captulo 4), estructural (Captulo 5) y de comportamiento (Captulo 6)


de

el sistema ha sido completado.

Puede encontrar el resto del caso en: www.wiley.com/go/dennis/casestudy

REVISIN DEL CAPTULO

Despus de leer y estudiar este captulo, usted debera ser capaz de:

Crea una definicin de requisitos.

Diferenciar entre un requisito funcional y uno no funcional.

Discuta la estrategia de requisitos de anlisis de problemas.

Discuta la estrategia de requisitos de anlisis de causa raz.

Discuta la estrategia de requisitos de anlisis de duracin.

Discuta la estrategia de requisitos de anlisis de costos basados en actividades.

Discuta la estrategia de requisitos de anlisis de benchmarking informal.

Discuta la estrategia de requisitos de anlisis de resultados.

Discuta la estrategia de requisitos de anlisis de tecnologa.

Discuta la estrategia de requisitos de eliminacin de actividades.


Discuta cmo usar las entrevistas para reunir los requisitos.

Discuta cmo usar el desarrollo de aplicaciones conjuntas para reunir requisitos.

Discuta cmo usar los cuestionarios para reunir los requisitos.

Discuta cmo usar el anlisis de documentos para reunir requisitos.

Discuta cmo usar la observacin para reunir requisitos.

Describe cmo usar los mapas conceptuales para documentar los requisitos.

Describe cmo usar las fichas y las listas de tareas para documentar los requisitos.

Describa el propsito y contenido de la propuesta del sistema.

TRMINOS CLAVE

Eliminacin de actividad

Costeo basado en actividades

Anlisis

Sistema tal como est

Benchmarking

Entrevista de abajo hacia arriba

Amplitud de anlisis

Requisitos comerciales

Pregunta cerrada

Mapeo conceptual

Mapas conceptuales

Habilidades de pensamiento crtico

Anlisis de documentos

Anlisis de duracin

Electronic JAD (e-JAD)

Facilitador

Sistema formal

Requerimientos funcionales

Reglas de juego

Evaluacin comparativa informal

Sistema informal
Habilidades interpersonales

Entrevista

Notas de entrevista

Informe de entrevista

Horario de entrevista

JAD (aplicacin conjunta

desarrollo)

Requerimientos no funcionales

Observacin

Pregunta abierta

Anlisis de resultados

Paralelizacin

Integracin de proceso

Informe posterior a la sesin

Valor comercial potencial

Pregunta de prueba

Anlisis del problema

Costo del proyecto

Cuestionario

Requisito

Definicin de requisitos

Requisitos

determinacin

Riesgo

Causa principal

Anlisis de causa raz

Muestra

Escriba

Tarjetas de historia

Entrevista estructurada

Propuesta del sistema


Requisitos del sistema

Listas de tareas, 144

Anlisis de tecnologa

Sistema futuro

Entrevista descendente

Entrevista no estructurada

Historias de usuarios

Tutorial

PREGUNTAS

1. Cules son los resultados clave que se crean durante

anlisis? Cul es el producto final del anlisis?

y que contiene?

2. Cul es la diferencia entre un sistema tal como es y un

un sistema futuro?

3. Cul es el propsito de la definicin de requisitos?

4. Cules son los tres pasos bsicos del proceso de anlisis?

Qu paso a veces se omite o se hace en un resumen?

Moda? Por qu?

5. Comparar y contrastar el anlisis de problemas y la raz

Anlisis de causa. Bajo qu condiciones usaras

anlisis del problema? Bajo qu condiciones

usar anlisis de causa raz?

6. Comparar y contrastar el anlisis de duracin y actividad basada

costeo

7. Describe los cinco pasos principales en la realizacin de entrevistas.

8. Explicar las diferencias entre una pregunta cerrada,

una pregunta abierta y una pregunta inquisitiva.

Cundo usaras cada uno?

9. Explicar las diferencias entre las entrevistas no estructuradas

y entrevistas estructuradas. Cundo usaras

cada enfoque?
10. Explicar la diferencia entre un top-down y

Enfoque de entrevista ascendente. Cundo usaras

cada enfoque?

11. Cmo se seleccionan los participantes para las entrevistas y JAD?

sesiones?

12. Cmo se puede diferenciar entre hechos y opiniones?

Por qu ambos pueden ser tiles?

13. Describe los cinco pasos principales en la conduccin de JAD

sesiones

14. Cmo difiere un facilitador JAD de un escriba?

15. Cules son las tres cosas principales que un facilitador

Qu hace en la conduccin de la sesin JAD?

16. Qu es e-JAD y por qu una compaa podra estar interesada?

en usarlo?

17. Cmo difiere el diseo de preguntas para los cuestionarios?

desde el diseo de preguntas para entrevistas o sesiones de JAD?

18. Cules son las tasas de respuesta tpicas para los cuestionarios?

y cmo puedes mejorarlos?

19. Qu es el anlisis de documentos?

20. Cmo difiere el sistema formal de lo informal?

sistema? Cmo te ayuda el anlisis de documentos a comprender

ambos?

21. Cules son los aspectos clave del uso de la observacin en el

proceso de recopilacin de informacin?

22. Explique los factores que pueden usarse para seleccionar la recopilacin de informacin

tcnicas.

23. Cul es la principal ventaja de que los mapas conceptuales

tener sobre los documentos de requisitos textuales tradicionales

tcnicas?

24. Cules son algunas de las ventajas de usar tarjetas de historias?

y listas de tareas como una recopilacin de requisitos y documentacin


tcnica?

25. Qu informacin se incluye tpicamente en un sistema

propuesta?

26. Cul es el propsito del resumen ejecutivo de la

propuesta de sistema?

CEREMONIAS

A. Revise el sitio web de Amazon.com. Desarrolla el

definicin de requisitos para el sitio. Crear una lista

de requisitos comerciales funcionales que el sistema

cumple. Qu diferentes tipos de negocios no funcionales?

requisitos cumple el sistema? Proporcionar ejemplos

para cada tipo.

B. Suponga que va a construir un nuevo sistema que automatice

o mejora el proceso de entrevista para la carrera

departamento de servicios de tu escuela. Desarrollar requisitos

definicin para el nuevo sistema. Incluye ambos

requisitos funcionales y no funcionales del sistema.

Pretenda que lanzar el sistema en tres diferentes

versiones. Priorice los requisitos en consecuencia.

C. Describa en trminos muy generales el negocio tal como est

proceso para inscribirse en las clases de su universidad.

Colabora con otro estudiante en tu clase, y

evaluar el proceso usando anlisis de problemas y raz

Anlisis de causa. En funcin de su trabajo, enumere algunas mejoras

que has identificado

D. Describa en trminos muy generales el proceso comercial tal como est

para solicitar la admisin en tu universidad.

Colabora con otro estudiante en tu clase, y

evaluar el proceso utilizando benchmarking informal.

En funcin de su trabajo, enumere algunas mejoras que


han identificado

E. Describa en trminos muy generales el negocio tal como est

proceso para inscribirse en las clases de su universidad.

Colabora con otro estudiante en tu clase, y

evaluar el proceso usando la eliminacin de la actividad. Basado

en su trabajo, enumere algunas mejoras que tiene

identificado

F. Suponga que su universidad est teniendo un aumento dramtico

en la inscripcin y est teniendo dificultades para encontrar lo suficiente

asientos en cursos para estudiantes. Realizar una tecnologa

anlisis para identificar nuevas formas de ayudar a los estudiantes a completar

sus estudios y graduarse

G. Supongamos que usted es el analista encargado de desarrollar un

nuevo sistema para la librera universitaria para que los estudiantes

puede ordenar libros en lnea y hacer que se los entreguen a su

dormitorios o vivienda fuera del campamento. Qu requisitos recopilacin

tcnicas que usars? Describe en detalle

cmo aplicaras las tcnicas.

H. Supongamos que usted es el analista encargado de desarrollar

un nuevo sistema para ayudar a los gerentes senior a mejorar

decisiones estratgicas. Qu requisitos-recoleccin

tcnicas que usars? Describe en detalle cmo

aplicara las tcnicas.

I. Encontrar un compaero y entrevistarse sobre lo que

tareas que cada uno realiz en el ltimo trabajo que realiz (a tiempo completo,

a tiempo parcial, pasado o actual). Si no has trabajado

antes, entonces asume que tu trabajo es ser un estudiante.

Antes de hacer esto, desarrolle un breve plan de entrevista.

Despus de que su pareja lo entreviste, identifique el tipo

de entrevista, enfoque de entrevista y tipos de preguntas

usado.
J. Encuentra un grupo de estudiantes y ejecuta un sesenta minutos

JAD sesin sobre la mejora de las relaciones de ex alumnos en su

Universidad. Desarrolle un breve plan JAD, seleccione dos tcnicas

eso ayudar a identificar mejoras, y luego

desarrollar una agenda Realice la sesin usando el

agenda, y escriba su informe posterior a la sesin.

K. Encuentre un cuestionario en la Web que ha sido creado

para capturar informacin del cliente. Describe el propsito

de la encuesta, la forma en que las preguntas estn redactadas, y

cmo se han organizado las preguntas Cmo puede ser

mejorado? Cmo se analizarn las respuestas?

L. Desarrollar un cuestionario que ayudar a reunir informacin

con respecto a los procesos en un restaurante popular

o la cafetera de la universidad (por ejemplo, pedidos, servicio al cliente).

Entregue el cuestionario a diez o cinco estudiantes,

analizar las respuestas, y escribir un breve informe que

describe los resultados.

M. Pngase en contacto con el departamento de servicios de carrera en su universidad,

y encontrar todos los documentos pertinentes diseados

para ayudar a los estudiantes a encontrar un empleo permanente y / o a tiempo parcial

trabajos. Analiza los documentos y escribe un breve informe.

MINICASES

1. La Asociacin Estatal de Bomberos tiene una membresa

de 15,000. El propsito de la organizacin es proporcionar

algn apoyo financiero a las familias de los difuntos

miembros fi rati ghters y para organizar una conferencia

cada ao reuniendo a reflectores de todas partes

el estado. A los miembros se les cobran cuotas y llamadas anualmente.

Las llamadas son fondos adicionales necesarios para atender

pagos hechos a las familias de los miembros fallecidos.

El trabajo de contabilidad para la asociacin se maneja


por el tesorero electo, Bob Smith, aunque es

ampliamente conocido que su esposa, Laura, hace todo el trabajo.

Bob corre sin oposicin cada ao en la eleccin, porque

nadie quiere hacerse cargo de lo tedioso y lento

trabajo de seguimiento de membresas. Bob es pagado

un estipendio de $ 8,000 por ao, pero su esposa pasa bien

ms de veinte horas por semana en el trabajo. La organizacin,

sin embargo, no est contento con su desempeo.

Un sistema de computadora se utiliza para rastrear la facturacin y

recibo de fondos. Este sistema fue desarrollado en 1984

por un estudiante de informtica y su padre. Los

sistema es un sistema basado en DOS escrito usando dBase 3.

El problema ms inmediato que enfrenta el tesorero y

su esposa es el hecho de que el paquete de software no es ms

existe, y no hay nadie alrededor que sepa cmo

mantener el sistema Una consulta, en particular, toma

diecisiete horas para correr. Con los aos, solo tienen

evit ejecutar esta consulta, aunque la informacin

en eso sera bastante til. Preguntas de los miembros

con respecto a sus declaraciones no puede ser fcilmente

contestada. Por lo general, Bob o Laura solo anota el

consulta y devuelve una llamada con la respuesta. A veces

lleva de tres a cinco horas encontrar la informacin

necesario para responder la pregunta. A menudo, tienen que

realizar clculos manualmente porque el sistema

no fue programado para manejar ciertos tipos de consultas.

Cuando la informacin del miembro se ingresa en

sistema, cada campo se presenta uno a la vez, que

hace que sea muy difcil regresar a un campo y corregir

un valor que fue ingresado. Algunas veces un nuevo miembro es


ingresado pero desaparece de los registros. El informe

de la membresa utilizada en los materiales de la conferencia

no alfabetizar miembros por ciudad. Solo las ciudades estn listadas

en el orden correcto.

Qu estrategia o estrategias de anlisis de requisitos

recomendaras para esta situacin? Explique

tu respuesta.

2. Brian Callahan, gerente de proyecto de SI, est a punto de estar listo

partir para una reunin urgente convocada por Joe Campbell,

gerente de operaciones de fabricacin. Un gran proyecto

patrocinado por Joe recientemente aprob el obstculo de aprobacin,

y Brian ayud a llevar el proyecto a travs del proyecto

iniciacin. Ahora que el comit de aprobacin ha dado

el visto bueno, Brian ha estado trabajando en el proyecto

plan de anlisis.

Una noche, jugando al golf con un amigo que

trabaja en el departamento de operaciones de fabricacin,

Brian aprendi que Joe quiere impulsar el tiempo del proyecto

marco de la estimacin original de Brian de trece

meses. El amigo de Brian escuch a Joe decir: "No puedo ver

por qu ese equipo de proyecto de IS debe pasar todo ese tiempo

analizando cosas Tienen dos semanas programadas

solo para ver el sistema existente! Th en parece una

desperdicio real Quiero que ese equipo contine construyendo

mi sistema ".

Porque Brian tiene un poco de conocimiento interno sobre

La agenda de Joe para esta reunin, ha estado considerando

cmo manejar a Joe. Qu sugieres que Brian le cuente a Joe?

3. Barry recientemente ha sido asignado a un equipo de proyecto que

desarrollar un nuevo sistema de gestin de tiendas minoristas

para una cadena de tiendas de sndwiches submarinos. Barry


tiene varios aos de experiencia en programacin, pero

l no ha hecho mucho anlisis en su carrera. El era un

poco nervioso por el nuevo trabajo que estara haciendo,

pero estaba seguro de que poda manejar cualquier tarea

se le dio.

Una de las primeras tareas de Barry fue visitar uno

de las tiendas de sndwich submarino y preparar una

informe de observacin sobre cmo funciona la tienda. Barry

planeaba llegar a la tienda alrededor del medioda, pero l

eligi una tienda en un rea de la ciudad que no conoca

con, y debido a los retrasos de trfico y la dificultad para encontrar

la tienda, l no lleg hasta la 1:30. La tienda

gerente no lo esperaba y se neg a dejar un

extrao detrs del mostrador hasta que Barry tuvo su contacto

el patrocinador del proyecto (el director de administracin de la tienda)

en la sede de la empresa para verificar quin era l y

cul era su propsito

Despus de obtener permiso para observar, Barry finalmente

se estacion prominentemente en el rea de trabajo

detrs del mostrador para que pudiera ver todo.

El personal tuvo que maniobrar a su alrededor a medida que avanzaban

sobre sus tareas, pero solo hubo ocasionalmente

colisiones Barry not que el personal de la tienda

pareca estar haciendo su trabajo muy lentamente y

deliberadamente, pero supuso que era porque el

la tienda no estaba muy ocupada. Al principio, Barry cuestion cada

trabajador sobre lo que estaba haciendo, pero la tienda

gerente finalmente le pidi que no interrumpa su

trabajar tanto; estaba interfiriendo con su servicio

a los clientes

A las 3:30, Barry estaba un poco aburrido. l decidi irse,


fi gurando que podra volver a la oficina y prepararse

su informe antes de las 5:00 ese da. Estaba seguro de que su equipo

El lder estara satisfecho con su rpida finalizacin

de su asignacin. Mientras conduca, reflexion, "Eras

Realmente no ser mucho para decir en este informe. Todos ellos

hacer es tomar el pedido, hacer el sndwich, recoger el

pago, y entregar el pedido. Es realmente simple! "

La confianza de Barry en sus habilidades analticas se elev cuando l

anticip los elogios del lder de su equipo.

De vuelta en la tienda, el gerente de la tienda la sacudi

cabeza, comentando a su personal, "l viene aqu en el

tiempo ms lento del da en el da ms lento de la semana. l

Ni siquiera mir todo el trabajo que estaba haciendo en el

habitacin trasera mientras l estaba aqu, resumiendo lo de ayer

ventas, verificando el inventario disponible, inventando

reabastecer pedidos para el fin de semana. . . Adems, l ni siquiera

considerado nuestros procedimientos de apertura y cierre de tiendas.

Odio pensar que el nuevo sistema de gestin de la tienda

va a ser construido por alguien as. Ser mejor

pngase en contacto con Chuck [el director de administracin de la tienda]

y que sepa lo que pas aqu hoy

Evaluar la conducta de Barry de la observacin

asignacin.

4. Anne tiene la tarea de realizar una encuesta

de vendedores que utilizarn un nuevo sistema de entrada de pedidos

siendo desarrollado para un catlogo de productos para el hogar

empresa. El objetivo de la encuesta es identificar a los empleados

opiniones sobre las fortalezas y debilidades de la corriente

sistema. Hay alrededor de 50 empleados que trabajan en tres

Diferentes ciudades, por lo que una encuesta pareca una forma ideal de
reuniendo la informacin necesaria de los empleados.

Anne desarroll el cuestionario cuidadosamente y

lo pretest en varios supervisores de ventas que fueron

disponible en la sede corporativa. Despus de revisarlo

basado en sus sugerencias, ella envi una versin en papel

del cuestionario a cada empleado, pidiendo que sea

regres dentro de una semana. Despus de una semana, ella tena

solo regresaron tres cuestionarios completados. Despus

otra semana, Anne recibi solo dos ms completadas

cuestionarios Sintindote algo desesperado, Anne

luego envi una versin de correo electrnico del cuestionario,

nuevamente a todos los empleados, pidindoles que respondan

el cuestionario por correo electrnico tan pronto como sea posible. Ella

recibi dos cuestionarios por correo electrnico y tres mensajes

de los empleados que completaron la versin impresa

expresando molestia por estar molesto con el

mismo cuestionario por segunda vez. En este punto, Anne

tiene solo una tasa de respuesta del 14 por ciento, que est segura

no complacer a su lder de equipo. Qu sugerencias hacer

tienes que podra haber mejorado la respuesta de Anne

tasa para el cuestionario?

You might also like