TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 20

TEMA III

ANALISIS Y DETERMINACION DE REQUERIMIENTOS

3.1. ESPECIFICACIONES DE REQUERIMIENTOS

La determinación de requerimientos es la etapa más importante en el desarrollo de un sistema de

información. Comienza después de que el Cliente ha detectado una ausencia, o falta de información o
simplemente, luego de que la organización ha determinado un cambio en sus políticas, reglas o tecnologías
a aplicar.

En esta etapa, se debe responder a la pregunta fundamental: ¿Qué es lo que quiere el Cliente? y para
ello, se debe diagnosticar la Situación Actual, recopilar los requerimientos del Cliente, tanto en relación al
Sistema, es decir la Situación Ideal, para así poder definir Alternativas de Solución, según las cuales se
podrá avanzar desde lo que hoy se posee, hacia el objetivo que se quiere alcanzar. Estudiar la situación
actual, consiste en estudiar el sistema actual a fin de encontrar como trabaja y de donde debe mejorarse.

3.2. DEFINICIÓN DE REQUERIMIENTO

Según la Real Academia Española, un requerimiento se define como la acción y efecto de requerir, donde
requerir significa tener precisión o necesidad de alguien o algo. Hablando ya en términos de Ingeniería de
Software, según la IEEE un requerimiento se define como:

a) Condición o capacidad que necesita el usuario para lograr un objetivo o solucionar un problema.
b) Una condición o capacidad que debe tener el sistema para satisfacer un contrato, estándar,
especificación de Software u otro documento formal.

Según Young, un requerimiento es un atributo necesario para el sistema a desarrollar, en el cual se puede
describir una funcionalidad o característica que tenga valor para los stakeholders dentro del mismo. La
información para estas características se puede encontrar dentro de muchas personas o departamentos
dentro de la organización que participan proporcionando información para el desarrollo del sistema.

Todos los requerimientos tienen características que los Ingenieros de Requerimientos deben tener en
cuenta para que sean tomados como requerimientos válidos para la construcción de un sistema,
independientemente del tipo al que pertenezcan estos, es decir, particularidades generales para todos los
documentos correspondientes a Requerimientos. Estos rasgos son los siguientes

Característica Descripción

No Ambiguo El requerimiento debe ser conciso, debe expresar hechos objetivos vitales para el
desarrollo. Solo puede tener una posibilidad de interpretación.

Completo El requerimiento debe estar totalmente declarado, sin información faltante.

Correcto El requerimiento debe cumplir con la necesidad expresada por el usuario para la
solución de desarrollo.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 21

Entendible Si se comprende fácilmente el significado de todos los requerimientos con una

mínima de la explicación.

Verificable La implementación del requerimiento debe poder ser seguida a través del
desarrollo del sistema. Deben existir las técnicas finitas y rentables para verificar
que cada requerimiento satisface el sistema según lo construido.

Ningún subconjunto de requerimientos individuales está en conflicto. Posible por

Consistencia Interna medio de mapeo de entradas, salidas y estados.

Consistencia Externa Ningún requerimiento está en conflicto con la documentación interna de la

organización.

Realizable El requerimiento debe ser posible de implementar y no ser un hecho utópico

dentro de la etapa de desarrollo.

Conciso Ser tan cortos como sea posible sin afectar los demás requerimientos.

Independiente del diseño Implementación con diferentes métodos para un mismo objetivo.

Detectable El requerimiento debe estar escrito de manera que se facilite referenciarlo

individualmente.

Modificable Si la estructura y estilo del requerimiento se puede cambiar fácil, completa y

constantemente.

Anotado por importancia Si se pueden determinar fácilmente cuales requerimientos son los más importantes
relativa
para el cliente.

Anotado por estabilidad Si se puede determinar fácilmente cuales requerimientos tengan más probabilidad
relativa
de cambio.

Anotado por versión Si se puede determinar fácilmente cual versión del producto satisface cual
requerimiento.

No redundante Si el requerimiento no está en varias partes del sistema.

Preciso Si en el requerimiento se usan las cantidades numéricas siempre que sean posibles.
A su vez se asegura que estos niveles de precisión se utilizan apropiadamente para
cada cantidad numérica.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 22

Trazabilidad Si el origen del requerimiento es limpio y cuenta con constante referencia a través
del proceso.

3.3. ANALISIS DEL SISTEMA ACTUAL

Los analistas estructuran su investigación y buscan respuestas a las siguientes cuatro interrogantes
principales:

A. ¿Cuál es el proceso básico del área en estudio?

B. ¿Qué datos utiliza o produce este proceso?
C. ¿Qué frecuencia y volumen del proceso existe?
D. ¿Qué controles utiliza para su realización?

Estudiamos por separado cada una de estas cuatro preguntas:

A. ¿Cuál es el proceso básico del área en estudio?

Se empezará con lo básico. Se harán aquellas preguntas que proporcionarán cuando se contesten, un
antecedente de los datos fundamentales y de las descripciones del sistema.

Las siguientes preguntas ayudaran a adquirir el conocimiento necesario.

a) ¿Cuál es la finalidad (propósito) de esta actividad en la empresa?

