Introducción a la Ingeniería de Requisitos

Transcripción

1 Introducción a la 26/09/2013 los de Introducción a la Grupo de l Software y Bases de Datos Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla Introducción a la los de Objetivos del tema Conocer el concepto de y su terminología relacionada. Conocer los diferentes tipos de. Entender el proceso de la ingeniería de y su relación con el resto de procesos de desarrollo. 1 IR 1

2 Introducción a la 26/09/2013 Introducción a la Terminología sobre los de No hay un consenso claro sobre la terminología relacionada con los. Nosotros usaremos la misma que en CMMI-DEV* Stakeholder needs Customer Product * Ver el tema de Introducción a la l Software de IISSI. 2 Introducción a la los de Terminología sobre Stakeholder needs Stakeholder: clientes, usuarios finales, responsables TIC, cualquier persona con interés en el sistema a desarrollar (o a mantener). Las stakeholders needs son todas aquellas necesidades, expectativas, restricciones, etc. que tienen los stakeholders con respecto a (los procesos de negocio de) su organización. Puede que algunas necesidades estén por escrito en informes internos, auditorias, etc., pero la mayoría están implícitas en la mente de los stakeholders y a veces ni siquiera son conscientes de ellas. Stakeholder needs También denominadas necesidades de negocio, necesidades de usuario, necesidades de cliente, etc. 3 IR 2

3 Introducción a la 26/09/2013 Introducción a la los de Terminología sobre Customer Son las stakeholder needs una vez elicitadas y especificadas en algún tipo de documento. Deben estar expresadas en el lenguaje de los stakeholders, usando su vocabulario. Suelen estar relacionados con los procesos de negocio a los que el sistema a desarrollar debe dar apoyo. Deben estar priorizados, para poder organizar las iteraciones en el desarrollo. También denominados de cliente, de usuario, objetivos de negocio, etc. Customer 4 Introducción a la los de Terminología sobre Product Describen un sistema que debe satisfacer los customer, a los que deben estar trazados. Pueden usar un vocabulario más técnico que los de cliente. Suele empezarse por generales u objetivos del sistema a desarrollar, y luego por más detallados. Los más detallados se suelen dividir en funcionales y no funcionales. También denominados de sistema*, software, o simplemente. Product * Normalmente, cuando se habla de sistema, se incluye hardware y software. 5 IR 3

4 Introducción a la 26/09/2013 Introducción a la Terminología sobre los de Product En sistemas muy complejos, el producto puede dividirse en diferentes componentes o subsistemas, cada uno con sus product component o subsystem. En esos casos, los suelen ser muy técnicos. Product 6 Introducción a la Definiciones de los de Glosario IEEE a)una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. b)una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal. c) Una representación en forma de documento de una condición o capacidad como las expresadas en a) o en b). Norma MIL-STD-498 Característica del sistema que es una condición para su aceptación. Goguen Propiedad que un sistema debería tener para tener éxito en el entorno en el que se usará. 7 IR 4

5 Introducción a la 26/09/2013 Introducción a la los de Definiciones de Glosario IEEE a)una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. A qué tipo de b)una condición o capacidad que debe tener un sistema o un CMMI componente de un sistema para satisfacer un contrato, una norma, corresponde una especificación cada u otro documento formal. definición? c) Una representación en forma de documento de una condición o capacidad como las expresadas en a) o en b). Norma MIL-STD-498 Característica del sistema que es una condición para su aceptación. Goguen Propiedad que un sistema debería tener para tener éxito en el entorno en el que se usará. 8 Introducción a la Tipos de (de producto) los de Requisito general (objetivo) Requisito de información Regla de negocio Requisito Requisito funcional Requisito de interfaz Caso de uso Requisito (detallado) Requisito de usabilidad Requisito no funcional Requisito de seguridad Requisito de fiabilidad Restricción técnica 9 IR 5

