UNIDAD 2

ANALISIS DE LOS REQUERIMIENTOS

DE INFORMACION
 LOS REQUERIMIENTOS
Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer: el
servicio que ofrece y las restricciones en su operación. Tales requerimientos reflejan las
necesidades de los clientes por un sistema que atienda cierto propósito. Con la finalidad de
definir a mayor detalle los requerimientos, se describen mediante reglas de negocios y, en
muchos casos, se hacen uso de los diagramas de procesos para que el personal de desarrollo
pueda entender con un mayor nivel de detalle las especificaciones funcionales. El personal de
sistemas es el encargado de trasformar los requerimientos funcionales en requerimientos de
sistemas y, de esta manera, generar un nivel más técnico de especificaciones para el
desarrollo del software.
I.E.E.E. define “Requisito” como:
 Condición o aptitud necesaria para resolver un problema o alcanzar un objetivo.
 Condición o facilidad que debe proporcionar un sistema o algunos de sus subsistemas para
satisfacer un contrato, norma, especificación o cualquier otra condición impuesta
formalmente a través de un documento.
 Una representación documentada de una condición o facilidad.
www.profmatiasgarcia.com.ar
Un requisito define: ¿Qué hace el sistema? Y no ¿Cómo lo hace?
 LOS REQUERIMIENTOS
La inexactitud en la especificación de requerimientos causa muchos problemas en la ingeniería de
software. Es natural que un desarrollador de sistemas interprete un requerimiento ambiguo de forma que
simplifique su implementación. Sin embargo, con frecuencia, esto no es lo que desea el cliente. Tienen
que establecerse nuevos requerimientos y efectuar cambios al sistema. Desde luego, esto aplaza la
entrega del sistema y aumenta los costos.
En principio, la especificación de los requerimientos funcionales de un sistema debe ser total y
consistente. Totalidad significa que deben definirse todos los servicios requeridos por el usuario.
Consistencia quiere decir que los requerimientos tienen que evitar definiciones contradictorias.
Clasificación para describir los requisitos:
 Requisitos de negocio
 Requisitos de las partes interesadas
 Requisitos de la solución
 Requisitos de transición
La clasificación de requisitos considera diferentes enfoques porque es necesario cubrir todas las
perspectivas de lo requerido por el usuario y, de esta manera, poder generar una propuesta adecuada.
www.profmatiasgarcia.com.ar
 LOS REQUERIMIENTOS
REQUISITOS DE NEGOCIO: Se describen a alto nivel las necesidades de la organización, sus
metas y objetivos. Esto implica precisar los antecedentes y objetivos del proyecto,
indicadores de desempeño de gestión y operación para el seguimiento del proyecto. Algunos
de los requisitos de negocio son:
 Debemos ser líderes en el mercado en el uso de aplicaciones móviles para las gestiones de
nuestras operaciones.
 El 40% de las operaciones generadas por nuestros clientes debe ser gestionada por nuestra
página web.
REQUISITOS DE LAS PARTES INTERESADAS: Son las declaraciones de las necesidades de un
interesado o clase particular de partes interesadas. Describen las necesidades que tiene un
determinado actor y cómo interactúan las partes interesadas con la solución. A modo de
ejemplo, podemos mencionar dos requisitos de partes interesadas:
 El estatus de contratación de personal debe ser visualizado por cada una de las unidades
de negocio.
 El área de tesorería debe tener acceso a la información de pagos que se generan por
órdenes de compra en el área de logística. www.profmatiasgarcia.com.ar
 LOS REQUERIMIENTOS
REQUISITOS DE LA SOLUCIÓN: Describe las características de una solución que cumpla con los
requerimientos del negocio y los requerimientos de las partes interesadas. Se desarrollan y definen a
través del análisis de requisitos.
Con frecuencia se dividen requisitos funcionales y no funcionales, especialmente cuando los requisitos
describen una solución de desarrollo de software.

 REQUISITOS FUNCIONALES : Describen el comportamiento y los datos que el sistema administrará.

Definen el comportamiento del sistema, los servicios o funciones del mismo. Describen las tareas que el
sistema debe realizar. También, las capacidades que el sistema podrá realizar en términos de
comportamientos o acciones o respuestas de aplicación de tecnología de la información específicas de
las operaciones. Enuncian cómo debería reaccionar el sistema a entradas particulares y de cómo
debería comportarse el sistema en situaciones específicas. Algunos ejemplos de requisitos funcionales
son:
 El sistema debe permitir el registro de todos los clientes de la tienda.
 El sistema debe permitir el registro de las marcas de los productos y el movimiento logístico del
almacén y la tienda.
 El sistema debe permitir la generación de la boleta dewww.profmatiasgarcia.com.ar
venta y factura.
 LOS REQUERIMIENTOS
 REQUISITOS NO FUNCIONALES: Están relacionados con la operación del software y hacen referencia al
comportamiento de la solución, describen condiciones ambientales bajo las cuales la solución debe
permanecer activa por determinados períodos de tiempo o cualidades que los sistemas deben tener a
nivel operacional. Los requisitos no funcionales están relacionados con la capacidad, experiencia de
usuario, disponibilidad, velocidad, seguridad y arquitectura de la información. A continuación se
muestran ejemplos de requisitos funcionales:
 El sistema debe funcionar en Explorer 7 y 8, también en Chrome.
 El sistema web debe tener disponibilidad permanente; debe ser 24x7.
 Las interfaces del aplicativo móvil deben ser amigables e intuitivas.
 El nivel de respuesta de los reportes del sistema no debe ser mayor a 30 seg.
REQUISITOS DE TRANSICIÓN: Las capacidades que debe tener la solución para facilitar la transición
desde el estado actual de la empresa a un estado futuro deseado, pero que no será necesario una vez que
la transición esté completa. Son siempre de naturaleza temporal y no pueden desarrollarse hasta que se
definen una solución nueva y existente. Normalmente cubren la conversión de datos de los sistemas
existentes, las brechas de habilidades que deben ser abordadas y otros cambios relacionados para
alcanzar el estado futuro deseado.
www.profmatiasgarcia.com.ar
 LOS REQUERIMIENTOS
Los requerimientos no funcionales, como el rendimiento, la seguridad o la disponibilidad,
especifican o restringen por lo general características del sistema como un todo.
Los requerimientos no funcionales a menudo son más significativos que los requerimientos
funcionales individuales. Es común que los usuarios del sistema encuentren formas para
trabajar en torno a una función del sistema que realmente no cubre sus necesidades. No
obstante, el fracaso para cubrir los requerimientos no funcionales haría que todo el sistema
fuera inútil.
Un problema común con requerimientos no funcionales es que los usuarios o clientes con
frecuencia proponen estos requerimientos como metas generales, como facilidad de uso,
capacidad de que el sistema se recupere de fallas, o rapidez de respuesta al usuario.
Las metas establecen buenas intenciones; no obstante, ocasionan problemas a los
desarrolladores del sistema, pues dejan espacio para la interpretación y la disputa posterior
una vez que se entregue el sistema.
Siempre que sea posible, se deberán escribir de manera cuantitativa los requerimientos no
funcionales, de manera que puedan ponerse objetivamente a prueba.
www.profmatiasgarcia.com.ar
 ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
