Ingeniería de

Software
Reflexiones sobre la Ingeniería
de Requisitos
Agenda

1. ¿ Que es la IR , quienes lo hacen y

sus etapas ?.
2. Etapa de Inicio.
3. Etapa Obtención (especificación).
4. Etapa de Elaboración.
5. Etapa de Negociación.
6. Etapa de Verificación
1. ¿ Que es ?

● Ayuda de los IR a entender mejor el problema en cuya solución

trabajan.
● Define lo que el cliente quiere y cómo interactúan los usuarios finales
en el software
● La Ingeniería de Requisitos es una etapa de la Ingeniería de Software
que comienza durante la actividad de comunicación y continua en la
actividad de modelado. ¿ cual es el resultado del proceso ?
● La ingeniería de requisitos proporciona el mecanismo apropiado para
entender lo que el cliente quiere, analizar las necesidades, evaluar la
factibilidad, negociar una solución razonable, especificar la solución
sin ambigüedades, validar la especificación.
● Los desarrolladores suelen anticiparse a implementar aplicaciones que
aun no han sido especificadas. Este método es válido siempre y
cuando los proyectos sean pequeños (no mayores a un mes).
● El enfoque de la IR puede darse de manera ágil o rigurosa. El equipo
de IS debe adaptar su enfoque lo que no significa el abandono de la
IR.
1 ¿ Quien lo hace ?

● Ingenieros de Software.

● Especificadores.

● Gerentes.

● Clientes.

● Usuarios Finales.
1. Pasos de la Ingeniería de
Requisitos

● Inicio.

● Obtención.

● Elaboración (Especificación).

● Negociación.

● Validación (Especificación)
 2. Etapa de Inicio

● Establecer una comprensión básica del problema, las personas que

quieren la solución, la naturaleza de la solución y la efectividad de la
comunicación.
● Identificación de los Interesados: todos aquellos que se beneficien directa
o indirectamente con el sistema que está en desarrollo. Se debe crear una
lista de interesados la cual podrá crecer a medida que se van
entrevistando más interesados.
● Reconocimiento de múltiples puntos de vista: conforme se recopila
información desde múltiples puntos de vista, los requisitos que surjan
pueden ser inconsistentes o entrar en conflicto con algún otro. Se deben
recopilar todos los requisitos y escalar la decisión de cuáles serán o no
incluidos.
● El ingeniero de requisitos debe identificar áreas en común (requisitos en
que todos los interesados están de acuerdo) y áreas de conflicto o
inconsistencia.
● Una sesión de preguntas y respuestas se debe usar sólo para el primer
encuentro y después se debe reemplazar por un formato de obtención de
requisitos que combine elementos de resolución de problemas,
negociación y especificación.
2. Etapa de Inicio

● Preguntas enfocadas al cliente, interesados, metas generales y

beneficios:
○ ¿ Quién está detrás de la solicitud de este trabajo?
○ ¿ Quién usará la aplicación?
○ ¿ Cuál será el beneficio económico de una solución ?
○ ¿ Existe otra fuente para la solución requerida ?

● Preguntas enfocadas a comprender mejor el problema:

○ ¿ Cómo podría caracterizarse un buen resultado generado por una
solución exitosa.?
○ ¿ Cuales problemas debería atacar esta solución ?

● Preguntas enfocadas a la efectividad de la comunicación:

○ ¿ Es usted la persona adecuada para contestar esta pregunta?
○ ¿ Sus respuestas son oficiales?
○ ¿ Estoy haciendo demasiadas preguntas?
○ ¿ Alguien mas puede proporcionar información adicional?
○ ¿Debería preguntarle alguna otra cosa.?
3. Obtención de Requisitos

● La obtención de requisitos se realiza con base al desarrollo conjunto de

