Cómo crear empleo descripción del caso de su informe de análisis de negocio
LA uso modelo de caso es una presentación de análisis de negocio de los pasos que definen las interacciones entre un usuario (llamado actor) Y un sistema (por lo general un sistema informático). En él se detallan las interacciones y establece las expectativas de cómo el usuario va a trabajar dentro del sistema.
El modelo de casos de uso se compone de dos artefactos: el utilizar diagrama de casos, que es una representación gráfica que muestra que los actores pueden operar de casos de uso, y el utilizar descripción del caso (a veces llamado utilizar narrativa caso), Que son los basados en texto, detallado, interacciones paso a paso y el diálogo entre el actor y el sistema.
La narrativa de casos de uso es lo que la gente suele decir cuando dicen utilice caso. Sólo recuerde que hay múltiples piezas que componen un modelo de casos de uso.
La descripción de casos de uso es un relato escrito de la secuencia de las etapas realizadas por un analista de lograr una transacción de negocios completo. Ha iniciado por un actor, proporciona valor a ese actor, y es un objetivo del actor que trabaja en ese sistema. A continuación, verá una descripción de casos de uso que documenta claramente cómo un gerente estudiante aprueba una solicitud de capacitación de un trabajador estudiante.
La mayoría de las descripciones de casos de uso incluyen los siguientes elementos como mínimo:
Título: El título se comunica el objetivo del caso de uso. En el ejemplo, el Registro de Estudiantes (el título) utiliza el objetivo del caso es que el alumno sea capaz de inscribirse en una clase.
Actores: Estas personas son las personas o sistemas que interactúan con el caso de uso. Algunas personas escriben casos de uso también romper los actores por nivel en el caso de uso: primario (el actor que inicia el caso de uso), secundario (el que interactúa con el caso de uso), e incluso fuera del escenario (los que no interactúan directamente con el caso de uso, pero están involucrados desde una perspectiva de reglas de negocio).
Condiciones previas: Condiciones previas son esas cosas que deben estar en su lugar antes de que el caso de uso se puede iniciar. Una condición previa para el ejemplo es que el estudiante tiene que haber hecho la solicitud de capacitación.
Poscondiciones: Poscondiciones están en su lugar cuando termine el caso de uso con o sin éxito. Una condición posterior en caso de éxito indica lo que sucede cuando el proceso finaliza correctamente. Un postcondition el fracaso es el opuesto: se especifica lo que sucede cuando el proceso no se completa correctamente.
Camino: También llamado fluir o historia, el camino es la acción paso a paso y la interacción entre el actor y el sistema. Caminos vienen en tres tipos:
Ruta Primaria (también conocido como camino feliz o flujo principal): Esta ruta es la ruta más común llevado a una conclusión exitosa.
Usted puede ver este camino documentado en la parte superior del ejemplo: El gerente estudiante hace clic en el enlace del correo electrónico, navega a través del sistema de registro a la página de aprobaciones de entrenamiento, ve a la solicitud, y la aprueba, lo que provocó una confirmación por e-mail al estudiante. Sucede exactamente como debería.
Camino alternativo: Este camino es un suplente, menos frecuentado manera de llegar a una conclusión exitosa.
En el ejemplo, el gerente de estudiante ya ha iniciado sesión en el sistema y busca a las solicitudes de capacitación pendientes en lugar de acceder al sistema a través de un correo electrónico. Después de que él se encuentra, sigue los mismos pasos que el camino principal. Es una Terminación- éxito él no hizo uso de la vía más común para llegar a ella.
Ruta Excepción: Este camino es un camino alternativo que conduce a una conclusión sin éxito. Una ruta de excepción relacionada con el ejemplo puede ser que el administrador de estudiante no puede aprobar la solicitud porque ya no está asignado como gerente del estudiante. Un mensaje de error o excepción se mostrará indicando la razón.
Puede agregar objetos adicionales para la descripción de casos de uso para dar cuerpo totalmente fuera:
Caso de uso ID: Un identificador único que se utiliza para el rastreo.
Descripción: Una breve descripción textual de lo que el caso de uso. Una descripción del ejemplo sería " Esta descripción de casos de uso se describen los pasos para un gestor de estudiante para examinar la solicitud de los estudiantes y aprobar o denegar la solicitud ".
Creado por: El autor del caso de uso.
Fecha de creación y revisión histórica: Una cronología del caso de uso, lo que le permite ver la edad que el caso de uso es (útil cuando se hace el análisis de documentos),
Prioridad: Un indicador de la importancia de este caso de uso, que es útil en la planificación de la solución.
Frecuencia de uso: Un indicador de la frecuencia con que se ejecuta este caso de uso (también útil en la planificación de la solución).
Para poner realmente una descripción de casos de uso conjunto, siga estos pasos:
Calcule el punto de partida para el caso de uso.
Esto se convierte en su condición previa.
Obtener de sus grupos de interés los pasos que se pueden esperar al usuario tomar y lo que el sistema debe hacer (la ruta principal).
Para cada paso, documento que realiza una acción y que lleva a cabo una reacción (o la respuesta).
Vuelve y obtener las formas alternativas de llevar a cabo el proceso.
Indique donde comienza cada ruta alternativa. Por ejemplo, en el ejemplo, verá que camino 3a alternativo se toma en lugar de la ruta principal 3. Por lo tanto, es necesario asegurarse de que la solución a construir proporciona una manera de negar la solicitud de capacitación.
Debido a que el caso de uso se construye alrededor de la ruta principal, indicar cómo navegar a las alternativas y caminos de excepción de ese camino principal. Si estás usando una herramienta para generar la descripción de casos de uso, es posible que le pida esta detallada de lo contrario, incluso un simple, " Esta ruta alternativa se inicia después del paso X de la ruta principal " Será suficiente.
Documentar los flujos de excepción y mensajes de error hasta que la descripción es completa.
El producto final es una lista detallada de los pasos realiza el usuario y la respuesta esperada del sistema.