Seminario 1. Stakeholders
¿Qué es un stakeholder?
- Son las personas interesadas o implicadas en el proyecto y en la especificación de requisitos
Tipos de stakeholders
- Internos
- Empresas cliente, equipo de desarrollo…
- Externos
- Clientes finales, inversores, competidores…
Importancia de identificación de los stakeholders
- Distintos stakeholders proporcionan puntos de vista diferentes
- No identificarlos correctamente podría provocar insatisfacción
- Errores al identificar requisitos resultarán errores en las fases posteriores del proyecto
Ejercicio 1. Identificar stakeholders
- S1: personal médico
- S2: usuarios registrados (pacientes)
- S3: personal de administración
- S4: personal de la centralita
- S5: usuario administrador del sistema IRMed
- S6: todos los centros de salud de Asturias
- S7: usuarios no registrados
- S8: cliente (Conserjería de Salud)
- S9: equipo de traducción
- S10: equipo de marketing
- S11: equipo de desarrollo
- S12: proveedor de certificados
- S13: proveedor de nombre de dominio
Ejercicio 2. identificar funcionalidades relacionadas con stakeholders previos
Funcionalidad | S1 | S2 | S3 | S4 | S5… |
---|---|---|---|---|---|
Traducción a español e inglés | X | ||||
Todo usuario con tarjeta sanitaria puede registrarse en la aplicación | |||||
Todo usuario registrado podrá realizar reservas que se verán en el calendario de reservas | |||||
Los usuarios no registrados no podrán realizar reservas | |||||
Todo usuario (registrado y no registrado) podrá ver el calendario de reservas | |||||
El personal médico del centro podrá ver el calendario de reservas, pero no podrá hacer modificaciones | |||||
La aplicación tendrá un único usuario administrador | |||||
El administrador puede añadir roles a los administrativos del centro de salud | |||||
El administrador puede dar permisos a los administrativos del centro de salud en caso de nuevas incorporaciones | |||||
Gestión de cuentas de usuario |
Seminario 2. Requisitos no funcionales
¿Qué son los requisitos no funcionales?
- Son restricciones a las funcionalidades que ofrece el sistema
- Detallan cómo debe funcionar el sistema en vez de sus funcionalidades (requisitos funcionales)
¿Por qué son importantes?
- Ignorarlo ahora supone tener que arreglarlo en la fase de implementación
Clasificación según Someville
Requisitos de producto
- Especifican cómo debe comportarse el software
- De usabilidad
- De eficiencia
- De dependencia (disponibilidad, mantenibilidad, fiabilidad, integridad)
- De seguridad
Ejercicio. Clasificar requisitos de producto
Requisitos organizacionales
- Estos requisitos derivan de políticas de la empresa cliente y de la empresa desarrolladora
- De entorno
- Operacionales
- De desarrollo
Requisitos externos
- Requisitos derivados de factores externos al sistema, por ejemplo, requisitos necesarios para que el sistema sea aprobado por un organismo regulador
- Regulatorios
- Éticos
- Legislativos
Ejercicio. Organizacionales vs Externos
Atributos de calidad
- Disponibilidad
- Fiabilidad
- Extensibilidad
- Escalabilidad
- Mantenibilidad
- Seguridad
- Usabilidad
Ejercicio 1. Identificar requisitos no funcionales
- RNF1: Un mensaje entre un usuario emisor y otro receptor ha de llegar del usuario emisor al receptor en menos de 2 segundos
- RNF2: Un usuario ha de poder autenticarse mediante contraseña
- RNF3: El sistema debe permitir autenticación de tipo MFA
- RNF4: El sistema debe almacenar los datos encriptados en una mongodb
- RNF5: El sistema debe permitir al usuario recuperar sus datos mediante un código previamente otorgado en la creación de su cuenta
- RNF6: El sistema debe cumplir los estándares de usabilidad para personas con discapacidad visual del W3C
Seminario 3. Casos de uso
¿Qué es un caso de uso?
- Un caso de uso es la descripción de una funcionalidad del sistema y cómo interactúa dicho sistema con actores externos o actores
¿Qué es un escenario?
- Cada secuencia de interacciones posible de un caso de uso es un escenario
- Por tanto, un caso de uso contiene todos los escenarios posibles para que el actor primario consiga su objetivo
¿Qué es un actor?
- Es una persona, grupo de personas o incluso otro sistema
- Cada caso de uso está asociado con el objetivo de un actor, que es el actor primario
Stakeholders vs actores
- Todos los actores son stakeholders, pero no todos los stakeholders son actores (no todos interactúan con el sistema)
¿Cómo escribir un diagrama de caso de uso?
Elementos de un diagrama de caso de uso
Relación entre actor y caso de uso
Relaciones entre actores
¿Cuál es la diferencia entre estos diagramas?
- En el primero, los dos actores participan en el caso de uso a la vez
- En el segundo, lo hacen de forma individual
Relaciones entre casos de uso
Includes
Extends
Generalización
Ejercicio 1. Escribir un caso de uso
Ejercicio 2. Diagrama de casos de uso
Seminario 4. Diagramas de estado
¿Qué es un diagrama de estado?
- Es un diagrama donde se representan los posibles estados de un sistema u objeto
¿Qué es un estado?
- Describe el estado en el que se encuentra un objeto en un momento concreto de su ciclo de vida
Transición
Externa
- Representa la transición entre dos estados. En la imagen, es una transición externa
- Evento (e): evento que dispara el cambio de estado
- Condición (c): condición booleana que permite el cambio de estado
- Actividades (A): actividades que se ejecutan durante un cambio de estado
Interna
- Se maneja la aparición de un evento dentro de un estado
- Como el evento nunca sale de dicho estado, las actividades en entrada y salida no se ejecutan
Auto-transición
- Transición en la que el estado fuente y el objetivo son el mismo
Equivalencias
Explicar el orden de ejecución
Pseudoestados
¿Es correcto este diagrama?
Hacer el diagrama de estado
Estudiante en una asignatura
Asientos de cine
Seminario 5. Verificación de requisitos
Verificación y validación
- Validación: comprobar si los requisitos cumplen las necesidades de los stakeholders
- Verificación: comprobar si los requisitos cumplen con los criterios de calidad