Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica

Unidad 3: Captura de Requisitos

Objetivo:
El estudiante Identificar las reas de oportunidad en una organizacin, para la propuesta y diseo de sistemas de
informacin. Tambin analizar diversas alternativas de solucin a partir de la identificacin y definicin de
requerimientos especificados por el cliente.

3.1. Tipos de requisitos.

Requisito.
En la ingeniera de sistemas, un requisito (del ingls requirement: requisito) es una necesidad documentada sobre
el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniera de
sistemas o la ingeniera de software.
En la ingeniera clsica, los requisitos se utilizan como datos de entrada en la etapa de diseo del producto.
Establecen qu debe hacer el sistema, pero no cmo hacerlo.
La fase de captura, licitacin y registro de requisitos puede estar precedida por una fase de anlisis conceptual del
proyecto. Esta fase puede dividirse en recoleccin de requisitos, anlisis de consistencia e integridad, definicin en
trminos descriptivos para los desarrolladores y un esbozo de especificacin, previo al diseo completo.
Qu es un requisito?
Es una condicin o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
Es una condicin o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estndar,
especificacin, u otra documentacin formalmente impuesta (IEEE).
Es una condicin o capacidad que debe ser conformada por el sistema (RUP).
Es algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).
Requisitos en ingeniera de software y sistemas
En ingeniera de sistemas existen tres tipos de requisitos.
Un requisito funcional puede ser una descripcin de lo que un sistema debe hacer. Este tipo de requisito especifica
algo que el sistema entregado debe ser capaz de realizar.
Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cmo debe
realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento,
la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la
compatibilidad con cierto sistema operativo hasta la adecuacin a leyes o regulaciones aplicables al producto.
Una coleccin de requisitos describe las caractersticas o atributos del sistema deseado. Se omite el cmo debe
lograrse su implementacin, ya que esto debe ser decidido en la etapa de diseo por los diseadores.
En la ingeniera de software se aplica el mismo significado, slo que el nfasis est puesto en el propio software.
Pseudorequerimientos: Son aquellos referidos al entorno donde sera instalado o implementado el sistema, que
determinan en gran medida su desarrollo, pueden ser cuestiones como hardware y software.
L.S.C.A. Ral1Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Caractersticas de los requisitos:
Los requisitos bien formulados deben satisfacer varias caractersticas. Si no lo hacen, deben ser reformulados hasta
hacerlo.
Necesario: Lo que pida un requisito debe ser necesario para el producto.
No ambiguo: El texto debe ser claro, preciso y tener una nica interpretacin posible.
Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo tcnico y
especializado, aunque an as debe referenciar los aspectos importantes.
Consistente: Ningn requisito debe entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo,
el lenguaje empleado entre los distintos requisitos debe ser consistente tambin.
Completo: Los requisitos deben contener en s mismos toda la informacin necesaria, y no remitir a otras fuentes
externas que los expliquen con ms detalle.
Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los
recursos disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificacin
puede lograrse mediante inspeccin, anlisis, demostracin o testeo.
Estas caractersticas suelen ser subjetivas, es decir, no pueden ser calculadas de forma automtica por ningn
sistema. Por ello, se tiende a medir otras mtricas o indicadores que s que pueden ser calculados de forma
automtica y que, de algn modo, pueden sustituir o mapear con esta lista de caractersticas.
Anlisis de requisitos
La etapa en que se estudian los requisitos para verificar que estn correctamente adecuados a las caractersticas
mencionadas es conocida como Anlisis de requisitos. En la misma se enfocan e intentan solucionar las
deficiencias que los requisitos puedan tener.
El anlisis de requisito tambin conocido cola la ingeniera de requisitos del software es un proceso de
descubrimiento, refinamiento, modelado y especificacin. Se refinan en detalle los requisitos del sistema y el papel
asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de requisitos un conjunto de
actividades que son denominadas anlisis El cliente intenta replantear un sistema confuso, a nivel de descripcin
de datos, funciones y comportamiento, en detalles concretos. El desarrollador acta como interrogador, como
consultor, como persona que resuelve problemas y como negociador.
El anlisis y la especificacin de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias
engaan. El contenido de comunicacin es muy denso. Abundan las ocasiones para malas interpretaciones o falta
de informacin. Es muy probable que haya ambigedad.
El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un
cliente annimo: S que cree que entendi lo que piensa que dije, pero no estoy seguro de que se d cuenta de que
lo que escuch no es lo que yo quise decir.
El anlisis de requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a
nivel sistema y el diseo de software. El anlisis de requerimientos permite al ingeniero de sistemas especificar las
caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros
elementos del sistema y establece las restricciones que debe cumplir el software.
L.S.C.A. Ral2Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica

3.2. Fuentes de datos para el anlisis del sistema.

Fuentes de Datos para el anlisis de sistemas.
Las razones para iniciar un anlisis de sistema son:
* La necesidad de resolver un problema.
Este sucede cuando el sistema no funciona como se esperaba, entonces se recurre al analista de sistemas.
* Las nuevas necesidades.
Esto es cuando surgen nuevas disposiciones en la organizacin, puede tratarse de una nueva ley, practica contable,
practica administrativa, etc.
Para identificar las modificaciones o adiciones al sistema.
* La implantacin de una nueva tecnologa (tiende a reemplazar el equipo existente).
* Mejoramiento general de los sistemas.

Existen bsicamente tres fuentes de hechos dentro y alrededor de la organizacin:

