Cuaderno de Apuntes Ingeniería de Requerimientos EIT 112 PDF

Vicerrectoría Académica
Cuaderno de Apuntes – 2009
I. IDENTIFICACIÓN
NOMBRE DEL MÓDULO: INGENIERÍA DE REQUERIMIENTOS.

UNIDAD DE COMPETENCIA: Al finalizar el módulo los participantes serán capaces de:
Realizar un análisis de requerimientos para el desarrollo de sistemas computacionales según
necesidades del cliente, aplicando técnicas y estrategias adecuadas de recolección de datos.
DURACIÓN: 90 horas pedagógicas
II. DESCRIPCIÓN POR ÁREA DE FORMACIÓN Y PRERREQUISITO
ÁREA DE FORMACIÓN: Especialidad

UBICACIÓN EN LA MALLA: Primer semestre
PRERREQUISITO: No tiene
III. UNIDADES DE APRENDIZAJE
PRIMERA UNIDAD LA INGENIERÍA DE REQUERIMIENTOS Y SU ROL EN LA ORGANIZACIÓN
APRENDIZAJES ESPERADOS:
 Reconocen la importancia de la Ingeniería de Requerimientos.
 Reconocen el rol del Foda, como parte de la planificación estratégica del software.
 Identifican la relación complementaria entre Foda e I. R.
 Distinguen la diferencia entre SIA v/s Sistemas Computacionales.
 Definen los conceptos de requerimientos relevantes.
 Identifican al personal involucrado.
SEGUNDA UNIDAD: ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
 Identifican y validan usuarios involucrados.
 Analizan y acotan el problema presentado.
 Definen en conjunto con usuarios los requerimientos.
 Validan y proponen requerimientos adecuados.
 Definen la frontera de los requerimientos.
 Estudian la factibilidad de la solución
TERCERA UNIDAD: TÉCNICAS Y HERRAMIENTAS ASOCIADAS
 Definen focus group, a tratar según la frontera del proyecto.
 Analizan distintas técnicas de recolección de datos según el focus group, detectado.
 Preparan y aplican entrevistas y cuestionarios.
 Aplican lluvias de ideas a un problema determinado.
Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP. 1
 Reconocen la importancia de la observación en terreno.

 Analizan y comparan distintas técnicas.
 Aplican herramientas graficas para modelamiento.
CUARTA UNIDAD: SELECCIÓN Y APLICACIÓN DE TÉCNICAS SEGÚN PROYECTO
 Seleccionan la técnica según el proyecto a desarrollar.
 Definen las técnicas adecuadas para validar la solución.
 Construyen un modelo de técnicas y las aplican.
 Tabulan los datos y toman decisiones.
 Construyen un informe final del proyecto.
IV. EVALUACIÓN DE UNIDADES
Unidad 1 Al menos 1
Unidad 2 Al menos 2
Unidad 3 Al menos 2
Unidad 4 Al menos 2
Examen de Módulo Práctico
V. BIBLIOGRAFÍA
-Kendall y Kendall. Análisis y diseño de sistemas, 6º edición. Pearson, 2005. ISBN: 9702605776
-McLeod, Raymond, Jr. Sistemas de información gerencial 7º edición. Prentice Hall. 2007. ISBN 10: 970-17-0255-7.
VI. CLASE A CLASE
PRIMERA UNIDAD: LA INGENIERÍA DE REQUERIMIENTOS Y SU ROL EN LA ORGANIZACIÓN
CLASE 1
APRENDIZAJES ESPERADOS CONTENIDOS

 Reconocen la importancia de la Ingeniería de Requerimientos.  Conceptos básicos.
 Importancia de la I. R.
INTRODUCCION:
Cuántas veces hemos escuchado por ahí decir, a los usuarios que el sistema es malo, no funciona o simplemente se cae a cada rato.
En realidad lo que ocurre es que el sistema no es malo, no es un tema de programa ni de código, sino más bien lo podemos definir
como una distancia entre lo que el usuario desea y lo que realmente el sistema esta realizando. Por ejemplo:
“imagínese usted que un usuario le ha solicitado arreglar su casa. Usted como buen ingeniero trabaja durante varias semanas
arreglándola y una vez terminada se la presenta y este le dice que ese arreglo no le satisface… por lo tanto no le va a pagar
nada”….
Todo su esfuerzo fue en vano… y lo más probable que ocurra, es que el usuario comente que la casa quedo mal…y que su trabajo
fue pésimo…
En realidad la casa no es mala, ni el trabajo fue pésimo, lo que sucede es que usted se lanzó a arreglar la casa sin antes haber
consultado al usuario en detalle, ¿Cuáles son los arreglos que el deseaba hacerle? Y además usted no formalizó dicha petición.
¡¡ En el desarrollo de sistemas ocurre exactamente lo mismo!!
Muchos informáticos, confunden el desarrollo de un sistema, con una tarea vital de programar, sin preguntar.
La ingeniería de requerimientos, tiene como objeto disminuir la distancia entre usuario y programas, de tal forma que el software,
como producto final refleje fielmente las necesidades del usuario, asegurando así el éxito de nuestro trabajo.
Actividades:
Reúna un grupo de cinco personas y elabore un plan sencillo para preparar una cazuela. Terminada la reflexión, pregunmte al docente
cómo le gusta la cazuela.
Material complementario:
Analice y comente:
Cuando se habla de la crisis del software, esta no se refiere de modo alguno al código de programa o a la plataforma que se a utilizado
para diseñar el sistema. Se refiere al método que ha utilizado el informático para capturar los requerimientos, esta situación nos podría
llevar a concluir que a pasar que el sistema funciona correctamente, no cumple con las expectativas del cliente por lo tanto no sirve.
La falta de coherencia entre software y requisitos planteados por el usuario es una de las principales causas de la falta de calidad y por
lo tanto el fracaso de los programas y sistemas que se están desarrollando.
Esta apreciación nos indica una vez más a reflexionar sobre funcionalidad y efectividad; pues el sistema funciona correctamente pero no
cumple con las expectativas del cliente que lo ha solicitado, por lo tanto en resumen no funciona.
Generalmente esto ocurre debido a que muchas organizaciones exigen productos rápidos no dejando tiempo para desarrollar un buen
análisis o también suele ocurrir que el informático evita analizar al usuario ya que supone su total disposición a trabajar en la explotación
del sistema.
Suele pensarse además que por el hecho de estar ocupando el cargo o ejerciendo la función el usuario esta disponible y motivado a
trabajar de manera pro activa.
En este aspecto los informáticos deben tener sumo cuidado ya que muchos usuarios tienen intereses distintos a la organización o
muchas veces ocurre que dentro de la organización existen formas diversas de interpretar el mismo trabajo por lo tanto, nos podemos
encontrar con distintas organizaciones dentro de una empresa lo que puede afectar nuestras expectativas de sistema.
CLASE 2

 Reconocen el rol del FODA, como parte de la planificación estratégica del Importancia de la I.R.