El énfasis global del análisis es recolectar los datos sobre el sistema existente,
determinar los requerimientos para el sistema nuevo, considerar alternativas dentro
de dichas restricciones e investigar la factibilidad de las soluciones. El resultado
principal del análisis de sistemas es una lista priorizada de requerimientos del
sistema.
El análisis de sistemas comienza con clarificar las metas globales de la
organización y la determinación de cómo el sistema de información existente o
propuesto ayudará a alcanzarlas. Esta meta puede traducirse en una o más
necesidades de información.
El propósito de la recolección de datos es buscar información adicional acerca de
los problemas o necesidades identificados en el reporte de investigación de
sistemas. Durante este proceso se enfatizan las fortalezas y debilidades del sistema
existente.
El propósito global del análisis de requerimientos es determinar las necesidades de
usuarios, interesados y de la organización. www.profmatiasgarcia.com.ar
 ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
El análisis de requisitos ayuda a plasmar los requisitos funcionales de los usuarios en
diagramas técnicos que permitan a los analistas y programadores de software un mejor
entendimiento del producto de software que tienen que desarrollar. En esta primera etapa,
los diagramas de contexto y diagramas de flujo de datos son los primeros por elaborar para
poder lograr un entendimiento con el usuario de lo que se requiere.
Este análisis constituye la fase inicial del desarrollo de software, pues ayuda a generar las
especificaciones preliminares para tal desarrollo.
En esta primera etapa pueden elaborarse incluso pruebas de concepto preliminares para
evaluar la tecnología por aplicar y la factibilidad de continuar con el desarrollo del software.
Igualmente, se aplican técnicas de experiencia de usuario para que el usuario en esta primera
etapa conozca a alto nivel cómo quedarán sus interfaces.
El riesgo en esta etapa es la indecisión del usuario, pues si aún no sabe concretamente lo
que quiere o tiene mucha dificultad para tomar decisiones, esta etapa puede tomar mucho
tiempo.

www.profmatiasgarcia.com.ar
 ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
La recolección de datos comienza con la identificación y ubicación de las diversas
fuentes de datos, incluidas las fuentes internas y externas.

FUENTES INTERNAS FUENTES EXTERNAS

Usuarios, interesados y administradores Clientes
Organigramas Proveedores
Formatos y documentos Agencias gubernamentales
Manuales de procedimientos y políticas Competidores
Reportes financieros Grupos externos
Otras medidas de proceso empresarial Consultores

Después de identificar las fuentes de datos, comienza su recolección.

La recolección de datos puede requerir algunas herramientas, métodos y técnicas,
como entrevistas, cuestionarios, observación directa, etc.

www.profmatiasgarcia.com.ar
 MÉTODOS PARA OBTENER REQUERIMIENTOS
Existen tres métodos interactivos que se utilizan para obtener los requerimientos
humanos de información de los miembros de la organización: entrevistas, diseño de
aplicaciones conjuntas (JAD), encuestas mediante cuestionarios y observación
directa. La base de sus propiedades compartidas es hablar con las personas en la
organización y escucharlas para comprender sus interacciones con la tecnología, a
través de una serie de preguntas cuidadosamente elaboradas. Cada uno de los tres
métodos interactivos para recopilar información cuenta con su propio proceso
establecido.
Aunque con sólo estar presente en una organización el analista de sistemas genera
un cambio en la misma, hay métodos discretos “como el muestreo, la investigación
y la observación del comportamiento del encargado de las decisiones y su
interacción con su entorno físico” menos perturbadores que otras formas de
averiguar los requerimientos humanos de información. Los métodos discretos se
consideran insuficientes para recopilar información cuando se utilizan por sí solos,
por esto se recomienda usar ambos. www.profmatiasgarcia.com.ar
 ENTREVISTAS
Una entrevista para recopilar información es una conversación dirigida con un propósito específico, en
la cual se usa un formato de preguntas y respuestas. En la entrevista hay que obtener las opiniones del
entrevistado y lo que siente sobre el estado actual del sistema, los objetivos de la organización y los
personales, y los procedimientos informales para interactuar con las tecnologías de la información.
Se debe pensar en el proceso completo de la entrevista antes de llevarla a cabo. Visualizar por qué se
hará, las preguntas que formulará y qué la convertirá en una entrevista exitosa de acuerdo con su
criterio. Además se debe planear cómo hacer de la entrevista un suceso satisfactorio para el
entrevistado.
Sobre todo buscar las opiniones del entrevistado. Éstas pueden ser más importantes y reveladoras que
los hechos. Además de las opiniones hay que tratar de capturar los sentimientos del entrevistado. Para
entender mejor la cultura de organización se debe escuchar los sentimientos del que responde a la
entrevista.
Los objetivos son información importante que podemos obtener de las entrevistas. Los datos “duros”
pueden explicar el desempeño en el pasado, pero los objetivos proyectan el futuro de la organización. La
entrevista también es un valioso momento para explorar las cuestiones sobre HCI (interacción humano-
computadora), incluyendo los aspectos ergonómicos, la capacidad de uso del sistema, qué tan placentero
y divertido es el sistema, y qué tan útil es para apoyar las tareas individuales.
www.profmatiasgarcia.com.ar
 PASOS PARA LA PREPARACIÓN DE UNA ENTREVISTA
1. INVESTIGAR ANTECEDENTES Leer y comprender todo lo que se pueda sobre los antecedentes de los
entrevistados y la organización. El sitio Web corporativo, un informe anual actualizado, un boletín de
noticias corporativo o cualquier publicación que se emita para explicar el funcionamiento de la empresa
al público son fuentes útiles de información. En esta fase de investigación ponga especial atención al
lenguaje utilizado por los integrantes corporativos para describirse a sí mismos y a la compañía. Trate de
recopilar un vocabulario común que le permita expresar preguntas de forma que sus entrevistados puedan
comprender inmediatamente. Otro beneficio de investigar la organización es aprovechar al máximo el
tiempo invertido en las entrevistas, al no tener que hacer preguntas generales sobre antecedentes.
2. ESTABLECER LOS OBJETIVOS DE LA ENTREVISTA Definir los objetivos de la entrevista a partir de los
antecedentes investigados y de su propia experiencia. Debe haber de cuatro a seis áreas clave
concernientes a HCI, el procesamiento de información y el comportamiento de los encargados de tomar
las decisiones, sobre lo cual será conveniente interrogar. Estas áreas incluyen cuestiones sobre HCI (la
utilidad y capacidad de uso del sistema, cómo se ajusta a los aspectos físicos, cómo se adapta a las
capacidades cognitivas de un usuario, si es interesante y si al utilizar el sistema se obtienen o no las
consecuencias deseadas), fuentes de información, formatos de información, frecuencia de la toma de
decisiones, calidades de la información y el estilo de la toma de decisiones.

