Tabla de contenidos 1. Conceptos a) Concepto. b) Características, c) Tipos de requerimientos. 1. Proceso de Determinación de requerimientos. a) Concepto. b) Fases. c) Características. 2. Metodología para la Determinación de requerimientos. 1. Conceptos. Requisito/Requerimiento. Condición, Característica o Restricción que debe tener o cumplir un sistema o componente de un sistema para satisfacer un contrato, norma, especificación u otro documento formalmente impuesto. Ingeniería de Requerimientos. Disciplina de la ISW que se encarga de definir los requerimientos del sistema. Fases: 1. Determinación de requerimientos. 2. Análisis de requerimientos. 1. Conceptos -- Características. Características que han de reunir los requisitos para ser de alta calidad. Correctos, sin errores. Consistentes. No ambiguos. Son completos: 1. Externamente completa si contiene todas las propiedades deseadas por el cliente. 2. Internamente completa si no existen referencias no definidas. 1. Conceptos. Características. Son realistas. Puede el sistema hacer lo que el cliente desea. Los R. Describen algo necesario para el cliente. Verificables. Un requisito es verificable si existe algún proceso finito de coste razonable que pueda probar que el producto software cumple con el requisito. Son rastreables. Trazables, el origen de cada requisito está claro y se posibilita la referencia de cada uno de estos requisitos en desarrollos futuros o incrementos de la documentación. 1. Conceptos. Tipos de Requerimientos. 1. R. Funcionales. Una función es algo que hará el sistema. Describen una interacción entre el sistema y su ambiente. 2. R. No funcionales. Describen restricciones que limitan las opciones de solucionar el problema. Restricciones cuantitativas o precisión. 3. Seudorequerimientos. Requerimientos impuestos por el cliente que restringen la implementación del sistema. Especificación Sistema 1. Conceptos. Determinación Requerimientos Obtención Documentación Cliente/Usuario Desarrolladores Validación 2. Determinación de Requerimientos. Concepto y Fases. Proceso que tiene como objetivo capturar, documentar y condiciones o características que debe cumplir un sistema dado: La especificación del sistema. 1. Obtención de requerimientos. Captura de requerimientos con el objetivo de definir que es el sistema. 2. Documentación de requerimientos. Los requisitos han de reflejarse en un documento como registro del proceso de captura con el objetivo de fijar una base para clientes y desarrolladores. 3. Validación. Es el proceso por el cual se determina si la especificación es consistente es decir si los requerimientos satisfarán las necesidades del cliente. 2. Participantes en el proceso. Supervisores del contrato, sugieren hitos de control y cronogramas que disciplinan el desarrollo del sistema. Clientes y usuarios, deben comprender y trasmitir adecuadamente los requerimientos, para el sistema. Los gerentes de negocios, para calibrar el impacto de construir y utilizar el sistema. Los diseñadores que usarán los requerimientos como base del desarrollo. Los verificadores encargados de las sesiones de prueba destinadas a asegurar que el sistema cumple los requerimientos. 2. Captura de requerimientos 1. Primera tarea 2. Fase critica. Colaboración de grupos heterogéneos. Desarrollador Cliente/Usuario Identifc. Actores Actividades Obtención Requer. Captura de Requer. Identifc. Funcionalidad 2. Objetivos de la captura de requerimientos : Identificación de actores. Entidades externas que interactúan con el sistema. Como abstracción de papeles. Identificar la funcionalidad a la que tiene acceso cada actor. Identificación de escenarios. Descripción concreta, enfocada e informal de una sola característica del sistema desde el punto de vista de un solo actor. Descripción de casos de uso. 2. Administración de la Captura de requerimientos: Fuentes: Documentación. Personas con puntos de vista necesarios. Técnicas Cuestionarios Entrevistas Talleres Prototipos 2. Captura de requerimientos -- Fuentes. Análisis de Documentación. Es imprescindible cuando: Introducción del sistema en infraestructuras existentes. Suplemento de funcionalidad ya disponible. Documentación a analizar: Sobre las prácticas existentes de los usuarios. Sobre procedimientos de soporte. Sobre componentes técnicos. Sobre el modelo lógico Sobre los modelos de procesos y datos Sobre requisitos existente 2. Captura de Requerimientos -- Fuentes. Personas. Identificar personas con puntos de vista precisos para representar el conjunto de los requerimientos: 1. 2. 3. 4. 5. 6. 7. Dirección general Usuarios finales y dirección Clientes Proveedores El equipo operativo El equipo de mantenimiento Asesoría jurídica u otros expertos. Importante contar con más de una persona por cada punto de vista. 2. Captura Requerimientos -- Técnicas 1. Elaboración de cuestionarios. 1. Recomendable para grandes poblaciones (+30 personas). 2. Recomendable como base para posterior entrevista personal. 3. Crear un marco para el análisis de resultados. (visión clara de cómo utilizar 4. 5. 6. 7. la información) Comprobar que existe información suficiente en el personal “cuestionado”. Garantizar que es comprensible (no utiliza argot técnico). Probarlo antes de comenzar Verificar la comprensión. 2. Captura de requerimientos -- Tipos de cuestionarios. Para recopilar datos estructurados. 2 Modalidades: 1. Mediante Lista de cuestiones concretas y de respuesta cerrada. ▪ ¿Cuánto lleva operando el actual sistema de facturación (en años)?. 2. Mediante índices. ▪ ¿Importancia de estos factores para adquirir un OS? Baja Alta Velocidad 1 2 3 4 5 Usabilidad 1 2 3 4 5 Flexibilidad 1 2 3 4 5 2. Captura de requerimientos -- Tipos de cuestionarios. Cuestionarios para recoger información abierta. Se formula una pregunta abierta. ¿Cuál son para usted los factores principales en la selección de proveedor de servicios de Internet” Útiles para obtener una información inicial sobre el área. Importante evitar sesgos. 2. Determinación de Requerimientos. Técnicas captura. Entrevistas Objetivo: Obtener toda la información posible de la visión que el entrevistado tiene de los requisitos. Depende de la habilidad del entrevistador para crear un clima de confianza. Resulta útil planificar las entrevistas para evitar sesgos (evitar que un grupo incline a un lado el proceso). Preparar un marco para la entrevista (mediante un cuestionario) Confirmar detalles del entrevistado Establecer la finalidad de la entrevista con el entrevistado Organizar una lugar adecuado. Confirmar los detalles por escrito. 2. Técnicas de captura -- Entrevistas. Es aconsejable 2 entrevistadores (una conduce la entrevista el otro supervisa la interacción y toma notas): Mejora la gestión del tiempo. Beneficia la supervisión. Es aconsejable emplear tanto preguntas abiertas como cerradas: Abiertas: Suelen comenzar por “qué”, por qué” y “como” y exigen respuesta detallada por el entrevistado. Cerradas: Aquellas con un Intervalo específico de respuesta. El entrevistador debe centrar la entrevista cuando esta se desvía. El entrevistador debe evitar emitir juicios de valor para no influir. 2. Técnicas captura. -- Entrevistas. Análisis de resultados de la entrevista: Si se ha utilizado como marco un cuestionario, este se utilizará como contexto en el análisis. Si la entrevista no es estructurada, el resultado se detallará como informe. Esquema de resumen de entrevista Nombre entrevistado. Puesto de trabajo y breve descripción. Punto de vista que representa. Fecha, hora y lugar de la entrevista Resumen de puntos principales Doc´s. de referencia Otros contactos. 2. Técnicas captura -- Talleres Reunión de partes interesadas. Sesiones intensivas y estructuradas concentradas en uno o dos días. Es preciso una importante preparación previa: Definir con los participantes la finalidad del taller. Facilitarles información histórica. El taller ha de ser dirigido por un experto para: Garantizar que todo los participantes aportan sus puntos de vista. No se desvían del propósito del taller. 2. Técnicas captura -- Talleres Los requisitos capturados en el taller se registran junto con todas las cuestiones y acciones resultantes. Se genera un informe para documentar los resultados y base de la especificación de requisitos. Tiene la ventaja de reunir a los participantes pudiendo debatirse las cuestiones más controvertidas y resolver así requisitos aparentemente divergentes satisfaciendo a las partes. 2. Técnicas captura -- Modelado de proceso Método de análisis vertical (up-down) para establecer la composición funcional del área para la cual se propone el sistema. Proceso Funciones Actividades Actividades Funciones Funciones Actividades Actividades Actividades 2. Técnicas captura -- Modelado de proceso Se descompone el sistema en procesos “atómicos” que no admitan mas divisiones. La derivación de procesos se realizará mediante técnicas de captura de requisitos. Los usuarios revisarán el modelo en cada desagregación. Permite correcciones antes de seguir con una mayor elaboración Permite identificar procesos de bajo nivel duplicados, permitiendo una simplificación del modelo. 2. Técnicas captura -- Prototipado Un prototipo es un modelo de sistema eventual que se puede utilizar para demostrar las características de lo que el sistema puede ofrecer. 2 métodos: P. desechable, P. evolutivo. Los prototipos pueden usarse para: Demostrar la viabilidad del sistema. Se implanta parte del sistema para: ▪ Comprobar el comportamiento funcional. ▪ Análisis de rendimiento. Aclarar los requisitos del usuario. 2. Documentación. Los requisitos han de reflejarse en un documento como registro del proceso de captura. El objetivo de la documentación es servir de base para la futura operativa del proyecto tanto para clientes como para desarrolladores. Por ello han de escribirse de modo que sean significativos para ambos. Así se generan dos documentos: Doc. De requisistos del usuario/Definición de requerimientos Doc. De requisitos del sistema/Especificación de requerimientos. 2. Documentación de Requisitos del Usuario/determinación de requerimientos. Listado completo de las cosas que el cliente espera que haga el sistema propuesto para todas las categorías de usuarios (incluido el soporte operativo). Redactado de forma que el cliente pueda entenderlo. (con claridad, conciso y congruente) Es generado entre cliente y desarrollador como documento de compromiso. Si el Documento recoge requisitos documentarán en términos mensurables. no funcionales se 2. Documentación de Requisitos del Usuario/Determinación de requerimientos. Elementos de la documentación: Se perfila el propósito general del sistema con referencias a otros sistemas relacionados y un diccionario de términos y abreviaturas que puedan ser útiles. Descripción de antecedentes y objetivos del desarrollo. Si el cliente tiene un nuevo enfoque para describir el problema se recoge el enfoque y sus restricciones o suposiciones si las hay. Se detallan se definen las características del sistema: Limites del sistema, interfaces, lista clases y características, funciones y procesos con sus entradas y salidas y finalmente requerimientos específicos de rendimiento. Requerimientos sobre soporte, seguridad y privacidad y cualquier restricción. 2. Documentación de Requisitos del Usuario/determinación de requerimientos. E. Requisitos del Usuario Introducción 1. Alcance. Área de aplicación de los requisitos. 2. Definiciones. 3. Historial. 4. Descripción de alto nivel. Esquema del problema. 5. RF (Forma atómica y con identificador) 6. RNF (Forma atómica y con identificador y vinculados a los funcionales que soportan) 7. Restricciones específicas 2. Documentación de Requisitos del Sistema/ Especificación de requerimientos. Se desarrolla a partir del documento de requisitos del usuario. Cubre el mismo área que el documento de requisitos del usuario pero en los términos técnicos adecuados para diseñar el sistema, Suele estar redactado por analistas de requerimientos. Se fundamenta en: El modelado del sistema, para esclarecer la funcionalidad del sistema. Restricciones sobre infraestructura. Requisitos Funcionales y no funcionales. 2. Documentación de requisitos del sistema/especificación de requerimientos. E. Requisitos del Sistema Introducción 1. Alcance. Relación con otros sistemas 2. Definiciones. 3. Historial. Infraestructura existente 4. Descripción de alto nivel. Esquema del problema. 5. RF (Forma atómica y con identificador) 6. RNF (Forma atómica y con identificador y vinculados a los funcionales que soportan) 7. Restricciones específicas 2. Determinación de Requerimientos. Validación. La determinación de requerimientos tiene 2 propósitos: El acuerdo entre clientes y desarrolladores sobre qué debe ser el sistema. Proporcionar a los diseñadores pautas para el desarrollo. La validación de requerimientos es el proceso por el cual se determina si la especificación del sistema es consistente, es decir si los requerimientos satisfarán las necesidades del cliente. 2 pasos (trazabilidad): Se asegura que cada especificación del sistema pueda ser rastreada hasta su requerimiento en el documento de definición. Se chequea la definición comprobando que cada requerimiento es rastreable hasta la especificación. 2. Determinación de Requerimientos. Validación. La técnica más utilizada y simple son las reuniones de revisión. Se examinan los requerimientos por parte de: Representantes del cliente: ▪ Operadores del sistema. ▪ Operadores que preparan las entradas ▪ Operadores los que utilizan las salidas ▪ Gerentes de estos empleados. Representantes del desarrollador: ▪ Equipo de diseño ▪ Equipo de pruebas, y gestión de configuración 2. Determinación de Requerimientos. Validación. La reuniones comprenden las siguientes actividades: Se revisan las metas declaradas y los objetivos del sistema. Se comparan las metas con los requerimientos para verificar que todos estos son necesarios. Se describe el ambiente en el que debe operar el sistema. Se evalúa y documenta el riesgo y se plantean alternativas. Se determinan las pruebas según avance el sistema. Cuando se detecta un problema se documenta y se establece la acción para subsanarlo antes del comienzo del proceso de diseño. 2. Determinación de Requerimientos. Validación. La trazabilidad de requisitos se documenta mediante la MTR (Matriz de trazabilidad de Requisitos). Matriz de Trazabilidad de Requisitos Resumen de requisitos del Usuario Requisito del Usuario Requisito del Sistema Identificador Identificador
