Please enable JavaScript.
Coggle requires JavaScript to display documents.
COMPRENSIÓN DE LOS REQUERIMIENTOS - Coggle Diagram
COMPRENSIÓN DE LOS REQUERIMIENTOS
INGENIERÍA DE REQUERIMIENTOS
¿Para que sirve?
Entender específicamente que se desea desarrollar
Estructurar los requerimientos iniciales y pulirlos, modificarlos, eliminarlos, agregarlos
Pasos:
Concepción
Las personas que quieren una solucion
La naturaleza de la solución
Indagacion
Saber más sobre el sistema a desarrollarse y como realmente beneficia al negocio
Problemas de::
Alcance: Los limites del sistema no están claros y los clientes sueltan informacion innecesaria y que confunde
Entendimiento: Los usuarios desconocen la capacidad de sus propios instrumentos de trabajo, omiten información, no saben lo que realmente quieren
Volatidad:Los requerimientos cambian con el tiempo
Elaboracion
Se expande y refinan los requerimientos
Como interactuan los usuarios finales con el sistema
Abstracción de atributos esenciales para el funcionamiento del sistema
Negociación
Los clientes piden mas de lo que puede lograrse
conflictos entre requerimientos
Los requerimientos se combinan, modifican y eliminan
Especificación
Es la formalizacion de los requerimientos
Para sistemas pequeños usar escenarios de uso es suficiente
Para sistemas grandes usar documentos escritos con lenguaje natural con modelos gráficos es recomendable
Validación
Validan los clientes, usuarios e ingenieros de software
Se detectan y corrigen las inconsistencias
Se eliminan ambigüedades y errores de interpretación
Administración de Requerimientos
Identifica, controla y da seguimiento a los requerimientos
Los requerimientos siempre quedran ser modificados a lo largo del desarrollo
ESTABLECER LAS BASES
Identificación de los participantes
Cualquier persona que se beneficie de manera directa o indirecta del sistema en desarrollo
Cada participante tiene su punto de vista diferente del sistema
Reconocer los múltiples puntos de vista
Cada area del negocio tendra sus diferentes requerimientos Y al principio todos los requerimientos deben ser escuchados
Las personas que toman las decisiones son las que deciden que requerimientos se quedan y que requerimientos se irán
Trabajar hacia la colaboración
Al haber tantos requerimientos se deben hallar las areas de interés comun
Los participantes únicamente aportan su punto de vista con los requerimientos
Al final es sólo una persona quien decide que requerimientos se quedan
Hacer las primeras preguntas
Se centran en el cliente y en otros participantes en las metas y beneficios generales
Permiten entender mejor el problema y hacen que el cliente exprese sus percepciones respecto de la solución
“romper el hielo” para una indagación exitosa
INDAGACIÓN DE LOS REQUERIMIENTOS
Recabación de los requerimientos en forma colaborativa
Tanto ingenieros de software como otros participantes dirigen o intervienen en las reuniones.
Se establecen reglas para la preparación y participación
Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas.
Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión.
Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas, etiquetas adhesivas, pizarrón electrónico, grupos de conversación o foro virtual).
Despliegue de la función de calidad
Requerimientos normales. Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente.
Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los mencione de manera explícita.
Requerimientos emocionantes. Estas características van más allá de las expectativas del cliente.
Escenarios de uso
Identifican la naturaleza de los usos para el sistema que se va a construir (casos de uso)
Indagación de los productos del trabajo
Un enunciado de la necesidad y su factibilidad
Un enunciado acotado del alcance del sistema o producto
Una lista de clientes, usuarios y otros participantes que intervienen en la indagación de los requerimientos
Una descripción del ambiente técnico del sistema
Una lista de requerimientos (de preferencia organizados por función) y las restricciones del dominio que se aplican a cada uno
Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o producto en diferentes condiciones de operación
Cualesquiera prototipos desarrollados para definir requerimientos
DESARROLLO DE CASOS DE USO
Actor
es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste
preguntas:
¿Quién es el actor principal y quién(es) el(los) secundario(s)?
¿Cuáles son los objetivos de los actores?
¿Qué precondiciones deben existir antes de comenzar la historia?
¿Qué tareas o funciones principales son realizadas por el actor?
¿Qué excepciones deben considerarse al describir la historia?
¿Cuáles variaciones son posibles en la interacción del actor?
¿Qué información del sistema adquiere, produce o cambia el actor?
¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
¿Qué información desea obtener el actor del sistema?
¿Quiere el actor ser informado sobre cambios inesperados?
Definiciones
un caso de uso capta un contrato que describe el comportamiento del sistema en distintas condiciones en las que el sistema responde a una petición de alguno de sus participantes
En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final con el sistema en circunstancias específicas
Elementos
Precondiciones:
Disparador:
Objetivo en contexto:
Escenario:
Actor principal:
Excepciones:
Caso de uso:
Prioridad:
Cuándo estará disponible:
Frecuencia de uso:
Canal para el actor:
Actores secundarios:
Canales para los actores secundarios:
Aspectos pendientes:
ELABORACIÓN DEL MODELO DE LOS REQUERIMIENTOS
Elementos del modelo de requerimientos
Elementos basados en el escenario: El sistema se describe desde el punto de vista del usuario con el empleo de un enfoque basado en el escenario
Elementos de comportamiento: utiliza el diagrama de estado es un método de representación del comportamiento de un sistema que ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado.
Un estado es cualquier modo de comportamiento observable desde el exterior
Elementos orientados al flujo.: La información se transforma cuando fluye a través de un sistema basado en computadora. El sistema acepta entradas en varias formas, aplica funciones para transformarla y produce salidas en distintos modos.
Patrones de análisis
Ciertos problemas son recurrentes, estos patrones de análisis sugieren soluciones dentro del dominio de la aplicación que pueden volverse a utilizar cuando se modelen muchas aplicaciones.
REQUERIMIENTOS DE LAS NEGOCIACIONES
Actividades
Identificación de los participantes clave del sistema o subsistema.
Determinación de las “condiciones para ganar” de los participantes.
Negociación de las condiciones para ganar de los participantes a fin de reconciliarlas en un conjunto de condiciones ganar-ganar para todos los que intervienen (incluso el equipo de software).
Objetivo
Desarrollar un plan del proyecto que satisfaga las necesidades del participante y que al mismo tiempo refleje las restricciones del mundo real
VALIDACIÓN DE LOS REQUERIMIENTOS
Preguntas para cada requerimientos
¿Es coherente cada requerimiento con los objetivos generales del sistema o producto?
¿Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es decir, ¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en esta etapa?
El requerimiento, ¿es realmente necesario o representa una característica agregada que tal vez no sea esencial para el objetivo del sistema?
¿Cada requerimiento está acotado y no es ambiguo?
¿Tiene atribución cada requerimiento? Es decir, ¿hay una fuente (por lo general una individual y específica) clara para cada requerimiento?
¿Hay requerimientos en conflicto con otros?
¿Cada requerimiento es asequible en el ambiente técnico que albergará el sistema o producto?
Una vez implementado cada requerimiento, ¿puede someterse a prueba?
El modelo de requerimientos, ¿refleja de manera apropiada la información, la función y el comportamiento del sistema que se va a construir?
¿Se ha “particionado” el modelo de requerimientos en forma que exponga información cada vez más detallada sobre el sistema?
¿Se ha usado el patrón de requerimientos para simplificar el modelo de éstos? ¿Se han validado todos los patrones de manera apropiada? ¿Son consistentes todos los patrones con los requerimientos del cliente?