Análisis de requisitos: análisis de roles funcionales y diagramas de casos de uso

El análisis de necesidades no es una tarea que pueda realizarse de la noche a la mañana. Requiere un proceso a largo plazo, y este proceso es un proceso de grueso a fino, que encarna las leyes objetivas de la comprensión humana de las cosas. En la etapa inicial del análisis de necesidades, nuestra comprensión de las necesidades es a menudo holística y macroscópica y, a medida que el análisis se profundiza, se refina gradualmente. Según esta idea, nuestro análisis de necesidades debería partir del análisis de los roles funcionales. El llamado análisis de roles funcionales consiste en analizar las funciones que todo el sistema de software puede proporcionar desde la perspectiva de un usuario externo y para qué roles se proporcionan estas funciones.

Uno de los métodos principales para organizar y analizar las funciones y roles de un sistema es dibujar un diagrama de casos de uso. El diagrama de casos de uso es una de las vistas 4+1 de UML, que resulta ser la "+1". El diagrama de casos de uso es la vista principal de OOA/D. Describe qué funciones proporciona el sistema a los usuarios y qué usuarios están utilizando estas funciones. Es un puente entre usuarios y técnicos.

El proceso de utilizar la vista de casos de uso para analizar, abstraer, organizar y refinar los requisitos comerciales y luego formar un modelo abstracto se denomina modelado de casos de uso, y este modelo es el modelo de casos de uso. En términos generales, hay tres elementos en un diagrama de casos de uso: actores, casos de uso y límites del sistema.

La figura anterior es un diagrama de casos de uso de un submódulo en el sistema de evaluación. Los casos de uso en el diagrama son las funciones que el sistema proporciona a los usuarios. Tenga en cuenta que esto es solo una lista de funciones y no representa la relación entre ellas, como las llamadas a procesos. Este es un error común que cometen algunos principiantes.

En este diagrama de casos de uso, los usuarios comunes realizan operaciones de consulta y consultan informes como la "Consulta única de monitoreo de alerta temprana" y la "Consulta resumida de monitoreo de alerta temprana" proporcionada por el sistema, que activa el disparador automático diario; Función de evaluación. Las funciones recopilan datos de sistemas externos como el Sistema de Administración Tributaria. En la figura, los administradores de evaluaciones y los agentes del orden representan dos roles completamente diferentes, pero encarnan algunas características en esta figura, que son las consultas de este montón de informes, por lo que se extraen como heredados de los usuarios comunes. La herencia es la única relación entre los partícipes, lo que significa que el heredero tiene todas las funciones y derechos del causante. Además de los actores, existen algunos tipos de casos de uso que están directamente relacionados con los casos de uso, que analizaremos en detalle más adelante. Un detalle que vale la pena considerar al dibujar diagramas de casos de uso es cómo se obtienen los casos de uso mediante el análisis. Este problema no existe en algunos proyectos con mucha experiencia en la gestión de información del cliente, porque cada función está claramente dividida en el documento de requisitos proporcionado por el cliente. Estas funciones pueden ajustarse en futuros análisis de requisitos, pero forman un prototipo en su conjunto y se convierten en la base para nuestro análisis y formación de casos de uso. Pero cuando nos enfrentamos a algunos clientes que no tienen experiencia en gestión de información, la situación no es buena. En este caso, normalmente el cliente sólo puede darnos algunos objetivos de gestión e ideas básicas, y nosotros mismos debemos realizar otros trabajos de investigación. En este momento, mi sugerencia para usted es: primero defina claramente a partir de la estructura organizacional qué departamentos y departamentos están involucrados en el sistema, y ​​luego, sobre esta base, divida las diferentes funciones que realiza el personal de estos departamentos y qué operaciones comerciales completan. . Una función en el sistema es generalmente una operación completada por uno (o más) roles en la organización en un proceso de negocios de la organización. Esta operación debe tener un resultado determinado (es decir, una salida). Esta funcionalidad es el caso de uso que necesitamos extraer. Aunque el análisis de roles funcionales puede continuar ajustándose a medida que se profundiza la comprensión a lo largo del proceso de análisis de requisitos, generalmente así es como procede el proceso de análisis. Algunas personas dicen que los clientes no pueden entender los diagramas de casos de uso que dibujamos. Con un diagrama de casos de uso tan claro, complementado con nuestra descripción de los gráficos, ¿cómo podría el cliente no entenderlo? El problema clave es que no entendemos la esencia de los diagramas de casos de uso. Algunos problemas comunes hacen que los diagramas de casos de uso sean anodinos y, por supuesto, los clientes no pueden entenderlos.