Ingeniería de requerimientos

Ing. David Benavides, Msc. MAE

Presentación del facilitador
 Ing. David Benavides, MAE Msc.
(resumen)
Preparación formal:

▪ Ingeniero en Sistemas Computacionales

▪ Magister en Administración de Empresas con mención en Sistemas de Información Gerencial (MAE)
▪ Magister en Docencia y Gerencia en Educación Superior (Msc)
▪ Diplomado en Pedagogías Innovadoras
▪ Cursos y seminarios técnicos de especialización nacionales e internacionales

Experiencia docente y académica:

▪ Docente en las carreras de Ingeniería en Sistemas e Ingeniería en Networking desde 2003 hasta el 2016 en la
UG
▪ Subdirector de las carreras de Ingeniería en Sistemas e Ingeniería en Networking, tutor de tesis, miembro de la
Comisión Académica, miembro del Consejo Consultivo, Coordinador de Seguimiento a Graduados
▪ Docente de cursos especiales en la Universidad Politécnica Salesiana en 2008
▪ Cursos de educación continua en empresas de capacitación
▪ Docente en Universidad Ecotec desde 2017 en la Facultad de Ingenierías (Sistemas y Redes)

Experiencia profesional:

▪ Gerente de Sistemas en una empresa multinacional de servicios basados en telefonía y telecomunicaciones,

desde el 2005 hasta la actualidad.
Lineamientos
 Normas generales del curso
modalidad online
• Empatía y respeto entre estudiantes y docente
• Puntualidad y permanencia durante el desarrollo de los cursos virtuales.
• Presionar el ícono de “Levantar la mano” en la plataforma zoom para intervenir al final de
una actividad o tema, de acuerdo a la indicación del capacitador.
• En caso de tener preguntas durante el desarrollo de la asignatura, se solicita colocarlas en el
chat y serán atendidas según el orden de ingreso.
• Los estudiantes no deben grabar las clases. Las clases serán grabadas por parte del docente
y permanecerán en el repositorio indicado por el mismo.
• El primer día de clases se dará la explicación de la metodología.
• El contenido del curso será organizado por temas.
• Se ira añadiendo los contenidos conforme revisemos las clases
• Para la aprobación de la asignatura, los estudiantes deben cumplir con las actividades
sincrónicas y asincrónicas (revisar reglamento de la Universidad).
• El desarrollo de las actividades del curso será en la plataforma educativa MOODLE
• Subir las actividades y tareas según el día correspondiente de apertura y finalización.
Componentes de aprendizaje
Horario de clases
 Objetivo General

Aplicar conceptos, características y técnicas de la Ingeniería de Requerimiento

para la generación de especificaciones correctas que describan con claridad y
consistencia las necesidades del usuario con la finalidad de minimizar los
problemas relacionados a la mala gestión de requisitos.
 Unidades

▪ Unidad I. Introducción y proceso de Ingeniería de

requerimientos

▪ Unidad II. Elicitación de requerimientos

▪ Unidad III. Análisis y especificación de

requerimientos

▪ Unidad IV. Validación y gestión de requisitos

Unidad II. Elicitación de
requerimientos
“Nunca debe perderse de vista porqué se desarrolla el software: para
satisfacer necesidades reales, para resolver problemas reales. La única forma
de resolver las necesidades reales es comunicarse con aquellos que tienen
dichas necesidades. El cliente o usuario es la persona más importante
involucrada en el proyecto”
Alan Davis
 Elicitación de requerimientos - introducción

Es una realidad que entre el 40% y el 60% de los errores y defectos del software
son el resultado de una pobre gestión y definición de requisitos.

En palabras simples, esto significa que aproximadamente la mitad de los

problemas encontrados se podrían haber evitado, simplemente con dejar
claro, desde el principio, lo que el cliente espera del proyecto respectivo.
 Definición de elicitación

La Elicitación de Requisitos –ER– se considera como la primera etapa en el

proceso de abstraer una comprensión del problema que se quiere resolver
con el producto software. Se trata, esencialmente, de una actividad humana
donde se identifican las partes interesadas y se establecen las relaciones
entre el comprador, el cliente, los usuarios y el equipo de desarrollado.