software. Importancia del FODA.
 Identifican la relación complementaria entre FODA e IR
Frente a esta situación nuestro informático, debe como tarea vital conocer la organización, en su todo, con el fin de conocer:
 ¿Cómo son cada uno de sus procesos, especialmente aquellos que le dan la razón de ser?
 ¿Qué información necesitan cada uno de ellos para operar?
 ¿Quiénes los operan?
 ¿Por qué los operan de tal o cual manera?
Investigue en Internet sobre FODA.

Construya una matriz considerando los siguientes aspectos de su persona:
 Fortaleza; ¿Qué es lo que tengo y los demás no tienen y que yo hago bien?..
 Oportunidad; ¿Qué ventajas tengo con respecto a mis competidores?
 Debilidades; ¿Qué no tengo pero que mis competidores si tienen?
 Amenazas; ¿A qué estoy expuesto sí no me actualizo?
En su investigación puede usted establecer una relación entre el análisis foda y la ingeniería de requerimientos para corregir sus
debilidades y potenciar sus fortalezas?
Material complementario:
Las dos herramientas anteriores, son la base, para desarrollar una buena estrategia de sistemas. Sin embargo muchos alumnos aun
confunden este concepto.
¡¡Hablar de sistemas y sistemas computacionales no es lo mismo!!
La relevancia entre uno y otro se debe al grado de integración que se le debe otorgar a nuestro usuario.
El rol que le asignemos a este usuario nos permitirá determinar, si el sistema que vamos a desarrollar es relevante o no para la
organización. Y en esta FACE el trabajo grupal es vital para el éxito de nuestro proyecto.
¿Cuándo es relevante desarrollar un sistema?

Cuando la información que se debe digitalizar es vital para la organización, pero además existen usuarios interesados en participar de
esta digitalización.
El rol del informático es detectar estos puntos críticos, y definir el equipo de trabajo que participará en dicho proyecto, no solo deben
participar expertos sino que también todos aquellos usuarios que se verán directamente, afectados.
Punto crítico, es aquel proceso, que por su mal funcionamiento esta entrabando a otros procesos que perjudican el accionar de la
organización.
CLASE 3

 Distinguen la diferencia entre SIA y sistemas computacionales  Diferencias entre sistemas
 Definen los conceptos de requerimientos relevantes  Conceptos relevantes
 Equipote trabajo.
¡¡Hablar de sistemas y sistemas computacionales no es lo mismo!!

La relevancia entre uno y otro se debe al grado de integración que se le debe otorgar a nuestro usuario.
¿Cuándo es relevante desarrollar un sistema?

Cuando la información que se debe digitalizar es vital para la organización, pero además existen usuarios interesados en participar de
esta digitalización.
ACTIVIDADES:
1. Defina en conjunto con su grupo de trabajo, ¿Qué entiende usted por sistema computacional?
2. Identifique los principales elementos que lo componen.
3. Comente sobre sistemas de información administrativos y defina que rol debe jugar el usuario en este tipo de sistemas.
4. Revise el concepto de la Preparación de la cazuela visto anteriormente y en conjunto con su equipote trabajo identifique
cuales el tipo de cazuela ideal, según los comensales;(usuarios finales del sistema), ¿cuáles son los ingredientes para esa
cazuela?; (requerimientos relevantes); y finalmente describa como será preparada la cazuela y quienes deben participar en
dicha preparación asignando responsables por tareas; (proceso interno del sistema que incluye el trabajo en equipo).
5. Prepare una pequeña exposición del tema.
MATERIAL COMPLEMENTARIO:
Analice y comente:
Los sistemas computacionales son aquellos donde solo se denota el computador y los programas, la relación con los usuarios no es
relevante. (Fierro, programas).
Mientras que los sistemas de información incluyen hardware, software y usuarios integrados, como un todo armonioso, hoy en día uno
de los principales problemas de gestión, tiene que ver con que muchos informáticos le dan prioridad a desarrollar sistemas
computacionales más que sistemas de información administrativos. Evitan tratar con el usuario. Esta situación es letal para éxito del
sistema que se esta desarrollando.
SEGUNDA UNIDAD: ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
CLASE 4

 Identifican y validan los usuarios involucrados  Usuarios claves.
 Analizan y acotan el problema presentado  Trabajo en equipo
 Definen en conjunto con el usuario los requerimientos  Enfoque sistémico
