UNIDAD 4.

ANLISIS DEL
SISTEMA.
Determinacin y Especificacin de requerimientos
Los analistas al trabajar con los empleados de la empresa, deben estudiar el
proceso que se efecta actualmente para as poder contestar las preguntas claves de
esta fase.
Qu y cmo se est haciendo?
Qu tan frecuentemente ocurre?
Qu tan grande es la cantidad de transacciones?
Existe algn problema?, si el problema existe
Qu tan serio es y cul es su principal causa?

Para que el analista pueda contestar estas preguntas deber hablar con diferentes
grupos de empleados para as recabar diferente opiniones sobre las causas por las que
se originan las cosas. Los mtodos de recoleccin pueden ser cuestionarios a grupos de
personas o individuales, tambin se requiere estudiar los manuales y reportes, observar
los comportamientos y actividades, recabar formas y documentos para entender los
procesos. Una vez, recopilada la informacin, los analistas estudian los requerimientos
para identificar las caractersticas del nuevo sistema.
Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de
informacin, tienen que profundizar en un rea de la Organizacin, de la cual tienen poco
conocimiento. Del trabajo del analista se espera que se produzca una mejora en el
sistema. As que el analista debe ser capaz de:
a) Aprender los detalles y procedimientos del sistema en uso.
b) Prever necesidades futuras de la Organizacin, en funcin del crecimiento,
cambios futuros en el sector, introduccin de nuevas tecnologas etc.
c) Documentar detalles del sistema actual para su comprensin y discusin por otros
profesionales de la organizacin.
d) Evaluar la efectividad y eficiencia del sistema actual y sus procedimientos.
e) Recomendar modificaciones del sistema actual, o proponer un nuevo sistema
completo, justificndolo en cada caso.
f) Documentar las caractersticas del nuevo sistema con un nivel de detalle que
permita comprender a otros sus componentes.
g) Fomentar la participacin de gerentes y empleados en todo el proceso.

A todas estas tareas, se les une la de cumplir los plazos establecidos. De modo
que una de las claves del xito ser la de estructurar el proceso para el desarrollo del
nuevo sistema.
Requerimiento.
En la ingeniera de sistemas, un requerimiento es una necesidad documentada
sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido
formal en la ingeniera de sistemas o la ingeniera de software.
En la ingeniera clsica, los requerimientos se utilizan como datos de entrada en la
etapa de diseo del producto. Establecen QU debe hacer el sistema, pero NO CMO
hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de
anlisis conceptual del proyecto. Esta fase puede dividirse en recoleccin de
requerimientos de los inversores, anlisis de consistencia e integridad, definicin en
trminos descriptivos para los desarrolladores y un esbozo de especificacin, previo al
diseo completo.
Qu es un Requerimiento?
Condicin o capacidad que un usuario necesita para poder resolver un problema o
lograr un objetivo (IEEE).
Condicin o capacidad que debe exhibir o poseer un sistema para satisfacer un
contrato, estndar, especificacin, u otra documentacin formalmente impuesta
(IEEE).
Una condicin o capacidad que debe ser conformada por el sistema (RUP).
Algo que el sistema debe hacer o una cualidad que el sistema debe poseer
(Robertson -Robertson).
Tipos de Requerimientos.
En ingeniera de sistemas existen tres tipos de requerimientos.
Un requerimiento funcional puede ser una descripcin de lo que un sistema debe
hacer. Este tipo de requerimiento especfica algo que el sistema entregado debe
ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo
sobre el propio sistema, y cmo debe realizar sus funciones. Algunos ejemplos de
aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad
de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al
producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo
hasta la adecuacin a leyes o regulaciones aplicables al producto.

Una coleccin de requerimientos describe las caractersticas o atributos del
sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto debe
ser decidido en la etapa de diseo por los diseadores.
En la ingeniera de software se aplica el mismo significado, slo que el nfasis
est puesto en el propio software.
Caractersticas de los Requerimientos.
Los requerimientos bien formulados deben satisfacer varias caractersticas. Si no
lo hacen, deben ser reformulados hasta hacerlo.
Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
No ambiguo: El texto debe ser claro, preciso y tener una nica interpretacin
posible.
Conciso: Debe redactarse en un lenguaje comprensible por los inversores en
lugar de uno de tipo tcnico y especializado, aunque an as debe referenciar los
aspectos importantes
Consistente: Ningn requerimiento debe entrar en conflicto con otro requerimiento
diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos
requerimientos debe ser consistente tambin.
Completo: Los requerimientos deben contener en s mismos toda la informacin
necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle.
Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser
alcanzado con el dinero, el tiempo y los recursos disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue
satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis,
demostracin o testeo.

