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.

Aspectos comunes a todos los casos de uso

CU-00: NOMBRE DEL CASO DE USO

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?