6 Introducción a la 26/09/2013 Introducción a la los de Objetivos Son generales, de alto nivel, denominados también features o características cuando se trata de productos orientados al mercado. Enuncian una condición que deberá cumplir el sistema pero a un nivel de detalle insuficiente como para que a partir de ellos pueda implementarse una solución. Ejemplos: [ ] Icono en REM* El sistema deberá gestionar los préstamos de los libros de la biblioteca. El sistema deberá permitir a los contribuyentes realizar su declaración del IRPF a través de Internet. * Herramienta de documentación de que veremos en el laboratorio. 10 Introducción a la los de Objetivos [ ] Icono en REM* Lo habitual en sistemas medianamente complejos es que los objetivos se organicen jerárquicamente en subobjetivos a distintos niveles. Suele ser el primer nivel de que se obtienen en el proceso de desarrollo. Posteriormente se van refinando para obtener los detallados. * Herramienta de documentación de que veremos en el laboratorio. 11 IR 6

7 Introducción a la 26/09/2013 Introducción a la los de funcionales [ ] Definen los servicios que debe ofrecer el sistema a los usuarios para alcanzar los objetivos. Tradicionalmente se han documentado como párrafos de texto libre, por ejemplo: El sistema deberá imprimir, a petición de los usuarios, un listado de los préstamos cuyo plazo haya expirado al menos una semana antes de la fecha actual. Cada vez es más frecuente que gran parte de estos se expresen mediante casos de uso, especialmente en el caso de sistemas de información interactivos. 12 Introducción a la los de de (almacenamiento de) información [ ] concepto relevante Describen qué información debe almacenar el sistema para poder cumplir los generales/objetivos de nivel superior. Deben identificar el concepto relevante sobre el que se debe guardar información así como qué datos específicos relativos al concepto son importantes para cumplir los objetivos del sistema. Ejemplo: El sistema deberá almacenar la información correspondiente a los préstamos realizados en la biblioteca. En concreto: el socio que realiza el préstamo, el libro o los libros prestados, la fecha en la que se realizó el préstamo y, para cada libro prestado, la fecha de devolución prevista y la fecha de la devolución efectiva, si ésta se ha producido. datos específicos 13 IR 7

8 Introducción a la 26/09/2013 Introducción a la los de de reglas de negocio (restricciones) [ ] Definen restricciones, reglas o políticas del negocio que deben ser respetadas por el sistema a desarrollar. Ejemplos: El sistema deberá respetar la siguiente regla de negocio: no se podrán eliminar del sistema los datos correspondientes a un cliente mientras éste tenga registradas facturas pendientes de pago o pedidos pendientes de ser servidos. El sistema deberá respetar la siguiente regla de negocio: un socio de la biblioteca no puede tener en préstamo simultáneamente más de 3 libros a la vez. Suelen ser relativamente inestables, p.e. la sanción por devolución tardía o el número máximo de préstamos simultáneos en una biblioteca podría cambiar en el futuro debido a cambios en la política de la biblioteca. 14 Introducción a la los de de interfaz Definen qué interfaces debe usar el sistema cuando se comunique con otros sistemas. Ejemplos: El sistema deberá acceder al Sistema Central de Recursos Humanos a través de la Intranet corporativa mediante los servicios web XML que se describen a continuación El sistema deberá ser capaz de comunicarse con dispositivos que dispongan de interfaz inalámbrica Bluetooth. El sistema deberá permitir a sus usuarios acceder con su cuenta de Facebook. El sistema deberá publicar la actividad de los usuarios que lo soliciten en sus cuentas de Twitter. 15 IR 8