Estas caractersticas suelen ser subjetivas, es decir, no pueden ser calculadas de
forma automtica por ningn sistema. Por ello, se tiende a medir otras mtricas o
indicadores que s que pueden ser calculados de forma automtica y que, de algn modo,
pueden sustituir o mapear con esta lista de caractersticas.
Determinacin de requerimientos
Determinar requerimientos consiste en estudiar un sistema para conocer cmo
trabaja y donde es necesario efectuar mejoras.
Un requerimiento es una caracterstica que debe incluirse en el nuevo sistema.
Esta puede ser la inclusin de determinada forma para capturar o procesar datos, producir
informacin, controlar una actividad de la empresa o brindar soporte a los directivos.
Los analistas de sistemas no trabajan como directivos o empleados de los
departamentos de usuarios, no tiene los mismos conocimientos, hechos y detalles que los
usuarios y directivos de estas reas. Por lo tanto el primer paso del analista es
comprender la situacin.
El primer paso del analista es comprender la situacin actual.
Actividades de la Determinacin de Requerimientos
a. Anticipacin de Requerimientos
Prever las caractersticas del sistema con base en la experiencia previa. Esto
puede llevar al analista a investigar reas y aspectos que de otra forma no seran
tomados en cuenta.
La experiencia permite anticipar requerimientos para el nuevo sistema.
b. Investigacin de Requerimientos
Estudio y documentacin del sistema actual utilizando para ello tcnicas para
hallar hechos, anlisis de flujos de datos y anlisis de decisin.
Es la actividad ms importante.
c. Especificacin de Requerimientos
Anlisis de los datos que describen el sistema para determinar qu tan bueno es
su rendimiento, qu requerimientos deben satisfacer y las estrategias para alcanzarlos.
Investigacin de Requerimientos.
Los analistas estructuran su investigacin en base a 4 preguntas:
i. Cul es el proceso bsico de la empresa?
Las siguientes preguntas se utilizan para adquirir la comprensin necesaria:
Cul es la finalidad de esta actividad en la empresa?
Qu pasos se siguen para llevarla a cabo?
Dnde se realizan estos pasos?
Quines los realizan?
Cunto tiempo tardan en efectuarlos?
Con cuanta frecuencia lo hacen?
Quines emplean la informacin resultante?

ii. Qu datos utiliza o produce este proceso?
Este paso consiste en detectar qu datos se utilizan para llevar a cabo cada
actividad.
iii. Qu frecuencia y volumen de proceso existe?
Los analistas deben investigar con cuanta frecuencia se repite una actividad. Esto
cambia mucho dependiendo de la actividad ya que por ejemplo el pago de la nmina se
repite mensualmente o semanalmente pero el pago de impuestos es anualmente.
La manera ms fcil de obtener esta informacin es identificar el objetivo de la
actividad, es decir, cul es la causa de la actividad.
El volumen de los procesos puede aumentar el tiempo de realizacin de las
actividades, es decir la cantidad total de pasos que puede constar una actividad puede
generar problemas aun ocurriendo con poca frecuencia.
iv. Qu controles utiliza para su realizacin?
La falta o debilidad de los controles es un descubrimiento importante en cualquier
investigacin del sistema. El analista debe examinar los mtodos de control preguntando:
Quin se encarga de comparar lo realizado con los estndares?
Cmo se detectan los errores?
Cmo se corrigen los errores?

Respuestas concisas a estas preguntas proporcionan un conocimiento amplio de
una actividad en particular y muestra tambin su objetivo. Pero analista no se detiene ah,
todava no existe informacin para comprender en su totalidad la actividad; ms bien lo
que se tiene son los antecedentes que permiten a los analistas formular preguntas ms
detalladas.
Durante la investigacin de requerimientos, debemos identificar muy claramente
los siguientes elementos:
procesos
flujos de datos entre procesos
datos de cada flujo de datos
almacenes de datos
datos de los almacenes de datos.

