¡Descarga Ingeniería de requisitos y más Apuntes en PDF de Ingeniería del Software solo en Docsity!
Ingeniería de requisitos
Es difícil establecer qué debe hacer un sistema software, para ello están la descripción de los
servicios y restricciones, que son los requisitos del sistema. La ingeniería de requisitos nos
permite identificar dichos requisitos, que se identifican por:
-Requisitos de usuario, que son frases en lenguaje natural que indican qué servicios debe proporcionar el sistema y las restricciones bajos las que debe operar -Requisitos de sistema, que determinan los servicios del sistema y las restricciones en detalle. Sirven como contrato.
Hay tres tipos de requisito: -Requisitos funcionales Son los servicios que proporciona el sistema, la respuesta del sistema ante determinadas entradas, el comportamiento del sistema en situaciones particulares y en algunos casos determinan lo que no debería hacer el software. -Requisitos no funcionales Son restricciones de los servicios que ofrece el sistema(tiempo, proceso de desarrollo…) hay tres tipos: -Requisitos del producto. Especifican el comportamiento del producto: prestaciones, memoria, tasa de fallos… -Requisitos organizativos. Especifican el proceso y los procedimientos y herramientas: estándares de proceso, lenguajes de programación… -Requisitos externos. Vienen de factores externos al sistema y al proceso: requisitos legales, etc. -Requisitos del dominio Se derivan del dominio de la aplicación y reflejan características de dicho dominio, por ejemplo, capacidad de importar o exportar datos en un formato determinado, o restringir acceso a bases de datos o a tablas concretas de una base de datos…
Así esta ingeniería se centra en lo que se debe hacer y no en el cómo. Tiene diversas fases que producen distintos resultados:
Estudio de viabilidad
Se origina tras la especificación preliminar. Se estima si se puede resolver el problema con las tecnologías disponibles y si es rentable y puede desarrollarse dentro de las restricciones. El estudio debe responder una serie de preguntas: · ¿Contribuye el sistema a los objetivos de la organización? · ¿Se puede implementar con la tecnología disponible y cumpliendo las restricciones? · ¿Se puede integrar el sistema con otros de la organización?
Tras esto se determina con los interesados el dominio de la aplicación y los requisitos funcionales y no funcionales. Se considera interesado (stakeholder) a cualquier persona que pueda tener influencia directa o indirecta sobre los requisitos, como clientes, usuarios…
Esto no suele ser fácil porque muchas veces los stakeholder desconocen lo que esperan del sistema, no se conoce bien el sistema de los stakeholders, pueden tener distintos requisitos entre sí… así que el análisis de requisitos tiene un modelo espiral con cuatro fases: -Descubrimiento de requisitos -Clasificación y organización de los requisitos -Ordenación por prioridades y negociación de requisitos -Documentación de requisitos
El proceso de ingeniería de requisitos es el siguiente:
Especificación de requisitos: Se fija una descripción detallada de los requisitos, para que sirva de base para un contrato, dependiendo de la fase el proyecto los requisitos serán de negocio, usuario o de sistema. El objetivo es realizar la especificación de requisitos software (SRS). Para esto pueden usarse distintos lenguajes, como el natural, natural estructurado, de descripción de diseño, de especificación de requisitos, notaciones gráficas, especificaciones matemáticas…
Validación de requisitos: Sirve para comprobar si los requisitos se ajustan a los deseos de los stakeholders, si la validación es inadecuada los errores se propagarán, y eso tendrá una gran repercusión sobre el coste.
Hay distintos tipos de verificaciones: -Validez: comprueba la necesidad de las funciones definidas -Consistencia: Comprueba que no hay restricciones contradictorias o distintas descripciones de una restricción -Completitud: Comprueba que todos los requisitos y restricciones están incluidos -Realismo: Comprueba que se puedan implementar los requisitos con las tecnologías y plantilla disponibles -Verificabilidad: Comprueba que los requisitos se pueden verificar para evitar problemas entre clientes y desarrolladores
Y a su vez hay distintas técnicas de validación de requisitos: -Revisión de requisitos: Es un análisis sistemático hecho por un equipo de revisores -Prototipado: Se crea un modelo ejecutable del sistema -Generación de casos de prueba: Si no se pueden diseñar casos de prueba probablemente el requisito sea problemático. -Análisis automático de consistencia: Si se ha usado una herramienta formal de especificación existen herramientas automatizadas para la detección de inconsistencias.
La SRS se desarrolla durante el Análisis de Requisitos. Es la entrada a la fase de diseño, y se utiliza también en la implentación y prueba. Suele ser necesario actualizarla junto con el proyecto. Los contenidos de esta son:
Introducción:
Proporciona una descripción de la SRS, debe incluir 1-Propósito, define el propósito y los clientes, usuarios y desarrolladores 2-Alcance, identifica el producto por un nombre, explica qué hará, qué no hará, el uso, beneficios, objetivos y es consistente con el resto del SRS 3-Definiciones, acrónimos y abreviaturas, Proporciona definiciones a todos los términos. 4-Referencias, hace una lista de todos los documentos referenciados, identifica cada uno y especifica las fuentes donde se obtienen las referencias 5-Resumen, describe el resto de la SRS y explica su organización.
Descripción General:
Describe los factores que afectan al producto y sus requisitos, sin que sean requisitos específicos y proporcionando un “background” para estos requisitos haciéndolos más comprensibles. Debe incluir: 1-Perspectiva del producto, que define el contexto de implantación y las interfaces, de sistema, usuario, hardware software y comunicación, las características de la memoria, las operaciones, los requisitos de adaptación… 2-Funciones del producto 3-Características de usuario, como su nivel educativo o experiencia y capacidades en el dominio 4-Restricciones, como políticas de regulación limitaciones hardware, interacciones con otras aplicaciones, funciones de control o auditoría, requisitos del lenguaje… 5-Supuestos y dependencias, que son factores que afectan a los requisitos 6-Requisitos futuros, que son requisitos para versiones en el futuro.
Requisitos específicos:
Contienen todos los requisitos del sistema, es el núcleo de la SRS, y sus características son que debe cumplir las características de toda srs, referencia la información previa, son identificables unívocamente y deben organizarse de forma que se facilite su legibilidad, pueden organizarse por modo de sistema, clase de usuario, objetos(Del mundo real), características, estímulos, respuestas, jerarquía funcional… Se puede elegir la organización más adecuada. Deben incluir: 1-Interfaces externas, con descripción detallada de todas las entradas y salidas, debe complementar la descripción de interfaces de la descripción general, y debe incluir el nombre del elemento, la descripción del propósito, el origen de entrada o destino de salida, unidades de medida, formatos, mensajes… 2-Funciones, que definen todas las acciones fundamentales que deben tener lugar en el software, incluyendo controles de validez, respuestas ante situaciones anormales… 3-Requisitos de rendimiento, que son los requisitos numéricos estáticos de rendimiento. 4-Requisitos lógicos de la BDs, como los tipos de información, frecuencia de uso, capacidad de acceso… 5-Restricciones de diseño, impuesto por estándares o limitaciones hardware 6-Atributos del sistema software, fiabilidad, seguridad, mantenibilidad, portabilidad…
Cada requisito funcional se puede representar como un caso de UML, y a su vez cada UML puede especificarse con lenguaje estructurado y con un diagrama de actividad UML
