SlideShare una empresa de Scribd logo
Ingeniería de Software Unidad 1 Análisis de Requerimientos Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
Introducción Cada uno de los modelos del proceso de desarrollo del software propuestos, incluye actividades que apuntan a la captura de requerimientos. Por lo tanto, la comprensión del propósito y la función del sistema comienza con un atento examen de los requerimientos.
Definición de Requerimiento Cuando el Cliente solicita que se desarrolle un sistema tiene algunas nociones de lo que debe hacer. Por está razón cada sistema basado en software tiene un propósito, usualmente expresado con algo que el sistema debe hacer. Un Requerimiento  “es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema” .
Definición de Requerimiento Es decir, los requerimientos son lo que los clientes/usuarios esperan que haga el sistema. Los analistas, por lo tanto, deben entender el problema de los usuarios en  SU  cultura y con  SU  lenguaje y construir el sistema que resuelve sus necesidades. En si el objetivo del análisis de requerimientos es resolver el problema.
Requerimientos v/s Diseño Los requerimientos definen el  Qué  (el problema) del sistema. El Diseño define el  Cómo  (la solución). Durante el análisis de requerimientos no se consideran descripciones especificas de la implementación como requerimientos, a menos que el cliente lo pida (Ej.: bases de datos especificas, lenguajes de programación, etc.). Los requerimientos, por lo tanto deben centrarse en el cliente/usuario y el problema.
Importancia de los requerimientos En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar como les estaba llendo. Los resultados fueron desencantadores: El 31% de los proyectos de software fueron cancelados antes de tiempo (2480 proyectos). En las grandes compañías, sólo el 9% de los proyectos fue entregado en el termino de tiempo y dentro del costo que se presupuestaron; el 16% satisfizo estos requerimientos en las compañías pequeñas.
En 1995 Standish pidió a los participantes que especificarán las causas. Los resultados fueron los siguientes: Requerimientos incompletos (13,1%). Falta de compromiso del usuario (12,4%). Falta de recursos (10,6%). Expectativas no realistas (9,9%). Falta de soporte ejecutivo (9,3%). Requerimientos y especificaciones cambiantes (8,7%). Falta de planeamiento (8,1%). Fin de la necesidad del sistema (7,5%). Importancia de los requerimientos
Importancia de los requerimientos Boehm y Papaccio en 1988, realizan un cuantificación del costo de corregir los errores asociados a requerimientos en las diversas etapas del software. 200 Producción 20 Prueba Unitaria 10 Codificación 5 Diseño 1 Análisis y Esp. Requerimientos Costo en USD Etapa en la que se encuentra el error
Documentos de Requerimientos Existen dos documentos que emanan del análisis de requerimientos: Definición de requerimientos Es un documento que debe escribirse en términos que el cliente pueda entender. Es decir, este documento es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto.  Este documento es escrito en forma conjunta por el cliente y el desarrollador.
Documentos de Requerimientos Especificación de requerimientos Documento que reitera la definición de los requerimientos en los términos técnicos  apropiados para el desarrollador del diseño de un sistema. Es la contrapartida técnica al documento de definición de requerimientos y es escrito por los analistas de requerimientos. A veces un único documento puede servir para ambos propósitos, lo que lleva a un entendimiento común entre clientes, analistas de requerimientos y diseñadores.  Pero a menudo se necesitan ambos documentos.
Documentos de Requerimientos Es muy importante,  que al usar ambos documentos exista un correspondencia directa entre cada requerimiento  del documento de definición y aquellos documentos en la especificación.  Esto para que la visión del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestión de configuración).
Clasificación de Requerimientos Según el Tipo los requerimientos se clasifican en: Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio. Según a quien van dirigidos se clasifican en: Requerimientos del Usuario. Requerimientos del Sistema.
Clasificación de Requerimientos Requerimientos funcionales Describen la funcionalidad o los servicios que se espera que el sistema proveerá. Dependen del tipo de software, del sistema que se desarrollo y de los posibles usuarios. Cuando se expresan como Requerimientos del usuarios, se definen de forma general.  Cuando se expresan como requerimiento del sistema describen con detalle  la función de éste, sus entradas y salidas, excepciones, etc.
Clasificación de Requerimientos Requerimientos no funcionales Son los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema , sino a las propiedades emergentes de éste, como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. A menudo son mas críticos que los funcionales. Mientras que un incumplimiento de un requerimiento funcional degrada el sistema, el de un requerimiento no funcional del sistema lo inutiliza.
Clasificación de Requerimientos Requerimientos no funcionales Los requerimientos no funcionales se clasifican según su implicancia: Del producto : especifican comportamiento del producto. Ej.:  de desempeño en la rapidez de ejecución del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y de usabilidad. Organizacionales:  se derivan de las políticas y procedimientos existentes en la organización del cliente y del desarrollador. Ej.: estándares en los procesos que deben utilizarse, requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar.
Clasificación de Requerimientos Requerimientos no funcionales Externos : cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales, requerimientos éticos. Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar. De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva. En la práctica, es difícil. El costo es muy alto.
Clasificación de Requerimientos Requerimientos del dominio Se derivan del dominio del sistema más que de las necesidades especificas del usuario. Son importantes debido a que a menudo reflejan los fundamentos del dominio de la aplicación. Si estos no se satisfacen es imposible que el sistema trabaje de forma satisfactoria. Estos se expresan utilizando un lenguaje especifico del dominio de la aplicación que a menudo es difícil de comprender. Ej.: operación para calcular desaceleración del tren, para un sistema de control de trenes.
Características de los requerimientos Es importante señalar que los requerimientos pueden servir a tres propósitos: Permitir que el desarrollador explique como ha entendido lo que el cliente pretende del sistema. Indican a los diseñadores que funcionalidades y características va a tener el sistema resultante. Los requerimientos indican al equipo de pruebas que demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es de hecho lo que había ordenado.
Características de los requerimientos Los requerimientos deben ser de alta calidad para la buena comprensión de clientes y desarrolladores. Con este fin debe comprobarse que los requerimientos posean las características que se desprenden de las siguientes preguntas: ¿los requerimientos son correctos? . Cliente y desarrollador deben revisarlos para asegurarse que no tienen errores. ¿los requerimientos son consistentes? . Es decir, ¿los requerimientos planteados son no conflictivos ni ambiguos?. Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultáneamente.
Características de los requerimientos ¿los requerimientos son completos?.  El conjunto de requerimientos es completo si todos los estados posibles, cambios de estado, entradas, productos, restricciones están descritos en alguno de los requerimientos. ¿los requerimientos son realistas? .¿El sistema puede hacer realmente lo que el cliente esta pidiendo que haga?. Todos los requerimientos deben ser revisados para asegurarse que son posibles. ¿describe cada requerimiento algo que es necesario para el cliente?.  Los requerimientos deben ser revisados para conservar sólo aquellos que inciden directamente en la resolución del problema del cliente. ¿los requerimientos son verificables?.  Debemos preparar pruebas que demuestren que se han cumplido los requerimientos.
Características de los requerimientos ¿los requerimientos son rastreables?.  ¿Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que la establece?. ¿Resulta fácil encontrar el conjunto de requerimientos que coinciden a un aspecto especifico del sistema?.
Fuentes de Requerimientos Requerimientos Deseos y necesidad De los interesados Modelo del Dominio Modelo de la situación actual Requerimientos  Reutilizables Tipo de Requerimientos recomendados Documentos existentes Organización y sistemas actuales Robertson y Robertson 1999 Plantilla de Requerimientos Biblioteca de Reutilización
Proceso: Ingeniería de Requerimientos La Ingeniería de Requerimientos (IR) es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema.
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Estudio de Factibilidad La entrada de este es una descripción resumida del sistema y como se utiliza dentro de una organización. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema. Además permite proponer cambios al alcance, presupuesto, calendarización, etc. Este es un estudio corto para resolver si es posible y conveniente construir el sistema con la tecnología existente, las restricciones de costo y tiempo, etc.
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Se trabaja en conjunto con los usuarios y los clientes. Problemas Comunes: No saben lo que quieren del sistema , sólo en términos generales, no conocen el costo de sus peticiones. Los requerimientos están en sus términos y con conocimientos implícitos de su propio trabajo. Distintos usuarios tienen distintos requerimientos, se deben encontrar todas las fuentes.  Influyen factores políticos. La importancia de los requerimientos varia en el tiempo. Aparecen nuevos requerimientos.
Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Proceso de Obtención y Análisis de requerimientos. Comprensión  del dominio Recolección de  Requerimientos Clasificación Resolución de Conflictos Priorización Verificación  de Requerimientos
Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Fases: Comprensión del Dominio : el analista debe desarrollar su propia comprensión del dominio de la aplicación. Ej.: Si fuera un sistema para un supermercado este debe evaluar como funciona un supermercado. Recolección de Requerimientos:  éste es el proceso de interactuar con los clientes y usuarios para descubrir sus requerimientos . Acá se desarrolla la compresión del dominio. Clasificación:  considera la recolección no estructurada de requerimientos y los organiza en grupos coherentes.
Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Resolución de conflictos : de forma inevitable, cuando existen muchos  stakeholders  involucrados, los requerimientos estarán en conflicto. Está actividad se refiere a resolver estos conflictos. Priorización : Descubrir la importancia de cada requerimiento. Es útil separar los requerimientos en tres categorías: Requerimientos que deben ser absolutamente satisfechos. Requerimientos que son muy deseables pero no indispensables. Requerimientos que son posibles, pero que podrían eliminarse.  Verificación de Requerimientos : Los requerimientos se verifican para descubrir si están completos, son consistentes y acorde con lo que realmente quieren los stakeholders. No existe un enfoque perfecto ni universal aplicable a la obtención y análisis de requerimientos  .
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Especificación de Requerimientos Lenguaje Natural Comprensible para el Cliente/Usuario. Ambiguo (glosario). Poca legibilidad (plantilla, formateo del texto). Difícil de tratar (Verificar correctitud, consistencia, completitud). Notaciones Especiales (más formales) Poca o ninguna ambigüedad. Facilita tratamiento. Necesidad de entrenamiento en la notación. Dificultades de comprensión por Cliente/Usuario
Proceso: Ingeniería de Requerimientos Especificación de Requerimientos Notaciones Especiales. Gráficas vs. Basadas en texto Estáticas vs. Dinámicas Descripciones Estáticas. Se especifican entidades y sus atributos, los requerimientos se pueden ver como las relaciones entre las entidades.  No describe como cambian las relaciones con el tiempo Descripciones Dinámicas Especifican estados y las transiciones entre estados en el tiempo.
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Validación de Requerimientos Proceso por el cual se determina si la especificación es consistente con las necesidades del cliente. Incluye verificar trazabilidad entre la especificación y el documento de requerimientos. Se trabaja con un bosquejo completo del documento a diferencia de la verificación del Análisis. Se realizan las siguientes verificaciones en el documento de requerimientos: Validez: compromiso con el usuario, que valide que es lo que quiere. Consistencia: que no haya contradicciones. Realismo: que se puedan implementar (incluye: tecnología, presupuesto y calendario). Verificabilidad: Diseñar conjunto de pruebas para demostrar que el sistema cumple esos requerimientos.
Proceso: Ingeniería de Requerimientos Validación de Requerimientos Verificación de Requerimientos no funcionales. Son difíciles de verificar. Se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva ( esto es IDEAL). Para los usuarios es difícil especificarlos en forma cuantitativa. Tiempo de capacitación. Facilidad de uso Número de sistemas.  Portabilidad Probabilidad de datos corruptos después de la falla. Robustez Tiempo promedio entre fallas. Fiabilidad KB. Tamaño Transacciones por seg. Rapidez Medida Propiedad
Entre los participantes en el proceso de requerimiento pueden incluirse: Supervisor del contrato : quienes sugieren hitos de control y cronogramas que restringen el desarrollo del sistema. Clientes y Usuarios : quienes deben comprender los requerimientos de modo que puedan estar seguros de que el sistema satisface sus necesidades. Gerentes de negocios : pueden comprender las probables consecuencias de construir y utilizar el sistema. Diseñadores : quienes utilizan los requerimientos como base para el desarrollo de una solución aceptable, que se implementara como un sistema basado en software. Verificadores : desarrollan datos de prueba y sesiones de prueba   para asegurar que el sistema de software satisface cada uno de los requerimientos. Proceso: Ingeniería de Requerimientos Participantes en el proceso de requerimientos.
Proceso: Ingeniería de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Artefactos Modelo del Sistema
Proceso: Ingeniería de Requerimientos Modelado del Sistema Existen una gran cantidad de métodos para el modelamiento de sistemas, a continuación se nombran los más significativos: Tablas de Decisión. Diagramas de transición de estados. Redes de Petri. Diagramas de Flujo de Datos. Diagramas de Casos de Uso. Técnicas para describir un sistema entorno a estados y estímulos.
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Decisión Descripción dinámica. Conjunto de  condiciones posibles  en un cierto instante o tiempo dado. Estados  donde se verifica una combinación determinada de las condiciones. Acciones  a tomar. Condiciones Acciones Estados F = Condición Falsa V = Condición Verdadera - = condición no importa F V V F V Buenos Antecedentes V V V F F Importe > 1000 X X X Analizar antecedentes X X Autorizar Crédito - F V - - Ya operó antes 5 4 3 2 1
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Decisión La tabla de decisión representa   acciones a ser tomadas cuando el sistema está en uno de los estados representados. El número de estados es = 2^ nº de condiciones, lo que da como resultado tablas de decisión muy extensas. Se puede verificar que si todo conjunto de posibles  condiciones  resulta en una acción, entonces la especificación está completa. También se puede analizar la consistencia de la tabla, y eliminar cualquier caso conflictivo.
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Descripción dinámica. Se interpreta el sistema de una forma similar, a un conjunto de estados donde el sistema reacciona a ciertos eventos posibles. El conjunto de estados se denomina S. Un estado inicial es, S0. Un conjunto de eventos o condiciones, C. Existe una función de transición de estados, F. F(Si,Cj) = Sk
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Tabla de Transición. S3 1 S3 S1 0 S3 S1 1 S2 S2 0 S2 S1 1 S1 S2 0 S1 PROXIMO ESTADO ENTRADA ESTADO ACTUAL S1 S2 S3 0 1 0 1 1 0
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Ejemplo de un diagrama de transición de estados para reserva de Hotel (Utilizando forma UML).  Condición Acciones INICIO Solicitud de plaza ninguna Solicitada Confirmada En Lista de Espera Ninguna plaza disponible Poner en lista de espera Plaza disponible decrementar cuenta de plaza Plaza disponible decrementar cuenta de plaza Cancelada El cliente desiste Retirar de la lista El cliente cancela Incrementar cuenta de plazas Ocupada El cliente ocupa ninguna
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Descripción dinámica. Las técnicas descritas hasta ahora son sumamente útiles para sistemas cuyos estados y eventos son secuenciales. Está técnica permite describir : concurrencia y sincronización.  La representación con una red de petri es una alternativa que se ajusta bien para expresar los requerimientos del procesamiento paralelo.
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Las Redes de Petri son Grafos dirigidos con dos tipos de nodos: Estados    y  Transiciones  . Arcos sólo pueden unir Estados con Transiciones y Transiciones con Estados
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri El estado inicial de una red de Petri se le llama marca, esta dado por los Tokens (marcas) iniciales. Significado:  Transiciones: Modelan eventos o acciones. Lugares con marca: Cumplimiento de una condición. Transición activada: Ocurrencia del evento o ejecución de la acción. L1 -Lugar con marca L2 -Lugar Transición
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Al activarse una transición, los tokens que activaron la transición desaparecen de los lugares de entrada y se generan tokens en los lugares de salida de la transición. Transición habilitada: Existe al menos un token en cada uno de sus lugares de entrada. Estado pronto para activar la transición. L3 L2 L1 L4 L5 L3 L2 L1 L4 L5 T1
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Secuencia A2 A1 L3 T1 T2 A4 T3 T4 T5 Conflicto Concurrencia T6 T7 T8 T9 A5 A6 A7
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri (Ejemplo) Máquina dispensadora T1-Inserta moneda E1- Tiene moneda E2- pronta T3- acepta moneda E3- pronto para dispensar T4-dispensa T2- rechaza moneda Se dispararon las transiciones: t1,t3,t4 Otra secuencia posible seria t1,t2
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Descripción dinámica Proviene de Metodología de Análisis y Diseño Estructurado fin de la década del 70. Usados en versión original de OMT (Rumbaugh 91), no incorporados a UML. Antes de los Casos de Uso era una de las formas más usadas para describir un sistema.  Elementos Proceso del sistema que recibe datos y genera otros. Archivo de datos. Flujo de Datos. Entidad Externa al sistema a modelar (actor) Proceso Datos que entran Archivo Datos que salen
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Ejemplo: Examen Historia Clínica Médico Paciente Experiencia y conocimiento Síntomas Medicación y  Diagnostico Factura Lista de exámenes y servicios brindados Contabilidad Registro Contable Paciente
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Permite visualizar cómo fluye la información por el sistema. Está asociado a una realización particular del sistema. El diagrama no es suficiente para precisar el comportamiento: por un flujo que entra a un proceso desde un archivo,  ¿fluye un registro o todo el archivo?. No estipula sincronización, un flujo llega a una entidad externa y otro sale  ¿Están relacionados? ¿Uno es respuesta del otro?. Se complementa con un diccionario de datos que describe: estructura de los flujos y otros detalles. los procesos (lenguaje natural estructurado) con lo que el comportamiento queda determinado. A menudo sistemas legados están documentados con DFD.
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Casos de Uso (UML) Técnica para entender y describir requerimientos. Los casos de uso son requerimientos, describen requerimientos funcionales. Pone el acento en el uso del producto. Describen como el sistema debe comportarse desde el punto de vista del usuario. Casos de Uso como caja negra: Especifican que es lo que el sistema debe hacer sin especificar cómo debe hacerlo. Se describen mediante documentos de texto. Introducido por  Ivar Jacobson (1992).
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Casos de Uso (UML) Ejemplo: Actor: Entidad Externa que interactúa con el sistema (persona identificada por un rol o sistema externo). Caso de Uso: Conjunto de escenarios posibles que puede encarar un actor (o varios) con el sistema para el logro de cierto objetivo. Limite del Sistema Caso de Uso Reutilizable <<include>> Caso de Uso Escenario Variable <<extends>> Generalización
Proceso: Ingeniería de Requerimientos Modelado del Sistema – Elección de una Técnica Ninguna técnica de especificación es completa. La elección de la técnica esta limitada por: Características del proyecto. Preferencia de los desarrolladores. Preferencias del cliente. Por lo general se combinan varios enfoques, por ejemplo: Una técnica para requerimientos funcionales. Otra técnica para los requerimientos no funcionales.
Proceso: Ingeniería de Requerimientos Técnicas – Obtención y Análisis de Requerimientos Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Posibles conflictos : Balancear Recursos Tiempo Alcance Calidad Necesidades Expectativas   Necesidades Expectativas   Tecnología Personas Proceso Restricciones
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Técnicas : Investigar antecedentes. Entrevistas individuales/grupales. Encuestas/Cuestionarios. Tormenta de ideas.  Casos de Uso. Prototipado.
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Investigar Antecedentes Estudio, muestreo, visitas,… Buena forma de comenzar un proyecto. Interna: Estructura de la organización, Políticas y procedimientos, Formularios e informes, Documentación de sistemas. Externa: Publicaciones de la industria y comercio, Encuentros profesionales, Visitas, Literatura y presentaciones de vendedores. Ventajas Ahorra tiempo de otros. Prepara para otros enfoques. Puede llevarse a cabo fuera de la organización. Desventajas Perspectiva limitada. Desactualizado. Demasiado genérico.
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Entrevistas Individuales y Grupales Usar para: Entender el problema de negocio. Entender el ambiente de operación. Evitar omisión de requerimientos. Mejorar las relaciones con el cliente. Ventajas Orientación a las personas. Interactivo / Flexible. Rico. Desventajas Costoso. Depende de las habilidades interpersonales.
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Encuesta / Cuestionario No substituye la entrevista. Antes de usar el enfoque: Determinar la información que se precisa. Desarrollar cuestionario. Probarlo con perfil típico. Analizar resultado de las pruebas. Su principal uso es para validar asunciones y obtener datos estadísticos sobre preferencias. Ventajas Conveniente para quien contesta. Respuestas anónimas. Desventajas Menos  Rico. Problemas por no Respuestas. Esfuerzo de desarrollo.
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Tormenta de Ideas Objetivo: Lograr consenso sobre los requerimientos. Ayuda a la participación de todos los involucrados. Permite pensar en otras ideas. Un secretario saca notas de todo lo discutido. Reglas: No se permite criticar ni debatir. Dejar volar la imaginación. Generar tantas ideas como sea posible. Mutar y combinar ideas.
Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Casos de Uso Formato simple y estructurado donde los usuarios y desarrolladores pueden trabajar juntos. No son de gran ayuda para identificar aspectos no funcionales. Mientras se definen los casos de uso, puede ser un buen momento para definir pantallas u otros objetos con los que el usuario interactúa. Pueden ser usados en el diseño y en el testing del sistema. Usarlo Cuando el sistema está orientado a la funcionalidad, con varios tipos de usuarios. Cuando la implementación se va a hacer OO y con UML. No son la mejor elección: Sistemas sin usuarios y con pocas interfaces. Sistemas dominados primariamente por requerimientos no funcionales y restricciones de diseño.
Implementación parcial, permite a los desarrolladores y usuarios: Entender mejor los requerimientos. Cuales son necesarios, deseables. Acotar riesgos. Prototipo desechable : El propósito es solo establecer que algo se puede hacer, luego se parte de cero en la construcción, quedando el conocimiento aprendido. Prototipo evolutivo : Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo. Aspectos para los que es frecuente construir prototipos: Apariencia y percepción de la interfaz de usuario. Arquitectura (riesgos técnológicos, tiempos de respuesta). Otros aspectos riesgosos. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Prototipado
Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos. Estudio de  factibilidad Obtención y  Análisis de  Requerimientos Especificación  de  Requerimientos Validación  de  Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento  de  Requerimientos Modelo del Sistema Artefactos
Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos. La validación incluye dos pasos: Asegurar que cada especificación pueda ser rastreada hasta su requerimiento en el documento de definición. Luego se chequea la definición para ver si cada requerimiento es  rastreable hasta la especificación.   Es importante recordar, que la validación no es tan solo un rastreo de traza. Ya que, además, pretende garantizar que el sistema hará lo que los clientes y usuarios esperan. Validando que las metas e intenciones de los usuarios y clientes están satisfechas. Una forma simple de validar los requerimientos es la realización de reuniones de revisión.
Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos Revisiones de Requerimientos Participan representantes del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus gerentes. del equipo de desarrollo: analistas de requerimientos, diseñadores, encargados de pruebas y gestión de configuración. Incluye: Revisar objetivos del sistema. Evaluar alineamiento de requerimientos con los objetivos (necesidad). Revisar el ambiente de operación y las interfaces con otros sistemas. Funciones completas, restricciones realistas. Evaluar riesgos. Considerar: Pruebas del sistema. Cambios en los requerimientos en el proyecto, su verificación y validación.
Medición de Requerimientos La medición de requerimientos está enfoca a tres áreas: Producto, Proceso y Recursos. Los productos de los requerimientos (definición y especificación) pueden ser evaluados en primer lugar considerando el  número de requerimientos . De manera similar se puede medir la  cantidad de cambios introducidos a los requerimientos . Un gran número de cambios indica cierta inestabilidad o incertidumbre en la comprensión de lo que el sistema debe hacer o como comportarse. También es bueno evaluar la  incertidumbre por tipo de requerimiento . Esto permite seccionar.
Medición de Requerimientos Debido a que los requerimientos son utilizados por los diseñadores y verificadores, pueden utilizarse medidas que reflejen cuando los requerimientos están preparados para derivar a ellos.  Existe un forma de evaluación utilizada para verificadores y diseñadores, donde califican los requerimientos en una escala de 1 a 5 para saber si estos están listos. La escala es la siguiente: Lo comprende por completo, ha diseñado (verificado)  requerimiento similar antes y no debería tener problema. El requerimiento posee algún elemento que le resulta nuevo, pero no es radicalmente distinto de lo que ha diseñado (verificado) con éxito antes.
Medición de Requerimientos Hay elementos nuevos que lo hacen muy diferente de los que ha diseñado (verificado) antes, pero los comprende y piensa que a partir de ellos puede desarrollar un buen diseño (prueba). Hay partes del requerimiento que no entiende bien y no está seguro de poder desarrollar un buen diseño (prueba). No comprende este requerimiento en absoluto y no puede desarrollar un diseño (prueba) para él. Si un verificador o diseñador entrega un perfil con mayoría de 1 y 2 entonces el requerimiento esta en forma y puede pasar al equipo de diseño o verificación. OK A B 1  2  3  4  5 Diseñadores Verificadores 1  2  3  4  5 1  2  3  4  5 1  2  3  4  5
Bibliografía Software Engineering 6a. ed.– Ian Somm erville – Pearson Education – 2000.(Cap. 5 y 6)  Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002. (Cap 4)