Para ello el cuestionario que se aplica debe requerir la siguiente informacin:
Nombre de la entidad
Nombre los campos
Descripcin
Fuente y sensibilidad (= seguridad)
Valor o importancia de los datos
Relaciones de los campos y entidades
Criterio de retencin y almacenamiento.
Obs.:
Preguntas clsicas para una determinacin de requerimientos.
I. Preguntas generales:
Cuntos empleados laboran para la organizacin en el rea que se pretende
desarrollar el sistema?; o sea, cuntos tienen relacin directa con el proyecto que
se est investigando?
Cules son las personas claves en el sistema? Por qu son importantes?
Existen obstculos o influencias de tipo poltico que afectan la eficiencia del
sistema?
Existen manuales de procedimientos, polticas o lineamientos de desempeo
documentados oficial o no oficialmente? Si los hay, Se cumplen en forma cabal
en el 100% de las ocasiones?, es decir, se respetan dichos procedimientos?
Existen mtodos para evadir el sistema?, Por qu se presentan?
Qu reas necesitan un control especfico?
Qu criterios se emplean para medir y evaluar el desempeo?

Por otra parte:
Existen actividades que considere podran mejorarse?, De qu manera?
Tiene alguna idea de actividades que podran implementarse para mejorar el
rendimiento del sistema en general?

II. Determinacin de procesos:
Cules son las principales actividades que se realizan en la organizacin y que
tienen relacin con el proceso que se est modelando?

III. Descripcin de cada proceso identificado
Qu es lo que da inicio a la actividad?
Cul es el objetivo de la misma?
Cunto tiempo se tarda en realizarla?
Qu retrasos ocurren o pueden ocurrir?
Qu mtodos se emplean para medir y evaluar el desempeo de esta actividad?
Se toman precauciones especficas de seguridad para la proteccin contra
alguna actividad impropia que se pudiera presentar?
Qu tan frecuente es el ciclo con el que se desarrolla dicha actividad?
De acuerdo al ciclo con el que se presenta la actividad, Cul es el volumen de
informacin que aqu se procesa?
Qu pasos, sub-procesos, o funciones constituyen la actividad? (describir la
actividad paso a paso)
Existe algn tipo de control desarrollado en el proceso en cuestin?

IV. Determinacin de datos (flujos y contenido de los flujos) - hacer la pregunta por
cada proceso o actividad identificada.
De dnde proviene la informacin que se utiliza en esta actividad? (fuentes)
Cules son especficamente los datos que recibe esta actividad? (detalles de
flujos)
De qu manera ingresan a este proceso? (flujos)
Qu tablas de referencia y diagramas u otros datos intervienen en la actividad?
(documentacin involucrada)
Qu informacin se genera en esta actividad? (producto de la actividad)
El resultado identificado anteriormente producto de los datos que se procesan
Hacia qu o quin van dirigidos?-persona o entidad- (destinos)
Con qu finalidad la utilizan?
Cules datos se conservan o almacenan en este proceso? Y en qu forma
quedan almacenados?
Existe informacin que se genera pero que no es utilizada nunca por nadie?
(partes extraas)

Para cada dato identificado:
Qu formato posee cada dato que interviene en esta actividad?
Para qu es usado?
Se interpone algn tipo de seguridad para la verificacin de la veracidad del dato
en mencin?
Qu tan importante es dicho dato?
Por cunto tiempo es importante mantener el dato en el sistema?

Por otra parte, si el sistema que se est investigando es para el soporte de
decisiones se deben, adems de las anteriores, formular otras preguntas para determinar
los requerimientos de las decisiones, un esbozo de las mismas bien podra ser:
Qu informacin se usa para tomar la decisin?
Cul es la fuente de esa informacin?
Qu sistemas transaccionales producen los datos utilizados en el proceso de
decisin?
Qu otros datos son necesarios y no es posible obtener del procesamiento de
transacciones?
Qu datos se originan en fuentes externas a la organizacin?
Cmo se deben procesar los datos para producir la informacin necesaria?
Cmo debe presentarse la informacin?