b) ¿Qué pasos se siguen para llevarla a cabo?
c) ¿Dónde se realiza esos pasos?
d) ¿Quién los realiza?
e) ¿Cuánto tiempo tardan en efectuarlos?
f) ¿Con que frecuencia se realiza?
g) ¿Quién utiliza la información resultante?

Ejemplo: Supóngase que se investiga un sistema de reabastecimiento de inventarios, tema sobre el

cual se conoce muy poco ¿Dónde se comenzaría? A continuación, se listan respuestas breves a las
preguntas básicas del sistema. Estos son los de respuestas que se deberían buscar para cualquier
sistema que se estudie.

a. ¿Cuál es la finalidad del sistema de reabastecimiento de inventarios?

Asegurar que cantidades adecuadas de existencias y materiales están disponibles para su uso, sin
tener que manejar una cantidad excesiva y por lo tanto costosa.

b. ¿Que pasos se siguen para reabastecer el inventario?

Comprobar las existencias actuales y determinar las necesidades futuras y los tiempos óptimos
para solicitar los pedidos.

c. ¿Dónde se realiza esta actividad?

El departamento de compras utiliza la información proporcionada por el personal de producción,
ventas y almacén para hacer los pedidos y poder tomar decisiones anticipadas.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 23

d. ¿Quienes realizan esta actividad?

Los directores de compras aprueban todos los pedidos. Los directores de almacén integran las
instrucciones de compra y escriben solicitudes de pedidos.

e. ¿Cuánto tiempo tarda esta actividad?

Para pedidos simples y rutinarios tarda unos minutos y para pedidos de artículos nuevos o de
determinadas características puede tardar un par de horas.

f. ¿Con cuánta frecuencia se realiza esta actividad?

Este es un proceso continuo donde siempre se están pidiendo artículos diferentes.

g. ¿Quién utiliza la información resultante?

El resultado de la información producida es un subproducto de este proceso y se utiliza en el
manejo de inventario, los servicios que calendariza producción, control y seguimiento de compras y
pagos a proveedores. También se usa para cubrir los requerimientos inesperados de compra y la
información de reabastecimiento de inventarios.

Nótese que tan rápido las respuestas a estas preguntas proporcionan en un entendimiento más amplio
de lo que el reabastecimiento de inventarios y muestra que su objetivo no es más que comprar
existencias (reabastecimiento de productos).

Sin embargo, el análisis no puede detenerse aquí. Simplemente no existe suficiente información
todavía para entender por completo el proceso de volver a solicitar inventarios: en lugar de esto,
antecedentes adquiridos permiten al análisis preguntas más detalladas.

B. ¿Qué datos utiliza o produce este proceso?

Este paso consiste en detectar qué datos se utilizan para llevar a cabo cada actividad. Ejemplo:
Reabastecimiento de inventarios

C. ¿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 nómina se repite mensualmente o
semanalmente pero el pago de impuestos es anualmente.

La manera más fácil de obtener esta información es identificar el objetivo de la actividad, es decir, cuál
es la causa de la actividad.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 24

El volumen de los procesos puede aumentar el tiempo de realización de las actividades, es decir la
cantidad total de pasos que puede constar una actividad puede generar problemas aun ocurriendo con
poca frecuencia.

Ejemplo: Reabastecimiento de inventarios

¿Qué frecuencia y volumen de proceso existe?

Su frecuencia es de forma continuada pero el volumen de artículos manejados puede ser que
aumente el tiempo necesario para completar la actividad.

D. ¿Qué controles utiliza para su realización?

La falta o debilidad de los controles es un descubrimiento importante en cualquier investigación del

sistema.

El analista debe examinar los métodos de control preguntando:

 ¿Quién se encarga de comparar lo realizado con los estándares?

 ¿Cómo se detectan los errores?
 ¿Cómo se corrigen los errores?

Ejemplo: Reabastecimiento de inventarios

¿Qué controles utiliza para su realización?

Tanto dirección de almacén como el personal del mismo llevan un seguimiento del proceso
mediante un registro manual de forma diaria, por lo tanto, existe un control, pero este presenta
errores como ser la perdida de información.

3.6. INGENIERÍA DE REQUERIMIENTOS

Una vez que se tienen identificado todo el proceso del sistema actual, y las características que deben
cumplir un requerimiento, se puede comenzar con la descripción de las actividades que ayudarán a realizar
una buena obtención de requerimientos. No vamos a descubrir como es el proceso, este ya está más que
definido, solo hay que aprender a llevarlo adecuadamente.

A este conjunto de actividades de le denomina Ingeniería de Requerimientos, el cual cumple un papel

primordial en el proceso de Desarrollo de Software, es la que puede apoyar para lograr proyectos
exitosos, ya que se enfoca un área fundamental: la definición de lo que se desea producir. Su principal
tarea consiste en la generación de especificaciones correctas que describan con claridad, sin
ambigüedades, en forma consistente y compacta, el comportamiento del sistema.

Este proceso comprende cinco actividades de alto nivel:

 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 25

 Obtención de Requerimientos

Es el primer paso en la Ingeniería de Requerimientos, y es el proceso en el cual se recolecta la

información necesaria para comenzar a entender el problema a resolver, e identificar qué es lo que el
cliente necesita para poder empezar a definir el rumbo del proyecto a realizar. Es la parte más
importante del proceso ya que todo lo que se obtenga en esta fase será la base para la construcción
del sistema.

