Introduccin

La parte 2 de este libro se centra en la fase de anlisis del SDLC. El trabajo

realizado 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 se refiere a la ruptura de un

anlisis
Todo en sus partes con la intencin de conocer las partes de la naturaleza, funcin
y
Interrelaciones. En el contexto de la SDLC, las salidas de la fase de planificacin
(la solicitud del sistema, un estudio de viabilidad y plan de proyecto), definir los
objetivos empresariales
Para el nuevo sistema, definir el alcance del proyecto, evaluar la factibilidad de
proyectos y proporcionar
El plan de trabajo inicial. Estas entregas de la fase de planificacin son los insumos
clave en el
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:
entender la situacin existente (como es el sistema).
Identificar mejoras.
Definir requisitos para el nuevo sistema (la del sistema).
A veces el primer paso (es decir, la comprensin del sistema as-is) es omitido o
hecho en una
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.
Tradicional
Mtodos tales como la cascada y desarrollo paralelo (vase el captulo 2)
tpicamente
Dedicar un tiempo considerable a la comprensin del sistema e identificar las
mejoras
Antes de pasar a capturar requisitos para la sistema. Nueva RAD y gil.
Metodologas, tales como el desarrollo iterativo, sistema de prototipos, prototipos
descartables,
Y la programacin extrema (vase el captulo 2), se centran casi exclusivamente en
Mejoras y la requisitos del sistema, y dedican poco tiempo para
La investigacin actual de los sistema. La experiencia demuestra que es
conveniente estudiar la

Situacin actual siempre que sea posible. Los conocimientos adquiridos a partir de
la revisin de la actual
El sistema puede ser muy valiosa para el equipo de proyecto.
Para mover los usuarios "desde aqu hasta all", un analista necesita un
fuerte pensamiento crtico
Aptitudes. El pensamiento crtico es la capacidad de reconocer sus puntos fuertes y
sus puntos dbiles.
Remodelacin de una idea en una forma mejorada. Estas habilidades son
necesarias para que el analista
Para comprender los problemas y desarrollar nuevos y mejores procesos de
negocio
Apoyado por tecnologas de sistemas de informacin. Estas habilidades son
esenciales para examinar
Los resultados de la deteccin de necesidades y traducir estos requisitos en
Un concepto para el nuevo sistema.
Como ejemplo, supongamos que un usuario afirma que el nuevo sistema debe
"eliminar
El agotamiento de las existencias de inventario." Aunque esto pudiera ser un
digno objetivo del proyecto, el analista
Necesita pensar crticamente a fin de formular la declaracin en trminos de
utilidad
Requisitos. El analista podra tener primero los usuarios pensar en las
circunstancias
Conduciendo a stock-outs (por ejemplo, rdenes de proveedor no estn colocados
de forma puntual) y, a continuacin,
Describir 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 alimentacin
Los elementos; se producen demoras en recibir la aprobacin de la orden de
suministro, etc.). Centrndose
Sobre estas cuestiones, el equipo est en una posicin mejor para desarrollar
nuevos procesos de negocio
Que aborden esas preocupaciones. Los nuevos requisitos ser entonces sobre la
base de los temas
Que realmente 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 elaborar 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
La notificacin.
El sistema deber producir un suministro de orden de compra que se envan a las
correspondientes
Jefe de proyecto 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 el verdadero
Requisitos para el nuevo sistema son fcilmente recogidos tras algunas
conversaciones

Con los interesados. El analista debe estar preparado para profundizar en la

situacin y descubrir
Requisitos. 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 las
tcnicas
Y las herramientas para que usted pueda aprender a utilizarlos durante la fase de
anlisis. Nosotros
Tambin 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 los
Tema 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 compila
La instruccin de definicin de requisitos detallados, casos de uso, modelos de
proceso, y
Modelo de datos junto con una versin revisada de un anlisis de viabilidad y plan
de trabajo. Al concluir
En la fase de anlisis, el sistema es una propuesta que se presenta a la aprobacin
del comit,
Generalmente en la forma de caminar a travs del sistema. El objetivo de la
caminata a travs de
Es explicar en detalle el sistema moderado, a fin de que los usuarios,
administradores y decisin clave
Decisiones claramente entendido, puede identificar las modificaciones necesarias,
y se
Puede tomar una decisin acerca de si el proyecto debe continuar. Antes de mover
En la fase de diseo, el proyecto debera revisarse para garantizar que contina
Aportar valor de negocio a la organizacin. Si se aprueba, la propuesta del sistema
Los componentes (la definicin de requisitos, casos de uso, modelos de procesos, y
el modelo de datos)
Se utilizan como insumos para los pasos en la fase de diseo, que refinar y
Definir en mucho ms detalle cmo funciona el sistema ser construido.
La lnea entre las fases de anlisis y diseo es muy borrosa, porque el
Entregas creadas en la fase de anlisis son realmente el primer paso en el diseo
de la
Nuevo sistema. Muchas de las principales decisiones de diseo para el nuevo
sistema se encuentran en
Anlisis de los resultados. De hecho, un mejor nombre para la fase de anlisis que
realmente
"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 aspecto ms crtico
de nico
Todo el SDLC. Aunque son muchos los factores que contribuyen a la falta de
desarrollo de sistemas

