Systems Analysis Design UML 5th Ed 127 172 Español

CHAPTER 3
Requisitos
Determinacin
D urante la fase de anlisis, el analista determina los requisitos funcionales para el

nuevo sistema. Este captulo comienza con la descripcin de la fase de anlisis y su principal
Entrega, la propuesta del sistema. El concepto de un requisito es explicada y varias
categoras de requisitos estn definidos. El propsito y la estructura de los requisitos
definicin declaracin est expuesto. Tcnicas para la obtencin de requisitos se
examinan, entrevistas, sesiones JAD, cuestionarios, anlisis de documentos y
observacin. Por ltimo, varios anlisis de requerimientos se describen las estrategias para
ayudar al analista descubrir necesidades.
Objetivos
Explicar la fase de anlisis del SDLC.
Describir el contenido y el propsito de la definicin de los requisitos de
declaracin.
Clasificar correctamente a los requisitos de negocio, el usuario, funcional o
requisitos no funcionales.
Emplear el requisito de la obtencin de las tcnicas de entrevistas, sesiones
JAD, cuestionarios, anlisis de documentos y observacin.
Definir el papel que cada requisito de la obtencin tcnica desempea en la
determinacin de las necesidades.
Describir varias estrategias de anlisis que puede ayudar al analista descubrir
necesidades.
Captulo esbozo
a
Introduccin d
La fase de anlisis e
Determinacin de requisitos c
Qu es un requisito? El u
proceso de determinar a
Requisitos d
La definicin de los requisitos a
de declaracin s
Las tcnicas de obtencin de los
requisitos de obtencin de requisitos
en la prctica entrevistas
Joint Application Development (JAD)
Cuestionarios
Observacin de anlisis
de documentos
La seleccin de las tcnicas
Aplicar los conceptos a sintonizar
Estrategias de Anlisis de requisitos fuente
Anlisis del problema el anlisis de causa raz Anlisis de Recabar y analizar requisitos
duracin
Propuesta de definicin de
Benchmarking de costos basada en actividad informal tecnologa
requisitos del sistema
de anlisis de resultados de la actividad de anlisis de eliminacin
Resumen
Comparacin de estrategias de anlisis
Aplicacin
Introduccin
La parte 2 de este libro se centra en la fase de anlisis del SDLC. El trabajo per-
formado en la fase de anlisis consiste en la ampliacin de la visin descrita en
la solicitud del sistema en una detallada comprensin de exactamente lo
que el nuevo sistema debe hacer. Como la comprensin detallada de lo que debe
hacer el nuevo sistema evoluciona, los detalles sern expresados y documentados
en varias formas, incluyendo una detallada definicin de los requisitos de
declaracin (este captulo), casos de uso (captulo 4), modelos de proceso
(captulo 5), y el modelo de datos (captulo 6). Aunque la estructura de un libro de
texto requiere que estos temas son presentados de forma secuencial, en la prctica,
el analista de sistemas utiliza todas las herramientas y las tcnicas que se abordan
en los captulos 3 a 6 durante la fase de anlisis para definir, clarificar y
documentar los requerimientos para el nuevo sistema.
La fase de anlisis
La fase de anlisis se denomina as porque el trmino anlisis se refiere a romper
un todo en sus partes con la intencin de conocer las partes de la naturaleza,
funcin y sus interrelaciones. En el contexto de la SDLC, las salidas de la fase de
planificacin (el sistema solicitud, estudio de viabilidad y plan de proyecto),
definir los objetivos de la empresa para el nuevo sistema, definir el alcance del
proyecto, evaluar la factibilidad del proyecto, y proporcionar el plan de trabajo
inicial. Estas entregas de la fase de planificacin son los insumos clave en la fase
de anlisis. En la fase de anlisis, el analista de sistemas trabaja intensamente con
los usuarios de negocios del nuevo sistema para comprender sus necesidades
desde el nuevo sistema. El proceso bsico de anlisis implica tres pasos:
Comprender la situacin existente (como es el sistema).

Identificar mejoras.
Definir los requisitos para el nuevo sistema (la del sistema).
A veces el primer paso (es decir, la comprensin del sistema as-

is) es omitido o realizado en forma limitada . Esto ocurre cuando no existe un
sistema actual, si el sistema existente y procesos son irrelevantes para el futuro
sistema, o si el equipo del proyecto est utilizando un RAD o metodologa de
desarrollo gil en el que el sistema no est subrayado. Tra- ditional mtodos como
cascada y desarrollo paralelo (vase el captulo 2) suelen dedicar un tiempo
considerable a la comprensin del sistema e identificar las mejoras antes de
mudarse a capturar requisitos para la sistema. RAD y nuevas metodologas giles,
tales como el desarrollo iterativo, sistema de prototipos descartables, proto-
escribiendo, y extreme programming (vase el captulo 2), se centran casi
exclusivamente en las mejoras y la requisitos del sistema, y dedican poco tiempo
para investigar la actual de sistema. La experiencia demuestra que es til para el
estudio de la situacin actual, siempre que sea posible. Los conocimientos
adquiridos a partir de la revisin del sistema existente puede ser muy valiosa para
el equipo de proyecto.
Para mover los usuarios "desde aqu hasta all", un analista necesita pensar
fuertemente crtico- ing aptitudes. El pensamiento crtico es la habilidad para
reconocer fortalezas y debilidades y reconstruir una idea en una forma mejorada.
Estas habilidades son necesarias para que el analista para comprender los
102 Captulo 3 Determinacin de requisitos
problemas y desarrollar nuevos y mejores procesos de negocio que se apoyan en
tecnologas de sistemas de informacin. Estas habilidades son esenciales en el
examen- la minera los resultados de deteccin de necesidades y traducir dichos
requisitos en un concepto para el nuevo sistema.
La fase de anlisis 103
Como ejemplo, supongamos que un usuario afirma que el nuevo sistema

debe "elimi- nate inventario existencias agotadas." Aunque esto pudiera ser
un digno objetivo del proyecto, el analista debe pensar crticamente a fin de
formular la declaracin en trminos de uso- ful requisitos. El analista podra tener
primero los usuarios piensan acerca de las circunstancias que conducen a las
roturas de stock (por ejemplo, rdenes de proveedor no estn colocados de forma
puntual) y, a continuacin, se describen los problemas que conducen a estas
circunstancias (por ejemplo, en mano de los niveles de inventario slo se
actualizan una vez a la semana; se producen retrasos en la identificacin de la
mejor fuente de abastecimiento de los productos; se producen demoras en recibir
la aprobacin de la orden de suministro, etc.). Al centrarse en estas cuestiones, el
equipo est en una mejor posicin para desarrollar nuevos procesos de negocio
que abordar estas preocupaciones. Los nuevos requisitos se basarn en las
cuestiones que verdaderamente necesitan ser reparadas. En este caso, los
requisitos pueden incluir, en parte:
El sistema deber actualizar a mano los niveles de inventario, dos veces al da.
El sistema deber producir un out-of-stock notificacin inmediatamente cuando
un elemento cantidad fsica alcanza el punto de punto de reordenacin.
El sistema deber incluir un proveedor recomendado con cada out-of-stock
notificacin.
El sistema deber producir un suministro de orden de compra que se enva al
gestor correspondiente para su aprobacin.
El sistema deber enviar una orden de compra de suministro aprobado por el
proveedor a travs de comunicacin electrnica segura.
Como este ejemplo demuestra, el analista no es realista esperar que los verdaderos
requisitos para el nuevo sistema son fcilmente recogidos
tras algunas conversaciones con las partes interesadas. El analista debe estar
preparado para profundizar en la situacin y dis- cubren las necesidades. Esto a
menudo no es un proceso fcil.
Un gran nmero de tcnicas y herramientas pueden ser
utilizadas por el analista para facilitar este proceso de deteccin de necesidades. En
este captulo, vamos a describir los techniques y herramientas para que usted
pueda aprender a utilizarlos durante la fase de anlisis. Tambin se explicar el
papel crucial que desempear en la definicin de los requisitos del nuevo sistema.
Como se mencion anteriormente, el analista tambin emplea herramientas
durante esta fase que son objeto de captulos completos: Casos de uso (captulo 4),
modelos de proceso (captulo 5), y los modelos de datos (captulo 6).
El resultado final de la fase de anlisis es la propuesta del sistema, que se
com- montones de sentencias de definicin de los requisitos detallados, casos de
uso, modelos de procesos, y el modelo de datos, junto con una versin revisada de
un anlisis de viabilidad y plan de trabajo. En la conclusin de la fase de anlisis,
el sistema es una propuesta que se presenta a la aprobacin de la comi- sin,
generalmente en la forma de caminar a travs del sistema. El objetivo de la
caminata es explicar en detalle el sistema moderado, a fin de que los usuarios,
administradores, y la llave de decisin makers claramente entendido, puede
identificar las modificaciones necesarias, y son capaces de tomar una decisin
sobre si el proyecto debe continuar. Antes de pasar a la fase de diseo, el proyecto
debera revisarse para garantizar que sigue aportando valor a la organizacin
empresarial. En caso de ser aprobada, la propuesta de crear un sistema de
componentes (definicin de requisitos, casos de uso, modelos de procesos, y el
102 Captulo 3 Determinacin de requisitos
modelo de datos) se utilizan como insumos para los pasos en la fase de diseo,
que refinar y definir con ms detalle cmo funciona el sistema ser construido.
La lnea entre las fases de anlisis y diseo es muy borrosa, porque las
entregas creadas en la fase de anlisis son realmente el primer paso en el diseo
del nuevo sistema. Muchas de las principales decisiones de diseo para el nuevo
sistema se encuentran en el anlisis entregas. De hecho, un mejor nombre para la
fase de anlisis que realmente
104 Chapter 3 Requirements Determination
"Anlisis y diseo inicial", sino porque este nombre es bastante larga y porque la
mayora de las organizaciones simplemente llaman a esta fase de "anlisis",
nosotros tambin. No obstante, es importante recordar que los entregables de la
fase de anlisis son realmente el primer paso en el diseo del nuevo sistema.
En muchos sentidos, la determinacin de las necesidades es el nico aspecto
ms crtico de todo el SDLC. Aunque son muchos los factores que contribuyen a
la falla de los sistemas de proyectos de desarrollo, fallando para determinar los
requisitos correctos es una causa primaria.1 Un estudio de 2008 de la empresa de
la lista Fortune 500 proyectos de desarrollo de software se encuentra el 37% de los
encuestados consider el proyecto cumple con las necesidades de los
usuarios.2 Por lo tanto, analistas debe dedicar gran atencin a la labor realizada en
la fase de anlisis. Es aqu que los principales elementos del sistema comienzan a
emerger. Si los requisitos se encontr ms tarde ser incorrecta o incompleta, puede
ser necesaria la rectificacin significativa, aadiendo sub- sustancial de tiempo y
costos para el proyecto.
Durante la determinacin de requisitos, la concepcin del sistema es fcil de
cambiar debido a que se ha hecho poco trabajo todava. A medida que el sistema
se desplaza a travs de los sub- sequent SDLC fases (diseo e implementacin), se
vuelve ms y ms difcil para volver a Determinacin de requisitos y hacer
cambios importantes a causa de todas la rectificacin de que se trate. Esta es la
razn por la que los enfoques iterativos de muchos RAD y metodologas giles
son tan efectivas-pequeos lotes de requisitos puede ser identi- zos e
implementado en etapas graduales, permitiendo al sistema general para cambiar y
evolucionar a lo largo del tiempo. Adems, metodologas como la V-modelo que
las pruebas de estrs para el sistema debe definirse al mismo tiempo que los
requisitos estn definidos. De ese modo, no es slo una prueba de ltimo minuto,
lanzados juntos, sino que se basa directamente en los requisitos del sistema a
medida que se definan.
Determinacin de requisitos
Determinacin de requisitos se realiza para transformar el sistema de solicitud
de declaracin de alto nivel de requisitos de negocio en una lista ms detallada,
precisa de lo que el nuevo sistema debe hacer para proporcionar el valor necesario
para el negocio. Esta lista detallada de requisitos es compatible, confirmado y
clarificado por las otras actividades de la fase de anlisis: la creacin de casos de
uso, la construccin de modelos de proceso, y la construccin de un modelo de
datos. En primer lugar debemos explicar qu es una exigencia y discutir el proceso
de creacin de una definicin de requisitos de declaracin.
Qu es un requisito?
Un requisito es simplemente una declaracin de lo que el sistema debe hacer o qu
caractersticas necesita tener. Durante un proyecto de desarrollo de sistemas, los
requisitos se cre- ciada que describen lo que el negocio necesita requisitos
empresariales (); lo que los usuarios necesitan para realizar los requisitos de usuario
(); lo que el software debe hacer requerimientos funcionales ( );
caractersticas debera tener el sistema ( requisitos no funcionales); y la forma en
que el sistema debe ser construido ( Requisitos del sistema). Aunque esta
lista de requisitos
Requirements Determination 105
1 Porejemplo, vase Kweku Ewusi-Mensah, fracasos en el desarrollo de software: Anatoma de los
proyectos fallidos, MIT Press, 2003.
2 JanetMullaney, "Recopilacin de requisitos carentes de recursos, prcticas en empresas de la lista Fortune
500, SearchSoftwareQuality.com," el 20 de agosto, 2008.
Categoras puede parecer intimidante al principio, las categoras reflejan

simplemente el propsito de los requisitos y la etapa en el centro de descargas de
Sun en el que estn definidas.
Ya hemos hablado de la creacin de los sistemas de solicitud en la fase de
planificacin del SDLC. En la peticin del sistema, hay declaraciones que
describen la rea- hijos de proponer el proyecto de desarrollo de sistemas. Estas
declaraciones reflejan los requisitos de negocio que este sistema, si se construye,
cumplir. Estos requerimientos de negocio ayudan a definir los objetivos
generales del sistema y ayudar a clarificar las contribuciones que hacen al xito de
la organizacin. Ejemplos de los requisitos de negocio incluyen: "Aumentar la
cuota de mercado"; "Acortar el tiempo de procesamiento del pedido"; "Reducir
cus- tomer costos de servicio"; "inventario menor corrupcin"; "Mejorar la
capacidad de respuesta a las solicitudes de servicio al cliente"; y "proporcionar
acceso a cuenta de clientes mviles." Cuando el proyecto de desarrollo de sistemas
est completa, el xito ser medido por evaluar si la declar requisitos
empresariales han sido efectivamente alcanzado; por lo tanto, proporcionan la
direccin general para el proyecto.
Durante la fase de anlisis, los requisitos estn escritos desde la perspectiva
de la empresa, y se centran en lo que el sistema necesita hacer para satisfacer busi-
ness las necesidades del usuario. Un buen punto de partida es concentrarse en lo
que el usuario realmente necesita para cumplir con el sistema a fin de cumplir una
funcin o tarea. Estos requisitos de usuario describir las tareas que los usuarios
realizan como parte integrante de las operaciones de la empresa, tales como:
"Programar una cita del cliente"; "un nuevo cus- tomer orden"; "Re-inventario
orden"; "Determinar el crdito disponible"; y "buscar saldos de cuenta." Los casos
de uso (discutidos en el captulo 4) son herramientas que se utilizan para aclarar
los pasos implicados en la realizacin de estas tareas de usuario. Mediante la
comprensin de lo que el usuario necesita hacer en trminos de tareas a realizar, el
analista puede entonces determinar la forma en que el nuevo sistema puede apoyar
las necesidades de los usuarios.
Determinar las formas en que el nuevo sistema puede apoyar las necesidades
de los usuarios lleva a declaraciones de los requisitos funcionales del sistema. Un
requisito funcional se relaciona directamente con un proceso, el sistema tiene que
funcionar como una parte de apoyar una tarea de usuario y/o la informacin que
necesita proporcionar el usuario est realizando una tarea. El Instituto
Internacional de Anlisis de negocio (IIBA) define los requisitos funcionales
como "las capacidades del producto, o cosas que un producto debe hacer para sus
usuarios."3 funcional comienza a definir los requisitos de cmo el sistema dar
soporte al usuario en com- pleting una tarea. Por ejemplo, supongamos que el
usuario requisito es "Programar una cita del cliente." Los requisitos funcionales
asociados con esa tarea incluyen: "determina la disponibilidad del cliente",
"encontrar vacantes disponibles disponibilidad cliente coincidentes", "Seleccionar la
cita", "Constancia de nombramiento", y "Confirmar cita." Observe cmo estos
requisitos funcionales ampliar la tarea del usuario para describir las capacidades y
funciones que el sistema deber incluir, permitiendo al usuario a completar la tarea.
Como el analista trabaja con las empresas usuarias del sistema a descubrir y
a los requerimientos funcionales del usuario, el usuario puede revelar procesos
que sern necesarios o informacin que sern necesarios. Por ejemplo, como se
muestra en la Figura 3-1, el usuario puede indicar "El sistema debe conservar el
historial de pedidos de los clientes durante tres aos" (una necesidad de
informacin). El analista debe sonda para el razonamiento detrs de esta
declaracin, como "El sistema debe permitir que los clientes registrados para
examinar su propio historial de pedidos de los ltimos tres aos" (un proceso que
necesita). Del mismo modo, el usuario puede indicar "El sistema debe verificar
rdenes de venta entrantes para disponibilidad de inventario" (un proceso que
necesita). Un analista de alerta reconocer la necesidad de informacin
relacionada, "El sistema debe
3 Instituto Internacional de Anlisis de negocios, Gua al cuerpo de conocimientos de anlisis de negocio (BABOK
), 2 Ed.
Requisito
Funcional Descripcin Ejemplos
Orientadas a procesos Un proceso que el sistema debe El sistema debe permitir que los clientes registrados para
realizar; un proceso que el sistema examinar su propio historial de pedidos de los ltimos tres aos.
debe hacer El sistema debe verificar rdenes de venta entrantes para
disponibilidad de inventario.
El sistema debe permitir a los estudiantes ver una programacin
de curso al registrarse para las clases.
Informacin orientada El sistema debe conservar el historial de pedidos de los clientes
El sistema debe contener informacin durante tres aos.
El sistema debe incluir los niveles de inventario en tiempo real en
todos los almacenes.
El sistema debe incluir presupuestadas y las ventas reales y los
montos de los gastos para el ao actual y los tres aos anteriores.
Figura 3-1
Requisitos funcionales.
Mantener los niveles de inventario en tiempo real en todos los almacenes." Todos
estos requisitos son necesarios para comprender plenamente el sistema que se
est desarrollando.
Modelos de proceso (captulo 5) se utilizan para explicar la relacin de
funciones y procesos a los usuarios del sistema, cmo las funciones y procesos se
relacionan entre s, cmo se introducen datos y producido por funciones o
procesos, funciones o procesos y cmo crear y utilizar los datos almacenados.
Modelos de proceso ayudan a aclarar los componentes de software que sern
necesarios para cumplir con los requisitos funcionales. Adems, los requisitos
funcionales comenzar a definir los datos que deben conservarse de pista para
poder llevar a cabo las tareas de usuario. Los datos de los componentes del
sistema se define en el modelo de datos (captulo 6).
YSUR 3-1 IDENTIFICACIN RREQUISITOS
TURN
Uno de los errores ms comunes 7. Tiene 2 segundos de tiempo mximo de respuesta para prede-
hechas por nuevos analistas se confunden y no funcional Consultas y multado con 10 minutos de tiempo de
respuesta mximo los requisitos funcionales. Pretender que usted recibi el fol- Para consultas ad hoc.
Bajar lista de requisitos para un sistema de ventas: 8. Incluir informacin de todas las filiales de la
compaa. Requisitos para el sistema propuesto: 9. Imprima informes subsidiarios en el idioma principal
del sistema debera... La filial.
10. proporcionar clasificaciones mensuales del vendedor el
rendimiento.
1. Ser accesible a los usuarios de la Web.
2. Incluir el logotipo de la empresa y la combinacin de colores. QUESTIONS:
3. Restringir el acceso a la informacin de la rentabilidad. 1. Qu requisitos son funcionales de negocio requieren-
4. Incluir informacin de costos presupuestados y reales. Declaraciones? Proporciona dos ejemplos adicionales.
5. Proporcionar informes de gestin. 2. Qu requisitos son inoperantes business
6. Incluir informacin de ventas que se actualiza por lo menos Requisitos? Qu tipo de funcionales requieren-
diariamente. Declaraciones son? Proporciona dos ejemplos
adicionales.
Los requisitos de usuario y requisitos funcionales definidos en la fase de