El término Elicitación se utiliza para resaltar el hecho de que los buenos requisitos
no sólo se obtienen desde los clientes, como se indica cuando se utiliza la frase
“recopilación de requisitos”.
 Definición de elicitación

La ER es el componente básico sobre el que se construye un proyecto software y

tiene un impacto muy alto en el diseño y las fases posteriores del ciclo de vida
del producto.

Si se realiza apropiadamente, puede ayudar a reducir los cambios y las correcciones en

los requisitos. Además, la calidad de la elicitación determina la exactitud de la
retroalimentación al cliente acerca de la integridad y validez de los requisitos.

Los productos generados de la elicitación son memorias de levantamiento que

representan información no estructurada.
 Funciones de la elicitación
• Obtener información sobre el dominio del problema y el sistema actual: Esta
tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio
del problema y los contextos organizacional y operacional, o sea, la situación
actual. Se recomienda la construcción de un glosario de términos y un modelado
del sistema actual.

• Preparar y realizar las reuniones: De acuerdo a la información recopilada

anteriormente es necesario identificar a los usuarios participantes con el propósito
de conocer las necesidades de los clientes y resolver, por parte del equipo de
desarrollo, los posibles conflictos. Se utilizan técnicas de elicitación de requisitos y
técnicas de negociación.

• Identificar/revisar los objetivos del sistema: A partir de la función anterior se

identifican los objetivos a alcanzar una vez que el software a desarrollar esté en
explotación y revisar los objetivos identificados, en caso de haber conflictos. Se
realiza el análisis de factores críticos o alguna técnica similar de identificación de
objetivos y la plantilla para especificar los objetivos del sistema.
 Funciones de la elicitación
• Identificar/revisar los requisitos de información : A partir de la información de los
puntos anteriores, se debe identificar, o revisar si existen conflictos en los
requerimientos, qué información es relevante para el cliente y se deberá gestionar
y almacenar el sistema software a desarrollar, así como qué restricciones o reglas
de negocio debe cumplir dicha información.

• Identificar/revisar los requisitos funcionales : Se debe identificar los actores que

interactuarán con el sistema, los requisitos funcionales, expresados en casos de
uso así como su especificación correspondiente y su revisión en caso de conflictos.
Se utilizan técnicas como: casos de uso, plantillas para actores, plantillas para casos
de uso y plantillas para requisitos funcionales.

• Identificar/revisar los requisitos no funcionales: Con la información obtenida

anteriormente se deben identificar y revisar los requisitos no funcionales del
sistema software a desarrollar. Se utilizan técnicas como la plantilla para requisitos
no funcionales.
 Objetivos de la elicitación

• Evaluar la viabilidad comercial y técnica para el sistema propuesto.

• Identificar las personas que ayudarán a especificar los requisitos y a

comprender sus prejuicios organizacionales.

• Definir el entorno técnico –por ejemplo, la arquitectura

computacional, el sistema operativo– en el que funcionará el sistema o
producto.

• Identificar las "restricciones de dominio" –es decir, las características del

entorno empresarial específico para el dominio de aplicación– que
limitan la funcionalidad o el rendimiento del sistema o producto que se desarrolla.
 Actividades de la elicitación

• Preparar la elicitación

• Ejecutar la elicitación

• Documentar la elicitación

• Confirmar resultados de la elicitación

 Actividades de la elicitación

1. Preparar la elicitación.

Organiza y reserva todos los recursos necesarios para las actividades de elicitación
(planificar reuniones, asistentes, lugares de reunión)

Información necesaria:

• Requisitos de negocio, alcance de la solución.

• Lista de interesados con roles y responsabilidades.

• Materiales de apoyo necesarios (documentación pre-existente)

• Seleccionar las técnicas de elicitación a emplear

 Actividades de la elicitación

2. Ejecutar la elicitación:

Consiste en levantar junto a los interesados, sus necesidades usando técnicas

seleccionadas en la actividad 1. Se debe tener en cuenta los objetivos del proyecto
para no desviarse del alcance.

La información obtenida, a pesar de ser aprobada por los interesados, puede estar
incompleta y podrán existir errores que se descubrirán a futuro (Requisitos implícitos),
por lo que el ingeniero de requisitos debe ser capaz de identificar lo que el interesado
piensa que es obvio y no lo menciona para evitar problemas en las siguientes fases.
Por esto es importante que el ingeniero profundice en el conocimiento del negocio
para asegurar que los requisitos sean completos.
 Actividades de la elicitación