1. El sistema actual.
Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de informacin en donde
anteriormente no haya existido ninguno. Con frecuencia se dedica una gran cantidad de tiempo investigando y
documentando el sistema anterior, pero un anlisis de ventajas y desventajas puede ayudar a determinar cundo y
qu tan extensamente debe estudiarse el sistema anterior.
Las principales ventajas de analizar el sistema anterior:
* Eficacia del sistema actual.
* Ideas de diseo.
* Reconocimiento de recursos.
* Conocimiento de conversin.
* Punto de partida comn.
Las principales desventajas de analizar el sistema anterior:
* Gastos
* Barreras Innecesarias.
* Conocer que el sistema automatizado ya exista.
* Conocer que el sistema automatizado no exista.
Para saber cuanto se ha invertido al sistema, como se documenta el sistema, si aporta pocos o muchos resultados y
si hay cuello de botella utilizar el diagrama de flujo de datos.
Aspectos a considerar en el sistema actual.
* Eficacia en el sistema actual.
Es una oportunidad para conocer si el sistema es satisfactorio, si requiere modificaciones menores, mantenimiento
o bien si hay que reemplazar al sistema.
* Ideas de diseo.
L.S.C.A. Ral3Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Permite o apoya al analista en ideas de diseo as como apreciar notablemente en como se hacen y en que forma las
actividadespor el sistema.
* Reconocimiento de recursos.
Le va a permitir al analista con que recursos se cuenta como lo que seria el personal, las instalaciones de
infraestructura, el equipo de computo y la formade operacin.
* Conocimiento de conversin.
Se coordinaran aquellas funciones que se dejaran hacer al sistema anterior, pero tengo que tener la observacin de
cmo se hacen, como sehacia antes y ahora. Para hacer algunas modificaciones, de cmo van a reaccionar los
usuarios.
2. Fuentes internas.
Las fuentes ms importante de hechos de estudio a disposicin del analista es la gente. Los requerimientos de
informacin puede ser planteado mejor por los usuarios de la informacin.
El papeleo describe la forma en que una organizacin esta estructurada.
La gente va a incluir a la gerencial, al personal de oficina o usuarios directos, que son los que se encargan de
procesar la informacin.
Ventaja: La gente nos dice que es lo que necesita.
Desventaja: Cuando necesitamos informacin la gente es mas cerrada por conservar su trabajo, etc.
Papeleo dentro de la organizacin o documentacin.
Aqu se utilizan tres tipos de documentos:
Documentos que describen como esta organizada la empresa. Ejemplo: Descripcin de puestos.
Documentos que describen lo que planea hacer la empresa. Ejemplo: Presupuestos, etc.
Documentos que describen lo que hace la empresa.
Ejemplo: Nominas, estados financieros, etc.
3. Fuentes externas.
La exploracin de otros subsistemas de informacin dentro de la organizacin puede ser una fuente til de
recopilacin de datos, procesamiento de datos o de ideas y tcnicas para el reporte de la informacin.
Aquellas organizaciones que estn fuera de la organizacin. Ejemplo : Clientes, proveedores, competencia, etc.
Revistas que nos dan informacin terica o practica que pueden ayudar al analista.
Los cursos, seminarios, talleres, etc.

3.3. Seleccin y diseo de instrumentos para la recopilacin de Informacin.

Recopilacin de Informacin
Recopilacin de datos: Deber dirigirse al registro de aquellos hechos que permitan conocer y analizar lo que
realmente sucede en la unidad o tema que se investiga. Esto consiste en la recoleccin, sntesis, organizacin y
comprensin de los datos que se requieren.
L.S.C.A. Ral4Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Se conocen dos tipos de fuentes:
1. Primarias: que contienen informacin original no abreviada ni traducida.
2. Secundarias: obras de referencia que auxilian al proceso de investigacin.
Se conoce otra divisin que se conforma por las siguientes fuentes:
-Documentales
-De campo.
Fichas bibliogrficas, de trabajo y hemerogrficas
Las fuentes de recoleccin de datos son todos los registros de aquellos hechos que permitan conocer y analizar lo
que realmente sucede en el tema que se investiga. Concluida la parte preparatoria de la investigacin se inicia la
fase de recopilacin de datos.
Para recabar la informacin existente sobre el tema, el investigador se auxilia de instrumentos como las fichas de
trabajo; hay diversos tipos de fichas de trabajo como:
Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un peridico,
para investigacin de campo, para observacin, fichas bibliogrficas y hemerogrficas.
Tcnicas para la recoleccin de datos o mtodos de obtencin de informacin pueden ser:
* Entrevista:
Esta herramienta consiste bsicamente en reunirse una o varias personas y cuestionarlas en forma adecuada para
obtener informacin. La entrevista es una conversacin dirigida, con un propsito especifico y que usa un formato
de preguntas y respuestas.
Con la entrevista se busca obtenerla opinin y sentimientosdel entrevistado acerca del sistema actual, los objetivos
de la organizacin y los personales. En ocasiones las opiniones de la persona pueden ser mas importantes y mas
reveladoras que los hechos, debido a que el entrevistado conoce mejor la organizacin que el analista.
Los objetivos son informacin importante que puede ser recogida en la entrevista. Los hechos pueden representar
los hechos pasados, los objetivos futuros. En la entrevista, se esta dando una relacin con alguien que
probablemente es extrao. Por tanto se necesita dar confianza, comprensin rpidamente pero al mismo tiempo, se
debe mantener el control de la entrevista.
Dentro de la entrevista se deber vender el sistema proporcionando al entrevistado informacin necesaria, las
entrevistas permiten la interaccin con las preguntas y sus significado. En una entrevista el analista tiene la
oportunidad de refinar una pregunta, definir un termino dudoso; cambiar el curso de las preguntas, responder una
apariencia confusa y en general controlar el contexto.
Cinco pasos para la preparacin de la entrevista.
Lectura del material a fondo.
Leer y comprender tanta informacin acerca del entrevistado y su organizacin como le sea posible. Este material
es obtenido, a veces, mediante una llamada rpida a la persona de contacto para pedirle un reporte de la funcin
que desempea la organizacin; pudiera ser esta una publicacin.
Este servir para conocer el lenguaje que usanlos miembros de la organizacin, as como es la organizacin.
L.S.C.A. Ral5Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Establecimiento de los objetivos de la entrevista.
Debe usarse la informacin de fondo y la propia experiencia para establecer los objetivos de la entrevista. En esta
punto deber incluir cada una de las reas de tratamiento de informacin y su comportamiento en la toma de
decisiones de las cuales deber hacer preguntas acerca de: fuentes de informacin, formatos de la informacin,
frecuencia de la toma de decisiones, cualidades de la informacin y estilo en la toma de decisiones.
Decidir a quien entrevistar.
Deben incluir personas clave de todos los niveles que sern afectados por el sistema de informacin de alguna
forma.
Prepare al entrevistado.
Prepare a la persona que va a ser entrevistada, dndole a conocer con anticipacin y que tenga tiempo para
prepararse para la entrevista. Las entrevistas deben de durar de 45 a una hora, mas tiempo hara de esta una
actividad difciltanto para el entrevistado como para el analista.
Decida el tipo de pregunta y su estructura.
Es necesario antes de realizar la entrevista, escribir preguntas para tratar de abarcar las reas principalesde la toma
de decisiones descubiertas cuando se averiguaron los detalles de la entrevista.
Tipo de preguntas
Preguntas abiertas:
Son aquellas preguntas que describen hechos o situaciones por parte del entrevistado con una gran cantidad de
detalles que a juicio del entrevistado son importantes.

