Ingeniería de Software
Dra. Vianca Vega Zepeda
Fundamentos
El Proceso
Elicitación de Requisitos
Documentos de especificación
Validación
Gestión de requisitos
¿Qué es Ingeniería de requisitos?
¿Qué es un requisito de software?
¿Por qué Ingeniería de Requisitos?
“No se puede dar en el blanco, si no se sabe
dónde está el objetivo”
“Los proyectos sin metas claras,
claramente no alcanzarán sus
metas”
Propósitos del Producto
¿Qué hacer para alcanzar ¿Qué cualidades debe
los propósitos? tener el producto?
Requerimientos Requerimientos
Funcionales No Funcionales
(Propiedades de Calidad)
Siempre No saben
No Quieren
dicen No se Todo lo
lo que
tienen decirme cómo
“No” comprometen ni quieren para
quieren
idea del hacer mi
responsabilizan mañana
negocio trabajo
Clientes y Usuarios Equipo desarrollador
STAKEHOLDERS
Interfaz
Desempeño Seguridad
Mantenibilidad Usabilidad
Usabilidad Desempeño Seguridad
Adecuación
Confidencialidad
Aprendizaje Tiempo
Facilidad de Uso
Integridad
Protección contra errores
Estética de la interfaz Espacio
Disponibilidad
Accesibilidad
Usuarios
Sistema
Desarrolladores
Restricciones
Restricciones
Competencia
Validación
Especificación
Análisis
Elicitación
Identificación de los stakehoders
Gestión de requisitos
1. Identifique los usuarios del sistema
2. Para cada usuario
1. Identificar quién le entrega información
2. Identificar a quién le entrega información
3. Para cada nuevo stakeholders identificado,
repetir los paso 2.1 y 2.2
4. La iteración finaliza cuando no aparecen
nuevos actores
La elicitación de requerimientos no es un
proceso fácil
Requiere un análisis riguroso de:
la organización
el dominio de aplicación
cómo funcionará el sistema
Es un proceso muy importante
Desde el punto de vista de los stakeholders:
usualmente no saben lo que quieren
no se saben expresar; articular y formular ideas
tienen ideas poco realistas o exageradas
debido a que no conocen el costo de su
elaboración
diferentes stakeholders formulan diferentes
requerimientos; expresan lo mismo en manera
diferentes
Desde el punto de vista del cliente:
se expresan en sus propios términos
utilizan el conocimiento tácito para
representar sus ideas
El analista debe entender el dominio del
cliente para formular los requerimientos en
un lenguaje común para todos
Desde el punto de vista de la organización:
factores políticos, sociales o
gubernamentales pueden afectar el
comportamiento del software
estos problemas no son obvios para los
usuarios finales
directores o gerentes solicitan requerimientos
específicos que influyen en el software
Una facilidad a nivel usuario
Una descripción en detalle de una
propiedad del sistema
Restricciones específicas del sistema
Restricciones sobre el proceso de
desarrollo
Entrevistas
Cuestionarios
Casos de uso
Escenarios
Lluvia de ideas
Observaciones
Estudios de documentación
Prototipos (utilizados en gran medida
para validar)
Técnica Observaciones
Entrevistas Estructuradas / Semiestructuradas / Libres
Cuestionarios Rectificar vacíos en la entrevistas
Detallar conceptos del dominio
Entender procesos del negocio
Casos de Uso Describen una lista de acciones que tienen un orden lógico
entre un actor y el sistema
Escenarios Descripción de ejemplos de uso del sistema
Lluvia de Ideas Formular soluciones a un problema concreto
Involucran dos o más personas relacionadas con el entorno
del sistema
Observaciones Los observadores pueden ser los especialistas en requisitos o
los ingenieros de desarrollo
Observar la forma en que trabajan los usuarios
Generalmente se realizan observaciones in situ
Estudio Revisión de la literatura disponible
documentación Su objetivo es contextualizar al analista en el dominio y
comprender de mejor manera el sistema a desarrollar
Req004
Req004
Uso de plantillas
Estructura estándar
Documento de
Especificación Lenguaje simple,
consistente y
sencillo.
Identificar de
Fácil de modificar Manera única
cada requerimiento
Req004
Req004
Planificar para enfrentar
los conflictos
Políticas de
Administración
Inspecciones
formales Uso de checklist
Tipos de documentos:
Requisitos-C
Requisitos-D
Plantillas:
◦ Estándar IEEE - 830
◦ Template Volere
Scrum Product backlog
XP Historias de Usuario
Product Backlog
1. Lenguaje natural
2. Lenguaje natural estructurado
3. Diseño de lenguaje descriptivo
4. Notaciones gráficas
5. Especificaciones matemáticas
Todos los requisitos están escritos siguiendo
un estándar o modelo.
Existe cierta uniformidad en la especificación
[Sujeto] [Acción] [Valor]
Ejemplo: “El sistema de facturación deberá
mostrar las facturas pendientes de pago del
cliente en orden ascendente a respecto a la
fecha de cancelación”.”.
Se debe evitar en lo posible, el uso de:
Términos superlativos (“el mejor”, “el más)
Lenguaje subjetivo (“fácil de usar”)
Pronombres imprecisos (“eso”, “este”)
Términos de composición abierta, que no
puedan ser verificados (“provee soporte”,
“como mínimo”)
La entrega de referencias incompletas (sin
fecha de entrega, versión)
Todos los supuestos formulados en relación
con un requerimiento deberán estar
documentados.
Bosquejo de una solución o un proceso (sin
gastar muchos recursos)
Entregan una visión de alto nivel respecto a
lo que se entiende del cliente y lo que se
quiere desarrollar/implementar
Documentación de
los requerimientos
(Descripción
narrativa y/o Propuestas
modelos)
Cambios
Evolución de los Discusión de los
requerimientos requerimientos
(Cambios) (Preguntas,
respuestas,
justificaciones)
Decisión
Identificación y almacenamiento de los
requerimientos
Gestión de cambios
Trazabilidad de los requerimientos
Autorización de Excepciones
Objetivo:
Mantener las relaciones entre los requerimientos y
los elementos de diseño, componentes y
documentación.
Políticas de trazabilidad:
◦ Qué información mantener
◦ Qué técnicas usar
◦ Cuándo recolectar la información
◦ Cómo manejar las excepciones
Tipos de trazabilidad:
Requerimientos – Fuente
Requerimientos – Motivación
Requerimientos – Requerimientos
Requerimientos – Arquitectura
Requerimientos – Diseño
Requerimientos – Interfaz
Relaciones entre requerimientos
◦ Especifica / Es especificado por
◦ Requiere / Es requerido por
◦ Restringe / Es restringido por
Técnicas Básicas
◦ Matriz de
trazabilidad
R1 R2 R3
R1 * *
R2
R3 *
“Es especificado por”
◦ Listas de trazabilidad Requerimiento Es requerido por
R1 R3, R4
R2 R4
R3
R4
◦ Enlaces automáticos de
trazabilidad
