La ingenieria de requisitos puede ser perjudicial debido a la sobre ingenieria en los problemas. Esta presentación esta basada en el artículo en: https://ieeexplore.ieee.org/document/7184708

1. ¿Es la ingeniería de requisitos
perjudicial para el desarrollo?
Jesús Eduardo Uriegas Ibarra

2. ¿Qué hace la ingeniería de requisitos?
Producir requisitos (necesidades
para lograr el objetivo del
sistema) no ambiguos,
consistentes, completos y
verificables.
Estos se dividen en 2 áreas:
● Hacer sentido del problema
● Estructurar el problema

3. Hacer sentido y estructuración del problema
Hacer sentido.
Involucra aprender, entender y organizar las
creencias sobre el contexto.
Estructuración del problema.
Involucra asignar restricciones socialmente
construidas, parámetros, opciones, y otras
especificaciones al contexto.

4. ¿Son realmente beneficiosos estos 2 aspectos al software?
Los datos muestran que no el hacer sentido es bueno para crear el software, mientras
que estructurar el problema simplifica la realidad y añade restricciones que en realidad
no lo son, así como que no es posible formular el problema y esperar que alguien más
lo diseñe, ya que ambas acciones están interconectadas.

5. Tareas de diseño mal estructurados
Los datos también han mostrado que aquellos arquitectos e ingenieros de software que
desarrollan bajo tareas de diseño mal estructuradas realizan un mejor software con una
mejor arquitectura que aquellos con diseños sin ambigüedad, medibles y bien
estructurados; además, estos últimos restringen la creatividad de los desarrolladores.

6. Ambigüedad: Relación entre ingeniería de requisitos y derecho
En ciencias de la computación y matemáticas la
ambigüedad es mal vista debido a que el objetivo es crear
algoritmos, modelos o sistemas que sean cuantificables e
implementables en una máquina.
En ingeniería de requisitos es deseable la ambigüedad
para tener un abanico de posibles interpretaciones a un
requisito cuya formulación puede cambiar en el futuro; lo
mismo sucede en derecho para no tener que reformar
leyes y hacer una interpretación al vuelo para agilizar la
resolución de problemas judiciales.

7. Recomendaciones
1. Separar el hacer sentido de estructurar el problema.
2. Aplicar herramientas y técnicas para lidiar con tareas de diseño mal estructuradas.
3. Utilizar instrumentos para medir el conocimiento de dominio.
4. Abrazar la ambigüedad.
5. Preguntar por soluciones creativas para evitar la sobre estructuración.

8. Referencia
P. Ralph and R. Mohanani, "Is Requirements Engineering Inherently
Counterproductive?," 2015 IEEE/ACM 5th International Workshop on the Twin Peaks
of Requirements and Architecture, 2015, pp. 20-23, doi: 10.1109/TwinPeaks.2015.12.