Los beneficios de usar este tipo de preguntas son:

Pone confortable al entrevistado.
Permite que el analista recoja el vocabulario del entrevistado, el cual refleja su educacin, valores, actitudes y
creencias.
Proporciona riqueza de detalles.
Revela caminos para preguntas posterioresque podran haber quedado sin atacar
Hace que sea mas interesante para el entrevistado.
Permite la espontaneidad.
Se les puede usar en un aprieto si es que el entrevistador es tomado por sorpresa.
Las desventajas del uso de estas preguntas son:
El usar estas preguntas pueden dar como resultado muchos detalles revelantes.
Se puede perder el control en la entrevista.
Permitir respuestas que pueden llevarse demasiado tiempo para la cantidad de informacin til obtenida.
Puede demostrar que el entrevistado no esta preparado.
Puede dar la impresin de falta de objetivo en la entrevista.
L.S.C.A. Ral6Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Preguntas cerradas:
En las preguntas cerradas las respuestas posibles estn cerradas al entrevistado, debido a que solamente puede
responder con un numero finito, tal como ninguno, uno, o quince.
Una pregunta cerrada limita las respuestas disponibles al entrevistado. Tal vez esta familiarizado con las preguntas
cerradas que hay en los exmenes de seleccin mltiple de la escuela. Se le hace una pregunta y se lo dan cinco
respuestas, pero no se le permite que escriba su propia respuesta y que cuente como respuesta correctamente
contestada.
Ejemplo.
Qu tantos reportes genera en un mes?
Desde hace cuanto trabaja para Barkerloo Brothers?
Cul de las siguientes fuentes de informacin es mas valiosa para usted:
Formas de queja de clientes archivadas.
Interaccin cara a cara con el cliente.
La devolucin de mercanca por si misma.
Liste sus dos prioridades mxima para el departamento de ventas.
Quin recibe esta salida?
Un tipo especial de pregunta cerrada es la pregunta bipolar. Esto limita todava mas al entrevistado, permitindole
solamente una seleccin de algn extremo, tal como si o no, cierto o falso, de acuerdo o desacuerdo.
Usa usted una microcomputadora?
Esta usted de acuerdo o no en que las funciones de contestadora automtica valdran la pena?
Quiere usted recibir una impresin de computadora de su estado de cuenta cada mes?
su departamento de contabilidad proporciona transferencia de fondos electrnicay automtica de los cheques de
nomina para los empleados porhoras?
Estaforma estacompletamente llenada?
Los beneficios de usar estas preguntas cerradas de cualquier tipo incluyen:
Se ahorra tiempo.
Se facilita la comparacin de las entrevistas.
Se llega al punto.
Se mantiene control sobre la entrevista.
Se tratan muchos temas rpidamente.
Se obtienen datos revelantes.
Sin embargo, las desventajas del uso depreguntas cerradas son sustanciales. Incluyen:
Ser aburridas para el entrevistado.
No llegan a obtener grandes detalles (debido a que el entrevistador proporciona el marco de referencia para el
entrevistado.
Se pierden ideas principales por la razn anterior.
No se llega a establecer una relacin armoniosa entre el entrevistador y el entrevistador.
Entrevistas estructuradas:
En una entrevistaestructurada todo esta planeadoy el plan es seguido estrictamente. Laspreguntas cerradasson la
parte medular de una entrevista completamenteestructurada.
Entrevista no estructurada:
L.S.C.A. Ral7Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
En esta entrevista el tiempo no tiene lmite y por lo tanto es posible recolectar informacin de todo tipo y se
necesita la habilidad del entrevistador para improvisar y tocar reas no contempladas.
Las ventajas de la entrevista no estructurada son:
1) El entrevistador tiene mayor flexibilidad para cambiar los tiempos de la entrevista para que se puedan cubrir
todos los temas.
2) El entrevistador puede ahondar en reas que aparecen de manera espontnea durante la entrevista.
Las desventajas de la entrevista no estructurada son:
1) Uso ineficiente del tiempo por parte de los participantes de la entrevista.
2) El entrevistador puede introducir sus propios sesgos en las entrevistas o al notificar sus resultados.
3) Se puede obtener informacin no relevante y/o ajena al problema.
4) El anlisis de los resultados puede llevarse mucho tiempo.
5) Se necesita ms tiempo para reunir hechos esenciales.
* Cuestionario:
Estn constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por captulos o temtica
especfica.
Los cuestionarios son tcnicas de recopilacin de informacin que permiten que los analistas estudien actitudes,
creencias, comportamientos y caractersticas de varias personas principales en la organizacin que pueden ser
afectadas por los sistemas actuales y enproceso.

