Contenido del curso
Requisitos funcionales y no funcionales en arquitectura de software
¿Sabes cómo determinar si un sistema informático posee la calidad adecuada? Dominar los requisitos funcionales y no funcionales es clave en arquitectura de software para garantizar un sistema robusto, íntegro y adaptable en el tiempo.
¿Qué son los requisitos funcionales y por qué son importantes?
Los requisitos funcionales definen específicamente qué problemas resuelve un sistema. Se centran principalmente en:
Estos requisitos se clasifican en:
Un método reciente y útil, conocido como método Amazon, plantea soluciones antes de enumerar requisitos, permitiendo recibir retroalimentación de usuarios para definir especificaciones más precisas.
¿Cuál es la importancia de los requisitos no funcionales?
Los requisitos no funcionales se relacionan directamente con los atributos de calidad del software, conformando el núcleo de la atención arquitectónica. Son imprescindibles para que un sistema pueda evolucionar adecuadamente con el tiempo.
Tipos de requisitos no funcionales:
¿Cómo se gestionan los riesgos y las restricciones en proyectos?
Identificar requisitos y analizar impactos lleva a estructurar tablas de riesgos, priorizando según severidad y frecuencia. Esto facilita decidir cuáles resolver previamente, cuáles aceptar posteriormente o cuáles requieren planes específicos de mitigación o control al materializarse.
Las restricciones aparecen como límites dinámicos al diseñar soluciones tecnológicas. Muchas surgen durante el propio proyecto, dependiendo de decisiones técnicas específicas:
Para consolidar esta información, un ejercicio práctico recomendado es listar riesgos conocidos y analizar restricciones existentes en el contexto specific del problema abordado. ¿Cuáles podrías identificar en tus proyectos actuales?
Alejandro Roa
Estudiante
Miguel Angel Reyes Moreno
Estudiante
Gustavo Laotshi Sánchez Estrada
Estudiante
Gabriel Obregón
Estudiante
Juan Camilo Santa Sánchez
Estudiante
Miguelangel Rojas
Estudiante
Andres Silva Vega
Estudiante
Javier Ramos
Estudiante
Devony Ramírez
Estudiante
José Cárdenas
Estudiante
John Eduard Meneses González
Estudiante
Humberto Cruz
Estudiante
Fernando Fernandez
Estudiante
wuainer Garcia
Estudiante
jefred bedoya
Estudiante
Platzi Team
Estudiante
Elias Estrabao
Estudiante
edgar ronaldo chico cordoba
Estudiante
Marcos Sarmiento Loarte
Estudiante
Cristian David Arroyo Noreña
Estudiante
Juan Carlos
Estudiante
Jair Israel Avilés Eusebio
Estudiante
Gustavo Bautista Hernández
EstudianteGustavo Laotshi Sánchez Estrada
Estudiante
JONATHAN SANCHEZ
Estudiante
MARIA TERESA PANIAGUA RIVERA
EstudianteMe queda resonando la idea de que los requisitos no funcionales son el verdadero corazón de una arquitectura de calidad. No se trata solo de que el sistema 'haga cosas', sino de 'cómo' las hace para asegurar su longevidad y evolución. Gracias por la clase!
Esto también me llamó la atención. Me pasa mucho que me concentro en el código y lo genial que es hacer cosas 'cool', pero al final del día ni al usuario ni al product manager le importa eso, lo importante es que el negocio prospere.
también se conocen como ilities, los atributos de calidad en un sistema. https://en.wikipedia.org/wiki/List_of_system_quality_attributes
🧠Calidad en Sistemas Informáticos
🎯 OBJETIVO
Asegurar que el sistema tenga calidad, robustez, integridad y adaptabilidad. 🔑 Claves:
⚙️ REQUISITOS FUNCIONALES
“Describen qué problemas resuelve el sistema y cómo se comporta.”
🔍 Enfocados en:
👤 Quién tiene la necesidad
🎯 Qué se espera como resultado
✅ Cómo verificar que se cumplen las condiciones mínimas ⚙️ Cuáles son los límites y fallos aceptables
🧩 Tipos:
💡 Método Amazon
📌 Propone imaginar soluciones antes de escribir requisitos.
🎧 Permite recibir feedback de usuarios y definir especificaciones más precisas.
🧱 REQUISITOS NO FUNCIONALES
“Definen los atributos de calidad y la capacidad del sistema para evolucionar.”
🌟 Atributos de calidad
🔒 Seguridad
🖱️ Usabilidad
🔧 Mantenibilidad
🚀 Extensibilidad ...y más.
💰 Costo
💡 Guía la toma de decisiones. 📊 Permite comparar alternativas según presupuesto y valor.
⚖️ Impacto
🔍 Evalúa consecuencias de las decisiones:
🧮 Se mide con una función que calcula el costo potencial de errores.
⚠️ GESTIÓN DE RIESGOS Y RESTRICCIONES
🧮 Gestión de riesgos
🚧 Restricciones técnicas
“Límites que aparecen durante el diseño del sistema.”
🗃️ Bases de datos relacionales:
✔️ Seguridad estructural
❌ Menor flexibilidad
📂 Bases de datos orientadas a documentos:
✔️ Mayor flexibilidad
❌ Menores capacidades analíticas (sin SQL)
Como haces estos resumenes? Te quedan geniales
"Cada decisión que tomes tiene un impacto."
Ley causa y efecto, muy bueno el curso!
O como decía Milton Friedman: "No hay almuerzos gratis". Toda decisión que tomes tiene un costo
No hay balas de plata
No hay almuerzos gratis
Hola para guiarse de los requisitos no funcionales les recomiendo mucho la iso 25010 especifica y nombra cada uno de los requisitos no funcionales para un software, espero que les sirva y sea de aporte
Acá un resumen de los atributos
Estos atributos son fundamentales al diseñar sistemas de software estructurados.
🧠 1. Frame with Strategic Intent
🧩 2. Use Structured Models
Leverage frameworks like Eisenhower, 5 WHYs, or decision matrices to show rigor and traceability.
⚖️ 3. Balance Risks and Constraints Transparently
Don’t hide limitations—frame them as managed risks or trade-offs
🎯 4. Justify with Data and Outcomes
Stakeholders love numbers. Use KPIs, benchmarks, or case studies to support your claims.
🗣️ 5. Simulate Objections and Preempt Them
Anticipate resistance and address it before it’s voiced. This shows leadership and strategic foresight.
📊 6. Use Executive-Friendly Visuals
Avoid dense text. Use:
🧭 7. Close with Strategic Alignment
End by tying the adaptation back to business value.
Para calcular la función de pérdida debido a un error en el sistema diseñado, primero identifica el impacto de errores potenciales en términos económicos o de calidad. La función de pérdida puede ser cuantificada evaluando costos asociados con la falla, como tiempo de inactividad, pérdida de clientes o gastos de reparación.
Utiliza métricas como el costo por error, la probabilidad de ocurrencia y el impacto en la satisfacción del cliente. Esto te ayudará a priorizar riesgos y realizar ajustes en el diseño del sistema para minimizar pérdidas futuras.
Con mi mente de Programador/Desarrollador pica codigo me ha costado ver este curso incluso cuando me habia estudiado estos temas en la Uni, pero ya ando agarrandole la onda pero ahora recordando con la experiencia, si me doy cuenta que es muy importante estas bases
¿Cuál es la mejor forma de mitigar riesgos?
La estrategia más efectiva es crear una matriz de priorización basada en dos ejes: probabilidad de ocurrencia y gravedad del impacto. Piensa en esto como un triaje médico en un hospital de urgencias. Primero, atacas los riesgos críticos y altamente probables (por ejemplo, una inyección SQL en tu login) resolviéndolos directamente desde el diseño de la arquitectura. Luego, para los riesgos graves pero poco probables (como que un centro de datos completo se incendie), creas un plan de mitigación, como tener respaldos automáticos en otra región geográfica. Finalmente, existen riesgos menores que simplemente debes aceptar y monitorear, porque el costo de prevenirlos es mayor que el costo del error mismo. La clave no es intentar construir un sistema invulnerable —eso es un mito extremadamente costoso— sino tener un sistema resiliente donde cada riesgo conocido tenga una etiqueta clara: prevenido, mitigado o aceptado.
Los Requisitos Funcionales definen el qué: las funciones y comportamientos específicos que el sistema debe ejecutar para satisfacer al usuario. Son la base operativa.
Los Requisitos No Funcionales definen el cómo: atributos de calidad como rendimiento, escalabilidad y seguridad. Determinan la viabilidad y robustez de la arquitectura. ¿Cuál de estos dos tipos crees que suele comprometer más la arquitectura cuando se ignora?
.MD Copialo y llevalo a cualquier apunte que tengas con MARKDOWN.
# 🏆 NFR & Atributos de Calidad: El ADN de un Sistema Robusto
Este módulo profundiza en cómo determinar si un sistema tiene la calidad adecuada mediante el análisis técnico de requisitos, la gestión de riesgos y la aceptación consciente de restricciones.
---
## 1. Requisitos Funcionales: El "Qué" y el "Para qué"
Definen las tareas específicas que el sistema debe ejecutar para resolver el problema del cliente.
* **Componentes clave:**
* **Actores:** Quién tiene la necesidad (Usuario, Sistema externo, Admin).
* **Resultados esperados:** Qué entrega el sistema tras el proceso.
* **Criterios de aceptación:** Condiciones mínimas para dar por válida la solución.
* **El Método Amazon (Working Backwards):** Antes de listar requisitos técnicos, se diseña el comunicado de prensa o manual de usuario. Esto asegura que el "Qué" esté alineado con el valor real para el usuario.
* **Clasificación:**
* **Visibles:** Funciones que el usuario opera directamente.
* **Background:** Procesos internos (ej. una IA procesando datos en la nube) que entregan un resultado final.
* **Control y Regulación:** Manejo de accesos y cumplimiento de leyes.
---
## 2. NFR: Requisitos No Funcionales (Atributos de Calidad)
Son el núcleo del trabajo del arquitecto. Definen **cómo** se comporta el sistema bajo presión y a través del tiempo.
* **Atributos Técnicos:** Seguridad, Usabilidad, Mantenibilidad, Extensibilidad y Resiliencia.
* **El Factor Costo:** No es solo el presupuesto inicial, sino cuánto cuesta mantener el sistema vivo (tokens de IA, gas en Web3, servidores).
* **Análisis de Impacto:** Cuantifica las consecuencias de una decisión o un fallo.
* **Económico:** Pérdida por caída de servicio.
* **Reputacional:** Pérdida de confianza del usuario.
* **Regulatorio:** Multas legales por fallos de seguridad.
---
## 3. Gestión de Riesgos: Severidad vs. Frecuencia
El arquitecto no elimina todos los riesgos, los **gestiona** mediante una matriz de prioridad.
| Nivel de Riesgo | Estrategia | Ejemplo |
| :--- | :--- | :--- |
| **Severidad Alta / Frecuencia Alta** | **Resolver Ya** | Caída constante del motor de pagos. |
| **Severidad Alta / Frecuencia Baja** | **Mitigar / Plan B** | Un hackeo masivo a los Smart Contracts (Web3). |
| **Severidad Baja / Frecuencia Alta** | **Mejorar / Aceptar** | El buscador de la app es un poco lento en horas pico. |
| **Severidad Baja / Frecuencia Baja** | **Monitorear** | Un error visual menor en navegadores antiguos. |
---
## 4. Restricciones: Los Límites del Diseño
Las restricciones son fronteras que aparecen al elegir una tecnología. No existe la "bala de plata"; cada elección tiene una limitación implícita.
### El Dilema de la Persistencia de Datos
* **Bases de Datos Relacionales (SQL):**
* **Ventaja:** Seguridad de esquemas, integridad total de datos (ideal para contabilidad).
* **Restricción:** Esquemas rígidos que dificultan cambios rápidos y escalabilidad masiva horizontal.
* **Bases de Datos Orientadas a Documentos (NoSQL):**
* **Ventaja:** Flexibilidad estructural (ideal para perfiles de usuario variables o datos de IA).
* **Restricción:** Capacidades analíticas limitadas y dificultad para mantener consistencia estricta en tiempo real.
---
> **💡 Conclusión del Arquitecto:** Diseñar es el arte de elegir qué problemas estás dispuesto a tener. Elegir una restricción hoy es una decisión estratégica para habilitar una funcionalidad mañana.
Para poder dise;ar software de calidad, debemos de conocer el problema que tenemos entre manos, para asi dise;ar soluciones de calidad, hay muchos sistemas que han crecido gracias al constante feedback que reciben de sus usuarios, los consideran y van implmenetando y al momento de cualquier implementacion estaremos tomando decisiones tecnicas que mas adelante nos afectaran de forma positiva o negativa.
La función de pérdida sirve para calcular el costo de los errores en un sistema. No solo considera valores económicos, sino también costos reputacionales o regulatorios.
resume la clase
Las restricciones son propias de cada solución, entonces hay que conocer las diversas opciones que se podrían aplicar para obtener la misma solución y así poder saber cual tiene menos restricciones que afecten negativamente el sistema que se esta desarrollando
Estimados, cordial saludo. Tengo una consulta: cuando se habla de los requisitos funcionales (lo que se espera del sistema), a que hace referencia cuando se habla de "límites generales en los que se puede solucionar?"
Yo lo entiendo como las restricciones en terminos como capacidad, costo para poder cumplir los criterios de aceptacion.
Cuando se mencionan los "límites generales en los que se puede solucionar" en relación con los requisitos funcionales, se refiere a las restricciones que definen el alcance del problema que el sistema debe resolver. Estos límites pueden incluir aspectos como:
Estos límites son fundamentales para guiar el diseño y desarrollo del sistema.
los requisitos no funcionales deberían de estar acompañados de estándares, lineamientos, políticas ya establecidas previamente en la organización
Siempre les enseño a mis estudiantes que tomar una decisión es como el sistema binario: no hay lugar para los puntos medios. O funciona o no funciona, es verdadero o es falso, es 1 o es 0. En este enfoque, el punto medio no existe, porque incluso en la duda, se elige un lado.
gracias