www.profmatiasgarcia.com.ar
 PASOS PARA LA PREPARACIÓN DE UNA ENTREVISTA
3. DECIDIR A QUIÉN ENTREVISTAR Incluir personas clave de todos los niveles que se vean
afectados por el sistema en cierta forma. Tratar de que la muestra sea representativa para
indagar sobre la mayor cantidad posible de necesidades de usuario. El contacto de la
organización o el steakholder también puede dar ideas sobre las personas que deben ser
entrevistadas.
4. PREPARAR AL ENTREVISTADO Para preparar a la persona que se va a entrevistar, se debe
llamar por teléfono o enviar un mensaje de correo electrónico con anticipación, de manera
que el entrevistado esté preparado; si la entrevista es muy detallada, se debe enviar
previamente el cuestionario por correo electrónico para que el entrevistado pueda pensar en
sus respuestas. En todo caso, como hay que cumplir muchos objetivos en la entrevista (como
crear confianza y observar el lugar de trabajo), las entrevistas se deben realizar por lo
general en persona y no a través de correo electrónico. Deben durar de 45 minutos a 1 hora
como máximo. Si las entrevistas exceden de una hora, es probable que los entrevistados
resientan la intrusión, independientemente de si se lo hacen saber o no.

www.profmatiasgarcia.com.ar
 PASOS PARA LA PREPARACIÓN DE UNA ENTREVISTA
5. DECIDIR SOBRE LOS TIPOS DE PREGUNTAS Y SU ESTRUCTURA Redactar preguntas
para cubrir las áreas clave de la HCI y el proceso de toma de decisiones que se haya
descubierto al momento de determinar los objetivos de la entrevista. Las técnicas
de interrogación apropiadas son la base de la entrevista. Las preguntas tienen
ciertas formas básicas.
Los dos tipos básicos de preguntas son abiertas y cerradas. Cada tipo de pregunta
puede lograr algo ligeramente distinto que los otros, y cada uno tiene sus beneficios
y desventajas.
Es posible estructurar la entrevista en tres patrones: estructura de pirámide,
estructura de embudo o estructura de diamante. Cada estructura es apropiada bajo
distintas condiciones y sirve a un propósito diferente.

www.profmatiasgarcia.com.ar
 PREGUNTAS ABIERTAS
Las preguntas abiertas son del tipo: “¿Qué piensa en cuanto a poner a todos los gerentes en una
intranet?”, “Por favor explique cómo toma una decisión sobre la programación de tiempos y fechas.”,
“¿En qué formas extiende el sistema su capacidad de realizar tareas que no sería posible realizar
mediante algún otro medio?”.
Abiertas describe las opciones que tiene el entrevistado para responder. La respuesta puede constar de
dos palabras o de dos párrafos.
VENTAJAS DESVENTAJAS
El entrevistado baja la guardia. Las preguntas pueden generar muchos detalles irrelevantes.
El entrevistador puede percibir el vocabulario del entrevistado, lo
Se puede llegar a perder el control de la entrevista.
cual refleja su educación, valores, posturas y creencias.
Se proveen muchos detalles. Podría parecer que el entrevistador no está preparado.
Se descubren vías de cuestionamiento adicionales que de otra Se permiten respuestas que pueden requerir demasiado tiempo
manera no se hubieran explotado. debido a la cantidad obtenida de información útil.
Puede darse la impresión de que el entrevistador “anda de
El entrevistado encuentra el proceso más interesante.
pesca”, sin objetivos bien definidos.
Se permite una mayor espontaneidad.
El entrevistador puede expresar mejor las preguntas.
El entrevistador puede recurrir a ellas en caso de que tenga que
improvisar.
www.profmatiasgarcia.com.ar
 PREGUNTAS CERRADAS
Asumen las formas básicas “¿Es fácil usar el sistema actual?” y “¿Cuántos subordinados tiene a su
cargo?”. Las posibles respuestas son cerradas para el entrevistado, debido a que sólo puede responder
con un número finito tal como “Ninguna”, “Una” o “Quince”.
Una pregunta cerrada limita al entrevistado la respuesta disponible. Se le proporciona una pregunta y
cinco respuestas posibles, y no puede anotar una respuesta propia ya que se considerará equivocada.
Hay un tipo especial de pregunta cerrada: la pregunta bipolar. Este tipo de pregunta limita incluso más
al entrevistado, ya que sólo le permite elegir uno de dos polos, como sí o no, verdadero o falso, etc.

VENTAJAS DESVENTAJAS
Ahorro de tiempo. Son aburridas para el entrevistado.
No proporcionan detalles adicionales (debido a que el
Se pueden comparar las entrevistas con facilidad.
entrevistador provee el marco de referencia para el entrevistado).
Van directo al grano. Se pierden las ideas principales por la razón anterior.
No se puede generar una buena comunicación entre el
Se mantiene el control sobre la entrevista.
entrevistador y el entrevistado.
Se cubre mucho terreno con rapidez.
Se obtienen datos relevantes.

www.profmatiasgarcia.com.ar
 SONDEO
El tercer tipo de pregunta es el sondeo o seguimiento. El sondeo más sólido es el
más simple: la pregunta “¿Por qué?”. Otros sondeos son: “¿Me puede dar un ejemplo
de un momento en el que el sistema no le haya parecido confiable?” y “¿Podría
explicarme eso?”.
El propósito del sondeo es ir más allá de la respuesta inicial para obtener más
detalles significativos, aclarar la información, y ampliar el punto del entrevistado.
Los sondeos pueden ser preguntas abiertas o cerradas.
Es imprescindible realizar sondeos. La mayoría de los entrevistadores principiantes
son reticentes en cuanto a realizar sondeos y con frecuencia aceptan respuestas
superficiales. Por lo general están más agradecidos por el hecho de que los
entrevistados hayan concedido las entrevistas y se sienten en parte obligados a
aceptar declaraciones sin argumentos con amabilidad.

www.profmatiasgarcia.com.ar
 ORDENAMIENTO DE PREGUNTAS
La organización inductiva de las preguntas de la entrevista se puede
visualizar en forma de pirámide. El entrevistador empieza con preguntas muy
detalladas, a menudo cerradas. Después expande los temas al permitir preguntas
abiertas y respuestas más generalizadas.
Se utilizara una estructura de pirámide si se cree que el entrevistado necesita
entrar en calor en cuanto al tema. También es conveniente usar una estructura de
pirámide para las secuencias de preguntas si desea una determinación final sobre el
tema. Cuál es
el problema
específico que está
experimentando
con su firewall?
Ha considerado otros métodos
para mejorar la seguridad de los datos corporativos?
De acuerdo con su punto de vista,
qué mejoraría la efectividad de la seguridad aquí?
En general, cómo se siente en cuanto a la seguridad de los datos en comparación con la
www.profmatiasgarcia.com.ar
importancia del acceso a Internet?
 ORDENAMIENTO DE PREGUNTAS
