Introducción al Análisis de Requerimientos: Arquitectura Charla (2) Requerimientos No Funcionales

En el artículo anterior, introduje brevemente el concepto de arquitectura y el proceso de diseño de la arquitectura, e introduje brevemente el contenido del análisis de requisitos,
y finalmente señalé: el resultado del análisis de requisitos debe incluir requisitos no funcionales, requisitos no funcionales comunes como sigue:

• velocidad de finalización de la tarea
• La precisión del resultado.
• seguridad operativa
• capacidad del producto
• rango de valores permitidos
• Rendimiento, como tps
• eficiencia en el uso de recursos
• fiabilidad
• Tolerancia a fallas y robustez
• Escalabilidad
• escalabilidad

La parte roja es el enfoque clave de los proyectos comunes (Nota: varía según los antecedentes del proyecto, por ejemplo, lo más importante de los productos de seguridad es la seguridad).
Para un proyecto, los requisitos no funcionales más altos representan una mayor complejidad del sistema y una mayor entrada de costos (costo de tiempo, costo de mano de obra, hardware y costo de mantenimiento), que deben basarse en la empresa/proyecto/mano de obra/entorno. Evaluación integral de los factores de fondo.

requerimientos no funcionales

La salida de requisitos no funcionales después del análisis de requisitos debe ser cuantificable, y los requisitos básicos son:

• Los requisitos no funcionales deben ser inequívocos, comprensibles y comprobables.
• Los estándares son lo primero, de lo contrario no habrá base para el diseño, la implementación o las pruebas.
• Todos los requisitos son medibles y la escala de medida es la unidad utilizada para probar la conformidad del producto.

Como arquitecto, lo más importante a lo que debe prestar atención son los requisitos no funcionales: los requisitos que no se pueden medir no son requisitos reales.

• Las métricas se definen de la siguiente manera:
  • Se refiere al proceso de evaluación de la calidad y el rendimiento del software a través de la recopilación y el análisis de datos durante el desarrollo del software.
    Este proceso puede ayudar al equipo de desarrollo a comprender el status quo del software, el progreso del desarrollo, descubrir problemas y riesgos potenciales, realizar evaluaciones cuantitativas del software y formular medidas de mejora.

Ejemplos de requisitos no funcionales no válidos:

• Se debe admitir una alta simultaneidad: ¿Se espera que el sistema sea simultáneo con 1000 usuarios o 10 000 usuarios?
• La respuesta de la interfaz debe ser lo más rápida posible: ¿tiempo de respuesta aceptable de 100 milisegundos? 200 milisegundos? O 1 segundo? ¿Es aceptable que el 5% de los usuarios supere 1 segundo?

A continuación se presentan los conceptos de estos requisitos no funcionales uno por uno, así como algunas métricas.Estas métricas deben evaluarse y recopilarse durante el diseño de la arquitectura para evaluar la situación actual del sistema y las futuras direcciones de optimización.

1. La velocidad a la que se completa la tarea

• Explicación:
  es decir, rendimiento/eficiencia, que generalmente se refiere a la eficiencia de "tiempo/espacio" del software, no solo a la velocidad de ejecución del software.
• Métrica:
  • Tiempo de respuesta (tiempo medio/tiempo máximo/tiempo percentil 95)
  • uso de CPU
  • tasa de aciertos de caché
  • Tiempos de E/S/duración de E/S (E/S de disco/E/S de red)
  • Número máximo de conexiones/concurrencia
• Ejemplo:
  El tiempo máximo de respuesta para una operación de un solo usuario no debe ser superior a 2 segundos,
  el producto debe leer el valor del sensor cada 10 segundos,
  el sistema debe identificar si una aeronave es un ejército enemigo o amigo en 0,25 segundos;
  después de actualizar la configuración de la nube, el producto debe actualizarse a la configuración más reciente y completar la actualización en 1 minuto.
• Ejemplo de datos:
  una CPU de 2,5 GHz, cada ciclo de reloj de la CPU es de 0,4 nanosegundos,
  suponiendo que cada ciclo de reloj de la CPU es de 1 segundo, los datos de comparación del consumo de tiempo de computadora común y el consumo de tiempo de ciclo de reloj relativo de 1 segundo son los siguientes: Resultados de la comparación Sigue
  
  siendo impactante, jaja.