Los proyectos, no 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 la encuesta
Los encuestados consideraron el proyecto cumple con las necesidades de los
usuarios.2 Por lo tanto, los analistas deben dedicar
Considerable atencin a la labor realizada en la fase de anlisis. Es aqu que
Los principales elementos del sistema comienzan a emerger. Si los requisitos son
ms tarde
Encontr a ser incorrecta o incompleta, puede ser necesaria la rectificacin
significativa, agregando importantes
El tiempo y el coste del proyecto.
Durante la determinacin de requisitos, la concepcin del sistema es fcil
Cambiar porque se ha hecho poco trabajo todava. A medida que el sistema se
desplaza a travs de la posterior
SDLC fases (diseo e implementacin), se vuelve ms y ms difcil
Para volver a la determinacin de requisitos y hacer grandes cambios porque de
todos
La modificacin de que se trate. Esta es la razn por la que los enfoques iterativos
de muchos RAD y
Las metodologas giles son tan efectivas-pequeos lotes de requisitos puede ser
identificado
E implementado en etapas graduales, permitiendo que el sistema global para
cambiar
Y evolucionar a lo largo del tiempo. Adems, metodologas como la V-modelo que
las pruebas de estrs
El sistema debe definirse al mismo tiempo que los requisitos son: ser
Definido. De ese modo, no es slo una prueba de ltimo minuto, lanzados juntos en
proceso, pero
En su lugar se basa directamente en los requisitos del sistema que estn siendo
Definido.

Determinacin de requisitos

Determinacin de requisitos se realiza para transformar el sistema de peticin

de alto nivel
Declaracin de requisitos de negocio en una lista ms detallada, precisa de lo
El nuevo sistema debe hacer para proporcionar el valor necesario para el negocio.
Esta detallada
Lista de requisitos es compatible, confirmado y clarificado por las dems
actividades de
La fase de anlisis: la creacin de casos de uso, la construccin de modelos de
proceso, y la creacin de una base de datos
Modelo. En primer lugar debemos explicar qu es una exigencia y discutir el
proceso de creacin de una
Definicin de los requisitos de declaracin.

Qu es un requisito?

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

qu caractersticas
Se necesita tener. Durante un proyecto de desarrollo de sistemas, los
requerimientos sern creados
Que describa lo que necesita el negocio (); los requisitos empresariales de los
usuarios
Necesita hacer (Requisitos del usuario); lo que debe hacer el software requisitos
funcionales ();

Caractersticas debera tener el sistema (requisitos no funcionales); y cmo

El sistema debe ser construido (Requisitos del sistema). Aunque esta
lista de requisitos
Categoras puede parecer intimidante al principio, las categoras reflejan
simplemente el propsito
Los requisitos y la etapa en el centro de descargas de Sun en el que estn
definidas.
Ya hemos hablado de la creacin de la solicitud en la planificacin de sistemas
Las fases del SDLC. En la peticin del sistema, hay declaraciones que describen las
razones
Para proponer el proyecto de desarrollo de sistemas. Estas declaraciones reflejan la
Requisitos empresariales que este sistema, si se construye, cumplir. Estos
requisitos empresariales
Ayudan a definir los objetivos generales del sistema y ayudar a clarificar las
contribuciones
Har que el xito de la organizacin. Ejemplos de los requisitos de negocio
Incluye: "Aumentar la cuota de mercado"; "Acortar el tiempo de procesamiento del
pedido"; "Reducir el cliente
Los costos de servicio"; "inventario menor corrupcin"; "Mejorar la capacidad de
respuesta a
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 alcanzados.
Por lo tanto, proporcionan la direccin general para el proyecto.
Durante la fase de anlisis, los requisitos estn escritos desde la perspectiva de
El negocio, y se centran en lo que el sistema necesita hacer para satisfacer
business
Las necesidades de los usuarios. 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 la
Las operaciones de negocios, tales como: "Programar una cita del cliente";
"Colocar un nuevo cliente
Orden"; "Re-inventario orden"; "Determinar el crdito disponible"; y "look up
Los saldos de las cuentas." Los casos de uso (discutidos en el captulo 4) son
herramientas que se utilizan para aclarar el
Los pasos implicados en la realizacin de estas tareas de usuario. Mediante la
comprensin de lo que el usuario
Hay que hacer en trminos de tareas a realizar, el analista puede entonces
determinar maneras 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 a un usuario
Tarea y/o la informacin que necesita proporcionar el usuario est realizando una
tarea. El
International Institute of Business Analysis (IIBA) define requisitos funcionales.

Como "las capacidades del producto, o cosas que un producto debe hacer para sus
usuarios."3 funcional
Requisitos empezar a definir cmo el sistema dar soporte al usuario en la
realizacin
Una tarea. Por ejemplo, supongamos que el usuario requisito es "Programar un
cliente
Nombramiento." Los requisitos funcionales asociados con esa tarea incluyen:
"Determinar
Disponibilidad del cliente", "encontrar vacantes disponibles, disponibilidad cliente
coincidentes"
"Seleccione la cita deseada", "Constancia de nombramiento", y "confirmar el
nombramiento".
Observe cmo estos requisitos funcionales ampliar la tarea del usuario para
describir
Las capacidades y funciones que el sistema deber incluir, permitiendo al usuario
Completar la tarea.
Como el analista trabaja con las empresas usuarias del sistema para descubrir y
usuario
Los requisitos funcionales, 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
podr indicar
"El sistema debe conservar el historial de pedidos de los clientes durante tres
aos" (una informacin
La necesidad). 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 pedido para
Los ltimos tres aos" (un proceso que necesita). Del mismo modo, el usuario
puede indicar "el sistema
Debera comprobar pedidos de clientes entrantes para disponibilidad de
inventario" (un proceso que necesita).
Un analista de alerta reconocer la necesidad de informacin relacionada, "El
sistema debe 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/
Los procesos para los usuarios del sistema, cmo las funciones y procesos se
relacionan entre s, cmo
Los datos se introducen y producida por funciones o procesos, y cmo las
funciones y procesos
Creacin y uso de los datos almacenados. Modelos de proceso ayudan a aclarar los
componentes de software
Que sern necesarios para cumplir con los requisitos funcionales. Adems, el
Requisitos funcionales comenzar a definir los datos que deben conservarse con el
fin de pista
Para llevar a cabo las tareas de usuario. Los datos de los componentes del sistema
se define en el
Modelo de datos (captulo 6).
Los requisitos de usuario y requisitos funcionales definidos en la fase de anlisis se