Además de ello, se hace en una junta llamada kick off o de arranque, donde se debe especificar lo
siguientes:

 Objetivo del sistema, y fechas tentativas del inicio y fin del proyecto
 Presentación del Equipo de Trabajo
 Presentación o definición de stakeholders (involucrados en la definición de los requerimientos y
líder funcional, que es quien hace la autorización de los documentos en nombre de todo el
equipo del cliente)
 Fechas tentativas de reuniones con el cliente (esto se usa cuando es una consultoría es la que
presta el servicio al cliente)

 Análisis de Requerimientos

Es el segundo paso que dicta la Ingeniería de Requerimientos, implica refinar, analizar, y

examinar/escudriñar los requerimientos obtenidos para asegurar que todos los stakeholders
involucrados entiendan lo que pidieron, y para encontrar errores, omisiones y otras deficiencias.

Las actividades a contemplar durante esta etapa son:

 Reducir ambigüedades en los requerimientos. En esta actividad se realizan las tareas que
permiten eliminar los términos que tienen más de una acepción, unificando el léxico empleado.
 Traducir a lenguaje técnico los requerimientos. Los requerimientos, ya con menos
ambigüedades, deben ser tratados a los efectos de llevarlos a un lenguaje que se vaya
aproximando al lenguaje técnico.
 Plantear un modelo lógico. Se debe construir un modelo del problema ya sea en términos de
diagramas de flujo o cualquier otro tipo de representación que se considere conveniente para el
modelado y que permita, además, establecer un vínculo con la Etapa de Especificación.

 Especificación de Requerimientos

La especificación de requerimientos consolida los resultados de la obtención y el análisis de

requerimientos. Es una descripción de lo que los usuarios del sistema esperan de éste, el ambiente en
que se desarrollara, los parámetros de desempeño y la calidad y efectividad deseados. El resultado de
esta etapa es un documento denominado SRS (Software Requirements Specification), el cual describe
por completo el comportamiento del sistema (requerimientos funcionales y no funcionales), mas no
condiciones de diseño, planeación, implementación y pruebas de la solución

 Verificación de Requerimientos

El proceso de verificación consiste en evaluar la exactitud, completitud y consistencia de cada uno de

los requerimientos que fueron especificados, con el fin de asegurar que el sistema que se va a construir
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 26

satisfará las necesidades y expectativas de los usuarios. Se define también como el proceso de
examinar el documento de requerimientos para garantizar que se define el software adecuado.
Además de esto, se debe generar un criterio de verificación para la arquitectura del sistema, el cual
asegure que los costos, el cronograma y los requerimientos de rendimiento sean satisfechos. Aquí un
ejemplo de puntos a revisar en los documentos obtenidos:

 ¿Están incluidas todas las funcionalidades requeridas por el cliente? (completa).

 ¿Existen conflictos en los requerimientos? (consistencia)
 ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
 ¿Esta cada requerimiento claramente representado? (entendible)
 ¿Puede ser los requerimientos implementados con la tecnología y presupuesto disponible?
(factible)
 ¿Está la especificación escrita en un lenguaje apropiado? (clara)
 ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
 ¿Está claramente definido el origen de cada requerimiento? (rastreable)
 ¿Pueden ser los Requerimientos ser sometidos a pruebas cuantitativas? (verificable)

 Aceptación de Requerimientos

Este es un proceso donde los analistas involucrados se reúnen con el cliente y comienzan a dar una
revisión formal al documento, esto es, comenzar a leer y explicar cada requerimiento, incluso se
pueden apoyar nuevamente en prototipos en papel para que quede más claro el funcionamiento, esto
con el fin de que todos estén en el mismo entendido de lo que se realizará para cada requerimiento.
Una vez que todos estén de acuerdo se hace la aceptación/aprobación de la especificación de
requerimientos, se realiza un compromiso formal de que lo contenga la Especificación será lo que se
construya y se pide al cliente una aprobación formal vía correo electrónico o una firma sobre el
documento físico.

 Administración de Requerimientos

La administración de requerimientos se realiza durante todo el proyecto, esto implica llevar un buen
control de los cambios, además se debe asegurar de hacerle ver al cliente el impacto en costo y/o el
tiempo de entrega del proyecto, pero también se debe cuidar como aplican estos cambios a los
entregables que se tiene programado, según la etapa donde se den.

Otro punto importante es que se debe asegurar de que todas las actividades del proyecto se den en
tiempo para no causar retrasos en la entrega. Se recomienda tener especial atención en cuidar las
versiones de documentos
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 27

3.4. TIPOS DE REQUERIMIENTOS

a) REQUERIMIENTOS DE NEGOCIO

Son aquellos requerimientos que representan los objetivos establecidos por la organización. Son la base
principal para el desarrollo del proyecto porque describen las necesidades que el Software cubrirá sin
descuidar las reglas de negocio de la organización. A menudo estos requerimientos reflejan las prácticas
de negocio actual de la organización o las nuevas prácticas que desean adoptar con el proyecto, ya que
ellos deben asegurarse que el producto se ajuste a sus necesidades. Algunas veces estos requerimientos
coinciden con las expectativas que tienen los usuarios, pero estos son más vistos a nivel técnico. La
Grafica explica el proceso de transformar las reglas de negocio en requerimientos, en donde intervienen
desde los expertos del negocio, que son los que tienen la información, hasta los analistas de Sistemas que
son los que la interpretan, pasando por un comité ejecutivo de la organización quien es la que avala la
información que se va a proporcionar al analista.