• La memoria es 200 veces más rápida que la velocidad de la red de un gigabit, por lo que cuando pueda usar la memoria caché, no considere Redis;
• El cambio de contexto también consume rendimiento de la CPU, así que no considere la posibilidad de subprocesos múltiples para tareas con pocos IO;
• Reemplace el disco duro SSD lo antes posible;
• Cuando realice una alta disponibilidad en los centros de datos, intente asegurarse de que cada centro tenga un conjunto completo de servicios para garantizar el acceso mutuo en el mismo centro de datos.

2. La precisión del resultado

• Explicación:
  generalmente se refiere a los requisitos de precisión de los resultados de salida del software (como resultados de cálculo, resultados de medición, resultados de análisis de datos, etc.).
• Métricas:
  Su estándar de medida es el tamaño del error entre el valor de salida y el valor real.
• Nota:
  La precisión del resultado generalmente no se refleja particularmente en la mayoría de los sistemas, pero en algunas industrias, la precisión es un indicador particularmente importante:
  • Sistema bancario: Si bien el interés que el banco le da al usuario es exacto al centavo, el cálculo interno debe tener una precisión de al menos centímetros, o incluso más, para garantizar que el resumen de datos sea correcto;
  • Sistema de conducción automática: la importancia del sistema de conducción automática para la precisión es obviamente extremadamente alta. Ya sea que la distancia entre los obstáculos y el automóvil se juzgue precisa o no, y para evitar errores de apreciación de los obstáculos, como imágenes fantasma, etc.
    Por lo general, la precisión se indica mediante un intervalo de rango, como ±1 cm
• Nota:
  Se recomienda utilizar el almacenamiento de enteros para todo el almacenamiento y los cálculos que involucren cantidades. Por ejemplo, para los cálculos ordinarios de RMB, al escribir en la base de datos, escriba en centavos; los cálculos de tasa de interés mencionados anteriormente se pueden escribir en la base de datos y la memoria
  en cálculos de centímetros para evitar problemas de precisión decimal que vienen con problemas binarios.

3. Seguridad de operación

• Explicación:
  se refiere a la capacidad de proteger un sistema contra el acceso accidental, la destrucción y el mal uso. Incluyendo: autenticación y autorización, control de acceso, protección de datos, seguridad de la comunicación, registro de seguridad, auditoría periódica, etc.
  Principalmente a través de la revisión del programa y casos de prueba para confirmar, tales como:
  complejidad de la contraseña, seguridad del algoritmo de verificación en dos pasos, permisos de roles y políticas de control de acceso, etc., evaluación del programa de protección de cifrado de datos, frecuencia e integridad de respaldo, programa de recuperación de desastres, comunicación cifrado Intensidad, integridad y confidencialidad de los registros de auditoría, frecuencia y profundidad de las auditorías de seguridad
