Please enable JavaScript.
Coggle requires JavaScript to display documents.
Capitulo 1: Requisitos de Software :star: (Requisitos de Elicitación …
Capitulo 1: Requisitos de Software :star:
Requisitos de Elicitación :check:
Especialistas en requisitos :silhouette:
Media el dominio de
Usuarios del software
Mundo técnico del ingeniero de software
Comunicación efectiva :silhouettes:
Entre las partes interesadas
Elemento crítico :warning:
Informar el alcance del proyecto
Descripción del software
Técnicas de elicitación :red_flag:
Obtención de la información mediante:
Prototipos
Esta técnica es una herramienta valiosa para aclarar requisitos ambiguos.
Pueden actuar de manera similar a los escenarios al proporcionar a los usuarios un contexto
Reuniones facilitadas
Cuando funciona bien, esta técnica puede resultar en un conjunto de requisitos más rico y más consistente
Pueden generar ideas y refinar ideas que pueden ser difíciles de sacar a la superficie mediante entrevistas.
Otra ventaja es que los requisitos en conflicto surgen desde el principio de una manera que permite a los interesados reconocer dónde ocurren.
Escenario
Permite hacer un marco de preguntas que se formulan de la siguiente manera "qué pasaría si" y "cómo se hace esto".
Observación
Los ingenieros de software aprenden sobre las tareas de los usuarios al sumergirse en el entorno y observar sus actividades.
Estas técnicas son relativamente caras.
Son instructivas porque ilustran que muchas tareas de usuario y procesos de negocios son demasiado sutiles y complejos para que sus actores los describan fácilmente.
Entrevista
Entrevistar a los medio interesados es una técnica tradicional
Es importante entender las ventajas y limitaciones de la misma
Historias de Usuario
Se refiere a descripciones breves y de alto nivel de la funcionalidad requerida expresada en términos del cliente.
Tiene la intención de contener la información suficiente para que los desarrolladores puedan producir una estimación razonable del esfuerzo para implementarlo.
El cliente debe escribir un procedimiento de aceptación adecuado para determinar si se han cumplido los objetivos de la historia de usuario
Otras Técnicas
Existe una gama de otras técnicas para respaldar la obtención de información.
Análisis de los productos de la competencia.
Técnicas de extracción de datos.
Uso de fuentes de conocimiento de dominio o bases de datos de solicitudes de clientes.
Fuentes de requerimientos :black_flag:
como
Entorno Organizativo
Software puede estar condicionado por la estructura, la cultura y las políticas internas de la organización.
Entorno Operacional
Se derivarán del entorno
Ejemplo
Restricciones de tiempo en software en tiempo real
Reglas del negocio
Declaraciones que definen o restringen algún aspecto de la estructura o el comportamiento del negocio
Partes Interesadas
Identificar, representar y gestionar
Los "puntos de vista" de las partes interesadas.
Conocimiento del dominio
Conocimiento disponible sobre el dominio de la aplicación.
Metas
Evaluación del valor y el costo de los objetivos
Estudio de viabilidad
Análisis de Requerimientos :pencil2:
Clasificación de Requisitos :silhouette:
Pueden ser clasificados en varias dimensiones
Requisito es funcional o no funcional
Requisito derivado de uno o más requisitos de alto nivel
Si el requisito es en el producto o el proceso
La prioridad requisito.
Cuanto mayor sea la prioridad, más esencial es el requisito para cumplir con los objetivos generales del software.
El alcance de la prescripción.
Volatilidad / estabilidad.
Algunos de los requisitos cambiarán durante el ciclo de vida de la Cesión de Software.
Modelo Conceptual :explode:
Comprender la situación en la que se produce el problema
Comprenden modelos de entidades del dominio del problema
Existen varios tipos de modelos
como
Casos de Uso
Flujo de datos
De estado
Basado en Objetos
Interacciones del usuario
Factores que influyen en la notación
La naturaleza del problema.
La experiencia del ingeniero de software.
Los requisitos del proceso del cliente.
Diseño arquitectónico y asignación de requisitos :pencil2:
Punto en el que el proceso se superpone con los requisitos de software
Sistemas de diseño e ilustra lo imposible que es disociar limpiamente las dos tareas.
Tareas
Asignación
Grandes proyectos
Análisis de subsistemas
Diseño
Modelado
Arquitectonico
Relacionado
Estructura del software
Arquitectura del software
Diseño responsable
Satisfacer requisitos
Negociación de requisitos :checkered_flag:
Analisis
Da como resultado
Problemas con Requisitos
Casos para validar requisitos
Filtra Requisitos
Resolución entre las dos partes
Conflictos
Planifica entregas
Tomar decisiones Complejas
Requiere Conocimiento
Detallado
Escuchar razones del cliente
Análisis de requisitos de software
Involucrados en el análisis
Análisis formal :fountain_pen:
Impacta en sistemas de alta integridad :checkered_flag:
Analisables
Predecibles
Se centra en etapas relativamente tardías de análisis de requisitos.
Razona los requisitos
Obtiene propiedades
Deseadas
Especificas
Requisitos precisos y sin ambigüedad
Evita malas interpretaciones