Más contenido relacionado

La actualidad más candente

Organigrama funcional de una empresa desarrolladora de software
Organigrama  funcional  de una empresa desarrolladora de softwareOrganigrama  funcional  de una empresa desarrolladora de software
Organigrama funcional de una empresa desarrolladora de software
Jose Luis Arce Caguana
 
Proceso unificado
Proceso unificadoProceso unificado
Proceso unificado
Yolanda Uruchima
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
Cesar Prado
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
Rosa Virginia Ortega Loaiza
 
Métricas de procesos y proyectos
Métricas de procesos y proyectosMétricas de procesos y proyectos
Métricas de procesos y proyectos
jose_macias
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
Alexander Chaunay Paladines
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
Universidad Tecnológica
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
aics-1986-13-saraguro
 
Factores de calidad del software
Factores de calidad del softwareFactores de calidad del software
Factores de calidad del software
SebastianSeronGuerre
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
Robert Rodriguez
 
Modelado con erwin
Modelado con erwinModelado con erwin
Modelado con erwin
Luis Jherry
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientos
FSILSCA
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
jmpov441
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
Carlos Macallums
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
EvelinBermeo
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
Juan Carlos Olivares Rojas
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
Camila Arbelaez
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
Joan Sebastián Ramírez Pérez
 