3. Documentar la elicitación:

Las técnicas utilizadas en la ejecución de la elicitación determinarán el tipo de

documentación que se generará.

Entre los principales tipos de documentación:

• Documentos como informes y actas de reunión

• Registro de audio y video
• Cuadros con anotaciones.
 Actividades de la elicitación

4. Confirmar resultados de la elicitación:

Es importante revisar los documentos con los interesados para garantizar que la
comprensión del ingeniero esté alineado con la necesidad del interesado. El
interesado podrá generar un listado de cambios que deberán ser incluidos en una
nueva versión del documento.
 Fuentes de elicitación
Identificar las fuentes del conocimiento necesario para la elicitación de los
requerimientos es un objetivo de la Ingeniería de Requerimientos y una actividad
importante para conseguir el desarrollo del software según la necesidad real del
cliente.

Las fuentes de elicitación pueden ser:

Clase 6
 Forma efectiva para hacer preguntas

• Siempre tratar de encausarlas de lo general a lo particular.

• Formularlas en el tono natural normal.
• Plantearlas con seguridad, sin titubeos, mirando directamente a los ojos de los
interlocutores.
• Tener actitud abierta y de escucha activa.
• No interrumpir a menos que sea absolutamente necesario.
• Si surge una duda o pregunta, apuntarla y formularla cuando el interlocutor
termine si intervención.
• No objetar con subjetividades o juicios de valor.
• Tomar atenta nota de lo pertinente, resaltando lo importante.
• Cada cierto tiempo solicitar al interlocutor que le ayude a organizar, agrupar y
jerarquizar ideas/palabras claves/ requerimientos.
Estructura del documento de requisitos del
sistema
 Problemas de la elicitación

El elicitador de requerimientos debe ser consciente de las restricciones de los usuarios

(fuentes de información) que puede generar problemas:

• Dificultad del usuario para describir sus tareas

• Omisión de información
• Limitación de tiempo
• Reacio a colaborar/poca apertura
 Problema de comprensión

• Los clientes/usuarios no están completamente seguros de lo que

necesitan,

• Tienen una comprensión deficiente de las capacidades y limitaciones de su

entorno informático

• No tienen una plena comprensión del dominio del problema

• Tienen dificultades para comunicar sus necesidades al ingeniero de

software

• Omiten información que consideran “evidente”

• Definen requisitos que entran en conflicto con las necesidades de

otros clientes/usuarios.

• Definen requisitos que son ambiguos o incomprobables.

 Problemas de articulación

Los problemas de articulación se presentan en la elicitación de requerimientos por los

siguientes factores:

• Dificultad para expresar claramente las necesidades.

• No ser conscientes de sus propias necesidades.

• No entender como la tecnología puede ayudar.

• Miedo a parecer incompetentes por ignorancia tecnológica.

• No tomar decisiones por no poder prever las consecuencias, no entender las

alternativas o no tener visión global.

• No escuchar adecuadamente a los clientes y usuarios

 Problema de comunicación

• Cultura y vocabulario diferentes

• Intereses distintos en el sistema a desarrollar.

• Medios de comunicación inadecuados (diagramas que no entienden los clientes y

usuarios)

• Conflictos personales o políticos

 Problema de limitaciones cognitivas

• No conocer el dominio del problema

• Hacer suposiciones sobre el dominio del problema

• Hacer suposiciones sobre aspectos tecnológicos

• Hacer simplificaciones excesivas

 Problema de conducta humana

• Conflictos y ambigüedades en los roles de los participantes.

• Pasividad de clientes, usuarios o ingenieros de requerimientos.

• Temor a que el nuevo sistema lo deje sin trabajo.

 Problema técnico

• Complejidad del dominio del problema.

• Complejidad de los requisitos.

• Cambios en los requisitos (cuanto más se ve, más se necesita)

• Cambios en hardware y software, reduciendo el coste.

• Múltiples fuentes de requisitos.

• Fuentes de información poco claras.

 Técnicas de elicitación

De acuerdo con Loucopulos, algunas de las técnicas de elicitación de