9 Introducción a la 26/09/2013 Introducción a la los de Casos de uso [ ] Son una forma de expresar funcionales en los que se describe como se usaría el sistema a desarrollar por parte de uno o más usuarios (denominados actores) para lograr un determinado objetivo. Ejemplo: Sacar dinero de un cajero automático El sistema deberá comportarse tal como se describe en el siguiente caso de uso: 1. El usuario introduce su tarjeta en la ranura del cajero automático. 2. El cajero automático solicita el PIN al usuario. 3. El usuario introduce el PIN. 4. El cajero solicita el tipo de operación a realizar. 5. El usuario selecciona la operación de sacar dinero. 6. El cajero solicita el importe. 7. El usuario introduce el importe. 8. El cajero solicita confirmación del importe. 9. El usuario confirma el importe. 10. El cajero devuelve la tarjeta al usuario. 11. El usuario retira su tarjeta. 12. El cajero imprime el recibo y proporciona el dinero. 13. El usuario retira el recibo y el dinero. 16 Introducción a la no funcionales [ ] los de Son condiciones que se le imponen al sistema a desarrollar relacionadas con aspectos principalmente de calidad: usabilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad con hardware o software, etc. Ejemplos: El sistema deberá soportar un máximo de 1000 usuarios concurrentes sin que el tiempo de respuesta medio aumente más de un 10%. El sistema deberá funcionar en ordenadores personales con sistema operativo Linux y entorno gráfico KDE. El sistema deberá funcionar en un servidor AS/400 con la siguiente configuración: 17 IR 9

10 Introducción a la 26/09/2013 Introducción a la Visión los los de Tradicionalmente se ha supuesto que la elaboración de los era responsabilidad única del cliente. Todos los procesos de desarrollo comenzaban con el análisis de unos supuestamente proporcionados por el cliente. Esta es una de las razones que han provocado los problemas identificados en los informes CHAOS. Actualmente, se asume que la elaboración de los es una responsabilidad compartida entre clientes, usuarios y desarrolladores. Esta nueva visión es la que ha llevado a definir una ingeniería de. 18 Introducción a la Problemas de comunicación los de 19 IR 10

11 Introducción a la 26/09/2013 Introducción a la Problemas de comunicación los de? Stakeholder needs Customer Product 20 Introducción a la Problemas de comunicación los de Stakeholder needs Customer Product 21 IR 11

12 Introducción a la 26/09/2013 Introducción a la los de [Hsia et al. 1993] Todas las actividades de la ingeniería de sistemas/software relacionadas con: Identificación y documentación de necesidades de clientes y usuarios. Creación de un documento que describe la conducta externa y las restricciones asociadas [de un sistema] que satisfarán dichas necesidades. Análisis y validación del documento de para asegurar consistencia, compleción y viabilidad. Evolución de las necesidades. Versiones Evaluación 22 Introducción a la los de [Christel y Kang 1992] El proceso sistemático de desarrollar mediante un proceso iterativo y cooperativo de analizar el problema, documentar las observaciones resultantes en varios formatos de representación y comprobar la precisión del conocimiento obtenido. Versiones Evaluación 23 IR 12

13 Introducción a la 26/09/2013 Introducción a la La IR en el ciclo de vida los de La IR comienza con el proyecto y continúa durante toda la vida del software. Normalmente, el esfuerzo principal en IR se realiza al comienzo del proyecto. Entregables Clientes y Usuarios Peticiones de Cambio Equipo de Desarrollo Desarrollo / Mantenimiento de Software Ingeniería de Ingeniero de 24 Introducción a la Actividades básicas de la IR los de Obtener información Elicitación de Resolver conflictos Especificar Controlar el proceso y generar baselines Documentación de Gestión de Análisis de Verificación de Identificar conflictos Identificar defectos Asegurar consistencia con intenciones de clientes y usuarios Negociación de Validación de Actividad con participación fundamental de clientes y usuarios 25 IR 13

14 Introducción a la 26/09/2013 Introducción a la Modelo de procesos de IR los de Elicitación de Información elicitada Documentación de Conflictos [resueltos] [borrador] Negociación de Conflictos [pendientes] [versionados] Gestión de [validados] Defectos Análisis de [analizados] Verificación de [verificados] Validación de 26 Introducción a la Gestión de La gestión de los se ocupa de: los de Controlar el proceso de. Generar el documento base (baseline) de. Gestionar las peticiones de cambio en los. Definir los atributos (metainformación) de los. Mantener la trazabilidad (rastreabilidad). 27 IR 14