Una vez que se tenga recopilado el conjunto de hechos que se generan con
relacin al sistema que estamos modelando, es posible dar una especificacin de
requerimientos, mediante como se dijo un anlisis de los datos obtenidos durante la
recopilacin de hechos. Es despus de esto entonces, que se puede ya dar un conjunto
de requerimientos que nos servirn para modelar el sistema mediante un DFD y del que
surge el diagrama E-R.
Mtodo de trabajo para la recopilacin de informacin
La recopilacin de informacin, especialmente en un sistema grande y complejo,
puede ser una tarea ardua. La informacin se debe reunir siguiendo un camino
organizado para asegurar que no hay redundancias y que se recogen todos los detalles
del sistema. Para ello se debe consultar a todos los usuarios para asegurarse de que todo
problema del sistema, necesidad de usuario y objetivo est identificado. La bsqueda se
debe hacer de tal forma que se eviten los trabajos repetitivos y que un mismo usuario no
sea interrogado por diferentes analistas pidiendo la misma informacin.
Una de las actividades ms importantes para los participantes en desarrollo de
sistemas de informacin automatizados es la obtencin de informacin que permita
comprender el esquema de trabajo en donde se encuentra el sistema, por lo que, es
necesario identificar dnde y cmo es posible obtenerla. El dnde, se refiere a los lugares
en los cuales se encuentra disponible y que denominar fuentes que pueden ser internas
o externas al organismo y, el medio, son los instrumentos a travs de los cuales es
posible recopilarla.
Las fuentes de informacin se pueden clasificar en internas y externas, las
primeras, se encuentran disponibles dentro de la organizacin y las segundas, se refieren
a las fuentes de informacin que pueden ser localizadas fuera de la misma.
Fuentes de informacin internas
Informacin verdaderamente til en el desarrollo de sistemas de informacin
automatizados, se encuentra en las siguientes fuentes:
1) Sistema Actual.
El sistema actual es la fuente ms importante de informacin para los involucrados
en el desarrollo de los sistemas de informacin automatizados. A pesar del costo y tiempo
requeridos para obtener informacin acerca de su funcionamiento, presenta las siguientes
ventajas:
Conocerlo, permite al analista definir si el sistema es correcto, si solamente
requiere de pequeas modificaciones, si requiere de importantes cambios o bien,
si es necesario sustituirlo totalmente.
Al adentrarse en el funcionamiento del sistema actual el analista puede generar
ideas para el diseo.
Se conocen a profundidad, los recursos humanos, materiales y de equipo con los
cuales es posible implementar el nuevo sistema. Adems de la formacin
intelectual del elemento humano (Know how)).
En la fase de implementacin facilita las pruebas ya que el analista sabe cmo
eran las cosas.
Permite comparar el nuevo sistema con el anterior, establecer sus similitudes y de
con conocimiento, evitar la reaccin negativa al cambio.

