Este documento introduce el concepto de ingeniería de requisitos y explica que se refiere al proceso de descubrir, analizar, documentar y verificar las descripciones de lo que el sistema debe hacer. Luego define los requisitos, tipos de requisitos (funcionales y no funcionales), y describe algunas técnicas comunes para elicitación y documentación de requisitos como entrevistas, cuestionarios y prototipos. Finalmente, resalta la importancia de documentar los requisitos acordados con el cliente de manera precisa.

1. Introducción a la Ingeniería
de Requisitos
Centro de la Industria, la Empresa
y los Servicios, Regional Huila

2. Ingeniería de Requisitos
1

3. ¿Qué es la Ingeniería de Requisitos?
▪ Al proceso de descubrir, analizar, documentar y
verificar las descripciones de lo que el sistema
debe hacer (el servicio que ofrece y las
restricciones en su operación). (Sommerville,
2011: 83)
▪ 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)
▪ Es la ciencia y disciplina dedicada a analizar y
documentar los requisitos. (Std 24765-2010, IEEE:
308)

4. Síntomas de una inapropiada Ingeniería de Requisitos
• Requisitos faltantes
• Requisitos Incorrectos
• Contradicciones
• Redundancias
• Ambigüedad
• Diferentes Enfoques

5. Definición del Sistema y Contexto
Reciben de su entorno
datos, energía o
materia para
procesarlos y
transformarlos en
información, energía o
materia.
Que
interactúan
entre sí para
lograr un
Objetivo.
Conjunto de
Elementos
organizados,
relacionados,
SISTEMA

6. Definición del Sistema y Contexto
• Alcance del sistema
– El alcance o límite del sistema establece la frontera con su
entorno. Define los aspectos que se pueden cambiar en el
proceso de desarrollo.
• Contexto del Sistema
Todos aquellos factores que son relevantes para definir y
comprender los requisitos del sistema. Entre los aspectos
potenciales residentes en el contexto del sistema están:
– Personas (implicados o grupos de implicados)
– Sistemas en producción (sistemas técnicos, software y
hardware)
– Procesos (procesos técnicos o físicos, procesos de negocio)
– Eventos (técnicos o físicos)
– Documentos (por ejemplo, leyes, estándares,
documentación del sistema)

7. Definición de las fronteras del sistema y del contexto
• Frontera del Sistema:
 ¿Dónde termina el sistema?
 Determinar qué aspectos se encuentran dentro del alcance del
sistema(aspectos cubiertos por el sistema) y cuáles no.
• Frontera del Contexto:
 ¿Qué partes del entorno tienen alguna relación con el sistema(contexto del
sistema)?
 Todo lo demás es irrelevante.

8. Definición de las fronteras del sistema y del contexto
Alcance del
Sistema(futuro
sistema)
Sistemas
Vecinos
Usuarios
Interfaces
Físicas:
▪ Teclado
▪ Pantalla
Lógicas:
▪ Datos de entrada
▪ Datos de salida
Físicas:
▪ Ethernet
Lógicas:
▪ Datos de usuario
Frontera del sistema
Frontera del contexto
Entorno Irrelevante
Contexto del
Sistema

9. Actividad - Sistema y Contexto
Reconocimiento del Sistema y del Contexto
Se necesita un desarrollo tecnológico que permita
fomentar o mejorar el turismo en un municipio del
Departamento del Huila. Teniendo en cuenta esa
necesidad, sugiera que haría parte del contexto
del sistema, liste los factores que usted considere
que tengan relación con dicho contexto.
Socialice los resultados obtenidos con el resto de
participantes del curso.

10. ¿Qué son los Requisitos?
• “Una condición o necesidad de un usuario para resolver un problema
o alcanzar un objetivo”. (Std 24765-2010, IEEE: 307)
• “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 24765-2010, IEEE: 307)
• “Son descripciones de lo que el sistema debe hacer: el servicio que
ofrece y las restricciones en su operación”. (Sommerville, 2011: 108)
• “Es una característica del sistema o una descripción de algo que el
sistema es capaz de hacer con el objeto de satisfacer el propósito del
sistema”. (Cristiá, 2011: 3)

11. Sobre los Requisitos
• No es lo mismo un pedido o deseo de un usuario o cliente que un
requisito. No todos los pedidos o deseos de un usuario o cliente se
convierten necesariamente en requisitos, pero sí todos los
requisitos se originan en un pedido o deseo de un usuario o cliente.
• Para que un pedido o deseo de un usuario o cliente se convierta en
requisito, este debe ser documentado apropiadamente y el
solicitante debe validarlo.
• Los ingenieros de software no originan los requisitos; su función es
convertir pedidos de los usuarios o clientes en requisitos. Luego
deben proveer un sistema que los implemente.(Cristiá, 2011: 4)

12. Características de los Requisitos
Características
de los
Requisitos
Especificado
por Escrito
Posible de
probar o
verificar
Conciso
Completo
Consistente
No Ambiguo

13. Tipos de Requisitos
Requisitos Funcionales
• Son los que definen las funciones que el sistema será capaz de
realizar, describen las transformaciones que el sistema realiza sobre
las entradas para producir salidas. (Arias, 2007: 3)
• Son enunciados acerca de servicios que el sistema debe proveer, de
cómo debería reaccionar el sistema a entradas particulares y de
cómo debería comportarse el sistema en situaciones específicas.
(Sommerville, 2011: 84)
• Un requisito funcional describe una interacción entre el sistema y su
ambiente. Los requisitos funcionales describen cómo debe
comportarse el sistema ante un estímulo.

14. Tipos de Requisitos
Requisitos no Funcionales
• Características que de una u otra forma que puedan limitar el sistema,
como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de
usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),
mantenimiento, seguridad, portabilidad, estándares, etc. (Arias, 2007:
3)
• Son limitaciones sobre servicios o funciones que ofrece el sistema.
Incluyen restricciones tanto de temporización y del proceso de
desarrollo, como impuestas por los estándares. (Sommerville, 2011: 85)
• Un requerimiento no funcional es una restricción sobre el sistema o su
proceso de producción.

15. Ejemplos de Requisitos
Requisitos Funcionales
• Para un Editor de Texto:
– El usuario debe poder seleccionar un área de texto, lo que se representaría gráficamente
pintando el fondo del área con un color diferente al fondo que el área tenga en ese momento.
– El usuario debería poder ejecutar la función negrita desde un botón ubicado en una de las
barras de herramientas, mediante la combinación de teclas que se le haya asignado a dicha
función en ese momento y mediante la opción de menú Formato-Negrita.
• Para un Sistema de Facturación:
– El sistema debería permitir buscar, en la lista de clientes de la empresa, y completar
automáticamente la razón social del destinatario del sistema a medida que el usuario la
digita.
– Una vez ingresada la razón social del solicitante, si corresponde a un cliente de la lista de
clientes de la empresa, el sistema completaría automáticamente el NIT del solicitante.
• Para un Sistema de Biblioteca en línea:
– El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el
almacén de documentos.
– A cada pedido se le deberá asignar un identificador único, que el usuario podrá copiar al área
de almacenamiento permanente de la cuenta

16. Ejemplos de Requisitos
Requisitos no funcionales
• Toda funcionalidad del sistema y transacción de negocio debe responder
al usuario en menos de 5 segundos.
• Todos los sistemas deben respaldarse cada 24 horas. Los respaldos
deben ser almacenados en una localidad segura ubicada en un edificio
distinto al que reside el sistema.
• La aplicación web debe poseer un diseño “Responsive” a fin de
garantizar la adecuada visualización en múltiples computadores
personales, dispositivos tableta y teléfonos inteligentes.
• El procedimiento de desarrollo de software a usar debe estar definido
explícitamente (en manuales de procedimientos) y debe cumplir con los
estándares ISO 9000.
• Las páginas web a ser desarrolladas deben cumplir con la ley de
tratamiento en condiciones de igualdad para personas con discapacidad.

17. Elicitación de Requisitos
• La elicitación de requisitos consiste en hallar e
identificar los requisitos que deben satisfacer un
determinado sistema de información.
• La elicitación de requisitos inicia con el análisis del
contexto del sistema y de las fuentes de requisitos.
• La educción de requisitos se refiere a la captura y
descubrimiento de los requisitos.
• Es una actividad más “humana” que técnica.
• Se identifica a los interesados y se establecen las
primeras relaciones entre ellos y el equipo de
desarrollo.

18. Fuentes de Requisitos
Las principales fuentes de requisitos son:
• Implicados (Stakeholders)
• Documentos
• Sistemas en Operación

19. StakeHolders
Un Stakeholder (interesado) representa un grupo de
personas
• Que tienen un interés en el resultado del proyecto
• Cuyas necesidades deben ser satisfechas por el
proyecto
Un participante en el sistema es quien debe tener alguna
influencia directa o indirecta sobre los requerimientos del
mismo.
Los participantes incluyen a usuarios finales que
interactuarán con el sistema, y a cualquiera en una
organización que resultará afectada por él. (Sommerville,
2011: 101)

20. Categorización de Requisitos según Modelo de Kano

21. Técnicas de Elicitación
Observación
Creativas
Basadas en la
documentación
Soporte
Prospección
• Entrevistas
• Cuestionarios
• Brainstorming
• Cambio de perspectiva
• Arqueología de sistema
• Reutilización de requisitos
• Mapas mentales
• Talleres
• Grabaciones de audio y vídeo
• Modelado de casos de uso
• Prototipos
• Observación de Campo
• Aprendizaje

22. Documentación de Requisitos
• En esta fase se documentan los requisitos
acordados con el cliente, en un nivel
apropiado de detalle.
• En la práctica, está etapa se va realizando
conjuntamente con el análisis, se puede decir
que la especificación es el "pasar en limpio"
el análisis realizado previamente aplicando
técnicas y/o estándares de documentación.

23. Estructura de la Documentación
• IEEE 830 – 1998
• Volere
• IEEE 1233 – 1994
• Rational Unified Process (RUP)
• Modelo-V 2004

24. Tipo de documentación
Para documentar pueden usarse las siguientes formas:
• Documentación de requisitos en lenguaje natural
– Multipropósito, fácil de entender
– Apropiado para las 3 perspectivas (de datos, funcional y comportamiento)
– Impreciso, se pueden mezclar las perspectivas
• Modelos conceptuales de requisitos tales como diagramas de casos de uso,
diagramas de clase, diagramas de actividad y diagramas de estado
– Precisos y entendibles debido a su sintaxis formal
– Es necesario tener conocimiento de la notación
• Formas combinadas de documentación de requisitos.

25. Beneficios de una estructura de documento uniforme
• Reusabilidad en fases subsiguientes del desarrollo
• Definiciones de casos de prueba
• Completar capítulos
• Orientación a nuevos miembros del equipo
• Rápida identificación y asimilación de contenidos
• Facilidad para la comprobación de la completitud de contenido
para cada tema
• Aseguramiento de implementación de estándares para el
contexto de un proyecto específico

26. Uso del Documento de Requisitos
• Planificación
• Diseño del sistema
• Implementación
• Pruebas
• Gestión del cambio
• Despliegue y mantenimiento
• Gestión de contratos

27. Criterios de Calidad para los Documentos de Requisitos
• Ausencia de ambigüedad y consistencia
• Estructura clara
• Capacidad de ser modificado y capacidad de ser
ampliado
• Completitud
• Trazabilidad

28. Criterios de Calidad para los Documentos de Requisitos
• Consensuado
• Evaluado
• No ambiguo
• Válido y actualizado
• Correcto
• Consistente
• Verificable
• Realizable
• Trazable
• Completo
• Comprensible
Además de estos criterios de calidad, existen dos reglas básicas de estilo para los requisitos
expresados en lenguaje natural que ayudan a su legibilidad:
• frases y párrafos cortos;
• sólo un requisito por frase.

29. Documentación en Lenguaje Natural
Ventajas
• Expresivo
• Intuitivo
• Universal
Desventajas
• Potencialmente vago
• Ambiguo
• Significado depende de los Antecedentes del
Lector

30. Documentación en Lenguaje Natural
Los Procesos de transformación más importantes para la IR son:
• Nominalización
• Sustantivos sin índice de referencia
• Cuantificadores universales
• Condiciones especificadas de manera incompleta
• Palabras de proceso especificadas de forma incompleta

31. Como minimizar la interpretación errónea en Lenguaje
Natural
1. Elabore un formato estándar y asegúrese de que todas las definiciones de
requerimientos se adhieran a dicho formato.
2. Utilice el lenguaje de manera clara para distinguir entre requerimientos
obligatorios y deseables.
3. Use texto resaltado (negrilla, cursiva o color) para seleccionar partes clave del
requerimiento.
4. No deduzca que los lectores entienden el lenguaje técnico de la ingeniería de
software.
5. Siempre que sea posible, asocie una razón con cada requerimiento de usuario.

32. Uso de Plantillas
Los cinco pasos para la formulación de requisitos a través de
una plantilla son:
1. Determinar la obligatoriedad
2. Establecer el núcleo del requisito
3. Caracterizar la actividad del sistema
4. Incluir objetos
5. Determinar condiciones lógicas y temporales

33. Uso de Plantillas
Determinar la obligatoriedad (permite hacer la priorización)
DEBE: vínculo obligatorio
DEBERÍA: fuertemente recomendado (importante)
PODRÁ: cumplimiento de requisitos futuros (opcional)
Ejemplo:
“El usuario debe ser capaz de modificar su información”

34. Uso de Plantillas
Establecer el núcleo del requisito
Para describir una actividad o un procedimiento únicamente se permitirá el
uso de verbos, cuyo significado debe ser comprendido por todos los
implicados (stakeholders).
Ejemplo:
“El sistema deberá ser capaz de imprimir”
Nota: para evitar ambigüedades se recomienda utilizar glosarios.

35. Uso de Plantillas
Caracterizar el comportamiento del sistema
Los 3 tipos de comportamiento son:
a) Actividad autónoma del sistema
b) Interacción del usuario
c) Requisitos sobre las interfaces del sistema

36. Uso de Plantillas
Identificar los objetos involucrados
Previene el uso de verbos definidos de forma incompleta (efecto del
lenguaje).
Ejemplo:
“El sistema deberá ofrecer posibilidades de imprimir los recibos”

37. Uso de Plantillas
Incluir las condiciones lógicas y temporales
Condición lógica: tan pronto como, después, durante, antes
Condición lógica: Si…
Ejemplo:
“Tras concluir el registro, y si el usuario cuenta con autorización, el sistema debe
ofrecer la posibilidad de imprimir la factura”

38. Uso de Plantillas
¿Cuándo?
¿Bajo que
condiciones?
EL SISTEMA
DEBE
DEBERÍA
DEBERÁ
-
<¿CUÁNDO?>
OFRECERÁ LA
POSIBILIDAD DE
SERÁ CAPAZ DE
<VERBO>
<OBJETO Y
DETERMINACI
ÓN>

39. Documentación basada en Modelos
Definición de Modelo
Es una imagen abstracta de la realidad (abstracción) existente o de la
realidad a desarrollar.
Características de los Modelos:
• Característica de Representación
• Característica de Reducción
• Característica Pragmática

40. Validación y Negociación de Requisitos
• La validación de requerimientos es el proceso de verificar que los
requerimientos definan realmente el sistema que en verdad quiere el
cliente. Se traslapa con el análisis, ya que se interesa por encontrar
problemas con los requerimientos.
• La validación de requerimientos es importante porque los errores en un
documento de requerimientos pueden conducir a grandes costos por tener
que rehacer, cuando dichos problemas se descubren durante el desarrollo
del sistema o después de que éste se halla en servicio. (Sommerville, 2011:
110)

41. Validación y Negociación de Requisitos
Comprobaciones realizadas durante la validación:
• Comprobaciones de validez
• Comprobaciones de consistencia
• Comprobaciones de totalidad
• Comprobaciones de realismo
• Verificabilidad

42. Validación y Negociación de Requisitos
Técnicas de Validación de Requisitos
• Revisiones de requerimientos
• Creación de prototipos
• Generación de casos de prueba

43. Referencias
• Manquillo, Paola, Martelo Ronald. Curso Especificación de Requisitos
de Software. Escuela Nacional de Instructores del SENA.
• Choucair Effective Software Testing, Formación para profesional
Certificado en Ingeniería de Requisitos - Nivel Básico IREB.

44. Muchas Gracias
César Marino Cuéllar Chacón
Instructor Desarrollo de Software
Centro de la Industria, la Empresa
y los Servicios, Regional Huila