Please enable JavaScript.
Coggle requires JavaScript to display documents.
REQUERIMIENTOS Y DRIVERS ARQUITECTONICOS - Coggle Diagram
REQUERIMIENTOS Y DRIVERS ARQUITECTONICOS
Requerimientos
Definición (Wiegers, 2013)
Especifican funcionalidades, atributos o factores de calidad del sistema
Pueden imponer restricciones sobre cómo se construye el sistema
Objetivo del negocio ↔ sistema
Los comportamientos/funciones soportan procesos de negocio
Además puede haber restricciones (fechas, presupuesto, tecnologías)
Ingeniería de requerimientos
Obtención, análisis, documentación y validación de requerimientos
Requerimientos: tipos y niveles de abstracción
Actores e interés
Patrocinadores/negocio • Usuarios finales • Equipo de desarrollo
Capas (alto → bajo nivel)
Requerimientos de negocio
Visión y alcance • Reglas de negocio • Atributos de calidad
Requerimientos de usuario
Requerimientos de sistema
Requerimientos funcionales detallados
Interfaces externas
Restricciones
Especificación de requerimientos de software (documento)
Notas
La importancia de cada requerimiento depende del interesado
Clasificar por tipo/nivel facilita comprensión y manejo
Requerimientos de usuario vs funcionales
Requerimientos de usuario (servicios para procesos de negocio)
Ej.: “Comprar boleto en línea”
Se suelen capturar con Casos de uso o Historias de usuario
Requerimientos funcionales detallados (diseño/implementación)
Ej.: “Elegir origen y destino desde un combo”
Ej.: “Correos de confirmación de pago deben ser HTML”
Atributos de calidad
ISO/IEC 9126 (categorías y ejemplos)
Funcionalidad: pertinencia, precisión, interoperabilidad, seguridad, conformidad
Confiabilidad: madurez, tolerancia a fallas, recuperación, conformidad
Usabilidad: entendimiento, facilidad de aprendizaje, operabilidad, atractivo, conformidad de uso
Eficiencia: tiempo de respuesta, uso de recursos, conformidad
Facilidad de mantenimiento: análisis, cambio, estabilidad, ser probado, conformidad
Portabilidad: adaptabilidad, instalación, coexistencia, reemplazabilidad, conformidad
Bass, Clements y Kazman (2012) – 7 categorías frecuentes
Disponibilidad • Seguridad • Desempeño • Facilidad de prueba • Modificabilidad • Usabilidad • Interoperabilidad
Clave
No hay valores universales: deben especificarse para poder evaluarlos en diseño/implementación
Restricciones
Restricciones técnicas
Software/terceros, métodos, hardware, lenguajes
Ej.: DBMS debe ser freeware
Restricciones administrativas
Costo, tiempo, equipo
Ej.: desarrollo en ≤ 12 meses
Reglas de negocio e interfaces externas
Reglas de negocio
Políticas/estándares/procedimientos que rigen procesos de la organización
Influyen en otros tipos de requerimientos
Ej.: regla para calcular descuento de boletos
Interfaces externas
Detalles necesarios para comunicarse con software/hardware externos
Ej.: pago con tarjeta requiere integración con pasarela de pagos
Consideraciones importantes
Las reglas suelen existir fuera del sistema pero afectan requisitos
Drivers de calidad y restricciones guían decisiones de diseño
Drivers arquitectónicos
Tipos
Drivers funcionales • Drivers de atributos de calidad • Drivers de restricciones
Drivers funcionales (casos de uso)
CU-01: Consultar corridas por criterios
CU-02: Comprar boletos (razón primaria del sistema)
CU-03: Cancelar boletos
CU-04: Imprimir/reimprimir boletos
CU-05: Alta de usuario para compra e impresión
CU-06: Ingreso para consultas, reportes y tareas administrativas
CU-07: Generar reportes de análisis
CU-08: ABM de entidades del sistema
Criterios de elección
CU-02 = razón de ser del sistema
CU-01 debe soportar concurrencia y otros atributos de calidad
Drivers de atributos de calidad (escenarios)
Formato: Fuente/Estímulo • Artefacto • Entorno • Respuesta • Medida
EAC-01 Desempeño
Usuario pulsa “buscar” con ciudades y fechas → en operación normal → sistema muestra lista de corridas → ≤ 2 s
EAC-02 Disponibilidad
Falla interna detiene operación → sistema vuelve a operar normalmente → ≤ 10 min
EAC-03 Seguridad
Atacante intercepta comunicación → sistema no expone datos en claro → canal cifrado
EAC-04 Usabilidad
Usuario captura con errores en navegador → sistema muestra mensajes claros e instrucciones
EAC-05 Facilidad de prueba
Pruebas unitarias sobre componentes → ejecución repetible y con datos persistentes/semillas
EAC-06 Modificabilidad
Cambio en interfaz o componente → impacto acotado; evitar recompilar todo el sistema
Otra información
Reglas de negocio e interfaces externas pueden determinar estructuras/elementos
Influencia en el diseño
Implementar funcionales en “aislado” puede ser simple
Con restricciones y atributos de calidad, las decisiones dejan de ser triviales
Fuentes para extracción de drivers
Documento de Visión y Alcance (estructura típica)
1) Requerimientos de negocio
Antecedentes • Oportunidad • Objetivos/criterios de éxito • Necesidades del cliente/mercado • Riesgos
2) Visión de la solución
Enunciado de visión • Características • Suposiciones y dependencias
3) Alcance y limitaciones
Versión inicial • Versiones subsecuentes • Exclusiones
4) Contexto de negocio
Perfiles de interesados • Prioridades del proyecto • Ambiente de operación
Ejemplos de “Ambiente de operación”
Navegadores soportados • Móviles soportados • Prohibir Flash/applets
DB legado Oracle v11.2 • Integración vía servicios web
Criterios de aceptación (sistema instalado/funcionando; servicios publicados; protocolo de pruebas, etc.)
Métodos para identificación de drivers
QAW (Taller de Atributos de Calidad)
Participación activa de interesados • Facilitadores (líder y secretarios)
Escenarios de calidad como unidad de especificación
8 etapas
Introducción y presentación
Presentación de la organización
Boceto de la arquitectura
Identificación de drivers
Generación de escenarios
Consolidación de escenarios
Priorización de escenarios
Refinamiento de escenarios
Salida: drivers y escenarios priorizados
ACDM (Diseño centrado en la arquitectura
)
Fases
Identificación de drivers
Especificación del alcance
Creación/refinamiento de la arquitectura
Revisión de la arquitectura
Decisión de llevar a producción o no
Experimentación
Planeación de la implementación
Implementación
Roles: PM, soporte, arquitecto líder, ing. de requisitos/tecnología/calidad/producción, devs, diseñadores, integradores, usuarios, directivos
Salidas: drivers documentados y priorizados + plan maestro de diseño actualizado
FURPS+ (Modelo)
Categorías: Funcionalidad • Usabilidad • Confiabilidad • Desempeño • Soportabilidad
“+” incluye: restricciones de diseño/implementación • físicas • de interfaz
Considera todos los drivers • Usado en RUP
Comparación de métodos y modelo
QAW (taller)
Duración 1–2 días • Presentaciones + lluvia de ideas • Proceso definido
Salida: drivers + escenarios priorizados
Terminación: escenarios completos/priorizados
Enfoque: atributos de calidad
ACDM (taller)
Uno o más talleres • Proceso definido
Salida: todos los drivers completamente documentados/priorizados
Terminación: drivers completamente documentados
Enfoque: TODOS los drivers
FURPS+ (modelo)
Se usa dentro de un proceso de desarrollo
Drivers: TODOS
Resumen
Tres tipos de drivers
Funcionales • Atributos de calidad • Restricciones
Idea clave
Los drivers de calidad y las restricciones suelen influir más en el diseño de la arquitectura
Métodos y modelos aplicables
QAW • ACDM • FURPS+