b) REQUERIMIENTOS DE USUARIO

Los usuarios son los individuos o grupos de ellos a quien va dirigido el sistema. Por tal motivo estos
requerimientos son aquellas funciones específicas que los usuarios esperan ver en la solución. Los
usuarios se identifican por medio de los requerimientos de negocio, como ya se explicó en la sección
anterior y a su vez es el resultado del proceso de levantamiento de Requerimientos. Los requerimientos de
usuario deben ser descritos de tal forma que sean fácil de entender por parte de los usuarios, teniendo en
cuenta que ellos no manejan el lenguaje técnico que es de gran dominio por el equipo desarrollador. Aparte
de estar explicados en lenguaje natural para un mejor entendimiento también se pueden presentar
diagramas con bajo nivel de detalle. Otra cosa importante es que solo se manejará el documento de
requerimientos para estos, ya que solo se debe describir el comportamiento del sistema, mas no aun el
detalle que tendría un diseño o prototipo
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 28

c) REQUERIMIENTOS DEL SISTEMA

Son descripciones más detalladas de los requerimientos del usuario. Estos ya tienen cierto nivel de detalle
avanzado y son la base para empezar la fase de diseño del sistema. Estos requerimientos hacen referencia
hacia los requerimientos funcionales y no funcionales, los cuales se describen a continuación:

1) REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales describen lo que el sistema o software debe hacer. Estos siempre se
refieren a funciones específicas que debe hacer la solución, todo en base a las indagaciones hechas
en el proceso de levantamiento de requerimientos y su respectivo análisis en las definiciones de
Requerimientos de Negocio y Requerimientos del Sistema. Son las necesidades de los Stakeholders
que requiere que el Sistema deba de cumplir de manera satisfactoria.

Young define también estos requerimientos como operacionales, ya que especifica las entradas y
salidas del sistema junto con todas las relaciones entre ellas.

Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general
mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus
entradas y salidas, excepciones, etc.

2) REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales especifican propiedades o cualidades del sistema, como pueden ser
la seguridad y la fiabilidad del sistema. Las mismas que los Stakeholders esperan como parte del
comportamiento del sistema de Software.

Los requerimientos no funcionales son propiedades que las funciones del sistema deben tener. Por
ende, no pueden existir requerimientos no funcionales sin que haya requerimientos funcionales. Son
requerimientos que pueden definirse con un valor especificado por el analista de Sistema, es decir, se
pueden aplicar criterios para revisarlos según la solución que se esté elaborando.

Algunos ejemplos de aspectos solicitados son:

 Rendimiento del sistema: Fiabilidad, tiempo de respuesta, disponibilidad…

 Interfaces: Dispositivos de E/S, usabilidad, interoperabilidad…
 Proceso de desarrollo: Estándares, herramientas, plazo de entrega…

A continuación se describen más a fondo los tipos de requerimientos no funcionales

 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 29

 REQUERIMIENTOS DE PRODUCTO: Estos requerimientos especifican el comportamiento del

producto. Dentro de estos encontramos los siguientes:

Comportamiento Descripción

Funcionalidad La capacidad del sistema para proveer las funciones que cumplan las necesidades
de los usuarios, es decir, que cumplan con los requerimientos del negocio y de
usuarios. Las funciones que se manejan acá deben ser las que necesita el sistema y
ser capaces de permitir interoperabilidad entre varios sistemas.

Fiabilidad La capacidad del sistema para mantener su nivel de rendimiento en determinados

periodos de tiempo establecidos por la organización. En esta parte debe cumplir
con las expectativas a tolerancia de fallos, así como la de recuperación y
restablecimiento del sistema.

Usabilidad La capacidad del sistema para ser fácilmente entendido, aprendido y de uso
sencillo para el usuario final.

Eficiencia La capacidad del sistema para lograr el rendimiento deseado, teniendo en cuenta
recursos físicos utilizados y condiciones específicas de uso. También tiene en
cuenta los tiempos de respuesta de la solución.

Mantenibilidad La capacidad que tiene el sistema para ser actualizado, modificado o corregido
según sea el caso. Se deben tener en cuenta el control de cambios, la forma y la
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 30

capacidad del sistema de implementar un cambio, estabilidad y verificación de

pruebas.

Portabilidad La capacidad que tiene el sistema para ser desplazado entre diferentes entornos, lo
que representa adaptabilidad al medio en donde sea colocado y su forma de
interactuar con los demás sistemas.

Seguridad La capacidad del sistema de proteger la información que contiene, tanto de

usuarios internos como de usuarios externos.

 REQUERIMIENTOS ORGANIZACIONALES: Estos requerimientos se derivan de políticas y

procedimientos existentes en la organización del cliente y en la del desarrollador. Las organizaciones
se rigen en sus procedimientos por una serie de estándares que permiten evaluar la calidad de los
productos que producen. Se pueden ver como requerimientos organizacionales los siguientes tipos:

Tipos Descripción

Requerimientos de Se rigen bajo estándares y herramientas que se usaran para la implementación del
Implementación sistema.

Requerimientos de Son los requerimientos que se rigen a cronograma, con tiempos para cada una de
Entrega las fases del desarrollo y la entrega final con su documentación.

 REQUERIMIENTOS EXTERNOS: Son aquellos requerimientos que se derivan de la interacción del

sistema con el entorno que lo rodea. Bajo estos aspectos se pueden regir la compatibilidad que maneja
el sistema con los demás y las leyes gubernamentales sobre las cuales se debe regir. A continuación,
se aclararán los tipos de requerimientos externos:

Tipos Descripción

Requerimientos de Compatibilidad Capacidad del sistema para relaciones con otros entornos externos.

Requerimientos Éticos Son requerimientos que se deben especificar, para asegurar que los
usuarios aceptaran el sistema

Requerimientos Legislativo Se asegura que el sistema funciones bajo la legislación actual y no

se cometa algún acto indebido durante su desarrollo.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 31

La distinción entre requerimientos funcionales y no funcionales no siempre resulta evidente. Ejemplo: La

seguridad puede interpretarse inicialmente como un requerimiento no funcional al principio. No obstante, su
elaboración puede conducir a nuevos requerimientos funcionales, como la necesidad de autentificar a los
usuarios del sistema.

3.5. ESTRATEGIA PARA LA RECOPILACION DE INFORMACION

La recopilación de información, especialmente en un sistema grande y complejo, puede ser una tarea
ardua. La información 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 búsqueda 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 información.

A. FUENTES DE INFORMACIÓN

Hay gran variedad de fuentes de información para un sistema. Normalmente, cada fuente da información
distinta y requiere un método de búsqueda diferente para conseguirla.

1. Usuarios del sistema (stakeholders)

Los usuarios del sistema son normalmente la primera fuente de información a investigar por el
analista. De los usuarios es posible extraer información de las actividades del sistema existente y
determinar los objetivos del usuario y sus necesidades. Aquí, los métodos usuales son las
entrevistas y, a veces, cuestionarios.

2. Formularios y documentos
Los formularios y documentos son fuentes de información utilizadas para los diagramas de flujos de
datos y transacciones. La búsqueda comienza con la obtención por parte del analista de una lista
de tales documentos, para, a través de ellos, encontrar los datos elementales y sus estructuras de
datos. En ese punto, es corriente un control de duplicidad de datos y de consistencia de nombres
para asegurar que el mismo dato no aparece con dos nombres distintos.

3. Programas
Los programas se pueden utilizar para determinar los detalles de las estructuras de datos o de los
procesos. Los métodos de búsqueda son generalmente laboriosos y suponen la lectura del
programa o su documentación y, a veces, su ejecución con datos de muestra para ver lo que hace
o si algo está en desacuerdo con el interfaz actual del usuario.

4. Manual de procedimiento
Los manuales de procedimiento especifican lo que hace el personal de una organización. Los
puede utilizar el analista para determinar en detalle las actividades del usuario. Esta información
adquiere relevancia en el diseño detallado.

5. Informes
Se pueden utilizar como base para las entrevistas con el usuario y así determinar cualquier nuevo
requerimiento de salida que pueda tener.

Es muy improbable que una de estas fuentes pueda, por sí sola, suministrar toda la información que
necesita un analista. El procedimiento de búsqueda determina cómo llevar a cabo una búsqueda revisando
esas fuentes.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 32

B. PROCEDIMIENTOS DE BÚSQUEDA

El procedimiento de búsqueda propone el orden para buscar las fuentes de información y qué métodos
utilizar en la búsqueda. Así, el procedimiento de búsqueda viene a ser un plan para fijar qué información se
obtendrá de cada fuente y qué secuencia se seguirá para investigar en ellas.

Procedimiento top-down

Se necesita la aproximación top-down para construir progresivamente el modelo del sistema. No se puede
proceder secuencialmente para primero recoger toda la información del sistema y luego construir el
modelo. Tal aproximación sería muy difícil de manejar y puede conducir a errores. En un primer momento
habría un gran volumen de información aparentemente no relacionada que el analista tendría que examinar
para eliminar inconsistencias y completar las partes incompletas. En estas circunstancias es fácil descuidar
información vital, crear modelos incompletos o encontrar entrevistas repetidas de analistas con usuarios
disgustados.

Es mejor empezar por nivel superior y seguir hasta el nivel inferior para obtener información detallada. Esta
aproximación comienza normalmente con una serie de entrevistas con los directores, para determinar las
funciones principales del sistema y sus actividades. Entonces, el analista busca más información para
describir esas funciones y actividades. Esta información detallada se obtiene entrevistando al personal de
operación. Las entrevistas en los niveles detallados pueden estructurarse para completar huecos
identificados definidos previamente. Esos huecos se identificarán mientras el analista desarrolla el modelo.

Los procedimientos de búsqueda deben especificar el nivel organizativo en el que comienza las entrevistas,
el personal a entrevistar y cualquier otra fuente de información utilizable. Los procedimientos de búsqueda
varían dependiendo de si se investiga un sistema existente o si se diseña uno totalmente nuevo.