• Observación:
  • Se debe tener muy en cuenta la fuerza del cifrado. Por ejemplo, MD5 convencional con sal no es lo suficientemente seguro. Una mejor manera es:MD5( MD5(明文+用户特定盐值1) + 用户特定盐值2）
  • Cuando los datos que involucran la cantidad se escriben en la base de datos, se debe agregar un campo de verificación, que se obtiene mediante el cálculo de hash y sal en función de todos los campos de la fila. Al usarlo, el campo debe verificarse. Si lo
    hace no coincide, la transacción debe prohibirse para evitar la manipulación interna de los datos por parte de los empleados;
  • Para los sistemas con altos requisitos de seguridad, se debe implementar un servicio de cifrado y descifrado independiente, y se debe pasar la ID de usuario + los datos de origen. El servicio obtiene una clave de cifrado específica basada en la ID de usuario y devuelve los datos cifrados;
  • Toda visualización/operación de datos confidenciales debe autenticarse dos veces; todas las exportaciones de datos deben insensibilizarse;
  • Las líneas de productos con altos requisitos de seguridad deben aislarse de otras redes de líneas de productos para evitar ataques a este producto desde la intranet a través de otras vulnerabilidades del producto.

4. Capacidad del producto

• Explicación:
  por lo general, se refiere a los requisitos de capacidad de datos del software dentro de un cierto período de tiempo.
• Métricas:
  salida de acuerdo con los requisitos del software, como el número de usuarios registrados, el tamaño de los archivos almacenados
• Ejemplo:
  el sistema puede admitir 10 000 usuarios registrados en un mes y 100 000 usuarios registrados en un año;
  el almacenamiento S3 puede admitir 100 000 archivos/100 GB en un mes y 1000 millones de archivos/5 PB en un año.

5. Rango de valores permitidos

• Explicación:
  Durante el uso del sistema de software, el alcance de algunos datos de entrada es limitado.
• Ejemplo: la
  longitud máxima del nombre del usuario,
  el monto mínimo y máximo de la transacción, por ejemplo, el precio del menú de un restaurante no puede exceder los 10,000 yuanes

6. Rendimiento

• Explicación:
  Generalmente se refiere a la cantidad de datos transferidos por el software por unidad de tiempo.
• Métrica:
  • TPS: transacciones por segundo (la cantidad de transacciones por segundo transmitidas)
  • QPS: Queries Per Second (consultas por segundo)
    puede entenderse como agregar un QPS una vez que el servidor recibe una solicitud.
    Suponga que abre la página de inicio del sitio web e inicia 3 solicitudes al servidor: página de inicio, estado de inicio de sesión, lista de noticias,
    en este momento TPS más 1, QPS más 3
  • RT: Tiempo de respuesta (tiempo de respuesta para cada solicitud)
  • Número de concurrencia: el número de solicitudes procesadas por el sistema al mismo tiempo.
    Por ejemplo, si un servicio recibe 100 solicitudes y aún no procesa ninguna respuesta, entonces la concurrencia es 100 en este momento.
    Muchos artículos dicen que el número de concurrencia = QPS * tiempo de respuesta promedio, que en realidad es inexacto Sí, estos son dos indicadores de rendimiento diferentes,
    de hecho: cuanto mayor sea la concurrencia, más largo puede ser el tiempo de respuesta, y el QPS será de hecho más pequeño,
    pero estos indicadores de rendimiento se ven afectados. por el estado del servidor, el estado de la red, el disco, etc., y no se pueden convertir directamente entre sí.
• Ejemplo:
  el TPS del sistema de pago alcanza más de 4000,
  el TPS del sistema de centro comercial alcanza más de 2000 y el QPS alcanza más de 10,000,
  el número concurrente del sistema de marketing alcanza más de 10,000 y
  el RT del la API del sistema de pedidos está dentro de los 100 ms

7. Eficiencia en el uso de los recursos

• Explicación:
  por lo general, especifique el uso, la tasa de ocupación y la versión de componentes de hardware específicos, como CPU con 4 núcleos o más, memoria con 16 G o más; se requiere ancho de banda Gigabit.
• Métrica:
  • tiempo de uso de la CPU
  • uso de memoria
  • Espacio del disco
  • Valor medio de IO, valor máximo, volumen total de datos transmitidos, etc.
  • La unidad de tiempo TPS puede ser procesada
• Explicación:
  a través de un buen diseño de arquitectura y una mejor implementación de algoritmos, se puede optimizar la eficiencia del uso de recursos.
  Cuando la máquina no se puede expandir horizontalmente en escenarios especiales, se puede optimizar simplemente actualizando la configuración de hardware de una sola máquina.

8. Confiabilidad

• Explicación:
  Se refiere a la capacidad del producto para completar la función predeterminada dentro del tiempo especificado y bajo las condiciones especificadas.
• Métrica:
  • MTBF: el nombre completo es Mean Time Between Failure, es decir, el tiempo medio entre fallos.
  • MTTR: ​​el nombre completo es Mean Time To Repair, es decir, el tiempo promedio de recuperación de fallas.
  • MTTF: el nombre completo es Mean Time To Failure, es decir, el tiempo medio entre fallos.
  • 可用性Disponibilidad=Tiempo activo/(Tiempo activo+Tiempo inactivo)=MTBF / (MTBF + MTTR)
• Ejemplo:
  el tiempo promedio sin fallas del servicio debe ser superior al 99,9 %, y una tasa de error de solicitud superior al 1 % en 5 minutos se considera una falla.
• Nota:
  • Algunos artículos dicen que MTBF = MTTF + MTTR.En
    mi opinión, MTBF es el tiempo medio entre fallas, que se refiere al tiempo promedio para que el sistema funcione normalmente, y MTTR no debe incluirse.
  • MTTF se refiere a cuánto tiempo el sistema puede funcionar normalmente antes de que ocurra una falla. Cuanto mayor sea la fiabilidad del sistema, mayor será el tiempo medio entre fallos.
    Más tarde, escribiré un artículo sobre el tema para presentar la confiabilidad y la usabilidad.

9. Tolerancia a fallas y robustez

• Explicación:
  Se refiere a la capacidad de procesamiento y estabilidad del sistema ante errores y situaciones anormales.
• Métricas:
  generalmente medidas por las restricciones de especificación de desarrollo, la calidad de la inspección del código, la revisión del diseño
  y la evaluación de datos, como la cantidad de fallas del sistema y las estadísticas del registro de errores.
• Ejemplo:
  cuando el usuario ingresa cualquier dato, el sistema puede procesarlo normalmente o generar un error, y no fallará ni generará una respuesta de error y generará datos incorrectos.
  Cuando el sistema falla, puede registrar información anormal para solucionar problemas y puede responder de manera efectiva a los usuarios (degradación del servicio)

10. Escalabilidad

• Explicación:
  Sin cambiar el sistema, ajuste la capacidad del sistema para manejar negocios simplemente ajustando la configuración/adición o sustracción de servidores.
• Métrica:
  • Tiempo de respuesta: a medida que aumenta el número de usuarios/aumenta el número de solicitudes, ¿aumenta el tiempo de respuesta en consecuencia?
  • Número de respuestas de error: aumenta el número de usuarios/aumenta el número de solicitudes, y si las respuestas de error aumentan en consecuencia, como tiempos de espera, errores de red, errores de limitación de corriente, etc.
• Ejemplo:
  en el caso de un crecimiento uniforme del tráfico, puede expandir automáticamente la capacidad para lograr la disponibilidad del servicio sin afectarlo;
  en el caso de una disminución del tráfico, puede reducir automáticamente la capacidad para reducir los costos y la disponibilidad del servicio no se ve afectada;

11. Escalabilidad

• Explicación:
  cuando se agregan nuevos productos o necesidades, la capacidad de lanzar nuevos productos de manera transparente sin afectar los productos existentes.
• Ejemplo:
  el sistema es compatible con la versión azul-verde, la versión continua y la versión en escala de grises.

conocimiento de referencia

Para los requisitos no funcionales, ya existen muchos estándares de la industria para el aprendizaje y la referencia, que proporcionan más requisitos y descripciones no funcionales, como:

• Modelo de calidad de software de Jim McCall (1977)

• Modelo de calidad del software de Barry W. Boehm (1978)

• Modelo de calidad de software FURPS/FURPS+

• R. Geoff Dromey Modelo de calidad del software

• Modelo de calidad de software ISO/IEC 9126 (1993)

• Modelo de calidad de software ISO/IEC 25010 (2011)

A continuación se presentan dos modelos de calidad de software comúnmente utilizados en la actualidad, se recomienda leer y comprender detenidamente:

Modelo de Calidad de Software ISO/IEC 25010

Un estándar de calidad de software formulado conjuntamente por ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica Internacional), que reemplaza el estándar ISO/IEC 9126; para obtener más información, consulte
: https://iso25000.com/index.php/en/ iso-25000-normas/iso-25010

Modelo de Calidad de Software FURPS/+

El modelo FURPS fue propuesto por primera vez por Robert Grady y Caswell de Hewlett-Packard, y luego Rational Software lo extendió a FURPS+.
Para obtener una introducción detallada, consulte: https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/process/workflow/requirem/co_req.htm

epílogo

Lo anterior presenta brevemente algunos requisitos no funcionales e indicadores relacionados.Los dos artículos siguientes presentarán la usabilidad y la optimización del rendimiento del sistema de software.