Ejemplo de ficha textual y pautas generales

Ejemplo de ficha textual y pautas generales
Caso de Uso: CU01 – Autenticando usuario
Actor: Usuario del Sistema
Curso Normal:
Alternativas:
1) El caso de uso comienza cuando el usuario
1.A) Si el ingreso es al Módulo Web:
selecciona la opción “Ingresar al Sistema”
1.A.1) El usuario selecciona la opción “Ingresar
como usuario registrado”, en la página de
inicio del módulo.
1.A.2) El sistema muestra la página de ingreso
al sistema.
1.B) Si el ingreso es al Módulo Windows:
1.B.1) El usuario ejecuta la aplicación.
1.B.2) El sistema muestra la ventana de
ingreso al sistema.
2) El sistema muestra los campos a ser
completados para autenticar al usuario:

Nombre de usuario: campo de texto.
Valor obligatorio.

Contraseña: campo de texto de tipo
contraseña (se muestra un “*” por
cada carácter ingresado por el
usuario). Valor obligatorio.
3) El usuario ingresa los datos solicitados.
4) El sistema realiza las validaciones de
interfaz correspondientes:

Los campos obligatorios poseen
valores. (1)
5) El sistema valida que el nombre de usuario
5.A) Si el usuario ingresó al módulo Web: (3)
y contraseña correspondan a un usuario del
5.A.1) Si el usuario no está registrado, el
sistema.
sistema muestra el siguiente mensaje:
“Usuario no registrado. Ingrese por la opción
“Usuario nuevo” y complete los datos
requeridos para registrarse en el sistema”.
5.A.2) El caso de uso finaliza acá.
5.B) Si el usuario ingresó al módulo Windows:
5.B.1) El sistema muestra siguiente mensaje:
“Nombre de usuario o contraseña inválidos.
Vuelva a ingresarlos correctamente”.
5.B.2) El sistema vuelve al paso 2 del caso de
uso.
6) El sistema controla el acceso del usuario.
6.A) Si el usuario ingresó al módulo Web:
(2)
6.A.1) No es necesario realizar este paso dado
que el único usuario de dicho módulo
(postulante) tiene acceso a todas las
funcionalidades existentes.
6.B) Si el usuario ingresó al módulo Windows:
6.B.1) El sistema habilita las funcionalidades
según el rol o grupo al que pertenece.
7) El caso de uso finaliza acá.
(1) En otros Cus, donde se ingresan otros datos, se deben indicar las validaciones necesarias, por
ejemplo: validar que el dato sea de tipo fecha; validar que el dato sea numérico, entero,
positivo; validar que el dato tenga N caracteres como mínimo; etc.
Si hubiera campos seleccionables en una lista, indicar en el CU si se puede seleccionar uno
solo o varios.
(2) Esto generalmente se hace en un CU aparte denominado “Control de acceso”, es decir, se
divide lo que es la autenticación de usuario (si es un usuario válido) del control de acceso (a
qué funcionalidades tiene permiso).
(3) Estos pasos alternativos no serían necesarios si se hubieran especificados dos Cus, uno para
ingreso al módulo Web y otro al módulo Windows. Por ejemplo:
ud MCU-Ingreso al sistema
Nombre:
MCU-Ingreso al sistema
Autor:
Josefina Morais
Versión:
1.0
Creado:
12/02/2001 12:00:00 a.m.
Actualizado:0 2/05/2005 09:09:40 p.m.
CU002-Ingresar al
módulo w eb
«realize»
CU001-Ingresar al
sistema
Usuario del sistema
«realize»
CU003-Ingresar al
módulo w indow s
En el gráfico se ve un tipo de relación no contemplado en el módulo: “Realización”. Esto significa
que el CU001-Ingresar al sistema es un CU abstracto (no tendrá implementación), que tiene
características comunes a los otros Cus que lo implementan o realizan (estos últimos sí tendrán
implementación concreta).
Esto es lo más adecuado para este tipo de situaciones, pero se podría considerar como que los
CU002 y CU003 son extensiones del CU001, lo cual nos es familiar porque sí se estudiaron las
relaciones de “Extensión” entre casos de uso.
Pautas generales a tener en cuenta en la confección de fichas textuales







Un CU no puede estar especificado por un solo paso. Todo CU es una secuencia de
acciones o pasos.
Indicar siempre como primer paso cuándo y cómo comienza un CU. Ejemplos:
o Para el caso de un CU primario, es decir ejecutado directamente por un usuario:
“1. El caso de uso comienza cuando el usuario selecciona la opción Registrar
entrevista”
o Para el caso de un CU invocado por otro CU mediante una relación de extensión o
uso: “1. El caso de uso comienza cuando es invocado por el CU xx.”
Indicar siempre que el CU finaliza. A veces un CU tiene varias finalizaciones, una por el
curso normal y otra/s por distintas alternativas.
Son bastante extraños los Cus que no tengan ninguna alternativa. Significaría que el
usuario sigue una única secuencia de pasos, no tiene ninguna opción, y no ocurre ningún
tipo de error. Por ejemplo, qué pasa si el usuario ingresa a seleccionar las preguntas y
todavía no hay ninguna cargada en la DB? Seguramente el sistema le mostrará un mensaje
indicando la situación.
Indicar la invocación a otro CU mediante relación de uso en el Curso Normal.
Indicar la invocación a otro CU mediante relación de extensión en el Curso Alternativo.
En lo posible, evitar nombrar a los Cus como “Administrando ...” (Ej: “Administrando
Resultados de Entrevistas”), a menos que luego se haga la modularización de dicho CU.
Esta recomendación se debe a que no queda claro si el Administrando incluye o no el alta
(registrando), la modificación, la eliminación, la consulta, la búsqueda (por determinados
criterios), etc. En desarrollos concretos puede llevar a conflictos con el cliente que puede
asumir distintas funcionalidades incluidas en la “Administración” de una entidad del sistema
de las que pensó el Ingeniero de Requerimientos y que luego serán desarrolladas.