Diagrama de casos de usos
Diagrama de casos de usosDiagrama de casos de usos
Diagrama de casos de usos
Juan Carlos Tapias
 
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
Software Guru
 

La actualidad más candente (20)

Organigrama funcional de una empresa desarrolladora de software
Organigrama  funcional  de una empresa desarrolladora de softwareOrganigrama  funcional  de una empresa desarrolladora de software
Organigrama funcional de una empresa desarrolladora de software
 
Proceso unificado
Proceso unificadoProceso unificado
Proceso unificado
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Métricas de procesos y proyectos
Métricas de procesos y proyectosMétricas de procesos y proyectos
Métricas de procesos y proyectos
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
 
Factores de calidad del software
Factores de calidad del softwareFactores de calidad del software
Factores de calidad del software
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
 
Modelado con erwin
Modelado con erwinModelado con erwin
Modelado con erwin
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientos
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
Diagrama de casos de usos
Diagrama de casos de usosDiagrama de casos de usos
Diagrama de casos de usos
 
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
 

Destacado

Analisis y especificacion de requerimientos
Analisis y especificacion de requerimientosAnalisis y especificacion de requerimientos
Analisis y especificacion de requerimientos
UPTP
 
Herramientas de Servicio
Herramientas de ServicioHerramientas de Servicio
Herramientas de Servicio
Hugo A. Saenz
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisis
Carolina Rojas
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisis
Javier Rivera
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
manuel alfredo chacon valero
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitos
Kleo Jorgee
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
Ramiro Estigarribia Canese
 
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Sergio Sanchez
 
Analisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de SoftwareAnalisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de Software
Marvin Romero
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
turlahackers
 
Analisis y diseño de sistemas
Analisis y diseño de sistemasAnalisis y diseño de sistemas
Analisis y diseño de sistemas
Jesus A. Olivier Pereira
 
Sistema de información para el control de nomina
Sistema de información para el control de nominaSistema de información para el control de nomina
Sistema de información para el control de nomina
Javier Contreras
 
Kendall y Kendall
Kendall y KendallKendall y Kendall
Kendall y Kendall
Natalia Alejandra
 
Sistema De Gestion De Notas
Sistema De Gestion De NotasSistema De Gestion De Notas
Sistema De Gestion De Notas
Carlos Cardenas Fernandez
 
Proceso de organización, tipos y tecnicas(administracion)
Proceso de organización, tipos y tecnicas(administracion)Proceso de organización, tipos y tecnicas(administracion)
Proceso de organización, tipos y tecnicas(administracion)
Hugo Arturo Gonzalez Macias
 
Metodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemasMetodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemas
Andoni Vasquez
 
Kendal y Kendal
Kendal y KendalKendal y Kendal
Las 7 fases de kendal & kendall
Las 7 fases de kendal & kendallLas 7 fases de kendal & kendall
Las 7 fases de kendal & kendall
davidmonar
 
Sistema de Nomina
Sistema de NominaSistema de Nomina
Sistema de Nomina
Nidara Belikov
 

Destacado (19)

Analisis y especificacion de requerimientos
Analisis y especificacion de requerimientosAnalisis y especificacion de requerimientos
Analisis y especificacion de requerimientos
 
Herramientas de Servicio
Herramientas de ServicioHerramientas de Servicio
Herramientas de Servicio
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisis
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisis
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitos
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
 
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo Conceptual
 
Analisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de SoftwareAnalisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de Software
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
 
Analisis y diseño de sistemas
Analisis y diseño de sistemasAnalisis y diseño de sistemas
Analisis y diseño de sistemas
 
Sistema de información para el control de nomina
Sistema de información para el control de nominaSistema de información para el control de nomina
Sistema de información para el control de nomina
 
Kendall y Kendall
Kendall y KendallKendall y Kendall
Kendall y Kendall
 
Sistema De Gestion De Notas
Sistema De Gestion De NotasSistema De Gestion De Notas
Sistema De Gestion De Notas
 
Proceso de organización, tipos y tecnicas(administracion)
Proceso de organización, tipos y tecnicas(administracion)Proceso de organización, tipos y tecnicas(administracion)
Proceso de organización, tipos y tecnicas(administracion)
 
Metodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemasMetodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemas
 
Kendal y Kendal
Kendal y KendalKendal y Kendal
Kendal y Kendal
 
Las 7 fases de kendal & kendall
Las 7 fases de kendal & kendallLas 7 fases de kendal & kendall
Las 7 fases de kendal & kendall
 
Sistema de Nomina
Sistema de NominaSistema de Nomina
Sistema de Nomina
 

Similar a Unidad 1.3 Analisis De Requerimientos

Analisis derequerimientos
Analisis derequerimientosAnalisis derequerimientos
Analisis derequerimientos
ljds
 
Material de apoyo analis de requerimientos
Material de apoyo analis de requerimientosMaterial de apoyo analis de requerimientos
Material de apoyo analis de requerimientos
SERGIO ANDRÉS BARANDICA PÉREZ
 