requerimientos que pueden ser utilizadas para el levantamiento de requerimientos:

Clase 7
 Técnicas de elicitación

De acuerdo con Nuseibeh y Easterbrook, las técnicas de elicitación se pueden

resumir en:
Técnicas básicas
 Observación in situ

En la observación in situ, el investigador se sumerge en una cultura distinta y

contempla en primera persona y con detención, comportamientos de grupos humanos
o funcionamiento de procesos y servicios.

En este tipo de métodos, la capacidad de observación del investigador es clave. Se

recomienda combinar esta práctica con entrevistas y/o encuestas para obtener mayor
profundidad de información sobre las personas.

Con la observación in situ se espera descubrir información que las personas no

entregan voluntariamente mediante encuestas o entrevistas. Su principal característica
es que permite comparar lo que nos contaron sobre algo y lo que ocurre realmente en
esa situación vista en su contexto.
 Observación in situ

Métodos de observación in situ:

❖ Mosca en la pared (fly-on-the-wall): Se observa en terreno sin intervención del

entorno. Se registran movimientos, conversaciones y acciones. El investigador
debe pasar lo más desapercibido posible.

❖ Observación con participación: Se observa en terreno pudiendo conversar

directamente o hacer preguntas a personas.

❖ Cliente incognito: Se vive la experiencia desde el punto de vista de un cliente y se

corrobora la experiencia de uso de un servicio o producto.

❖ Un día en la vida de: Se vive la experiencia de un servicio desde el punto de vista

de un actor/ trabajador involucrado en la cadena del servicio. Con este método se
buscan alcanzar un alto nivel de empatía al vivir y “padecer” los servicios.
Observación in situ
 Estudio de la documentación

El estudio de documentación consiste en realizar una lectura en profundidad basada

en documentos sobre el dominio del problema del sistema a desarrollar. Dichos
documentos versarán sobre aspectos relativos a los objetivos de negocio de la
organización o sobre sus prácticas profesionales.

Algunos de los principales documentos que se pueden consultar y analizar son:

manuales de procedimientos y funciones, informes generados por el sistema actual,
normativas y legislaciones, manuales de usuario del sistema actual, etc.
 Encuestas

Es una técnica de recopilación de cantidades masivas de datos e información sobre

opiniones, consultas, mejoras del sistema, falencias del sistema. Se basa en un
formulario de preguntas.

La encuesta se la debe realizar si las personas que se necesitan interrogar están muy
dispersas o si se desea conocer la posición de cantidades de personas sobre un tema
en particular.
 Encuestas

Vocabulario a utilizar en la encuesta:

• Mantener la redacción sencilla

• Usar en lo posible el lenguaje de quien contesta
• Ser específico
• Usar preguntar cortas
• Evitar la parcialidad y la censura
• No suponer
• Asegurar la precisión de las preguntas
 Encuestas

Tipos de encuesta:

• Encuestas descriptivas:

Recaban o documentan las actitudes o condiciones presentes. Esto significa que

intentan describir en qué situación se encuentra una determinada población en
el momento en que se realiza la encuesta.

• Encuestas analíticas:

Buscan, además de describir, explicar los por qué de una determinada situación.
En este tipo de encuestas las hipótesis que las respaldan suelen contrastarse por
medio del examen de por lo menos dos variables, de las que se observan
interrelaciones y luego se formulan inferencias explicativas.
 Encuestas

Tipos de preguntas empleadas en las encuestas:

• De respuesta abierta:

En estas encuestas se le pide al interrogado que responda él mismo a la pregunta

formulada. Esto le otorga mayor libertad al encuestado y al mismo tiempo
posibilitan adquirir respuestas más profundas. Por otro lado, permite adquirir
respuestas que no habían sido tenidas en cuenta a la hora de hacer los
formularios y pueden crear así relaciones nuevas con otras variables y respuestas.

• De respuesta cerrada:

Los encuestados deben elegir para responder una de las opciones que se
presentan en un listado que formularon los investigadores. Esta manera de
encuestar da como resultado respuestas más fáciles de cuantificar y de carácter
uniforme. El problema que pueden presentar estas encuestas es que no se tenga
en el listado una opción que coincida con la respuesta que se quiera dar.
 Glosario de términos