2) Personas.
El recurso humano relacionado directamente con el sistema es el ms capacitado
para opinar sobre las fallas o beneficios de los procedimientos y por tanto, el que puede
ofrecer posiblemente las mejores opiniones sobre las mejoras necesarias al sistema
actual. Por otra parte, el elemento humano involucrado indirectamente con el sistema
actual puede aportar consideraciones importantes sobre el ambiente que rodea al
sistema.
3) Otros sistemas.
Los sistemas dentro de la organizacin que puedan relacionarse con el nuevo
sistema, proporcionan informacin sobre las caractersticas de los estndares de diseo
que el sistema deber adoptar, as tambin pueden aportar informacin valiosa en la fase
de anlisis para conocer las polticas institucionales respecto a hardware, software y
recursos humanos.
4) Documentos y archivos.
En todas las organizaciones, existen por escrito elementos que pueden permitir al
analista establecer el diseo del nuevo sistema en un marco acorde con el funcionamiento
de la organizacin. Estos elementos pueden ser reglamentaciones, polticas, estructura
organizacional, procedimientos, descripcin de funciones, etc. todos ellos generalmente
se encuentran en forma de manuales o reglamentos, los cuales es conveniente solicitar
para su anlisis desde la fase inicial del desarrollo de sistemas.
Los archivos integran documentalmente toda la informacin que se maneja en un
rea de trabajo. El analista de sistemas, debe recurrir a los archivos para obtener
informacin sobre el desarrollo normal del trabajo del rea en estudio, conociendo los
formatos usados, verificando su llenado, analizando sus problemas, etc.
Fuentes de informacin externas.
Otros sistemas similares al que se piensa desarrollar, los proveedores, los
clientes, los distribuidores, los cursos o los libros, pueden ser fuentes de informacin
valiosa para el diseo del sistema considerando que son algunos de los involucrados en
las operaciones de la organizacin y por tanto los que cuentan con informacin valiosa
para ser considerada.
1) Otros Sistemas.
Puede tenerse conocimiento de sistemas similares al que se encuentra en estudio,
estos sistemas pueden proporcionar informacin sobre factores importantes a considerar
tanto en el anlisis como en el diseo del sistema. Aunque no debe perderse de vista que
los sistemas se disean de acuerdo con las condiciones propias de cada organizacin.
2) Proveedores, clientes y distribuidores.
Tanto proveedores como distribuidores y clientes son personas relacionadas con
los procesos que se realizan en la organizacin, adems de que en el caso de clientes y
distribuidores son los que reciben el servicio final de la organizacin, por tanto, pueden
emitir opiniones interesantes y que sirvan de apoyo al analista sobre fallas o sugerencias
de mejoras que podra contemplar el nuevo sistema.
3) Libros e instructivos.
Los libros en los cuales algunos estudiosos de la materia presentan sugerencias
sobre determinados sistemas o sugerencias en base a su experiencia, pueden aportar
informacin valiosa para desarrollar mejor la tarea del analista. Adicionalmente, todas las
mquinas al adquirirse, proporcionan instructivos sobre su uso los cuales son otra fuente
de informacin con la cual se puede conocer con facilidad el equipo o software
actualmente en uso as como sus principales caractersticas.
4) Cursos o Seminarios.
Cuando el analista de sistemas acude a cursos o seminarios sobre el tema, puede
contar con informacin valiosa que le permita desarrollar su trabajo de manera
estructurada y por tanto con mayor facilidad.
Medios para la recopilacin de Informacin.
Hasta aqu, se han considerado las fuentes de informacin ms relevantes para el
analista de sistemas. Sin embargo, es necesario sealar los medios a travs de los cuales
la informacin puede ser recopilada de entre estas fuentes, los cuales pueden se
describen en las siguientes lneas.
I. Revisin de Documentos.
Uno de los medios ms importantes de recoleccin de datos, es la revisin tanto
de manuales, como de formas, procedimientos y en general de cualquier documento que
contenga informacin relevante para el desarrollo del sistema. La revisin de documentos
provee de informacin sobre errores que se cometan en los procesos normales de trabajo
y sobre las tareas que no se terminen por lentitud en el desempeo del trabajo. Los
documentos pueden ser revisados en su contenido cuantitativa y cualitativamente,
algunos ejemplos de los primeros son: informes financieros, informes de desempeo; la
revisin cualitativa puede hacerse a memorandos, avisos y manuales que ofrecen
informacin sobre la ideologa de la institucin. En esencia este medio permite obtener
informacin acerca de lo que es en contraposicin a lo que debera ser.
a) Formularios
Los formularios son transportes de datos y existen en todas las formas y tamaos.
Se usan para muy diversos propsitos, por ej.: pedidos de provisiones para un
restaurante, saldo de una cuenta bancaria, informe de fabricacin de ciertos artculos,
solicitudes de inscripcin, actas de exmenes, etc.
Se debe obtener una copia de cada formulario usado en el sistema, ya sea que se
origine dentro o fuera de la organizacin. El mejor modo de ver cmo se usa un
formulario, es obtener una copia del formulario vaco y otro lleno.
De cada formulario se debe conocer:
Cul es el objetivo del formulario?
Quin lo llena?
Dnde es enviado? De dnde viene?
Quin usa el formulario?
Qu autoridad lleva?
b) Muestreo
Esta tcnica consta de reunir slo un conjunto representativo de los datos. Por
ejemplo, en lugar de observar a 75 empleados llenando pedidos en una hora, tome una
muestra de 3 o 4 de ellos. O en casos de salidas impresas de mucho volumen, tal como
facturas a clientes, podra reunir una muestra al azar de algunas de ellas.
Es apropiada cuando hay un gran volumen de datos. Puede ser muy costoso
controlar todos los datos, pero la misma informacin puede obtenerse usando muestreo.
Saber cunto y qu dato seleccionar es un trabajo para especialistas que usan tcnicas
estadsticas.
II. Entrevista.
La entrevista es un medio de obtener informacin de las personas conocedoras a
travs de preguntas que propone el entrevistador, dicho de otra manera, es un
intercambio de informacin cara a cara, con un propsito especfico.
En el desarrollo de sistemas, la entrevista es el medio ms significativo y
productivo del que disponen los participantes en la recoleccin de informacin, adems,
tiene la ventaja de permitir que el analista entre en contacto desde el principio con las
personas involucradas en el uso del sistema y establezca relaciones de simpata con
ellas, lo cual es benfico para el desarrollo del estudio.
Como todo trabajo, el entrevistador debe planificar la entrevista antes de realizarla
y contemplar al menos los siguientes puntos:
1. Anlisis de antecedentes
2. Determinacin del objetivo de la entrevista
3. Seleccin de entrevistados
4. Preparacin del entrevistado
5. Seleccin y tipo de preguntas: Las entrevistas pueden efectuarse
estructuradamente o no.