Otra forma de ordenar las preguntas es usando una estructura de embudo, donde
el entrevistador usa un enfoque deductivo al empezar con preguntas generalizadas y
abiertas, para después reducir la cantidad de respuestas posibles mediante el uso de
preguntas cerradas. Esta ofrece una manera fácil y amigable de empezar una
entrevista. También es conveniente usar una secuencia de preguntas en forma de
embudo cuando el entrevistado está relacionado sentimentalmente con el tema y
necesita libertad para expresar esos sentimientos.
Cuáles son sus reacciones en cuanto al nuevo
sistema de adquisiciones basado en Web?
Qué departamentos están involucrados en su
implementación?
Qué artículos se podrán comprar
en el sitio Web?

Hay algún artículo

esencial
que se haya excluido
del sitio?
www.profmatiasgarcia.com.ar
 ORDENAMIENTO DE PREGUNTAS
A menudo es mejor utilizar una combinación de las dos estructuras anteriores, a lo cual se
le conoce como estructura de entrevista en forma de diamante. En esta estructura la
entrevista empieza de una manera muy específica y después se examinan las cuestiones
generales, para finalmente llegar a una conclusión muy particularizada.
El entrevistador empieza con preguntas fáciles y cerradas que permiten al entrevistado
entrar en calor; a la mitad se le pregunta lo que opina sobre temas amplios que obviamente
no tienen sólo una respuesta “correcta”. Después, el entrevistador restringe incluso más las
preguntas para obtener respuestas específicas, con lo cual se produce un cierre tanto para el
entrevistado como para el entrevistador. La estructura de diamante combina las ventajas de
los otros dos métodos pero tiene la desventaja de que toma más tiempo que las otras dos
estructuras.
Al concluir la entrevista, se hará un resumen y se debe proveer retroalimentación sobre las
impresiones en general. Se informara al entrevistado sobre los pasos a seguir, y lo que harán
los demás miembros del equipo a continuación. Preguntar al entrevistado con quién debería
hablar en adelante. Establecer citas para dar seguimiento a las entrevistas, agradecer al
entrevistado por su tiempo y despedirse cordialmente.
www.profmatiasgarcia.com.ar
 DISEÑO DE APLICACIONES CONJUNTAS
Sin importar qué tan experto se vuelva el entrevistador, se cruzará con situaciones en las
que las entrevistas cara a cara no resultan tan convenientes como esperaba. Las entrevistas
personales consumen tiempo y son propensas a errores, por lo cual sus datos se pueden
malinterpretar. IBM desarrolló una metodología alternativa para entrevistar a los usuarios uno
a uno, conocida como diseño de aplicación conjunta (JAD, Joint Application Design).
Los motivos para usar JAD son reducir el tiempo (y por ende el costo) requerido por las
entrevistas personales, mejorar la calidad de los resultados de la evaluación de los
requerimientos de información y mejorar el grado de identificación del usuario con los nuevos
sistemas de información como resultado de los procesos participativos.
Aunque JAD se puede sustituir por las entrevistas personales en cualquier momento
apropiado durante el SDLC, por lo general se emplea como técnica que le permite al analista
de sistemas, realizar el análisis de requerimientos y diseñar la interfaz de usuario en forma
conjunta con los usuarios, en un ambiente de grupo.
Las sesiones de diseño de aplicaciones conjuntas incluyen a varios participantes (analistas,
usuarios, ejecutivos, etcétera), quienes aportarán sus distintos antecedentes y capacidades.
Se Selecciona un patrocinador ejecutivo, algún superior que introduzca y concluya la sesión
www.profmatiasgarcia.com.ar
JAD.
 DISEÑO DE APLICACIONES CONJUNTAS
De preferencia seleccionar un ejecutivo del grupo de usuarios que tenga cierto tipo de autoridad sobre
el personal de sistemas de información implicado en el proyecto. Esta persona será un símbolo importante
y visible del compromiso de la organización con el proyecto de sistemas.
Debe haber por lo menos un analista de sistemas de información presente, aunque por lo general asume
un rol pasivo, a diferencia de las entrevistas tradicionales, donde el analista controla la interacción, aquí
esta para escuchar qué dicen los usuarios y qué requieren y también podría ser necesaria su opinión sobre
posibles soluciones propuestas durante la sesión. Sin este tipo de retroalimentación inmediata, pueden
surgir soluciones irreales con costos excesivos en la propuesta, que serán difíciles de descartar más
adelante.
Se pueden elegir de ocho a doce usuarios de cualquier rango para que participen en las sesiones JAD,
tratando de seleccionar a los que puedan articular la información que necesitan para realizar sus
trabajos, así como lo que desean en un sistema de cómputo nuevo o mejorado.
El líder de la sesión no debe ser un experto en el análisis y diseño de sistemas, sino alguien con
excelentes habilidades de comunicación como para poder facilitar las interacciones apropiadas. El
objetivo es contar con alguien que pueda atraer la atención del grupo para tratar con las cuestiones
importantes de sistemas, negociar y resolver conflictos en forma satisfactoria y ayudar a que los
miembros del grupo lleguen a un consenso.
www.profmatiasgarcia.com.ar
 DISEÑO DE APLICACIONES CONJUNTAS
La sesión JAD también debe incluir uno o dos observadores que sean analistas o expertos
técnicos de otras áreas funcionales para ofrecer explicaciones técnicas y consejos al grupo
durante las sesiones. Además debe haber un escriba del departamento de sistemas de
información en las sesiones JAD para escribir formalmente todo lo que se haga.
El método recomienda realizar las sesiones fuera de la empresa con una duración de dos a
cuatro días, en un ambiente cómodo. Algunos grupos utilizan centros ejecutivos o salas de
reuniones en hoteles o instituciones. La idea es minimizar las distracciones y
responsabilidades diarias del trabajo regular de los participantes. La sala debe alojar
cómodamente a las personas invitadas. El equipo mínimo para apoyar la presentación incluye
dos proyectores, un pizarrón blanco y acceso a una copiadora. También proporcionan Pcs o
notebooks en red, acceso a internet y software para facilitar la interacción en grupo, al
tiempo que se minimizan los comportamientos en grupo improductivos.
Se programan las sesiones JAD cuando todos los participantes se puedan comprometer a
asistir. Esta regla es imprescindible para el éxito de las sesiones. Todos los participantes
recibirán una agenda antes de la reunión y de forma ideal llevar a cabo una reunión de
orientación de medio día, cuando menos una semana antes del taller para que los que estén
involucrados sepan lo que se espera de ellos. www.profmatiasgarcia.com.ar
 DISEÑO DE APLICACIONES CONJUNTAS