Flujo en la fase de diseo, donde evoluciona hasta convertirse en ms tcnica,

describiendo cmo
El sistema ser implementado. Requisitos en la fase de diseo reflejan la
Developer's
Perspectiva y generalmente 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 blackandBlanco, 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
Requisitos cambiarn con el tiempo a medida que el proyecto avanza desde la
planificacin hasta el anlisis
Para el diseo de la aplicacin. Requisitos evolucionan a partir de amplias
declaraciones de general
Necesidades empresariales, desde el sistema de declaraciones detalladas de las
capacidades empresariales
Ese sistema debera apoyar a declaraciones tcnica detallada de la forma en
Las capacidades que se implementar 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 e
implementacin
Las restricciones, y las interfaces externas que un producto debe tener." 4
Aunque el trmino "funcionales" no es muy descriptiva, este requisito de la
categora
Incluye importantes propiedades de comportamiento que el sistema debe poseer,
tales como
Rendimiento y facilidad de uso. La posibilidad de acceder al sistema a travs de un
dispositivo mvil
Sera considerado un requisito no funcionales. Requisitos no funcionales son
Se utiliza principalmente en la fase de diseo cuando se toman decisiones acerca
de la interfaz de usuario,
El hardware y software, y la arquitectura subyacente del sistema. Muchos de
Estos requisitos sern descubiertos durante las conversaciones con los usuarios en
el anlisis
Fase, 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 describen una variedad de
sistema
Caractersticas: funcionamiento, rendimiento, seguridad y cultural y poltica. Estos
Caractersticas no describir procesos de negocio o informacin, pero son muy
Importante en la comprensin de lo que el sistema final como debe ser. Por
ejemplo, el
Equipo de proyecto necesita saber si un sistema debe ser altamente seguro,
requiere subsecond
Tiempo de respuesta, o ha de alcanzar una base de clientes multilinge. Estos
requisitos

Afectar a las decisiones de diseo que se realizarn en la fase de diseo,

especialmente
Diseo de arquitectura, as que revisaremos en detalle en el Captulo 8. El objetivo
de este
El punto es identificar las cuestiones principales. Adems, si la metodologa en uso
incluye
Desarrollar planes de prueba durante el anlisis, a continuacin, estos requisitos
sern importantes en
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 el
Fase de anlisis. Los analistas de sistemas no pueden comprender el verdadero
negocio de las necesidades
Los usuarios. Un estudio reciente realizado por el Standish Group constat que la
falta de participacin del usuario
Es la principal razn para que el proyecto fracase.5 Por otra parte, los usuarios
empresariales pueden

El funcionamiento en entornos fsicos y tcnicos

Que el sistema funcionar
El sistema puede ejecutarse en dispositivos de mano.
El sistema debera ser capaz de integrarse con los
actuales
Sistema de inventario.
El sistema debera ser capaz de trabajar en cualquier
explorador Web.

El rendimiento de la velocidad, la capacidad y la fiabilidad del sistema

No debe exceder de 2 segundos.
cualquier interaccin entre el usuario y el sistema
debera
El sistema nuevo dentro de los parmetros de estado
de descargas
A 5 minutos de un cambio.
El sistema debe estar disponible para su uso durante
las 24 horas del 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 que ha autorizado el acceso al sistema en .

Qu circunstancias
directa slo los administradores pueden ver los
registros de personal de personal
Los clientes pueden ver su historial de pedidos slo
durante business
Horas.
El sistema incluye todas las salvaguardias disponibles
de virus,
Los gusanos, troyanos, etc.

Poltica cultural y los factores culturales y polticos y legales

Requisitos que afectan al sistema
El sistema debera ser capaz de distinguir entre EE.UU.
Moneda y divisas de otros pases.
La poltica de la empresa es comprar ordenadores slo

De Dell.
Los directores del pas estn autorizados a autorizar
usuario personalizado
Las interfaces dentro de sus unidades.
informacin personal est protegida de conformidad
con la Ley de Proteccin theData.

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 manera de
Apoyar ese 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 un
Casa o apartamento, y la mayora de nosotros tenemos cierta comprensin de lo
que nos gustara
En nuestros hogares. Si se nos pidi disear una casa desde cero, sin embargo,
permitira
Ser un reto porque nos falta el diseo apropiado de las habilidades y tcnicas de
ingeniera
Habilidades. Asimismo, un arquitecto actuando solos, probablemente pierda
algunos de nuestros exclusivos
Requisitos.
Por lo tanto, el enfoque ms eficaz es tener ambos empresarios y
Los analistas 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 el principal
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
Los interesados. Hay una variedad de tcnicas de captacin que puede utilizarse
para
Adquirir informacin, incluyendo entrevistas, cuestionarios, la observacin, la
aplicacin conjunta
Desarrollo (JAD), y anlisis de documentos. Discutiremos estas tcnicas
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 los
requisitos
Que se identifican. Durante este proceso, los casos de uso, modelos de procesos y
datos.
Los modelos pueden ser utilizados para aclarar y definir las ideas para el nuevo
sistema. Este proceso
Contina durante la fase de anlisis, y la definicin de los requisitos evoluciona