Análisisde requerimientos
Análisisde requerimientosAnálisisde requerimientos
Análisisde requerimientos
mayrapeg
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
mezcalote
 
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
Análisis y diseño de sistemas   sesion 09 - validacion de requisitos iiAnálisis y diseño de sistemas   sesion 09 - validacion de requisitos ii
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
GianfrancoEduardoBra
 
Analisis_requerimientos_recopilacion.pptx
Analisis_requerimientos_recopilacion.pptxAnalisis_requerimientos_recopilacion.pptx
Analisis_requerimientos_recopilacion.pptx
Angel Tello
 
Unidad13analisisderequerimientos 13026971308524-phpapp01
Unidad13analisisderequerimientos 13026971308524-phpapp01Unidad13analisisderequerimientos 13026971308524-phpapp01
Unidad13analisisderequerimientos 13026971308524-phpapp01
duberlisg
 
Requerimiento
RequerimientoRequerimiento
Requerimiento
JoseUSA129
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
Tensor
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
jocabedmariamartinez
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer Alas
Eliezer Alas
 
Tema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de RequisitosTema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de Requisitos
Juan Carlos González Moreno
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemas
cardan2007i
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
univ of pamplona
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Zuleima
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
karolavergara
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
Mario César Ramírez Venegas
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Zuleima
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
Luis Anibal
 
F capitulo 5_requerimientos_del_software
F capitulo 5_requerimientos_del_softwareF capitulo 5_requerimientos_del_software
F capitulo 5_requerimientos_del_software
JesseniaMangua
 

Similar a Unidad 1.3 Analisis De Requerimientos (20)

Analisis derequerimientos
Analisis derequerimientosAnalisis derequerimientos
Analisis derequerimientos
 
Material de apoyo analis de requerimientos
Material de apoyo analis de requerimientosMaterial de apoyo analis de requerimientos
Material de apoyo analis de requerimientos
 
Análisisde requerimientos
Análisisde requerimientosAnálisisde requerimientos
Análisisde requerimientos
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
 
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
Análisis y diseño de sistemas   sesion 09 - validacion de requisitos iiAnálisis y diseño de sistemas   sesion 09 - validacion de requisitos ii
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
 
Analisis_requerimientos_recopilacion.pptx
Analisis_requerimientos_recopilacion.pptxAnalisis_requerimientos_recopilacion.pptx
Analisis_requerimientos_recopilacion.pptx
 
Unidad13analisisderequerimientos 13026971308524-phpapp01
Unidad13analisisderequerimientos 13026971308524-phpapp01Unidad13analisisderequerimientos 13026971308524-phpapp01
Unidad13analisisderequerimientos 13026971308524-phpapp01
 
Requerimiento
RequerimientoRequerimiento
Requerimiento
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer Alas
 
Tema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de RequisitosTema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de Requisitos
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemas
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
F capitulo 5_requerimientos_del_software
F capitulo 5_requerimientos_del_softwareF capitulo 5_requerimientos_del_software
F capitulo 5_requerimientos_del_software
 

Más de Sergio Sanchez

Unidad 6 Lenguaje Sql
Unidad 6 Lenguaje SqlUnidad 6 Lenguaje Sql
Unidad 6 Lenguaje Sql
Sergio Sanchez
 
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Sergio Sanchez
 
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Sergio Sanchez
 
Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2
Sergio Sanchez
 
Unidad 5 TransformacióN Er A Relacional NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióNUnidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional NormalizacióN
Sergio Sanchez
 
Unidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióNUnidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióN
Sergio Sanchez
 
Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos Conceptual
Sergio Sanchez
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De Datos
Sergio Sanchez
 
Unidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De DatosUnidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De Datos
Sergio Sanchez
 
Unidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De SistemasUnidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De Sistemas
Sergio Sanchez
 
Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De Programas
Sergio Sanchez
 
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El ProgramaUnidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Sergio Sanchez
 
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De SistemasUnidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De Sistemas
Sergio Sanchez
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
Sergio Sanchez
 
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos TradicionalesUnidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
Sergio Sanchez
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De Software
Sergio Sanchez
 
Unidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De ClasesUnidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De Clases
Sergio Sanchez
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
Sergio Sanchez
 
Unidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióNUnidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióN
Sergio Sanchez
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Sergio Sanchez
 

Más de Sergio Sanchez (20)

Unidad 6 Lenguaje Sql
Unidad 6 Lenguaje SqlUnidad 6 Lenguaje Sql
Unidad 6 Lenguaje Sql
 
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
 
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
 
Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2
 
Unidad 5 TransformacióN Er A Relacional NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióNUnidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional NormalizacióN
 
Unidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióNUnidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióN
 
Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos Conceptual
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De Datos
 
Unidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De DatosUnidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De Datos
 
Unidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De SistemasUnidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De Sistemas
 
Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De Programas
 
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El ProgramaUnidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
 
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De SistemasUnidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De Sistemas
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
 
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos TradicionalesUnidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De Software
 
Unidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De ClasesUnidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De Clases
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
 
Unidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióNUnidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióN
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
 