IBM recomienda que las sesiones JAD examinen estos puntos en el proyecto de sistemas
propuesto: planeación, recepción, procesamiento/rastreo de recibos, monitoreo y asignación,
procesamiento, registro, envío y evaluación. Para cada tema también hay que formular y
responder las preguntas quién, qué, cómo, dónde y por qué.
El analista involucrado en las sesiones JAD debe consultar las notas, que alguien designado
tome durante la reunión, para preparar un documento de especificaciones con base en lo que
ocurrió en ella. Presente en forma sistemática los objetivos de la administración, así como el
alcance y los límites del proyecto. Incluya también los aspectos específicos del sistema, como
los detalles en pantalla y los esquemas de los informes.
Una desventaja es que JAD requiere que todos los participantes comprometan mucho
tiempo, durante un periodo de dos a cuatro días, no es posible realizar ninguna otra actividad
en forma concurrente ni postergar actividades, como se realiza comúnmente en las
entrevistas cara a cara.
Otro obstáculo se produce cuando la preparación para las sesiones JAD es inadecuada en
cualquier aspecto, o si el informe de seguimiento y la documentación de las especificaciones
están incompletos. En estos casos, los diseños resultantes podrían ser insatisfactorios.
www.profmatiasgarcia.com.ar
 CUESTIONARIOS / ENCUESTAS
El uso de cuestionarios es una técnica de recopilación de información que permite a los
analistas de sistemas estudiar las posturas, las creencias, el comportamiento y las
características de varias personas clave en la organización que se pueden ver afectadas por
los sistemas actual y propuesto. Las posturas son lo que las personas en la organización dicen
desear (en un nuevo sistema, por ejemplo); las creencias son lo que las personas dan por
cierto; el comportamiento es lo que hacen los miembros de la organización, y las
características son las propiedades de las personas u objetos.
Las respuestas obtenidas a través de cuestionarios (también conocidos como encuestas) en
los que se utilizan preguntas cerradas se pueden cuantificar. Si encuesta personas a través del
correo electrónico o Web, puede usar software para convertir las respuestas electrónicas
directamente en tablas de datos para analizarlas mediante una aplicación de hoja de cálculo
o paquetes de software estadísticos. Las respuestas a los cuestionarios en los que se utilizan
preguntas abiertas se analizan e interpretan de otras formas. Las respuestas a las preguntas
sobre posturas y creencias son sensibles a las palabras elegidas por el analista de sistemas.
Por medio del uso de cuestionarios, el analista puede buscar cuantificar lo que encontró en
las entrevistas.
www.profmatiasgarcia.com.ar
 CUESTIONARIOS / ENCUESTAS
A primera vista, tal vez los cuestionarios parezcan una forma rápida de recopilar cantidades masivas de
datos sobre la forma en que los usuarios valoran el sistema actual, los problemas que experimentan con
su trabajo y lo que las personas esperan de un sistema nuevo o modificado, sin invertir tiempo en las
entrevistas cara a cara.
Para desarrollar un cuestionario útil se requiere mucho tiempo de planeación. Cuando decidimos
encuestar a los usuarios por correo electrónico o a través de Web, debemos tomar en cuenta ciertos
aspectos de planeación adicionales relacionados con la confidencialidad, la autenticación de la identidad
y los problemas de respuestas múltiples. Se recomienda el uso de cuestionarios si:
1. Las personas a quienes se necesita interrogar están esparcidas en un área amplia (distintas sucursales
de la misma organización).
2. Hay gran cantidad de personas involucradas en el proyecto de sistemas, por lo que es importante
saber qué proporción de un grupo dado (por ejemplo, la gerencia) aprueba o desaprueba una
característica específica del sistema propuesto.
3. Piensa realizar un estudio exploratorio y desea medir la opinión general antes de que el proyecto de
sistemas tome cualquier dirección específica.
4. Desea estar seguro de que se identifiquen y consideren los problemas con el sistema actual en las
entrevistas de seguimiento.
www.profmatiasgarcia.com.ar
 PREGUNTAS PARA CUESTIONARIOS
La mayor diferencia entre las preguntas que se utilizan en la mayoría de las entrevistas y las que se
utilizan en cuestionarios es que las entrevistas permiten la interacción entre las preguntas y sus
significados. En una entrevista, el analista tiene la oportunidad de refinar una pregunta, definir un
término confuso, cambiar el curso del cuestionamiento, responder a una mirada desconcertada y en
general, controlar el contexto.
En un cuestionario, muy pocas de estas oportunidades son posibles. Por lo tanto, para el analista las
preguntas deben ser tan claras como el agua, el flujo del cuestionario debe ser convincente, se debe
anticipar a las preguntas del encuestado, y la administración del cuestionario se debe planear con detalle
(el encuestado es la persona que responde o contesta el cuestionario).
Los tipos de preguntas básicas que se utilizan en el cuestionario son abiertas y cerradas, como en las
entrevistas. Al escribir preguntas abiertas para un cuestionario, se debe anticipar al tipo de respuesta que
se obtendrá, las respuestas pueden ser demasiado amplias como para obtener una interpretación o
comparación precisa. Por lo tanto, una pregunta abierta debe ser lo suficientemente estrecha como para
guiar a los encuestados a responder en cierta forma específica.
En particular, las preguntas abiertas son adecuadas para las situaciones en las que se quiere conocer las
opiniones de los miembros de la organización sobre cierto aspecto del sistema, ya sea un producto o un
proceso.
www.profmatiasgarcia.com.ar
 PREGUNTAS PARA CUESTIONARIOS
Las preguntas cerradas son aquellas que limitan o cierran las opciones de respuestas disponibles para el
encuestado.
Hay que utilizar preguntas cerradas cuando el analista de sistemas pueda enlistar de manera efectiva
todas las posibles respuestas a la pregunta y cuando todas éstas sean mutuamente exclusivas (al elegir
una de ellas se descarta la posibilidad de elegir cualquier otra).
Usar preguntas cerradas cuando desee encuestar a una amplia muestra de personas. La razón se vuelve
obvia al momento de imaginar cómo se verán los datos recolectados. Si se utilizan sólo preguntas
abiertas para cientos de personas, sería imposible lograr un análisis e interpretación correctos de sus
respuestas sin la ayuda de un programa de análisis de contenido computarizado.
Elegir uno u otro tipo de preguntas implica sacrificar unas ventajas para lograr otras. Hay que tener en
cuenta que las respuestas a las preguntas abiertas pueden ayudar a los analistas a obtener una visión
detallada y preliminar, así como amplitud y profundidad sobre un tema. Aunque las preguntas abiertas se
pueden escribir con facilidad, las respuestas para ellas son difíciles y se requiere tiempo para analizarlas.
Al referirnos a la escritura de preguntas cerradas con respuestas ordenadas o desordenadas, a menudo
nos referimos al proceso como escalar.

www.profmatiasgarcia.com.ar
 OBSERVACIÓN DIRECTA
Con la observación directa, uno o más miembros del equipo de análisis observan
directamente el sistema existente en acción. Una de las mejores formas para
comprender cómo funciona éste es trabajar con los usuarios para descubrir cómo
fluyen los datos en ciertas tareas empresariales. Determinar el flujo de datos
implica la observación directa de los procedimientos operativos de los usuarios, sus
reportes, pantallas actuales (si ya está automatizado), etc. A partir de esta
observación, los miembros del equipo de análisis determinan cuáles formatos y
procedimientos son adecuados y cuáles son inadecuados y necesitan mejorarse. La
observación directa requiere cierta habilidad. El observador debe ver lo que
realmente ocurre y no estar influenciado por actitudes o sentimientos. Este enfoque
revela importantes problemas y oportunidades que serían difíciles de obtener
usando otros métodos de recolección de datos. Un ejemplo sería observar los
procedimientos operativos, reportes y pantallas de computadora asociados con un
sistema de cuentas por pagar que se considera sustituir.