anlisis pasa a la fase de diseo, donde evolucionan para ser ms tcnico, que
describe cmo el sistema ser implementado. Requisitos en la fase de diseo reflejan
el desa- la perspectiva de oper, y usualmente se denominan requisitos del
sistema. Estos requisitos se centran en la descripcin de cmo crear el producto de
software que ser producido por el proyecto. Ms se dijo acerca de los requisitos del
sistema en la parte 3 del libro de texto.
Antes de continuar, queremos hacer hincapi en que puede ser difcil
de establecer un blanco y negro, la lnea divisoria entre estas categoras de
exigencia y, confusamente, algunas empresas utilizan los trminos
indistintamente. Lo importante para recordar es que un requisito es una
declaracin de lo que el sistema debe hacer, y el enfoque de las necesidades
cambiarn con el tiempo a medida que el proyecto avanza desde la planificacin
hasta el anlisis al diseo de la aplicacin. Requisitos evolucionan a partir de las
afirmaciones generales sobre todas las necesidades de las empresas en el sistema
de declaraciones detalladas de la empresa capabili- lazos que un sistema debe
apoyar a declaraciones tcnica detallada de la forma en que las funciones se
ejecutarn en el nuevo sistema.
La ltima categora de requisitos es requisitos no funcionales. El IIBA define
este grupo de requisitos como "los atributos de calidad, diseo y ejecucin
restricciones, y las interfaces externas que un producto debe tener."4 Aunque el
trmino "funcionales" no es muy descriptiva, este requisito cate- gory incluye
importantes propiedades de comportamiento que el sistema debe tener como, por
ejemplo, rendimiento y usabilidad. La posibilidad de acceder al sistema a travs de
un dispositivo mvil sera considerado un requisito no funcionales. Requisitos no
funcionales son usados principalmente en la fase de diseo cuando se toman
decisiones acerca del usuario inter- face, el hardware y el software, y la
arquitectura subyacente del sistema. Muchos de estos requisitos sern descubiertos
durante las conversaciones con los usuarios en la fase de anlisis, sin embargo, y
deben ser registrados como son descubiertos.
La figura 3-2 muestra una lista de los diferentes tipos de requisitos no
funcionales y ejemplos de cada tipo. Observe que los requisitos no funcionales
describir una variedad de caractersticas del sistema: funcionamiento, rendimiento,
seguridad y cultural y poltica. Estas caractersticas no describen procesos
comerciales o informacin, pero son muy importantes para comprender lo que el
sistema final como debe ser. Por ejemplo, el equipo de proyecto necesita saber si un
sistema debe ser altamente seguro, requiere sub- segundo tiempo de respuesta, o ha
de alcanzar una base de clientes multilinge. Estos exigen- cias afectar las
decisiones de diseo que se realizarn en la fase de diseo, especialmente el diseo
de la arquitectura, por lo que revisaremos en detalle en el Captulo 8. El objetivo en
este punto es identificar los temas principales. Adems, si la metodologa en uso
incluye el desarrollo de planes de pruebas durante el anlisis, a continuacin, estos
requisitos sern importantes para el establecimiento de puntos de referencia de
pruebas que ser necesario ms tarde.
El proceso de determinacin de los requisitos

Ambas perspectivas de negocio y son necesarios para determinar las necesidades
durante la fase de anlisis. Los analistas de sistemas no pueden comprender el
verdadero las necesidades empresariales de los usuarios. Un estudio reciente
realizado por el Standish Group constat que la falta de participacin de los
usuarios es la principal razn para que el proyecto fracase. 5 Por otra parte, los
usuarios empresariales pueden
4 Ibd.
5 Frank Hayes, "caos" est de vuelta, Computerworld, 8 de noviembre de 2004.

Inoperante.
Requisito Descripcin Ejemplos
Funcionamiento Los entornos fsicos y tcnicos en El sistema puede ejecutarse en dispositivos de mano.
Que el sistema funcionar El sistema debera ser capaz de integrarse con el
sistema de inventario existente.
El sistema debe ser capaz de trabajar en cualquier
navegador Web.
Rendimiento La velocidad, la capacidad y la fiabilidad del sistema cualquier interaccin entre el usuario y el sistema debera
No debe exceder de 2 segundos.
El sistema descarga los nuevos parmetros de estado
dentro de los 5 minutos de un cambio.
El sistema debe estar disponible las 24 horas al da, 365
das al ao.
El sistema admite 300 usuarios simultneos desde
9-11 a .m .; 150 usuarios simultneos en todas las otras veces.
La seguridad Quin tiene acceso autorizado al sistema bajo directa slo los administradores pueden ver los registros
de personal de los funcionarios. qu circunstancias Los clientes pueden ver su historial de pedidos slo
durante business
Horas.
El sistema incluye todas las salvaguardias disponibles
frente a virus, gusanos, caballos de Troya, etc.
Poltica y cultural Los factores culturales y polticos y legales El sistema debera ser capaz de distinguir entre EE.UU.
necesidades que afectan al sistema Moneda y divisas de otros pases.
La poltica de la empresa es slo comprar
ordenadores de Dell.
Los directores del pas son la facultad de autorizar las
interfaces de usuario personalizadas dentro de sus
dependencias.
La informacin personal est protegida de conformidad con el
Ley de Proteccin de datos.
Fuente: el Atlntico, el gremio de los sistemas http://www.systemsguild.com
Figura 3-2
Requisitos no funcionales
Conceptos 3-WHAT CUN HAPPEN SI STED Ignorar NONFUNCTIONAL RREQUISITOS

En accin
Una vez trabaj en una consultora pro- tecnologa que haba en el lugar era anticuado, pero ject en
que mi manager ha creado una definicin requisitos- sin embargo queran que el sistema funcione eficazmente en cin sin
enumerar requisitos no funcionales. El proyecto del equipo existente. Porque no establecimos el proyecto fue calculado
sobre la base de la definicin de los requisitos de alcance correctamente, incluyendo nuestros supuestos acerca de la no- y
vendido al cliente por $5.000. En la mente de mi jefe, requisitos funcionales en la definicin de requisitos, tenemos el
sistema que queremos construir para el cliente sera bsicamente tuvo que hacer lo que queran.
Muy sencillo sistema autnomo ejecutndose sobre tecnologa actual- Las capacidades queran tom varias
semanas para el diseo de tecnologa. No debe tomar ms de una semana para analizar, Y el programa. El proyecto
termin por tomar cuatro meses, disear y construir. Y el costo final del proyecto fue de $250.000.
Lamentablemente, nuestra empresa, el cliente tena otras ideas. Ellos Tena que ir a recoger a la ficha de todo
excepto el acuerdo quera un sistema para ser usado por muchas personas en tres A 5.000 dlares. Este fue, con mucho,
la ms frustrante project
Los diferentes departamentos, y queran que la habilidad para cualquier Situacin que
he experimentado. Barbara Wixom
Nmero de personas para trabajar en el sistema de forma simultnea. El
No ser conscientes de las posibilidades que

las nuevas tecnologas pueden ofrecer. Es importante que el equipo se consideren
cuidadosamente el proceso de negocio subyacente y la mejor forma de apoyar este
proceso empresarial con la tecnologa de sistemas de informacin.
Una buena analoga es la construccin de una casa o un apartamento. Todos
hemos vivido en una casa o apartamento, y la mayora de nosotros tenemos cierta
comprensin de lo que queremos en nuestros hogares. Si se nos pidi disear una
casa desde cero, sin embargo, que sera un reto porque nos falta el diseo
apropiado de las habilidades y conocimientos de ingeniera tcnica. Asimismo, un
arquitecto actuando solos, probablemente pierda algunos de nuestros requisitos
nicos.
Por lo tanto, el enfoque ms eficaz es tener ambos empresarios y analistas
que trabajan juntos para determinar las necesidades. De hecho, la fase de
anlisis implica importantes interacciones con las personas que tienen un inters en el
nuevo sistema (a menudo llamados stakeholders). Una de las primeras tareas para el
analista es identificar la primaria fuentes de requisitos, incluyendo el patrocinador del
proyecto, project champion(s), todos los usuarios del sistema (directos e indirectos), y
posiblemente otros. Es importante que todas las perspectivas del usuario estn
incluidos.
El analista tambin debe considerar la mejor manera de obtener los
requerimientos de los interesados. Hay una variedad de obtencin de las tcnicas
que pueden utilizarse para adquirir informacin, incluyendo entrevistas,
cuestionarios, observacin, aplicacin de desarrollo conjuntas (JAD), y anlisis
de documentos. Discutiremos estos techniques en la siguiente seccin. La
informacin recopilada por estas tcnicas es crticamente analizado y utilizado
para crear la definicin de requisitos de declaracin. El analista trabaja con todo el
equipo del proyecto y los usuarios de negocios para verificar, modificar y
completar la lista de requisitos y, si es necesario, para priorizar la importancia de
la exigen- cias que son identificados. Durante este proceso, los casos de uso,
modelos de proceso, y los modelos de datos pueden utilizarse para clarificar y
definir las ideas para el nuevo sistema. Este proceso contina durante la fase de
anlisis, y la definicin de los requisitos evoluciona con el tiempo a medida que se
identifican nuevos requisitos y a medida que el proyecto avanza en posteriores
fases del SDLC.
Cuidado: La evolucin de la definicin de requisitos debe administrarse
cuidadosamente. Mantenimiento de la lista de requisitos apretadas y concentrado
es una clave para el xito del proyecto. El equipo del proyecto no puede seguir
aadiendo nuevos elementos a las necesidades definicin- cin o el sistema
seguir creciendo y creciendo y nunca terminan . En su lugar, el equipo del
proyecto identifica y evala los requisitos cuidadosamente cules caben dentro
del alcance del sistema. Cuando un requisito refleja una necesidad de
negocio real, pero no est dentro del alcance del sistema actual o la versin
actual, que deben ser evaluados en trminos de su importancia y repercusin
en el tiempo y el presupuesto. Puede ser que el requisito esencial es
suficiente para agregar al proyecto actual, junto con los ajustes de apro-
piadas en el alcance del proyecto, presupuesto y plazos. No debemos asumir
que los requisitos para el proyecto nunca puede ser cambiado. Sin embargo,
tambin es posible que el requisito podra ser agregado a una lista de futuras
necesidades o poca prioridad. La gestin de los requisitos (y alcance del
sistema) es una de las partes ms difciles de administrar un proyecto!
La definicin de los requisitos de declaracin
La definicin de los requisitos de instruccin normalmente llamado simplemente
la definicin de requisitos-es un informe de texto
sencillo que simplemente enumera las caractersticas funcionales y no funcionales
los requisitos en un formato de esquema. La figura 3-3 muestra un ejemplo de
definicin de requisitos para viajes de vacaciones vehculos, un vehculo de
recreacin ficticia concesionario.
Requisitos funcionales.
1. Nueva gestin de vehculos

1.1 El sistema le permiten a los administradores ver el actual inventario de vehculos nuevos.
1.2 El sistema permitir que el nuevo vehculo manager para realizar pedidos de vehculos nuevos.
1.3 El sistema grabar la adicin de nuevos vehculos inventario cuando se reciben de los
fabricantes.
2. Gestin de ventas de vehculos

2.1 El sistema permitir a los vendedores para crear una oferta al cliente.
2.2 El sistema permitir a los vendedores para saber si una oferta es pendiente de un vehculo
especfico.
2.3 El sistema permitir a los administradores registrar la aprobacin de una oferta al cliente.
2.4 El sistema preparar un contrato de venta.
2.5 El sistema se prepara una orden de trabajo de fabricacin basado en cliente solicita opciones del
concesionario.
2.6 El sistema grabar un depsito del cliente.
2.7 El sistema grabar un pago de cliente.
2.8 El sistema crear un registro del vehculo del cliente compra.
3. Gestin de vehculos usados

3.1 El sistema grabar la informacin sobre un cliente-comercio en el vehculo...
Requisitos no funcionales
1. Funcionamiento
1.1 El sistema debera funcionar en equipos Tablet PC para ser usado por los vendedores.
1.2 El sistema debe interactuar con el sistema de gestin de la tienda.
1.3 El sistema debe conectarse a impresoras de forma inalmbrica.
2. Rendimiento
2.1 El sistema debe apoyar un equipo de ventas de 15 vendedores.
2.2 El sistema debe ser actualizado con ofertas pendientes en los vehculos cada 15 minutos.
3. La seguridad
3.1 No hay ningn vendedor puede acceder a cualquier otro vendedor de contactos de clientes.
3.2 Slo el propietario y gerente de ventas podr aprobar el cliente ofrece.
3.3 El uso de cada uno de los tablet PC debe estar restringido al vendedor a quien se ha
asignado.
4. Poltica y cultural
4.1 La poltica de la compaa dice que todos los equipos informticos se adquiri en Dell.
4.2 La informacin personal del cliente est protegida de conformidad con la Ley de Proteccin
de datos.
4.3 El sistema cumplir con la "ley del limn".
Figura 3-3
Definicin de requisitos de muestra
Como se muestra en la Figura 3-3, es comn a varios de los requisitos

legales o en un formato de esquema, de modo que cada requisito est claramente
identificado. Es importante que las necesidades se identifican con nmeros nicos
para que cada requisito puede ser fcilmente rastreados a travs de todo el proceso
de desarrollo. Para mayor claridad, las exigen- cias normalmente se agrupan en
grupos funcionales y no funcionales. Entonces,
Requirements Elicitation Techniques 111
Dentro de cada uno de esos grupos, se clasifican por el tipo de requisito o por rea
de negocio.
A veces, los requisitos son una prioridad en la definicin de requisitos de-
claracin. Ellos pueden ser clasificados como "alto", "medio" o "bajo" importancia
en el nuevo sistema, o pueden ser etiquetados con la versin del sistema que
abordar las necesidades (por ejemplo, versin 1, versin 2, versin 3). Esta
prctica es particularmente importante con RAD metodologas que entregar los
requisitos en lotes por desarrollando versiones incrementales del sistema.
El objetivo ms obvio de la definicin de los requisitos es proporcionar una
declaracin clara de lo que el nuevo sistema debe hacer para alcanzar la visin del
sistema descrito en la solicitud del sistema. Los casos de uso, modelos de
procesos, modelos de datos y proporcionar contenido adicional explicativo en
diferentes formatos. Un importante objetivo de la definicin de requisitos, sin
embargo, es definir el alcance del Sys- tem. El documento describe los analistas
exactamente lo que el sistema final tiene que hacer. Adems, sirve para establecer
las expectativas de los usuarios para el sistema. Si y cuando surgen discrepancias
o malentendidos, el documento sirve como un recurso de aclaracin.
Las tcnicas de obtencin de requisitos

Un analista es muy parecida a un detective (y usuarios empresariales a veces son
como elu- sive sospechosos). l o ella sabe que existe un problema que debe ser
resuelto y, por tanto, deben buscar pistas que desvelan la solucin.
Lamentablemente, los indicios no son siempre obvias (y a menudo son perdidas),
por lo que el analista debe notar los detalles, hablar con testigos y siga los cables,
as como Sherlock Holmes habra hecho. Los mejores analistas a fondo para
requisitos de bsqueda utilizando una variedad de tcnicas y asegurarse de que los
procesos comerciales actuales y las necesidades del nuevo sistema son bien
entendidas antes de pasar al diseo. Usted no quiere descubrir ms tarde que usted
tiene requisitos clave malas sorpresas como esta tarde en el centro de descargas de
Sun pueden causar todo tipo de problemas.
Obtencin de requisitos en la prctica

Antes de discutir los cinco requisitos obtencin tcnicas en detalle, unas prcticas-
tical consejos estn en orden. En primer lugar, el analista debe reconocer que
importantes efectos secundarios del proceso de definicin de requisitos que
incluyen la construccin de apoyo poltico para el proyecto y establecer un clima
de confianza y de relacin entre el equipo del proyecto y el ulti- mate a los
usuarios del sistema. Cada contacto y la interaccin entre el analista y un potencial
usuario de negocio o manager es una oportunidad para generar inters, enthusi-
asm y compromiso con el proyecto. Por lo tanto, el analista debe estar preparado
para hacer un buen uso de estas oportunidades a medida que surgen durante el
proceso de definicin de requisitos.
Segundo, el analista debe determinar cuidadosamente que se incluye en el
proceso de definicin de requisitos. La opcin de incluir (o excluir) alguien es
significativa; la participacin de alguien en el proceso implica que el analista
vistas a esa persona como un recurso importante de valores y sus opiniones.
Usted debe incluir a todos los actores (las personas que pueden afectar el sistema
o que se vern afectadas por el sistema). Esto podra incluir a los administradores,
empleados, funcionarios,
E incluso algunos clientes y proveedores. Tambin, ser sensible al hecho de que