INTRODUCCIÓN:
El aseguramiento de la calidad se basa en definir correctamente el sistema a desarrollar; para enfrentar este gran dilema los
informáticos identificamos tres puntos fundamentales que nos pueden ayudara a construir un software de calidad.
1-. La primera tarea a desarrollar cuando se comienza con un proyecto es identificar en todas sus aristas el problema a resolver y definir
cuan relevante para la organización es que este problema sea resuelto, la relevancia esta relacionada con aquella información que es
vital para la existencia de la empresa; una vez definida la relevancia debemos acotar el problema identificando que áreas se verán
afectadas y cueles no se verán afectadas.
2-. Identificar al o los usuarios que nos proveerán de información para entender la dimensión del problema y también nos
ayudaran a validar la solución que nosotros presentaremos a través de un modelo.
En este punto el informático debe hacer una propuesta proactiva al usuario, ya que es él el experto; esta propuesta debe ser
formalmente validada por los usuarios a través de un documento escrito.
En este punto destacamos también que la relación usuario informático permite determinar el grado de interés, motivación e intención de
las partes lo cual le permite al informático anticiparse a potenciales fracasos no del software si no de funcionalidad, producto del
estado motivación al del o los usuarios.
La calidad de nuestro trabajo se mide por el grado de satisfacción que muestra el usuario, en este aspecto para el usuario el código de
programa pasa a segundo plano.
Es importante considerar que el problema que vamos a resolver debemos establecerle un límite.
ACTIVIDADES:
 Imagínese que a su grupo de trabajo se le ha asignado desarrollar un pequeño sistema que calcule las notas finales de cada uno de
los alumnos de un determinado curso, así como también los porcentajes de presentación al examen final.
 Identifique al docente como usuario clave del proceso. Es él quien lo proveerá de información.
 En primer lugar según el modelo esencial visto en clases establezca el propósito del sistema a desarrollar, usted sabe cuáles son las
condiciones de dicho propósito.
 A continuación defina ahora cuáles son los elementos que usted necesita del medio ambiente para cumplir con ese propósito que se
han establecido., incluya personas, datos, objetos.
 Considere ahora cómo el sistema debería funcionar según su equipo de trabajo, para cumplir con el propósito que se han establecido,
construya las tareas a desarrollar y la forma como los usuarios deben participar de ellas.
Analice y comente:
EL MODELO ESENCIAL Y EL ENFOQUE SISTÉMICO.

El modelo esencial es un modelo lógico, fácil y sencillo de utilizar consiste en describir algo que los humanos constantemente, pero que
no nos damos cuenta
Paso de este modelo:
A: La primera fase consiste en definir o establecer en forma precisa que es lo que se desea hacer, el propósito NO debe ser ambiguo, es
decir bajo ninguna circunstancia debe tener más de una interpretación. Por ejemplo:
1. Comprar pan: es un propósito preciso; pero comprar pan francés, es aun más preciso.
2. Arreglar la casa, es un propósito muy ambiguo ya que existen muchas formas de arreglar la casa. Pintar la casa es más preciso y
menos ambiguo.
B: La segunda fase llamada MODELO AMBIENTAL consiste en identificar ¿de donde? O ¿donde?, se encuentran los
datos/insumos/energía que necesitamos para cumplir con el propósito que nos hemos establecido; pero que ese entorno no lo podemos
afectar y nos debemos ajustar a sus condiciones.
Por ejemplo si necesitamos pintar la casa, la pintura la encontramos en una ferretería y tenemos que aceptar sus condiciones de
ubicación, valor, etc.
C: La tercera fase llamada MODELO DE COMPORTAMIENTO consiste ahora en determinar ¿Cómo vamos a llevar a cabo las distintas
tareas internas para cumplir con el propósito establecido en la primera fase?, por ejemplo contratar pintores, ¿a que hora pintan?,
¿como pintan? , ¿DÓnde pintan?, ¿Cuándo pintan? etc.
Este modelo gráfica por si solo el enfoque sistémico, ya que la esencia de todo sistema esta en su medio ambiente, es decir, pintar,
comer, viajar, son instancia que requieren de el entorno para ser satisfechas.
CLASE 5

 Definen la frontera de los requerimientos  Factibilidad Técnica.
 Estudian la factibilidad de la solución  Factibilidad operacional.
 Factibilidad económica
A continuación el informático deberá planificar cuanto tiempo va a demorar en construir el modelo solución así como también determinar
la factibilidad de aplicar el modelo en la organización y de acuerdo a los recursos disponibles en ella, todo esto con el fin de determinar
los costos del proyecto.
Es importante calcular el tiempo estimado de duración del proyecto, sobre la base de lo consensuado con los usuarios., definiendo los
límites de cada una de las actividades implícitas en el proyecto.
ACTIVIDADES:
1. Redefina el modelo esencial construyendo la solución al sistema planteado

2. identifique cada uno de los componentes del sistema solución.
3. estudie la factibilidad de la solución según lo visto en clases.
Analice y comente:
EL ESTUDIO DE FACTIBILIDAD Y SU RELEVANCIA

