Los requisitos en la Ingeniería de sistemas y servicios

Los requisitos en la ingeniería de sistemas y servicios Su captura, especificación y gestión José Luis Fernández Sánchez Profesor titular ETSI IndustrialesUniversidad Politécnica de Madrid [email protected]m.es Málaga,30 de Noviembre de 2015 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 2 Contenido de la presentación La importancia de los requisitos Obstáculos Problemas habituales Definiciones y tipos de requisitos Ingeniería de sistemas Ingeniería de servicios Ingeniería de requisitos La gestión de los requisitos El esfuerzo de la obtención y especificación de requisitos El futuro de los requisitos La importancia de los requisitos Los requisitos son un factor clave en el éxito o fracaso de los proyectos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 4 Los requisitos y los proyectos  Estudios de la industria de las tecnologías de la información en Estados Unidos muestran que los sistemas entregados cumplen sólo del 42% al 67% de los requisitos. 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 5 El Informe Standish (I) Razones para el fracaso de los proyectos 1. Requisitos incompletos 2. Falta de participación del usuario 3. Falta de recursos 4. Expectativas no realistas 5. Falta de apoyo de la dirección 6. Cambios en los requisitos 7. Falta de planificación 8. El proyecto se convierte en innecesario 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 6 El informe Standish (II) Los 10 factores de éxito en los proyectos: 1. Grado de participación del usuario 2. Apoyo de la dirección 3. Jefe de proyecto con experiencia 4. Objetivos de negocio claros 5. Minimizar el alcance 6. Proceso ágil de ingeniería de requisitos 7. Infraestructura estándar 8. Metodología rigurosa 9. Estimaciones fiables 10. Personal competente Obstáculos Impedimentos que dificultan hacer bien los requisitos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 8 El enfoque tradicional de la ingeniería Por ejemplo en aeronáutica, este enfoque se fundamenta en las ecuaciones matemáticas que rigen el comportamiento estructural, aerodinámico y de mecánica del vuelo de la aeronave. 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 9 La visión desde dentro hacia afuera  Orientación a la solución en lugar de orientarse a las necesidades del usuario y/o cliente  Se pone el foco en la identificación y definición de las tecnologías que resuelven el problema  La tecnología es la herramienta Definiciones y tipos de requisitos ¿Qué es un requisito? ¿Son todos los requisitos iguales? 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 17 Necesidades, expectativas y requisitos Las necesidades expresan de forma no precisa lo que quiere el cliente (también puede ser llamado “requisito en bruto”) Las expectativas representan necesidades no explícitas del cliente Un requisito es una propiedad que debe ser mostrada por un sistema desarrollado o modificado para resolver un problema en particular 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 18 Concepto de Requisito según IEEE Std. 1233 Un requisito bien formulado establece una funcionalidad o capacidad del sistema que puede ser validada, y que debe ser poseída por el sistema para resolver un problema o realizar un objetivo de negocio. Un requisito esta cualificado por “condiciones” medibles Un requisito puede estar limitado por restricciones de tipo técnico, económico, de proyecto o legales 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 19 Ejemplo de Requisito Transportar personas de Madrid a Málaga a una velocidad máxima de 300 km/h por un precio por persona menor de 75 Euros  capacidad: transportar personas de Madrid a Málaga  condición: velocidad máxima de 300 km/h  restricción: precio por persona menor de 75 Euros 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 20 Tipos de requisitos  Funcionales: Según Thayer , los requisitos funcionales describen una función que un sistema, aplicación software o componente debe ser capaz de realizar. Básicamente describen aspectos de conducta mediante transformaciones de entradas en salidas  No funcionales o de atributos de calidad: Según Thayer, los requisitos no funcionales no describen qué tiene que hacer el sistema, aplicación software o componente sino cómo tiene que hacerlo.  Restricciones: Son requisitos de tipo legal, técnico, económico u otro que limitan el espacio de posibles soluciones.  Reglas de negocio: Son requisitos relacionados con la organización o su forma de hacer el negocio. Pueden ser hechos, algoritmos de cómputo, reglas de inferencia u otras. 4 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 21 Otras clasificaciones de los requisitos  Por su nivel en el sistema:  Requisitos de alto nivel  Requisitos de bajo nivel  Requisitos derivados  Por su orientación  Requisitos de producto  Requisitos de proyecto 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 22 Ejemplos de requisitos Req. Usuario : “El usuario podrá hervir un recipiente con 10 litros de agua en 4 minutos sobre la superficie de la cocina” Req. de alto nivel: “La cocina dispondrá de un quemador de gas de 10 cm. de diámetro”. Req. de bajo nivel: “El quemador tendrá un suministro de gas a una presión no menor de 25 psi” 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 23 Requisitos derivados Los requisitos de bajo nivel se van obteniendo a partir de los requisitos de alto nivel En muchos casos aparecen “requisitos derivados” Un requisito derivado es aquel que no es trazable directamente a un requisito de nivel más alto. Un requisito derivado puede depender de una solución de diseño. Un ejemplo de requisito derivado sería la necesidad de implementar en el software un manejador de interrupciones para el procesador escogido La ingeniería de sistemas la Ingeniería de Sistemas es la disciplina que considera todos los aspectos de la resolución de un problema de ingeniería, desde su definición hasta el desarrollo de la solución. Además, se tienen en cuenta los aspectos externos y los aspectos empresariales que pueden afectar el resultado. 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 25 Descomposición de un Sistema-Jerarquía (IEEE Std 1220) 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 3232 Especificaciones de componentes y arquitectura física  Se especifica en detalle cada uno de los componentes de la arquitectura del servicio  Se identifican los diferentes nodos donde se ejecuta el servicio y la solución (protocolos) elegida para la comunicación internodos La ingeniería de requisitos Cómo capturarlos, organizarlos y especificarlos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 34 Proceso de la especificación de los requisitos Cliente Entorno Comunidad Técnica Captura de requisitos Presentar la especificación de requisitos Coleccion de requisitos Requisitos bien formulados Construir los requisitos bien formulados Organizar los requisitos Feedback tecnico Restricción Necesidad Requisito Feedback Cliente 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 35 Actividades de la ingeniería de requisitos  La ingeniería de requisitos conlleva las siguientes actividades:  Captura de requisitos  Análisis de requisitos  Especificación de requisitos  Validación de requisitos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 36 Captura de requisitos  Posibles fuentes de requisitos:  Objetivos del negocio  Dominio de conocimiento  Partes interesadas en el proyecto del sistema  Entorno operacional del sistema  La Empresa o entorno organizativo 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 37 Captura de requisitos Técnicas de captura de requisitos:  Entrevistas  Escenarios  Prototipos  Reuniones dirigidas  Observación 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 38 Análisis de requisitos Esta actividad conlleva:  Detectar y resolver conflictos entre los requisitos  Identificar las fronteras del sistema y como éste interacciona con su entorno (contexto)  Desarrollar modelos que ayuden a la comprensión del problema  Modelo de contexto  Modelos conceptuales  Flujos de datos y control  Modelos de estados  Trazas de eventos  Interacciones con los usuarios del sistema  otros 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 39 Especificación de requisitos  Organizar los requisitos  Representar los requisitos de diversas formas según la audiencia  Elaboración del documento de especificación de requisitos La gestión de los requisitos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 41 La gestión de los requisitos La gestión de requisitos es una actividad a realizar durante todo el ciclo de desarrollo. Sus objetivos fundamentales son dos: 1. Los requisitos están controlados y sirven de referencia para las actividades de ingeniería del software y dirección de proyecto 2. Los planes, productos y actividades del proyecto se mantienen consistentes con los requisitos 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 48 El futuro de los requisitos (I) Los requisitos son cada vez más importantes y más demandados en los proyectos Importancia de la mejores prácticas en su captura y especificación Los requisitos no son sólo texto sino videos, planos y modelos Se entiende que la ingeniería de requisitos es un trabajo complejo Los requisitos son un activo de la organización 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 49 El futuro de los requisitos (II) Existe una evolución de la ingeniería de requisitos donde cobra mayor relevancia su justificación a efectos de gestión del portafolio Una aproximación orientada a la persona (casos de uso, relatos o”storyboards”) dará lugar a requisitos de mayor valor. Uso de los medios sociales es decir foros, blogs y otros 30 de Noviembre de 2015 ©José Luis Fernández Sánchez 50 Referencias  Ryan, M., Wheatcraft, L., Zinni,R., Dick, J., Baksa, K., Fernandez, J.L., Smith G.R. and C. Unger. “Guide for Writing Requirements”. International Council on Systems Engineering (INCOSE). July1, 2015.  Fernandez J. L.” "Los requisitos. Un factor crítico en el éxito de los proyectos. La importancia de los modelos“. PMI Madrid Julio 2014. Enlace video en Youtube: http://www.youtube.com/watch?v=wBQ8bZIQyf0  Grant, T. “High-Value Requirements are Changing App Development and Delivery”. Forrester Research. December 2011.  IEEE Computer Society, IEEE Std 830-1998, “Recommended Practice for Software Requirements Specifications”, New York 1998  IEEE Computer Society, IEEE Std 1233, “Guide for Developing System Requirements Specifications”, New York 1998.  ISO/IEC/IEEE 29148 Systems and software engineering —Life cycle processes — Requirements Engineering. December 2011.  PMI. “Business Analysis for Practitioners: A Practice Guide” .Newton Square, PA, 2015.  Thayer R. y Dorfman M. (eds.). “System and Software Requirements Engineering”. IEEE Computer Society Press, Los Alamitos (California). 1990.  Weigert T. y Reed, R. “Specifying Telecommunications Systems with UML”. En UML for Real, L. Lavagno, G. Martin y B.Selic (eds). Kluwer Academic Publishers, Dordrecht, 2003.  Wiegers, K. and Beatty, J “Software Requirements”. Microsoft Press, Aug 2013.