A lo largo del tiempo a medida que se identifican nuevos requisitos y a medida que
el proyecto avanza hacia adelante
Las fases del SDLC.
Cuidado: La evolucin de la definicin de los requisitos debe ser cuidadosamente
Administrado. Mantenimiento de la lista de requisitos apretadas y centrado es la
clave para el xito del proyecto.
El equipo del proyecto no puede seguir aadiendo nuevos elementos para la
definicin de requisitos
O el sistema seguir creciendo y creciendo y nunca terminan. En su lugar,
El equipo del proyecto identifica y evala los requisitos cuidadosamente cules
colocar
Dentro del alcance del sistema. Cuando un requisito refleja una necesidad de
negocio real, pero es
No est dentro del alcance del sistema actual o la versin actual, debera ser
evaluado
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 la
adecuada
Ajustes en el mbito del proyecto, presupuesto y plazos. No debemos
Asumir que los requisitos para el proyecto nunca puede ser cambiado. Sin
embargo, es
Tambin es posible que el requisito podra ser agregado a una lista de futuras
necesidades
O considerada de baja 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 generalmente llamados simplemente
los requisitos
Definicin: es un informe de texto sencillo que simplemente enumera las
caractersticas funcionales y no funcionales
Requisitos en un formato de esquema. La figura 3-3 muestra un ejemplo de
requisitos
Definicin para los viajes de vacaciones de 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 a inventario cuando son recibidos
A partir 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 registrar informacin sobre un cliente-comercio en el vehculo...

Requisitos no funcionales
1. Funcionamiento
1.1 El sistema se debe ejecutar en los 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 debera 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 actualizarse 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 La utilizacin 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".

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

forma legal
O formato de esquema, de modo que cada requisito est claramente identificado.
Es importante que
Los requisitos ser identificados con nmeros nicos para que cada requisito puede
Ser fcilmente rastreados a travs de todo el proceso de desarrollo. Para mayor
claridad, los requisitos
Normalmente se agrupan en grupos funcionales y no funcionales. Entonces,
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 los requisitos de
declaracin.
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
El requisito (por ejemplo, versin 1, versin 2, versin 3). Esta prctica es
especialmente
Importante RAD con metodologas que entregar los requisitos en lotes mediante el
desarrollo
Versiones incrementales del sistema.
El objetivo ms obvio de la definicin de los requisitos es proporcionar una clara
Declaracin de lo que el nuevo sistema debe hacer para alcanzar la visin del
sistema
Descrita en la solicitud del sistema. Los casos de uso, modelos de proceso, y los
modelos de datos
Proporcionar contenido adicional explicativo en diferentes formatos. Un importante
El propsito de la definicin de requisitos, sin embargo, es definir el alcance del
sistema.
El documento describe los analistas exactamente lo que el sistema necesita para
finales
Hacer. Adems, sirve para establecer las expectativas de los usuarios para el
sistema. Y si
Cuando surgen discrepancias o malentendidos, el documento sirve como un
recurso
Para la clarificacin.

Las tcnicas de obtencin de requisitos

Un analista es muy parecida a un detective (y usuarios empresariales a veces son

como esquivo
Los sospechosos). l o ella sabe que existe un problema que debe ser resuelto y
por lo tanto
Debe buscar pistas que desvelan la solucin. Lamentablemente, los indicios no son
Siempre obvia (y a menudo son perdidas), por lo que el analista debe notar los
detalles, hablar
Con testigos, y seguir los cables, as como Sherlock Holmes habra hecho. El
Mejores analistas a fondo para requisitos de bsqueda utilizando una variedad de
tcnicas
Y asegrese de que los actuales procesos de negocio 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 puede causar
Todo tipo de problemas.

Obtencin de requisitos en la prctica

Antes de discutir los cinco requisitos obtencin tcnicas en detalle, unos prcticos
Consejos estn en orden. En primer lugar, el analista debe reconocer que
importantes efectos secundarios
El proceso de definicin de requisitos que incluyen la construccin de apoyo
poltico para la
Proyecto y establecer confianza y relaciones entre el equipo de proyecto y el
ultimate
Los usuarios del sistema. Cada contacto y la interaccin entre el analista y una
El administrador o usuario de negocio potencial es una oportunidad para generar
inters, entusiasmo,
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 los
requisitos
Proceso de definicin.
Segundo, el analista debe determinar cuidadosamente que se incluye en el
Proceso de definicin de requisitos. La opcin de incluir (o excluir) alguien
Importante; la participacin de alguien en el proceso implica que el analista
opiniones que
Persona como un recurso importante de valores y sus opiniones. Usted debe incluir
Todos los interesados clave (las personas que pueden afectar al sistema o que ser
Afectados por el sistema). Esto podra incluir a los administradores, empleados,
funcionarios,
E incluso algunos clientes y proveedores. Tambin, ser sensible al hecho de que
algunos
Las personas que pueden tener una influencia significativa en el seno de la
organizacin incluso si no
Alto rango en la jerarqua de la organizacin formal. Si no implican una persona
clave,
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 son
Pidiendo a los participantes que hagan. La mejor manera de hacer esto es estar
completamente preparado y

Para hacer un buen uso de todos los tipos de requisitos de la obtencin de

tcnicas. Aunque,
Como veremos, la entrevista es la tcnica ms utilizada, otra indirecta
El analista mtodos pueden ayudarle a desarrollar 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
Los gerentes para tener una mejor comprensin del proyecto y obtener la "gran
imagen". Estos
Las entrevistas preliminares pueden luego ser seguido por el anlisis de los
documentos y, posiblemente,
La observacin de los procesos de negocio para aprender ms acerca de los
negocios, el dominio
El vocabulario y el sistema tal y como es. 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
a travs de
Las sesiones de 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 mucho
Ampliar el grupo de usuarios o usuarios potenciales para obtener una amplia gama
de opiniones. El concepto
Para el sistema a ser frecuentemente se desarroll a travs de entrevistas con
altos
Los gerentes, seguidas por sesiones de JAD con usuarios de todos los niveles, para
asegurarse de que el
Requisitos clave del nuevo sistema son bien entendidas.
En esta seccin, nos centraremos en los cinco requisitos ms comnmente usados
Obtencin tcnicas: entrevistas, sesiones JAD, cuestionarios, anlisis de
documentos,
Y observacin.

