Diseño y Arquitectura de
Software
Sesión 03: Requerimientos de software.
Inicio
Observa el siguiente video y responde:
¿Qué es la Ingeniería de Requisitos?
https://www.youtube.com/watch?v=umpRjaFX_XM
Logro de la sesión
Al finalizar la sesión, el estudiante analiza los
requerimientos de software para estructurar el
"Documento de especificación de requerimientos
de software".
Utilidad
¿Por qué son importantes los requisitos en arquitectura de software?
Agenda
Requerimientos de Software.
Documento Especificación de requerimientos de software (SRS).
Recordando
Explique el
ciclo de
desarrollo de
la arquitectura
de software
Actividades del ciclo de desarrollo de la arquitectura de
Actividades en desarrollo de sistemas de software
software
Saberes previos
¿En el contexto de la Ingeniería de Requerimientos, quiénes participan
en la recolección y documentación de los requerimientos?
Transformación
Requerimientos de Software
Requerimiento es una especificación que describe
alguna funcionalidad, atributo o factor de calidad de
un sistema de software.
Puede describir también algún aspecto que restringe
la forma en que se construye ese sistema.
Tipos de requerimientos
a) Requerimientos de negocio,
describen metas de una
organización.
b) Requerimientos de usuario
como casos de uso o historias de
usuario. Describen los servicios
que los usuarios pueden llevar a
cabo por medio del sistema
c) Requerimientos funcionales
detallados, como alguna
especificación particular en el nivel
de la interfaz de usuario.
Tipos de requerimientos
Drivers arquitectónicos
Los drivers son todos aquellos requerimientos que tienen mayor influencia sobre la forma que
tomarán los elementos de la estructura de la arquitectura.
La etapa de requerimientos se centra en la identificación, documentación y priorización de drivers.
Hay 3 tipos:
1. Drivers funcionales.
Describen detalles finos de diseño y/o implementación relacionados a los requerimientos de
usuario. (ejemplo: seleccionar destino de un combo box)
2. Drivers de atributos de calidad.
Establecen criterios sobre la calidad del sistema.
3. Drivers de restricciones.
Aspectos que limitan el proceso de desarrollo del sistema. Restricciones técnicas (tipo de
lenguaje, motor de BD, etc). Restricciones administrativas (plazos, costos, etc)
De todos los drivers, los de atributos de calidad y las restricciones son los que tienen mayor
influencia sobre el diseño de la arquitectura de software.
Atributos de calidad
Son las características útiles para
establecer criterios sobre la calidad del
sistema.
No existe un “listado único” de atributos de
calidad relevantes para diseñar la
arquitectura de software.
Los arquitectos de software utilizan
estándares como el ISO/IEC 9126 o
modelos de calidad (McCall’s, Boehm)
para identificar y especificar este tipo de
drivers arquitectónicos.
Atributos de calidad
Atributos de calidad según el estándar ISO/IEC. 9126.
Documento de Requerimientos de usuario (DRU)
En ingeniería de requerimientos, el DRU es un
documento que describe, en términos no
técnicos, las necesidades y expectativas
del usuario sobre el sistema. Se centra en
qué quiere el usuario sin detallar cómo se Ejemplo:
implementará. Para un sistema de venta de boletos en línea, un
Esta información se especifica a través de requerimiento de usuario sería:
casos de uso e historias de usuario.
Lenguaje claro y sencillo. "El usuario debe poder seleccionar el origen, el
Describe lo que el usuario espera del sistema. destino y la fecha de viaje para comprar su
boleto en línea."
Define objetivos y restricciones generales.
No entra en detalles técnicos
Documento de Requerimientos de usuario (DRU)
Casos de Uso
Los casos de uso, describen cómo un Ejemplo. Sistema de venta de boletos en línea.
usuario interactúa con el sistema para
lograr un objetivo específico. Caso de Uso : Comprar boleto de viaje
Incluyen una descripción textual que Actor : Usuario del sistema
detalla la secuencia de interacciones Flujo principal :
entre el sistema y los actores. - El usuario ingresa al sistema.
- Selecciona ciudad de origen y destino.
En la descripción textual se incluye el
- Selecciona la fecha de viaje.
nombre del caso de uso, actores
involucrados, objetivos de negocio - El sistema muestra las opciones de boletos
relacionados, precondiciones, disponibles.
poscondiciones, y flujos alternativos. - El usuario elige un boleto y lo añade al carrito.
- Realiza el pago.
Se suelen representar con diagramas - El sistema genera un boleto digital.
UML, en forma de elipse.
Documento de Requerimientos de usuario (DRU)
Historias de usuario
Son una técnica ágil que describe los
requerimientos desde la perspectiva del
usuario final, en un formato simple y corto.
Ejemplo. Sistema de venta de boletos en línea.
Formato:
"Como [rol], quiero [acción] para [beneficio]. "Como usuario, quiero seleccionar el origen y
destino de mi viaje para comprar un boleto
fácilmente.“
Lenguaje sencillo y orientado al usuario.
"Como usuario, quiero ver una lista de opciones de
Enfocado en el valor que aporta al usuario.
boletos disponibles para elegir el que más me
Útil para metodologías ágiles como Scrum convenga."
Documento de Especificación de Requerimientos
del Software (SRS)
El SRS es un documento técnico detallado que
traduce los requerimientos del usuario en
especificaciones formales para el equipo de
desarrollo. Ejemplo. Sistema de venta de boletos en línea.
Características: Un requerimiento en el SRS sería:
- Especificaciones detalladas del sistema.
"El sistema debe permitir al usuario seleccionar
- Uso de lenguaje técnico y formal. una ciudad de origen y una ciudad de destino
- Incluye diagramas y modelos de datos. desde un menú desplegable. Al elegir la fecha del
viaje, el sistema mostrará las opciones disponibles
- Define funcionalidades, restricciones y en una tabla con horarios y precios."
requisitos de hardware/software.
El DRU es la base inicial centrada en el usuario, mientras que el SRS es el documento técnico detallado
para desarrolladores que guía la implementación del software.
Métodos para identificar drivers arquitectónicos
A continuación presentamos 3 métodos para realizar tareas de identificación, especificación y
priorización de drivers arquitectónicos.
Método Objetivo Aplicación Cuándo usarlo
Se realiza un taller con
Identificar y priorizar
QAW (Taller de Atributos de stakeholders para definir y Proyectos grandes donde la
atributos de calidad con
Calidad) priorizar atributos de calidad calidad es un factor crítico.
los stakeholders.
mediante escenarios y votación.
Se establecen patrones
Definir y validar arquitectónicos, se estructuran Sistemas grandes y críticos
ACDM (Diseño Centrado en
arquitecturas de módulos y se evalúan los donde la arquitectura es
la Arquitectura)
software desde el inicio. impactos en la calidad del clave.
sistema.
FURPS+ (Modelo de
Se categorizan los requisitos en
Clasificación de
Organizar requisitos en funcionalidad, usabilidad, Proyectos que requieren un
Requerimientos)
funcionales y no confiabilidad, rendimiento, análisis detallado de
Funcionalidad+ Usabilidad, + funcionales. soporte y restricciones requisitos.
Fiabilidad + Rendimiento + adicionales.
Soportabilidad
Práctica
Trabajo individual Tiempo : 35 min
En base al ejemplo mostrado en la Guía práctica:
• Elabore la documentación sobre las actividades relacionadas a la
“Ingeniería de Requerimientos de la Arquitectura”.
Compartir las resoluciones obtenidas.
Explicar el proceso y las dificultades que ha tenido durante el desarrollo.
Finalmente, recibirán feedback de sus compañeros y el docente.
Espacio de
Preguntas
¡Comparte tus dudas de la sesión o de los
ejercicios y problemas que acaban de
trabajar!
20
Cierre
Conclusiones:
¿Qué es un requerimiento de
Software?
Mencione algunos atributos de
calidad de software.
¿Qué es el Documento de
Especificación de
Requerimientos del Software
(SRS) ?
FINALMENTE
PARA TI
Recuerda que Recuerda que, tienes un
¡Excelente esta sesión quedará foro para consultas en la
participación! grabada para tus plataforma virtual de
consultas. aprendizaje. Además, te
recomiendo seguir
👍👍 practicando.
Datos/Observaciones 22