aplicaciones (JAD) la cual es una técnica popular para la recopilación de
requisitos basado en que se debe tener completa seguridad de que los
requisitos se obtienen de una muestra representativa de los usuarios. Si
solo uno de los usuarios definen todos los requisitos, el riesgo de rechazo
es alto.
● Las reuniones deben ser dirigidas por un moderador (Ing. de Software,
cliente o especificador ), se debe definir una agenda.
● Con base en una solicitud de producto que será distribuida a todos los
asistentes antes de la fecha de la reunión. Se solicitará a cada asistente
elaborar una lista de objetos que son parte del ambiente que rodea el
sistema, los objetos que producirá, objetos con los cuales se relaciona,
procesos o funciones que interactúan con los objetos, restricciones del
sistema (costo, tamaño, reglas del negocio), criterios de rendimiento
(velocidad, exactitud). No debe ser exhaustiva.
● Se comparten y debaten las listas de objetos entre los participantes a
través de hojas grandes de papel, tableros, foros o wikis, cuyo resultado
será una lista concesada y/o combinada (eliminaciones, adiciones,
3. Obtención de Requisitos

● Se deben formar subequipos para redactar miniespecificaciones para

cada objeto de la lista combinada, se comparten y debaten, Por último
uno o más participantes reciben el encargo de escribir las
especificaciones completas.
● Requisitos Normales: reflejan los objetivos y metas establecidos para un
producto durante las reuniones con el cliente. Si estos requisitos están
presentes, el cliente estará satisfecho. Ejemplo: funciones específicas del
sistema, niveles de rendimiento, etc.
● Requisitos Esperados: están implícitos en el producto y pueden parecer
tan obvios que el cliente no los establece de manera explícita. Su
ausencia causaría una insatisfacción significativa.
● Requisitos estimulantes: reflejan las características que van más allá de
las expectativas del cliente y que prueban ser muy satisfactorias cuando
están presentes.
4. Elaboración Especificación
● Definición Especificación: documento escrito, conjunto de modelos gráficos, un
modelo matemático formal, una colección de escenarios de uso, un prototipo, o
cualquier combinación de estos.
● Algunos autores sugieren una especificación basada en plantillas, sin embargo,
algunas veces es necesario ser flexible. Con respecto a sistemas grandes podría
ser suficiente con una combinación entre una descripción en el lenguaje natural y
modelos gráficos; para sistemas pequeños podría no necesitar más que escenarios
de uso.
● Caso de uso: cuenta una historia (de alto nivel) de la manera que un usuario final
interactúa con el sistema en un conjunto específico de circunstancias (texto
narrativo, descripción basada en plantilla, diagrama).
● CU puede estar compuesto por: actores (personas o dispositivos), Meta en el
contexto, Condiciones Previas, escenario, excepciones, Condiciones Posteriores,
diagramas de casos de uso.
● Diagramas de Actividades / Flujo: representan el comportamiento interno de un
caso de uso, agrupadas secuencialmente. El propósito de este diagrama es
modelar el flujo de tareas de un caso de uso. Está compuesto por: nodo de fin,
tarea / actividad, transiciones, nodo de decisión, nodo inicio, barras de
sincronización, carriles.
4. Elaboración Especificación
5. Negociación de Requisitos

● Las tareas de inicio, obtención y elaboración tienen el suficiente detalle

para emprender los pasos subsecuentes de la IS, sin embargo, entre el
cliente y el desarrollador se debe iniciar un proceso de negociación.

● Se debe solicitar al cliente un balance entre la funcionalidad y el

rendimiento frente al costo y el tiempo de colocación en el mercado.

● El objetivo principal de la tarea de negociación es desarrollar un plan de

proyecto que satisfaga las necesidades del cliente al mismo tiempo que
refleja las restricciones del mundo real (tiempo, recursos, presupuesto).

● Las mejores negociaciones son aquellas que buscan un resultado del tipo
ganar-ganar. (Un acuerdo es el arte de dividir un pastel de tal forma que
cada uno piense que se quedó con la rebanada más grande)
5. Tips para Negociación

● Reconocer que no es una competencia: ambos lados debe tener el

sentimiento de haber ganado. Se deben buscar acuerdos.

● Escuchar de manera activa: no se debe pensar en formular una

respuesta mientras la otra parte está exponiendo sus argumentos. Es
posible que se obtenga un conocimiento que ayudará a negociar de mejor
manera.

● Enfocarse en los intereses de la otra parte: para evitar conflictos no se

deben tomar posiciones inflexibles.

● No dejar que se vuelva personal: enfocarse en el problema que debe

ser resuelto.