Tipos de Entrevistas:
a. Entrevista estructurada: se refiere a que previo a la realizacin de la
entrevista, el entrevistador prepare la lista de preguntas que se van a
proponer.
b. Entrevista no estructurada: se refiere a que la entrevista se efecte de
manera libre, en forma de pltica durante la cual el entrevistador permitir
que espontneamente surja el tema de su inters.

Las ventajas y desventajas que presentan cada una de stas alternativas son:
Entrevista No Estructurada.
Ventajas
El entrevistador tiene mayor flexibilidad al realizar las preguntas.
El entrevistador puede explotar reas que surgen espontneamente durante la
entrevista.
Puede producir informacin sobre reas que se minimizaron o en las que no se
pens que fueran importantes.

Desventajas
Los entrevistadores pueden introducir sesgos en las preguntas o al informar de los
resultados.
Puede utilizarse negativamente el tiempo, tanto de quien responde como del
entrevistador.
El anlisis e interpretacin se dificulta y requiere de tiempo.
En general se necesita de ms tiempo para su desarrollo.

Entrevista Estructurada.
Ventajas.
Asegura la elaboracin uniforme de las preguntas para todos los que van a
responder.
Se necesita un limitado entrenamiento del entrevistador.
Fcil de administrar y evaluar. Los que responden pueden no aceptar un alto nivel
en la estructura y el carcter mecnico de las preguntas.
Resulta en entrevistas ms cortas en tiempo.
Evaluacin ms objetiva tanto de quienes responden como de las respuestas a las
preguntas.

Desventajas
Alto costo de preparacin
Un alto nivel en la estructura puede no ser adecuado para todas las situaciones.
El alto nivel de la estructura reduce responder en forma espontnea, as como la
habilidad del entrevistador para continuar con comentarios hacia el entrevistado.

Cuando la entrevista es estructurada, es conveniente ocuparse del tipo de
preguntas a usar las cuales dependiendo de la forma en que se espera una respuesta
pueden ser: abiertas, cerradas o mixtas. En las primeras, la respuesta se expresa
libremente (son tiles para explorar el problema), en las segundas, la respuesta se
presenta en forma opcional de entre una serie de alternativas propuestas y por ltimo el
tercer tipo es una combinacin de las dos anteriores.
Obs.:
A continuacin se describen algunos factores a considerar Antes, Durante y
Despus de realizar una entrevista:
Antes de La Entrevista.
1. Organizar y preparar la entrevista considerando:
a. La posicin que ocupa en la organizacin el futuro entrevistado
b. Las actividades bsicas y responsabilidades del futuro entrevistado
c. Preparar las preguntas que van a plantearse y los documentos de apoyo
necesarios.

2. Confirmar la cita
3. Conseguir que alguien lo introduzca.
4. Llegar temprano.
5. Vestirse adecuadamente