1. Procedimientos para sistemas existentes

Los procedimientos de búsqueda para sistemas existentes deben incluir las numerosas fuentes de
información de los sistemas para establecer una secuencia de búsqueda en esas fuentes.
Comienzan con una serie de entrevistas iniciales para saber de qué se trata del problema. Estas
entrevistas identifican funciones y a veces establecen los límites del problema.

En este punto, generalmente los analistas estudian algunos de los informes y documentos más
importantes. Entonces diseñan un modelo de nivel superior y lo verifican durante el siguiente
conjunto de entrevistas.

Una vez establecido un modelo de nivel superior satisfactorio, el analista comienza operaciones
más detalladas. La búsqueda de esa información, más detallada empieza normalmente con
entrevistas al personal de operación. Estas entrevistas establecen las fuentes detalladas de
información, incluyendo programas, informes y manuales.

La clase de datos solicitados en el nivel inferior depende del sistema. Si se perfecciona un sistema
de ordenador, el analista debe examinar los sistemas de ordenador y programas existentes,
entonces el analista realizará un examen detallado de los procedimientos actuales. En la mayoría
de casos se debe examinar tanto el sistema de ordenador como el procedimiento de usuario.

El analista utiliza esta nueva información detallada para expandir el modelo de nivel superior que
será verificado con el usuario.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 33

Este procedimiento puede repetirse varias veces mientras se busca información cada vez más
detallada. Esta subsecuencia de entrevistas y búsquedas se hará más crítica según el analista
vaya aprendiendo cosas sobre el sistema. El analista comienza la identificación de los problemas
del sistema y junto con el usuario establece los objetivos del nuevo sistema.

La iteración continuará hasta que el analista esté conforme con el modelo.

2. Procedimientos para nuevos sistemas

Los procedimientos de búsqueda para nuevos sistemas son más simples, porque hay pocas
fuentes de información. No hay informes, programa ni manuales que examinar. El procedimiento
completo se centra en las entrevistas, pero la forma de atacar éstas es distinta. Las entrevistas no
deben buscar cómo trabaja el sistema, sino determinar lo que los usuarios esperar del nuevo
sistema.

Cuándo se propone la totalidad del nuevo sistema, generalmente el analista busca información en
fuentes externas. En la mayoría de los casos, el nuevo sistema surge porque alguien lo ha visto en
alguna parte. Los analistas pueden examinar estos sistemas externos para ver si alguna de sus
características se ajusta al nuevo sistema propuesto.

3.6. MÉTODOS DE BÚSQUEDA

Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente.
Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo
lo cual ayuda a asegurar una investigación completa.

3.6.1. LA ENTREVISTA

Este es el método más corriente para recoger información del usuario. Es un proceso continuo utilizado por
el analista para construir gradualmente un modelo del sistema y para obtener conocimientos sobre los
problemas del sistema, obtener información acerca de las necesidades del mismo y la manera de
satisfacerlas.

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el
analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del
sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán
afectados por la aplicación propuesta. Sin embargo, las entrevistas no siempre son la mejor fuente de datos
de aplicación.

Hay dos factores clave en la realización de entrevistas. El primero es elegir a la persona a entrevistar. Es
importante, así que el analista debe asegurarse de que se considera a todas las personas clave dentro del
entorno del estudio. El siguiente factor es encontrar el camino correcto para dirigir una entrevista individual.
Aquí se deben considerar las relaciones humanas. El entrevistador debe establecer algunos contactos con
el entrevistado a fin de asegurar la cooperación necesaria para obtener todos los factores relevantes.

 PLAN DE LA ENTREVISTA

Se debe realizar un plan de la entrevista conforme lo siguiente:

 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 34

a) Selección de Entrevistados.

El analista utiliza los términos del proyecto de referencia para seleccionar las áreas organizativas que caen
dentro de los límites de estudio del sistema y que se verán afectadas probablemente por cualquier nuevo
sistema.

Normalmente, es deseable comenzar las entrevistas por el nivel más alto de la organización para obtener el
soporte y la cooperación de la dirección antes de comenzar a examinar actividades organizativas
particulares o sugerir nuevas soluciones. La entrevista se aplica en todos los niveles gerenciales y de
empleados que tengan dependientes y pueda proporcionar la mayor parte de la información útil.

Realizar entrevistas toma tiempo; por lo tanto, no es posible utilizar este método para recopilar toda la
información que se necesita en la investigación. Incluso el analista debe verificar los datos recopilados
utilizando unos de los otros métodos de recuperación de datos.

Ejemplo, para el estudio de la administración de inventarios los analistas pueden entrevistar a los
trabajadores del embarque y de recepción, al personal de almacén y a los supervisores de los diferentes
turnos, es decir. Aquellas personas que realmente trabajan en el almacén también entrevistaran a los
gerentes más importantes.

b) Determinación del tipo de Entrevista.

La estructura de la entrevista varía, si el objetivo de la entrevista radica en adquirir información general, los
dos tipos son:

1. Las entrevistas estructuradas