Las actitudes son lo que la gente de la organizacin dice que quiere.

Las creencias son lo que la gente piensa que es, de hecho cierto.
El comportamiento es lo que hacen los miembros de la organizacin.
Las caractersticas son propiedades de las personas o cosas.

L.S.C.A. Ral8Monforte Chuln

MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica

Las respuestas obtenidas mediante cuestionarios usando preguntas cerradas pueden ser cuantificadas.
Las respuestas a cuestionarios de preguntas abiertas sonanalizadas e interpretadasde otras formas.
Las preguntas sobre actitudes y creencias son notablemente sensibles a la redaccin escogida por el analista.

Los cuestionarios pueden ser usados para determinar que tan amplio o limitado es el sentimiento expresado en una
entrevista. Pueden ser usados para investigar a una gran muestra de usuarios de un sistema, para tratar de encontrar
problemas o recoger cosas importantes antes para realizar la entrevista.
El cuestionario requiere un amplio tiempo de planeacin.
Que es lo que debo hacer para usar un cuestionario?.
Las personas a quien debe de preguntarse estn ampliamente dispersas (diferentes lugares dentro de la
organizacin).
Se debe conocer el grado en que se aprueba o desaprueba una caracterstica particular del sistema propuesto
dependiendo de la cantidad de personas:
Se hace un estudio exploratorio para medir la opiningeneral; darle al proyecto una direccin especifica:
Se debe utilizar el cuestionario para asegurarse de cualquier problema en el sistema actual que este
identificado.

Definicin de preguntas en el uso del cuestionario:

La diferencia entre las preguntas de una entrevista y un cuestionario; se encuentran en que el cuestionario exige al
analista ser muy claro; el flujo de preguntas deber ser coherente; las preguntas del interlocutor anticipadas y la
administracin del cuestionario planeada a detalle.
Los tipos bsicos de preguntas usadas son las abiertas y las cerradas:
Preguntas abiertas:
Son aquellas quedejan todas las posibles opciones de respuesta al interlocutor; es decir; usa trminos como
describe; en su opinin; que siente; etc. Cuando considere este tipo de preguntas anticipe el tipo de respuesta a
obtener; para u correcta interpretacin. Por lo tanto si escribe una pregunta de este tipo debe ser lo suficientemente
estrecha para guiar al interlocutor a que responda de forma especifica.
Ejemplo:
Cuales son los problemas ms frecuentes que presenta su sistema de informacin?
a___________________________________________________________________________________________
________________________
b___________________________________________________________________________________________
________________________
c___________________________________________________________________________________________
________________________
De los problemas listados anteriormente, cual es el que se presenta con mayor frecuencia?
____________________________________________________________________________________________
__________________________________________________________________________________
L.S.C.A. Ral9Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Porque?
____________________________________________________________________________________________
____________________________________________________________________________________________
________________________________________________
Preguntas cerradas:
Conocidas tambin como enunciados. Son aquellas que se limitan o cierran las opciones de respuesta disponibles.
Ejemplo:
De acuerdo a sus necesidades marque con una cruz el nombre del software que usa para sus actividades diarias con
mayor frecuencia:
( ) Word
( ) Visual fox
( ) Excell
Turbo C ( )
( ) Power point
( ) Java
Note que no se solicita preferencia y se limita solo a uno.
Las preguntas cerradas deben ser usadas cuando el analista sea capaz de generar listas donde todas las reapuestas
posibles ala pregunta se involucren y cuando todas las respuestas listadas sean mutuamente excluyentes con el
objetivo de seleccionar una. Debe cuidarse al generar preguntas cerradas de que la lista de respuesta sea limitada;
ya que de no hacerlo as; esta lista se volvera infinita. Es necesario usar preguntas cerradas cuando se va analizar
un gran numero de personas.
Formato del cuestionario
Deje bastante espacio en blanco alrededor del cuestionario.
Use papel blanco o muy claro.
Deje suficiente espacio para las respuestas, usar de 3 a 5 lneas.
Pida que las respuestas sean encerradas en un circulo.
Use adjetivos que le ayudena determinar el formato.
Respuestas escritas para calcular el espacio.
Sea consistente en el estilo (orden o sombreado de preguntas)
Orden en las preguntas.
Las preguntas importantes para el interlocutor van primero.
Agrupe conceptos de contenido similar.
Emplee tendencias asociativas de los interlocutores.
Ponga primero los termino menos controvertidos.
* Encuesta:
La recoleccin de informacin se hace a travs de formularios, los cuales tienen aplicacin en aquellos problemas
que se pueden investigar por mtodos de observacin, anlisis de fuentes documentales y dems sistemas de
conocimiento.
Esta tcnica de recoleccin de informacin es la ms usadas, a pesar de que cada vez pierde mayor credibilidad por
el sesgo de las personas encuestadas, la encuesta se fundamenta en el cuestionario o conjunto de preguntas que se
preparan con el propsito de obtener informacin de las persona.

L.S.C.A. Ral10
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
* Observacin:
La observacin esotra tcnica til para el analistaen su proceso de investigacin, consiste en observar a las
personas cuando efectan su trabajo. Como tcnica de investigacin, la observacin tiene amplia aceptacin
cientfica.
La observacin es una tcnica de observacin de hechos durante la cual el analista participa activamenteo acta
como espectador de las actividades llevadas a cabo por una persona para conocer mejor su sistema.
El propsito de la observacin es mltiple, permite al analista determinar que se esta haciendo, como se esta
haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, donde se hace y porque se hace.
Tipos de observacin
El analista puede observar de tres maneras bsicas:

Puede observar a una persona o actividad sin que elobservado se de cuenta y sin interactuar por parte del
propio analista.

El analista puede observar una operacin sin intervenir para nada pero estando la persona observada
enteramente conciente de la observacin.

Se puede observar y estar en contacto con las personas observadas. La interrogacin puede
consistirsimplemente en preguntar respecto a una actividad especifica, pedir una explicacin, etc.
La observacin puede emplearse para verificar los resultados de una entrevista, o bien como preparacin de la
misma . Tambin es otra tcnica valiosa para recopilar datos que implican relaciones. La observacin tiende a
adquirir mayor sentido al nivel tcnico del procesamiento de datos, donde las tareas se cuantifican mas fcilmente.
Entre estas tareas encontramos la recopilacin, acumulacin y transformacin de los datos.
Pasos de la observacin:
1. Determinar y definir aquelloque se va a observar.
2. Estimar el tiempo necesario de observacin.
3. Obtener la autorizacin para llevar a cabo la observacin.
4. Explicar a las personas que van a ser observadaslo que se va hacer y las razones para ello.
Conduccin de la observacin
1. Familiarizarse con los componentes fsicos del rea inmediata a observar.
2. Mientras se observa,medir el tiempo en forma peridica.
3. Anotar lo que se observa lo ms especficamente 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
queimplique un juicio de valor.
5. Observar las reglas de cortesa y seguridad.

Seguimiento de la observacin.

L.S.C.A. Ral11
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
1. Documentar y organizar formalmente las notas e impresiones entre los analistas.
2. Revisar los resultados y conclusiones junto con la persona observada, el supervisor inmediato y posiblemente
otro analista.

La observacin le permite al analista de sistemas generar experiencia en cuanto a observar y como observar.

Se recomienda el uso de la observacin con otras tcnicas para maximizar su efectividad, sobre todo cuando se
trata de analistas con poca experiencia.
Muestreo y recopilacin de documentos.
Dos tcnicas adicionales a disposicin del analista, particularmente en las tareas de indagacin de hechos, son el
muestreo y la recopilacin de documentos. Ambas tcnicas estn orientadas a los papeles y documentos
almacenados en toda la organizacin. Ambas tcnicas proporcionan una fuente de informacin que no puede
obtenerse con ningn otro enfoque de indagacin de hechos.
Anlisis e interpretacin de informacin:
La interpretacin de los resultados de la indagacin lleva inmediatamente a la solucin. El anlisis del instrumento
de recoleccin de informacin de campo (encuesta), fue utilizando el anlisis individual de preguntas que se realiza
con base en los porcentajes que alcanzan las distintas respuestas de cada pregunta.
Para llevar a cabo este tipo de anlisis se diseo una forma donde se tabulan las respuestas en base a la cantidad de
personas que contestaron cada respuesta y el porcentaje que representa del total de la muestra.
Redaccin y presentacin del informe:
El objetivo del informe es presentar a los lectores el proceso que se realiz para presentar una solucin al problema
planteado, para lo cual es necesario hacer la presentacin del problema, los mtodos empleados para su estudio, los
resultados obtenidos, las conclusiones a las que se llegaron y las recomendaciones en base a estas.
Con respecto a la estructura del informe, sta es sencilla y sigue fielmente los pasos fundamentales del diseo de la
investigacin, ya que el informe debe ser la respuesta a lo planteado por el diseo de investigacin.
El formato y contenido de este reporte incluye:
1.- Una nueva exposicin de la razn y alcance del anlisis
2.- Una lista de los principales problemas identificados
3.- Una presentacin de todos los requerimientos de los usuarios
4.- Una planeacin de todas las suposiciones hechas por el analista de sistemas para el anlisis de datos.

3.4. Captura de requisitos candidatos.

El propsito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto.

L.S.C.A. Ral12
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un
modelo del negocio o partimos de uno ya desarrollado. En otros casos si es un sistema acotado que no da soporte
al negocio podemos partir de un modelo de objetos sencillo como un modelo del dominio.
En otros casos el cliente puede ya haber desarrollado una especificacin completa de requisitos no basada en
objetos, de la cual podemos partir.
En forma tpica, el flujo de trabajo de requisitos incluye los siguientes pasos: Enumerar los requisitos candidatos.
Comprender el contexto del sistema. Capturar requisitos funcionales. Capturar requisitos no funcionales.
Enumerar los requisitos candidatos
La lista de caractersticas deseadas del sistema constituyen los requisitos candidatos. De cada caracterstica se
registra:
Nombre corto.
Descripcin.
Estado (propuesto, aprobado, incluido, o validado).
Coste estimado de implementacin (en trmino de tipos de recursos y horas-hombre).
Prioridad (crtico, importante, o secundario).
Nivel de riesgo asociado a la implementacin de la caracterstica (crtico, significativo, ordinario).
Estos valores se utilizan para estimar el tamao del proyecto y decidir cmo dividirlo en secuencia de
iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en que iteracin se
implementar la caracterstica.
Comprender el contexto del sistema
Hay por lo menos dos aproximaciones para expresar el contexto de un sistema:
modelado del dominio y modelado del negocio.
Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio relacionados
entres s.
Un modelo del negocio es ms amplio. Describe los procesos con el objetivo de comprenderlos. El modelado
del negocio especifica que procesos de negocio
soportar el sistema.
Capturar requisitos funcionales
Los requisitos funcionales son capturados por medio de casos de uso, que conforman el modelo de casos de uso.
Los casos de uso tambien capturan requisitos no funcionales especficos de un caso de uso determinado.
Capturar requisitos no funcionales
Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la
implementacin, rendimientos, etc.
Hay requisitos no funcionales especficos para un caso de uso y otros genricos para la aplicacin. Los que son
especficos para un caso de uso, pueden documentarse junto con el caso de uso correspondiente. Los que son
ms genricos se documentan por medio de una lista de requisitos adicionales.

