Tesis de último año: Comprensión y comprensión del análisis de requisitos de desarrollo de softwareAnálisis de requisitos y métodos en el desarrollo de software de aplicaciones La ingeniería de software generalmente tiene las siguientes actividades básicas: Descripción del software: definición de funciones de software y restricciones de operación del software; diseño e implementación del software: el software debe diseñarse de acuerdo con la descripción; verificación de la validez del software: debe determinarse que el software es efectivo y puede completar la aplicación esperada; evolución del software: el software evoluciona de acuerdo con los cambios en los requisitos de la aplicación; Entre ellos, el objetivo de la descripción del software es determinar qué servicios requiere el sistema de software y a qué restricciones está sujeto durante el desarrollo y la operación. La actividad de descubrir, analizar, documentar y validar servicios y restricciones ahora se conoce comúnmente como ingeniería de requisitos. Con este fin, el autor habla sobre cómo realizar análisis y métodos de demanda. 1. Proceso de requisitos La ingeniería de requisitos es una etapa particularmente crítica para el proceso de software. Los errores en esta etapa inevitablemente se trasladarán a las etapas posteriores de diseño e implementación del sistema. La fase de ingeniería de requisitos es única en el sentido de que existen pocos patrones ya preparados o documentos especializados a los que hacer referencia. Las fases posteriores pueden basarse en el trabajo anterior (al menos hasta cierto punto, derivando varios modelos relevantes), mientras se crean los resultados de la fase de ingeniería de requisitos. La ingeniería de requisitos en sí misma es un proceso que produce documentos de requisitos para describir el sistema. Por lo general, los requisitos se dividen en dos niveles en este documento: los usuarios finales necesitan una descripción de requisitos de alto nivel, mientras que los desarrolladores de sistemas necesitan una descripción más detallada del sistema. (1) Cuatro etapas principales del proceso de demanda. Estudio de viabilidad: explique si la tecnología de software y hardware existente puede cumplir con los requisitos del usuario para el nuevo sistema. Determine si el desarrollo del sistema es rentable desde una perspectiva empresarial y puede desarrollarse dentro del presupuesto. El estudio de viabilidad es preliminar y permite concluir si el sistema merece un análisis más detallado. 2. Derivación y análisis de requisitos: este es un proceso de derivación de requisitos del sistema mediante el análisis de los sistemas existentes, discusiones con usuarios potenciales y análisis de tareas. También es posible que sea necesario desarrollar uno o más modelos y prototipos de sistemas diferentes. Todo esto ayudará al analista a comprender el sistema que se describirá. 3. Descripción del requisito: La descripción del requisito determina la información recopilada durante las actividades de análisis en forma de documento. Hay dos tipos de requisitos en este documento. Los requisitos del usuario son descripciones abstractas de los requisitos del sistema de los usuarios finales; los requisitos del sistema son descripciones detalladas de la funcionalidad proporcionada por el sistema. 4. Verificación de requisitos: esta actividad verifica la implementación, coherencia e integridad de los requisitos. Durante este proceso, se pueden descubrir y corregir errores en el documento de requisitos. Por supuesto, las actividades del proceso de requisitos no son estrictamente secuenciales. El análisis de requisitos continúa durante la definición y descripción, por lo que siguen surgiendo nuevos requisitos a lo largo del proceso de ingeniería de requisitos. Así, se alternan análisis, definición y descripción. (2) Comprender mejor el requisito 1. Los requisitos del sistema de software generalmente se dividen en requisitos funcionales, requisitos no funcionales y requisitos de dominio. Requisitos funcionales: incluya una descripción de los servicios que el sistema debe proporcionar, cómo responde a las entradas y cómo se comporta el sistema en condiciones específicas. En algunos casos, es posible que los requisitos funcionales también deban establecer claramente lo que el sistema no debe hacer. En teoría, la descripción de los requisitos funcionales del sistema debería ser completa y coherente. Integral significa que se deben describir todos los servicios que los usuarios necesitan. Coherencia significa que la descripción de los requisitos no puede ser inconsistente. De hecho, para sistemas grandes y complejos, es casi imposible describir los requisitos de manera integral y consistente. Por un lado, debido a la complejidad inherente del sistema, por otro lado, debido a diferentes puntos de vista, los requisitos también pueden entrar en conflicto. Requisitos no funcionales: Restricciones a los servicios o funcionalidades proporcionadas por el sistema. Incluyendo limitaciones de tiempo, limitaciones del proceso de desarrollo, estándares, etc. Los requisitos no funcionales surgen de restricciones del usuario, incluidas restricciones presupuestarias, políticas institucionales, interoperabilidad con otros sistemas de hardware y software y factores externos como regulaciones de seguridad y protecciones de derechos de privacidad. Requisitos de dominio: este es el requisito del campo de aplicación del sistema y refleja las características de este campo. También pueden ser requisitos funcionales o requisitos no funcionales. 2. Un documento de requisitos de software, también conocido como descripción de requisitos de software (SRS), es una declaración formal de los requisitos del desarrollador del sistema. El estándar IEEE propone la siguiente estructura para los documentos de requisitos: introducción (propósito, alcance, abreviaturas, etc.), descripción general (perspectiva del producto, funciones, características del usuario, restricciones, etc.), requisitos especiales (funcionales, no funcionales, interfaz ), apéndice e índice. 2. Método (1) El dominio del problema (dominio de aplicación) se refiere a la parte del mundo real donde existen problemas. El dominio del problema es el principal objeto de investigación de los analistas de requisitos. Por ejemplo, para un sistema de control de ascensores, incluiría cualquier hardware existente (ascensores, indicadores, sensores, botones, etc.), características del edificio (número de pisos, número de huecos de ascensores), patrones de uso esperados, características del usuario, restricciones de uso. (por ejemplo, restricciones en viajes de corta distancia), etc.
En este dominio del problema, el problema puede definirse como "un sistema de control que permite un uso más eficiente de los ascensores en los edificios". Para resolver el problema, es obviamente necesario producir algunos efectos en el dominio del problema, y son estos efectos deseados los que constituyen los requisitos del software, es decir, la razón y el propósito de formular los requisitos del software. Hasta ahora tenemos argumentos preliminares. Antes de construir un nuevo sistema de software, es mejor decidir qué debería poder hacer y qué no, comenzar con el estudio del dominio del problema y obtener una descripción del problema y una declaración del efecto de su nueva solución; el sistema producirá (es decir, requisitos); determinar el comportamiento deseado de un nuevo sistema para que pueda producir los efectos deseados en el dominio del problema. (2) Análisis de requisitos: mediante el estudio del dominio del problema, obtenga una comprensión profunda de las características de este dominio y las características de los problemas que existen en él (que deben resolverse) y regístrelos. El análisis de requisitos tiene como objetivo revelar la estructura de un sistema existente (dominio del problema), mientras que el diseño interno tiene como objetivo crear la estructura de un sistema de software que aún no existe (sistema de solución). Para esta importante tarea, las características son: (1) analizar el dominio del problema y construir su modelo en lugar de resolver el sistema; el objetivo principal es comprender la naturaleza del dominio del problema y los problemas existentes en él; especificación del comportamiento del sistema (aunque sea un proceso superpuesto e iterativo). (3) Una metodología no es sólo una técnica, es una forma de resolver una tarea, que normalmente consta de un conjunto de técnicas. Para hacer un buen uso de cualquier método de análisis, se deben requerir y describir fácilmente los siguientes aspectos: (1) La estructura del dominio del problema, de acuerdo con sus subdominios y sus relaciones, las propiedades inherentes y las propiedades del subdominio del problema en términos; de datos, sintaxis y semántica; eventos y fenómenos importantes en el dominio del problema; los sistemas de solución deben desempeñar un papel en el dominio del problema; Específicamente, existen los siguientes tres métodos: 1. Análisis Estructural (SA) El Análisis Estructural (SA) es un método de análisis con una larga historia, y su evolución es sutil pero importante. Al igual que la programación estructurada, se centra en el modelado de todo el sistema del procesamiento de transacciones, el flujo de datos y las estructuras de datos de almacenamiento. El modelado incluye principalmente el modelo de flujo de datos (DFD), el diccionario de datos (DD) y el diagrama de relación entre entidades (ERD). Los prototipos utilizados en análisis estructurados son intuitivos y fáciles de entender tanto para los desarrolladores como para los clientes. Si el enfoque inicial es modelar el sistema original, esto será un fuerte apoyo para lograr el objetivo analítico básico de comprender el dominio del problema. El método estructurado es muy similar a la forma de pensar de la gente, centrándose en el proceso y los aspectos de las cosas. Es fácil comprender un nuevo dominio de problema mediante el análisis estructurado, que es adecuado para realizar requisitos de software en áreas desconocidas. 2. Análisis orientado a objetos (OOA) El método orientado a objetos era inicialmente solo un método para modelar la estructura del sistema, luego se expandió al diseño interno y ahora se usa ampliamente en la fase de análisis. La idea básica del análisis orientado a objetos es que si el modelado de clases de objetos se limita al dominio del problema de requisitos, entonces el análisis se puede llevar a cabo utilizando los principios, modelos y representaciones básicos del análisis orientado a objetos. OOA (Análisis Orientado a Objetos) no es realmente un enfoque de requisitos. El punto de partida de OOA es un documento de requisitos original, o incluso una especificación de comportamiento. El análisis del dominio del problema supuesto implícito en OOA se ha completado, es decir, el analista ya comprende qué estudiar. La verdadera esencia de OOA es el diseño de la arquitectura de alto nivel del sistema de solución, que favorece el próximo desarrollo y diseño del sistema (si se trata de desarrollo OOD). El método general de OOA es: identificar clases de objetos en el dominio del problema; definir las propiedades y métodos de estas clases; definir el comportamiento de estas clases y modelar las relaciones entre estas clases; 3. El análisis de dominio orientado a problemas (PDOA) es una tecnología nueva. PDOA enfatiza más descripción y menos modelado. La descripción se divide aproximadamente en dos partes: una se centra en el dominio del problema y la otra en el comportamiento del sistema de solución. Generalmente se recomienda tener dos documentos independientes al mismo tiempo: el primer documento contiene una descripción de las partes relevantes del dominio del problema y una lista de problemas que deben resolverse en este dominio (es decir, los requisitos); (especificación) contiene el sistema de solución indeterminada que resuelve los requisitos. Descripción del comportamiento. Entre ellos, el primer documento se genera mediante el análisis; el segundo documento se pospone para tareas de especificación posteriores. Los pasos básicos de todo el proceso del método PDOA: recopilar información básica, desarrollar un marco de problema (modelo) y establecer el tipo de dominio del problema. Bajo la guía del tipo de marco del problema, se recopila información más detallada para brindar una descripción característica relacionada con el dominio del problema. Con base en los dos puntos anteriores, se desarrolla un marco para recopilar y registrar nuevos requisitos del sistema. El encuadre del problema modela el dominio del problema en una serie de subdominios interrelacionados. Un subdominio puede ser cualquier parte del dominio del problema que pueda seleccionarse. El objetivo del encuadre del problema es obtener más información sobre el dominio del problema.