algunas personas pueden tener una influencia significativa en la organizacin,
aunque no ocupa un lugar muy alto en la jerarqua de la organizacin formal. Si no
implican una clave por hijo, esa persona puede sentirse slighted, causando
problemas durante la ejecucin (por ejemplo, diciendo "Yo podra haber les dijo
que esto podra suceder, pero no me lo pregunten a m!"). Por ltimo, hacer todo
lo posible para respetar el compromiso de tiempo que usted est pidiendo a los
participantes que hagan. La mejor manera de hacer esto es estar completamente
preparado y hacer buen uso de todos los tipos de requisitos de la obtencin de
tcnicas. Aunque, como veremos, la entrevista es la tcnica ms utilizada, otros
mtodos indirectos pueden ayudar al analista elaborar una comprensin bsica del
dominio empresarial de modo que las tcnicas directas son ms productivos. En
general, una estrategia til para el analista a emplear es comenzar la recopilacin
de requisitos mediante entrevistas a altos directivos para tener una mejor
comprensin del proyecto y obtener la "gran imagen". Esas entrevistas
preliminares pueden luego ser seguido por el anlisis de los documentos y,
posiblemente, la observacin de los procesos empresariales para obtener ms
informacin sobre el negocio del dominio, el vocabulario, y la del sistema. Ms
entrevistas entonces puede seguir para recoger la
El resto de la informacin necesaria para comprender el sistema tal y como es.
En nuestra experiencia, la identificacin de mejoras es ms comnmente
realizada mediante sesiones JAD porque estas sesiones permiten a los usuarios y
actores clave para trabajar juntos y crear una comprensin compartida de las
posibilidades de la sistema. En ocasiones, estas sesiones JAD son seguidas por
cuestionarios enviados a un grupo mucho ms numeroso de usuarios o usuarios
potenciales para obtener una amplia gama de opiniones. La CEPT- para el sistema
a ser frecuentemente se desarroll a travs de entrevistas con altos directivos,
seguido por JAD sesiones con usuarios de todos los niveles, para asegurarse de
que los requisitos fundamentales del nuevo sistema son bien entendidas.
En esta seccin, nos centraremos en los cinco requisitos ms comnmente
utilizado tcnicas de obtencin: entrevistas, sesiones JAD, cuestionarios, anlisis
de documentos y observacin.
Entrevistas
La entrevista es la ms comnmente utilizada la tcnica de obtencin de
requisitos. Despus de todo, es natural --Generalmente, si necesitan saber algo,
pregunte a alguien. En general, hay entrevistas uno a uno (un entrevistador y un
entrevistado), pero a veces, debido a las limitaciones de tiempo, se entrevist a
varias personas al mismo tiempo. Hay cinco pasos bsicos para el proceso de la
entrevista: La seleccin de los entrevistados, el diseo de las preguntas de la
entrevista, la preparacin para la entrevista, realizacin de la inter- vista y
postinterview seguimiento6.
La seleccin de los entrevistados una entrevista horario debera

ser creado, anuncio que sern entrevistadas, la finalidad de la entrevista, y dnde y
cundo tendr lugar. (Consulte la Figura 3-4.) La programacin puede ser una lista
oficiosa que se utiliza para ayudar a configurar los horarios de las reuniones o una
lista formal que est incorporado en el plan de trabajo. Las personas que aparecen
en la programacin de la entrevista son seleccionados sobre la base de las
necesidades de informacin del analista. El patrocinador del proyecto, los
principales usuarios, y otros miembros del equipo del proyecto puede ayudar al
analista determinar quines en la organizacin mejor pueden proporcionar
informacin importante acerca de los requisitos. Estas personas aparecen en la
programacin de la entrevista en el orden en el que deberan ser entrevistados.
6 Un
buen libro en la entrevista de Brian James, el anlisis de sistemas entrevista,
Manchester: NCC Blackwell, 1989.
fin de
Nombre puesto Entrevista
Andria McClellan , Director visin estratgica para el Mon, el 1 de marzo

nuevo sistema de de8:00 a 10:00 a. m.
Jennifer Draper contabilidad Mon, el 1 de marzo
Gerente de Cuentas,
actuales problemas de2:00 a 3:15 p.M.
Gerente de cuentas con las cuentas por
Mark Goodin por cobrar, cobrar proceso; los Mon, el 1 de marzo
objetivos futuros
cuentas por pagar de4:00 a 5:15 p.M.
problemas actuales
, la entrada de datos relacionados con el
Anne Asher mi, 3 de marzo de
proceso de cuentas
10:00 a 11:00 a .m.
a pagar; objetivos
Fernando Merce supervisor encargado futuros mi, 3 de marzo de
Figura 3-4 1:00 a 3:00 p.M.
Programa de entrevistas de muestra procesos de cuentas por
de la introduccin de cobrar y por pagar
las cuentas por cobrar y
Las personas datos
en los diferentes niveles de laprocesos
por pagar organizacin tienen diferentes
puntos de vista sobre el sistema, por lo tanto, es importante incluir tanto los
administradores que gestionan los procesos y el personal que realmente llevan a cabo
procesos para obtener tanto de alto y bajo nivel de perspectivas sobre un problema.
Adems, el tipo de entrevistados que usted necesita puede cambiar con el tiempo. Por
ejemplo, al comienzo del proyecto, el analista tiene una limitada comprensin de
como es el proceso de negocio. Es comn comenzar por entrevistar a uno o dos
directivos para obtener una visin estratgica y luego pasar al nivel medio- man agers
quienes pueden brindar un amplio y general de informacin acerca de los procesos de
negocio y el papel esperado del sistema que se est elaborando. Una vez que el
analista tiene una buena comprensin de la gran imagen de nivel inferior, los gerentes
y los miembros del personal pueden rellenar los detalles exactos de cmo funciona el
proceso. Como la mayora de las otras cosas sobre el anlisis de sistemas, este es un
proceso iterativo, empezando por los altos directivos, Mover a gerentes de nivel
medio y, a continuacin, los miembros del personal, a los administradores de nivel
medio, y as sucesivamente, dependiendo de qu informacin es necesaria a lo largo
del camino.
Es bastante comn que la lista de los entrevistados a crecer, a menudo en un
50%-75%. Como usted entrevistar gente, probablemente identificar ms
informacin que se necesita y otras personas que puedan proporcionar la
informacin.
Conceptos 3-B SELECCIN DE LA WRONG Pas personas

En accin
En 1990, me llevaron a un equipo de consultora para una construccin. Estos individuos fueron los
primeros y segundos- de los grandes proyectos de desarrollo para los EE.UU. Ejrcito. El objetivo era ond los gerentes de
lnea de la funcin empresarial. La indi- para reemplazar ocho sistemas existentes utilizadas en virtualmente cada
viduals eran expertos en el manejo del proceso, pero no una base del ejrcito en los Estados Unidos. El proceso tal
como es y no conozco los detalles exactos de cmo funcionaba el proceso. Los modelos de datos de estos
sistemas han sido construidos, y nuestro trabajo La resultante a ser modelo de proceso era muy general y
Es identificar y desarrollar las oportunidades de mejora. Alan Dennis
Inespecficos.
A ser modelos de proceso para cada uno de los ocho sistemas.
Para el primer sistema, hemos seleccionado un grupo de nivel intermedio. QUESTION :
Los administradores (capitanes y comandantes) recomendado por su Supongamos que estaban a cargo del
proyecto. Crear una comandantes como expertos en el sistema bajo Programacin de entrevistas para los
restantes siete proyectos.
Diseo de las preguntas de la entrevista existen tres tipos de preguntas:

preguntas cerradas, preguntas abiertas y preguntas de sondeo. Cerrado-
terminaron las preguntas requieren una respuesta especfica. Se puede pensar en
ellos como similar a preguntas de opcin mltiple o aritmtico en un examen.
(Consulte la Figura 3-5). Las preguntas cerradas se utilizan cuando el analista est
buscando informaciones concretas y precisas (por ejemplo, cuntas solicitudes de
tarjeta de crdito son recibidos por da). En general, precisa preguntas, son los
mejores. Por ejemplo, en vez de preguntar "Usted maneja una gran cantidad de
peticiones?" es mejor preguntar "cuntas peticiones Proceso por da?".
Las preguntas cerradas permiten a los analistas para el control de la
entrevista y obtener la informacin que necesitan. Sin embargo, estos tipos de
preguntas no descubrir por qu la respuesta es como es, ni
tampoco revelar informacin que el entrevistador no piensa pedir antes de tiempo.
Las preguntas abiertas son aquellas que deja espacio para la elaboracin por
parte del entrevistado. Son similares en muchos aspectos a las preguntas de
redaccin que puede encontrar en un examen. (Consulte la Figura 3-5 para ver
ejemplos.) Las preguntas abiertas estn diseadas para recopilar abundante
informacin y dar el entrevistado ms control sobre la informacin que se puso de
manifiesto durante la entrevista. A veces los temas el entrevistado elige para
discutir descubrir informacin que es tan importante como la respuesta (por
ejemplo, si la interviewee habla slo sobre otros departamentos cuando se le
pregunt acerca de los problemas, se puede sugerir que l o ella es reacia a
reconocer sus propios problemas del departamento).
El tercer tipo de pregunta es la pregunta de tanteo. Preguntas de sondeo
el seguimiento de lo que ha sido discutido en orden para que el entrevistador para
aprender ms, y a menudo se utilizan cuando el entrevistador no est claro acerca
de la respuesta del entrevistado. Estimulan el entrevistado para ampliar o para
confirmar la informacin de una respuesta anteriores, y son una seal de que el
entrevistador est escuchando e interesado en el tema en discusin. Muchos
analistas de comienzo son reacios a utilizar preguntas de sondeo porque tienen
miedo de que el entrevistado puede ser ofendido por haber sido cuestionado o
porque creen que muestra que no entendan lo que el entrevistado dijo. Cuando
hace cortsmente, preguntas de sondeo puede ser una herramienta poderosa en el
descubrimiento de los requisitos.
En general, usted no debe hacer preguntas acerca de la informacin que se
encuentra fcilmente disponible de otras fuentes. Por ejemplo, en lugar de
preguntar qu informacin se utiliza para realizar una tarea, es ms fcil mostrar el
entrevistado un formulario o informe (vase el documento anlisis posterior) y
pregunte qu informacin sobre ti es utilizado. Esto ayuda a centrar
procesadas actualmente?
Cules son algunos de los problemas que enfrentan a diario?
Cules son algunas de las mejoras que le gustara ver en la forma
en que se procesan las facturas?
Preguntas de sondeo Por qu? Requirements Elicitation Techniques 117
Figura 3-5 Puede darme un ejemplo?
Tres tipos de preguntas Puede explicar que en un poco ms de detalle?
El entrevistado en la tarea y ahorra tiempo, porque l o ella no necesita para

describir la informacin en detalle, l o ella slo debe sealarlo en el formulario o
informe.
Las preguntas de la entrevista debe anticipar el tipo de informacin que el
interviewee es probable que sepan. Los gerentes son a menudo algo alejado de los
detalles de los procesos diarios de la empresa y as podra ser incapaz de responder a
preguntas sobre ellos, mientras que los miembros del personal de nivel inferior puede
responder prontamente. Por el contrario, empleados de nivel inferior no puede ser
amplio, capaz de responder a preguntas orientadas a la poltica, mientras que el
hombre podra agers. Puesto que nadie quiere parecer ignorantes, evitar la confusin
entre- viewees con preguntas fuera de sus reas de conocimiento.
Ningn tipo de pregunta es mejor que otro, y generalmente una combinacin
de preguntas, se utiliza durante una entrevista. En la etapa inicial de un proyecto
de desarrollo es el proceso puede ser confuso, por lo que el proceso de la
entrevista comienza con entrevistas no estructuradas, entrevistas que buscan una
amplia y aproximadamente un conjunto definido de informacin. En este caso, el
entrevistador tiene un sentido general de la informacin necesaria, pero pocas
preguntas cerradas a preguntar. Estos son los desafos ms entrevistas que pro-
ducto porque requieren el entrevistador para formular preguntas abiertas y de la
sonda para obtener importante informacin "sobre la marcha".
A medida que avanza el proyecto, el analista trata de comprender el proceso
de negocio mucho mejor, y que l o ella necesita informacin muy especfica
sobre cmo business se realizan procesos (p. ej., exactamente cmo un cliente
solicitud de crdito es aprobada). En este momento, el analista realiza entrevistas
estructuradas en las que determinadas series de preguntas se desarroll antes de las
entrevistas. Por lo general son ms las preguntas cerradas en una entrevista
estructurada que en el enfoque no estructurado.
No importa qu tipo de entrevista se llev a cabo la entrevista, las preguntas
deben ser organizados en una secuencia lgica de modo que la entrevista fluye
bien. Por ejemplo, al intentar recopilar informacin acerca del actual proceso, el
analista de negocios encontrarn til para moverse en un orden lgico a travs del
proceso o de los problemas ms importantes a los menos importantes.
Existen dos enfoques fundamentales para organizar las preguntas de la
entrevista: de arriba abajo o de abajo arriba; vase la figura 3-6). Con el top-down
entrevista, el encuestador comienza con amplia, temas generales y poco a poco va
hacia ms especfico
Alto nivel: C
mo
pued
e
mejorarse el
procesamient
nivel medio muy o de pedidos
generales: Moderadament
e
especficas Cmo se puede
de reducir el nmero
de veces que los clientes
devuelvan artculos que han
Figura 3-6 ordenado?
bajo nivel muy
especficas: Cmo podemos reducir el
Bottom-Up descendente y
cuestionando las estrategias
Queridos. Con el bottom-up entrevista, el entrevistador comienza con preguntas,

muy especficas y se traslada a preguntas generales. En la prctica, los analistas
mezclar los dos enfoques, a partir de cuestiones generales, Mover a preguntas
especficas y, a continuacin, volver a cuestiones generales.
El enfoque top down es una estrategia apropiada para la mayora de las
entrevistas. (sin duda es el enfoque ms comn.) El enfoque top down permite la
interviewee acostumbrarse al tema antes de que l o ella necesita para
proporcionar mayores detalles. Tambin permite que el entrevistador para
comprender las cuestiones antes de pasar a los detalles, porque el entrevistador
puede no tener suficiente informacin al comienzo de la entrevista a preguntas
especficas. Quizs lo ms importante, el enfoque top-down permite al
entrevistado para levantar un conjunto de grandes problemas con la imagen antes
de quedar atrapados en los detalles, por lo que el entrevistador es menos probable
que pierda importantes cuestiones.
Un caso en el cual la estrategia bottom-up puede ser preferida
es cuando el analista ya ha reunido una gran cantidad de informacin acerca de
cuestiones y slo necesita rellenar agujeros con algunos detalles. O bottom-
up, puede ser apropiado si los miembros del personal de nivel inferior se sienten
amenazados o son incapaces de responder a las preguntas de alto
nivel. Por ejemplo, "Cmo podemos mejorar el servicio al cliente?" Puede ser
una cuestin demasiado amplia para un empleado del servicio de atencin al
cliente, mientras que una pregunta especfica es fcilmente respondible (p.
ej., "Cmo podemos acelerar las devoluciones de los clientes?"). En cualquier
caso, todas las entrevistas deben comenzar con no- cuestiones controvertidas
primero y luego avanzar gradualmente hacia cuestiones ms controvertidas despus
de que el entrevistador ha desarrollado cierta empata con el entrevistado.
Preparacin para la entrevista , es importante prepararse para la entrevista de la

misma forma que se preparara para dar una presentacin. Usted debe tener un
plan de vista general inter- que enumera las preguntas que le preguntar en el
orden apropiado; antic- ipates proporciona respuestas posibles y cmo se har el
seguimiento con ellos; e identifica segues entre temas relacionados. Confirmar las
reas en las que el entrevistado tiene conocimientos de modo que usted no haga
preguntas que l o ella no puede responder. Revisar los temas, las preguntas, y el
plan para la entrevista, y claramente decidir cules tienen mayor prioridad en caso
de que se agote el tiempo.
En general, las entrevistas estructuradas con preguntas cerradas tomar ms
tiempo para la preparacin de entrevistas no estructuradas. As, algunos analistas
prefieren inicio entrevistas no estructuradas, pensando que pueden
"improvisar ". Esto es muy peligroso y a menudo contraproducente, porque
cualquier informacin no recogida en la primera vista inter- tendra que obtenerse
mediante esfuerzos de seguimiento, y la mayora de la gente no le gusta ser
entrevistado reiteradamente sobre los mismos temas.
Asegrese de preparar el entrevistado . Cuando programe
la entrevista, informar al entrevistado de la razn de la entrevista y las reas que se
dis- soltando palabrotas con suficiente antelacin para que l o ella tenga tiempo
para pensar acerca de los temas y organizar sus pensamientos. Esto es
particularmente importante cuando un sider a la organizacin y para entrevistar a
empleados de nivel inferior que a menudo se les pide su opinin y que puede ser
incierto acerca del motivo por el que inter- verlas.
Realizacin de la entrevista al iniciar la entrevista, el primer objetivo es

construir una relacin con el entrevistado para que l o ella confa en usted y est
dispuesto a decirle toda la verdad, no dar las respuestas que l o ella piense que
usted desee. Usted debe aparecer con un profesional imparcial, independiente y un
buscador de la informacin. La entrevista debe comenzar con una explicacin de
por qu estn all y por qu
Usted ha elegido para entrevistar a la persona y, a continuacin, avanzar en su