www.profmatiasgarcia.com.ar
 MUESTREO
El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de una
población. Cuando se examinan con detalle estos elementos seleccionados, se asume que el análisis
revela información útil sobre la población en general.
El analista de sistemas debe decidir con respecto a dos cuestiones clave. En primer lugar hay muchos
informes, formularios, documentos de resultados, memos y sitios Web que las personas en la organización
han generado. ¿A cuáles de ellos debe el analista poner atención y cuáles debe ignorar?
En segundo lugar, muchos empleados se pueden ver afectados por el sistema de información propuesto.
¿A quiénes debería entrevistar el analista de sistemas?, ¿de quienes debería buscar información por medio
de cuestionarios?, ¿a quienes debería observar en el proceso de llevar a cabo sus roles de toma de
decisiones?
Un analista de sistemas debe seleccionar una muestra representativa de datos para examinarlos o de
personas representativas para entrevistarlas, interrogarlas u observarlas por varias razones:
1. Contener los costos.
2. Agilizar el proceso de recopilación de datos.
3. Mejorar la efectividad.
4. Reducir la predisposición.
www.profmatiasgarcia.com.ar
 DISEÑO DE MUESTRA
Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra:
1. DETERMINAR LOS DATOS A RECOLECTAR O DESCRIBIR. Si se recopilan datos irrelevantes se desperdicia
tiempo y dinero en la recolección, el almacenamiento y el análisis de datos inútiles. Hay que considerar
los objetivos del estudio, así como el tipo de método de recopilación de datos (investigación, entrevistas,
cuestionarios, observación) a utilizar.
2. DETERMINAR LA POBLACIÓN A MUESTREAR Por ejemplo en caso de muestrear datos rigurosos, se
necesita decidir si basta con los últimos dos meses o si se requiere todo un año de informes para el
análisis. De manera similar, al decidir a quién va a entrevistar, el analista de sistemas tiene que
determinar si la población incluirá uno o todos los niveles de la organización, o incluso si debe considerar
a clientes, distribuidores, proveedores o competidores.
3. ELEGIR EL TIPO DE MUESTRA. Tipos principales de muestras: de conveniencia, intencionada, simple y
compleja. Las de conveniencia son muestras sin restricciones ni probabilidades. Una muestra de este tipo
resultaría de que el analista de sistemas publicara un aviso en la intranet de la empresa para pedir que
los interesados en trabajar con los nuevos informes de rendimiento de ventas fueran a una reunión a la 1
P.M. el martes 12. Es una muestra poco confiable. Una muestra intencionada se basa en el juicio. El
analista de sistemas puede elegir un grupo de individuos que parezcan expertos y estén interesados. Es
confiable sólo en un nivel moderado.
www.profmatiasgarcia.com.ar
 DISEÑO DE MUESTRA
Si elige realizar un muestreo aleatorio simple, necesita obtener una lista numerada de la población
para asegurar que cada documento o persona en la población tenga la misma probabilidad de ser
seleccionada. A menudo este paso no es práctico, en especial cuando el muestreo involucra documentos e
informes. Las muestras aleatorias complejas más apropiadas para el analista de sistemas se obtienen
mediante 1) muestreo sistemático, 2) muestreo estratificado y 3) muestreo de conglomerados.
4. DECIDIR SOBRE EL TAMAÑO DE LA MUESTRA En definitiva, si todos en la población vieran el mundo de
la misma forma, o si cada uno de los documentos de una población tuviera exactamente la misma
información que cualquier otro, sería suficiente una muestra con tamaño de uno. Como no es así, es
necesario establecer un tamaño de muestra mayor, pero menor que el de la población.
A menudo, el tamaño de las muestras depende del costo o el tiempo requerido por el analista de
sistemas, o incluso del tiempo disponible de las personas en la organización.
Una buena regla general es entrevistar a por lo menos tres personas en todos los niveles de la
organización, y a por lo menos una de cada una de las áreas funcionales. No es necesario entrevistar a
más personas sólo porque se trate de una empresa más grande. Si el muestreo estratificado se lleva a
cabo en forma apropiada, pocos individuos representarán de manera adecuada a toda la organización.

www.profmatiasgarcia.com.ar
 INVESTIGACIÓN
Investigar es descubrir y analizar información. A medida que el analista de sistemas trabaja
para entender a los usuarios, su organización y sus requerimientos de información, debe
examinar los distintos tipos de datos “duros” que ofrecen información no disponible por
cualquier otro medio de recopilación. Estos datos revelan dónde ha estado la organización y
hacia dónde creen sus miembros que se dirige. Para formarse una imagen precisa, el analista
necesita examinar datos tanto cuantitativos como cualitativos.
Hay muchos documentos cuantitativos disponibles para su interpretación en cualquier
empresa: informes empleados para la toma de decisiones, informes de rendimiento, registros
y variados tipos de formularios. Todos estos documentos tienen un propósito y una audiencia
específicos.
INFORMES PARA LA TOMA DE DECISIONES El analista de sistemas requiere acceso a algunos de
los documentos utilizados para dirigir la empresa. A menudo consisten en informes sobre el
estado del inventario, las ventas o la producción. Muchos de ellos son simples y su función es
dar apoyo a una acción rápida.
INFORMES DE RENDIMIENTO La mayoría de los informes de rendimiento consisten en una
comparación entre el rendimiento actual y el esperado.
www.profmatiasgarcia.com.ar
 INVESTIGACIÓN
REGISTROS Los registros proveen actualizaciones periódicas de lo que ocurre en la empresa. Si el
encargado del registro es cuidadoso y lo actualiza en forma oportuna, puede proveer mucha información
útil para el analista. Hay varias formas en que el analista puede inspeccionar un registro, muchas de las
cuales son indicativas de su capacidad de uso:
1. Revisar errores en montos y totales.
2. Buscar oportunidades para mejorar el diseño de los formularios de registro.
3. Observar el número y tipo de transacciones.
4. Estar al tanto de los casos en los que una computadora pueda simplificar el trabajo (por ejemplo, los
cálculos y otras formas de manipular los datos).
FORMULARIOS DE CAPTURA DE DATOS Antes de disponerse a cambiar los flujos de información de la
organización, hay que entender el sistema que está en uso en ese momento.
1. Recolectar ejemplos de todos los formularios en uso, sin importar que estén aprobados o no por la
empresa (formularios oficiales vs. formularios clandestinos).
2. Observar el tipo de formulario (impreso dentro de la empresa, escrito a mano, generado por
computadora dentro de la empresa, formularios en línea, formularios para llenar en Web, formularios que
se imprimen y compran de manera externa, etcétera). 3. Documentar el patrón de distribución deseado.
www.profmatiasgarcia.com.ar
 INVESTIGACIÓN
Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, anuncios en
carteleras y áreas de trabajo, páginas Web, manuales de procedimientos y de políticas. Muchos de estos
documentos contienen gran cantidad de detalles que revelan las expectativas de los autores con respecto
al comportamiento de los demás, junto con las formas en que los usuarios esperan interactuar con las
tecnologías de información.
Varios lineamientos pueden ayudar a los analistas a adoptar un enfoque sistemático para este tipo de
análisis; muchos se relacionan con los aspectos afectivos, emotivos y motivacionales, así como las
relaciones interpersonales en la organización.
1. Examinar los documentos en busca de metáforas clave o que sirvan como guía.
2. Buscar discrepancias entre internos contra externos o una mentalidad del tipo “nosotros contra
ellos”.
3. Hacer una lista de los términos que caractericen el bien o el mal y que aparezcan varias veces en los
documentos.
4. Buscar el uso de mensajes y gráficos significativos que se publiquen en áreas comunes o en páginas
Web.
5. Reconocer un sentido del humor, si es que lo hay.
www.profmatiasgarcia.com.ar
 OBSERVACIÓN