Durante la Entrevista.
1. Al efectuar la entrevista tomar en cuenta los siguientes pasos :
a. Comenzar por presentarse y sealar la naturaleza del proyecto sobre el
cual se est trabajando, sus propsitos y sus objetivos.
b. Explicar la funcin del analista y lo que se espera del entrevistado
2. En relacin al comportamiento del entrevistador durante el desarrollo de la
entrevista se recomienda:
a. Ser un buen escucha. Escuchar atentamente y no anticiparse a las
respuestas. Dejar hablar al entrevistado.
b. No probar reacciones.
c. No creer que sabe ms que el entrevistado porque el experto es l.
d. Evitar terminologa tcnica, como por ejemplo hablar de cerebros
electrnicos, sistemas operativos, UNIX, LINUX, memoria RAM, campos de
la base, SQL, compilar, etc.
e. Conservar el control de la entrevista evitando divagaciones y comentarios
al margen de las preguntas.
f. Evitar externar opiniones o crticas cuando se encuentren fallas o
deficiencias.
g. No juzgar los hechos.
h. Evitar dar sugerencias.
i. No tomar decisiones.
j. No entrar en polmica con el entrevistado.
k. Seguir las reglas de cortesa y de trato amable como: ser puntual, corts,
calmado, paciente, profesional, mostrar inters fijando la vista en el
entrevistado, preguntar cuando no se entienda algo, ser amigable (pero no
demasiado).
l. No despreciar el trabajo del entrevistado ni humillarlo presentndole formas
complejas y desconocidas para l o cuestionarios con tecnicismos.
m. Si el entrevistado externa fatiga o inquietud, dar por terminada la entrevista
aunque no de manera cortante.
3. Al final de la entrevista resumir para confirmar la informacin con el entrevistado y
verificar que se han considerado todos los temas preparados.
4. Expresar al entrevistado agradecimiento por la ayuda proporcionada, concertar
una nueva cita o bien, dejar la puerta abierta de ser necesario.
5. Ofrecer al entrevistado el resumen de la entrevista.

Despus de la Entrevista.
1. Escribir lo recopilado, analizarlo y obtener conclusiones
2. Verificar si hay confusiones.
3. Reportar los resultados y enviar una copia al entrevistado solicitando su
confirmacin, correcciones o adiciones.
4. De ser necesario solicitar nuevamente cita.
5. Archivar los resultados de la entrevista para referencias posteriores.

III. Cuestionario.
El cuestionario es una tcnica que permite recoger opiniones, posturas, conductas
y caractersticas de personas o situaciones a travs de un conjunto de preguntas
formalizadas en un documento. Las preguntas pueden ser abiertas, cerradas o mixtas (ver
entrevista). En el desarrollo de sistemas, el uso del cuestionario es limitado a aquellos
casos en los que la entrevista no puede ser utilizada debido a la distancia fsica o bien,
cuando el grupo del cual se obtendr la informacin es numeroso (grupo de vendedores)
o como posible medio de verificacin de la informacin obtenida por otros medios.
Obs.:
En la elaboracin de un cuestionario, es necesario definir:
1. Qu datos se desean conocer (Objetivo) y quines son las personas ms
calificadas para proporcionarlos.
2. Seleccionar el tipo de preguntas ms adecuadas: abiertas, cerradas o mixtas.
3. Desarrollar un conjunto de preguntas (considerando la forma de anlisis de las
respuestas (tabulacin manual o electrnica)).
4. Revisar el cuestionario para encontrar fallas o defectos como pueden ser :

a. Interrogantes innecesarias
b. Preguntas que puedan malinterpretarse
c. Preguntas que no se puedan responder
d. Preguntas que llevan a determinada respuesta
e. Preguntas mal establecidas que lleven a varias respuestas
f. Falta de opciones en preguntas cerradas
g. Desorden en la secuencia de preguntas
h. Falta de espacio para responder
i. Tendencia central, indulgencia y efecto de halo al usar escalas

5. Probar el cuestionario
6. Analizar las respuestas del grupo de prueba y realizar correcciones
7. Realizar cambios finales de edicin y de presentacin.
8. Aplicar el cuestionario considerando :
a. Distribuir el cuestionario de ser posible con los nombres de cada persona
(solamente si la informacin no implica compromisos).
b. Distribuir el cuestionario con una explicacin del propsito del mismo, as
como del uso que se dar a las respuestas y si es necesario especificar el
carcter confidencial de las respuestas.
c. Agradecer la sinceridad de las respuestas remarcado la importancia de las
mismas.
d. Considerar de ser necesario instructivo para el llenado del cuestionario.
e. Establecer de forma amable el tiempo lmite para la devolucin del
cuestionario.

9. Codificar y capturar la informacin.
10. Analizar la informacin recopilada

