¿Cómo revisa un supervisor las especificaciones de requisitos? Si quieres comer frutos secos, primero debes romperles la cáscara. Es difícil controlar el alcance de los requisitos durante la etapa de requisitos. Si no se maneja bien, dará lugar a disputas entre el propietario y el contratista, e incluso el proyecto será interminable y no podrá ser aceptado. Porque durante la aceptación del proyecto, a menudo se determina si el proyecto cumple con los requisitos de alcance en función de los documentos de licitación, los documentos de licitación, los contratos de desarrollo y los documentos de resultados de la demanda. A menudo, los documentos de licitación no especifican el alcance de las necesidades de los usuarios y el contrato tampoco es claro. Si el documento de resultados de requisitos está mal redactado, el propietario pensará que las funciones requeridas no se han implementado durante la ejecución de prueba del proyecto, y el contratista pensará que el usuario no presentó los requisitos al principio, pero luego continuamente. modificó y complementó los requisitos, y el proyecto nunca será aceptado. Para resolver este problema, los supervisores deberían desempeñar un papel importante. Las sugerencias son las siguientes: 1. Controlar el método de desarrollo de software favorece la adquisición de requisitos: seleccionar el método de desarrollo de acuerdo con la complejidad del proyecto y la situación básica de informatización del propietario. Si la complejidad es alta y la base de información del propietario es débil, se puede elegir el método del prototipo. Si el tiempo es escaso y el contratista tiene experiencia, se pueden elegir métodos ágiles. En segundo lugar, orientar hábilmente el uso de las especificaciones de requisitos del usuario, coordinar y asesorar a propietarios y contratistas. Al realizar una encuesta de demanda, resuma el "cuestionario de demanda" para formar una especificación de demanda del usuario para definir el alcance del desarrollo y los requisitos del objetivo de desempeño. Se recomienda que el departamento comercial del propietario firme y confirme sus necesidades comerciales y acuerde el alcance del. el cambio es razonable, como 10%-15%. Si está dentro de este alcance, forme actas de reuniones o memorandos para que todas las partes los respeten. En tercer lugar, basándose en las especificaciones de requisitos del usuario, verifique y revise el alcance de desarrollo de las especificaciones de requisitos. Esta sección explica principalmente la integridad de la forma y el contenido. Solo cuando la forma y el contenido cumplen con los requisitos se puede considerar una especificación de requisitos calificada. Primero, la forma es perfecta, incluida una portada perfecta, información clara de control de versiones, capítulos razonables, concisión, precisión, profesionalismo, sin redundancia e imágenes y textos ricos, etc. En segundo lugar, el contenido es completo, incluida la introducción (incluido el propósito, el alcance, los objetos de lectura, los materiales de referencia, las abreviaturas, las abreviaturas, las leyes y regulaciones relevantes, etc.), los requisitos no funcionales (incluidos la confiabilidad, la seguridad, la usabilidad y la facilidad); de uso, etc.) escalabilidad, mantenibilidad, portabilidad, etc.); los requisitos de la interfaz, las restricciones y otros documentos están razonablemente estructurados, incluido el entorno operativo, el modo de funcionamiento, el manejo de fallas, los requisitos de respaldo, la velocidad de respuesta, el tráfico, la frecuencia, etc. Un principio a comprender es: no te pierdas ningún elemento. Centrarse en niveles superiores: comprender los tres elementos de la especificación de requisitos es la primera clave para la auditoría. Primero, debemos comprender el impacto del uso de métodos estructurados, métodos orientados a objetos y arquitectura SOA en el desarrollo de software sobre las especificaciones de requisitos. Además de comunicarse con los usuarios, la especificación de requisitos sirve como base para que los supervisores controlen el proyecto y los evaluadores como base para las pruebas. También es una base y guía de trabajo para los diseñadores. Si el método de desarrollo está estructurado, entonces el "flujo de negocios", el "flujo de datos" y el "diccionario de datos" en la especificación de requisitos se han convertido en sus tres elementos indispensables. Están entrelazados y se refuerzan mutuamente. 1. Diagrama de flujo comercial: debe ser coherente con el negocio real del usuario y expresarse claramente con gráficos estándar que sean fáciles de entender para los usuarios. Si es complicado, debe expresarse en capas de subgráficos. El principio es simple y el negocio es fácil de entender. El segundo es el diagrama de flujo de datos: primero corresponde al diagrama de flujo de negocios uno a uno, y luego las tablas de entrada o salida involucradas deben dibujarse claramente y las tablas deben dividirse razonablemente sin redundancia. Presta atención a la expresión al aplicar capas. 3. Diccionario de datos: en realidad, son los elementos de datos correspondientes en las tablas de entrada y salida del diagrama de flujo de datos. Lo que hay que explicar es indicar el tipo requerido o la longitud de palabra del elemento de datos. En el caso de un enfoque orientado a objetos, no existe un límite claro entre los requisitos y el diseño debido a su naturaleza iterativa y fluida. Por lo tanto, al revisar la especificación de requisitos, se deben utilizar al menos diagramas de casos de uso, diagramas de secuencia, diagramas de clases, etc. , y la información a expresar debe captar la equivalencia entre los tres elementos del método básico y estructurado. Si la situación es más compleja, debe haber un diagrama de estado, que se describe brevemente de la siguiente manera: Diagrama de casos de uso: puede reflejar claramente roles y casos de uso, y generalmente puede corresponder a los principales elementos funcionales del proceso de negocio. Diagrama de secuencia: verifique la granularidad del diagrama de secuencia, que básicamente corresponde a procesos de negocio y procesos de datos. Describe el proceso en orden cronológico, que también puede ser reemplazado por un diagrama de colaboración espacialmente secuencial. Diagrama de clases: el diagrama de clases describe principalmente elementos de datos, que pueden corresponder a un diccionario de datos de un método estructurado, pero está más cerca de la naturaleza y más adaptable a los cambios. Enfoque 2: Es particularmente importante centrarse en las interfaces y la seguridad. Las interfaces y la seguridad son el foco y las dificultades del desarrollo de software. Si no se maneja adecuadamente, se colocará una bomba de tiempo para el proyecto. Incluso si lo evitas temporalmente, la contradicción pronto quedará al descubierto. Captar estas dos direcciones basándose en la situación real del proyecto es también el foco de la supervisión y auditoría.