Login | Register
My pages Projects Community openCollabNet
Project highlights: Browse templates | Download | Words-of-wisdom | Translations: Spanish

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

  • Capture the user's intention, not the details of a particular UI.
  • Each use case should show the user succeeding at a goal. Any type of failure or error should be handled as an alternative.
  • If one use case has too many steps or extensions, split it into two use cases. Use the "perform" notation to refer to shared steps.
  • If it is not already clear from context, you may want to number the steps of an extension to indicate the point in the main use case steps where the extension starts.
  • The actor, frequency, and use case name should fit into this sentence, both logically and grammatically: "An ACTOR will FREQ want to USE-CASE-NAME." If the frequency is "Once", scope the timeframe: e.g., once per user, or once per customer, or once per installation.
  • If a use case has more than about 9 steps, you are probably showing too much detail (or the task will be really hard to perform).
  • Evaluate the usefulness and usability of your system by evaluating the use cases before going further with design or implementation. See the words of wisdom for links to evaluation techniques.
  • One good evaluation technique is the cognitive walkthrough. At each step think of a confident answer to these questions:
    • Would the user realize that they should do that step?
    • Would the user recognize the proper button to press?
    • Would the user be able to provide the needed information?
    • Does the system provide an indication that the user's action succeeded?
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.