Un elemento importante que debemos considerar es el estudio de factibilidad para implementar nuestra solución en la organización;
para lograr esto los informáticos deben realizar un levantamiento de Información sobre los siguientes aspectos:
1. FACTIBILIDAD TÉCNICA: Identificar y cuantificar las disponibilidad de recursos informáticos existentes en la organización, como
por ejemplo, computadores, software, programas de aplicación y otros que nos pueden ser útiles para desarrollar e implementar
nuestro modelo.
Es importante destacar, que aquellos recursos que ya se encuentran en la organización y que potencialmente podrán ser
utilizados deben cuantificarse monetariamente de forma negativa. Este simple hecho denotará una evidente optimización de
recursos para el usuario.
2. FACTIBILIDAD OPERACIONAL: Identificar a los usuarios que se verán directamente afectados por nuestro sistema, no basta.
Desde el punto de vista operacional debemos considerar que tipo de Características, conocimientos o habilidades debe tener o
adquirir cada uno de los usuarios para ser parte de nuestro sistema.
Es importante definir en este estudio cuales son los conocimientos ideales que nuestros usuarios deberían tener para que el uso
del sistema sea óptimo, así como también evaluar que grado actual de conocimientos tienen, con el fin de planificar una
capacitación adecuada.
La importancia de esta actividad radica en anticiparse a cualquier falla funcional de nuestro sistema, provocada por un usuario mal
capacitado o no capacitado o sencillamente desmotivado.
3. FACTIBILIDAD ECONÓMICA: Este estudio debe considerar un resumen de los dos estudios anteriores. Además de indicar los
costos de construcción y puesta en marcha de nuestro sistema solución. La factibilidad económica debe resumir todos los costos
implícitos, de nuestro sistema solución.
CLASE 6

 Elaboran informes técnicos.  Informe final.
 Presentan informe técnico para la toma de decisiones  Factibilidad de la solución.
del proyecto.  Presentación final del proyecto.
RESUMEN DE PROYECTO:
En esta etapa la organización determina si el proyecto continua o no, en forma total o parcial.
La continuidad del proyecto va a depender del grado de detalles que fundamenten su decisión.
COSTO Y BENEFICIOS IMPLÍCITOS.
ACTIVIDADES:
Elabore en conjunto con su equipo de trabajo un resumen que considere:

1. Una descripción del modelo solución, utilizando el modelo esencial.
2. describa el estudio de factibilidad de la solución según lo visto en clases.
3. prepare una pequeña exposición sobre su proyecto.
Conclusión:
Es importante destacar los beneficios que la implementación de nuestra solución traerá a la gestión de la organización. Recuerde
que de esta presentación depende la continuidad del proyecto en su totalidad o forma parcial.
Analice y comente:
MATRIZ RESUMEN DE LOS ESTUDIOS ASOCIADOS
Ítems Total
Factibilidad Técnica.
Factibilidad Operacional
Factibilidad Económica.
Total
El cuadro anterior es un ejemplo a utilizar para vaciar la información recavada.
TERCERA UNIDAD: TÉCNICAS Y HERRAMIENTAS ASOCIADAS
CLASE 7

 Definen focus groups a tratar según frontera del  Informe final.
proyecto.  Factibilidad de la solución.
 Analizan distintas técnicas de recolección de datos  Presentación final del proyecto.
según focus groups
INTRODUCCION
Focus groups:
El grupo focal, es aquel grupo de personas que han sido seleccionados para trabajar en el proyecto, pues se verán directamente
afectadas por el sistema solución o que están directamente vinculadas con el área problema. La composición de este grupo depende
directamente de la forma como se han definido las fronteras del proyecto.
Por otro lado las técnicas de recolección de datos a utilizar van a depender en gran medida de factores como la composición
socioeconómica del grupo, su nivel educacional, el número de integrantes afectado o a evaluar.
ACTIVIDADES
1. Imagínese que se requiere estudiar y diseñar un sistema para controlar la toma de exámenes de conducir en una
municipalidad. Identifique con su grupo cual es el focus groups a analizar y que técnica de recolección de datos usuaria con
ellos.
2. Se requiere diseñar un sistema que controle la salida de autobuses de un determinado Terminal, ¿Qué focus groups debería
usted identificar?.
3. Si a su grupo de trabajo se le asigna la tarea de controlar en forma óptima la entrega de cuadernos del instituto AIEP.
Identifique su focus groups a analizar? . Usaría una encuesta?
MATERIAL COMPLEMENTARIO
Recolección de datos
La recolección de datos se basa en el uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el
informático para desarrollar sistemas de información; estas técnicas utilizadas de manera combinada permiten asegurar la calidad de
los requerimientos y por lo tanto nuestro sistema será mucho más efectivo.
Las técnicas más utilizadas, en nuestra área son entrevistas, cuestionarios, observaciones y juego de roles, el diagrama de flujo de
datos, el diagrama entidad relación y el diccionario de datos.
Estas técnicas son vitales para el éxito de buen sistema. Además permiten un mejor acercamiento con el usuario.
Todos estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información para construir nuestro
modelo solución.
Sugerencias para generar un Focus Groups
Participantes
Características bastante homogéneas, lo ideal es que sean usuario del mismo nivel.
Tamaño del grupo entre ocho y doce persona no mas que eso, ya que si hay más involucrados existe la posibilidad de que no todos
participen en la discusión ya análisis
Ambiente
Es mejor establecer una atmósfera de "café" o de "reunión de amigos", es decir un ambiente de confianza y eso se debe logar con una
introducción sólida al trabajo que se desea lograr con objetivos claros y precisos. Esta reunión no debe durar más allá de entre una hora
y dos horas.
El Nº de sesiones de grupo depende de la naturaleza del proyecto en cuestión, del número de usuario involucrados y de las limitaciones
de tiempo y costo del proyecto.
El usuario líder (dueño) puede hacer saber al moderador, durante los descansos, las áreas en las cuales desea mayor exploración.
Moderación
Las características fundamentales del moderador son:
Amabilidad y firmeza
Permisividad
Participación
CLASE 8

 Preparan ya aplican encuestas y cuestionarios.  Encuestas
 Aplican lluvia de ideas a un problema determinado.  Cuestionarios.
 Lluvias de ideas.