Unidad 1.3 Analisis De Requerimientos

  • 1. Ingeniería de Software Unidad 1 Análisis de Requerimientos Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
  • 2. Introducción Cada uno de los modelos del proceso de desarrollo del software propuestos, incluye actividades que apuntan a la captura de requerimientos. Por lo tanto, la comprensión del propósito y la función del sistema comienza con un atento examen de los requerimientos.
  • 3. Definición de Requerimiento Cuando el Cliente solicita que se desarrolle un sistema tiene algunas nociones de lo que debe hacer. Por está razón cada sistema basado en software tiene un propósito, usualmente expresado con algo que el sistema debe hacer. Un Requerimiento “es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema” .
  • 4. Definición de Requerimiento Es decir, los requerimientos son lo que los clientes/usuarios esperan que haga el sistema. Los analistas, por lo tanto, deben entender el problema de los usuarios en SU cultura y con SU lenguaje y construir el sistema que resuelve sus necesidades. En si el objetivo del análisis de requerimientos es resolver el problema.
  • 5. Requerimientos v/s Diseño Los requerimientos definen el Qué (el problema) del sistema. El Diseño define el Cómo (la solución). Durante el análisis de requerimientos no se consideran descripciones especificas de la implementación como requerimientos, a menos que el cliente lo pida (Ej.: bases de datos especificas, lenguajes de programación, etc.). Los requerimientos, por lo tanto deben centrarse en el cliente/usuario y el problema.
  • 6. Importancia de los requerimientos En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar como les estaba llendo. Los resultados fueron desencantadores: El 31% de los proyectos de software fueron cancelados antes de tiempo (2480 proyectos). En las grandes compañías, sólo el 9% de los proyectos fue entregado en el termino de tiempo y dentro del costo que se presupuestaron; el 16% satisfizo estos requerimientos en las compañías pequeñas.
  • 7. En 1995 Standish pidió a los participantes que especificarán las causas. Los resultados fueron los siguientes: Requerimientos incompletos (13,1%). Falta de compromiso del usuario (12,4%). Falta de recursos (10,6%). Expectativas no realistas (9,9%). Falta de soporte ejecutivo (9,3%). Requerimientos y especificaciones cambiantes (8,7%). Falta de planeamiento (8,1%). Fin de la necesidad del sistema (7,5%). Importancia de los requerimientos
  • 8. Importancia de los requerimientos Boehm y Papaccio en 1988, realizan un cuantificación del costo de corregir los errores asociados a requerimientos en las diversas etapas del software. 200 Producción 20 Prueba Unitaria 10 Codificación 5 Diseño 1 Análisis y Esp. Requerimientos Costo en USD Etapa en la que se encuentra el error
  • 9. Documentos de Requerimientos Existen dos documentos que emanan del análisis de requerimientos: Definición de requerimientos Es un documento que debe escribirse en términos que el cliente pueda entender. Es decir, este documento es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.
  • 10. Documentos de Requerimientos Especificación de requerimientos Documento que reitera la definición de los requerimientos en los términos técnicos apropiados para el desarrollador del diseño de un sistema. Es la contrapartida técnica al documento de definición de requerimientos y es escrito por los analistas de requerimientos. A veces un único documento puede servir para ambos propósitos, lo que lleva a un entendimiento común entre clientes, analistas de requerimientos y diseñadores. Pero a menudo se necesitan ambos documentos.
  • 11. Documentos de Requerimientos Es muy importante, que al usar ambos documentos exista un correspondencia directa entre cada requerimiento del documento de definición y aquellos documentos en la especificación. Esto para que la visión del cliente este unida a la de los desarrolladores (esto se logra gracias a la gestión de configuración).
  • 12. Clasificación de Requerimientos Según el Tipo los requerimientos se clasifican en: Requerimientos funcionales. Requerimientos no funcionales. Requerimientos del Dominio. Según a quien van dirigidos se clasifican en: Requerimientos del Usuario. Requerimientos del Sistema.
  • 13. Clasificación de Requerimientos Requerimientos funcionales Describen la funcionalidad o los servicios que se espera que el sistema proveerá. Dependen del tipo de software, del sistema que se desarrollo y de los posibles usuarios. Cuando se expresan como Requerimientos del usuarios, se definen de forma general. Cuando se expresan como requerimiento del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.
  • 14. Clasificación de Requerimientos Requerimientos no funcionales Son los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema , sino a las propiedades emergentes de éste, como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. A menudo son mas críticos que los funcionales. Mientras que un incumplimiento de un requerimiento funcional degrada el sistema, el de un requerimiento no funcional del sistema lo inutiliza.
  • 15. Clasificación de Requerimientos Requerimientos no funcionales Los requerimientos no funcionales se clasifican según su implicancia: Del producto : especifican comportamiento del producto. Ej.: de desempeño en la rapidez de ejecución del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea aceptable, los de portabilidad y de usabilidad. Organizacionales: se derivan de las políticas y procedimientos existentes en la organización del cliente y del desarrollador. Ej.: estándares en los procesos que deben utilizarse, requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar.
  • 16. Clasificación de Requerimientos Requerimientos no funcionales Externos : cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales, requerimientos éticos. Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar. De forma ideal los requerimientos no funcionales se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva. En la práctica, es difícil. El costo es muy alto.
  • 17. Clasificación de Requerimientos Requerimientos del dominio Se derivan del dominio del sistema más que de las necesidades especificas del usuario. Son importantes debido a que a menudo reflejan los fundamentos del dominio de la aplicación. Si estos no se satisfacen es imposible que el sistema trabaje de forma satisfactoria. Estos se expresan utilizando un lenguaje especifico del dominio de la aplicación que a menudo es difícil de comprender. Ej.: operación para calcular desaceleración del tren, para un sistema de control de trenes.
  • 18. Características de los requerimientos Es importante señalar que los requerimientos pueden servir a tres propósitos: Permitir que el desarrollador explique como ha entendido lo que el cliente pretende del sistema. Indican a los diseñadores que funcionalidades y características va a tener el sistema resultante. Los requerimientos indican al equipo de pruebas que demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es de hecho lo que había ordenado.
  • 19. Características de los requerimientos Los requerimientos deben ser de alta calidad para la buena comprensión de clientes y desarrolladores. Con este fin debe comprobarse que los requerimientos posean las características que se desprenden de las siguientes preguntas: ¿los requerimientos son correctos? . Cliente y desarrollador deben revisarlos para asegurarse que no tienen errores. ¿los requerimientos son consistentes? . Es decir, ¿los requerimientos planteados son no conflictivos ni ambiguos?. Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultáneamente.
  • 20. Características de los requerimientos ¿los requerimientos son completos?. El conjunto de requerimientos es completo si todos los estados posibles, cambios de estado, entradas, productos, restricciones están descritos en alguno de los requerimientos. ¿los requerimientos son realistas? .¿El sistema puede hacer realmente lo que el cliente esta pidiendo que haga?. Todos los requerimientos deben ser revisados para asegurarse que son posibles. ¿describe cada requerimiento algo que es necesario para el cliente?. Los requerimientos deben ser revisados para conservar sólo aquellos que inciden directamente en la resolución del problema del cliente. ¿los requerimientos son verificables?. Debemos preparar pruebas que demuestren que se han cumplido los requerimientos.
  • 21. Características de los requerimientos ¿los requerimientos son rastreables?. ¿Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que la establece?. ¿Resulta fácil encontrar el conjunto de requerimientos que coinciden a un aspecto especifico del sistema?.
  • 22. Fuentes de Requerimientos Requerimientos Deseos y necesidad De los interesados Modelo del Dominio Modelo de la situación actual Requerimientos Reutilizables Tipo de Requerimientos recomendados Documentos existentes Organización y sistemas actuales Robertson y Robertson 1999 Plantilla de Requerimientos Biblioteca de Reutilización
  • 23. Proceso: Ingeniería de Requerimientos La Ingeniería de Requerimientos (IR) es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema.
  • 24. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 25. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 26. Proceso: Ingeniería de Requerimientos Estudio de Factibilidad La entrada de este es una descripción resumida del sistema y como se utiliza dentro de una organización. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema. Además permite proponer cambios al alcance, presupuesto, calendarización, etc. Este es un estudio corto para resolver si es posible y conveniente construir el sistema con la tecnología existente, las restricciones de costo y tiempo, etc.
  • 27. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 28. Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Se trabaja en conjunto con los usuarios y los clientes. Problemas Comunes: No saben lo que quieren del sistema , sólo en términos generales, no conocen el costo de sus peticiones. Los requerimientos están en sus términos y con conocimientos implícitos de su propio trabajo. Distintos usuarios tienen distintos requerimientos, se deben encontrar todas las fuentes. Influyen factores políticos. La importancia de los requerimientos varia en el tiempo. Aparecen nuevos requerimientos.
  • 29. Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Proceso de Obtención y Análisis de requerimientos. Comprensión del dominio Recolección de Requerimientos Clasificación Resolución de Conflictos Priorización Verificación de Requerimientos
  • 30. Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Fases: Comprensión del Dominio : el analista debe desarrollar su propia comprensión del dominio de la aplicación. Ej.: Si fuera un sistema para un supermercado este debe evaluar como funciona un supermercado. Recolección de Requerimientos: éste es el proceso de interactuar con los clientes y usuarios para descubrir sus requerimientos . Acá se desarrolla la compresión del dominio. Clasificación: considera la recolección no estructurada de requerimientos y los organiza en grupos coherentes.
  • 31. Proceso: Ingeniería de Requerimientos Obtención y Análisis de requerimientos Resolución de conflictos : de forma inevitable, cuando existen muchos stakeholders involucrados, los requerimientos estarán en conflicto. Está actividad se refiere a resolver estos conflictos. Priorización : Descubrir la importancia de cada requerimiento. Es útil separar los requerimientos en tres categorías: Requerimientos que deben ser absolutamente satisfechos. Requerimientos que son muy deseables pero no indispensables. Requerimientos que son posibles, pero que podrían eliminarse. Verificación de Requerimientos : Los requerimientos se verifican para descubrir si están completos, son consistentes y acorde con lo que realmente quieren los stakeholders. No existe un enfoque perfecto ni universal aplicable a la obtención y análisis de requerimientos .
  • 32. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 33. Proceso: Ingeniería de Requerimientos Especificación de Requerimientos Lenguaje Natural Comprensible para el Cliente/Usuario. Ambiguo (glosario). Poca legibilidad (plantilla, formateo del texto). Difícil de tratar (Verificar correctitud, consistencia, completitud). Notaciones Especiales (más formales) Poca o ninguna ambigüedad. Facilita tratamiento. Necesidad de entrenamiento en la notación. Dificultades de comprensión por Cliente/Usuario
  • 34. Proceso: Ingeniería de Requerimientos Especificación de Requerimientos Notaciones Especiales. Gráficas vs. Basadas en texto Estáticas vs. Dinámicas Descripciones Estáticas. Se especifican entidades y sus atributos, los requerimientos se pueden ver como las relaciones entre las entidades. No describe como cambian las relaciones con el tiempo Descripciones Dinámicas Especifican estados y las transiciones entre estados en el tiempo.
  • 35. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 36. Proceso: Ingeniería de Requerimientos Validación de Requerimientos Proceso por el cual se determina si la especificación es consistente con las necesidades del cliente. Incluye verificar trazabilidad entre la especificación y el documento de requerimientos. Se trabaja con un bosquejo completo del documento a diferencia de la verificación del Análisis. Se realizan las siguientes verificaciones en el documento de requerimientos: Validez: compromiso con el usuario, que valide que es lo que quiere. Consistencia: que no haya contradicciones. Realismo: que se puedan implementar (incluye: tecnología, presupuesto y calendario). Verificabilidad: Diseñar conjunto de pruebas para demostrar que el sistema cumple esos requerimientos.
  • 37. Proceso: Ingeniería de Requerimientos Validación de Requerimientos Verificación de Requerimientos no funcionales. Son difíciles de verificar. Se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva ( esto es IDEAL). Para los usuarios es difícil especificarlos en forma cuantitativa. Tiempo de capacitación. Facilidad de uso Número de sistemas. Portabilidad Probabilidad de datos corruptos después de la falla. Robustez Tiempo promedio entre fallas. Fiabilidad KB. Tamaño Transacciones por seg. Rapidez Medida Propiedad
  • 38. Entre los participantes en el proceso de requerimiento pueden incluirse: Supervisor del contrato : quienes sugieren hitos de control y cronogramas que restringen el desarrollo del sistema. Clientes y Usuarios : quienes deben comprender los requerimientos de modo que puedan estar seguros de que el sistema satisface sus necesidades. Gerentes de negocios : pueden comprender las probables consecuencias de construir y utilizar el sistema. Diseñadores : quienes utilizan los requerimientos como base para el desarrollo de una solución aceptable, que se implementara como un sistema basado en software. Verificadores : desarrollan datos de prueba y sesiones de prueba para asegurar que el sistema de software satisface cada uno de los requerimientos. Proceso: Ingeniería de Requerimientos Participantes en el proceso de requerimientos.
  • 39. Proceso: Ingeniería de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Artefactos Modelo del Sistema
  • 40. Proceso: Ingeniería de Requerimientos Modelado del Sistema Existen una gran cantidad de métodos para el modelamiento de sistemas, a continuación se nombran los más significativos: Tablas de Decisión. Diagramas de transición de estados. Redes de Petri. Diagramas de Flujo de Datos. Diagramas de Casos de Uso. Técnicas para describir un sistema entorno a estados y estímulos.
  • 41. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Decisión Descripción dinámica. Conjunto de condiciones posibles en un cierto instante o tiempo dado. Estados donde se verifica una combinación determinada de las condiciones. Acciones a tomar. Condiciones Acciones Estados F = Condición Falsa V = Condición Verdadera - = condición no importa F V V F V Buenos Antecedentes V V V F F Importe > 1000 X X X Analizar antecedentes X X Autorizar Crédito - F V - - Ya operó antes 5 4 3 2 1
  • 42. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Decisión La tabla de decisión representa acciones a ser tomadas cuando el sistema está en uno de los estados representados. El número de estados es = 2^ nº de condiciones, lo que da como resultado tablas de decisión muy extensas. Se puede verificar que si todo conjunto de posibles condiciones resulta en una acción, entonces la especificación está completa. También se puede analizar la consistencia de la tabla, y eliminar cualquier caso conflictivo.
  • 43. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Descripción dinámica. Se interpreta el sistema de una forma similar, a un conjunto de estados donde el sistema reacciona a ciertos eventos posibles. El conjunto de estados se denomina S. Un estado inicial es, S0. Un conjunto de eventos o condiciones, C. Existe una función de transición de estados, F. F(Si,Cj) = Sk
  • 44. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Tabla de Transición. S3 1 S3 S1 0 S3 S1 1 S2 S2 0 S2 S1 1 S1 S2 0 S1 PROXIMO ESTADO ENTRADA ESTADO ACTUAL S1 S2 S3 0 1 0 1 1 0
  • 45. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Tablas de Transición de Estados Ejemplo de un diagrama de transición de estados para reserva de Hotel (Utilizando forma UML). Condición Acciones INICIO Solicitud de plaza ninguna Solicitada Confirmada En Lista de Espera Ninguna plaza disponible Poner en lista de espera Plaza disponible decrementar cuenta de plaza Plaza disponible decrementar cuenta de plaza Cancelada El cliente desiste Retirar de la lista El cliente cancela Incrementar cuenta de plazas Ocupada El cliente ocupa ninguna
  • 46. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Descripción dinámica. Las técnicas descritas hasta ahora son sumamente útiles para sistemas cuyos estados y eventos son secuenciales. Está técnica permite describir : concurrencia y sincronización. La representación con una red de petri es una alternativa que se ajusta bien para expresar los requerimientos del procesamiento paralelo.
  • 47. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Las Redes de Petri son Grafos dirigidos con dos tipos de nodos: Estados y Transiciones . Arcos sólo pueden unir Estados con Transiciones y Transiciones con Estados
  • 48. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri El estado inicial de una red de Petri se le llama marca, esta dado por los Tokens (marcas) iniciales. Significado: Transiciones: Modelan eventos o acciones. Lugares con marca: Cumplimiento de una condición. Transición activada: Ocurrencia del evento o ejecución de la acción. L1 -Lugar con marca L2 -Lugar Transición
  • 49. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Al activarse una transición, los tokens que activaron la transición desaparecen de los lugares de entrada y se generan tokens en los lugares de salida de la transición. Transición habilitada: Existe al menos un token en cada uno de sus lugares de entrada. Estado pronto para activar la transición. L3 L2 L1 L4 L5 L3 L2 L1 L4 L5 T1
  • 50. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri Secuencia A2 A1 L3 T1 T2 A4 T3 T4 T5 Conflicto Concurrencia T6 T7 T8 T9 A5 A6 A7
  • 51. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Redes de Petri (Ejemplo) Máquina dispensadora T1-Inserta moneda E1- Tiene moneda E2- pronta T3- acepta moneda E3- pronto para dispensar T4-dispensa T2- rechaza moneda Se dispararon las transiciones: t1,t3,t4 Otra secuencia posible seria t1,t2
  • 52. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Descripción dinámica Proviene de Metodología de Análisis y Diseño Estructurado fin de la década del 70. Usados en versión original de OMT (Rumbaugh 91), no incorporados a UML. Antes de los Casos de Uso era una de las formas más usadas para describir un sistema. Elementos Proceso del sistema que recibe datos y genera otros. Archivo de datos. Flujo de Datos. Entidad Externa al sistema a modelar (actor) Proceso Datos que entran Archivo Datos que salen
  • 53. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Ejemplo: Examen Historia Clínica Médico Paciente Experiencia y conocimiento Síntomas Medicación y Diagnostico Factura Lista de exámenes y servicios brindados Contabilidad Registro Contable Paciente
  • 54. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Diagramas de Flujo de Datos (DFD) Permite visualizar cómo fluye la información por el sistema. Está asociado a una realización particular del sistema. El diagrama no es suficiente para precisar el comportamiento: por un flujo que entra a un proceso desde un archivo, ¿fluye un registro o todo el archivo?. No estipula sincronización, un flujo llega a una entidad externa y otro sale ¿Están relacionados? ¿Uno es respuesta del otro?. Se complementa con un diccionario de datos que describe: estructura de los flujos y otros detalles. los procesos (lenguaje natural estructurado) con lo que el comportamiento queda determinado. A menudo sistemas legados están documentados con DFD.
  • 55. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Casos de Uso (UML) Técnica para entender y describir requerimientos. Los casos de uso son requerimientos, describen requerimientos funcionales. Pone el acento en el uso del producto. Describen como el sistema debe comportarse desde el punto de vista del usuario. Casos de Uso como caja negra: Especifican que es lo que el sistema debe hacer sin especificar cómo debe hacerlo. Se describen mediante documentos de texto. Introducido por Ivar Jacobson (1992).
  • 56. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Casos de Uso (UML) Ejemplo: Actor: Entidad Externa que interactúa con el sistema (persona identificada por un rol o sistema externo). Caso de Uso: Conjunto de escenarios posibles que puede encarar un actor (o varios) con el sistema para el logro de cierto objetivo. Limite del Sistema Caso de Uso Reutilizable <<include>> Caso de Uso Escenario Variable <<extends>> Generalización
  • 57. Proceso: Ingeniería de Requerimientos Modelado del Sistema – Elección de una Técnica Ninguna técnica de especificación es completa. La elección de la técnica esta limitada por: Características del proyecto. Preferencia de los desarrolladores. Preferencias del cliente. Por lo general se combinan varios enfoques, por ejemplo: Una técnica para requerimientos funcionales. Otra técnica para los requerimientos no funcionales.
  • 58. Proceso: Ingeniería de Requerimientos Técnicas – Obtención y Análisis de Requerimientos Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 59. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Posibles conflictos : Balancear Recursos Tiempo Alcance Calidad Necesidades Expectativas Necesidades Expectativas Tecnología Personas Proceso Restricciones
  • 60. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Técnicas : Investigar antecedentes. Entrevistas individuales/grupales. Encuestas/Cuestionarios. Tormenta de ideas. Casos de Uso. Prototipado.
  • 61. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Investigar Antecedentes Estudio, muestreo, visitas,… Buena forma de comenzar un proyecto. Interna: Estructura de la organización, Políticas y procedimientos, Formularios e informes, Documentación de sistemas. Externa: Publicaciones de la industria y comercio, Encuentros profesionales, Visitas, Literatura y presentaciones de vendedores. Ventajas Ahorra tiempo de otros. Prepara para otros enfoques. Puede llevarse a cabo fuera de la organización. Desventajas Perspectiva limitada. Desactualizado. Demasiado genérico.
  • 62. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Entrevistas Individuales y Grupales Usar para: Entender el problema de negocio. Entender el ambiente de operación. Evitar omisión de requerimientos. Mejorar las relaciones con el cliente. Ventajas Orientación a las personas. Interactivo / Flexible. Rico. Desventajas Costoso. Depende de las habilidades interpersonales.
  • 63. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Encuesta / Cuestionario No substituye la entrevista. Antes de usar el enfoque: Determinar la información que se precisa. Desarrollar cuestionario. Probarlo con perfil típico. Analizar resultado de las pruebas. Su principal uso es para validar asunciones y obtener datos estadísticos sobre preferencias. Ventajas Conveniente para quien contesta. Respuestas anónimas. Desventajas Menos Rico. Problemas por no Respuestas. Esfuerzo de desarrollo.
  • 64. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Tormenta de Ideas Objetivo: Lograr consenso sobre los requerimientos. Ayuda a la participación de todos los involucrados. Permite pensar en otras ideas. Un secretario saca notas de todo lo discutido. Reglas: No se permite criticar ni debatir. Dejar volar la imaginación. Generar tantas ideas como sea posible. Mutar y combinar ideas.
  • 65. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Casos de Uso Formato simple y estructurado donde los usuarios y desarrolladores pueden trabajar juntos. No son de gran ayuda para identificar aspectos no funcionales. Mientras se definen los casos de uso, puede ser un buen momento para definir pantallas u otros objetos con los que el usuario interactúa. Pueden ser usados en el diseño y en el testing del sistema. Usarlo Cuando el sistema está orientado a la funcionalidad, con varios tipos de usuarios. Cuando la implementación se va a hacer OO y con UML. No son la mejor elección: Sistemas sin usuarios y con pocas interfaces. Sistemas dominados primariamente por requerimientos no funcionales y restricciones de diseño.
  • 66. Implementación parcial, permite a los desarrolladores y usuarios: Entender mejor los requerimientos. Cuales son necesarios, deseables. Acotar riesgos. Prototipo desechable : El propósito es solo establecer que algo se puede hacer, luego se parte de cero en la construcción, quedando el conocimiento aprendido. Prototipo evolutivo : Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo. Aspectos para los que es frecuente construir prototipos: Apariencia y percepción de la interfaz de usuario. Arquitectura (riesgos técnológicos, tiempos de respuesta). Otros aspectos riesgosos. Proceso: Ingeniería de Requerimientos Técnicas -Obtención y Análisis de requerimientos Prototipado
  • 67. Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos. Estudio de factibilidad Obtención y Análisis de Requerimientos Especificación de Requerimientos Validación de Requerimientos Informe de factibilidad Actividades Especificación de Requerimientos Documento de Requerimientos Modelo del Sistema Artefactos
  • 68. Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos. La validación incluye dos pasos: Asegurar que cada especificación pueda ser rastreada hasta su requerimiento en el documento de definición. Luego se chequea la definición para ver si cada requerimiento es rastreable hasta la especificación. Es importante recordar, que la validación no es tan solo un rastreo de traza. Ya que, además, pretende garantizar que el sistema hará lo que los clientes y usuarios esperan. Validando que las metas e intenciones de los usuarios y clientes están satisfechas. Una forma simple de validar los requerimientos es la realización de reuniones de revisión.
  • 69. Proceso: Ingeniería de Requerimientos Técnicas – Validación de Requerimientos Revisiones de Requerimientos Participan representantes del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus gerentes. del equipo de desarrollo: analistas de requerimientos, diseñadores, encargados de pruebas y gestión de configuración. Incluye: Revisar objetivos del sistema. Evaluar alineamiento de requerimientos con los objetivos (necesidad). Revisar el ambiente de operación y las interfaces con otros sistemas. Funciones completas, restricciones realistas. Evaluar riesgos. Considerar: Pruebas del sistema. Cambios en los requerimientos en el proyecto, su verificación y validación.
  • 70. Medición de Requerimientos La medición de requerimientos está enfoca a tres áreas: Producto, Proceso y Recursos. Los productos de los requerimientos (definición y especificación) pueden ser evaluados en primer lugar considerando el número de requerimientos . De manera similar se puede medir la cantidad de cambios introducidos a los requerimientos . Un gran número de cambios indica cierta inestabilidad o incertidumbre en la comprensión de lo que el sistema debe hacer o como comportarse. También es bueno evaluar la incertidumbre por tipo de requerimiento . Esto permite seccionar.
  • 71. Medición de Requerimientos Debido a que los requerimientos son utilizados por los diseñadores y verificadores, pueden utilizarse medidas que reflejen cuando los requerimientos están preparados para derivar a ellos. Existe un forma de evaluación utilizada para verificadores y diseñadores, donde califican los requerimientos en una escala de 1 a 5 para saber si estos están listos. La escala es la siguiente: Lo comprende por completo, ha diseñado (verificado) requerimiento similar antes y no debería tener problema. El requerimiento posee algún elemento que le resulta nuevo, pero no es radicalmente distinto de lo que ha diseñado (verificado) con éxito antes.
  • 72. Medición de Requerimientos Hay elementos nuevos que lo hacen muy diferente de los que ha diseñado (verificado) antes, pero los comprende y piensa que a partir de ellos puede desarrollar un buen diseño (prueba). Hay partes del requerimiento que no entiende bien y no está seguro de poder desarrollar un buen diseño (prueba). No comprende este requerimiento en absoluto y no puede desarrollar un diseño (prueba) para él. Si un verificador o diseñador entrega un perfil con mayoría de 1 y 2 entonces el requerimiento esta en forma y puede pasar al equipo de diseño o verificación. OK A B 1 2 3 4 5 Diseñadores Verificadores 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
  • 73. Bibliografía Software Engineering 6a. ed.– Ian Somm erville – Pearson Education – 2000.(Cap. 5 y 6) Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002. (Cap 4)