1. INGENIERÍA DE
REQUISITOS
DE SOFTWARE
TEMA 1
Prof. Magemyl Egaña

2. La Ingeniería de Requisitos (IR) juega un papel
crucial a lo largo de todas las fases del desarrollo
de software, considerándose como el proceso
técnico de inicio que ocurre en el espacio de la
solución del problema del usuario.
La IR se encarga de caracterizar la aplicación con
base a las necesidades y los requerimientos de los
usuarios y provee los procesos de identificación,
análisis, especificación, validación y gestión de los
requisitos que los sistemas de software o
aplicaciones deben cumplir. (Barrios y Montilva,
2006).
DEFINICIÓN
02

3. DEFINICIÓN
03
“Ayuda a los ingenieros de software a entender
mejor el problema en cuya solución trabajarán.
Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software
sobre el negocio, qué es lo que el cliente
quiere y cómo interactuarán los usuarios
finales con el software”. (Pressman, 2006: 155)
“Proceso para desarrollar una especificación
de software. Las especificaciones pretender
comunicar las necesidades del sistema del
cliente a los desarrolladores del sistema”.
(Sommerville, 2005: 82).

4. BENEFICIOS
04
Permite gestionar las necesidades del proyecto de
forma estructurada.
Mejora la calidad del software, pues éste cumple
cabalmente con el conjuntos de requisitos descritos
y documentados (funcionalidad, usabilidad,
desempeño, entre otros).
Mejora la comunicación entre los integrantes del
equipo de trabajo de IS, representando una forma
de tener consenso entre el usuario y el equipo de
desarrollo.
Evita rechazo por parte del usuario final.
Genera insumos importantes para la fase de diseño
arquitectónico y pruebas de software.

5. MODELADO DE NEGOCIO VS
INGENIERÍA DE REQUISITOS
MODELADO DE NEGOCIO
CONTEXTO ORGANIZACIONAL
Qué y cómo hace la empresa
INGENIERÍA DE REQUISITOS
05
CONTEXTO SOFTWARE
Qué y cómo hace el software
EL PROBLEMA
Objetivos, procesos, objetos, reglas, actores, eventos
LA SOLUCIÓN
Requisitos funcionales, no funcionales y complementarios

6. ¿QUÉ ES UN
REQUERIMIENTO?
06
Originado del deseo del usuario por
resolver un problema.
Deseo que tiene el usuario sobre un
posible producto de sofware que
resuelva su problema dentro de la
empresa.
Necesidad documentada en lenguaje de
usuario.

7. ¿QUÉ ES UN
REQUISITO?
07
Originado del requerimiento del usuario,
para resolver su problema.
Condición o capacidad que debe tener un
software para cumplir el deseo del usuario.
Especificación de lo que necesita el
software para cumplir la petición de
usuario, documentado con un lenguaje
técnico dirigido a una audiencia específica.

8. ¿QUÉ ES UN REQUISITO?
•Una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo”
(Std 610.12-1900, IEEE: 62).
08
•Una condición o capacidad que debe estar presente
en un sistema o componentes de sistema para
satisfacer un contrato, estándar, especificación u otro
documento formal” (Std 610.12-1900, IEEE: 62).
Una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de
éste”(Sommerville, 2005: 108).

9. CONDICIÓN DEL REQUISITO
09
Especificado por escrito, como si fuera un contrato o un
acuerdo entre partes.
Probable y verificable; sí no se puede comprobar,
entonces ¿cómo se sabe si se cumplió con él o no?
Conciso, fácil de leer y entender, redactado de forma
simple y clara para aquellos que deseen consultar a
futuro.
Completo, que no necesite ampliar detalles en su
redacción, es decir, la información proporcionada es
suficiente para su comprensión.
Consistente, sin contradecir a otro requisito.
No ambiguo, posee una sola interpretación. El lenguaje
usado en su definición, no debe causar confusiones al
lector.
1.
2.
3.
4.
5.
6.

10. Durante la etapa de descubrimiento, análisis y
especificación de requisitos, se pueden presentar
muchos inconvenientes, los cuales son importantes
de identificar y prevenir; entre los más comunes
tenemos:
•Los requerimientos no son obvios y vienen de
muchas fuentes.
•Los requerimientos son difíciles de expresar en
palabras (el lenguaje es ambiguo).
•La cantidad de requerimientos del usuario es
difícil de manejar.
DIFICULTADES
10

11. •Cambio en los requisitos durante el ciclo de
desarrollo.
•El usuario no explica lo que realmente hace en
un determinado proceso y tiende a recordar lo
excepcional y olvidar lo rutinario e importante.
•El usuario se centra en lo que no funciona del
proceso.
•El usuario difiere del Desarrollador, pues
manejan distintos vocabularios.
•El usuario usa el mismo término pero con
distintos significado.
DIFICULTADES
11

12. TIPOS DE REQUISITOS
12
•FUNCIONALES: define “qué hace el sistema”, las
funciones que el sistema será capaz de hacer y las
transformaciones del sistema (entradas-proceso-
salidas).
•NO FUNCIONALES: define “cómo hace el
sistema”, los atributos de calidad del sistema, las
restricciones y limitaciones del sistema.
•COMPLEMENTARIOS: define aquellas
restricciones técnicas no contempladas en los
requisitos no funcionales.

13. PREGUNTAS
Y
RESPUESTAS
13