Análisis de Requisitos del Software. Universidad de Oviedo Departamento de Informática

Transcripción

1 Análisis de Requisitos del Software Universidad de Oviedo Departamento de Informática 1

2 Contenidos Introducción Técnicas para la extracción de requisitos Fundamentos del análisis de requisitos Principios de especificación Cuestiones prácticas: Tipos de Requisitos Cuestiones prácticas: Identificación de requisitos Cuestiones prácticas: Catalogación de requisitos 2

3 Introducción El análisis de requisitos del software es una tarea que establece una representación de la función y el rendimiento del software. Podemos dividirla en cuatro subfases: Extracción o determinación de requisitos Análisis de requisitos Especificación y modelización de requisitos Validación de requisitos 3

4 Técnicas para la extracción de requisitos Entrevistas Desarrollo conjunto de aplicaciones Prototipado Observación Estudio de documentación Cuestionarios 4

5 Principios del análisis de requisitos Todos los métodos de análisis y especificación de requisitos están basados en unos principios fundamentales: Dominio de la información: Debe representarse y entenderse el dominio de información de un problema Sucesos Aceptar datos de entrada Obtener datos de salida Manipular los datos Es fundamental conocer tres visiones diferentes de los datos procesados: Flujo de la información Contenido de la información Estructura de la información 5

6 Principios del análisis de requisitos (cont.) Modelización Deben definirse las funciones que debe realizar el software y debe representarse el comportamiento del mismo como consecuencia de acontecimientos externos Qué modelamos para construir el software? 1. Información 2. Funciones y subfunciones 3. Comportamiento del software 6

7 Principios del análisis de requisitos (cont.) Partición Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente) Horizontal Vertical 7

8 Principios del análisis de requisitos (cont.) Visiones esencial y de implementación Una visión esencial de los requisitos del software presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de implementación La visión de implementación de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información 8

9 Principios de la especificación 1 PRINCIPIO 1: Separar la funcionalidad de la implementación PRINCIPIO 1: Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales del sistema a varios estímulos del entorno PRINCIPIO 3: Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él PRINCIPIO 4: Definir el entorno en que va a operar el sistema PRINCIPIO 5: Crear un modelo intuitivo en vez de un diseño o modelo de implementación PRINCIPIO 6: Reconocer que la especificación debe ser tolerante a un posible crecimiento si no es completa PRINCIPIO 7: Establecer el contenido y la estructura de una especificación de manera que acepte cambios 1 R. Balzer, N. Goodman,

10 Cuestiones prácticas: Tipos de Requisitos Los requisitos pueden ser funcionales y no funcionales: Los requisitos funcionales indican características y restricciones sobre las funciones que el software debe proporcionar. Los requisitos no funcionales indican necesidades no relacionadas directamente con lo que el software hace, sino con cómo lo hace. 10

11 Cuestiones prácticas: Tipos de Requisitos (cont.) Respecto a los requisitos funcionales, se deben estudiar los siguientes tipos: Requisitos sobre la actualización de datos: características sobre las funciones que cambian la información del sistema. Debe estudiarse de qué forma y bajo qué restricciones el usuario desea que se introduzcan nuevos datos, se cambien los que ya existen o se eliminen. Requisitos sobre la estructura de la información: características de los datos que el software maneja. Requisitos sobre las consultas y los informes Requisitos sobre la interacción con otros sistemas. 11

12 Cuestiones prácticas: Tipos de Requisitos (cont.) Respecto a los requisitos no funcionales, se deben estudiar los siguientes tipos: Requisitos de rendimiento: límites al rendimiento (para aquellas aplicaciones donde existan) y volúmenes de información que el software debe tratar. Requisitos de frecuencia de tratamiento: características sobre la frecuencia con que se ejecutan las deferentes funciones del software. Requisitos de seguridad: características de control de acceso al software y copias de seguridad, entre otros relacionados con la seguridad del sistema y la información. Requisitos de comunicaciones: características de la red de ordenadores que compone el sistema y necesidades de conexión con redes externas. 12

13 Cuestiones prácticas: Identificación de requisitos Para identificar requisitos hay varias técnicas. Un método de trabajo general puede ser el siguiente: 1. Hacer entrevista 2. Contrastar las notas con las actas de otras entrevistas y la documentación que tenemos 3. Redactar el acta, enviarla y verificarla 4. Extraer requisitos de la entrevista y categorizarlos 5. Comparar los requisitos obtenidos con la versión actual del catálogo y con entrevistas anteriores 6. Actualizar el catálogo 7. Si hay discrepancias o dudas redactar un guión para los clientes y volver al punto 1 13

14 Cuestiones prácticas: Catalogación de requisitos Un catálogo de requisitos debe cumplir siempre las siguientes pautas: Los requisitos estarán claramente identificados. Para lograrlo, se recurre a cadenas o números habitualmente agrupados. Por ejemplo, RF11.3 podría ser el tercer requisito funcional del grupo 11. Los requisitos deben agruparse de manera coherente. Lo habitual es agruparlos por tipo de requisito o por subsistemas. Las agrupaciones suelen reflejarse en el identificador del requisito, como veíamos antes. También es habitual realizar subgrupos (p. ej. RNF1.2.15). Si el proyecto es grande, suele ser más cómodo agrupar los requisitos por subsistemas. A cada requisito se le debe establecer una prioridad, que indique la importancia de su implementación para el cliente. En la metodología METRICA, la prioridad se documenta con un número entre 1 y 5, siendo 1 la máxima prioridad y 5 la menor. Sin embargo, habrá requisitos para los que no tenga sentido establecer prioridades, como los de volumen de información. 14