Ideal para la adquisición de información concreta del sistema, utilizan preguntas estandarizadas.
Los formatos de respuestas para las preguntas pueden ser abiertas o cerradas; las preguntas para
respuestas abiertas permiten a los entrevistados dar cualquier respuesta que parezca apropiada.
Pueden contestar por completo con sus propias palabras. Con las preguntas para respuesta
cerrada se proporcionan al usuario un conjunto de respuesta que se pueda seleccionar. Todas las
personas que responden se basan en un mismo conjunto de posibles respuestas.

2. La entrevista no estructurada
Preguntas y respuestas libres ideal para obtener información general, requiere menos tiempo de
preparación, porque no necesita tener por anticipado las palabras precisas de las preguntas.
Analizar las respuestas después de la entrevista lleva más tiempo que con la entrevista
estructurada. El mayor costo radica en la preparación, administrativo y análisis de las entrevistas
estructuradas para preguntas cerradas.

ENTREVISTA ESTRUCTURADA ENTREVISTA NO ESTRUCTURADA

-Asegura la elaboración uniforme de las -El entrevistador tiene mayor flexibilidad al

preguntas para todos los que van a responder.
VENTAJAS -Fácil de administrar y evaluar.
-Evaluación más objetiva tanto de quienes
responden como de las repuestas a las preguntas.
realizar las preguntas adecuadas a quien
responde.
-El entrevistador puede explotar áreas que
surgen espontáneamente durante la entrevista.
-Puede producir información sobre área que se
minimizaron o en las que no se pensó que fuera
importantes.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 35

-Alto costo de preparación. -Puede utilizarse negativamente el tiempo, tanto

-Los que responden pueden no aceptar un alto
nivel en la estructura y carácter mecánico de las
DESVENTAJAS preguntas.
-El alto nivel en las estructuras reduce responder
en forma espontánea, así como la habilidad del
entrevistador para continuar con comentarios
hacia el entrevistado.
de quien responde como del entrevistador.
-Los entrevistadores pueden introducir sus
sesgos en las preguntas o al informar de los
resultados.
-Pueden recopilarse información extraña.
-El análisis y la interpretación de los resultados
pueden ser largos.
-Toma tiempo extra recabar los hechos
esenciales.

c) Realización de Entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de información por medio de la
entrevista. Las buenas entrevistas dependen del conocimiento del analista, tanto de la preparación del
objetivo de una entrevista específica, como de las preguntas por realizar a una persona determinada. El
tacto, la imparcialidad e incluso la vestimenta apropiada ayuda a asegurar una entrevista exitosa.

Las entrevistas deben efectuarse de forma organizada y amistosa. El entrevistador siempre será cortés y
respetará la oposición y necesidades del usuario. Es importante no imponer soluciones a los usuarios, sino
el papel de asesor. La jerga informática no se debe utilizar para impresionar al usuario.

d) Recabar datos

La entrevista es una forma de conversación, no de interrogación, al analizar las características de los

sistemas con el personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los
analistas pueden conocer datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistema, las formas cualitativas y cuantitativas de la información importante. La

información cualitativa está relacionada con opinión, política y descripciones narrativas de actividades o
problemas, mientras que las descripciones cuantitativas tratan con números, frecuencia, o cantidades. A
menudo las entrevistas pueden ser más útiles para recabar datos cuantitativos.

Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a como se podría hacer el trabajo,
las entrevistas a veces es la mejor forma para conocer las actividades de las empresas. La entrevista
puede descubrir rápidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las
aplicaciones de desarrollo más aun a menudo es más fácil calendarizar una entrevista con los gerentes de
alto nivel que pedirle que llenen cuestionario.

Tanto en las entrevistas iniciales como en las posteriores, el analista siempre intentará encontrar la forma
de conseguir más información, si el entrevistado no puede contestar, se le preguntará dónde se podría
obtener dicha información.

De esta forma, el proceso de la entrevista sigue un camino totalmente estructurado. Se consigue de la

dirección una visión general de la operación del sistema, pasando después a las operaciones detalladas
mediante entrevistas con usuarios de distintos niveles de operación del sistema
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 36

 FASES DE LA ENTREVISTA

I. Preparación de la Entrevista.

1. Determinar la posición que ocupa en la organización el futuro entrevistado, sus responsabilidades

básicas, actividades, etc.
2. Prepara las preguntas que van a plantearse y los documentos necesarios.
3. Preparar la agenda para la entrevista.
4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad.
5. Hacer la cita con la debida anticipación.

II. Conducción de la Entrevista.

1. Explicar con toda amplitud el propósito y alcance del estudio.

2. Fijar un límite de tiempo.
3. Conseguir permiso para tomar apuntes y notas durante la entrevista.
4. Explicar las funciones del analista y la función que se espera conferir al entrevistado.
5. Hacer preguntas específicas para obtener respuestas cuantitativas.
6. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares.
7. Evitar las frases carentes de sentido.
8. Ser cortes absteniéndose de emitir juicios de valores.
9. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas.

III. Secuela de la Entrevista.

1. Escribir los resultados.

2. Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones.
3. Archivar los resultados de la entrevista para referencia y análisis posteriores.

3.6.2. LA ENCUESTA.

Hoy en día la palabra “encuesta” se usa más frecuentemente para describir un método de obtener
información de muestra de individuos. Esta “muestra” es usualmente solo una fracción de la población bajo
estudio.

