FOLKLORE is a systems documentation technique that was created to supplement some of the techniques just covered. Even with the plethora of techniques available, many systems are inadequately documented or not documented at all. FOLKLORE gathers information that is often shared among users but is seldom written down.
FOLKLORE was first developed in the 1980s by Kendall and Losee, well before the creation of blogs and user communities. FOLKLORE has two main advantages over commonly found user communities: (1) it is structured, resulting in more organized, more complete documentation, and (2) it encourages someone familiar with the software to seek out information rather than depending on users to come forth on their own.
FOLKLORE is a systematic technique, based on traditional methods used in gathering folklore about people and legends. This approach to systems documentation requires the analyst to interview users, investigate existing documentation in files, and observe the processing of information. The objective is to gather information corresponding to one of four categories: customs, tales, sayings, and art forms. Figure illustrated below suggests how each category relates to the documentation of information systems.
When documenting customs, the analyst (or other folklorist) tries to capture in writing what users are currently doing to get all programs to run without problems. An example of a custom is: “Usually, we take two days to update the monthly records because the task is quite large. We run commercial accounts on day one and save the others for the next day.”
Tales are stories that users tell regarding how the system worked. The accuracy of the tale, of course, depends on the user’s memory and is at best an opinion about how the program worked. Tales normally have a beginning, a middle, and an end. So we would have a story about a problem (the beginning), a description of the effects (the middle), and the solution (the end).
Sayings are brief statements representing generalizations or advice. We have many sayings in everyday life, such as “April showers bring May flowers,” or “A stitch in time saves nine.” In systems documentation, we have many sayings, such as “Omit this section of code and the program will bomb,” or “Always back up frequently.” Users like to give advice, and the analyst should try to capture this advice and include it in the FOLKLORE documentation.
Gathering art forms is another important activity of traditional folklorists, and the systems analyst should understand its importance, too. Flowcharts, diagrams, and tables that users draw sometimes may be better or more useful than flowcharts drawn by the original system author. Analysts will often find such art posted on bulletin boards, or they may ask the users to clean out their files and retrieve any useful diagrams.
Contributors to the FOLKLORE document do not have to document the entire system, only the parts they know about. Just like with Web-based user communities, the danger of relying on FOLKLORE is that the information gathered from users may be correct, partially correct, or incorrect.
Choosing a Design and Documentation Technique
The techniques discussed in this chapter are extremely valuable as design tools, memory aids, productivity tools, and as a means of reducing dependencies on key staff members. The systems analyst, however, is faced with a difficult decision regarding which method to adopt. The following is a set of guidelines to help the analyst use the appropriate technique.
Choose a technique that:
- Is compatible with existing documentation.
- Is understood by others in the organization.
- Allows you to return to working on the system after you have been away from it for a period of time.
- Is suitable for the size of the system on which you are working.
- Allows for a structured design approach if that is considered to be more important than other factors.
- Allows for easy modification.