2.5. Seleccin de metodologa de desarrollo.

L.S.C.A. Ral13
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Seleccin de las metodologas
El acelerado desarrollo de software en la actualidad y la necesidad de que los proyectos sean concluidos
exitosamente siendo un producto de gran valor para los clientes, generan grandes cambios en las metodologas
adoptadas por los equipos para cumplir sus objetivos, puesto que unas se adaptan mejor que otras al contexto del
proyecto brindando mejores ventajas. Debido a ello es de vital importancia la seleccin de una metodologa robusta
que ajustada en un equipo cumpla con sus metas, y satisfaga mas all de las necesidades definidas al inicio del
proyecto.

En el momento de seleccionar una metodologa para aplicar en la construccin de un sistema es necesario tener en
cuenta las caractersticas del proyecto y del equipo y ser adaptada al contexto del mismo. Una de las caractersticas
principales a tener en cuenta es la complejidad del sistema a desarrollar, es decir, es necesario valorar la
complejidad del proceso a automatizar, la cantidad de requisitos que deben ser implementados en el sistema y la
complejidad y cantidad de informacin que se maneja en el proceso. La complejidad puede ser alta, media o baja
en dependencia de las caractersticas antes mencionadas. Por ejemplo un proceso econmico de una empresa es
ms complejo que el proceso de marketing de la misma.

En el rea de informtica los sistemas que se realizan responden a peticiones no solo del propio centro de trabajo
sino de otras reas que necesitan automatizar su gestin.

Criterios de seleccin de Metodologas de desarrollo de Software

La buena seleccin metodologas; y tambin el buen desarrollo software; es producto o resultado de una buena
seleccin de estndares y normas para trabajar mediante una Metodologa de Desarrollo de Software fija. En la
actualidad, la experiencia en el rea de la Informtica me ha permitido comprender que el diseo y el desarrollo de
software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodologa definida.
Sabemos por conocimiento puramente profesional que las metodologas tradicionales se basan en normas
provenientes de estndares seguidos por el entorno de desarrollo; con una fuerte y cierta resistencia a los cambios
donde todo se encuentra impuestas externamente y poseen un proceso muy controlado, con numerosas normas.
Pero eso no es todo, dichas metodologas tradicionales necesitan un contrato prefijado donde el cliente interacta
con el equipo de desarrollo mediante reuniones con grupos grandes los cuales requieren de mas artefactos y el
resultado final se basa en la arquitectura del software es esencial.
Las metodologas agiles son todo lo contario. Se basan en heursticas provenientes de prcticas de produccin de
cdigo; total y completamente preparados para cambios durante el proyecto las cuales son impuestas internamente
por el equipo con proceso menos controlado, con pocos principios. As como tambin con un contrato flexible e
incluso inexistente, donde el cliente es parte del desarrollo y los grupos son pequeos por lo que se incluyen pocos
artefactos y existe una menor nfasis en la arquitectura del software.
L.S.C.A. Ral14
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Todo lo anteriormente mencionado, me ayuda a concluir algunas cosas. Es claro que antes de desarrollar un
producto software, necesitamos comprender la visin del producto, la cual podemos obtenerla en base a la
vinculacin con el cliente, y un previo establecimiento del modelo de ciclo de vida del software, as como la
gestin de los requisitos, el plan de desarrollo y tambin la parte de la integracin del proyecto. Esto nos permitir
tener un amplio panorama donde podremos ver las medidas de progreso del proyecto, as como las mtricas para
evaluar la calidad, las maneras de medir el riesgo, y saber con ello como gestionar los cambios y as establecer una
lnea de meta; lo que nos ayuda para poder seleccionar una metodologa de desarrollo de software; pues al ver lo
que realmente necesitamos, podremos ver que es lo que nos proporciona una metodologa tradicional y una gil,
independientemente de cul seleccionemos para llevar a cabo el desarrollo de nuestro software, ya que tenemos
variedades de metodologas tanto tradicionales como agiles.
Lo que se debe tener claro es que, para tener una seleccin optima de metodologa, este aspecto no ha sido tratado
de manera adecuada, sobre todo en el mbito de las metodologas tradicionales, y en el caso de las giles no existe
un criterio unificado para poder llevar una debida seleccin de la metodologa a tratar para poder desarrollar un
software de calidad. Ahora bien por lo anteriormente mencionado podemos tener una gua de orientacin, o una
formulacin inicial para la deba seleccin, el cual puede llenar las expectativas base del cliente, que es un coste
del desarrollo inicial relativamente bajo, con un software fcil de mantener, portable a nuevo hardware y sobre todo
que haga lo que el cliente quiere, ya que en base a la informacin existente a la fecha y a la experiencia personal,
puedo decir que la formulacin para poder seleccionar una buena metodologa se basa en una buena seleccin por
criterios de expertos y por conocimiento de desarrollo en la rama de los analistas y diseadores que nos guie a la
pura necesidad del cliente y la metodologa que se acople a dicha necesidad.
El desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una
metodologa defi nida. Al respecto algunos autores defi nen una metodologa como una coleccin de
procedimientos, tcnicas, herramientas y documentos auxiliares que ayudan a los desarrolladores de software en
sus esfuerzos por implementar nuevos sistemas de informacin. En las dos ltimas dcadas, respecto a estas
metodologas de desarrollo de software se ha entablado un intenso debate entre dos grandes corrientes. Por un lado,
las denominadas metodologas tradicionales, centradas en el control del proceso, con un riguroso seguimiento de
las actividades involucradas en ellas. Por otro lado, las metodologas giles, centradas en el factor humano, en la
colaboracin y participacin del cliente en el proceso de desarrollo y a un incesante incremento de software con
iteraciones muy cortas. El artculo presenta una propuesta, en medio de este debate, para seleccionar una
metodologa de desarrollo de software.

