Santiago Bermúdez Bonilla

Santiago Ladino Giraldo

Sistemas informáticos lunes 7:45 – 10:00 pm

1. ¿Por qué muchos desarrolladores de software no ponen atención suficiente a la ingeniería

de requerimientos? ¿Existen algunas circunstancias que puedan ignorarse?

Muchos desarrolladores podrían argumentar que estos requisitos se van agregando o se van
conociendo a medida que se desarrolla el proyecto, muchos comienzan sin tener un conocimiento
claro y previo de lo que necesita, los participantes en el proyecto podrán comprender sus
necesidades sólo después de ver los primeros resultados del software, que el tiempo hace que las
cosas cambien tan rápido que cualquier intento de entender los requerimientos en detalle es una
pérdida de tiempo.

2. El lector tiene la responsabilidad de indagar los requerimientos de un cliente que dice

estar demasiado ocupado para tener una reunión. ¿Qué debe hacer?

Al momento de realizar la indagación, es muy importante que esta se haga de manera colaborativa,
entre los principales participantes involucrados entre ellos el cliente, ya que es de mucha
importancia entender de primera mano las necesidades del mismo, y las negociaciones que se
deben hacer a los requerimientos dados inicialmente, por esto desde un comienzo se deben
establecer unas reglas, que permitan cumplir las fechas del proyecto y conocer las opiniones y
necesidades que van surgiendo durante la definición de los requerimientos, por eso es muy
importante tener en cuenta los siguientes puntos:

- Identificar a los participantes: Esto nos permitirá saber quiénes son las personas que se
beneficiarán por el desarrollo del sistema, ya que estos harán aportes en la lista de requerimientos
que se necesitan desarrollar.

- Reconocer los distintos puntos de vista: Cada uno de los participantes podrá aportar información
al proceso de ingeniería de los requerimientos, y a medida que se indaga o se reúne información
procedente de múltiples puntos de vista, los requerimientos que surjan tal vez sean inconsistentes
o muy individualizados, generando un conflicto uno con otro. Para ello debe clasificarse toda la
información de los participantes, teniendo en cuenta aquellos que generen conflictos, de tal forma
que permita a quienes toman las decisiones escoger para el sistema un conjunto de
requerimientos que tenga coherencia y agrado de las partes involucradas.

- Trabajar hacia la colaboración: El trabajo del ingeniero de requerimientos es lograr identificar las
áreas o puntos de interés común, por ejemplo, requerimientos en los que todos los participantes
estén de acuerdo y los conflictivos, por ejemplo, requerimientos que desea un participante, pero
que están en conflicto con las necesidades de otro. Teniendo en cuenta que es la última categoría
la que representa un reto mayor.

- Hacer las primeras preguntas: Estas preguntas ayudan al ingeniero de requisitos a identificar a
todos los participantes que cuenten con un interés en el software que se va a elaborar. Además, las
preguntas identifican el o los beneficios de lograr una implementación exitosa y las posibles
alternativas para el desarrollo de software personalizado.

3. Analice algunos de los problemas que ocurren cuando los requerimientos deben indagarse
para tres o cuatro clientes distintos.

En esos casos los problemas que se pueden presentar son opiniones diferentes frente a los
requerimientos solicitados del software, también puede pasar que algunos ordenen
requerimientos según sus propias necesidades o pueden llegar a pelear por insignificancias.

4. ¿Por qué se dice que el modelo de requerimientos representa una fotografía instantánea
del sistema en el tiempo?

Dado que el modelo va cambiando de forma dinámica a medida que se va aprendiendo más sobre
el sistema que se quiere construir, y los otros participantes van comprendiendo que es lo que con
más urgencia y que objetivamente necesitan y esperan del sistema en desarrollo.

5. Suponga que ha convencido al cliente (es usted muy buen vendedor) para que esté de
acuerdo con todas las demandas que usted hace como desarrollador. ¿Eso lo convierte en
un gran negociador? ¿Por qué?

6. Desarrolle al menos tres “preguntas libres de contexto” adicionales que podría plantear a
un participante durante la concepción.

- ¿Cuál sería una salida adecuada que se genere cuando la solución no tenga éxito?

- ¿Qué aspectos o restricciones no son necesarios para poder realizar una operación exitosa?

- ¿Cuáles son los beneficios extras que aporta esta solución en relación a otras ya existentes?

7. Desarrolle un “kit” para recabar requerimientos. Debe incluir un conjunto de lineamientos

a fin de llevar a cabo la reunión para recabar requerimientos y los materiales que pueden
emplearse para facilitar la creación de listas y otros objetos que ayuden a definir los
requerimientos.

El kit para obtener requerimientos con éxito y así realizar un proceso correcto de definir los
requerimientos necesarios para el desarrollo del software son los siguientes:

Tanto ingenieros de software como otros participantes dirigen o intervienen en las reuniones.

• Se establecen reglas para la preparación y participación.

• Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero
con la suficiente informalidad para que estimule el libre flujo de ideas.

• Un facilitador, que puede ser un cliente, desarrollador o participante externo, controla la

reunión.
• Se utiliza un mecanismo de definición, que pueden ser hojas de trabajo, tablas sueltas, etiquetas
adhesivas, pizarrón electrónico, grupos de conversación o foro virtual.

8. Su profesor formará grupos de cuatro a seis estudiantes. La mitad de ellos desempeñará el

papel del departamento de mercadotecnia y la otra mitad adoptará el del equipo para la
ingeniería de software.
9. Desarrolle un caso de uso completo para una de las actividades siguientes:
a) Hacer un retiro de efectivo en un cajero automático.
 10. ¿Qué representan las “excepciones” en un caso de uso?

Son todas y cada uno de los casos o falta de procesos que puedan impedir que el sistema funcione
o prosiga en su funcionamiento durante un proceso específico dentro del sistema; Son cosas que
tal vez pueden evitar una solución u operación exitosa.
 11. Describa con sus propias palabras lo que es un patrón de análisis.

Un patrón de análisis es un grupo de conceptos o ideas que representan una construcción común
en el modelo de las actividades de una empresa. Estos pueden ser usados para un único domino o
varios.

12. Con el formato presentado en la sección 5.5.2 sugiera uno o varios patrones de análisis
para los siguientes dominios de aplicación:

a) Software de contabilidad.

b) Software de correo electrónico.

c) Navegadores de internet.

d) Software de procesamiento de texto.

e) Software para crear un sitio web.

f) El dominio de aplicación que diga su profesor.

13. ¿Qué significa ganar-ganar en el contexto de una negociación durante la actividad de

ingeniería de los requerimientos?

Significa que los participantes ganan porque obtienen el sistema o producto que satisface la
mayoría de sus necesidades y el equipo de software gana porque trabaja con presupuestos y
plazos realistas y asequibles.

14. ¿Qué piensa que pasa cuando la validación de los requerimientos detecta un error?
¿Quién está involucrado en su corrección?

Al momento de ser detectado un error tanto el ingeniero como el cliente, ya que si este tipo de
errores se presenta una vez después del desarrollo, puede resultar en un costo 100 veces mayor
que fijar o solucionar el error en la implementación, por tanto es muy necesario que tanto
ingeniero como cliente validen cada uno de los requisitos para así evitar este tipo de errores, que
puedan incurrir en gastos adicionales para el cliente, para ello se puede hacer uso de diferentes
técnicas de validación que nos permitirá evitar este tipo de problemas:

 Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa

documentación o modelado de la definición de requisitos. Con ello solamente se puede
validar la correcta interpretación de la información transmitida. Más difícil es verificar
consistencia de la documentación o información faltante.
 Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de
los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir
sólo una muestra es revisada.
 Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y
chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz &Toro, 1999). Es
 necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar
inconsistencias u objetivos no cubiertos.
 Prototipos: Algunas propuestas se basan en obtener de la definición 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 técnica tiene el problema de que el usuario debe entender que lo que está viendo es
un prototipo y no el sistema final.