Es un pequeño diccionario que contiene términos relativos al dominio del problema.

Cada término tiene un nombre y una definición.

Es una técnica muy sencilla que permite registrar el conocimiento que se va

adquiriendo sobre el dominio del problema y es compartido con todos los
participantes en el proyecto, estableciendo un vocabulario común.

Clase 8
 Glosario de términos

Principio del glosario de términos:

• Principio de circularidad:

Un glosario debe ser tan autocontenido como sea posible, ayuda a que los términos
estén relacionados y que no se deje conocimientos fuera del glosario.

• Principio de mínimo vocabulario:

Los requerimientos deben expresarse usando principalmente elementos del glosario,

ayuda a que sea más comprensible y menos ambiguo.
 Entrevistas

Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en

cualquier proceso de desarrollo de un sistema software ya que es una de las formas de
comunicación más natural entre personas.

En esta técnica se pueden identificar tres fases: preparación, realización y análisis por
lo que no deben improvisarse, o sea debe tener una preparación previa a través de
tareas como:

• Estudiar el dominio del problema.

• Seleccionar a las personas a las que se va a entrevistar.
• Determinar el objetivo y contenido de las entrevistas.
• Planificar las entrevistas.
 Entrevistas
Preparación de entrevista

Conocer el vocabulario del dominio del problema:

• Imprescindible para poder entender al entrevistado.

Seleccionar las personas a entrevistar:

• Se debe minimizar el número de entrevistas.
• Los directivos suelen proporcionar una visión general, mientras que los futuros
usuarios una más detallada.

Determinar objetivos y contenidos de las entrevistas:

• Se debe minimizar el tiempo de la entrevista.
• Los entrevistados deben conocer con antelación el objetivo de la entrevista y las
preguntas que se le van a hacer.

Planificar las entrevistas:

Establecer fecha, hora, lugar y duración de cada entrevista de acuerdo con el
entrevistado
 Entrevistas

Ventajas de las entrevistas

• Ahorran tiempo al contactar con varias personas a la vez.

• Permiten contrastar las opiniones de los participantes directamente en lugar de
hacerlo por separado.
• Suelen generar una mayor implicación de clientes y usuarios.

Inconvenientes de las entrevistas

• Un grupo de personas es mucho más difícil de controlar que una sola persona.
• La planificación es más compleja, al implicar a varias personas.
Entrevistas
 JAD

JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario,

basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha
reunión los temas a tratar se centran más en el negocio que en el asunto técnico.

Lógicamente está más orientado a proyectos de cliente (o bien sistemas a medida,

como también se los conoce), y permite recolectar requisitos eficientemente.

Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una
falsa realidad en cuanto al progreso del proyecto o la productividad.
 JAD

Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular

problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse
partícipes del desarrollo.

Se basa en cuatro principios:

• Dinámica de grupo
• Uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias,
multimedia, herramientas CASE, etc.)
• Mantener un proceso organizado y racional
• Filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve
es lo que se obtiene)

Por la que durante las reuniones se trabaja directamente sobre los documentos a
generar.
 JAD

Dentro de la técnica del JAD se distinguen tres fases:

Fase 1. Adaptación

El jefe del JAD debe adaptar el JAD al proyecto, seleccionar los participantes, definir el
formato de la documentación, planificar las reuniones y preparar material audiovisual
introductorio.

Fase 2. Celebración de las sesiones JAD

• Presentación
• Definir objetivos y requisitos
• Delimitar el ámbito del sistema
• Documentar temas abiertos
• Concluir la sesión
 JAD

Fase 3. Conclusión

• Completar la documentación
• Revisar la documentación
• Validar la documentación
 Lluvia de ideas

El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo

objetivo es la generación de ideas en un ambiente libre de críticas o juicios.

Las sesiones suelen estar formadas por un número de cuatro a diez participantes.
Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de
diferentes formas. Es muy fácil de aprender y requiere poca organización.

Objetivo: Generar ideas en un ambiente libre de críticas o juicios.

• Grupos de 4 a 10 personas, una de ellas es el jefe de la sesión.

• Requiere poca organización y es fácil de aprender.
• Puede generar diferentes vistas del problema,
aunque no con una gran calidad de detalles
Lluvia de ideas
Lluvia de ideas