Entrevistas
La entrevista es la ms comnmente utilizada la tcnica de obtencin de
requisitos. Despus
Todo es natural-normalmente, si necesitan saber algo, pregunte a alguien. En
general,
Las entrevistas se realizan uno a uno (un entrevistador y un entrevistado),
Pero a veces, debido a las limitaciones de tiempo, varias personas son
entrevistados en el mismo
Tiempo. Hay cinco pasos bsicos para el proceso de la entrevista: La seleccin de
los entrevistados,
Diseo de las preguntas de la entrevista, la preparacin para la entrevista, la
realizacin de la entrevista
Y postinterview seguimiento6.
La seleccin de los entrevistados una entrevista horario debera ser creado,
anuncio que
Ser entrevistado, el propsito 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. El pueblo
Que aparecen en la programacin de la entrevista son seleccionados sobre la base
de la analista del
Necesidades de informacin. El patrocinador del proyecto, los principales usuarios,
y otros miembros de
El equipo del proyecto puede ayudar al analista determinar quines en la
organizacin puede mejor
Proporcionar informacin importante acerca de los requisitos. Estas personas se
enumeran en el
Programacin de la entrevista en el orden en el que deberan ser entrevistados.
Las personas en los diferentes niveles de la 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 un alto y
bajo nivel.
Perspectivas sobre un problema. Adems, el tipo de entrevistados que necesitas
Cambiar a travs del tiempo. Por ejemplo, al comienzo del proyecto, el analista
tiene una limitada
Comprensin de como es el proceso de negocio. Es comn comenzar entrevistando
a
Uno o dos directivos para obtener una visin estratgica y luego pasar a los
administradores de nivel medio
Quin puede proporcionar 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 llenar
En los detalles exactos de cmo funciona el proceso. Como la mayora de las otras
cosas acerca de sistemas
Anlisis, este es un proceso iterativo, empezando con los gerentes senior, pasando
a nivel intermedio
A continuacin, los administradores, los funcionarios, a los administradores de
nivel medio, etc.
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 se identifiquen ms informacin
necesaria
Y otras personas que puedan proporcionar la informacin.
Diseo de las preguntas de la entrevista existen tres tipos de preguntas:
Preguntas cerradas, preguntas abiertas y preguntas de sondeo. Closedended
Las preguntas requieren una respuesta especfica. Se puede pensar en ellos como
siendo similar a
Preguntas de opcin mltiple o aritmtico en un examen. (Consulte la Figura 3-5).
cerradas
Las preguntas se usan cuando el analista est buscando informaciones concretas y
precisas