3.6. Modelo del negocio.

Modelo de negocios
Un modelo de negocio, tambin llamado diseo de negocio o diseo empresarial, es el mecanismo por el cual
un negocio busca generar ingresos y beneficios. Es un resumen de cmo una compaa planifica servir a
sus clientes. Implica tanto el concepto de estrategia como el de implementacin. Comprende el conjunto de las
siguientes cuestiones:
* Cmo seleccionar sus clientes
* Cmo define y diferencia sus ofertas de producto
* Cmo crea utilidad para sus clientes
L.S.C.A. Ral15
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
* Cmo consigue y conserva a los clientes
* Cmo sale al mercado (estrategia de publicidad y distribucin)
* Cmo define las tareas que deben llevarse a cabo
* Cmo configura sus recursos
* Cmo consigue el beneficio

En una definicin ms actual, podemos decir que un "modelo de negocio describe el modo en que una organizacin
crea, distribuye y captura valor". Esta definicin conlleva un tratamiento del concepto que va mucho ms all de la
generacin de ingresos o gastos, y divide el concepto en partes ms pequeas (p.e. Segmentos de clientes,
proposicin de valor, canales, relacin con los clientes, esquema de ingresos, recursos clave, actividades clave,
socios clave y estructura de costos) que pueden ser abordadas, tanto de un modo individual, como analizando como
se configuran las relaciones entre ellas.

Tipos de modelos de negocios

Generalmente, los modelos de negocio de las compaas de servicio son ms complejos que las de fabricantes y
vendedores. El modelo ms viejo y bsico es el del tendero. Este modelo consiste en instalar una tienda en el sitio
donde deberan estar los clientes potenciales y desplegar la oferta de un producto o servicio.

A lo largo de los aos los modelos de negocio han llegado a ser mucho ms sofisticados. El modelo del cebo y
el anzuelo (tambin llamado el de las cuchillas y la maquinilla o el de los productos atados) fue introducido a
principios del siglo XX. Consiste en ofrecer un producto bsico a un precio muy bajo, a menudo a prdidas (el
cebo) y entonces cobrar precios excesivos por los recambios o productos o servicios asociados. Algunos ejemplos
son los de la maquinilla de afeitar (cebo) y las cuchillas (anzuelo); las impresoras (cebo) y los cartuchos de tinta
(anzuelo); y las cmaras de fotos (cebo) y el revelado de fotografas (anzuelo). Una variante interesante de este
modelo es un desarrollador de software que ofrece gratis su lector de textos pero cobra muchos cientos de dlares
por su procesador de textos.

En los aos 1950, aparecieron nuevos modelos de negocio de la mano de McDonald's y Toyota. En los aos 1960,
los innovadores fueron Wal-Mart y los hipermercados. En los 1970 nacieron nuevos modelos de negocio
introducidos por Federal Express y Toys "" Us; en los 1980 por Blockbuster, Home Depot, Intel, y Dell
Computer; en los 1990 porSouthwest Airlines, eBay, Amazon.com, y Starbucks. Cada una de estas innovaciones en
modelos de negocio pueden proporcionar a una compaa una ventaja competitiva. Pero los tiempos estn
cambiando y las compaas deben replantearse continuamente su diseo de negocio, cambiando sus modelos al
L.S.C.A. Ral16
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
ritmo en que el valor cambia de un sector industrial a otro. Hoy en da, el xito o fracaso de una compaa depende
sobre todo de cmo se adapta su diseo de negocio a las prioridades de sus clientes.

El modelo de negocio, es aquel en el cual se planifica de manera ordenada y sistemtica todo el proceso que ha de
llevarse a cabo en el establecimiento y desarrollo de un negocio, por tanto debes de incluir desde el aporte de sus
accionistas hasta contemplar todos los posibles desembolsos necesarios para poder operar, tales como licencias,
maquinarias y equipos, capacitacin, estudio de mercado, etc. Con una Visin clara, objetivos bien definidos y una
buena Misin, se han de elaborar los forecast(pronsticos) y presupuestos, Cash Flow (flujos de caja), tanto como
sean necesarios para el buen desenvolvimiento, es decir, es mejor cometer un error en Papeles y no en la realidad,
ya que es ms complejo un modelo de negocio en una compaa de Servicios, que si fuera una de Fabricacin o
distribucin de productos.

3.7. Modelo del dominio.

Modelo de Dominio.
Un Modelo de Dominio es un artefacto de la disciplina de
anlisis, construido con las reglas de UML durante la fase de
concepcin, en la tarea construccin del modelo de dominio,
presentado como uno o ms diagramas de clases y que
contiene, no conceptos propios de un sistema de software sino
de la propia realidad fsica.

Los modelos de dominio pueden utilizarse para capturar y

expresar el entendimiento ganado en un rea bajo anlisis
como paso previo al diseo de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales
utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el
sector industrial o de negocios al cual el sistema va a servir.

El siguiente diagrama es un pequeo ejemplo de Modelo de

Dominio, en este caso, referido al Metro o sistema de
transporte subterraneo de una ciudad cualquiera.

Figura 3.7 Ejemplo de Modelo de Dominio de un

sistema de subterrneo.

En este diagrama se ve que un Usuario del Metro tiene cero o ms boletos, comprados estos en una maquina de
Venta de Boletos; dicha maquina crea los boletos los cuales son consumidos en un viaje, el cual tiene una
L.S.C.A. Ral17
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
estacin de origen y otra de destino. Finalmente se ve que una estacin tiene una o ms maquinas de venta as
como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto
detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender
donde va a funcionar el sistema que estamos diseando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseo del sistema. Esto es as ya que
cuando se realiza la programacin orientada a objetos, se supone que el funcionamiento interno del software va a
imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una
primera versin del sistema.

