¿Cuál es el proceso de análisis de requisitos?
Explique brevemente por qué es necesario el análisis de necesidades. El contenido y los pasos principales del análisis de la demanda
Las principales tareas de la fase de análisis de la demanda de la base de datos: Realizar una investigación detallada de los objetos a procesar en el mundo real (organizaciones, departamentos, empresas), etc. y a través de la comprensión del sistema original, el teléfono móvil admite los datos básicos del nuevo sistema y los procesa para determinar la funcionalidad del nuevo sistema.
El contenido principal del informe de análisis del sistema: 1. Descripción general del sistema, objetivos del sistema, alcance, antecedentes, historia y situación actual 2. Principios y tecnologías del sistema, mejoras al sistema original; del sistema Descripción de la estructura del subsistema de dominio; 4. Descripción de la función del sistema; 5. Resumen del procesamiento de datos, división de la fase de diseño y sistema de ingeniería; 6. Solución del sistema y viabilidad técnica, económica, funcional y operativa;
El proceso de análisis de requisitos de software
La tarea del análisis de requisitos de software es describir las funciones y el rendimiento del software en profundidad, determinar las limitaciones del diseño del software y los detalles de la interfaz entre el software y otros elementos del sistema. Definir otros requisitos de efectividad para el software. Al realizar un análisis de necesidades, se debe tener en cuenta que toda la información y las necesidades provienen de la perspectiva del usuario. Intente evitar la imaginación subjetiva de los analistas e intente enviar el progreso del análisis a los usuarios. Permita que los usuarios inspeccionen y evalúen sin instrucciones directas. Para lograr la precisión del análisis de la demanda. A través del análisis de la demanda, los analistas refinan gradualmente los requisitos del software, describen los dominios de datos que procesará el software y proporcionan al desarrollo de software una representación funcional y de datos que se puede transformar en diseño de datos, diseño de estructura y diseño de procesos. Una vez completado el software, las especificaciones del software desarrolladas también proporcionarán una base para evaluar la calidad del software.
Análisis detallado del análisis de la demanda
Entendido en un sentido amplio: el análisis de la demanda incluye una serie de ingeniería de la demanda que incluye la adquisición, el análisis, la especificación, el cambio, la verificación y la gestión de la demanda. En un sentido estricto, el análisis de requisitos se refiere al proceso de analizar y definir requisitos. El análisis de requisitos consiste en analizar cuáles son las necesidades de los usuarios de software. Si se invierte mucha mano de obra, recursos materiales, recursos financieros y tiempo, pero nadie quiere que se desarrolle el software, entonces toda la inversión será en vano. Si dedica mucho esfuerzo a desarrollar un software, pero al final no cumple con los requisitos del usuario y necesita ser redesarrollado, este tipo de reelaboración es desgarrador (creo que todos lo han experimentado). Por ejemplo: un usuario necesita un software para Linux, pero usted ignoró el entorno de ejecución del software en la etapa inicial del desarrollo del software, olvidó hacerle esta pregunta al usuario y dio por sentado que estaba desarrollando software para Windows. Cuando has trabajado tan duro para desarrollarlo y enviárselo al usuario, solo descubres que hay un problema. En ese momento, estás al borde de las lágrimas y quieres suicidarte con un trozo de tofu. La razón por la que el análisis de requisitos es importante es que tiene un papel direccional, estratégico y de toma de decisiones. Desempeña un papel fundamental en el proceso de desarrollo de software. Todos deben prestar suficiente atención al análisis de requisitos. En el desarrollo de un gran sistema de software, su papel es mucho mayor que el de la programación. El trabajo en la etapa de análisis de requisitos se puede dividir en cuatro aspectos: identificación, análisis y síntesis de problemas, formulación de especificaciones y revisión. Identificación de problemas: consiste en comprender el software desde una perspectiva del sistema, determinar los requisitos integrales para el sistema desarrollado y proponer las condiciones para la realización de estos requisitos, así como los estándares que deben cumplir los requisitos. Estos requisitos incluyen: requisitos funcionales (qué hacer), requisitos de rendimiento (qué indicadores se deben lograr), requisitos ambientales (como modelos de máquinas, sistemas operativos, etc.), requisitos de confiabilidad (probabilidad de que no haya fallas), seguridad y confidencialidad. requisitos y requisitos de interfaz de usuario, requisitos de uso de recursos (memoria, CPU, etc. necesarios para la operación del software), consumo de costos de software y requisitos de progreso de desarrollo, y estimación previa de los objetivos que el sistema puede lograr en el futuro. Análisis y síntesis: perfeccione gradualmente todas las funciones del software, descubra las conexiones entre los distintos elementos del sistema, las características de la interfaz y las limitaciones de diseño, analice si satisfacen las necesidades, elimine las partes irrazonables y agregue las partes necesarias. Finalmente, se sintetiza en una solución de sistema y se proporciona un modelo lógico detallado del sistema a desarrollar (un modelo de qué hacer). Desarrollar especificaciones: es decir, preparar documentos. El documento que describe los requisitos se denomina especificación de requisitos de software. Tenga en cuenta que el resultado de la fase de análisis de requisitos es la especificación de requisitos, que se envía a la siguiente fase. Revisión: evalúe la funcionalidad para determinar si es correcta, completa, clara y otros requisitos. Sólo después de pasar la revisión se podrá llevar a cabo la siguiente fase de trabajo; de lo contrario, se volverá a realizar el análisis de requisitos.
Hay muchos métodos de análisis de requisitos. Aquí solo enfatizamos el método de creación de prototipos. Otros métodos incluyen: método estructurado, método de análisis dinámico, etc. Estos métodos nunca se han utilizado y no se discutirán aquí. El método de creación de prototipos es muy importante. Un prototipo es una versión ejecutable temprana del software que implementa algunas o todas las funciones del sistema de destino. El método de creación de prototipos consiste en construir un sistema aproximado lo más rápido posible que implemente algunas o todas las funciones del sistema objetivo. Pero este sistema puede tener fallas en cuanto a confiabilidad, facilidad de interfaz u otros aspectos. El propósito de construir un sistema de este tipo es examinar la viabilidad de un determinado aspecto, como la viabilidad de un algoritmo, la viabilidad de la tecnología o si satisface las necesidades de los usuarios. Por ejemplo: para comprobar si se cumplen los requisitos del usuario, puede utilizar determinadas herramientas de software para construir rápidamente un sistema prototipo. Este sistema es solo una interfaz y luego escuchar las opiniones de los usuarios para mejorar el prototipo. El futuro sistema de destino se desarrollará sobre la base del sistema prototipo. Hay tres tipos principales de prototipos: exploratorios, experimentales y evolutivos. Exploratorio: el propósito es aclarar los requisitos del sistema objetivo, determinar las características deseadas y explorar la viabilidad de múltiples soluciones. Tipo experimental: se utiliza para evaluar si el plan es adecuado y si las especificaciones son confiables antes del desarrollo e implementación a gran escala. Tipo evolutivo: el propósito no es mejorar las especificaciones, sino construir el sistema para que sea fácil de cambiar y, en el proceso de mejorar el prototipo, evolucionar gradualmente el prototipo hasta convertirlo en el sistema final. Hay dos estrategias diferentes cuando se utiliza el método de creación de prototipos: estrategia de descarte y estrategia de adición. Estrategia de abandono: primero cree un sistema modelo con funciones simples y requisitos de baja calidad, luego modifique repetidamente este sistema para formar mejores ideas y luego diseñe un sistema final más completo, preciso, consistente y confiable. Una vez completada la construcción del sistema, se descarta el sistema modelo original. Los tipos exploratorios y experimentales entran dentro de esta estrategia. Estrategia adicional: primero construya una función con funciones simples y requisitos de baja calidad...
¿Qué contenido debe incluirse en el análisis de requisitos?
El análisis de requisitos se refiere a comprender las necesidades del usuario y analizar las funciones del software es un proceso complejo para llegar a un acuerdo con los clientes, estimar los riesgos del software y evaluar los costos del proyecto y, en última instancia, formar un plan de desarrollo. En este proceso, los usuarios están de hecho en una posición dominante. son responsables de clasificar los requisitos del usuario y preparar la base para el software futuro. Sentar las bases para el diseño. La etapa de análisis de requisitos incluye:
1. Requisitos comerciales: reflejan los requisitos objetivos de alto nivel de la organización o el cliente para el sistema y el producto, y generalmente se establecen en los documentos de definición y alcance del proyecto.
2·Requisitos del usuario: describe las tareas que los usuarios deben completar al utilizar el producto, lo cual se explica en ejemplos de uso o scripts de solución.
3. Requisitos funcionales: define las funciones de software que los desarrolladores deben implementar para que los usuarios puedan utilizar el sistema para completar sus tareas y así satisfacer las necesidades comerciales.
4. Requisitos no funcionales: describen el comportamiento mostrado al usuario y las operaciones realizadas por el sistema. Incluye los estándares, especificaciones y restricciones que debe cumplir el producto, así como los detalles específicos. y estructura de la interfaz operativa.
5. Informe de análisis de requisitos: los requisitos funcionales descritos en el informe describen completamente el comportamiento externo que debe tener el sistema de software. El Informe de análisis de requisitos juega un papel importante en el desarrollo, las pruebas, el control de calidad, la gestión de proyectos y las funciones relacionadas del proyecto.
¿Cuáles son los pasos principales del análisis de requisitos de prueba de software?
La prueba de software es la revisión final de las especificaciones de requisitos de software, las especificaciones de diseño y la codificación antes de que el software se entregue a los usuarios para su uso o puesta. en funcionamiento, es un paso clave en el aseguramiento de la calidad del software. La prueba de software es el proceso de ejecutar un programa para encontrar errores. Las pruebas de software abarcan dos etapas en el ciclo de vida del software: generalmente, después de escribir cada módulo, es necesario probarlo (lo que se denomina prueba unitaria). La codificación y las pruebas unitarias pertenecen a la misma etapa del ciclo de vida del software. Después de completar esta etapa, el sistema de software debe pasar por varias pruebas integrales, como pruebas de integración, pruebas del sistema, pruebas de rendimiento y pruebas de configuración, etc. Esta es otra etapa independiente del ciclo de vida del software, es decir, la etapa de prueba.
El propósito de las pruebas de software: 1. El propósito final de las pruebas es evitar errores y garantizar que la aplicación pueda ejecutarse de manera normal y eficiente. 2. Los buenos casos de prueba son descubrir errores que no se han descubierto hasta ahora; para descubrir errores que se han descubierto hasta ahora. Pruebas de errores no descubiertos. 4. Un buen ingeniero de pruebas no solo debe encontrar problemas, sino también ayudar a los desarrolladores a analizar los problemas. Principios de las pruebas de software: 1. "Realizar pruebas de software lo antes posible; y continuamente" como lema de los desarrolladores de software, la práctica ha demostrado que las pruebas unitarias pueden detectar problemas lo antes posible y reducir la cantidad de errores en pruebas posteriores. Junit y Jtest se pueden utilizar para ayudar en las pruebas unitarias. 2. El caso de prueba debe constar de tres partes: datos de entrada de la prueba, pasos de ejecución de la prueba y los resultados de salida esperados correspondientes. 3. Los programadores deben evitar comprobar sus propios programas. (Refiriéndose a la fase posterior de prueba del sistema, excluyendo las pruebas unitarias) 4. El diseño de los casos de prueba debe garantizar que se cubran todos los caminos posibles. Al diseñar casos de prueba, se deben incluir condiciones de entrada razonables y condiciones de entrada no razonables. Las condiciones de entrada irrazonables se refieren a condiciones de entrada críticas y anormales que pueden causar problemas. 5. Preste total atención al fenómeno de agrupación durante las pruebas. La experiencia muestra que la cantidad de errores que quedan en un programa después de la prueba es directamente proporcional a la cantidad de errores encontrados en el programa o la tasa de detección de errores. Los segmentos de programa que presentan errores deben probarse intensivamente. 6. Implementar estrictamente el plan de prueba y eliminar la aleatoriedad de la prueba. El plan de prueba debe incluir: funciones, entrada y salida del software bajo prueba, contenido de la prueba, cronograma de cada prueba, requisitos de recursos, materiales de prueba, herramientas de prueba, selección de casos de prueba, métodos y procesos de control de prueba y métodos de configuración del sistema. reglas de rastreo, reglas de depuración, regulaciones de pruebas de regresión, etc. y criterios de evaluación. 7. Se debe realizar una inspección exhaustiva de cada resultado de la prueba. 8. Guarde adecuadamente los planes de prueba, casos de prueba, estadísticas de errores e informes de análisis final para facilitar el mantenimiento. Objetos de las pruebas de software: Las pruebas de software no son simplemente equivalentes a las pruebas de programas. Las pruebas de software deben realizarse durante todo el período de definición y desarrollo del software. Por lo tanto, los documentos obtenidos en cada etapa del análisis de requisitos, diseño del esquema, diseño detallado y codificación del programa, incluidas las especificaciones de requisitos, especificaciones del diseño del esquema, especificaciones de diseño detalladas y programas fuente, deben ser todos objetos de prueba (revisión) de software.
En la verificación de la exactitud de la comprensión y expresión de los requisitos, la corrección del diseño y la expresión, la corrección de la implementación y la corrección del funcionamiento, pueden aparecer problemas en cualquier enlace en las pruebas de software. Espero que esto les sea útil.
Cómo realizar el análisis de requisitos de software
1. Concepto
La definición de requisitos incluye desde la perspectiva del usuario (el comportamiento externo del sistema), y desde la perspectiva del desarrollador (algunas características internas) para describir los requisitos.
La cuestión clave es que el documento de requisitos debe estar escrito. Una vez fui testigo de un proyecto en el que todos los desarrolladores fueron reemplazados a mitad de camino y el cliente se vio obligado a hacerlo. Siéntese con el nuevo analista de requisitos Sistema Los analistas dijeron: "Queremos hablar con usted sobre sus necesidades". La primera reacción del cliente fue: "Les he contado a sus predecesores todos mis requisitos y ahora lo único que quiero es compilar un". sistema para mí."
Sabelotodo
De hecho, los requisitos de UGG no están documentados, por lo que los nuevos analistas tienen que empezar desde cero. Entonces, si solo hay un montón de correos electrónicos, notas de reuniones o algunos basados en conversaciones fragmentadas y desorganizadas, está convencido de que comprende las necesidades del usuario, lo cual es completamente un autoengaño.
Otra definición de demanda es que la demanda es "lo que el usuario necesita y puede desencadenar un programa o sistema "Descripción del trabajo de desarrollo". Algunos expertos en análisis de requisitos han ampliado este concepto: "Las características, funciones y atributos del sistema que satisfacen a los usuarios se pueden encontrar desde fuera del sistema". El producto es cómo, en lugar de cómo se diseña y construye el producto. La siguiente definición va más allá de las necesidades del usuario a las características del sistema:
Los requisitos son especificaciones que indican lo que se debe lograr. Describe el comportamiento y las características. o atributos del sistema, es una restricción para el sistema durante el proceso de desarrollo.
No es difícil encontrarlo en las diferentes formas de definiciones anteriores: no existe un término claro e inequívoco "requisitos". los "requisitos" reales De hecho, en la mente de las personas, estas personas se refieren principalmente a los clientes, pero en general, los usuarios no pueden describir sus propias necesidades. Los analistas del sistema solo necesitan clasificar las necesidades relevantes en función de las descripciones en el propio idioma del usuario y luego. comunicarse más con los clientes. Los analistas de sistemas y los clientes deben asegurarse de que todas las partes interesadas del proyecto comprendan claramente los términos utilizados para describir los requisitos.
Cualquier requisito documentado (como la especificación de requisitos que se describe a continuación). Especificación) es sólo un modelo, una descripción.
2. La tarea del análisis de requisitos
La parte más difícil del desarrollo de un sistema de software es describir con precisión qué desarrollar. trabajo conceptual difícil Es escribir requisitos técnicos detallados, que incluyen todas las interfaces del sistema de software orientadas al usuario, orientadas a la máquina y otras. Al mismo tiempo, esta es también la parte que, si se hace mal, eventualmente causará un gran daño. El sistema y se puede modificar más tarde también es extremadamente difícil.
En la actualidad, debido a la complejidad de los productos nacionales, una empresa puede tener varios sistemas ejecutándose en paralelo y la interfaz entre ellos es. el mayor dolor de cabeza para los desarrolladores de sistemas.
Para las aplicaciones de usuario final empresarial, los sistemas de información empresarial y los productos de software como parte de un sistema más grande son obvios, pero para nosotros, los desarrolladores, sin escribir un documento de requisitos aprobado por el cliente. ¿Cómo sabemos cuándo finaliza el proyecto? ¿Cómo podemos satisfacer a nuestros clientes si no sabemos qué es importante para ellos?
Sin embargo, los requisitos de software son necesarios incluso si no son para fines comerciales. Por ejemplo, bibliotecas, componentes y herramientas que utilizan internamente los equipos de desarrollo. Por supuesto, ocasionalmente es posible que pueda llegar a un acuerdo con otros sin documentación, pero con mayor frecuencia habrá la consecuencia inevitable de reelaboraciones repetidas y el costo de la recodificación. Mucho más que el costo de reescribir un documento de requisitos, estas sangrientas lecciones están sucediendo para los desarrolladores de software nacionales.
Recientemente, conocí a un equipo de desarrollo que desarrollaba un conjunto interno de software que incluía un editor de código. Se utilizó software asistido. Desafortunadamente, después de desarrollar la herramienta, descubrieron que la herramienta no podía imprimir archivos de código fuente. Por supuesto, los usuarios esperaban tener esta función. Como resultado, el equipo tuvo que copiar manualmente el código fuente. documentos para la revisión del código. Esto demuestra que incluso si los requisitos son claros y la concepción es precisa, si no escribimos la documentación, el software no alcanzará los objetivos esperados solo por nuestra propia culpa.
En por el contrario, he visto un "error" que debe integrarse en el sistema de seguimiento.
Escribieron una descripción de requisitos de una página para una interfaz simple en el sistema. Los administradores del sistema operativo descubrieron que una lista simple de requisitos era muy útil al procesar scripts. Cuando probaron el sistema de acuerdo con los requisitos, el sistema no era solo. muy claro Todas las funciones necesarias se implementaron sin ningún error.
De hecho, los documentos de requisitos siempre han jugado un papel guía en el proceso de desarrollo.
3. Proceso de análisis de requisitos
...
El papel del análisis de la demanda y cómo realizar el análisis de la demanda
A través de la comprensión y el análisis del problema correspondiente y su entorno, proporcionar información y funciones involucradas en el problema Establecer modelos de comportamiento del sistema, refinar y completar los requisitos del usuario y finalmente formar especificaciones de requisitos. Esta serie de actividades constituye la etapa de análisis de requisitos del ciclo de vida de desarrollo de software.
El análisis de requisitos se realiza entre el sistema. El puente entre las etapas de análisis y diseño de software. Por un lado, el análisis de requisitos toma las especificaciones del sistema y la planificación del proyecto como punto de partida básico para las actividades de análisis, y las verifica y ajusta desde la perspectiva del software. el software La base principal para el diseño, implementación, prueba y mantenimiento Las buenas actividades de análisis ayudan a evitar o eliminar errores tempranos lo antes posible, mejorando así la productividad del software, reduciendo los costos de desarrollo y mejorando la calidad del software. La ingeniería es el siguiente paso. Se desarrolló con el desarrollo de las computadoras. En los primeros días del desarrollo de las computadoras, la escala del software era pequeña. El desarrollo de software se centró en la escritura de códigos y el análisis de requisitos recibió poca atención. Se introdujo en el desarrollo de software y el análisis de requisitos se convirtió en su primera etapa. Con la expansión de la escala de los sistemas de software, el análisis y la definición de requisitos se están volviendo cada vez más importantes en todo el proceso de desarrollo y mantenimiento de software. El éxito del software. La gente se da cuenta gradualmente de que las actividades de análisis de requisitos ya no se limitan a la etapa inicial del desarrollo del software, sino que abarcan todo el ciclo de vida del desarrollo del sistema. Ingeniería de requisitos (RE): se formó desde la década de 1990, la ingeniería de requisitos se ha convertido en uno de los temas de investigación más candentes. Desde entonces, el Simposio Internacional sobre Ingeniería de Requisitos (ISRE) se ha celebrado cada dos años, y la Conferencia Internacional sobre Ingeniería de Requisitos. (ICRE) se celebra cada dos años desde 1994. En 1996, Springer-Verlag publicó una nueva publicación: "Requirements Engineering" También se crearon algunos grupos de trabajo sobre ingeniería de requisitos, como RENOIR (Requirements Engineering Network of International Cooperating Research). Groups) en Europa, y han comenzado a trabajar. La ingeniería de requisitos se refiere a la aplicación de tecnologías y métodos probados y efectivos para realizar análisis de la demanda, determinar las necesidades del cliente y ayudar a los analistas a comprender y resolver problemas. el sistema objetivo. Utiliza herramientas y notaciones apropiadas para describir sistemáticamente el sistema a desarrollar, sus características de comportamiento y restricciones relacionadas, formar un documento de requisitos y respaldar las necesidades cambiantes de los usuarios. La RE se puede dividir en ingeniería de requisitos del sistema (si es para todo el sistema compuesto de software y hardware) e ingeniería de requisitos de software (si es solo para la parte pura de software). La ingeniería de requisitos de software es una disciplina que analiza y registra los requisitos del software. Descompone los requisitos del sistema en algunos subsistemas y tareas principales, asigna estos subsistemas o tareas al software y realiza una serie de análisis, diseño y estudios comparativos repetidos. El proceso de desarrollo de prototipos. convierte estos requisitos del sistema en descripciones de requisitos de software y algunos parámetros de rendimiento.
La ingeniería de requisitos es un proceso de iteración continua de definición de requisitos, documentación, evolución de requisitos y, finalmente, congelación de requisitos en función de la verificación. En la década de 1980, Herb Krasner definió el ciclo de vida de cinco etapas de la ingeniería de requisitos: definición y análisis de la demanda, toma de decisiones sobre la demanda, formación de especificaciones de la demanda, implementación y verificación de la demanda, y gestión de la evolución de la demanda. Recientemente, Matthias Jarke y Klaus Pohl propusieron un ciclo de tres etapas: adquisición, representación y verificación.
Basándose en varios puntos de vista, las actividades de ingeniería de requisitos se pueden dividir en las siguientes cinco etapas independientes:
(1) Adquisición de requisitos: a través de la comunicación con los usuarios, el sistema existente se observa y se analiza. tareas para desarrollar, capturar y revisar los requisitos del usuario;
(2) Modelado de requisitos: establecer un modelo conceptual para el sistema visto por los usuarios finales como base para los requisitos. Descripción abstracta y captura tanta semántica del mundo real como sea posible. posible;
(3) Especificaciones de requisitos de formulario: genere descripciones formales precisas de los componentes del modelo de requisitos como un contrato entre usuarios y desarrolladores;
(4) Verificación de requisitos: tomando la especificación de requisitos como ingresar, analizar la exactitud y viabilidad de la especificación de requisitos a través de ejecución simbólica, simulación o creación rápida de prototipos.
(5) Gestión de requisitos: respalda la evolución de los requisitos del sistema, como cambios de requisitos y problemas de trazabilidad; ...
¿Cuáles son los pasos del análisis de requisitos en el proceso de desarrollo del sistema?
⑴ Primero investigue la estructura organizacional
Incluyendo la comprensión de la composición departamental de la organización, las funciones de cada departamento, etc., para prepararse para analizar el flujo de información.
⑵ Luego investigue las actividades comerciales de cada departamento.
Incluyendo comprender qué datos ingresa y utiliza cada departamento, cómo procesar los datos, qué información se genera, a qué departamento y resultados de salida ¿Cuál es el formato de .
⑶Ayudar a los usuarios a aclarar varios requisitos para el nuevo sistema
Incluyendo requisitos de información, requisitos de procesamiento, integridad y requisitos de integridad.
⑷Determine los límites del nuevo sistema
Determine qué funciones las completarán las computadoras o las completarán las computadoras en el futuro, y qué actividades se completarán manualmente. Las funciones realizadas por la computadora son las funciones que el nuevo sistema debe implementar.
⑸Analizar funciones del sistema
⑹Analizar datos del sistema
⑺Escribir informe de análisis
¿Cuáles son los pasos incluidos en el proceso de análisis de requisitos en función del uso? casos
¿Necesita mi ayuda con el análisis de requisitos basado en casos de uso?