(por ejemplo, cuntas solicitudes de tarjeta de crdito son recibidos por da). En
general, preguntas precisas
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 el
Respuesta es la manera que es, ni revelar informacin que el entrevistador hace
No creo que preguntar antes de tiempo.
Las preguntas abiertas son aquellas que deja espacio para la elaboracin por parte
de
El entrevistado. Son similares en muchos aspectos a las preguntas de redaccin
que podras 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
Al hablar de descubrir la informacin que es tan importante como la respuesta (p.
ej., si el entrevistado
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 siga
En 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 confirmar la informacin a partir de un
anterior
La respuesta, y son una seal de que el entrevistador est escuchando e
interesado
En el tema de discusin. Muchos analistas de comienzo son reacios a utilizar el
sondeo
Preguntas porque tienen miedo de que el entrevistado puede ser ofendido por ser
Cuestionado o porque creen que muestra que no entendan lo que el
Entrevistado dijo. Cuando hace cortsmente, preguntas de sondeo puede ser una
poderosa herramienta en Requisitos del descubrimiento.
En general, usted no debe hacer preguntas acerca de la informacin que se
encuentra fcilmente
Disponible a partir de otras fuentes. Por ejemplo, en lugar de preguntar qu
informacin es
Se utiliza para realizar una tarea, es ms fcil mostrar el entrevistado un formulario
o informe (vase
Anlisis de documentacin posterior) y preguntar qu informacin sobre ti es
utilizado. Esto ayuda a centrar
El entrevistado en la tarea y ahorra tiempo, porque l o ella no necesita
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

entrevistado
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 funcionarios de nivel inferior puede responder prontamente. Por el
contrario, de nivel inferior
Los empleados no podrn ser amplio, capaz de responder a preguntas orientadas a
la poltica, mientras que los administradores
Podra. Puesto que nadie quiere parecer ignorantes, evitar la confusin de los
entrevistados
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 se inicia con la
entrevista estructurada
EntrevistasLas 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 pocos
Las preguntas cerradas para preguntar. Estos son los ms difciles de llevar a cabo
entrevistas
Porque requieren el entrevistador para formular preguntas abiertas y sonda
Para obtener importante informacin "sobre la marcha".
A medida que avanza el proyecto, el analista trata de comprender el negocio
Proceso mucho mejor, y que l o ella necesita informacin muy especfica sobre
cmo los negocios
Los procesos se realizan (por ejemplo, exactamente cmo una solicitud de crdito
de cliente
Aprobado). En este momento, el analista realiza entrevistas estructuradas en las
que determinadas
Juegos de preguntas son desarrolladas 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 est llevando a cabo, las preguntas de la
entrevista
Debe estar organizada en una secuencia lgica de modo que la entrevista fluye
bien. Para
Ejemplo, cuando se trata de recopilar informacin acerca de los actuales procesos
de negocio, el
Analista le resultar til para moverse en un orden lgico a travs del proceso o de
los
Cuestiones ms importante hasta la menos importante.
Existen dos enfoques fundamentales para organizar las preguntas de la entrevista:
De arriba hacia abajo o de abajo arriba; vase la figura 3-6). Con el top-down
entrevista, el entrevistador
Comienza con un amplio, temas generales y poco a poco va hacia ms especfico
Queridos. Con el bottom-up entrevista, el entrevistador comienza con preguntas
muy concretas
Y mueve 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. (Es
Ciertamente el enfoque ms comn.) El enfoque top down permite que el
entrevistado
Para acostumbrarse al tema antes de que l o ella necesita para proporcionar
Detalles especficos. Tambin permite que el entrevistador para comprender las
cuestiones antes de mudarse a
Los detalles, porque el entrevistador puede no tener suficiente informacin al inicio
De la entrevista a preguntas especficas. Quizs lo ms importante, la topdown
Enfoque permite que el entrevistado a plantear una serie de cuestiones antes de
imagen grande
Cada vez atrapados en los detalles, por lo que el entrevistador es menos probable
que se pierda una llamada importante
Cuestiones.
Un caso en el cual la estrategia bottom-up puede ser preferida es cuando el
analista
Ya se ha reunido una gran cantidad de informacin acerca de problemas y slo
necesita rellenar algunos
Agujeros con 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 cliente.
Empleado de servicio, mientras que una pregunta especfica es fcilmente
respondible (p. ej., "Cmo podemos
Acelerar el cliente devuelve?"). En cualquier caso, todas las entrevistas deben
comenzar con noncontroversial
Preguntas 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 en que se preparar para dar una presentacin. Usted debe tener una
entrevista general
Plan que enumera las preguntas que le preguntar en el orden apropiado; anticipa
Proporciona respuestas posibles y cmo se har el seguimiento con ellos; y
Identifica segues entre temas relacionados. Confirmar las reas en las que el
entrevistado
Posee conocimientos de modo que no haga preguntas que l o ella no puede
responder. Comentario
Los temas, las preguntas, y el plan para la entrevista, y claramente decidir cules
Tienen la mxima prioridad en caso de que se agote el tiempo.
En general, las entrevistas estructuradas con preguntas cerradas tardan ms
tiempo
Para 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 entrevista
Tendra que obtenerse mediante esfuerzos de seguimiento, y la mayora de la
gente no le gusta
Al 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 en las que se
discutirn
Con suficiente antelacin a fin de que l o ella tenga tiempo para pensar acerca de
los temas
Y organizar sus pensamientos. Esto es particularmente importante cuando un
extrao
Para la organizacin y para entrevistar a empleados de nivel inferior que a menudo
son
No pregunt por sus opiniones y que puede ser incierto acerca de por qu usted
est entrevistando
Ellos.
Realizacin de la entrevista al iniciar la entrevista, el primer objetivo es
construir
La compenetracin 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
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 la entrevista
Preguntas.
Es fundamental registrar cuidadosamente toda la informacin que proporciona el
entrevistado.
En nuestra experiencia, el mejor enfoque es tomar notas cuidadosamente-escriban
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 esto es una clara indicacin de que la informacin es importante del
entrevistado
A 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
Intimidatorio para el entrevistado. La mayora de las organizaciones tienen
polticas o generalmente
Las prcticas aceptadas acerca de la grabacin de las entrevistas, a fin de
averiguar qu 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 detallado
Las notas.
A lo largo de la entrevista, es importante que usted entienda los problemas que
Son discutidas. Si usted no entiende algo, asegrese de preguntar. No tengas
miedo
Preguntar preguntas "tontas", porque la nica cosa peor que aparezcan "tonta" es

Ser "tonto" por no entender algo que usted podra haberse despejado de
interrogatorio.
Si usted no entiende algo durante la entrevista, usted ciertamente
No entiendo despus. Intentar reconocer y definir la jerga, y asegrese de que
Aclarar la jerga que no entienda. Una buena estrategia para aumentar su
comprensin.
Durante una entrevista es peridicamente resumir los puntos clave que el
Entrevistado se est comunicando. Esto evita confusiones y tambin demuestra
Que se 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 verificar los hechos
Porque cualquier diferencia entre los hechos y las opiniones del entrevistado puede
apuntar
Las reas clave de mejora. Supongamos que el entrevistado se queja de una
Alta o aumento del nmero de errores, pero los registros muestran que los errores
han sido
Disminuyendo. Esto sugiere que los errores son vistos como un problema muy
importante que
Debera ser abordado por el nuevo sistema, incluso si estn disminuyendo.
Como la entrevista llega a su fin, asegrese de darle tiempo para preguntar al
entrevistado
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
preocupaciones adicionales
O la informacin, pero en algunos casos esto conducir a imprevista, pero
importante
Informacin. Asimismo, puede ser til pedir al entrevistado si hay otros
Las 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
La siguiente seccin.) Usted no quiere prematuramente la promesa de
determinadas caractersticas en el nuevo
Sistema 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 necesaria en la
Una cuidada y organizada. En algunos casos, puede que no quiera compartir lo que
Todos conocemos. Los analistas deben afinar sus habilidades interpersonales para
mejorar sus entrevistas
El xito. (Ver sugerencia prctica 3-1).

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 recogieron durante el
curso
De la entrevista y se resumen en un formato til. En general, la entrevista
Informe debe ser escrito dentro de 48 horas despus de la entrevista, ya que
Espere, ms probabilidades existen de que se olvide la informacin.
A menudo, la entrevista informe es enviado al entrevistado con una solicitud para
leerlo
E informar al analista de aclaraciones o actualizaciones. Asegrese de que el
entrevistado est convencido
Que usted quiere realmente sus correcciones al informe. Normalmente, hay
Pocos cambios, pero la necesidad de cualquier cambio significativo que sugiere
que una segunda entrevista
Ser necesario. Nunca entregue informacin de alguien sin autorizacin previa.

Joint Application Development (JAD)