INTRODUCCION
La entrevista es la técnica más significativa y productiva que dispone el informático para recabar información, su eficiencia depende de
la cantidad de personas a entrevistar.
Por otro lado los cuestionarios se pueden utilizar cuando la cantidad de usuarios implicados en el proyecto es muy grande y por un
factor de tiempo se requiere actuar rápido.
Finalmente una de las características principales de la lluvia de ideas es para trabajar con focus groups pequeños y exige del
informático un gran dominio de esta tecnica.
ACTIVIDADES
1. Elabore un cuestionario sencillo con cinco preguntas cerradas, para ver la posibilidad de realizar una fiesta familiar, (encueste
a su familia).
2. Elabore un cuestionario cuyo objeto sea mejorar la forma como se realiza esta clase.
3. Realice en conjunto con su grupo de trabajo una lluvia de ideas para optimizar el uso de los taxi-colectivos, por parte de los
usuarios.
4. Elabore una entrevista de diez preguntas y aplíquela a su madre sobre la visión que tiene ella de usted.
TÉCNICAS PARA RECOLECTAR DATOS

Los informáticos utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, cada uno de estos métodos
tiene sus ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada uno y ayudar a asegurar
una investigación completa:
LA ENTREVISTA
Las entrevistas se utilizan para recolectar información de manera verbal, a través de preguntas que propone el informático. Quienes
responden pueden ser usuarios que se verán directamente afectados por el sistema.
El informático puede entrevistar al personal en forma individual o en grupos, esto va a depender de la experiencia del informático y de la
envergadura del proyecto a desarrollar.
Preparar la Entrevista
1. Determinar el rol que ocupa en la organización el entrevistado, su función dentro de ella, actividades que realiza.
2. Preparar las preguntas que van a realizara, este es un tema de grupo las preguntas no deben ser muchas y deben ser
precisas, lo ideal que la construcción de la entrevista sea realizada por el equipote trabajo.
3. Fijar un límite de tiempo y preparar la agenda para la entrevista.
4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad lo ideal es que el entrevistado elija ese lugar.
5. Hacer la cita con la debida anticipación.
Conduction de la Entrevista
1. Explicar cual es el objeto de la entrevista y que se esta buscando, ser honesto.

2. hablar de todo un poco hablar de lo cotidiano, noticias, deportes etc., esto permite romper el hielo entre entrevistado y
entrevistador.
3. Explicar el rol de cada uno de los participantes.
4. Hacer preguntas específicas para obtener respuestas precisas que se puedan cuantificar.
5. Evitar las preguntas ambiguas, cuya respuesta esconda un resentimiento.
6. Evitar los morillos y gestos incoherentes.
7. Ser cortés y gentil, evitando de emitir juicios que pueden predisponer al entrevistado.
8. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.
9. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas.
Después de la entrevista:
1. Escribir los resultados
2. Entregar una copia al entrevistado, solicitando su aprobación a través de una firma del documento.
3. Archivar los resultados de la entrevista para referencia y análisis posteriores
LOS CUESTIONARIOS
Los cuestionarios proporcionan una alternativa muy útil para la entrevista; si embargo, existen ciertas características que pueden ser
apropiada en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben diseñarse cuidadosamente para una máxima
efectividad.
Los cuestionarios se pueden utilizar cuando la cantidad de usuarios implicados en el análisis de requerimientos es muy grande y por un
factor de tiempo se requiere actuar rápido
Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer
varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a
todas las personas apropiadas para recabar hechos en relación al sistema. En la mayor parte de los casos, el analista no verá a los que
responde; no obstante, también esto es una ventaja porque al no conocer al usuario que responde el cuestionario este podrá responder
con mayor honestidad. También las preguntas estandarizadas pueden proporcionar datos más confiables.
Selección de formas para cuestionarios.
El desarrollo y distribución de los cuestionarios; depende en gran medida de la envergadura del proyecto y del tiempo planificado para
tal efecto. También es importante el formato y contenido de las preguntas sea preciso para que el retorno de la información sea claro.
Existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados, y se aplican dependiendo de si los analistas
conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas. Con frecuencia se utilizan ambas formas en
los estudios de sistemas.
Cuestionario Abierto.
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y
experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar
los métodos de verificación de crédito, es un medio.
El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin
embargo, encuentran más fácil escoger una de un conjunto de respuestas preparadas que pensar por sí mismas.
Debemos tener cuidado con este tipo de cuestionarios, ya que muchas veces estamos trabajando contra el tiempo. Y esto puede afectar
nuestro presupuesto inicial.
Cuestionario Cerrado
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el
analista puede controlar el marco de referencia. Este formato es el método para obtener información sobre los hechos. También fuerza a
los individuos para que tomen una posición y forma su opinión sobre los aspectos importantes.
Esta técnica requiere de una gran experticia de nuestro informático, pues la idea es tener respuestas precisas, sobre los requerimientos
solicitados.
LLUVIA DE IDEAS
La lluvia de ideas es una técnica, que requiere un gran dominio por parte del informático. No es fácil aplicarla ya que requiere de ciertas
condiciones, como se explica a continuación:
1. En primer lugar, se plantea un problema a resolver el cual al igual que el propósito del sistema deber ser preciso y concreto,
como por ejemplo celebrar una determinada fiesta.
2. los directamente implicados, es decir todos los usuarios deben aportar con ideas, nadie debe ser espectador, el que no aporte
con una idea, debe salir del juego.
3. todos son iguales, en esta técnica donde todos participan todos son iguales, los jefes dejan de ser jefes, por lo tantos en
algunos casos están expuestos a las criticas y ahí se debe tener especial cuidado en saber como manejar la situación.
4. debe existir un secretario que anote todas las ideas solución por muy vanas que estas sean.
5. finalmente se elijen las mejores y se construye la solución compartida y consensuada.
6. el documento por escrito debe ser asumido por todos.
Esta técnica requiere de una gran experticia del informático, para manejar grupoide trabajo, ya que sino controla lo mas probables
es que los usuario terminen odiándose a muerte.
CLASE 9

 Reconocen la importancia de la observación en  La observación encubierta
terreno.  La observación anunciada.
 Analizan y comparan distinta técnicas.  .
INTRODUCCION
La observación es un interesante método de recolección de datos ya que permite al informático conocer en terreno el desarrollo de los
acontecimientos, vivenciarlos en todo su potencial.
La observación encubierta permite al informático conocer la real intencionalidad que le da el usuario a la función que esta realizando.
Este tipo de observación se utiliza mucho en aquellas empresas de atención de público.
Por otra parte la observación avisada, genera una actitud formal por parte del observado, es decir hay una predisposición a hacerlo bien.
ACTIVIDADES
1. observe el comportamiento de los pasajeros frente a la llegada del bus en un paradero, describa la situación.
2. observe la atención de público en las cajas de un supermercado, describa la situación.
3. observe la atención de enfermos en cualquier en una posta de urgencias.
4. compare cada una de sus observaciones considerando si obtendría el mismo resultado si aplica otra técnica de las que ha
visto en clases.
LA OBSERVACIÓN
Otra técnica útil para el analista en su progreso de investigación, consiste en observar a los usuarios cuando efectúan su trabajo. Este
método es útil pues permite conocer al usuario en su ambiente real de trabajo, permite además determinar que se está haciendo, como
se está haciendo, quien lo hace, cuando lo hace, cuanto tiempo demora, dónde se hace y por que se hace. Lo ideal es que el
informático actúe de manera camuflada para no incomodar a los usuarios.
Cuando se habla de camuflaje nos estamos refiriendo a la forma de vestir y hablar, frente al usuario.
Tipos de Observación
El analista de sistemas puede observar de tres maneras básicas. Primero, puede observar a un usuario o actitud sin que el observado
se dé cuenta, la actitud del informático es de camuflaje.
Segundo, el analista puede observar una operación sin intervenir para nada, pero estando el usuario observado enteramente
consciente de la observación.
Por último, puede observar y a la vez estar en contacto con el usuario que observa. La interacción puede consistir simplemente en
preguntar respecto a una tarea específica, pedir una explicación, etc.
La elección de uno de estos tipos de observación depende del grado de confianza que se logre con el usuario y el grado de disposición
que este tenga para cooperar.
Preparación para la observación

Determinar y definir aquellas funciones que serán observadas.
Estipular el tiempo necesario de observación.
Obtener la autorización de la gerencia para llevar a cabo la observación.
Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello, en el caso de que sea una acción formal.
Conducción de la observación
Familiarizarse con los componentes físicos del área inmediata de observación.
Mientras se observa, medir el tiempo en forma periódica.
Anotar lo que se observa lo más específicamente posible, evitando las generalidades y las descripciones vagas.
Si se está en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o que impliquen un
juicio de valores.
Observar las reglas de cortesía y seguridad.
Mimetizarse con el medio.
Secuela de la observación
Documentar y organizar formalmente los apuntes.
Revisar los resultados y conclusiones junto con el usuario observado.
CLASE 10

Aplican herramientas graficas para modelar situación actual de sistemas y Castellano estructurado
sistemas solución.
INTRODUCCION
Las herramientas graficas tienen una gran utilidad para determinar cómo funciona realmente un proceso, para entenderlo y corregirlo,
estas herramientas ofrecen otra óptica, para analizar un problema. Dan una imagen de un proceso completo, lo que hace más fácil su
comprensión.
ACTIVIDADES
1. Describa el proceso de levantarse, use castellano estructurado.
2. Describa usando castellano estructurado como freír un huevo.
3. Aplique castellano estructurado para comprar una polera en una tienda
CASTELLANO ESTRUCTURADO
Este método se utiliza para evitar los problemas de ambigüedad del lenguaje al establecer condiciones y acciones, tanto en
procedimientos como en decisiones.
DESARROLLO DE DECLARACIONES ESTRUCTURADAS