15 Introducción a la 26/09/2013 Introducción a la Gestión de Documento base de (baseline) los de Es un documento acordado con clientes y usuarios que contiene todos los del sistema a desarrollar conocidos en la fecha del acuerdo. Cualquier petición de cambio posterior al acuerdo debe seguir el procedimiento de control de cambios acordado para el proyecto, pudiendo ser necesario una modificación en los costes, recursos y fecha de entrega inicialmente acordados. Cuanto mejor sea el documento base de, menos cambios deberían realizarse a lo largo del proyecto y la probabilidad de cumplir los plazos y presupuesto iniciales aumentaría. 28 Introducción a la los de Peticiones de cambio en los En el caso de que se generen peticiones de cambio en los, el proceso a seguir suele ser: 1. Se registra la petición de cambio (request for change). 2. Se analiza el impacto del cambio. 3. El Comité de Control de Cambios (Change Control Board), formado por clientes y desarrolladores, toma la decisión de aceptar o rechazar el cambio en función del informe de análisis de impacto del cambio. 4. Si se acepta el cambio, se revisan los acuerdos previos sobre costes, recursos y fechas de entrega, se incorporan los cambios oportunos en una nueva versión acordada del documento base de y se hace un seguimiento del cambio en el resto del desarrollo. 5. Si se rechaza el cambio, se registran las causas del rechazo y se informa a los solicitantes. Las peticiones de cambio suelen venir de clientes y usuarios con nuevas necesidades, pero también pueden venir del equipo de desarrollo por dificultades técnicas no previstas. 29 IR 15

16 Introducción a la 26/09/2013 Introducción a la Atributos de los los de Los no son únicamente el texto que describe la condición que debe cumplir el sistema a desarrollar. Los atributos habituales de los son: identificador único (imprescindible para rastreabilidad) versión y fecha autores fuentes (de información) dependencias (trazas) prioridad (importancia y urgencia) estado (borrador, analizado, verificado, ) estimación de estabilidad comentarios etc. En función de las necesidades del proyecto, se pueden usar otros atributos (coste, dificultad, etc.). 30 Introducción a la Rastreabilidad de los los de La rastreabilidad, también denominada trazabilidad (traceability), es una propiedad que permite conocer las dependencias entre los distintos artefactos que se van generando durante el desarrollo, incluyendo los. Cada vez que se crea un nuevo artefacto (un objetivo, un, un elemento de modelado, un módulo, un fichero de código fuente, una prueba, etc.) se debe registrar de qué elementos de nivel superior y de su mismo nivel depende. Es la única forma de poder realizar un análisis de impacto cuando se solicita un cambio. Cuando se produce un cambio en un artefacto, todos los que dependen de él, tanto directa como indirectamente, están expuestos a posibles cambios. 31 IR 16

17 Introducción a la 26/09/2013 Introducción a la los de Propiedades deseables de los documentos de (I) Comprensible por clientes, usuarios y desarrolladores. Correcto, sin innecesarios o redundantes. No ambiguo y con el nivel de precisión necesario. Completo, que no falten y que todas las respuestas del sistema a entradas tanto válidas como inválidas estén especificadas. Consistente, sin conflictos ni contradicciones entre los o con documentos de nivel superior y con una terminología única. Verificable, que pueda comprobarse que el sistema final cumple los mediante un proceso finito y de coste razonable. 32 Introducción a la los de Propiedades deseables de los documentos de (II) Fácilmente modificable, organizada, con los identificados y con control de configuración. Rastreable, de forma que se conozcan las dependencias de los hacia detrás y hacia delante. Priorizada, indicando la importancia de los. Anotada con estabilidad, para conocer posibles fuentes de cambios durante el desarrollo. Independiente del diseño y la implementación, para evitar complejidades innecesarias y no limitar a los diseñadores. 33 IR 17