Joint Application Development ( JAD o como es ms conocido) es un servicio de
informacin
Reunin tcnica que permite que el equipo de proyecto, usuarios y administracin
Trabajar juntos para identificar los requisitos del sistema. IBM desarroll la tcnica
de JAD
A finales de la dcada de 1970, y es a menudo el mtodo ms til para recopilar
informacin
A partir de 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,
Ambos pueden causar problemas durante las etapas posteriores del SDLC.8 JAD es
un estructurado
Proceso en el cual 10 de 20 usuarios se renen bajo la direccin de
un facilitador capacitado
En JAD tcnicas. 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 proporcionan ideas u opiniones sobre los temas en discusin y permanece
Neutral durante la sesin. El facilitador debe ser un experto en el proceso de grupo
Tcnicas de anlisis y diseo de sistemas y tcnicas. Uno o dos escribanos ayudar
al
Facilitador mediante la grabacin de notas, hacer copias, y as sucesivamente. A
menudo, los escribas utilizar
Los 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
todos
De las cuestiones que se han debatido y se recopila la informacin necesaria. La
mayora JAD
Las sesiones tienen lugar en una sala especialmente preparada, lejos de los
participantes.
Las oficinas, por lo 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).
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
asociados
Con grupos: a veces la gente se muestra reacia a desafiar las opiniones de los
dems
(particularmente su jefe), algunas personas suelen dominar la discusin, y no todo
el mundo
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
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
El groupware. En un e-JAD Sala de reunin, cada participante utiliza un software
especial en un
Los ordenadores de la red a enviar annimamente ideas, ver todas las ideas
generadas por el
Grupo, y velocidad y clasificar ideas a travs de la votacin. El facilitador utiliza las
herramientas electrnicas
El sistema e-JAD para guiar el proceso de grupo, manteniendo el anonimato y
activacin
El grupo de enfoque 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 .
La seleccin de los participantes seleccin JAD participantes se realiza de la
misma forma bsica como
La seleccin de participantes en la entrevista. Los participantes son seleccionados
sobre la base de la informacin
Pueden contribuir a proporcionar una amplia gama de niveles de la organizacin, y
a
Crear apoyo poltico para el nuevo sistema. La necesidad de que todos los
participantes sean JAD
Lejos de sus oficinas al mismo tiempo puede ser un gran problema. La Oficina
podr
Deben ser cerradas o ejecutarse con una mnima dotacin de personal hasta las
sesiones de JAD estn completos.
Idealmente, los participantes que son liberados de la obligacin de asistir a las
sesiones regulares de la JAD
Las reuniones deberan ser las mejores personas en dicha unidad de negocio. Sin
embargo, sin una fuerte
Apoyo a la gestin de sesiones JAD puede fallar, porque aquellos seleccionados
para asistir el JAD
Perodo de sesiones 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-JAD tcnicas

