Taller # 5: Ingeniería de requisitos

Ingeniería del software: un enfoque práctico

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
Caso de U so Transacion Cajero Automatico
Fue nte s Banco, Administrador
Actor Act.# 1 Cliente
Act # 2 Administrador
Dispar ador El Cliente decide realizar una transaccion de dinero en su cuenta desde el
cajero automatico
De scr ipción Representa la interaccion de un usuario que desea hacer transacciones en
un cajero automatico.
Flujo básico 1. Iniciar el sistema
El administrador inicia el sistema para su correspondiente uso
2. Iniciar sesión en el sistema
Lo primero que debe hacer el usuario es iniciar sesión para poder disponer
de las operaciones de transación
3. Ingresar cantidad a retirar
El usuario deberá ingresar la cant. Deseada para retirar, por medio de una
interfaz de usuario numerica
4. Realizar transación
El sistema realiza la correspondiente transacion, y modifica su estado interno
5. Actualizar saldo del usuario
El sistema debe notificar al usuario su nuevo valor del saldo disponible
6. Salir del Sistema
El usuario luego de realizar sus respectivas operaciones con el sistema, debe
cerrar la sesión.
7. Apagar el sistema
El administrador apaga el sistema, despues de su uso
Flujos alte r nos 1. Falla al iniciar sesión
En el paso 2, el usuario se le impide iniciar la sesión en el sistema. El sistema
no puede validar los datos del usuario, por tanto se le notifica que ingrese
nuevamente los datos 3 veces. El usuario acepta el mensaje. El CU regresa al
paso 2.
2. Saldo insuficiente
En el paso 3, el usuario ha ingresado una cant. Superior al saldo que dispone
en su cuenta. El SI le notifica en un mensaje. El usuario acepta y puede ir al
paso 6.
Pr e -condicione s 1. Cuenta de usuario

El usuario deberá tener una cuenta en el banco para poder retirar dinero del
cajero
2. Dinero en el cajero
El administrador debe gestionar el dinero y su cantidad en el cajero, a fin de
evitar que se quede sin saldo.
Post-condicione s El Cliente realiza la transaccion exitosamente

Pr ior idad Escencial, debe implementarse

Fr e cue ncia de Diario

uso

Canale s par a e l Cajero automatico

usuar io
 nuevamente los datos 3 veces. El usuario acepta el mensaje. El CU regresa al
paso 2.
2. Saldo insuficiente
En el paso 3, el usuario ha ingresado una cant. Superior al saldo que dispone
en su cuenta. El SI le notifica en un mensaje. El usuario acepta y puede ir al
paso 6.
Pr e -condicione s 1. Cuenta de usuario

El usuario deberá tener una cuenta en el banco para poder retirar dinero del
cajero
2. Dinero en el cajero
El administrador debe gestionar el dinero y su cantidad en el cajero, a fin de
evitar que se quede sin saldo.
Post-condicione s El Cliente realiza la transaccion exitosamente

Pr ior idad Escencial, debe implementarse

Fr e cue ncia de Diario

uso

Canale s par a e l Cajero automatico

usuar io

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.