There are different techniques you can use to document use cases. You can use a narrative, a flowchart, a table, or you can use a Structured Analysis and Design Technique (SADT).1 The SADT (a.k.a., IDef0) provides a way to visually represent applicable information about the step or action being performed. 

Step

The step is the action being performed by your audience or user. If you are using personas, then the step is what your site's persona will perform. The challenge with identifying a step is to know how granular you need to get. For example, which of the following is a step?

• Click the Submit button
• Create an event
• Upload an image

The first step example might be too small to document unless it is a step that is uncommon to the task or if the submit process needs to execute more than your typical submit command.

The second step is more in line with the task to create an event. What does it take to create an event? The steps might include create a new node, complete for the event form, upload the event brochure, upload an image, insert an image, and enable a view listing related nodes.

The last example, upload an image, can be accomplish using different features in Drupal. By isolating this action as a step, you can describe the way you want the image to be uploaded, where you want the image to be stored, who can see the image, and so on.

Input

Input is the data needed to perform the step. Input can be a word or term to be searched. It can be personal data used to create an account or place an order. It could also be the information needed to complete a web form. The objective is to identify what data is needed, if any, to complete the step and to identify its source.

If the source of the input is the user performing the step, that should be noted. If each step requires the users to provide input before the step can be completed, this might be a sign that the users might need a heads-up before they start the task.

Not all steps will require data. For example, the step to create a node might require a decision regarding which type of content to create or it could require that the user know where to find the "create content" option. A complete statement of the step will help clarify what is expected.

By knowing what the input is, you can ensure that users have that input available to them when they go to execute the step.

Output

Output is the result of the step. You might require multiple actions to occur as the output of the step. For example, you might want a message to appear on the screen and an email to be sent. The output from one step can be the input for another step.

For instance, have you ever been on a site that allowed you to sign a guest register or create an account? When you submitted the form, did you get any feedback on the screen like "Thank you for submitting your information?" Did the feedback screen give you the option to continue browsing the site, which might be the input to the next step? This is just one example of why you need to be aware of the output generated by a step.

The objective is to identify everything you want to happen or be available to the user when the step is complete.

Controls

These are conditions that influence or govern how the step is performed. They can be enforced by the site technology. For example, they can be implemented via a sequenced form that prevents the user from moving on to the next page until the form is complete. Other technology controlled options include user roles and the associated permissions. Unless the user is assigned to a role and that role has a specific level of permission, the user can’t perform a step (such as viewing a form or accessing a page).

Controls can also be business policies that the user follows. Although there is a risk that the user will not adhere to the control policy, it might be a risk whose cost does not out weigh the expense of programing a technology solution. Of course, there are times when there don't appear to be any controls except for "The site has to exist for the user to do that." Not a control worth mentioning usually. 

The objective in identifying controls is to identify if or when Drupal needs to validate conditions (does the user have permission). 

Mechanisms

Mechanisms can be tools on the screen or functions that run in the background (backend). The screen mechanisms can include, but are not limited to, how-to pop-ups, calendar functions, calculators, fields, buttons, and/or forms the user needs in order to complete the step. Backend functions might require Drupal to compare the dates selected with the dates in another field on the form to ensure the two dates don't contradict each other.

Mechanisms can also include tools that are not included in the site. Even if you aren’t going to provide the tool, you might need to offer advanced notice that a tool is required or you might offer a link to another site where the tool can be used. For example, will you be providing downloadable PDFs? You might need to tell your audience where they can get the PDF reader required for the download. The objective is to identify the functions and features that will be needed to complete the step.

Conclusion

This technique is useful in getting you to think about the step and everything that needs to be in play in order for the step to be performed successfully. There is a good chance that some steps will simply need to behave as the system decides. Other times you will want something different. When you want something other than the default way Drupal supports the step, you need to take care to document those details and footnote that you are deviating from the default. If you don't know how Drupal would support the step by default, document everything assuming it is unique.

1. 1. http://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique