Taller # 5: Ingeniería de requisitos

Ingeniería del software: un enfoque práctico

Por Jeancarlo Fontalvo

1. ¿Por qué muchos desarrolladores de software no ponen atención

suficiente a la ingeniería de requerimientos? ¿Existen algunas
circunstancias que puedan ignorarse?
Rta:
Existen muchas razones para que los desarrolladores tomen esta
decisión que casi siempre se debe a que los requisitos son
dinámicos, entonces al menos que se utilice un enfoque eficiente y
ágil que haga al equipo versátil en esta tarea.
Otra, puede ser que es una actividad que requiere de un alto grado
de análisis, lo que demanda tiempo, es preferible solo tomar los
requisitos que afectaran directamente al negocio y avanzar en las
próximas iteraciones.
También se piensa que retrasa la etapa más divertida que es el
modelado y la codificación del proceso de software, pero se sabe
que es fundamental.

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?
Rta:
 Debe prepararse con la información pertinente del negocio
 Tratar de solicitar una persona auxiliar que conozca el negocio,
su funcionamiento, y tenga una idea más técnica de las
necesidades del cliente, como un Product Owner
 Procurar de tener una visión del proyecto que satisfaga dichos
requisitos

3. Analice algunos de los problemas que ocurren cuando los

requerimientos deben indagarse para tres o cuatro clientes
distintos
Rta:
Muchos de los problemas que nos enfrentaremos como Ingenieros
de software es la indagación de requisitos conflictivos.
Estos problemas se dan en primera por la oposición o “conflicto”
de algunos participantes del negocio. Si bien esto puede parecer
un problema en primera, también brinda sutilmente una riqueza
“visual” al proyecto, por la accesibilidad de varios puntos de
vistas. Ahora, lo ideal para tal situación es hacer una
retroalimentación con el grupo conflictivo e implementar la
 negociación de requisitos, y obtener la mejor estrategia para el
proyecto.

4. ¿Por qué se dice que el modelo de requerimientos representa

una fotografía instantánea del sistema en el tiempo?
Rta:
Considero, que constituye una visión de lo que será el proyecto ya
que se identifican las ideas, y se concibe el software de manera
rápida, para suponer lo que yacerá a largo plazo el proyecto.

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é?
Rta:
La verdad, es relativo. Si en esa situación el cliente también se
dispone convencido y acepta con entusiasmo, además de que
siente que gana, durante dicha tarea; entonces se puede decir
que soy un gran negociador.
Mas sin embargo, si el cliente quedo en dudas o se siente
desplazado de la negociación, entonces estaré siendo egoísta, y
no cumpliría con uno de los principios del manifiesto ágil, por
tanto sería un pésimo negociador.

6. Desarrolle al menos tres “preguntas libres de contexto”

adicionales que podría plantear a un participante durante la
concepción.
Rta:
 ¿Por qué nace la idea de hacer e implementar un proyecto de
software en la empresa?
 ¿Qué espera(n) usted(s) del proyecto a desarrollar?
 ¿Cómo cree que afectará el software al negocio?

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.
Rta:
Especificación de JRC2 Kit:
- Lineamientos:
 Simpleza y puntualidad: Antes que todo, se debe
representar una buena imagen laboral ante el cliente, es
fundamental la puntualidad a la hora de llegar a citas de
intercambio de información.
  Indagación del Negocio a través de la preparación:
Es preferible saber de forma razonable, conceptos y
términos del negocio, ya que facilita mucho la
comunicación.
 Apoyarse en el uso de las TIC: La obtención
tradicional de los requisitos, se podía plasmar en lápiz y
papel, pero eso ha cambiado; como actualizados que
somos, debemos hacer uso de herramientas que mejoren
y optimicen dicha actividad a través de las TICS.
 Disponibilidad de facilitadores: Un facilitador evita la
tensión entre los participantes, y sirve de interfaz para el
flujo de información entre el cliente y el equipo.
- Herramientas:
 Si se prefiere el uso del lápiz y papel, se puede, aunque
se debe pensar en TIC en un futuro.
 Tablero y videobeam para presentar lógicas del negocio
por parte del cliente.
 Cámara de video y fotográfica.

8. Desarrolle un caso de uso completo para uno de las actividades

siguientes:
a) Hacer un retiro de efectivo en un cajero automático
Rta en la página siguiente.
 9.
9.
¿Qué representan las “excepciones” en un caso de uso?
Rta:
Son situaciones que inducen comportamientos ajenos al flujo
normal o “feliz” de uso, en el sistema. Aunque no correspondan al
flujo normal, se deben evaluar, analizar, validad e implementar
(controlar y satisfacer).

10. Describa con sus propias palabras lo que es un patrón de

análisis.
Rta:
Como su nombre lo indica, surgieren la solución parcial o
completa de una situación, problemática, dominio o modelos y
análisis de requisitos que se comportan como patrones o se han
vivido y solucionada parcial o totalmente anteriormente.

11. 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
Rta:

Escojo en primera a los navegadores web, que tienen que modelar

siempre un protocolo de comunicación, por el que se comunican
con los servidores y permiten al usuario navegar en internet por
peticiones y respuestas.

 Nombre del patrón: Protocolito

 Intención: El patrón trata de modelar la interacción, y flujo que se da
en el protocolo de comunicación HTTP que debe satisfacer el navegador
web.
 La motivación: Servir de interfaz en una solicitud de cliente (petición)
y respuesta de servidor.
 Solución: Definir un conjunto de pasos que modelen el protocolo. Dicho
modelo debe poseer por lo menos dos identificadores (cliente y servidor)
implementados en clases. Los objetos deben proveer métodos de
comunicación e interfaces para la transmisión y transporte de Hipertexto
y Archivos.
 Consecuencias: El patrón facilita la tarea de modelar el protocolo,
apoyándose en las clases de cliente y servidor.
 Diseño: Uso del patrón de diseño Comando y Visitante
 Los usos conocidos: Todos los navegadores, lo deben implementar
como requisito.

12. ¿Qué significa ganar-ganar en el contexto de una

negociación durante la actividad de ingeniería de los
requerimientos?
Rta:
Que tanto el cliente y el equipo, se ven beneficiados por un
conjunto de negociaciones, que permiten la satisfacción del
cliente y condiciones buenas de trabajo para el equipo.

13. ¿Qué piensa que pasa cuando la validación de los

requerimientos detecta un error? ¿Quién está involucrado en su
corrección?
Rta:
Por obviedad se debe corregir. Se puede hacer por medio de la
retroalimentación conjunta que se hace con el cliente que es
quien que realiza la aclaración y corrección indirecta del
requerimiento.