B3T3 - ESTRATEGIAS DE DETERMINACIÓN DE REQUERIMIENTOS. LA ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE Flashcards
Requisitos Funcionales vs No-Funcionales
- Funcionales -> Lo que el sistema debe hacer
- No-Funcionales -> Restricciones
- De producto -> Comportamiento del sistema (accesibilidad, rendimiento, usabilidad)
- De organización -> Estandares de la organización
- Externos -> Normativas externas
Caracteristicas de los requisitos funcionales
IEEE 830-1998
- Correcto: debe representar algo requerido o solicitado.
- No ambiguo: tiene una sola interpretación.
- Completo: debe incluir todo lo que el software tiene que hacer.
- Consistente: no puede entrar en conflicto con otros requisitos.
- Clasificado: debe categorizarse según su importancia.
- Verificable: se ha de poder comprobar, mediante un proceso efectivo y de coste limitado, que el sistema cumple con el requisito.
- Modificable: la estructura y estilo del documento debe hacer fáciles los cambios del requisito.
- Trazable: debe conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseño y de la implementación.
Fases de la Ingeniería de Requisitos
- OBTENCIÓN -> Identificación y extracción de requisitos
- ÁNALISIS -> Confictos e incoherencias
- REPRESENTACIÓN -> Casos de uso -> Especificación de Requisitos Software
- VERIFICACIÓN, VALIDACIÓN Y NEGOCIACIÓN -> No defectos, cubrir necesidades y resolución de conflictos con el cliente
- GESTIÖN -> Petición de cambios (TestLink)
Otras aproximaciones: Clasica, Swebok
Que normativa sustituye a IEEE 830-1998
ISO 29148:2011
Identificación de requisitos según Métrica 3
- Técnicas de ALTO NIVEL:
- JAD (Joint Application Design).
- JRP (Joint Requeriments Planning).
- Prototipado.
- Factores críticos de éxito.
- Historias de usuario.
- Técnicas de BAJO NIVEL:
- Entrevistas.
- Reuniones.
- Brainstorming.
- PIECES.
- Casos de uso.
- Especificación de casos de uso.
Casos de uso
Según Metrica 3 es una técnica de ALTO nivel. Según la teoría es una técnica de BAJO nivel
- Para identificar los requisitos funcionales desde el punto de vista del usuario.
- Para guiar todo el desarrollo
- Modelo claro y preciso de comunicación. Caja negra para el cliente
- Resultado observable y valioso
- Elementos
- Actores -> Fuera del sistema pero interactuan (personas o máquinas)
- Caso uso -> Requisito, comportamiento. Pegado directamente al usuario
Notación de los casos de uso. Relaciones
Relaciones:
- Bidireccional -> Línea continua, entre actores y caso de uso
- Include (Usa) -> Línea discontinua flecha desde básico hacia común. OBLIGATORIO
- Extends (Extiende) -> Línea discontinua desde el adicional hacia el básico. OPCIONAL
- Precondiciones y Postcondiciones -> Condiciones que se dan antes y después del caso de uso
Pasos:
- Límite del sistema
- Actores
- Casos de uso
- Refinar (sólo teórico)
NOTA: En UML los actores y los casos de uso pueden tener herencia
Especificación de CU
Se especifica el caso de uso a bajo nivel. Descripción textual incluyendo la siguiente información
- Nombre del caso de uso.
- Identificador único.
- Actores involucrados.
- Descripción de alto nivel.
- Tipo: indica la importancia (principal, secundario, opcional) y el nivel de detalle (esencial: descripción abstracta, real: descripción con detalles tecnológicos).
- Referencias cruzadas con otros casos de uso relacionados.
- Curso normal de eventos.
- Curso alternativo de eventos: alternativas, excepciones y errores.
Historias de usuario
Se definen los requisitos a alto nivel (a diferencia con los Cu)
- En texto y usado por las metodologías ágiles.
- Frases simples
- Relación cercana al cliente
- Más precisas que los casos de uso
Se dividen en tres partes:
- CARD: título descriptivo de la funcionalidad a implementar.
- CONVERSATION: recoge los detalles.
- CONFIRMATION: recoge de forma transparente los criterios de aceptación para considera esa historia finalizada.
Características de las historias de usuario (INVEST):
- Independent: no dependen de otras historias.
- Negotiable: no es un contrato pudiendo cambiar a lo largo del tiempo.
- Valuable: aporta valor por sí misma al usuario.
- Estimable: estimación del esfuerzo para desarrollarla.
- Small: su tamaño debe ser pequeño.
- Testeable: debe contar con criterios de prueba que permitan comprobar que el comportamiento es el esperado.
COMO <rol> QUIERO <algo> PARA PODER <beneficio>
Casos de uso VS Historias de usuario
Sesiones de trabajo
- Técnicas (alto nivel)
- JAD (Joint Application Design)
- JRP (Joint Requirements Planning)
- Prácticas (bajo nivel)
- Entrevistas -> cara a cara. Acta
- Reuniones -> varias personas. Acta
- Brainstorming (bajo nivel)
JAD (Joint Application Design)
Reducir el tiempo de desarrollo, involucra a los usuarios desde la identificación de la necesidad, alternativas de solución y requisitos.
- Se elaboran los diagrmas durante la sesión. Al finalizar tendremos el conjunto de modelos que tendrán que ser aprobados por los participantes
- Perfiles
- Moderador -> dinámicas de grupo
- Promotor -> el que impulsa el proyecto y aprueba el gasto.
- Jefe de proyecto
- Especialista en modelización
- Analistas
- Desarrolladores
- Usuarios
Intervienen los Curritos
JRP (Joint Requirements Planning)
Potenciar la participación activa de la alta dirección
- Perfiles
- Moderador -> dinámicas de grupo
- Promotor -> el que impulsa el proyecto y aprueba el gasto.
- Director de proyecto -> subdirector
- Consultores
- Especialista en modelización
- Usuarios de alto nivel
Interviene la dirección
Prototipos
En general se nos habla de una representación de Alta fidelidad. Técnica de alto nivel para identificar los requisitos. En función de la fidelidad tenemos:
- Sketch -> Dibujo a mano alzada, ubicacion de elementos. Baja fidelidad
- WireFrame -> Esqueleto, mostrado lo esencial, qué hace. Baja fidelidad
- Mockup -> Apariencia y aspectos estáticos, estilo del sistema. Media fidelidad
- Prototipo -> Combinación de las dos anteriores, qué hace y el aspecto visual concreto. Alta fidelidad
En la AGE -> Guía de Comunicación Digital para la AGE
WireFrame. Herramientas
- Miro
- RWD Wireframes
- WireFrame.cc
- MockFlow (Cuidadin al nombre!!)
