Desarrollar un plan de gestión de requisitos, definir líneas base de requisitos, obtener comprensión y compromiso con los requisitos, gestionar los cambios de requisitos, mantener un seguimiento bidireccional de los requisitos e identificar inconsistencias entre el trabajo del proyecto y los requisitos.

Seguimiento bidireccional de requisitos: en el seguimiento hacia adelante, en qué caso de uso se cumple el requisito original, si se cumplen todos los requisitos originales. En el seguimiento inverso, si un caso de uso no cumple con ningún requisito original, es una necesidad interesante.

Información relacionada con el dominio del problema, información relacionada con el problema a resolver, expectativas y limitaciones del usuario.

Partes interesadas, sistemas heredados, competidores, expertos en el dominio

Reunión de requisitos de discusión conjunta (discusión de varias partes), entrevistas con usuarios (los usuarios clave preparan preguntas), encuestas escritas (cuando hay muchas personas), observaciones en el sitio, lectura de documentos históricos y participación en prácticas comerciales.

Herramientas gráficas: diagrama de bloques jerárquico, diagrama de casos de uso, diagrama IPO, diagrama de Warnier

El desarrollo de requisitos es un proceso evolutivo iterativo que no es en cascada y que descompone el problema de arriba a abajo, capa por capa, y proporciona una vista lógica y una vista física del sistema.

Dibujar un diagrama de alcance de la relación entre el sistema y las entidades externas, crear un prototipo de interfaz de usuario, analizar la viabilidad de los requisitos, determinar la prioridad de los requisitos, establecer un modelo de análisis de los requisitos (modelo de caso de uso, diagrama ER, diagrama de flujo de datos). , crear un diccionario de datos y utilizar funciones de calidad para asignar

métodos de análisis estructurados

Método de análisis orientado a objetos.

Método de análisis del dominio del problema de área.

Vista lógica (cumplimiento de requisitos funcionales), vista de proceso (problemas de concurrencia), vista de componentes (problemas de implementación), vista de implementación (problemas de distribución)

Convertir los requisitos de software en estructuras de datos y estructuras de sistemas de software, completando principalmente el diseño general, incluida la división de funciones en módulos, la determinación de las funciones de los módulos y las relaciones de llamada y composición entre módulos.

De arriba hacia abajo, refinamiento gradual, ocultación de información (interfaz de operación), módulos independientes (alta cohesión, bajo acoplamiento)

Diseñe la estructura de datos y el algoritmo para cada módulo, rendimiento, tiempo de respuesta, tiempo de respuesta, rendimiento, precisión, etc.

Módulo entrante, módulo saliente, módulo de transformación, módulo de coordinación

Transformación, Transacción, Mixta

Diseñar casos de prueba de acuerdo con las especificaciones funcionales y verificar si las funciones cumplen con los requisitos, independientemente de la estructura y procesamiento del programa.

División de clases de equivalencia

análisis de valor límite

error al adivinar

diagrama de causa y efecto

Contenido de la prueba

Métodos de prueba

Combine pruebas de caja negra y caja blanca

Realizadas durante la fase de codificación, pruebas generales de caja blanca, como pruebas de función de interfaz de módulo, pruebas de estructura de datos locales, pruebas de ruta, pruebas de manejo de errores y pruebas de condiciones límite.

Se descubren errores en la etapa de diseño. Una vez ensamblados los módulos, se prueban la interfaz y la comunicación entre los módulos, generalmente pruebas de caja negra.

Verifique si las funciones y el rendimiento del software son consistentes con las necesidades del usuario, basándose en las especificaciones de demanda, pruebas de validez, revisión de la configuración del software y pruebas de aceptación (informe de análisis, manual de usuario, informe resumido de desarrollo) en un entorno simulado.

Pruebas del entorno de producción, pruebas de caja negra basadas en especificaciones de requisitos, que cubren todos los componentes conjuntos y evalúan la calidad de los productos de software.

Incluyendo software, hardware, periféricos, datos, software de soporte, etc., específicamente pruebas de recuperación, pruebas de seguridad, pruebas de resistencia, pruebas de rendimiento, pruebas de confiabilidad y pruebas de instalación.

Para el software de tipo producto, el desarrollador @ está presente y el cliente implementa la prueba, y el desarrollador b no está presente.

Propósito (evaluar las capacidades del sistema, identificar debilidades, ajustar el sistema, verificar la estabilidad y confiabilidad), tipo (pruebas de carga, pruebas de resistencia, pruebas de capacidad)

Análisis de requisitos de software, preparación del plan de pruebas de aceptación y criterios de aceptación del proyecto, diseño de pruebas y diseño de casos de prueba, construcción del entorno de pruebas, implementación de pruebas, análisis de resultados, informe de pruebas.

Intermediario--Centro de Evaluación de Software de Beijing

Análisis de requisitos: se explican posibles mejoras y modificaciones.

Fase de diseño: solución fácil de ampliar, portátil, reutilizable y orientada a objetos

Fase de codificación: anotación, calidad, orientada a objetos

Fase de prueba: si la prueba es buena, entonces el mantenimiento es bueno y todos los documentos relacionados con la prueba están disponibles;

Fase de mantenimiento: buena gestión de la configuración y documentos sincronizados.

Número de bucles (complejidad del código fuente), tamaño del software, otros factores