Las encuestas al ser un medio masivo de recabar de información, tiene como instrumento a los
cuestionarios que son un conjunto de preguntas sobre un tema en particular.

No solo las encuestas tienen una gran variedad de propósitos, sino que también pueden conducirse de
muchas maneras incluyendo por teléfono, por correo o en persona. Aun así, todas las encuestas tienen
algunas características en común.

Hay personas que sugieren el cuestionario, en vez de las entrevistas, para obtener información sobre el
sistema. El cuestionario contiene todas las preguntas que el usuario debe responder para proporcionar la
información que busca el analista. El cuestionario se envía al usuario y el analista analiza las respuestas.

La experiencia sugiere que estos cuestionarios no son normalmente buenos sustitutos de las entrevistas.
Por lo general, las preguntas como 'describa todos sus trabajos' o '¿cuáles son los componentes
principales del sistema?' no son efectivas. Estas preguntas normalmente no se responderán
completamente y en general expresarán sucesos recientes en vez de sucesos intemporáneos.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 37

Los cuestionarios, sin embargo, se utilizan cuando se busca la misma información en usuarios distintos.
Los cuestionarios se utilizan también como complemento de otras técnicas. Se usan para recoger datos
numéricos u obtener opiniones relativamente simples de un número de personas, pero no son efectivos
para búsquedas detalladas ni para identificar problemas o soluciones del sistema.

Se debe hace notar que los participantes individuales nunca puedan ser identificados al reportar los
hallazgos. Todos los resultados de la encuesta deben presentarse en resúmenes completamente
anónimos, tal como tablas y graficas estadísticas.

El desarrollo y distribución de las encuestas debe realizarse de forma inteligente, por ello es importante el
formato y contenido de las preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados y se aplican
dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y si
pueden incluirlas. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

1. Cuestionario Abierto.
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren
conocer los sentimientos, opiniones y experiencias generales: también son útiles al explorar el
problema básico. Algunas personas, sin embargo, encuentran más fácil escoger una de un
conjunto de respuestas preparadas que pensar por sí mismas.

2. Cuestionario Cerrado.
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso
estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el método
para obtener información sobre los hechos. También fuerza a los individuos para que tomen una
posición y forma su opinión sobre los aspectos importantes.

 FASES DE LA ENCUESTA

Para desarrollar un cuestionario se debe seguir los siguientes puntos que ayuden a expresarlo de manera
más clara.

I. Preparación de la Encuesta.

1. Determinar el tipo de cuestionario adecuado (abierto o cerrado). En algunas ocasiones es

conveniente aplicar los cuestionarios mixtos.
2. Determinar qué datos necesitan recabarse y que personas son las más calificadas para
proporcionarlos.
3. Desarrollar un grupo de preguntas adecuadas.
4. Examinar el cuestionario para encontrar fallas y defectos como:
o Interrogantes innecesarias.
o Preguntas mal interpretadas.
o Preguntas a interpretarse en forma diferente.
o Preguntas que no proporcionan opciones adecuadas de respuesta.

II. Realización de la encuesta.

1. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad).

2. Fijar un límite de tiempo.
 TEXTO PARALELO – ANALISIS Y DISEÑO DE SISTEMAS I 38

III. Secuela de la Encuesta.

1. Análisis de los resultados.

2. Presentación de datos en tablas y gráficos
3. Archivar los resultados para referencia y análisis posteriores.

3.6.3. LA OBSERVACIÓN.

Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas
cuando efectúa su trabajo. Como técnica de investigación, la observación tiene amplia aceptación
científica.

El propósito de la observación es múltiple; ya que permite al analista determinar que se está haciendo,
como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, donde se hace y por
qué se hace.

TIPOS DE OBSERVACIÓN.

El analista de sistemas puede observar de tres maneras básicas:

a) INDIRECTA: puede observar a una persona o actitud sin que el observado se dé cuenta y su
interacción por parte del propio analista. Quizá esta alternativa tenga poca importancia para el
análisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias
b) DIRECTA: el analista puede observar una operación sin intervenir para nada, pero estando la
persona observada enteramente consciente de la observación.
c) PARTICIPANTE: puede observar y a la vez estar en contacto con las personas observas. La
interacción puede consistir simplemente en preguntar respecto a una tarea específica, pedir una
explicación, etc.

 FASES DE LA OBSERVACIÓN

I. Preparación de la Observación

1. Determinar y definir aquello que va a observarse.

2. Estipular el tiempo necesario de observación.
3. Obtener la autorización de la gerencia para llevar a cabo la observación.
4. Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello.

II. Conducción de la Observación.

1. Familiarizarse con los componentes físicos del área inmediata de observación

2. Mientras se observa, medir el tiempo en forma periódica.
3. Anotar lo que se observa lo más específicamente posible, evitando las generalidades y las
descripciones vagas.
4. Si se está en contacto con las personas observadas, es necesario abstenerse de hacer
comentarios cualitativos o que impliquen un juicio de valores.

III. Secuela de la Observación.

1. Documentar y organizar formalmente las notas, impresiones, etc.

2. Revisar los resultados y conclusiones junto con la persona observada el supervisor inmediato