IV. Observacin.
La observacin es una tcnica que permite obtener informacin en forma directa a
travs del sentido de la vista. Permite al observador determinar qu se est haciendo,
cmo se est haciendo, quin lo hace, cundo se realiza, cunto tiempo ocupa en
realizarse, dnde se hace y por qu se hace.
La observacin, brinda informacin al observador acerca de las diferencias entre lo
que debera suceder de acuerdo con los procedimientos normales de operacin, controles
establecidos, requisicin de formas y perodo de tiempo para la realizacin de alguna
tarea en particular y lo que realmente ocurre como puede ser: retraso al hacer el trabajo,
etapas de procedimientos omitidas, trabajo extra innecesario, documentos mal
requisitados, informacin manejada de memoria, informacin sin archivar, etc.
Existen varios mtodos de llevar a cabo la observacin. Se puede observar alguna
persona o actividad sin que el observado se d cuenta y sin que el observador realice
ninguna interaccin con el observado, tambin se puede observar sin intervenir el
observador pero con pleno conocimiento por parte del observado y por ltimo, se puede
observar y a la vez estar en contacto con la persona observada.
Obs.:
Para obtener mejores resultados del proceso de observacin, es conveniente
considerar los siguientes lineamientos:
1. Determinar lo que se va a observar
2. Estimar el tiempo necesario de observacin
3. Obtener autorizacin para efectuar la observacin (por parte del jefe)
4. En su caso, explicar a las personas que van a ser observadas lo que se va a llevar
a cabo y las razones para hacerlo.
5. Desarrollar la observacin considerando:

a. Familiarizarse con los componentes fsicos del rea en observacin
b. Mientras se observa, tomar el tiempo en forma peridica
c. Anotar lo que se observa de manera especfica evitando generalidades y
descripciones vagas (ser objetivo).
d. Si se est en contacto con las personas observadas, evitar hacer
comentarios de cualquier tipo.
e. Observar las reglas de educacin y seguridad en su caso.

6. Documentar y organizar formalmente las notas de la observacin.
7. Es conveniente, revisar al final de la observacin, los resultados y conclusiones de
la misma tanto con las personas observadas como con sus superiores inmediatos.

Como un comentario general, a las personas no les gusta ser observadas por lo
cual tienden comportarse de manera distinta a la que normalmente lo hacen, por ello, se
recomienda que la observacin se utilice conjuntamente con algn otro medio de
recopilacin de datos como puede ser la entrevista (con la finalidad de prepararla o bien,
de estructurarla).
La observacin es costosa ya que requiere de tiempo y experiencia por parte del
observador.
En realidad la observacin es ms efectiva cuando se realiza en niveles operativos
ya que en stos niveles las actividades que se realizan son de tipo repetitivo y
generalmente no involucran el proceso de decisin el cual es a veces es ms fcil de
entender a travs de otros medios como por ejemplo el de la entrevista.
Especificacin de Requerimientos.
Es un proceso de representacin que est basado en los siguientes principios:
Separar funcionalidad de implementacin: la especificacin es una descripcin de
lo que se desea, en vez de como se implementa.
Se necesita un lenguaje de especificacin de sistemas orientado al proceso, que
es un modelo de comportamiento deseado en trminos de respuestas funcionales
a distintos estmulos de entorno.
Una especificacin debe abarcar el sistema del cual el software es una
componente. Solo dentro del contexto del sistema completo y de la interaccin
entre las partes puede ser definido el comportamiento de una componente
especfica.
Una especificacin debe abarcar el entorno en el que el sistema opera.
Una especificacin de sistema debe ser un modelo cognitivo, que es la descripcin
del sistema tal como es.
Una especificacin debe ser operacional, en el sentido de ser lo suficientemente
completa y formal como para poder evaluar diferentes alternativas de
implementacin.
Una especificacin del sistema debe ser tolerante con la incompletitud y
complementable.
Una especificacin debe ser localizada y dbilmente acoplada frente a las posibles
modificaciones a sta.
El formato de representacin y el contenido deben ser adecuados al problema.
Debe aadirse la informacin contenida dentro de una definicin, en capas de
informacin para representar el nivel de detalle adecuado para comprenderla.
Debe restringirse el nmero de formas notariales y ests deben ser consistentes
en su uso.
Las representaciones deben ser revisables.