Y, idealmente, alguien que tenga experiencia con los negocios 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 a varios
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
Las reuniones suelen durar de 1 a 4 das en un perodo de 1 semana. JAD y e-JAD
las sesiones suelen
Ir ms all de la recopilacin de informacin en producir resultados de anlisis.
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
JAD sesiones estn diseadas 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
Planearse cuidadosamente. 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.
Tpicamente, 30 minutos es asignado a cada tema del programa, as como de
frecuentes
Los descansos son programados a lo largo de todo el da, ya que los participantes
cansarse fcilmente.
Preparacin para la sesin de JAD como con entrevistas, es importante
preparar el
Los analistas y los participantes para la sesin de JAD. Debido a que las sesiones
pueden ir ms all de la
La profundidad de una entrevista tpica y generalmente se llevan a cabo fuera de
sitio, los participantes pueden ser
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, consiste
en desarrollar un
Comprensin 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
Se puede 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. Terreno comn
Las reglas incluyen el calendario siguiente, respetando las opiniones de otros,
aceptando el desacuerdo,
Y garantiza que slo una persona habla a la vez.
El papel del facilitador JAD puede ser desafiante. Muchos de los participantes
proceden de
El JAD sesin con fuertes sentimientos acerca del sistema que est siendo
discutido. Canalizacin
Estos sentimientos, de modo que la sesin avanza en una direccin positiva y
obtencin
Los participantes reconocen y aceptan, pero no necesariamente de acuerdo en
opiniones y
Situaciones diferentes de su propia requiere una experiencia significativa en el
anlisis de sistemas
Y DISEO, JAD, y las habilidades interpersonales. Algunos analistas de sistemas
intenta facilitar
Las sesiones de JAD sin ser entrenados en tcnicas de JAD, y la mayora de
aprendiz
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
Queda claro que el facilitador, lder de proyecto, patrocinador del proyecto y que la
sesin de JAD
Se ha producido una nueva informacin que es inesperado y requiere la sesin de
JAD
(y quizs el proyecto) para moverse en una nueva direccin. Cuando los
participantes intento
Para desviar el debate fuera de la agenda, el facilitador debe ser firme, pero
educado,
En liderar el debate volver a la agenda y obtener el grupo de vuelta en la pista.
Segundo, el facilitador debe ayudar al Grupo comprender los trminos tcnicos y
La jerga que rodean el proceso de desarrollo del sistema y ayudar a los
participantes
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
cmo eficazmente
Proporcionar la informacin adecuada.
En tercer lugar, el facilitador registra la entrada del grupo en un rea de
visualizacin pblica, que puede
Ser un rotafolio, pizarra o pantalla de ordenador. l o ella estructuras la
informacin
Que el grupo proporciona y ayuda al grupo a reconocer las principales cuestiones y
soluciones importantes.
Bajo ninguna circunstancia debe el facilitador insertar sus opiniones en la
La discusin. 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
una cuestin, el
Grupo ya no lo ve a l o a ella como una parte neutral, sino como alguien que
Podra intentar influenciar el grupo en alguna solucin predeterminada.
Sin embargo, esto no significa que el facilitador no debe tratar de ayudar al grupo
Resolver los problemas. Por ejemplo, si dos elementos parecen ser los mismos para
el facilitador, el
El facilitador no debe decir, "Creo que estos pueden ser similares." En su lugar, el
facilitador
Debera 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 similares
(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. Los casos de uso
puede ser creado 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. Proceso
Los modelos pueden ser construidos 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 est preparado y
Distribuy entre los asistentes a la sesin. El informe posterior al perodo de
sesiones es esencialmente el mismo
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 antes
de la JAD
Informe est completa.

Cuestionarios
Un cuestionario es un conjunto de preguntas escritas para la obtencin de
informacin de los individuos.
Los cuestionarios se utilizan frecuentemente cuando hay un gran nmero de
personas procedentes de
Ellos informacin y opiniones son necesarias. En nuestra experiencia, los
cuestionarios son
Se utiliza comnmente para sistemas destinados para uso fuera de la organizacin
(por ejemplo, por
Los clientes o proveedores) o para sistemas con muchos usuarios repartidos por
negocios geographic

Ubicaciones. La mayora de la gente piensa automticamente cuando piensan de

papel de
Los cuestionarios, pero hoy ms cuestionarios se distribuye en formato electrnico
Formulario, ya sea va e-mail o en la Web. Distribucin electrnica puede ahorrar
una importante
Cantidad de dinero, en comparacin con la distribucin de cuestionarios en papel.
La seleccin de los participantes como con entrevistas y sesiones de JAD, el
primer paso es
Seleccionar los individuos a quienes el cuestionario ser enviado. Sin embargo, no
es
Es habitual para seleccionar cada persona que podra proporcionar informacin til.
El estndar
Enfoque consiste en seleccionar una muestra o subconjunto de personas que son
representativas de la
Todo el grupo. Directrices de muestreo son discutidos en la mayora de las
estadsticas, y la mayora de libros
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 es, sin embargo, darse cuenta
de que no todo el mundo
Quien recibe un cuestionario realmente completar. En promedio, slo el 30%-50%
De papel y los cuestionarios por correo electrnico son devueltos. Las tasas de
respuesta basado en Web
Los cuestionarios tienden a ser considerablemente inferior (a menudo, slo el 5%30%).
Disear el cuestionario desarrollar buenas preguntas es crtico para
cuestionarios
Debido a que la informacin de un cuestionario no aclararse inmediatamente por
una confusa
Demandado. Preguntas sobre los cuestionarios deben ser muy claramente por
escrito y debe
Dejan 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
Opiniones. Dictamen las preguntas suelen pedir al demandado en la medida en
que acepta o
No estoy de acuerdo (por ejemplo, "son problemas de red comn?"), mientras que
las cuestiones fcticas buscar ms
Valores 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 recopilada en el cuestionario
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 tienen que leer las instrucciones para cada pregunta antes de contestar.
Generalmente es

Una buena prctica para agrupar preguntas relacionadas juntos para hacerlos ms
simples
Para contestar. Algunos expertos sugieren que los cuestionarios deben comenzar
con preguntas
Importante para los encuestados, por lo que el cuestionario inmediatamente
agarra su inters
Y los induce a responder. Quiz el paso ms importante es tener varios
Colegas a revisar el cuestionario y, a continuacin, pruebe con una pocas personas
Extradas de los grupos a los cuales se enviar. Es sorprendente cmo a menudo
aparentemente
Preguntas simples pueden ser malinterpretado.
Administrar el cuestionario la cuestin clave en la administracin del
cuestionario es
Haciendo que los participantes para completar el cuestionario y enviarlo de vuelta.
Docenas de marketing
La investigacin libros han sido escritos sobre maneras de mejorar las tasas de
respuesta. Comnmente
Utiliza tcnicas incluyen explicando claramente por qu el cuestionario est siendo
Realizado 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
contactando personalmente
Quienes no han regresado despus de una semana o dos, as como solicitar el
Los encuestados de los 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
Pidi recibir copias de los resultados a la mayor brevedad posible.

Anlisis de documentos

Los equipos de proyecto suelen utilizar el documento anlisis para entender el

sistema. Bajo
Las circunstancias ideales, el equipo del proyecto que desarroll el sistema
existente tendr
Producido 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 propio sistema.
Lamentablemente, la mayora de los sistemas no estn bien documentadas,
porque los equipos de proyecto
Dejar de documentar sus proyectos a lo largo del camino, y cuando los proyectos
son ms, hay
No hay tiempo para volver atrs y documento. Por lo tanto, no puede haber mucha
documentacin tcnica

Sobre el sistema actual disponible, o no puede contener informacin actualizada

Acerca de los recientes cambios en el sistema. Sin embargo, hay muchos
documentos tiles que hacer
Existe en la organizacin: papel informes, memorandos, manuales de polticas,
capacitacin de usuarios
Manuales, organigramas y formas. Los informes de problemas presentados por los
usuarios del sistema
Puede ser otra valiosa fuente 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 de la
organizacin
Utiliza. 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
Pueden cambiarse. Por ejemplo, formularios o informes que nunca se usan
probabilidades debe ser eliminado.
Asimismo, cajas o preguntas en formas que nunca se completan (o son usados
Para otros fines) deben ser repensadas. Consulte la Figura 3-10 para ver un
ejemplo de cmo un
El 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. Tales
Cambios demuestran claramente la necesidad de mejoras a los sistemas
existentes. As,
Es conveniente revisar tanto 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 poderosa

herramienta para ganar
Visin del sistema tal y como es. La observacin permite al analista para ver la
realidad de un
Situacin, en lugar de escuchar a los dems describirlo en entrevistas o sesiones
de JAD.