SRS > Conjunto de Casos de Uso > Formato de Casos de Uso

Impacto del Proceso: Esta página de referencia documenta el frmato de los casos de uso y da sugerencias para escribir casos de uso. Ud. puede copiar y pegar el caso de uso del ejemplo en su archivo use-cases.html Este archivo no debería ser editado para manejar casos de uso específicos.

TAREAS: Use esta plantilla una vez por cada documento de caso de uso. Cualquier cosa que mencione aquí deberá aplicar para todos los casos de eso en ese archivo.

Aspectos comunes a todos los casos de uso

Actores Directos:
Usuario: usuario final en cualquier rol
Sistema: El sistema que se está construyendo
Cuando los actores no están listados, asuma que un usuario está realizando la acción.
Los elementos que comiencen con "ver" indican que el Sistema ha presentado una pantalla nueva.
Inversionistas: El usuario que está introduciendo la información, y lo que la leerán
Prerequesitos: El proyecto está instalado
TAREAS: Copie y pegue esta plantilla de caso de uso tantas veces como necesite en su documento de casos de uso. Solo utilice aquellos campos que no son los mismos que los de defecto en todos los casos de uso.

CU-00: NOMBRE DEL CASO DE USO

Resumen: 1-3 ORACIONES
Prioridad: Esenciales Esperadas Deseadas Opcionales
Frecuencia de Uso: Siempre A veces Algunaa veces Raramente Una vez
Actores Directos: ACTOR1, ACTOR2, ACTOR3
Inversionistas: INVERSIONISTA, INVERSIONISTA, INVERSIONISTA
Prerequisitos:
PRECONDICION
PRECONDICION
PRECONDICION
Escenario Principal de Éxito:
  1. PASO
  2. PASO
  3. PASO
Escenario de Extensiones Alternativas:
  • Si CONDICIÓN, entonces PASOS ALTERNATIVOS.
    • NOTAS o DETALLES.
  • Si CONDICIÓN, entonces PASOS ALTERNATIVOS.
    • NOTAS o DETALLES.
Notas y Preguntas
  • NOTA
  • NOTA
  • PREGUNTA
  • PREGUNTA

Formato de Pasos para Caso de Uso

Intente empezar cada paso con una de estas palabras de acción:

Incio de Sesión [como ROL o USUARIO]
Log into the system with a given user or a user of the given type. Usually usually only stated explicitly when the test case involves a workflow between different users.
visit LOCATION
Visit a page or GUI window. State the user's intention, don't say too much about UI choices that could change later. E.g., WRONG: "Press the 'Advanced...' button on the File | Page Setup dialog". RIGHT: "Visit the page margin configuration dialog".
enter INFORMATION
Fill in specific information. Try to state the information in some detail. E.g., WRONG: "Enter customer information." RIGHT: "Enter customer shipping address and discount code." Don't commit to details of a particular UI, i.e., don't name specific UI fields that might change later.
COMMAND
Describe a command that the user can tell the system to do. State the user's intent, not the label on a particular UI widget. This will usually be followed by a "see" step where the user sees a confirmation of their action. E.g., WRONG: "Control-P, OK". RIGHT: "Print the current document with default settings".
see CONTENT
The user should see the specified information on the currently presented web page or GUI window. Try to be specific about the information that is seen, but try not to refer to specific UI elements. E.g., WRONG: "see UserList.jsp" (what is the user supposed to notice on that page?) RIGHT: "see list of users with the newly added user in the list".
perform USE-CASE-NAME
This is like a subroutine call. The user will do all the steps of the named use case and then continue on with the next step of this use case.

Guidelines for Writing Use Cases

TODO: Check for words of wisdom and discuss ways to improve this template.
Company Proprietary
Copyright © 2003 Jason Robbins. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.