Contenido. Sistemas. Ingeniería de Requerimientos. Introducción. Definiciones. Niveles y Clasificación ERS UNPA UARG

Transcripción

1 Requerimientos de Software Ingeniería de Requerimientos UNPA UARG 2008 Contenido 1 Introducción 2 Definiciones 3 Niveles y Clasificación 4 ERS Sistemas Conjunto de componentes interrelacionados. Subsistemas. Desarrollo en paralelo. Debe hacerse revisión del trabajo Requiere de una Ingeniería de Software 1

2 Evolución de los sistemas Los sistemas tienen una larga vida, deben mantenerse. 1 Elaboración. Construcción. Puesta en Funcionamiento. 2 Generación de Información. Mantenimiento. Modificaciones: Errores en los requerimientos. Nuevos requerimientos. Cambios en el hardware. Reorganización. 3 Muerte. Retirada del producto. Datos. Capacitación. Reutilización. Procesos Organizacionales Procesos: Adquisición del Sistema Proceso de Desarrollo Proceso Operativo Adquisición Compramos o desarrollamos?? Compramos - Adaptar Requerimientos -Elegir Sistema -Emitir Peticiones de oferta -Elegir Proveedor desarrollamos - Elegir Proveedor. -Negociar Contrato -Establecer contrato de desarrollo. 2

3 Ingeniería de Requerimientos Trata de establecer lo que el sistema debe hacer, sus propiedades emergentes y sus restricciones en su funcionamiento y el proceso de desarrollo. Ingeniería de Requerimientos Clientes y usuarios Proceso de comunicación Técnico e intelectual COMUNICACIÓN Desarrolladores Influyen: -Preferencias -Prejuicios -Aversiones - Cuestiones políticas y organizacionales Principal Problema: Ingeniería de requerimientos Ingeniería de Requerimientos Es un PROCESO Descubrir Analizar Documentar Verificar 3

4 Requerimientos Para un sistema: es la descripción de los servicios proporcionados y sus restricciones operativas. Para el cliente: refleja una necesidad de un sistema que les ayude a resolver algún problema. Niveles de descripción Desde una simple declaración hasta una declaración detallada. Dos niveles de abstracción Niveles de descripción Clientes Usuarios Analistas de sistemas Requerimientos de usuario Declaraciones en Lenguaje Natural y Diagramas Requerimientos de sistema Estabecen con detalle las funciones y restricciones operativas. Contrato. Desarrolladores Usuarios Analistas de sistemas Arquitectos de sistemas Ambas descripciones son necesarias 4

5 Ejemplo: Ejemplo: RU: El sistema controlará los datos ingresados por los telefonistas. RS: El sistema deberá controlar: El nro de cliente ingresado corresponde a un cliente de la empresa y que todos los datos solicitados en el formulario del cliente sean ingresados correctamente. Clasificación de los requerimientos Los clasificamos en: Funcionales No Funcionales De dominio Requerimientos Funcionales Son declaraciones de los servicios que proveerá el sistema, de la manera en que este reaccionará a entradas particulares y de cómo se comportará en situaciones particulares. El usuario deberá tener la posibilidad de buscar un producto en la base de datos o seleccionar un subconjunto de productos. 5

6 Requerimientos Funcionales Son dependientes del software a desarrollar. Son más específicos que los requerimientos de usuario. Deben ser: Completos. Consistentes. Requerimientos No Funcionales Son restricciones de los servicios o funciones ofrecidas por el sistema. El sistema utilizará el protocolo IP para comunicarse entre las sucursales. El sistema utilizará el lenguaje de consulta SQL de Oracle. El sistema responderá las consultas de usuarios en no más de 5 segundos. Requerimientos No Funcionales Requerimientos del producto: Estos especifican el comportamiento del producto.(eficiencia, portabilidad, usabilidad). Requerimientos Organizacionales: Derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. (estándares de calidad, lenguaje de programación, documentación). Requerimientos externos: Cubre los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. (legales, éticos). 6

7 Requerimientos No Funcionales Son difíciles de verificar. Se deben expresar de manera cuantitativa, utilizando métricas que se puedan probar de manera objetiva. No existen métricas para todos los requerimientos No-Funcionales. Ej: Mantenimiento. Requerimientos de dominio Requerimientos que provienen del dominio de aplicación del sistema y reflejan las características de ese dominio. Facturación con discriminación de I.V.A. según sea la condición tributaria del cliente y de los productos. Requerimientos La clasificación no es una tarea simple. 7

8 Ejemplos: Con esta nueva plataforma estimamos llegar a nuevos socios registrados. Los clientes de la empresa exigen que se cumplan las normas I500. El cliente requiere una ayuda en linea. Para la especificación de los requerimientos deberá utilizarse el estandar IEEE 830. El sistema debe emitir el comprobante Mercadería Entregada cuando se despacha la mercadería. A cada cliente se le asignará un único número de cliente. Ejemplos: El acceso será controlado con un nombre de usuario y una contraseña. El nombre de usuario será único para cada empleado y la contraseña es de 8 caracteres, el administrador activará la cuenta, luego que el usuario se registre. El administrador también le asignará los permisos de accesos establecidos por la gerencia. Problemas de los requerimientos No son siempre obvios. Tienen muchas fuentes. No siempre es facil de expresarlos con palabras. Distintos niveles de detalle. La cantidad de req. puede ser inmanegable. Están relacionados. Hay muchos interesados. Sensibles al tiempo. 8

9 Requerimientos de usuario Desciben los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Expresan el comportamiento externo Utilización de un lenguaje natural. Requerimientos de usuario Inconvenientes de expresar en lenguaje natural: Falta de claridad. Confusión de requerimientos: No se distinguen claramente los tipos de requerimientos. Conjunción de requerimientos: Requerimientos diferentes se pueden expresar en forma conjunta en un único requerimiento. Requerimientos de usuario Recomendaciones Inventar un formato estandar y asegurar que todos los requerimientos se ajusten al formato. Utilizar el lenguaje en forma consistente: distinguir entre los requerimientos que son deseados (futuro condicional) y los obligatorios (futuro simple). Evitar lenguaje técnico. Resaltar textos. (negrita, cursiva, color). 9

10 Requerimientos del sistema Versiones extendidas de los RU. Agregan detalle y explican como el sistema debe proporcionar los requerimientos de usuario. Los Ing de Soft. Los utilizan como punto de partida para el diseño. Solo deben describir el comportamiento externo del sistema y sus restricciones operativas. No hará Diseño ni Implementación. Requerimientos del sistema Se pueden expresar en lenguaje natural: La comprensión del requerimiento dependerá que los lectores y redactores manejen el mismo lenguaje. Es demasiado flexible. Puede decir lo mismo de manera diferente. Es complejo relacionar los requerimientos. Un cambio implicará la lectura y análisis de todos los requerimientos. Requerimientos del sistema Herramientas: Lenguaje natural estructurado Lenguaje de descripción de diseño (pseudocódigo). Notaciones graficas. Especificaciones matemáticas. 10

11 El documento final RU RS ERS SRS La Especificación de Requerimientos de Software (SRS) es la declaración oficial de qué deben implementar los desarrolladores. Estructurado. Diferentes lectores. Estandarizado: IEEE IEEE Introducción: Propósito del documento Alcance del producto Definiciones Referencias Descripción General Perspectivas del producto Funciones del producto Características del usuario Restricciones IEEE Requerimientos específicos Funcionales No funcionales De dominio Es la parte más importante. No define una estructura. Es muy general, debe adaptarse. Existen otros estándares. 11

12 UNPA UARG