Emplea tres tipos básicos de declaraciones para describir un proceso: estructuras de secuencias, estructuras de decisión y estructura de
iteración. Estas estructuras son adecuadas son adecuadas para el análisis de decisión y pueden trasladarse al desarrollo de software y
programación.
Estructuras de secuencia: una estructura de secuencia es un solo paso o acción incluido en un proceso. Este no depende de la
existencia de ninguna condición y, cuando se encuentra, siempre se lleva acabo. En general, se emplean varias instrucciones en
secuencia para describir un proceso.
Por ejemplo, es probable que la compra de una polera siga un procedimiento similar al siguiente:
1. Escoger la polera deseada.

2. Llevar la polera a la caja.
3. Pagar la polera
4. Pedir Boleta.
5. Salir de tienda.
Este ejemplo muestra una secuencia de 5 pasos. Ninguno contiene alguna decisión o condición para determinar la realización del
siguiente paso.
Estructura de decisión: El español estructurado es otro camino para mostrar el análisis de decisión. A menudo se incluyen las
secuencias de acciones entre estructuras de decisión que sirven para identificar condiciones. Es así como las estructuras de
decisión aparecen cuando se pueden emprender dos o mas acciones, lo que depende del valor de una condición especifica.
Primero se evalúa la condición y después se toma la decisión de emprender las acciones asociado con esta condición. Una vez
determinada la condición las acciones son incondicionales.
Estas condiciones junto con las acciones pueden indicarse de la siguiente manera:
Si se encuentra la polera deseada ENTONCES.

Llevar llevara la polera a caja..
Pagar la polera.
Asegurase de pedir la boleta.
Abandonar la tienda
DE OTRO MODO
No llevar la polera a caja
Salir de tienda
La estructura de decisión que emplea las frases SI / ENTONCES / DE OTRO MODO, señala con bastante claridad las alternativas
de proceso de decisión. En este caso se indican dos condiciones y dos acciones.
Las estructuras de decisión no esta limitada a pares de combinaciones condición – acción. Pueden existir muchas condiciones.
Estructuras de iteración: En las actividades rutinarias de operación, es común encontrar que algunas de ellas se repiten mientras
existan ciertas condiciones o hasta que estas se representan. Las instrucciones de iteración permiten al analista describir estos
casos.
La búsqueda de una polera en una tienda se puede seguir repitiendo los siguientes pasos:
EJECUTAR MIENTRAS se examinan las poleras:

Si la polera es atractiva
ENTONCES verificar precio
Si la decisión es comprar la polera
Llevarla en la mano
OTRO regresar la polera al colgador
FIN DE SI
OTRO continuar
FIN DE EJECUTAR
SALIR.
CLASE 11

 Aplican herramientas graficas para modelar  DFD.
situación actual de sistemas y sistemas
solución.
INTRODUCCION
Las herramientas graficas tienen una gran utilidad para determinar cómo funciona realmente un proceso, para entenderlo y corregirlo,
estas herramientas ofrecen otra óptica, para analizar un problema. Dan una imagen de un proceso completo, lo que hace más fácil su
comprensión.
ACTIVIDADES
1. Diseñe a través de un dfd de contexto un sistema para comprar pan.
2. Diseñe utilizando un dfd de contexto un sistema para sacar boleto de bus.
3. Diseñe un sistema utilizando un dfd para describir la toma de módulos que usted realiza.
Diagrama de Flujo de Datos
Estos gráficos se utilizan para describir el flujote información que se produce en un determinado proceso.
Se utiliza para describir organizaciones completas o corregir en su totalidad sus procesos.
Los recursos utilizados son, el castellano estructurado:
Por ejemplo los verbos indican procesos y los sustantivos propios y comunes, indican que son entidades.
Gráficos utilizados
Entidad Externa
Proceso,
ewnt
COMPRAR,
VENDER
Flujo de datos.
Las entidades externas son aquellas que solicitan información a nuestro sistema y que no podemos controlarlas, como por ejemplo SII,
Gerentes, etc.
Los flujos de datos, indican la orientación de la información, verifique los ejemplos vistos en clases.
Los procesos están encerrados en óvalos, generalmente se usan verbos que definirlos, como por ejemplo COMPRAR, VENDER
PROCESAR, GUARDAR, etc.
CLASE 12

 Aplican herramientas graficas para modelar  Caso de uso.
situación actual de sistemas y sistemas
solución.
INTRODUCCION
Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema,
para conseguir un objetivo especifico.
ACTIVIDADES
1. Diseñe un caso de uso para comprar un café en el casino.
2. Diseñe un sistema utilizando caso de uso para describir la toma de módulos que usted realiza.
MATERIAL COMPLEMENTARIO
CASO DE USOS
En ingeniería del software, un caso de uso es una técnica para la captura de requerimientos para un nuevo sistema o una actualización
de software.
Normalmente, en los casos de usos se evita el empleo de lenguaje técnico, prefiriendo en su lugar un lenguaje más cercano al usuario
final, lo ideal es que sea un lenguaje contextualizado, asociado al usuario que será afectado por el sistema. Muchas veces suena
interesante construir un esquema donde nombres de actores son familiares a los usuarios, lo que hace que el modelamiento sea más
distendido.
En otras palabras, un caso de uso es:
 una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a
 un evento que inicia un actor principal sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con
los usuarios u otros sistemas.
En resumen, podemos decir que es un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.
Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a
eventos que se producen en el mismo.
Definiciones básicas
Actores
Se le llama Actor a toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye
a los operadores humanos pero también incluye a todos los sistemas externos así como a entidades abstractas como el tiempo.
Por ejemplo, vendedor, cliente, servicio de impuestos internos, otros…
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede
corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente
encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito
funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso.
Un caso de uso debe
1. Describir una tarea del negocio que sirva a una meta de negocio
2. Tener un nivel apropiado del detalle
3. Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:

 Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en
