Please enable JavaScript.
Coggle requires JavaScript to display documents.
Modelo Swebok 8 Técnicas análisis de requerimientos (Elicitación de…
Modelo Swebok
Elicitación de Requerimientos
Se ocupa de los orígenes de los requisitos de software y cómo el ingeniero de software puede obtenerlos.
Es la primera etapa en la construcción de una comprensión del problema.
Técnicas de Elicitación
Técnicas
Reuniones facilitadas
Intercambio y refinamiento de ideas.
Los requisitos surgen desde el principio permitiendo a las partes interesadas reconocer dónde ocurrió.
Puede dar como resultado una tecnología más rica y consistente.
Necesitan ser manejadas con cuidado.
El propósito de estas reuniones es lograr un efecto sumativo, por el cual un grupo de personas trae más información sobre sus requisitos de software que trabajando individualmente.
Observación
Etnografía
Para obtención de requisitos.
Los Ingenieros de software aprenden las tareas de los usuarios sumergiendoses en el entorno y observar cómo los usuarios realizan sus tareas interactuando con ellos.
Es cara e instructiva
porque Ilustran que muchas tareas de usuarios y procesos de negocios son demasiado sutiles y complejos para que sus actores puedan describirlos fácilmente.
Historias de Usuarios
Se usa comúnmente en métodos adaptativos
Descripciones breves de alto nivel
Contiene
Información suficiente
para producir estimaciones razonables de esfuerzo.
Tiene la forma
"Como un <rol>, quiero <objetivo/deseo> para que <beneficio>"
Objetivo
Evitar desperdicios que amenudo se producen en proyectos donde los requisitos se vuelven inválidos antes de que comience el trabajo. .
Antes de implementar
El cliente debe escribir un procedimiento de aceptación adecuado
para determinar si se han cumplido los objetivos de la historia de usuario.
Entrevistas
Medio tradicional de obtención de requisitos
Es importante comprender
Ventajas
Limitaaciones
Como debe llevarse a cabo
Otras Técnicas
Existe una gama de otras técnicas para respaldar la obtención de información de requisitos
Desde el análisis de los productos hasta la aplicación de técnicas de datos y uso de fuentes de conocimiento de dominio o bases de datos de solicitudes de clientes.
Escenarios
Medio valioso para proporcionar contexto a la obtención de los requisitos
Proporcionan una marco para las preguntas sobre las tareas del usuario
A partir de preguntas como
¿Qué pasaría si?
¿Cómo se hace esto?
El tipo mas común de escenario es el de casos de uso
Prototipos
Herramienta valiosa para aclarar requisitos ambiguos
Pueden actuar de manera similar al escenario
Al proporcionar un contexto donde se puede comprender de mejor manera la información que se necesita proporcionar
Amplia gama de técnicas para creación de prototipos
Maquetas de Papel
Versiones de Prueba Beta
Los prototipos de baja fidelidad
Se prefieren hasta evitar el anclaje de las partes interesadas
Características secundarias menores
Limitar la flexibilidad del diseño de manera no intencionada
Concepto
Identificar fuentes de requisitos
Formular requisitos
Se necesita
Técnicas.
Qué buscan que las partes interesadas humanas articulen información relevante.
1 more item...
Pueden sucitarse problemas como:
Información Incompleta.
Información sin declaras.
No estar dispuestos a cooperar.
Dificultad de usuarios a describir información
Trabajo arduo para obtener información correcta.
Obtener información
Fuente de requisitos
Los requerimientos tienen varias fuentes en un software típico o común. Y es esencial que todas las potenciales fuentes sean identificadas y evaluadas.
Este tema está diseñado para promover la conciencia de las diversas fuentes de software y de los marcos para poder gestionarlos
Los principales puntos cubiertos son:
Objetivos
Conocimiento del Dominio
Partes Interesadas(Stakeholders)
Reglas de Negocio
Entorno Operacional
Entorno Organizacional
Reglas de negocio: Estas son declaraciones que definen o restringen algún aspecto de la estructura o comportamiento del negocio.
Entorno Operacional: Los requerimientos se derivarán del medio ambiente en el que se ejecutará el software.
Entorno Organizacional: A menudo se requiere apoyar un proceso de negocio, la selección de las cuales puede estar condicionada por la estructura, cultura o la política de la organización
Stakeholders: Mucho software ha resultado insatisfactorio, porque ha subrayado los requisitos de un grupo de partes interesadas a expensas de otros.
Conocimiento del Dominio: El ingeniero de software necesita adquirir o tener conocimiento disponible sobre el dominio de aplicación.
Objetivos: Proveen la motivación para el software, pero a menudo son vagamente formulados
Es una actividad fundamental del ser humano y es donde
las partes interesadas están identificadas, tienen una relación establecida entre el equipo de desarrollo y el cliente.
Uno de los principios fundamentales de un buen proceso de elicitación es que la comunicación es efectiva entre varias partes interesadas.
Esta comunicación se da a lo largo de todo el ciclo de vida de desarrollo del software.
Análisis de Requerimiento
Detecta y resuelve conflictos entre requerimientos.
Descubre los limites del software y cómo debe interactuar con su entorno organizativo y operativo.
Elaborar los requisitos del sistema para derivar los requisitos del software.
Análisis Formal
Suele ser contraproducente aplicar la formalización hasta que los objetivos comerciales y los requisitos del usuario se hayan enfocado claramente.
Se enfoca en etapas tardías del análisis de requerimientos.
Requiere un soporte de herramientas que sean factibles para sistemas no triviales.
Verificadores de modelos
Probadores de teoremas
Beneficios:
Se pueden razonar los requisitos.
Permite que los requisitos se especifiquen de forma precisa y sin ambigüedades, evitando la posibilidad de una mala interpretación.
Requiere un lenguaje con semántica definida formalmente.
Modelo Conceptual
Modelos
Modelos de datos y muchos otros
Modelos de objetos
Diagramas de casos de uso
Modelo de flujo de datos
Modelos de entidades del problema
Relaciones y dependencias
Su propósito es ayudar a entender la situación en la que se produce el problema, así como representando una solución.
Los requisitos de proceso del cliente.
Analizados de manera particularmente rigurosa
La experiencia del ingeniero de software.
Los clientes pueden imponer su notación o método favorecido o prohibir cualquiera con el que no estén familiarizados
La naturaleza del problema.
Método con el que el ingeniero de software tenga experiencia
Diseño arquitectónico y Asignación de requisitos
La asignación permite un análisis detallado de los requisitos
Identifiquen los componentes de arquitectura
Responsables de satisfacer los requisitos
Estructura y arquitectura del software en el diseño de software KA
Debe ser derivada
Clasificación de Requerimientos
Volatilidad / Estabilidad
Alcance del requisito.
Estrecho
Global
La prioridad del requisito.
Opcional.
Deseable.
Altamente deseable.
Obligatorio.
Si el requisito esta en el producto o en el proceso.
Si el requisito se deriva de uno o mas requisitos de alto nivel o una propiedad emergente.
Si el requisito es funcional o no funcional.
Negociación de requerimientos
El Ing. de Software
Realizan priorizaciones de requisitos sin necesidad de conocerlos
Que pueden seguir un enfoque de valor de costo
En donde se definen los beneficios o el valor agregado que trae la implementación del requisito
No debe
Tomar una decisión unilateral
Debe
Consultar a las partes interesadas para llegar a una decisión consensa que requieren
Buenas habilidades de estimacion
De un conocimiento detallado del dominio
Reunir a las partes interasadas
Resolución de Conflictos
Resolver problemas con los requisitos
Requieren mutuamente características incompatibles entre
Funcional y no funcional
Requisitos y recursos
Entre dos actores
Los solicitantes son distintos
Se llega a esta etapa cuando hay incompatibilidad en dos o mas requisitos