Observar a los encargados de tomar decisiones, su entorno físico y su interacción con el
entorno físico y ergonómico es un importante método discreto para el analista de sistemas.
Mediante la observación de las actividades de los encargados de tomar decisiones, el analista
busca obtener una comprensión de lo que se lleva a cabo en realidad, no sólo de lo que está
documentado o explicado. Por medio de esta observación, el analista trata de ver de primera
mano las relaciones que existen entre los encargados de tomar decisiones y los demás
miembros de la organización, y al considerar además sus interacciones con las tecnologías
también puede obtener pistas importantes relacionadas con cuestiones del sistema, como qué
tan bien se adapta el sistema al usuario.
La observación permite al analista ver de primera mano la forma en que los gerentes
recopilan, procesan, comparten y utilizan la información y la tecnología para llevar a cabo su
trabajo.
Al observar el entorno físico donde trabajan estas personas también podemos obtener
muchos detalles sobre sus requerimientos humanos de información. La mayoría de las veces,
este proceso de información implica examinar de manera sistemática sus oficinas y sus
interacciones con la tecnología, ya que con ambas suelen establecer una relación de
influencia mutua. www.profmatiasgarcia.com.ar
 PROPIEDADES DESEABLES DE LOS REQUISITOS
 Comprensible por clientes, usuarios y desarrolladores.
 Correcto, sin requisitos innecesarios o redundantes.
 No ambiguo y con el nivel de precisión necesario.
 Completo, que no falten requisitos y que todas las respuestas del sistema a entradas tanto válidas
como inválidas estén especificadas.
 Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de nivel superior
y con una terminología única.
 Verificable, que pueda comprobarse que el sistema final cumple los requisitos mediante un proceso
finito y de coste razonable.
 Fácilmente modificable, organizada, con los requisitos identificados y con control de configuración.
 Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrás y hacia
delante.
 Priorizada, indicando la importancia de los requisitos.
 Anotada con estabilidad, para conocer posibles fuentes de cambios durante el desarrollo.
 Independiente del diseño y la implementación, para evitar complejidades innecesarias y no limitar a
los diseñadores.
www.profmatiasgarcia.com.ar
 PROBLEMAS EN LA OBTENCIÓN DE REQUERIMIENTOS
PROBLEMAS DE ÁMBITO: Se catalogan de esta manera cuando el alcance del sistema no está bien
definido; los usuarios hacen referencia a diferentes temas sin establecer claramente los límites del
sistema. En este caso, es necesario que el analista establezca los límites mediante supuestos y
restricciones, definiendo aquello que será parte del sistema y aquello que no será parte del sistema.
PROBLEMAS DE COMPRENSION: El usuario final no sabe concretamente lo que necesita, no tiene
conocimiento de elementos tecnológicos, es muy funcional. También entran en esta categoría los usuarios
que no saben transmitir claramente sus necesidades o la indican a muy alto nivel porque no disponen de
mucho tiempo; por tanto, omiten información necesaria para el desarrollo del sistema. Existen usuarios
que también especifican requisitos que corresponden a otras unidades de negocio o a otros sistemas sin
una coordinación previa a nivel funcional.
PROBLEMAS DE VOLATILIDAD: Existen casos en donde los usuarios por cada sesión de relevamiento de
información en lugar de complementar, modifican la información antes precisada para el desarrollo del
sistema; por tanto, es necesario que se concreten actas de trabajo en donde se especifiquen los temas
tratados y acuerdos. Esta actividad también se puede dificultar cuando los usuarios funcionales cambian
de una reunión a otra; por ello, es necesario que se solicite la interacción con un usuario representativo
que pueda expresar las necesidades de la unidad, organizaciones y verifique el producto culminado.

www.profmatiasgarcia.com.ar
 VALIDACIÓN DE REQUERIMIENTOS
Con frecuencia es útil analizar cada requerimiento en comparación con preguntas de verificación. A
continuación se presentan algunas:
 ¿Los requerimientos están enunciados con claridad? ¿Podrían interpretarse mal?
 ¿Está identificada la fuente del requerimiento (una persona, reglamento o documento)? ¿Se ha
estudiado el planteamiento final del requerimiento en comparación con la fuente original?
 ¿El requerimiento está acotado en términos cuantitativos?
 ¿Qué otros requerimientos se relacionan con éste? ¿Están comparados con claridad por medio de una
matriz de referencia cruzada u otro mecanismo?
 ¿El requerimiento viola algunas restricciones del dominio?
 ¿Puede someterse a prueba el requerimiento? Si es así, ¿es posible especificar las pruebas para
ensayar el requerimiento?
 ¿Puede rastrearse el requerimiento hasta cualquier modelo del sistema que se haya creado?
 ¿Es posible seguir el requerimiento hasta los objetivos del sistema o producto?
 ¿La especificación está estructurada en forma que lleva a entenderlo con facilidad, con referencias y
traducción fáciles a productos del trabajo más técnicos?
www.profmatiasgarcia.com.ar
 HERRAMIENTAS PARA ANÁLISIS DE REQUERIMIENTOS
Para documentar el análisis de requerimientos se pueden usar algunas
herramientas, incluidas las case.
Conforme se desarrollan los requerimientos y se acuerdan, en el repositorio case
se almacenan diagramas entidad-relación, diagramas de flujo de datos, formatos de
pantallas, plantillas de reporte y otros tipos de documentación. Dichos
requerimientos también se pueden usar más tarde como una referencia durante el
resto del desarrollo de sistemas o para un proyecto de desarrollo de sistemas
diferente.

www.profmatiasgarcia.com.ar
 ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE
Especificación de requisitos del software (SRS, Software requirements
specification). Un documento SRS es la especificación de las funciones que realiza
un determinado producto de software, programa o conjunto de programas en un
determinado entorno.
A través de los SRS se determina qué funcionalidades deben realizarse, qué datos
deben generarse en cada resultado, en qué lugar y quién los debe producir. La SRS
debe centrarse en los servicios que se realizarán, pero, en general, no debe
especificar elementos de diseño o de proyecto. Deben centrarse únicamente en el
punto de vista externo del sistema, y no en el funcionamiento interno.
El documento de especificación de requisitos puede elaborarlo el personal
representativo de la parte suministradora (desarrollador), o de la parte cliente; si
bien es aconsejable la intervención de ambas partes.
Este proceso también es considerado como: elicitación, educción, formulación,
identificación o extracción.
www.profmatiasgarcia.com.ar
 REPORTE DE ANÁLISIS DE SISTEMAS
El análisis de sistemas concluye con un reporte formal de dicho análisis. Debe cubrir los
siguientes elementos:
 Las fortalezas y debilidades del sistema existente desde la perspectiva del interesado.
 Los requerimientos de usuario/interesado para el nuevo sistema (también llamados
requerimientos funcionales).
 Los requerimientos organizacionales para el nuevo sistema.
 Una descripción de lo que debe hacer el nuevo sistema de información para resolver el
problema.
El reporte de análisis de sistemas brinda a los administradores una buena comprensión de
los problemas y fortalezas del sistema existente. Si éste opera mejor de lo esperado, o los
cambios necesarios son muy costosos en relación con los beneficios de un sistema nuevo o
modificado, el proceso de desarrollo de sistemas se puede detener en esta etapa. Si el
reporte muestra que los cambios a otra parte del sistema pueden ser la mejor solución, el
proceso de desarrollo puede iniciar de nuevo, y arrancar una vez más con la investigación de
sistemas. O, si el reporte de análisis de sistemas muestra que será benéfico desarrollar uno o
www.profmatiasgarcia.com.ar
más sistemas nuevos o realizar cambios a los existentes, comienza el diseño de sistemas.
 REPORTE DE ANÁLISIS DE SISTEMAS
En la práctica, en el documento de requerimientos, resulta difícil separar los requerimientos
funcionales de los no funcionales. Si los requerimientos no funcionales se expresan por separado de los
requerimientos funcionales, las relaciones entre ambos serían difíciles de entender. No obstante, se
deben destacar de manera explícita los requerimientos que están claramente relacionados con las
propiedades emergentes del sistema, como el rendimiento o la fiabilidad. Esto se logra al ponerlos en una
sección separada del documento de requerimientos o al distinguirlos, en alguna forma, de otros
requerimientos del sistema.
Son esenciales los documentos de requerimientos cuando un contratista externo diseña el sistema de
software. Sin embargo, los métodos de desarrollo ágiles argumentan que los requerimientos cambian tan
rápidamente que un documento de requerimientos se vuelve obsoleto tan pronto como se escribe, así que
el esfuerzo se desperdicia en gran medida. En lugar de un documento formal, los enfoques como la
Programación eXtrema (Beck, 1999) recopilan de manera incremental requerimientos del usuario y los
escriben en tarjetas como historias de usuario. De esa manera, el usuario da prioridad a los
requerimientos para su implementación en el siguiente incremento del sistema.
Naturalmente, la información que se incluya en un documento de requerimientos depende del tipo de
software que se va a desarrollar y del enfoque para el desarrollo que se use.

www.profmatiasgarcia.com.ar
 REPORTE DE ANÁLISIS DE SISTEMAS
CAPITULO DESCRIPCIÓN
Prefacio Debe definir el número esperado de lectores del documento, así como describir su historia de versiones, incluidas
las causas para la creación de una nueva versión y un resumen de los cambios realizados en cada versión.
Describe la necesidad para el sistema. Debe detallar brevemente las funciones del sistema y explicar cómo
Introducción funcionará con otros sistemas. También tiene que indicar cómo se ajusta el sistema en los objetivos empresariales o
estratégicos globales de la organización que comisiona el software.

Glosario Define los términos técnicos usados en el documento. No debe hacer conjeturas sobre la experiencia o la habilidad
del lector.

Definición de Aquí se representan los servicios que ofrecen al usuario. También, en esta sección se describen los requerimientos
no funcionales del sistema. Esta descripción puede usar lenguaje natural, diagramas u otras observaciones que sean
requerimientos del usuario comprensibles para los clientes. Deben especificarse los estándares de producto y proceso que tienen que seguirse.
Este capítulo presenta un panorama de alto nivel de la arquitectura anticipada del sistema, que muestra la
Arquitectura del sistema distribución de funciones a través de los módulos del sistema. Hay que destacar los componentes arquitectónicos
que sean de reutilización.

Especificación de Debe representar los requerimientos funcionales y no funcionales con más detalle.
Si es preciso, también pueden detallarse más los requerimientos no funcionales. Pueden definirse las interfaces a
Requerimientos del sistema otros sistemas.
Pueden incluir modelos gráficos del sistema que muestren las relaciones entre componentes del sistema, el sistema
Modelos del sistema y su entorno. Ejemplos de posibles modelos son los modelos de objeto, modelos de flujo de datos o modelos de
datos semánticos.
Describe los supuestos fundamentales sobre los que se basa el sistema, y cualquier cambio anticipado debido a
Evolución del sistema evolución de hardware, cambio en las necesidades del usuario, etc. Esta sección es útil para los diseñadores del
sistema, pues los ayuda a evitar decisiones de diseño que restringirían probablemente futuros cambios al sistema.
Brindan información específica y detallada que se relaciona con la aplicación a desarrollar; por ejemplo,
Apéndices descripciones de hardware y bases de datos. Los requerimientos de hardware definen las configuraciones, mínima y
óptima, del sistema. Los requerimientos de base de datos delimitan la organización lógica de los datos usados por el
sistema y las relaciones entre datos.

Índice de funciones, etcétera. www.profmatiasgarcia.com.ar

Pueden incluirse en el documento varios índices. Así como un índice alfabético normal, uno de diagramas, un índice
 BIBLIOGRAFÍA Y LICENCIA
♦ Kendall Kenneth y Kendall Julie. “Análisis y Diseño de Sistemas” (8va Ed). Prentice Hall,
2011,México.
♦ Stair Ralph y Reynolds George. “Principios de Sistemas de Información” (9na Ed). Cengage Learning,
2010, España.
♦ Wong Durand Sandra. “Análisis y requerimientos de software”. Universidad Continental, 2017, Peru.
♦ Este documento se encuentra bajo Licencia Creative Commons Attribution – NonCommercial -
ShareAlike 4.0 International (CC BY-NC-SA 4.0), por la cual se permite su exhibición, distribución, copia
y posibilita hacer obras derivadas a partir de la misma, siempre y cuando se cite la autoría del Prof.
Matías E. García y sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta.
♦ Autor:

Matías E. García
..
Prof.
Prof. &
& Tec.
Tec. en Informá
en Inform ática
tica Aplicada
Aplicada
www.profmatiasgarcia.com.ar
www.profmatiasgarcia.com.ar
[email protected]
[email protected]

www.profmatiasgarcia.com.ar