cambio si es secundario, el sistema será el que inicie la comunicación).
 Un caso de uso extiende otro caso de uso.

 Un caso de uso usa otro caso de uso.
Ventajas
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso
del sistema.
Como técnica de recolección de datos permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar
el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios
tecnológicos, esta última actitud es la que se conoce como crisis del software
Limitaciones
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos
funcionales ni permiten determinar los requisitos no funcionales.
Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de
datos que complementen los requerimientos del sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico
del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.
El valor verdadero de un caso de uso reposa en dos áreas:
1. La descripción escrita del comportamiento del sistema al enfrentar una tarea de negocio o un requisito de negocio. Esta
descripción se enfoca en el valor suministrado, (información validada) por el sistema a entidades externas tales como usuarios
humanos u otros sistemas.
2. La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de
casos de uso coherente, consistente promueve una imagen fácil del comportamiento del sistema, un entendimiento común
entre el usuario/cliente y el equipo de desarrollo.
Por ejemplo:
Un comprador puede:
 Compra mercadería
 No comprar mercadería.
 Pagar mercadería.
 Ver mercadería.
Un vendedor puede:
 Vender mercadería.
 No vender mercadería.
 Mostrar mercadería.
 No Mostar mercaderia.
Estos son los casos de usos de dos actores un cliente y un vendedor, en una situación de compra.

Cuaderno de Apuntes Ingeniería de Requerimientos EIT 112 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cuaderno de Apuntes Ingeniería de Requerimientos EIT 112 PDF

Cargado por

Copyright:

Formatos disponibles

Vicerrectoría Académica

Cuaderno de Apuntes – 2009

NOMBRE DEL MÓDULO: INGENIERÍA DE REQUERIMIENTOS.

DURACIÓN: 90 horas pedagógicas

II. DESCRIPCIÓN POR ÁREA DE FORMACIÓN Y PRERREQUISITO

ÁREA DE FORMACIÓN: Especialidad

III. UNIDADES DE APRENDIZAJE

PRIMERA UNIDAD LA INGENIERÍA DE REQUERIMIENTOS Y SU ROL EN LA ORGANIZACIÓN

DURACIÓN: 15 horas pedagógicas

SEGUNDA UNIDAD: ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

DURACIÓN: 15 horas pedagógicas

TERCERA UNIDAD: TÉCNICAS Y HERRAMIENTAS ASOCIADAS

DURACIÓN: 30 horas pedagógicas

 Reconocen la importancia de la observación en terreno.

CUARTA UNIDAD: SELECCIÓN Y APLICACIÓN DE TÉCNICAS SEGÚN PROYECTO

DURACIÓN: 30 horas pedagógicas

IV. EVALUACIÓN DE UNIDADES

VI. CLASE A CLASE

PRIMERA UNIDAD: LA INGENIERÍA DE REQUERIMIENTOS Y SU ROL EN LA ORGANIZACIÓN

APRENDIZAJES ESPERADOS CONTENIDOS

¡¡ En el desarrollo de sistemas ocurre exactamente lo mismo!!

APRENDIZAJES ESPERADOS CONTENIDOS

Investigue en Internet sobre FODA.

¡¡Hablar de sistemas y sistemas computacionales no es lo mismo!!

¿Cuándo es relevante desarrollar un sistema?

APRENDIZAJES ESPERADOS CONTENIDOS

¡¡Hablar de sistemas y sistemas computacionales no es lo mismo!!

¿Cuándo es relevante desarrollar un sistema?

SEGUNDA UNIDAD: ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS

APRENDIZAJES ESPERADOS CONTENIDOS

EL MODELO ESENCIAL Y EL ENFOQUE SISTÉMICO.

APRENDIZAJES ESPERADOS CONTENIDOS

1. Redefina el modelo esencial construyendo la solución al sistema planteado

EL ESTUDIO DE FACTIBILIDAD Y SU RELEVANCIA

APRENDIZAJES ESPERADOS CONTENIDOS

Elabore en conjunto con su equipo de trabajo un resumen que considere:

MATRIZ RESUMEN DE LOS ESTUDIOS ASOCIADOS

El cuadro anterior es un ejemplo a utilizar para vaciar la información recavada.

TERCERA UNIDAD: TÉCNICAS Y HERRAMIENTAS ASOCIADAS

APRENDIZAJES ESPERADOS CONTENIDOS

Sugerencias para generar un Focus Groups

APRENDIZAJES ESPERADOS CONTENIDOS

TÉCNICAS PARA RECOLECTAR DATOS

1. Explicar cual es el objeto de la entrevista y que se esta buscando, ser honesto.

APRENDIZAJES ESPERADOS CONTENIDOS

Preparación para la observación

APRENDIZAJES ESPERADOS CONTENIDOS

DESARROLLO DE DECLARACIONES ESTRUCTURADAS

1. Escoger la polera deseada.

Si se encuentra la polera deseada ENTONCES.

EJECUTAR MIENTRAS se examinan las poleras:

APRENDIZAJES ESPERADOS CONTENIDOS

Diagrama de Flujo de Datos

APRENDIZAJES ESPERADOS CONTENIDOS

Situaciones que pueden darse:

 Un caso de uso extiende otro caso de uso.

El valor verdadero de un caso de uso reposa en dos áreas:

También podría gustarte