planificacin de inter- ver las preguntas.
Es fundamental registrar cuidadosamente toda la informacin que el
entrevistado proporciona. En nuestra experiencia, el mejor enfoque es
tomar notas cuidadosamente-anote todo lo que el entrevistado dice, incluso
si no aparecen inmediatamente pertinentes. No tenga miedo de pedirle a
la persona para ralentizar o para hacer una pausa mientras escribe , porque esta es
una clara indicacin de que el entrevistado la informacin es importante para
usted. Uno potencialmente controvertida es la necesidad o no
de grabar la entrevista. La grabacin se asegura de que usted no pierda puntos
importantes, pero puede ser intimidante para el entrevistado. La mayora de las
organizaciones tienen polticas o prcticas generalmente aceptadas acerca
de la grabacin de las entrevistas, a fin de averiguar cules son antes
de comenzar una entrevista. Si usted est preocupado por la falta de informacin
y no tape la entrevista, luego de traer una segunda persona para tomar notas
detalladas.
A lo largo de la entrevista, es importante que usted entienda los temas que se
discuten. Si usted no entiende algo, asegrese de preguntar. No tengas miedo de
preguntar las preguntas "tontas", porque la nica cosa peor que aparezcan "tonta"
es ser "tonto" por no entender algo que usted podra haberse despejado por cues-
cionado. Si usted no entiende algo durante la entrevista, usted ciertamente no
entenderlo despus. Intentar reconocer y definir la jerga y asegrese de aclarar la
jerga que no entienda. Una buena estrategia para aumentar la comprensin
durante una entrevista es peridicamente para resumir los puntos clave en los que
el entrevistado se est comunicando. Esto evita confusiones y demonio tambin
demuestra que usted est escuchando.
Por ltimo, asegrese de separar los hechos de las opiniones. El
entrevistado puede decir, por ejemplo, "procesamos demasiadas solicitudes de tarjeta
de crdito." Esta es una opinin, y es til para seguir con una pregunta de tanteo
solicitando apoyo para la declaracin (por ejemplo, "Oh, cuntos proceso en un
da?"). Es til para verificar los hechos, puesto que las diferencias entre los hechos
y las opiniones del entrevistado puede sealar las reas clave de mejora.
Supongamos que el entrevistado se queja sobre un alto o creciente nmero de
errores, pero los registros muestran que los errores han ido disminuyendo. Esto
sugiere que los errores son vistos como un problema muy importante que debe ser
abordado por el nuevo sistema, incluso si estn disminuyendo.
Como la entrevista llega a su fin, asegrese de darle tiempo al entrevistado
para hacer preguntas o proporcionar informacin que l o ella piensa que es
importante, pero no era parte de su plan para la entrevista. En la mayora de los
casos, el entrevistado no tendr- cin adicional o informacin, pero en algunos
casos esto conducir a imprevista, pero la informacin importante. Asimismo,
puede ser til pedir al entrevistado si hay otras personas que deben ser
entrevistados. Asegrese de que la entrevista termina en el tiempo. (Si es
necesario, omitir algunos temas o plan para programar otra entrevista).
Como ltimo paso en la entrevista, explicar brevemente qu suceder a
continuacin. (Consulte la siguiente seccin.) Usted no quiere prematuramente la
promesa de determinadas caractersticas en el sistema nuevo o una fecha de
entrega especfica, pero desea tranquilizar al entrevistado que su tiempo fue bien
gastado y muy til para el proyecto.
Inicio Los analistas de sistemas pueden pensar, ingenuamente, que la
realizacin de una entrevista es tan fcil como hablar con un amigo.
Lamentablemente, esto casi nunca es cierto. A menudo, los entrevistados no
puedan o no estn dispuestos a entregar la informacin que se necesita en una
ordenada y organizada. En algunos casos, es posible que no quieran compartir lo
que saben. Los analistas deben afinar sus habilidades interpersonales para mejorar
su inter- xito de audiencia. (Ver sugerencia prctica 3-1).
Prctico 3-1 D esarrollo I NTERPERSONAL S mata

TIP
Yonterpersonal habilidades son Puntos clave al altavoz (por ejemplo, "Quiero

aquellas que le permiten desarrollar una relacin con los asegurarme de que entiendo. Las cuestiones clave son
dems, y son muy importantes para la entrevista. Le "). Este demonio demuestra que considere la
ayudan a comunicar con los dems de manera efectiva. informacin importante- y tambin te obliga a prestar
Algunas personas desarrollan buenas habilidades atencin. ( No se puede repetir lo que no or).
interpersonales a una edad temprana; ellos simplemente Ser sucinto. Cuando usted habla, ser sucinto. El
parecen saber cmo comunicarse e interactuar con otros. objetivo de la entrevista (y en mucho de la vida) es
Otras personas son menos "suerte" y la necesidad de para aprender, no para impresionar. Cuanto ms
trabajar arduamente para desarrollar sus habilidades. hablas, menos tiempo le da a los dems.
Habilidades interpersonales, como la mayora de Ser honesto. Conteste todas las preguntas con
las habilidades pueden ser aprendidas. veracidad, y si usted no sabe la respuesta, dgalo .
Aqu estn algunos consejos: Observe el lenguaje corporal (el suyo y el suyo). La
forma en que una persona se sienta o soportes
No se preocupe y sea feliz. La gente feliz irradia transmite mucha informacin. En general, una
confianza y proyectar sus sentimientos sobre otros. persona que est interesada en lo que usted diga- ing
Intente inter- ver a alguien mientras sonre y luego se sienta o se inclina hacia adelante, hace contacto con
entrevistar a alguien mientras fruncir el ceo y ver qu los ojos, y a menudo afecta a su cara. Una persona
pasa! inclina lejos de usted o con un brazo sobre el respaldo
Preste atencin. Preste atencin a lo que dice la otra de una silla es terested disin-. Los brazos cruzados
persona (que es ms difcil de lo que usted podra indican una actitud defensiva o de incertidumbre,
pensar). Ver cuntas veces se coge con tu mente en mientras que "el tringulo" (sentado con las manos
algo distinto de la conversacin en la mano. elevadas en la parte frontal del cuerpo con los dedos
Resumir los puntos clave. Al final de cada tema tocando) indica un sentimiento de superioridad.
principal o la idea de que alguien explica, debe repetir
el
Despus de la entrevista el seguimiento despus de la entrevista, el analista

debe preparar una entrevista informe que describe la informacin de la entrevista
(Figura 3-7). El informe contiene notas de entrevistas, informacin que se
ha recopilado durante el transcurso de la entrevista y se resumen en un formato
til. En general, la entrevista informe debera ser escrito dentro de 48 horas
despus de la entrevista, porque cuanto ms se espere, ms probabilidades existen
de que se olvide la informacin.
Conceptos 3-C L A R INTERVIEWEE ELUCTANT

En accin
Early en mi carrera en consultora fui Proyecto y nuestro intento para documentar este
sistema fue enviado a la organizacin de un cliente con el objetivo de la entrevista- Abandonados. Roberta Roth
Ing la nica persona de la Organizacin que supo
El sistema funcionaba, cuentas por cobrar y el desarrollo Q UE STI O NS :
Documentacin para ese sistema (inexistente en el momento). 1. Por qu se supone que el entrevistado era
tan unco- El entrevistado fue puntual, educado y me dijo Operativa?
Absolutamente nada de valor sobre las cuentas recep- 2. Puedes pensar en alguna forma de evitar esto no
fuera capaz, a pesar de mis mejores esfuerzos durante varios inter- Venir?
Ver sesiones. Finalmente, mi jefe me llam off
Notas de entrevistas Aprobado por: Linda Estey
Entrevistado: Linda Estey, Director

de Recursos Humanos el
entrevistador: Barbara Wixom los
propsitos de la entrevista:
Entender los informes producidos por los recursos humanos del sistema actual.
Determinar los requisitos de informacin para el futuro sistema.
Resumen de la entrevista:
Los informes de muestra de todos los informes de la FC actual se adjuntan al presente informe. La
informacin que no se utiliza y de falta de informacin se sealan en los informes.
Dos de los mayores problemas con el sistema actual son:
1. Los datos son demasiado antiguos. (El departamento de RR.HH., las necesidades de
informacin dentro de los 2 das de fin de mes; en la actualidad, la informacin es
proporcionada para ellos despus de 3 semanas de retraso).
2. Los datos son de mala calidad. (a menudo, los informes deben conciliarse con la base de
datos departamental de HR).
Los datos ms comunes de errores encontrados en el sistema actual incluyen informacin sobre
el nivel de empleo incorrecto y a la falta de informacin salarial.
Abrir elementos:
Obtener lista de empleados actual informe de Mara Skudrna (extensin 4355).
Verifique los clculos utilizados para determinar el tiempo de vacaciones con Mara Skudrna.
Figura 3-7 Programar entrevista con Jim Wack (extensin 2337) con respecto a las razones de los problemas de
Informe de la entrevista calidad de los datos.
Notas detalladas: vase la transcripcin adjunta.
A menudo, la entrevista informe

es enviado al entrevistado con una peticin de lectura e informar
al analista de aclaraciones o actualizaciones. Asegrese de
que el entrevistado est con la conviccin de que usted quiere
realmente sus correcciones al informe. Generalmente, hay pocos cambios, pero la
necesidad de cualquier cambio significativo que sugiere que una segunda entrevista
ser necesaria. Nunca entregue informacin de alguien sin autorizacin previa.
Joint Application Development (JAD)

Joint Application Development ( JAD o como es ms conocido) es
una recopilacin de informacin tcnica que permite que el equipo del proyecto,
los usuarios y la administracin para que trabajen juntos para identificar los
requisitos del sistema. IBM desarroll el JAD tech- nique en los 1970s, y es a menudo
el mtodo ms til para recopilar informacin de los usuarios.7 Capers Jones afirma
que JAD puede reducir el alcance de arrastre en un 50%, y evita que los requisitos
para un sistema de ser demasiado especfico o demasiado vago, que puede
causar problemas durante las etapas posteriores del SDLC.8 JAD es un proceso
estructurado en el cual 10 de 20 usuarios se renen bajo la direccin de
un facilitador experto en tcnicas de JAD. El mediador es una
persona que establece la agenda de la reunin y gua la discusin, pero no
participar en la discusin, como participante. l o ella no proporciona ideas u
opiniones sobre los temas en discusin y permanece
7 Ms informacin sobre JAD puede encontrarse en J. D. madera y plata, el desarrollo de aplicaciones

conjuntas, Nueva York: John Wiley & Sons, 1989; y Alan Cline, "Desarrollo de Aplicaciones conjuntas
para obtener los requisitos de recogida y gestin", http://www.carolla.com/wp-jad.htm.
8 VerKevin Strehlo, "ponerse al da con los Jones y el requisito de "Creep", InfoWorld, julio 29, 1996; y
Kevin Strehlo, "las cualidades de un cliente contento: Especificar el proyecto X", Infoworld, 11 Nov, 1996.
Neutral durante la sesin. El facilitador debe ser un experto en ambas tcnicas del
proceso de grupo y las tcnicas de anlisis y diseo de sistemas. Uno o
dos escribanos ayudar al facilitador por grabar notas, hacer copias, y as
sucesivamente. A menudo, los escribas se utilizan equipos y herramientas CASE
para grabar informacin como la sesin de JAD ganancias.
El JAD grupo se rene durante varias horas, varios das o varias semanas
hasta que todas las cuestiones se han debatido y se recopila la informacin
necesaria. La mayora de las sesiones de JAD tienen lugar en una sala
especialmente preparada, lejos de las oficinas de los participantes, de modo que
no se interrumpe. La sala de reuniones es normalmente dispuestos en forma de U,
de modo que todos los participantes puedan ver fcilmente unos de otros.
(Consulte la Figura 3-8.) en la parte delantera de la sala (la parte abierta de la
"U"), hay una pizarra, rotafolio y/o proyector de transparencias para su uso por el
facilitador, quien dirige el debate.
Uno de los problemas con JAD es que sufre de los problemas
tradicionales associ- ciada con grupos: a veces la gente se muestra
reacia a desafiar las opiniones de los dems
Pizarra Pantall
a
Hojas de
rotafolio.
Tarjetas de Proyector Impres

nombre es ora
Tarjetas de
nombre
Equipos
Figura 3-8
Sala de reuniones conjuntas de desarrollo de aplicaciones
YSUR 3-2 I PRACTICE NTERVIEW
TURN
Yonterviewing no es tan simple como primera QUESTIONS:

Aparece. Seleccione dos personas de clase para ir a la parte delantera 1. Describir el lenguaje corporal de la
pareja. Entrevista de la habitacin para demostrar una entrevista. (Esto tambin puede 2. Qu tipo de
entrevista fue realizada?
Puede hacerse en grupos.) contar con una persona que sea el entrevistador, 3. Qu tipo de preguntas se hicieron?
Y la otra el entrevistado. El entrevistador debe 4. Lo que se hizo bien? Cmo podra ser la entrevista
se realizara una entrevista de 5 minutos sobre el curso escolar Mejorar?
Sistema de registro. Recopilar informacin sobre el
sistema existente y cmo el sistema puede mejorarse. Si
hay tiempo, repita con otra pareja.
(particularmente su jefe), algunas personas suelen dominar la discusin, y no cada

uno participa. En un grupo de 15 miembros, por ejemplo, si todo el mundo
participa igualmente, cada persona puede hablar durante slo 4 minutos cada hora
y debe escuchar para los restantes 56 minutos no es una forma muy eficiente para
recopilar informacin.
JAD electrnico, o e-JAD, intenta superar estos problemas mediante el uso de
groupware. En un e-JAD Sala de reunin, cada participante utiliza un software
especial en un ordenador conectado a la red para enviar annimamente
ideas, ver todas las ideas generadas por el grupo, y la velocidad y el rango de ideas
a travs de la votacin. El facilitador utiliza las herramientas electrnicas del
sistema e-JAD para guiar el proceso de grupo, manteniendo el anonimato y
permite al grupo centrarse en cada idea de los mritos y no en el poder o rango de
la persona que aport la idea. De esta manera, todos los participantes pueden
contribuir, al mismo tiempo, sin temor a represalias de las personas con opiniones
divergentes. La investigacin inicial sugiere que e-JAD puede reducir el tiempo
necesario para ejecutar sesiones JAD en un 50%-80%9 .
Seleccin de Participantes Seleccin de participantes JAD se realiza de la misma
forma bsica como la seleccin de participantes en la entrevista. Los participantes
son seleccionados sobre la base de informacin que pueden contribuir a
proporcionar una amplia gama de niveles de la organizacin, y para fomentar el
apoyo poltico para el nuevo sistema. La necesidad de que todos los participantes
JAD para estar lejos de sus oficinas al mismo tiempo puede ser un gran problema.
La oficina puede necesitar ser cerrada o ejecutarse con una mnima dotacin de
personal hasta las sesiones de JAD estn completos. Idealmente, los participantes
que son liberados de funciones ordinarias a asistir a las sesiones de JAD debera
ser la mejor gente en esa unidad de negocio. Sin embargo, sin un fuerte apoyo a la
gestin de sesiones JAD puede fallar, porque aquellos seleccionados para asistir al
perodo de sesiones JAD son personas que tienen menos probabilidades de ser
perdida (es decir, menos gente competente). El facilitador debe ser alguien que es
un experto en JAD o e-techniques JAD e, idealmente, de alguien que tiene
experiencia con el negocio bajo discusin. En muchos casos, el facilitador JAD es
un consultor externo a la organizacin, porque la organizacin no puede tener un
da a da la necesidad de JAD o e-JAD
La experiencia. Desarrollo y mantenimiento de esta experiencia en casa puede ser
caro.
Disear la sesin de JAD JAD sesiones pueden ejecutarse desde tan poco como la
mitad de un da para sev- eral semanas, dependiendo del tamao y el alcance del
proyecto. En nuestra experiencia, la mayora de las sesiones de JAD tienden a durar de 5
a 10 das repartidos a lo largo de un perodo de 3 semanas. La mayora de e-JAD
9 Paraobtener ms informacin acerca de e-JAD, vase A. R. Dennis, G. S. Hayes, y R. M. Daniels,
"Modelado de procesos de negocios con Groupware", Oficial de Sistemas de Gestin de la informacin, 1999,
15(4): 115-142.
Las reuniones suelen durar de 1 a 4 das en un perodo de 1 semana. JAD y e-

sesiones JAD usu- aliado avanzar ms all de la recopilacin de informacin para
elaborar anlisis entregar- ables. Por ejemplo, los usuarios y los analistas
colectivamente pueden crear casos de uso, modelos de proceso, o la definicin de
requisitos.
Como con entrevistas, JAD xito depende de un minucioso plan. Las
sesiones de JAD generalmente estn diseados y estructurados siguiendo los
mismos principios que las entrevistas. La mayora de las sesiones de JAD estn
diseados para recopilar informacin especfica de los usuarios, y esto requiere el
desarrollo de un conjunto de preguntas antes de la reunin. Una diferencia entre
JAD y entrevistas es que todas estn estructuradas las sesiones JAD-deben ser
cuidadosamente planificada. En general, las preguntas cerradas son
raramente utilizados, porque no suscit el debate abierto y franco que es tpico
de JAD. En nuestra experiencia, es mejor proceder de arriba abajo en sesiones
JAD al reunir informacin. Normalmente, 30 minutos asignados a cada tema
aparte y descansos programados durante todo el da porque los participantes
cansarse fcilmente.
Preparacin para la sesin de JAD como con entrevistas, es importante preparar a
los analistas y a los participantes para la sesin de JAD.
Porque las sesiones pueden ir ms all de la profundidad de una entrevista
tpica y generalmente se llevan a cabo fuera de 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 de JAD, por ejemplo,
desarrollar un entendimiento del sistema actual y, a continuacin, los participantes
pueden traer manuales de procedimiento y documentos con ellos. Si el objetivo es
identificar las mejoras para un sistema, entonces pueden pensar en cmo se podran
mejorar el sistema antes de la sesin de JAD.
La realizacin de la sesin ms JAD JAD sesiones tratan de seguir una agenda
formal, y la mayora tienen razn formal de reglas que definen el comportamiento
apropiado. Reglas de juego comunes incluyen el calendario siguiente, respetando
las opiniones de otros, aceptando dis- acuerdo y garantiza que slo una persona
habla a la vez.
El papel del facilitador JAD puede ser desafiante. Muchos de los
participantes proceden a la sesin de JAD con fuertes sentimientos acerca del
sistema que est siendo discutido. La canalizacin de estos sentimientos, de modo
que la sesin avanza en una direccin positiva y recibiendo a los participantes a
reconocer y aceptar, pero no necesariamente de acuerdo en opiniones y situaciones
diferentes de sus propios sistemas requiere considerable experiencia en el anlisis
y el diseo, JAD, y las habilidades interpersonales. Algunos analistas de sistemas
intentan facil- itate sesiones JAD sin ser entrenados en tcnicas de JAD, y la
mayora de los aprendices con un experto facilitador JAD antes de intentar
conducir su primer perodo de sesiones.
El JAD facilitador realiza tres funciones clave. En primer lugar, l o ella
se asegura de que el Grupo se adhiere al programa. La nica razn para desviarse de
la agenda es cuando resulta claro para el facilitador, lder de proyecto, y patrocinador
del proyecto que el JAD ses- sin ha producido algunas informaciones nuevas que es
inesperado y requiere el JAD ses- sion (y quizs el proyecto) para moverse en una
nueva direccin. Cuando los participantes intentan desviar la discusin fuera de la
agenda, el facilitador debe ser firme, pero educado, para dirigir la discusin hacia el
programa y obtener el grupo de vuelta en la pista.
Segundo, el facilitador debe ayudar al Grupo comprender los trminos tcnicos
y jerga que rodean el proceso de creacin del sistema y ayudar a los participantes a
comprender las tcnicas de anlisis utilizadas. Los participantes son expertos en su
rea de negocio, pero probablemente no son expertos en anlisis de sistemas. El
facilitador debe, por tanto, minimizar el aprendizaje necesario y ensear a los
participantes a proporcionar eficazmente el derecho de informacin.
En tercer lugar, el facilitador registra la entrada del grupo en un rea de
visualizacin pblica, lo cual puede ser una pizarra, papelgrafo o pantalla de ordenador.
l o ella estructuras la informacin
Que el grupo proporciona y ayuda al grupo a reconocer cuestiones fundamentales

e importantes soluciones. Bajo ninguna circunstancia debe el facilitador insertar
sus opiniones en el debate. El facilitador debe permanecer neutral en todo
momento y simplemente ayudar al grupo a travs del proceso. En el momento en
que el facilitador ofrece una opinin sobre un tema, el grupo ya no lo ve a l o a
ella como una parte neutral, sino como alguien que podra estar
intentando influenciar el grupo en alguna solucin predeterminada.
Sin embargo, esto no significa que el facilitador no debe tratar de ayudar al grupo
a resolver problemas. Por ejemplo, si dos elementos parecen ser los mismos para el
facilitador, no debera decir, "Creo que estos pueden ser similares." En su lugar, el
facilitador debe preguntar, "Estos son similares?" Si el Grupo decide que lo son, el
facilitador puede combinarlos y avanzar. No obstante, si el Grupo decide que no son
similar (a pesar de lo que el facilitador cree), el facilitador debe aceptar la decisin y
seguir adelante. El grupo siempre tiene razn, y el facilitador no tiene ninguna
opinin.
Es comn que el JAD a los participantes a hacer uso de
una serie de herramientas durante la sesin de JAD para definir
plenamente el nuevo sistema. Se pueden crear casos de uso para
describir cmo los usuarios van a interactuar con el nuevo sistema. Se pueden crear
prototipos para comprender ms cabalmente la interfaz de
usuario o mediante el sistema de navegacin. Modelos de proceso puede
ser construido para comprender el software que ser desarrollado, mientras
que un modelo de datos puede ser usado para describir los datos que ser capturado y
mantenido. El facilitador y los analistas en el equipo de proyecto debe usar cada
herramienta a su disposicin para ayudar a los participantes a aclarar y definir sus
necesidades para el nuevo sistema.
Post-JAD seguimiento como con entrevistas, un JAD informe posterior al

perodo de sesiones se prepar y distribuy entre los asistentes a la sesin. El
informe posterior al perodo de sesiones es esencialmente el mismo que el informe
de la entrevista en la figura 3-7. Desde las sesiones de JAD son ms largos y
proporcionar ms informacin, normalmente tarda una semana o dos despus de la
sesin de JAD antes de que el informe est completo.
Cuestionarios
Un cuestionario es un conjunto de preguntas escritas para la obtencin de
informacin de los indi- viduals. Los cuestionarios se utilizan frecuentemente
cuando hay un gran nmero de personas de las cuales la informacin y opiniones
son necesarias. En nuestra experiencia, los cuestionarios se utilizan comnmente
para sistemas destinados para uso fuera de la organizacin (por ejemplo, clientes o
proveedores) o para sistemas con usuarios empresariales repartidos por muchos
lugares geo- grfica. La mayora de la gente piensa automticamente de papel
cuando piensan de cuestionarios, pero hoy ms cuestionarios son distribuidos en
forma electrnica, ya sea a travs del correo electrnico o en el Web. Distribucin
electrnica puede ahorrar una cantidad significativa de dinero, en comparacin
con la distribucin de cuestionarios en papel.
YSUR PRACTICE 3-3 JAD
TURN
Ohvosotros rganize en grupos de asignacin, hacer un sndwich, pago de facturas, la

obtencin de cuatro a siete personas, y elegir uno en cada grupo de clase). Cmo fue la sesin de JAD ir? Sobre
la base de su expe- a ser el JAD facilitador. Utilizando una pizarra, blanco- riencia, cules son los pros y los
contras del uso de JAD en un tablero o papelgrafo, recopilar informacin acerca de cmo la organizacin real?
Grupo realiza algn proceso (por ejemplo, trabajando en una clase
Prctico A dministracin de 3-2 P SESSIONS ROBLEMS EN JAD

TIP
He ejecutado ms de un centenar de JAD Persona trae a colacin la cuestin de nuevo,

interrumpirlos, sesiones y han aprendido varias "facilitador estndar Camine hacia el papel y preguntarles qu
agregar. Si trucos." Aqu estn algunos problemas comunes y algunas maneras Mencionar algo que ya estn en la
lista, rpidamente se puede tratar con ellos. Interrumpir, sealan que es all y preguntar qu otro
tipo de informacin que desea agregar. No dejes que repita la misma
La reduccin de la dominacin. El facilitador debe asegurar que Punto, pero escribir ninguna informacin nueva.
Nadie domina la discusin en grupo. El acuerdo de violentos. Algunos de los peores desacuerdos nica manera de
tratar con alguien que domina es el jefe Ocurren cuando los participantes realmente de
acuerdo sobre los temas pero. Durante un descanso, acercarse a la persona, darle las gracias No se dan cuenta
de que estn de acuerdo porque estn usando el dif- o a ella por sus acertados comentarios y pedirles que
Trminos tores. Un ejemplo es discutir si un vaso es
ayudarle a asegurarse de que otros tambin participan. Medio lleno o medio vaco; estn de acuerdo sobre los
hechos, pero no
Noncontributors alentadores. Sacando las personas De acuerdo a las palabras. En este caso, el facilitador
tiene que que han participado muy poco es desafiante Traducir los trminos en diferentes palabras y encontrar
comunes porque desea ponerlos en la conversacin El suelo de manera que las partes reconocen que
realmente de acuerdo. De manera que se contribuya de nuevo. El mejor enfoque es conflicto an no resuelto. En
algunos casos, los participantes no preguntar una cuestin fctica directa que estn determinados de acuerdo y no
puedo entender cmo determinar qu alter- pueden responder. Y ayuda a hacer la pregunta con Los
nativos son mejores. Puede ayudar a estructurar el problema. Algunas repeticiones para darles tiempo a pensar. Por
ejemplo Preguntar por los criterios por los que el grupo
identifique un buen "Pat, s que has trabajado el envo de pedidos de un largo La alternativa (por ejemplo,
"Supongamos que esta idea realmente mejorar el tiempo. Seguramente has estado en Shipping Departa-
Servicio de atencin al cliente. Cmo reconocer el mejora miento ms que nadie. Podra ayudarnos
Servicio al cliente?"). A continuacin, una vez que tenga una lista de crite- entender exactamente qu sucede cuando una
orden es Ria, pregunte al grupo a evaluar las alternativas con
ellos. recibido el envo?". un verdadero conflicto. A veces, a pesar de todo intento,
partic-
Discusiones paralelas. A veces, los participantes realizan Ipants simplemente no pueden ponerse de acuerdo
sobre una cuestin. La solucin est a lado de conversaciones y dejar de prestar atencin a la Aplazar la
discusin y avanzar. El documento del grupo. La solucin ms sencilla es simplemente caminar cerca de
Asunto como una "cuestin abierta" y en la lista de forma destacada en el pueblo y seguir facilitando justo delante
de Flip chart. El grupo regresar a la cuestin de horas.
Pocas personas seguir una conversin lateral Ms tarde. A menudo, la cuestin se resolver por s
mismo y luego cuando ests a dos metros de ellos y toda la No han perdido tiempo en ella. Si el problema no se
puede agrupar la atencin en usted y ellos. Resuelto posteriormente, moverlo a la lista de
cuestiones a decidir
Programa tiovivo. El tiovivo ocurre Por el patrocinador del proyecto o algn otro ms
altos mem- cuando un miembro del grupo contina volviendo a la misma Ber de gestin.
Cuestin cada pocos minutos y no dejarlo ir. Una solucin Utilizar el humor. El humor es una de las herramientas ms
poderosas en una es dejar queLa seleccin
la persona tengadecinco
losminutos
participantes
a divagar como
sobrecon entrevistas
Facilitador tieney y,
sesiones de JAD,
por tanto, debe el
utilizarse con cautela. El sobre primer
el temapaso
mientrases usted
seleccionar los individuos
anote cuidadosamente cada a quienes
El humorel escuestionario
siempre mejor ser
JAD en contexto; nunca contar chistes,Sin
enviado. peroembargo,
el punto no
en unesrotafolio o un para
habitual archivoseleccionar
de computadora.
cadaEstepersona
rotafolio oque
podra proporcionar informacin Aproveche
til. Ella enfoque
oportunidad para encontrar
habitual consisteelenhumor en la
seleccionar
situacin.
una muestra o subconjunto de personas que son representativas de la totalidad del
Archivo se anuncie visiblemente en la pared. Cuando el
grupo. Directrices de muestreoAlansonDennis
discutidos en la mayora de las estadsticas de
libros, y la mayora de las escuelas de negocios incluyen cursos que cubren el
tema, por lo que no vamos a discutir aqu. El punto importante en la seleccin de
una muestra, sin embargo, para darse cuenta de que no todos los que recibe
realmente completar un cuestionario. En promedio, slo el 30%-50% de papel y
los cuestionarios por correo electrnico son devueltos. Las tasas de respuesta a los
cuestionarios basados en la Web tienden a ser considerablemente inferior (a
menudo, slo el 5% - 30%).
Comenzar con preguntas interesantes y sin amenazas.

Agrupar elementos en secciones lgicamente coherentes.
No coloque elementos importantes al final del cuestionario.
No amontonar una pgina con demasiados elementos.
Evite las abreviaturas.
Evitar prejuicios o sugerentes elementos o trminos.
Varias preguntas para evitar confusiones.
Pruebe el cuestionario para identificar preguntas confusas.
Figura 3-9 Proporcionar anonimato a los entrevistados.
Un buen diseo del cuestionario
Disear el cuestionario desarrollar buenas preguntas es crtico para los cuestionarios

porque la informacin sobre un cuestionario no aclararse inmediatamente con un con-
fundido demandado. Preguntas sobre los cuestionarios deben ser muy claramente por
escrito y debe dejar poco espacio para el malentendido; por lo tanto, las preguntas
cerradas tienden a ser ms comnmente utilizados. Las preguntas deben habilitar el
analista para separar claramente los hechos de las opiniones. Dictamen las preguntas
suelen pedir al demandado en qu medida est de acuerdo o en desacuerdo (por
ejemplo, "son problemas de red comn?"), mientras que las cuestiones fcticas buscar
valores ms precisos (por ejemplo, "Con qu frecuencia ocurre un problema en la red:
una vez cada hora, una vez al da o una vez a la semana?"). Consulte la Figura 3-9 para
las directrices sobre el diseo del cuestionario.
Quizs el problema ms evidente pero que a veces se pasa por alto, es tener
un claro entendimiento de cmo la informacin obtenida de los cuestionarios
sern analizados y utilizados. Usted debe abordar esta cuestin antes de distribuir
el cuestionario, porque es demasiado tarde despus.
Las preguntas deben ser relativamente consistente en su estilo, de modo que
el demandado no tenga que leer las instrucciones para cada pregunta antes de
contestar. Es generalmente una buena prctica para agrupar preguntas
relacionadas juntos para hacerlos ms simples para contestar. Algunos expertos
sugieren que los cuestionarios deben comenzar con preguntas importantes para
los encuestados, por lo que el cuestionario inmediatamente agarra su inters y
los induce a responder. Quiz el paso ms importante es tener sev- eral colegas a
revisar el cuestionario y, a continuacin, pruebe con
algunas personas provenientes de los grupos a los cuales se enviar.
Es sorprendente cmo a menudo parecen- ingly preguntas simples pueden ser
malinterpretado.
Administrar el cuestionario la cuestin clave en la administracin del cuestionario
es conseguir que los participantes completen el cuestionario y enviarlo de vuelta.
Docenas de mercado- ing investigacin libros han sido escritos sobre maneras de
mejorar las tasas de respuesta. Com- mnicamente utiliza tcnicas incluyen
explicando claramente por qu se est llevando a cabo el cuestionario y la razn por
la que el demandado ha sido seleccionado; indicando la fecha en la que el
cuestionario se va a devolver; ofrecer un incentivo para completar el cuestionario
(por ejemplo, una pluma libre); y ofreciendo a suministrar un resumen de las
respuestas al cuestionario. Los analistas de sistemas tienen tcnicas adicionales para
mejorar las tasas de respuestas dentro de la organizacin como, por ejemplo,
entregando personalmente el cuestionario y contacto personal- llos que no han
regresado despus de una semana o dos, as como solicitar los encuestados"
supervisores para administrar los cuestionarios en una reunin del grupo.
Cuestionario de seguimiento es til para procesar los cuestionarios devueltos y
desarrollar un cuestionario cuestionario informe poco despus de la fecha lmite.
Esto asegura que el proceso de anlisis procede en forma oportuna y que los
encuestados que solicitaron recibir copias de los resultados a la mayor brevedad
posible.
YSUR 3-4 Q PRACTICE UESTIONNAIRE
TURN
Ohvosotros rganize en pequeos Pasar el cuestionario en relacin con el creador cuando

es grupos. Pida a cada persona desarrollar una breve pregunta- Completado.
Naire para recopilar informacin acerca de la frecuencia en
Que los miembros del grupo realizar algn proceso (p. ej. QUESTIONS:
Trabajar en una asignacin de clase, haciendo un sandwich, 1. Cmo el cuestionario completado difieren de
pagar las cuentas, llegar a clase), cunto tardan, El que has creado?
Cmo se sienten sobre el proceso y oportunidades para 2. Cules son los puntos fuertes de cada cuestionario?
La mejora del proceso. 3. Cmo analizar los resultados de la encuesta si
tuvieras
Una vez que todos hayan terminado su o Recibi 50 respuestas?
Su cuestionario, pida a cada miembro para pasarlo a la derecha 4. Qu te gustara cambiar sobre el cuestionario y, a
continuacin, completar su cuestionario del vecino. Usted desarrolla?
Anlisis de documentos
Los equipos de proyecto suelen utilizar el documento anlisis para entender el
sistema. En circunstancias ideales, el equipo del proyecto que desarroll el sistema
existente se ha producido la documentacin, que luego fue actualizado por todos
los proyectos posteriores. En este caso, el equipo de proyecto puede comenzar
revisando la documentacin y examinar el sistema en s.
Lamentablemente, la mayora de los sistemas no estn bien
documentadas, porque fallan los equipos de proyecto para documentar sus proyectos
a lo largo del camino, y cuando los proyectos son ms, no hay tiempo para
volver y documento. Por lo tanto, no puede haber mucha documentacin tcnica
sobre el sistema actual disponible, o no puede contener actualizado informacin
sobre los ltimos cambios en el sistema. Sin embargo, hay muchos documentos tiles
que existen en la organizacin: papel informes, memorandos, manuales de usuario,
manuales de capacitacin, organigramas y formas. Los informes de problemas
presentados por los usuarios del sistema pueden ser otra fuente rica de informacin
acerca de problemas con el sistema existente.
Pero estos documentos (formularios, informes, manuales de polticas,
organigramas) slo cuentan parte de la historia. Ellos representan el sistema
formal que utiliza la organizacin. Muy a menudo, el "real", o sistema
informal difiere de la formal, y estas diferencias, especialmente los
grandes, da fuertes indicios de lo que necesita ser cambiado. Por ejemplo,
formularios o informes que no se usan nunca debe ser probable- inated elim.
Asimismo, cajas o preguntas en formas que nunca se completan (o son utilizados
para otros fines) deben ser repensadas. Consulte la Figura 3-10 para ver un
ejemplo de cmo un documento puede ser interpretado.
La ms poderosa indicacin de que el sistema necesita ser cambiado es
cuando los usuarios crean sus propios formularios o aadir informacin adicional
a los ya existentes. Estos cambios demuestran claramente la necesidad de mejoras
a los sistemas existentes. Por lo tanto, es til examinar ambos en blanco y los
formularios completados a identificar estas desviaciones. Del mismo modo,
cuando los usuarios tienen acceso a varios informes para satisfacer sus
necesidades de informacin, es una clara seal de que la nueva informacin o
nuevos formatos de informacin son necesarios.
Observacin
La observacin, el acto de ver los procesos que se realiza, es una potente
herramienta para comprender el sistema tal y como es. La observacin permite al
analista para ver la realidad de una situacin, en lugar de escuchar a los dems
describirlo en entrevistas o sesiones de JAD.
El cliente cometi un error. El personal tuvo que agregar

Esto debera ser etiquetada informacin adicional sobre el tipo
como nombre del de animal y el animal la fecha de
propietario para evitar nacimiento y sexo. Esta informacin
confusiones. debe ser aadido a la nueva forma
en la sistema.
Clnica veterinaria central

Tarjeta de informacin para el
paciente
Nombre: Buffy Pat Smith
Nombre de Buffy Collie 7/6/07 Mac

mascota: ho
Direccin: 100 Tribunal Central. Apartment

10
Toronto, Ontario K7L 3N6
416-
Nmero de telfono: 555-3400
Tiene seguro: S
Compaa de Pet's Mutual

seguros:
Nmero de KA-5493243
pliza:
El cliente no incluyen cdigo

de rea con el nmero de
telfono. Esto debera
Figura 3-10 hacerse ms claro.
Realizar un anlisis del documento
Varios estudios han demostrado que muchos administradores realmente no recuerdo

cmo funcionan y cmo se distribuyen su tiempo. (Rpido, cuntas horas le pasan la
semana pasada en cada uno de los cursos?) la observacin es una buena manera de
verificar la validez de la informacin obtenida de otras fuentes, tales como entrevistas
y cuestionarios.
En muchos sentidos, el analista se convierte en un antroplogo como l o ella
camina a travs de la Organizacin y observa el sistema empresarial como
funciona. El objetivo es mantener un perfil bajo, para no interrumpir los que
trabajan, y a no influir sobre aquellos que estn siendo observados. No obstante,
es importante comprender que lo que los analistas observan puede no ser la
normal da a da la rutina porque la gente tiende a ser extremadamente cuidadosos
en su comportamiento cuando estn siendo observados.10 Aunque
10 Estoilustra el efecto Hawthorne: un aumento en la productividad del trabajador producida por el estmulo
psicolgico de ser singularizado y hace sentir importantes. Vase R. H. Frank y J. D. Kaul, "La Hawthorne
experimentos: primera interpretacin estadstica", American Sociological Review, 1978, 43: 623-643.
Conceptos 3-D PUBLIX CREDIT CARD FORM

En accin
Unsupermercado Publix de mi barrio t Los valores. Sin embargo, los cajeros a veces cometemos
errores
Store, las cajeras siempre
provoca que la carga de cada escribir a manode
formulario la cargo
cantidad total dede crdito,
de tarjeta Y escribir la cantidad
incluso Barbara Wixom
errnea en los formularios, lo que
Problemas.
Aunque es impreso en el formulario. Por qu? Porque el "back
Personal de oficina" la gente que conciliar el efectivo en la caja Q UE STI O NS :
Cajones con la cantidad vendida al final de cada turno buscar 1. Qu hace el cargo en la tarjeta de crdito indica acerca
de forma difcil de leer la letra pequea en los formularios de tarjeta de crdito. El sistema existente?
Escrito en letras grandes hace que sea ms fcil para ellos para agregar el 2. Cmo puede hacer mejoras con un
nuevo sistema?
La prctica normal puede romper las reglas formales de organizacin, el

observador es poco probable que pueda ver esto. (Recordar cmo manej la ltima
vez que un coche de polica seguido usted?) As pues, lo que se ve no es lo que
realmente desea.
La observacin se utiliza a menudo para complementar informacin de
entrevista. La ubicacin de una persona y su mobiliario de oficina da pistas en
cuanto a su poder e influencia en la organizacin, y tales indicios pueden ser
utilizados para apoyar o refutar la informacin dada en una entrevista. Por
ejemplo, un analista podra ser escptico de alguien que afirma que el uso de la
actual sistema informtico ampliamente si el equipo nunca est encendida
mientras visitas el analista. En la mayora de los casos, la observacin apoyar la
informacin que los usuarios proporcionen en las entrevistas. Si no lo hace, es
una seal importante que se debe tener especial cuidado en analizar el sistema de
negocios.
La seleccin de las tcnicas adecuadas

Cada una de las tcnicas de obtencin de requisitos slo discutieron tiene
fortalezas y debilidades. Ninguna tcnica es siempre mejor que los dems y, en la
prctica, la mayora de los proyectos se benefician de una combinacin de
tcnicas. Por lo tanto, es importante para comprender las fortalezas y debilidades
de cada tcnica y cundo utilizar cada uno. (Consulte la Figura 3-11.) Una
cuestin que no se discute que los analistas de la experiencia. En general, el
anlisis de documentos y observacin requieren la menor cantidad de
entrenamiento, mientras que las sesiones de JAD son los ms difciles.
Tipo de informacin que la primera caracterstica es el tipo de informacin.

Algunos niques tech- son ms adecuados para el uso en diferentes etapas del
proceso de anlisis, si la comprensin del sistema, identificando las mejoras, o el
desarrollo de la
YSUR 3-5 S PRACTICE BSERVATION
TURN
VISIT la biblioteca de tu colegio o Al volver a clase, comparta sus observaciones

universidad y observe cmo el libro check-out proceso con otros. Usted puede notar que no todos los informes pres-
ocurre. En primer lugar, mirar los libros de control de varios estudiantes, ent la misma informacin. Por qu? Cmo
sera el infor- y luego comprobar uno mismo. Preparar un breve resumen- macin ser diferente si se hubiera utilizado
la entrevista o JAD Mara informe de sus observaciones. Tcnica?
Diseo de Anlisis de
Entrevistas aplicacin Cuestionarios document Observacin
conjunta os
Tipo de informacin Tal como est, Tal como est, Tal como est, mejoras Com Como-es
mejoras
A SER mejoras
A SER o-es
La profundidad de la Alta Alta Mediano Baja Baja
informacin
La amplitud de la Baja Mediano Alta Alta Baja
informacin
Integracin de la Baja Alta Baja Baja Baja
informacin
Participacin del usuario Mediano Alta Baja Baja Baja
Costo Mediano Baja-Media Baja Baja Baja-Media
Figura 3-11
Comparacin de las tcnicas de obtencin de requisitos
Sistema. Entrevistas y JAD son utilizados comnmente en las tres etapas. En

contraste, anlisis de documentos y observacin son generalmente ms tiles para
entender el sistema como est, aunque ocasionalmente proporcionan informacin
acerca de las mejoras. Los cuestionarios se utilizan a menudo para recopilar
informacin sobre el sistema, as como informacin general sobre las mejoras.
La profundidad de la informacin de la profundidad de la informacin se refiere

a cun rica y detallada la informacin es que la tcnica generalmente produce y el
grado en que el tcnico- nique es til en la obtencin no slo hechos y opiniones,
sino tambin la comprensin de por qu esos hechos y opiniones existentes.
Entrevistas y sesiones de JAD son muy tiles al proporcionar una buena
profundidad de rica y detallada informacin y ayudar a los analistas a entender las
razones detrs de ellos. En el otro extremo, el anlisis de documentos y
observacin son tiles para obtener hechos, pero poco ms. Los cuestionarios
pueden proporcionar una profundidad media de informacin, solicitando ambos
hechos y opiniones con poca comprensin de la razn.
La amplitud de la informacin la amplitud de informacin se refiere a la

variedad de informacin y fuentes de informacin que pueden ser fcilmente
recogidos por esta tcnica. Pregunta- naires anlisis de documentos y ambos son
fcilmente capaz de solicitar una amplia gama de informacin de un gran nmero
de fuentes de informacin. En cambio, las entrevistas y la observacin requieren el
analista para visitar a cada fuente de informacin individual y, por lo tanto, tardan
ms tiempo. Hay sesiones JAD en el Oriente porque muchas fuentes de infor-
macin se renen al mismo tiempo.
Integracin de la informacin Uno de los aspectos ms desafiantes de la

recopilacin de requisitos es la integracin de la informacin procedente de
diferentes fuentes. Sencillamente, dif erentes- la gente
puede proporcionar informacin contradictoria. La combinacin de esta
informacin y tratar de resolver las diferencias de opiniones o hechos es
generalmente muy tiempo consum- ing porque significa ponerse en contacto con
cada fuente de informacin a la vez, explicando la dis- crepancy e intentar
perfeccionar la informacin. En muchos casos, el individuo percibe errneamente
que el analista est desafiando su informacin, cuando en realidad el origen del
conflicto es otro usuario de la organizacin. Esto puede hacer que el usuario la
defensiva y hacen que sea difcil para resolver las diferencias.
Todas las tcnicas sufren problemas de integracin hasta cierto grado, pero
JAD sesiones estn diseadas para mejorar la integracin porque toda la
informacin est integrada cuando se recolecta, no despus. Si dos usuarios
proporcionan informacin contradictoria, el conflicto
Resulta obvia inmediatamente, al igual que el origen del conflicto. La inmediata

integracin de la informacin es el nico y ms importante beneficio de JAD que
distin- guishes desde otras tcnicas, y esta es la razn por la que la mayora de las
organizaciones usan JAD para importantes proyectos.
Participacin del usuario la participacin del usuario se refiere a la cantidad de

tiempo y energa a los usuarios previstos del nuevo sistema debe dedicarse al
proceso de anlisis. Se gener- aliado acord que, a medida que los usuarios se
involucren ms en el proceso de anlisis, la probabilidad de xito aumenta. Sin
embargo, la participacin de los usuarios puede tener un costo significativo, y no
todos los usuarios estn dispuestos a aportar su valioso tiempo y energa.
Cuestionarios, anlisis documento y lugar de observacin al menos carga de
usuarios, mientras que las sesiones de JAD requieren el mayor esfuerzo.
Coste El coste es siempre una consideracin importante. En general, los
cuestionarios, mayor , anlisis y observacin son tcnicas de bajo costo (aunque la
observacin puede ser bastante tiempo). El bajo coste no implica que
stas son ms o menos eficaz que las otras tcnicas. Consideramos que las entrevistas
y sesiones de JAD como mod- rebajado los costes. En general, las sesiones de JAD son
mucho ms caras, porque requieren muchos usuarios a ausentarse de sus oficinas
durante perodos significativos, y que a menudo implican consultores muy bien
pagados. Sin embargo, las sesiones de JAD reducir significativamente el tiempo
empleado en la integracin de informacin y, por lo tanto, cuesta menos en el largo
plazo.
Estrategias de anlisis de requisitos

La seccin anterior discutido cinco tcnicas esenciales que los analistas utilizarn
para interactuar con los interesados en el proyecto de desarrollo del sistema para
obtener y definir exigen- cias. Como hemos explicado anteriormente en este
captulo, el analista a menudo deben alentar a los interesados a pensar crticamente
sobre las necesidades para el nuevo sistema y descubrir las verdaderas necesidades
subyacentes. En esta seccin presentamos varias estrategias que el analista pueda
emplear con las partes interesadas para lograr este objetivo.
Anlisis del problema

El ms sencillo (y probablemente la ms comnmente usado) requisitos anlisis
estrategia es el anlisis de problemas. Anlisis del problema significa preguntando a
los usuarios y man- agers para identificar problemas con el sistema como est y
describir cmo resolverlos en la sistema. La mayora de los usuarios tienen una buena
idea de los cambios que les gustara ver, y la mayora ser bastante elocuente sobre
sugiriendo ellos. La mayora de los cambios tienden a resolver los problemas, en lugar
de capitalizar las oportunidades, pero esto es posible tambin. Mejorar- ciales del
anlisis de los problemas tienden a ser pequeos y graduales (por ejemplo, agregar un
campo para almacenar el nmero de telfono mvil del cliente; proporcionar un nuevo
informe que actualmente no existe). Este tipo de mejora a menudo es muy eficaz a la
hora de mejorar un sistema efi- la eficacia o la facilidad de uso. Sin embargo, a
menudo slo proporciona mejoras menores en valor empresarial: el nuevo sistema es
mejor que el antiguo, pero puede ser difcil de identificar
Importantes beneficios monetarios del nuevo sistema.
Anlisis de causa raz
Las ideas producidas por el anlisis de los problemas tienden a ser soluciones a
problemas. Todas las soluciones hacen suposiciones acerca de la naturaleza del
problema, hiptesis que pueden o no ser vlidos. En nuestra experiencia, los
usuarios (y la mayora de la gente en general) tienden a pasar rpidamente a
soluciones sin considerar plenamente la naturaleza del problema. A veces
Requirements Analysis Strategies 131
Las soluciones son apropiadas, pero muchas veces se dirigen a un sntoma del
problema, no el verdadero problema o causa raz misma.11
Por ejemplo, supongamos que los usuarios informan de que "el agotamiento
de las existencias de inventario ocurren frecuentemente." las roturas de stock de
inventario no son buenas y, por supuesto, una manera obvia para reducir su
aparicin es aumentar la cantidad de productos disponible en stock. Esta accin se
incurre en costos, sin embargo, por lo que vale la pena investigar la causa
subyacente de las frecuentes roturas de stocks en vez de saltar a una solucin
rpida. Las soluciones que proponen (usuarios o sistemas que los analistas
consideran) podrn dirigirse a cualquiera de los sntomas o causas, pero sin un
anlisis cuidadoso, es difcil decir cul. Descubrir ms tarde que acaba gastado
millones de dlares y no ha corregido el verdadero problema subyacente es una
sensacin horrible!
Anlisis de causa raz se centra en primer lugar los problemas en lugar de
soluciones. El analista comienza por tener los usuarios generan una lista de
problemas con el actual Sys- tem, prioriza los problemas en orden de importancia.
Comenzando por la ms importante, a los usuarios y/o analistas generar todas
las posibles causas para el problema. Como se muestra en la figura 3-12, el
problema de "demasiado frecuentes roturas de stocks" tiene varios
Frecuentes
roturas de
stocks de
inventario
Conteos inexactos Reordenar las

Orden del
en mano cantidades
proveedor lag
incorrectas
Retraso en la Retraso en la Punto de

aprobacin de grabacin el reordenaci
la orden del inventario n
proveedor vendido demasiad
o baja
Cantidad de
Retraso en Conteo manual
Pedido Econmico
identificar infrecuente la
(EOQ) muy baja.
mejor reconciliacin
proveedor
Retraso en el
Retraso en el
registro de los
envo de pedido
elementos
al proveedor
recibidos de
proveedores
Figura 3-12
Anlisis de la causa raz de los problemas de existencias de inventario
11 dos buenos libros que tratan los problemas en la bsqueda de las causas de los problemas son E. M.
Goldratt y
J. Cox, el objetivo, Croton-on-Hudson, NY: North River Press, 1986; y E. M. Goldratt, El Pajar Syn-
drome, Croton-on-Hudson, NY: North River Press, 1990.
Posibles causas (impreciso sobre recuentos de mano; Reordenar puntos

incorrectos; retraso en la colocacin de rdenes del proveedor). Cada posible
causa raz es investigado y otras causas son identificadas. Como muestra la figura
3-12, a veces es til para mostrar las posibles causas en una jerarqua de rbol. En
definitiva, el proceso de investigacin revela la verdadera causa raz o causas del
problema, permitiendo al equipo para disear el sistema para corregir el problema
con la solucin adecuada. El punto clave en el anlisis de causa raz es siempre el
reto obvio y cavar en el problema profundamente bastante que la verdadera causa
subyacente(s) es revelada.
Anlisis de la duracin
Duracin anlisis requiere un examen detallado de la cantidad de tiempo que tarda
en realizar cada proceso en el actual sistema como est. Los analistas
empiezan por co- rrespondientes determin la cantidad total de tiempo que se tarda,
en promedio, para realizar un conjunto de procesos de negocio para una entrada
tpica. Ellos entonces cada uno de los pasos individuales (o sub- procesos) en el
proceso de negocio. El tiempo para completar los pasos bsicos se sum y se
compara con el total de todo el proceso. Una diferencia significativa entre los dos
y, en nuestra experiencia, el tiempo total puede ser 10 o incluso
Conceptos 3-E SATISFACTORIO From e xistente

En accin
Few nichos ms estrellado spectacu- En muchos sentidos, el sitio es un excelente

ejemplo de cmo la mente durante la Web 1.0 que en el sector del PET. En 2000, justo sobre una falla de
implementacin web, pero no as por la caracterstica rpida de nueve meses, que Pets.com lograron elevar un
lanzamiento alucinantes, viendo lo que funciona, y arreglar las cosas rpidamente.
$82.5 millones de dlares en una oferta pblica inicial (OPI), air a $1.2 millones del Super Bowl ad Segn Rheingold,
"cuando desplegamos una nueva fea- protagonizada por su Ttere de calcetn mascota, financiacin de la tierra
Ture, sabemos que probablemente no va a acertar el
Amazon.com construir una red de almacenes cavernoso ... La primera vez". Dogster y empresas similares han
discov- y salir de la empresa sin hacer un centavo en beneficios. Ered que reexaminar continuamente datos
de usuario-feri- al que Pets.com volc y muri en noviembre de 2000, Tantly, la desalentadora eventos
proporciona importantes presagi decenas de dot-com desastres para seguir y chocaron Direccin de mejoras.
Rheingold dice, "En lugar de la puerta en lnea de pet empresas, aparentemente para siempre. Trabajando en
una caracterstica durante meses intentando conseguir perfecto,
As que cuando San Francisco diseador Web Ted Rhein- Vamos a trabajar en algo durante dos
semanas y luego gastar el oro co-fund Dogster.com en enero de 2004 como una especie Dos o tres das
escuchando a los usuarios y la afinacin." de la versin canina de Friendster, la noticia llam sonre
De los pocos que se molest con previo aviso. Cmo podra Dogster, Fuente: "El mejor amigo de Inicio? Fracaso", Tom
McNichol, busi-
Un sitio de mascotas remendados los fines de semana y lanz ness 2.0. San Francisco: Marzo de 2007, vol. 8, Iss. 2,
pg. 39-41.
Con un presupuesto exiguo, esperan tener xito donde esplndidamente
Pet financiado sitios haban quemado? El consenso sobre QUESTIONS:
Dogster fue unnime: fracasara. 1. Est usted de acuerdo con la opinin de Dogster, o
compa-
Y, efectivamente, se ha fallado. Ms y ms. Pero, por desgracia, Nies objetivo de "cero defectos" las
operaciones? Por qu o por qu cada golpe ha sido un impulso. Dogster ha descubierto No? Cules son las
consecuencias de este modelo de negocio tiene maneras de convertir sus errores en mejores caractersticas. Con
bastante Para los analistas de sistemas?
No hay ninguna promocin, Dogster mucho (y sitio hermana Catster.com) 2. Empresas como Dogster inicio no son el
nico com-
ha evolucionado hacia un premier pet lover's red social. Empresas que estn aplicando la estrategia
100 veces ms que la suma de las partes indica que esta parte del proceso es muy
necesitados de una revisin importante.
Por ejemplo, supongamos que los analistas estn trabajando en una hipoteca
de casa Sys- tem y descubrir que, en promedio, toma 30 das para que el
banco apruebe una mort-Gage. Ellos entonces mirar a cada uno de los pasos
bsicos del proceso (por ejemplo, entrada de datos, verificacin de crdito,
bsqueda de ttulo, evaluacin, etc.) y encontrar que la cantidad total de tiempo
que se gasta en realidad en cada hipoteca es de aproximadamente 8 horas. Esto es
un fuerte indicio de que todo el proceso es muy rotas, porque tarda 30 das para
realizar 1 da de trabajo.
Estos problemas probablemente ocurren
porque el proceso es muy fragmentada. Muchas personas diferentes
debe realizar diferentes actividades antes de que se complete el proceso. En
el ejemplo de la hipoteca, la aplicacin probablemente se sienta en las mesas de los
muchos pueblos durante largos perodos de tiempo antes de que se procese. Los
procesos en los cuales muchas personas diferentes trabajan en pequeas partes de
los insumos son los principales candidatos para la integracin de procesos o paral-
lelization. La integracin del proceso significa cambiar el proceso
fundamental para que menos personas trabajan en la entrada, que a menudo requiere
el cambio de los procesos y la capacitacin del personal para realizar una amplia
gama de funciones. Paralelizacin de procesos significa cambiar el proceso,
de manera que todos los pasos se realizan al mismo tiempo. Por ejemplo, en el
ejemplo para la solicitud de hipoteca, probablemente no hay razn por la que la
comprobacin de crdito no pueden realizarse al mismo tiempo que la evaluacin
y comprobacin de ttulo.
Costando basada en actividad

Costeo basado en actividad es un anlisis similar que examina el costo de cada
proceso o paso importante en un proceso de negocio ms que el tiempo. 12 Los
analistas identificar al los costos asociados con cada uno de los pasos o procesos
funcionales bsicas, identificar los procesos ms costosos, y centrar sus esfuerzos
de mejora en ellos.
Asignacin de costos es conceptualmente simple. Usted acaba de examinar el
costo directo de la mano de obra y los materiales para cada entrada. Los costos de
materiales son fcilmente asignados en un proceso de manufacturas, mientras que
los costes laborales son generalmente calculada sobre la base de la cantidad de
tiempo dedicado a la entrada y el costo por hora de los empleados. Sin
embargo, como recordarn desde un curso de contabilidad de gestin, existen
costos indirectos tales como alquiler, depreciacin, etc., y que tambin pueden ser
incluidos en los costos de las actividades.
Benchmarking informal
El Benchmarking se refiere a estudiar cmo otras organizaciones que llevan a cabo
un proceso de negocio con el fin de aprender cmo su organizacin puede hacer
algo mejor. Bench- marcado ayuda a la organizacin mediante la introduccin de
ideas que los empleados nunca han considerado, pero que tienen el potencial para
agregar valor.
Benchmarking informal es bastante comn para "orientado al cliente" de los
procesos de negocio (es decir, aquellos procesos que interactan con el
cliente). Con el benchmarking, informales a los gestores y analistas piensan acerca
de otras organizaciones, o visitarlos como clientes para ver cmo se realiza el
proceso de negocio. En muchos casos, las empresas estudiadas puede ser un lder
reconocido en la industria o simplemente una empresa vinculada. Por ejemplo,
supongamos que el equipo est desarrollando un sitio Web para un concesionario
de automviles. El
12 se han escrito muchos libros sobre el costeo basado en actividad . tiles

incluyen K. B. Burk y D. W. Webster, costando basada en actividad, Fairfax, VA: American Management
Systems, 1994; y D. T. Hicks, basada en actividad cuesta: Hacer que funcione para las Pequeas y Medianas
Empresas, Nueva York: John Wiley, 1998. Los dos libros por Eli Goldratt mencionados anteriormente (la
meta y el sndrome haystack) tambin ofrecen conocimientos nicos en el clculo de costos.
Conceptos 3-F A PROCESS EN Necesita DE IMPROVEMENT

En accin
Un grupo de ejecutivos de una fortuna grupo aturdido. El proceso de adquisicin se haba metido
hasta 500 empresa utiliz anlisis de duracin para discutir sus pro- enrevesado que tard 18 das, incontables horas
de trabajo- curement proceso. Utilizando una enorme pared de velcro y un trabajo y casi 22.000 dlares en tiempo de
la gente para obtener el puado de pancartas, un facilitador procedi a trazar el producto pedido, recibido, y en
marcha en el proceso de la compaa para la adquisicin de $50 en el software de escritorio del solicitante.
Actualizacin. Haber cuantificado el tiempo que se tard en completar
Cada paso, se asignan los costos sobre la base de los sueldos Fuente: "En buena medida", CIO Magazine, Marzo 1, 1999
De los empleados involucrados. Los 15 minutos de ejercicio la izquierda Por Debby Joven.
Patrocinador del proyecto, los gerentes claves, y los miembros clave del equipo
es probable que visite los sitios Web de los competidores, los de otros en la
industria del automvil (por ejemplo, fabricantes, proveedores de accesorios), y
las de otras industrias que han ganado premios por sus sitios Web.
Anlisis de Resultados
Resultados El anlisis se centra en la comprensin de los resultados
fundamentales que proporcionan valor aadido a sus clientes. Mientras que estos
resultados el sonido como a pesar de que debera ser obvio, a menudo no lo son.
Por ejemplo, supongamos que usted es una compaa de seguros y uno de sus
clientes acaba tuvo un accidente de coche. Cul es el resultado fundamental
desde la perspectiva del cliente? Tradicionalmente, las compaas de seguros han
contestado a esta pregunta asumiendo que el cliente desea recibir el pago del
seguro con rapidez. Para el cliente, sin embargo, el pago es slo un medio para el
verdadero resultado: un coche reparado. La compaa de seguros podran
beneficiarse al ampliar su visin del proceso de negocio ms all de sus lmites
tradicionales para incluir, no slo pagar por reparaciones, pero realizar las
reparaciones o contratacin con un rgano autorizado tienda a hacer de ellos.
Con este enfoque, los analistas de sistemas y administradores de alentar
al patrocinador del proyecto para fingir que son clientes y a pensar
cuidadosamente acerca de lo que la organizacin, sus productos y servicios
permiten a los clientes hacer-y lo que podra permitir que los clientes hagan.
Anlisis de la tecnologa
Muchos cambios importantes en la empresa durante los ltimos 10 aos han sido
habilitadas por las nuevas tecnologas. Anlisis de la tecnologa , por lo tanto,
empieza por tener los analistas y man- agers desarrollar una lista de tecnologas
interesantes e importantes. Luego el grupo sys- tematically identifica cmo todos
y cada tecnologa podra aplicarse a la business proceso y determina el modo en
que la empresa se beneficiara.
Por ejemplo, una tecnologa til puede ser la Internet. Un fabricante puede
desarrollar una aplicacin de extranet para sus proveedores. En lugar de pedir
piezas para sus productos, el fabricante pone su cronograma de produccin
disponibles electrnicamente a sus proveedores que entregan las piezas necesarias
de modo que lleguen a la planta en el momento justo. Esto ahorra costes
significativos, ya que elimina la necesidad de la gente para supervisar la
planificacin de la produccin y la emisin de rdenes de compra.
Conceptos 3-G "LIKE" YNUESTRA Local GOVERNMENT

En accin
Municipal, ciudad y condado gobernar- zens para ser parte de los servicios del gobierno, no slo
declaraciones estn seriamente afectados por la reciente crisis econmica el destinatario de los servicios del gobierno.
Los ciudadanos pueden presentar depresin y presin presupuestaria resultante. Menos problemas tales como
baches en las carreteras o los vehculos abandonados empleados significa que es ms difcil de prestar servicios en el
cuando lo ven y los servicios del gobierno puede reparar el mismo antiguo camino de los ciudadanos. Los gerentes de
pensamiento avanzado de ellos, mientras que en el campo. Los ciudadanos son parte de las entidades
gubernamentales reconocen que los medios sociales puedan procesar y obtener satisfaccin inmediata por ayudar a
ser la onda del futuro. Los medios sociales pueden permitir citi- resolver problemas.
YSUR 3-6 IBM CREDIT

TURN
IBM crdito era una propiedad era imposible localizar uno sin caminar fsicamente- filial de
mainframe de IBM responsable de la financiacin de ing a travs de los departamentos y atravesando los pilotes
computadoras vendidas por IBM. Mientras que algunos clientes han comprado de formularios en todo el escritorio.
Los mainframes simples o obtuvo financiacin de otros IBM examin el proceso de crdito y lo cambiaron para
fuentes, equipos de financiacin proporcion importantes operacio- Que cada solicitud de crdito estuvo conectado en un
sistema internacional de beneficio. De manera que cada departamento podra registrar
una aplicacin es cuando un representante de ventas de IBM hizo una venta, l El estado tan pronto como fue
completado y enviado a la siguiente
O ella podra llamar inmediatamente a IBM para obtener crdito de un departamento. De esta manera, los representantes de
ventas podra pedir presupuesto de financiamiento. La llamada fue recibida por un oficial de crdito de la oficina de crdito y aprender
rpidamente el estado de cada aplique registre la informacin en el formulario de solicitud. El catin. IBM utiliza algunos gestin
sofisticada ciencia forma sera enviado al departamento de crdito para comprobar la teora de colas para equilibrar las cargas de
trabajo de anlisis y personal el estado de crdito del cliente. Esta informacin sera a travs de los diferentes departamentos de forma
que no hay ninguna aplicacin registrada en el formulario, que luego fue enviado a la nego- estara sobrecargado. Tambin
introdujeron prcticas ness rendimiento departamento, que escribira un contrato normas para cada departamento (por ejemplo, la
decisin de precios (a veces reflejando los cambios solicitados por el cus- tena que estar terminado en el plazo de un da despus de
que ese departamento tomer). El formulario y el contrato sera entonces ir al recibir una solicitud).
Departamento de precios, que utilizan la informacin de crdito Sin embargo, tiempos de proceso empeoraron, a
pesar de establecer una tasa de inters y el registro en el formulario. El Cada departamento estaba alcanzando casi un
100 por ciento com- formulario de contrato y luego se envi al grupo clerical, Observancia en sus objetivos de
rendimiento. Tras algunos investiga- donde un administrador preparara una carta Cin, gerentes encontraron que
cuando las personas se llenaba , citando a la tasa de inters y enviar la carta y contrato
Convenientemente encontrado errores que obligaron a regresar la
va Federal Express para el cliente. Solicitud de crdito para el departamento anterior para
corregir el problema en IBM, el crdito fue uno de los ms importantes. Get- Eliminando de sus mediciones de
tiempo.
Ting tuvo un presupuesto de financiamiento desde cuatro a ocho
Das (seis das en promedio), dando tiempo al cliente a QUESTIONS:
Repensar el orden o buscar financiacin en otros lugares. Mientras las tcnicas que puede utilizar para identificar las
mejoras? Quote estaba siendo preparado, representantes de ventas elegira una tcnica y aplicarla a esta situacin- que
suelen llamar para averiguar donde la cita estaba en el proceso, qu mejoras se puede identificar?
A fin de que puedan comunicar al cliente cuando la espera.
Sin embargo, nadie en la IBM de Crdito podra contestar la pregunta, Fuente: reingeniera de la Corporacin, Nueva York:
Harper busi-
Los formularios de papel porque podra estar en cualquier departamento y ness, 1993, por M. J. Champy y martillo.
Eliminacin de actividad
Eliminacin de actividad es exactamente lo que suena. Los analistas y gestores
trabajan juntos para identificar cmo la organizacin podra eliminar todas y cada
una de las actividades del proceso comercial, cmo la funcin podra funcionar sin
ella, y qu efectos tienen probabilidades de ocurrir. Inicialmente, los directivos
son reacios a la conclusin de que los procesos pueden ser eliminados, pero esto
es un "encajar" el ejercicio en que se deben eliminar cada actividad. En algunos
casos los resultados son tonteras; no obstante, los participantes deben abordar
todas y cada una de las actividades del proceso comercial.
Por ejemplo, en el proceso de aprobacin de prstamos hipotecarios se
discuti anteriormente, los gerentes y analistas podra empezar por eliminar la
primera actividad, introduciendo los datos en el ordenador de la compaa
hipotecaria. Esto lleva a una de las dos posibilidades obvias: (1) Eliminar la
utilizacin de un sistema informtico o (2) hacer alguien hacer la entrada de datos
(por ejemplo, el cliente, a travs de la Web). Deberan eliminar la actividad
siguiente, la comprobacin de crdito. Tonto, verdad? Despus de todo,
asegurndose de que el solicitante tiene buen crdito es crtico en la concesin de
un prstamo, no es as? No realmente. La respuesta real depende de cuntas
veces la comprobacin de crdito identifica aplicaciones incorrectas. Si todos o
casi todos los solicitantes tienen un buen historial de crdito y rara vez son
rechazados por una verificacin de crdito, entonces el costo de la verificacin de
crdito pueden no valer el beneficio de unos pocos malos prstamos de Evita. Su
eliminacin puede resultar en costos ms bajos, incluso con el costo de los
prstamos incobrables, a menos que el nmero de solicitantes con mal crdito
aumenta considerablemente.
Comparacin de estrategias de anlisis

Cada uno de los anlisis de requerimientos estrategias discutidas aqu tiene su
propio propsito. No hay una tcnica es intrnsecamente mejor que las dems.
Recuerde que una organizacin probablemente tendrn una amplia gama de
proyectos en su cartera; la estrategia de anlisis de requisitos debe ser elegido
para adaptarse a la naturaleza del proyecto. Anlisis de problemas y anlisis de
causa raz tienden a ser ms til en situaciones con un enfoque estrecho donde las
ganancias de eficiencia son buscados. Anlisis de la duracin y el costeo basado
en actividad estrategias ayudan al equipo a encontrar la mayora de los "rotos" de
los procesos de negocio a fin de que los procesos pueden ser rediseado y
mejorado. Anlisis de resultados, anlisis de la tecnologa, evaluacin comparativa
informal y ayudar al equipo a pensar "fuera de la caja" y son muy tiles cuando el
equipo est intentando crear formas completamente nuevas de realizar los
procesos de negocio.
Aplicar los conceptos a sintonizar fuente

Una vez que el comit de aprobacin de origen Tune aprob el sistema de
solicitud y feasi- bilidad de anlisis, el equipo del proyecto comenz a realizar las
actividades de anlisis. Estos incluyen la recopilacin de requisitos por una variedad
de tcnicas y el anlisis de los requisitos que se haban reunido. Algunos de los
aspectos ms destacados de las actividades del equipo de proyecto se presentan a
continuacin.
Recabar y analizar requisitos
Jason cree que sera importante para comprender los actuales procesos de ventas
basada en Web y sistemas que ya existen en la organizacin, ya que tendra que
estar estrechamente integrado con el sistema de descarga de msica
digital. Dos tcnicas de recogida de requisitos result ser muy til para la
comprensin de la cur- alquiler de sistemas y procesos de anlisis de documentos
y entrevistas.
En primer lugar, el equipo de proyecto recogieron informes existentes (por
ejemplo, formas de venta, capturas de pantalla de las pantallas de ventas online) y
la documentacin del sistema (modelos de datos, proceso
Aplicar los conceptos a sintonizar fuente 137
Modelos) que arrojan luz sobre el sistema. Fueron capaces de reunir una buena
cantidad de informacin sobre los actuales procesos de pedido y sistemas de esta
manera. Cuando surgan preguntas cortas, se realizaron entrevistas con la persona
que le proporcion la documentacin, para su aclaracin.
A continuacin, Jason entrevist a los analistas senior de los actuales sistemas de
venta para obtener un mejor entendimiento de cmo estos sistemas trabaj. l les
pregunt si tenan alguna idea para el nuevo sistema, as como si existen problemas de
integracin que sera necesario abordar. Jason tambin entrevist a un contacto de la
ISP y la persona que mantena sintona actual de origen del sitio Web proporcionan
informacin acerca de la infraestructura de comunicaciones existente en sintona y sus
capacidades Web de origen.
Carly sugiri que el equipo del proyecto realizar varias sesiones JAD con
gerentes, analistas de marketing, conocedor de la Web y miembros del personal de
TI. Juntos, los grupos podran brainstorm las caractersticas deseadas en el sistema de
descarga de msica digital. Jason facilit tres sesiones JAD que se llev a cabo en el
transcurso de una semana. Jason's pasado facilitacin experiencia ayudaron las ocho
reuniones personales funcionar suavemente y permanezca en la va. Porque este
proyecto introduce un nuevo proceso de negocios, Jason utiliza tecnologa de anlisis
y sugiri varias importantes tecnologas Web que podran ser utilizados por el
sistema. El JAD sesin gener ideas sobre cmo sintonizar fuente podra aplicar cada
una de las tecnologas en el sistema de descarga de msica digital. Jason tuvo el
grupo categorizar las ideas en tres conjuntos: "definitivo" de ideas que tendran una
buena probabilidad de proporcionar valor empresarial, "posibles" ideas que podran
Agregar valor al negocio y "improbable" de ideas.
A continuacin, Jason aplica benchmarking informal mediante
la introduccin de los sitios Web de varias de las principales minoristas y
sealando las caractersticas que se ofrecen en lnea. l seleccion algunos sitios
sobre la base de su xito con las ventas por Internet, y otros sobre la base de su
similitud con la visin para afinar el nuevo sistema de origen. El grupo analiz las
caractersticas que son comunes a la mayora de los detallistas, versus funcin
exclusiva- alidad y crearon una lista de sugerencias de requisitos empresariales
para el equipo del proyecto.
Definicin de requisitos
A lo largo de todas estas actividades, el equipo del proyecto informacin
recopilada y trat de identificar los requisitos de negocio para el sistema de la
informacin. A medida que el proyecto avanzaba, las necesidades se agregan a la
definicin de requisitos y requisitos agrupados por tipo. Cuando surgieron dudas,
trabajaron con Carly y Jason para confirmar que los requisitos eran en su alcance.
Los requisitos que se cay- lado del alcance del sistema actual se escribe en un
documento separado que se guarda para su uso futuro.
Al final de la fase de anlisis, la definicin de requisitos se distribuy
a Carly, dos empleados de marketing que trabajen con el sistema de la nego- ness
lateral, y varios gerentes de tienda minorista. Este grupo se reuni durante dos das
de sesiones JAD para aclarar, completar y priorizar las necesidades y crear casos
de uso (captulo 4) para mostrar cmo sera el sistema utilizado.
El equipo del proyecto tambin dedic tiempo a la creacin de modelos de
proceso (captulo 5) y los modelos de datos (captulo 6) que describan los
procesos y datos en el futuro sistema. Los miembros de mercadeo y revisaron los
documentos durante las entrevistas con el equipo de proyecto. La figura 3-13
muestra una parte de la definicin de los requisitos finales.
Propuesta de sistema
Jason revis la definicin de requisitos y los otros resultados que el equipo del
proyecto creados durante la fase de anlisis. Dado Carly el deseo de tener el sistema
en
Requisitos funcionales:
1. Buscar y Navegar
1.1 El sistema permitir a los clientes explorar opciones de msica por categoras predefinidas.
1.2 El sistema permitir a los clientes opciones para buscar msica por ttulo, artista y gnero.
1.3 El sistema permitir que los clientes para escuchar una breve muestra de una seleccin de msica.
1.4 El sistema permitir al cliente agregar selecciones de msica a una lista de "favoritos".
2. Compra
2.1 El sistema permitir al cliente al crear una cuenta de cliente (si se desea) que almacenar los datos de los clientes y la
informacin de pago.
2.2 El sistema permitir al cliente especificar la eleccin de msica para descargar.
2.3 El sistema va a recopilar y verificar la informacin de pago. Una vez que el pago se ha verificado, la seleccin de msica
comenzar el proceso de descarga.
3. Promover
3.1 El sistema va a seguir la pista de los intereses del cliente sobre la base de muestras seleccionadas para escuchar y utilizar esta
informacin para promocionar la msica selecciones durante futuras visitas al sitio Web.
3.2 Departamento de Marketing puede crear promociones y ofertas especiales en el sitio Web.
3.3 Sobre la base de compras anteriores del cliente, msica opciones pueden ser dirigidas al cliente en futuras visitas al sitio
Web. (Los clientes que gustan de X tambin le gusta Y.
3.4 Sobre la base de los intereses de los clientes, los clientes pueden ser notificados de ofertas especiales en CDs que se pueden
adquirir en el sitio Web de origen Tune regulares o en un almacn de origen Tune.
requisitos no funcionales:
1. Funcionamiento
1.1 La base de datos de msica digital ser construido para facilitar las bsquedas por ttulo, artista y gnero.
1.2 El sistema se ejecuta en cualquier navegador Web y en los quioscos en la tienda.
1.3 En el caso de un fallo durante una descarga, el cliente ser capaz de reiniciar la descarga.
2. Rendimiento
2.1 Las velocidades de descarga sern supervisados y se mantiene a un nivel aceptable.
3. La seguridad
3.1 Informacin del cliente estar asegurada.
3.2 Informacin de pago ser encriptada y protegida.
4.
No culturales y polticas culturales especiales y requisitos polticos esperados.
Figura 3-13
Ajustar la definicin de los requisitos de origen
La produccin tan pronto como sea posible, Jason decidi timebox el proyecto.
Haba orig- originalmente decidi abordar el proyecto en tres versiones (desarrollo
iterativo, vase el captulo 2), y est convencido de que esta es una
buena manera de estructurar el proyecto. La primera versin, que estar operativo
a finales de la primavera, se aplicaran una capacidad de descarga de msica digital
bsico que permitir a los clientes descargar msica a un precio fijo por cada
descarga. La segunda versin, planeado para estar listo en verano, incorporara un
programa de suscripcin de clientes. El departamento de marketing an tiene que
determinar su programa preferente de suscripcin. Se est considerando una tarifa
baja, programa a ms largo plazo o una tarifa superior, programa de corto plazo.
Por el momento, el equipo del proyecto est listo para iniciar la versin 2, sin
embargo, los detalles deben ser clavado en el suelo. La tercera versin, que se
espera est listo a finales de verano, se aade la opcin de tarjeta de regalo, enti-
tling el titular de la tarjeta de regalo con un nmero fijo de descargas durante un
tiempo limitado.
140 Chapter 3 Requirements Determination Resumen 139
1. Tabla de contenido
2. Resumen Ejecutivo
un resumen de toda la informacin esencial de la propuesta, de modo que un ejecutivo ocupado
puede leerlo rpidamente y decidir qu partes del plan de Leer ms en profundidad.
3.
El sistema revisado de peticin de sistema del formulario de solicitud. (Vase el captulo 1).
4. Plan de trabajo
el plan de trabajo original, revisado despus de haber completado la fase de anlisis. (Ver el
captulo 2).
5. Anlisis de viabilidad de
un anlisis de viabilidad revisado, usando la informacin de la fase de anlisis. (Vase el captulo
1).
6. Definicin de los requisitos de
una lista de los requisitos funcionales y no funcionales de negocios para el sistema (este
captulo).
7. Casos de uso de
un conjunto de casos de uso que ilustran los procesos bsicos que el sistema necesita apoyo.
(Vase el captulo 4).
8. Modelo de proceso de
un conjunto de modelos de procesos y descripciones de la sistema. (Vase el captulo 5). Esto
puede incluir modelos de proceso del sistema actual de que sern reemplazados.
9. Modelo de datos de
un conjunto de datos y descripciones de los modelos a ser el sistema. (Vase el captulo 6). Esto
Figura 3-14 puede incluir modelos de datos de como es el sistema que ser reemplazado.
Esquema del sistema de Apndices
origen Tune propuesta contienen material adicional relevante para la propuesta, se utiliza a menudo para apoyar el
sistema recomendado. Esto podra incluir los resultados de una encuesta por cuestionario o
entrevistas, informes y estadsticas de la industria, etc.
Jason examin el plan de trabajo y realizado algunos pequeos cambios. l
tambin pro- mencionados con Carly y el departamento de marketing de sus
miembros para examinar el anlisis de viabilidad. No se introdujeron cambios
importantes en este punto; el proyecto sigue siendo altamente factible en general.
Todas las entregas del proyecto fueron luego se combinan para formar un sistema
propuesta y sometido a la aprobacin del comit. La figura 3-14 muestra el
contorno de la meloda propuesta del sistema de origen. Carly y Jason se reuni
con la aprobacin del Comit y present los aspectos ms destacados de lo que se
aprendi durante la fase de anlisis y el concepto final del nuevo sistema. Sobre la
base de la propuesta y presentacin, con la aprobacin del comit decidi que
seguira para financiar el sistema de descarga de msica digital.
Resumen
Anlisis
El anlisis se centra en la captura de los requisitos del negocio para el sistema.
Anlisis identifica el "qu" del sistema, lo que conduce directamente a la fase de
diseo, durante que el "cmo" del sistema est determinado. Muchos productos
son creados durante la fase de anlisis, incluyendo la definicin de requisitos,
casos de uso, modelos de proceso, y un modelo de datos. Al final del anlisis,
todos estos resultados, junto con la planificacin y gestin del proyecto revisado
de las entregas, se combinan en una propuesta de sistema y sometido a la
aprobacin del comit para una decisin sobre si debe o no seguir adelante con el
proyecto.
Determinacin de requisitos
Determinacin de requisitos es la parte de anlisis en que el equipo del proyecto
resulta de muy alto nivel, la explicacin de los requisitos empresariales, declar en
la solicitud del sistema en una lista ms precisa de las necesidades. Un requisito es
simplemente una declaracin de lo que el sistema debe hacer o qu caracterstica
debe tener. Requisitos de negocio describir el "qu" del sistema, y requisitos del
sistema describe "cmo" el sistema ser implementado. Un requisito funcional se
relaciona directamente con un proceso, el sistema tiene que realizar o la informacin
que debe contener. Requisitos Nonfunc- nales se refieren a propiedades de
comportamiento que el sistema debe tener como, por ejemplo, rendimiento y
usabilidad. Todos los requisitos funcionales y no funcionales de negocios que entran
dentro del mbito de aplicacin del sistema estn escritos en la definicin de los
requisitos.
Las tcnicas de obtencin de requisitos

Cinco tcnicas que pueden utilizarse para obtener los requisitos de negocio para el
sistema propuesto: entrevistas, desarrollo de la aplicacin conjunta, cuestionarios,
anlisis de documentos y observacin. Entrevistas implican que cumpla con una o
ms personas y hacindoles preguntas. Hay cinco pasos bsicos para el proceso de
la entrevista: seleccin inter- viewees, disear las preguntas de la entrevista, la
preparacin para la entrevista, la realizacin de la entrevista, y despus de la
entrevista de seguimiento. Joint Application Development (JAD) permite que el
equipo del proyecto, los usuarios y la administracin para que trabajen juntos para
identificar los requisitos del sistema. JAD electrnica intenta resolver los pro-
blemas comunes asociados con grupos con groupware. Un cuestionario es un
conjunto de auto- diez preguntas desarrollado para la obtencin de informacin de
los individuos. Los cuestionarios se utilizan frecuentemente cuando hay un gran
nmero de personas de las cuales la informacin y opiniones son necesarias.
Anlisis de documentos incluye la revisin de la documentacin existente y
examinar el sistema en s. Puede proporcionar ideas sobre el sistema formal e
informal. La observacin, el acto de ver los procesos que se realiza, es una potente
herramienta para recopilar informacin acerca del sistema tal y como es, porque
permite a los analistas a ver la realidad de una situacin de primera mano.
Estrategias de Anlisis de requisitos

Los analistas tienen a menudo para ayudar a los usuarios de negocios pensar
crticamente sobre su nuevo Sys- tem requisitos. Algunas estrategias son tiles.
Anlisis de problemas y anlisis de causa raz son dos estrategias que pueden
ayudar a los usuarios empresariales en la comprensin de los problemas y
cuestiones del sistema actual, que requieren una solucin. Anlisis de la duracin,
costeo basado en actividad, e informal de benchmarking son tres popular anlisis
de estrategias que ayudan al equipo a descubrir los procesos ms en necesidad de
rediseo. Por ltimo, los resultados de los anlisis, el anlisis de la tecnologa, y la
eliminacin de la actividad son tres estrategias que se pueden utilizar para
"obligar" a los usuarios de negocios a reflexionar acerca de los procesos de
negocio en nuevas formas novedosas, quizs descubriendo formas completamente
nuevas para llevar a cabo los procesos de negocio.
Trminos clave
Eliminacin de la de costeo basado en Como es el sistema de
actividad de anlisis actividad benchmarking entrevista bottom-up
Amplitud de anlisis JAD electrnica (e-
empresarial requisito JAD) facilitador
pregunta cerrada las Requisit
habilidades de o
pensamiento crtico, Funcion
el anlisis de los al del
documentos de sistema
anlisis de duracin formal
de regla
de tierra
Benchmarking
informal
142 Chapter 3 Requirements Determination Preguntas 141
Sistema informal Informe Postsession Muestra

de habilidades valor comercial Scribe
interpersonales potencial sondaje Stakeholder
Entrevista Pregunta Problema Entrevista
Entrevista Anlisis de costo de estructurada
Entrevista proyecto de integracin sntoma
Entrevista informe de proceso de definicin Propuesta del
calendario notas de requisitos requisito Sistema Requisitos
Joint Application cuestionario del sistema para el
Development (JAD) Determinacin de requisitos anlisis de la
Requisitos no funcionales riesgo tecnologa a ser
observacin Causa raz sistema
Pregunta abierta la Anlisis de causa raz Top-down entrevista
paralelizacin de entrevista no
anlisis de resultados estructurada puede
atravesar los requisitos
de usuario
Preguntas
1. Cul es el significado del anlisis? Cul es la proyecto? Por qu o por qu no?
pose correspon- de la fase de anlisis del Centro de 9. Discutir la forma adecuada de configurar y realizar
descargas de Sun? entrevistas para la obtencin de requisitos.
2. Cules son los elementos clave de la propuesta 10. Dar un ejemplo de una pregunta cerrada, una
del sistema? pregunta abierta, y una pregunta de tanteo.
3. El proyecto de desarrollo de un Cundo cada tipo de pregunta se utiliza?
sistema pueden enfocarse en una de dos 11. "Las entrevistas deben ser siempre realizada como
maneras: como un nico proyecto monoltico, en el entrevistas estructuradas." est usted de acuerdo con
que todos los requisitos se consideran a la vez o esta afirmacin? Por qu o por qu no?
como una serie de pequeos proyectos centrados
en pequeos conjuntos de requisitos. El enfoque
parece ser ms exitoso? por qu suponer que esto
es cierto?
4. Distinguir entre empresas, usuarios y requisitos
funcionales.
5. Explicar qu se entiende por un requerimiento
funcional. Cules son los dos tipos de requisitos
funcionales? Dar dos ejemplos de cada uno de
ellos.
6. Explicar qu se entiende por un afuncional
requieren- ment. Cules son los principales tipos
de requisitos no funcionales? Dar
dos ejemplos de cada uno de ellos. Qu
papel juegan los requisitos no funcionales en
el proyecto en general?
7. Cul es el valor de la produccin de los requisitos
de una definicin y con el patrocinador del
proyecto y la clave a los usuarios revisar y
aprobar?
8. Cules son los tres pasos bsicos del proceso de
anlisis? Cada paso es realizado en cada
12. Discutir los aspectos que debe tener en cuenta a
la hora de determinar a quin incluir en las
entrevistas y/o sesiones de JAD.
13. Es el objetivo principal de las necesidades
determinacin para descubrir hechos o
para descubrir opiniones? Explique su respuesta.
14. Describir los cinco pasos principales para
realizar sesiones de JAD.
15. Describir las principales funciones que
intervienen en el JAD ses- siones. Cul es la
principal contribucin de la(s) persona(s) que el
cumplimiento de cada rol?
16. Discutir las razones que cuestionan el diseo de
cuestionarios es tan difcil.
17. Por qu es til el anlisis de documentos? Qu
ideas sobre la organizacin puede proporcionar?
18. Sugerencias de esquema para hacer una
observacin til y fiable tcnica de obtencin de
requisitos.
19. Describir una estrategia para utilizar las distintas
tcnicas de obtencin de requerimientos en un
proyecto.
20. Discutir el anlisis de problemas como
una estrategia de anlisis. Cules son las
fortalezas y limitaciones de esta tcnica?
21. Discutir el anlisis de la causa raz como
una estrategia de anlisis. Cules son las
fortalezas y limitaciones de esta tcnica?
22. Comparar y contrastar el anlisis de la
duracin y costes basados en actividad-. Qu
papel desempean estas actividades como el
anlisis de las estrategias?
23. Cmo puede contribuir el benchmarking
informal para determinacin de requisitos?
24. Comparar y contrastar los resultados de anlisis,
technol- ga, anlisis y eliminacin de actividad.
Qu contribucin general estas estrategias juegan
en la determinacin de las necesidades?
Ejercicios
A. Revise el sitio web de Amazon.com. Desarrollar la Con el cual los estudiantes pueden solicitar libros
definicin de los requisitos para el sitio. Crear una online y recibirlas en sus dormitorios y off-campus
lista de requisitos de negocio funcionales que el alojam- ing. Qu tcnicas de recopilacin de
sistema responde. Qu tipos diferentes de requisitos se puede utilizar? Describir en detalle
afuncional business no cumple los requisitos del cmo se aplican las tcnicas.
sistema? Proporcionar ejemplos de cada tipo. H. Supongamos que eres el analista encargado de
B. Supongamos que se va a construir un nuevo sistema desarrollar un nuevo sistema para ayudar a los
que automatiza o mejora el proceso de entrevista directivos tomar mejores decisiones estratgicas.
para el departamento de servicios profesionales de Qu requisitos - tcnicas de recogida se puede
su escuela. Desarrollar una definicin de requisitos utilizar? Describir en detalle cmo se aplican
para el nuevo sistema. Incluyen tanto los requisitos las tcnicas.
funcionales y no funcionales del sistema. Imagine I. Encontrar un socio y entrevista mutuamente acerca
que va a liberar el Sys- tem en tres versiones de las tareas que se hicieron en el ltimo puesto de
diferentes. Priorizar las exigen- cias en trabajo celebradas (tiempo completo, tiempo
consecuencia. parcial, pasadas o actuales). Si no
C. Describir en trminos muy generales la proceso de ha trabajado antes, entonces, asumir que su trabajo
negocios para registrarse para las clases en la es ser un estudiante. Antes de hacer esto,
universidad. Colaborar con otros estudiantes en la desarrollar una breve entrevista plan. Despus de
clase y evaluar el proceso utilizando el anlisis de que su pareja entrevistas, identificar el tipo
problemas y anlisis de causa raz. Sobre la base de entrevista, entrevista en el enfoque, y tipos de
de sus trabajos, la lista algunos ejemplos de cuestiones utilizado.
mejoras que usted ha identificado. J. Encontrar un grupo de estudiantes y ejecutar
D. Describir en trminos muy generales la proceso de una sesin de JAD de 60 minutos sobre la mejora
negocios para solicitar la admisin en su univer- de relaciones con egresados en su uni-
sity. Colaborar con otros estudiantes en la clase versity. Desarrollar un plan de JAD breve,
y evaluar el proceso utilizando la banqueta seleccione dos techniques que ayudar a
informal- marcado. Sobre la base de sus trabajos, identificar posibles mejoras y, a continuacin,
la lista algunos ejemplos de mejoras que usted ha desarrollar un programa. Conducir la sesin,
identificado. usando el programa y escribir el informe posterior
E. Describir en trminos muy generales la proceso de al perodo de sesiones.
negocios para registrarse para las clases en la K. Encontrar un cuestionario en la Web que ha cre-
universidad. Colaborar con otros estudiantes en la ados para capturar informacin del cliente.
clase y evaluar el proceso mediante la eliminacin Describir el propsito de la encuesta, la forma en
de la actividad. Sobre la base de sus trabajos, la que estn redactadas las preguntas, y cmo las
lista algunos ejemplos de las mejoras que ha preguntas han sido organizados. Cmo puede
identificado. mejorarse el cuestionario? Cmo analizar las
F. Supongamos que la universidad est teniendo respuestas?
un dramtico aumento en la inscripcin y est L. Desarrollar un cuestionario que ayudar a recabar
teniendo dificultades para encontrar suficientes informacin relativa a procesos en un popular
asientos en cursos para los estudiantes restaurante o cafetera de la escuela (por ejemplo,
para que puedan tomar los cursos necesarios para pedido, servicio al cliente). Dar el cuestionario a
la graduacin. Realizar un anlisis de la tecnologa 10-15 estudiantes, analizar las respuestas y escribir
para identificar nuevas formas de ayudar a los un breve informe que describe los resultados.
estudiantes a completar sus estudios y graduarse. M. Pngase en contacto con el departamento de
G. Supongamos que eres el analista encargado de servicios profesionales a su uni- versity
desarrollando un nuevo sistema para la librera y encontrar todos los documentos pertinentes
universitaria diseados para ayudar a los estudiantes a encontrar
permanente y/o empleos a tiempo parcial. Analizar
los documentos y escribir un breve informe.
MINICASES
1. La asociacin de bomberos del Estado tiene una Ao reuniendo a los bomberos de todo el estado.
membresa de 15.000. El propsito de la organizacin Anualmente, los miembros se cobran cuotas y
es proporcionar apoyo financiero a las familias de los llamadas. "Llama" son fondos adicionales necesarios
fallecidos estados bomberos y a organizar una para cuidar de los pagos realizados a las familias de
conferencia cada los miembros fallecidos.
144 Chapter 3 Requirements Determination Minicases 143
La labor de contabilidad para la asociacin es Una tarde, jugando al golf con un amigo que trabaja
manejada por el electo tesorero, Bob Smith, pese a en el departamento de operaciones de fabricacin,
que es ampliamente sabido que su esposa, Laura, Brian aprendi que Joe quiere empujar el marco
hace todo el trabajo. Bob se ejecuta cada ao sin temporal del proyecto de Brian la estimacin inicial de
oposicin en las elecciones, pues nadie quiere 13 meses. Brian's amigo Joe escuch decir, " no
asumir el tedioso y engorroso trabajo de seguimiento puedo ver por qu eso
de la pertenencia. Bob recibe un estipendio de $8000
por ao, pero su esposa dedica ms de 20 horas a la
semana en el trabajo. Sin embargo, la organizacin no
est contento con su rendimiento.
Se utiliza un sistema informtico para realizar el
seguimiento de la facturacin y la recepcin de los
fondos. Este sistema fue desarrollado en 1984 por un
estudiante de ciencias de la computacin y de su
padre. El Sys- tem es un sistema basado en dos
escritos en dBase 3. El problema ms inmediato hacia
el tesorero y su esposa es el hecho de que el paquete
de software ya no existe, y no hay nadie a quien sabe
cmo mantener el sistema. Una consulta en particular
tarda 17 horas para ejecutarse. A lo largo de los aos,
se han evitado la ejecucin de esta consulta, aunque
la informacin sera muy til. Las preguntas de los
miembros contra- partes referentes a sus
declaraciones no pueden ser respondidas con
facilidad. Generalmente, Bob o Laura jots justo abajo
de la encuesta y devuelve una llamada con la
respuesta. A veces se tarda de 3 a 5 horas para
encontrar la informacin necesaria para responder a
la pregunta. A menudo, tienen que realizar los
clculos manualmente, ya que el sistema no estaba
programado para manejar ciertos tipos de consultas.
Cuando los Estados miembros informacin se
introduce en el sistema, cada campo se pre- sentaron
una a la vez. Esto hace que sea muy difcil volver a
un campo y corregir un valor que se introdujo. A
veces se introduce un nuevo miembro, pero
desaparece de los registros. El informe de la
composicin utilizada en los materiales de la
Conferencia no se alfabetiza pases miembros por
ciudad. Slo las ciudades aparecen en el orden
correcto. Qu tcnica o tcnicas de anlisis de
requisitos le recomendara a esta situacin? Explique
su
Respuesta.
2. Brian Callahan, es gerente de proyecto, est casi listo
para partir una reunin urgente llamado por Joe
Camp- bell, gerente de operaciones de fabricacin.
Un importante proyecto BPI, patrocinado por Joe,
recientemente autoriz la aprobacin obstculo, y
Brian ayud a llevar el proyecto a travs de la
iniciacin. Ahora que la comi- sin de aprobacin ha
dado el visto bueno, Brian ha estado trabajando en el
plan de anlisis del proyecto.
Equipo de proyecto se necesita gastar todo ese Es realmente sencillo!" Barry's confianza en sus
tiempo 'analizar' las cosas. Tenemos dos semanas aptitudes analticas incrementado como anticip el
programadas slo a mirar el sistema existente! lder de su equipo, la alabanza.
Parece que fuera un autntico despilfarro. Quiero
que el equipo para empezar a trabajar en la
construccin de mi sistema".
Porque Brian tiene un poco de conocimiento
interior acerca de Joe's agenda para esta reunin, l
ha estado considerando cmo manejar Joe. Qu te
sugieren que Brian decirle a Joe?
3. Barry ha sido recientemente asignado a un equipo
de proyecto que ser el desarrollo de una nueva
administracin de tiendas minoristas Sys- tem para
una cadena de tiendas de sndwich submarino.
Barry tiene varios aos de experiencia en
programacin, pero no ha hecho mucho anlisis en
su carrera. l era un iluminado- tle nervioso sobre el
nuevo trabajo que estara haciendo, pero confiaba
en que poda manejar cualquier asignacin que le
fue dada.
Una de las primeras tareas de Barry fue a visitar
a uno de los submarinos loncheras y preparar un
informe de observacin sobre cmo opera la
tienda. Barry previsto para llegar a la tienda
alrededor del medioda, pero l eligi un almacn en
una zona de la ciudad que l no conoca, y debido a
los atascos de trfico y la dificultad en encontrar la
tienda no lleg hasta las 1:30 p.M. El gerente de la
tienda no esperaba de l y se neg a dejar entrar a
un extrao detrs del mostrador hasta que Barry
haba l contactar el proyecto podrn patrocinarse
(el director de administracin de la tienda) en com-
Pany la sede para verificar quin era l y cul era su
propsito.
Finalmente, despus de conseguir permiso para
observar, Barry estacionadas a s mismo de manera
destacada en el rea de trabajo detrs del mostrador
para que pudiera ver todo. El personal tuvo que
maniobrar alrededor de l mientras realizaban sus
tareas; sin embargo, slo hubo menor col- lisions
ocasionales. Barry not que el almacn personal
pareca estar yendo sobre su trabajo muy lentamente
y deliberadamente, pero que supona que era porque
la tienda no estaba muy lleno. En primer lugar, Barry
cuestionaron cada trabajador acerca de lo que l o
ella estaba haciendo, pero el gerente de la tienda
incluso- tually le pregunt a no interrumpir su labor
tanto- estaba interfiriendo con su servicio a los
clientes. A las 3:30, Barry era un poco aburrido. Se
decidi a salir, creyendo que poda volver a la
oficina y preparar su informe antes de las
5:00 p.M. Ese da. Estaba seguro de que el lder de su
equipo, estara encantado con su pronta finalizacin
de su asignacin. Mientras conduca, reflexion, "no
hay realmente mucho que decir en este informe.
Todo lo que hace es tomar la orden, hacen de la
arena- el cual, recoger el pago y entregar el pedido.
De vuelta en la tienda, el gerente de la tienda Anne desarrollado cuidadosamente el cuestionario

sacudi la cabeza, refirindose a su personal, "l y probada en varios supervisores de ventas que
viene aqu por el lento- est hora del da en el ms estaban disponibles en la sede de la empresa. Tras
lento de los das de la semana. l nunca incluso revisarlo de acuerdo a sus sugerencias, ella envi un
mirado todo el trabajo que estaba haciendo en la documento versin del cuestionario a cada
trastienda mientras l estaba aqu-resumiendo yester- empleado, pidiendo que sea devuelto en el plazo de
da de ventas, control de inventario en mano, una semana. Una semana despus, ella slo tena tres
haciendo pedidos de reabastecimiento hasta el fin de cuestionarios devueltos. Despus de otra semana,
semana ms que nunca nuestra tienda incluso Anne recibi slo dos ms cuestionarios
considera que los procedimientos de apertura y cierre. completados. Sintindose algo desesperado, Anne a
Me gusta pensar que el nuevo sistema de gestin de continuacin enva un e-mail versin del
almacn va a ser construida por alguien como l. Me cuestionario, una vez ms a todos los empleados,
gustara mejor contacto Chuck (el director de pidindoles que respondan el cuestionario por correo
administracin de la tienda) y hgale saber que pas electrnico tan pronto como sea posible. Ella recibi
aqu hoy". Evaluar la conducta de Barry de la dos cuestionarios por correo electrnico y tres mes-
observacin de asignacin. sabios de oficinistas que haban completado el papel
4. Anne se ha dado la tarea de realizar un estudio de los versin expresando su malestar por ser molestado
dependientes que estar usando un nuevo sistema de con el mismo cuestionario una segunda vez. En este
entrada de pedidos que est siendo desarrollado para punto, Anne tiene slo un 14% la tasa de respuesta,
un catlogo de productos domsticos empresa. El que es seguro que no va a satisfacer a su lder de
objetivo de la encuesta es identificar los oficinistas' equipo. Qu sugerencias hara que podran haber
opiniones sobre las fortalezas y debilidades del mejorado Anne's la tasa de respuesta al cuestionario?
sistema actual. Hay alrededor de 50 empleados que
trabajan en tres ciudades diferentes, por lo que un
estudio pareca una forma ideal de reunir la
informacin necesaria de los oficinistas.
PLANIN G
ANALSIS
utilizar tcnicas de obtencin de requisitos
(entrevistas, sesiones JAD, cuestionarios, anlisis de
documentos y observacin)
aplique estrategias de anlisis de requisitos necesarios
para
Descubra los requisitos subyacentes
Desarrollar la definicin de los
requisitos desarrollar casos de uso.
Desarrollar diagramas de flujo de
datos desarrollar modelo de entidad
relacin normalizar el modelo de
entidad relacin
T Un S K C H E C K L Yo S T
PLANING ANALSIS DESIGN

Systems Analysis Design UML 5th Ed 127 172 Español

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Systems Analysis Design UML 5th Ed 127 172 Español

Transféré par

Droits d'auteur :

Formats disponibles

CHAPTER 3

D urante la fase de anlisis, el analista determina los requisitos funcionales para el

Comprender la situacin existente (como es el sistema).

A veces el primer paso (es decir, la comprensin del sistema as-

Como ejemplo, supongamos que un usuario afirma que el nuevo sistema

Categoras puede parecer intimidante al principio, las categoras reflejan

YSUR 3-1 IDENTIFICACIN RREQUISITOS

Los requisitos de usuario y requisitos funcionales definidos en la fase de

El proceso de determinacin de los requisitos

5 Frank Hayes, "caos" est de vuelta, Computerworld, 8 de noviembre de 2004.

Fuente: el Atlntico, el gremio de los sistemas http://www.systemsguild.com

Conceptos 3-WHAT CUN HAPPEN SI STED Ignorar NONFUNCTIONAL RREQUISITOS

No ser conscientes de las posibilidades que

1. Nueva gestin de vehculos

2. Gestin de ventas de vehculos

3. Gestin de vehculos usados

Como se muestra en la Figura 3-3, es comn a varios de los requisitos

Las tcnicas de obtencin de requisitos

Obtencin de requisitos en la prctica

E incluso algunos clientes y proveedores. Tambin, ser sensible al hecho de que

La seleccin de los entrevistados una entrevista horario debera

Andria McClellan , Director visin estratgica para el Mon, el 1 de marzo

Conceptos 3-B SELECCIN DE LA WRONG Pas personas

Diseo de las preguntas de la entrevista existen tres tipos de preguntas:

El entrevistado en la tarea y ahorra tiempo, porque l o ella no necesita para

Queridos. Con el bottom-up entrevista, el entrevistador comienza con pre- guntas,

Preparacin para la entrevista , es importante prepararse para la entrevista de la

Realizacin de la entrevista al iniciar la entrevista, el primer objetivo es

Usted ha elegido para entrevistar a la persona y, a continuacin, avanzar en su

Prctico 3-1 D esarrollo I NTERPERSONAL S mata

Yonterpersonal habilidades son Puntos clave al altavoz (por ejemplo, "Quiero

Despus de la entrevista el seguimiento despus de la entrevista, el analista

Conceptos 3-C L A R INTERVIEWEE ELUCTANT

Notas de entrevistas Aprobado por: Linda Estey

Entrevistado: Linda Estey, Director

A menudo, la entrevista informe

Joint Application Development (JAD)

7 Ms informacin sobre JAD puede encontrarse en J. D. madera y plata, el desarrollo de aplicaciones

Tarjetas de Proyector Impres

YSUR 3-2 I PRACTICE NTERVIEW

Yonterviewing no es tan simple como primera QUESTIONS:

(particularmente su jefe), algunas personas suelen dominar la discusin, y no cada

Las reuniones suelen durar de 1 a 4 das en un perodo de 1 semana. JAD y e-

Que el grupo proporciona y ayuda al grupo a reconocer cuestiones fundamentales

Post-JAD seguimiento como con entrevistas, un JAD informe posterior al

YSUR PRACTICE 3-3 JAD

Ohvosotros rganize en grupos de asignacin, hacer un sndwich, pago de facturas, la

Prctico A dministracin de 3-2 P SESSIONS ROBLEMS EN JAD

He ejecutado ms de un centenar de JAD Persona trae a colacin la cuestin de nuevo,

Comenzar con preguntas interesantes y sin amenazas.

Disear el cuestionario desarrollar buenas preguntas es crtico para los cuestionarios

YSUR 3-4 Q PRACTICE UESTIONNAIRE

Ohvosotros rganize en pequeos Pasar el cuestionario en relacin con el creador cuando

El cliente cometi un error. El personal tuvo que agregar

Clnica veterinaria central

Nombre: Buffy Pat Smith

Nombre de Buffy Collie 7/6/07 Mac

Direccin: 100 Tribunal Central. Apartment

Toronto, Ontario K7L 3N6

Compaa de Pet's Mutual

El cliente no incluyen cdigo

Varios estudios han demostrado que muchos administradores realmente no recuerdo

Conceptos 3-D PUBLIX CREDIT CARD FORM

La prctica normal puede romper las reglas formales de organizacin, el