En la aproximacin llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo
Independiente del Computador o CIM, por sus siglas en ingls. El CIM es el que da inicio al proceso de desarrollo
y ocupa el rol, tanto de modelo de requisitos como de modelo anlisis.

Por otra parte, cuando se sigue una aproximacin Centrada en Casos de Uso como RUP/UP, el modelo de dominio
es utilizado como entrada en la tarea anlisis de los casos de uso en la construccin de los llamados escenarios de
anlisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagnico en el desarrollo moderno
de software y constituye un artefacto que vale la pena tener en nuestros proyectos.

3.8. Validacin de requerimientos.

Los requisitos una vez definidos necesitan ser validados.Es necesario asegurar que el anlisis realizado y los
resultados obtenidos de la etapa de definicin de requisitos son correctos. Pocas son las propuestas existentes que
ofrecen tcnicas para la realizacin de la validacin y muchas de ellas consisten en revisar los modelos obtenidos
en la definicin de requisitos con el usuario para detectar errores o inconsistencias.
El proceso de validacin de requisitos debe realizarse o de lo contrario se corre el riesgo de implementar una mala
especificacin, con el costo que eso conlleva.
L.S.C.A. Ral18
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Los parmetros a comprobar por la especificacin son:
1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista
distintos y necesitar otros requisitos.
2. Consistencia: No debe haber contradicciones entre unos requisitos y otros.
3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos,
deben estar disponibles todos los requisitos de la iteracin en curso.
4. Realismo: Se pueden implementar con la tecnologa actual.
5. Verificabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.
Validacin de Requisitos. La validacin de requisitos tiene como misin demostrar que la definicin de los
requisitos define realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999). El proceso de
validacin de requisitos comprende actividades que generalmente se realizan una vez obtenida una primera versin
de la documentacin de requisitos.
La actividad de validacin tiene como entrada el
documento de requisitos, los estndares relacionados y el
conocimiento de la organizacin, y como salida se obtiene
una lista de problemas y una lista de acciones
recomendadas.

Figura 3.8 La validacin en el proceso de requisitos.

Tcnicas de validacin de requisitos:

Reviews o Walk-throughs: Est tcnica consiste en la
lectura y correccin de la completa documentacin o
modelado de la definicin de requisitos. Con ello
solamente se puede validar la correcta interpretacin de la
informacin transmitida. Ms difcil es verificar consistencia de la documentacin o informacin faltante.
Auditoras: La revisin de la documentacin con esta tcnica consiste en un chequeo de los resultados contra una
checklist predefinida o definida a comienzos del proceso, es decir slo una muestra es revisada.
Matrices de trazabilidad: Esta tcnica consiste en marcar los objetivos del sistema y chequearlos contra los
requisitos del mismo (Durn, Bernldez, Ruz &Toro, 1999). Es necesario ir viendo qu objetivos cubre cada
requisito, de esta forma se podrn detectar inconsistencias u objetivos no cubiertos.
Prototipos: Algunas propuestas se basan en obtener de la definicin de requisitos prototipos que, sin tener la
totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del
sistema con el usuario (Olsina,1999). Esta tcnica tiene el problema de que el usuario debe entender que lo que est
viendo es un prototipo y no el sistema final.

2.9. Definicin de propuesta de solucin. Requisito (sistemas).

Propuesta de la solucin
L.S.C.A. Ral19
Monforte Chuln
MORCH Systems

Instituto Tecnolgico Superior de Coatzacoalcos

Anlisis y Modelado de Sistemas de Informacin - 5o Sem Ingeniera en Informtica
Esta fase se ocupa de la reunin y estudio a detalle de los datos del sistema en operacin y la especificacin de los
nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado
del anlisis. Con la recopilacin de datos se completan los datos resultantes de la fase 1, aadiendo detalles sobre el
sistema actual. Son medios comunes para acometer tal recopilacin: Las entrevistas, cuestionarios, encuestas a
usuarios finales, as como tambin, las consultas a documentos y manuales que contengan lineamientos de
funcionamiento o normas de procedimientos de operacin. Existen varias tcnicas y herramientas tiles para el
anlisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida
de las funciones de la organizacin de manera grafica. Estos diagramas sirven para desarrollar el llamado
diccionario de datos, el cual contiene la definicin de los datos usados en el sistema, as como sus caractersticas de
tipo, tamao, limitaciones o especificaciones especiales. La documentacin de la etapa de anlisis recoge la
descripcin del sistema de informacin en uso, los requerimientos para el nuevo sistema y un probable plan de
desarrollo en un reporte dirigido ala gerencia. Este reporte permite tomar la decisin de proseguir o no con el
proyecto. El aspecto ms importante de cualquier propuesta es identificar y comprender el problema que el cliente
busca resolver. Uno de los puntos del desarrollo de una propuesta de solucin es presentar una nocin propia del
problema, as como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor.
Para ello, se presentara lo que implica una descripcin de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las caractersticas del problema.
4.- Las soluciones alternas consideradas.
5.- La solucin o la tcnica seleccionada

Lema:
El mejor amigo del estudiante es el conocimiento, pues en el encontraras que hacer en el maana. Y recuerda un licenciado no es una
copia, es original y se atreve a cambiar una realidad, no importa el tiempo o el espacio, todo es posible mientras creas que es as.
Gracias a Dios: Ya vas hacer profesionista, ser profesional es parte de una mejor calidad de vida para ti y para toda tu familia, lograrlo es
una gran satisfaccin de manera espiritual, emocional, social y laboral; bscalo, esfurzate y disfrtalo; y veras que ser profesionista es
excelentemente profesional.
MORCH Systems.

L.S.C.A. Ral20
Monforte Chuln
MORCH Systems