Requisitos Ing. Maribel Valenzuela Beltrán 1

¿ Que son los requisitos de software ? La ingeniería de requisitos es el proceso en el que se establecen los servicios del sistema que requiere el cliente y las restricciones bajo las cuales será desarrollado y operará Los requisitos son la descripción de los servicios y restricciones del sistema generados durante la ingeniería de requisitos Diferentes niveles de abstracción Para un bosquejo del contrato puede estar abierto a la interpretación Para el contrato debe estar definido a detalle 2

Tipos de requisitos Requisitos de usuario Enunciados en lenguaje natural más diagramas de los servicios que debe proveer el sistema y sus restricciones de operación. Escrito para los clientes Requisitos del sistemas Un documento estructurado con descripciones detalladas de los servicios del sistema. Escrito como un contrato entre el cliente y el contratista Especificación de software Una descripción detallada del software que puede servir como base para el diseño e implementación. Escrito para los desarrolladores

Lectores de requisitos

Requisitos funcionales y no funcionales Establecimiento de los servicios que debe proveer el sistema, como debe reaccionar a entradas particulares y como debe comportarse bajo situaciones particulares Requisitos no funcionales Restricciones sobre los servicios o funciones ofrecidas por el sistema tales como restricciones de tiempo, restricciones en el proceso de desarrollo, normas, etc.

Imprecisiones en los requisitos Los problemas aparecen cuando los requisitos no se establecen de manera precisa Los requisitos ambiguos pueden ser interpretados de diferente manera por desarrolladores y usuarios Consideremos el término ‘vistas apropiadas’ Usuario – vistas especiales para cada tipo de documento Desarrollador – proveer vistas textuales que muestren el contenido del documento de forma precisa

Completud y consistencia En principio, los requisitos deben ser completos y consistentes Completos Deben incluir descripciones de todas las opciones requeridas Consistentes No debe haber conflictos o contradicciones en la descripción de las opciones del sistema

Los requisitos y el diseño En principio, los requisitos deben establecer lo que el sistema hará y el diseño debe describir como lo hará En la práctica, los requisitos y el diseño son inseparables Debe diseñarse un arquitectura del sistema para estructurar los requisitos El sistema puede inter operar con otros sistemas. Esto restringe el diseño y genera requisitos El uso de un diseño específico puede ser un requisito

Problemas durante el análisis de requisitos Los participantes no saben realmente lo que quieren Los participantes expresan los requisitos en sus propios términos Los diferentes participantes pueden tener requisitos en conflicto Algunos factores organizacionales y políticos pueden influenciar los requisitos del sistema Los requisitos cambian durante el proceso de análisis. Pueden surgir nuevos participantes y cambiar el ambiente del negocio

Validación de requisitos Consiste en demostrar que los requisitos definen el sistema que el cliente realmente desea Los errores en los requisitos tienen un costo alto, por eso es tan importante la validación Corregir un error de requisitos cuesta 100 veces más que corregir un error de implementación

Verificación de requisitos Validez - ¿ el sistema provee las funciones que mejor apoyan las necesidades del cliente ? Consistencia - ¿ existen conflictos en los requisitos ? Completud - ¿ se incluyen todas las funciones requeridas por el cliente ? Realismo - ¿ pueden implementarse los requisitos dentro del presupuesto y con la tecnología disponible ? Verificable - ¿ pueden ser verificados los requisitos ?

Revisiones de requisitos Se deben llevar a cabo revisiones periódicas mientras se realiza la definición de requisitos Debe involucrarse personal del cliente y del contratista en las revisiones Revisiones: Verificable - ¿ se puede probar realmente el requisito ? Comprensible ¿ se entiende bien el requisito ? Rastreable - ¿ se establece claramente el origen del requisito ? Adaptable - ¿ puede cambiarse el requisito sin tener un gran impacto en los otros requisitos ?

Administración de requisitos La administración de requisitos es el proceso de administración de los cambios a los requisitos durante los procesos de ingeniería de requisitos y desarrollo del sistema Los requisitos son incompletos e inconsistentes inevitablemente Pueden emerger nuevos requisitos durante el proceso como consecuencia de los cambios en las necesidades del negocio y el mejor entendimiento del sistema Los diferentes participantes tienen diferentes requisitos y estos son frecuentemente contradictorios

Seguimiento El seguimiento se refiere a las relaciones entre los requisitos, sus fuentes y el diseño de sistemas Seguimiento de la fuente – Enlaces de los requisitos a los participantes que los propusieron Seguimiento de requisitos – Enlaces entre requisitos dependientes Seguimiento de diseño – Enlaces de los requisitos al diseño

Problemas en el análisis de un SI

Escenarios Los escenarios son descripciones de cómo es utilizado un sistema en la práctica Son útiles en la obtención de requisitos ya que la gente puede entenderlos mejor que los enunciados abstractos Los escenarios son particularmente útiles para agregar detalles a la descripción de un requisito

Casos de uso Los casos de uso son una técnica basada en escenarios, la cual identifica a los actores en una interacción y describe la interacción misma Un conjunto de casos de uso pueden describir todas las interacciones posibles con el sistema Los diagramas de secuencia pueden ser utilizados para agregar detalles a los casos de uso al mostrar la secuencia de procesamiento de eventos en el sistema