1.4 Requirements and Scenarios

The first step in technical design is defining and understanding requirements, and this step can be retraced to provide a better understanding of an existing design. The requirements relate closely to the technology comparisons in the next chapter, and scenarios help put everything in context, so it's useful to introduce them now.

Some WebDAV requirements were drawn from existing practice. For example, since Front Page had a proprietary way to copy, move, and rename Web pages, and so did all the other proprietary solutions, WebDAV had to match this existing functionality.

Other requirements were drawn from scenarios, which are stories about how people interact with their software, their documents, and their collaborators. Scenarios help us understand which features are useful and which aren't. If a compelling story can't be told for how a feature is used and why the feature can't easily be done in some other fashion, then it's a good bet the requirement can be cut from the list.

When a protocol can be simplified by cutting requirements or reducing options, good designers do so in order to make it more easily implementable and interoperable (and incidentally to reduce the design period from infinite duration to just a few years). What remains is the minimum requirements list.

These few scenarios illustrate the kinds of situations that the core WebDAV protocol had to handle and from which the minimum requirements were derived.

• Several members of a project team share a task checklist spreadsheet. Since anybody can update task status in the spreadsheet, users should not be allowed to accidentally overwrite each other's changes. The group leader needs to know when the spreadsheet was last updated and by whom. The project team also has a large number of directories with specifications. It's convenient to keep file and directory names short, but short names can make it hard to find the right file. To solve this problem, their files and directories can all have descriptions and project names, stored as properties.

• A quilt guild shares digital images of its members' quilts online. The images are stored in a common location. Guild members use a wide variety of software on different operating systems, so they need a publishing solution that doesn't depend on one software platform. The users have access to the Internet through various routes corporate accounts, university accounts, and home-based ISP access.

• A Web site design firm is employed to design, implement, and maintain Web sites for their clients. The desktop computers used by the design firm and the Web servers they work on aren't on the same local network (the servers are often at high-availability hosting sites or at the client premises). Proprietary protocols could be used to maintain and extend these remote servers, but each customer might use a different proprietary Web management system. It's far easier if the remote servers all support an Internet standard protocol. Standard authentication and access control are essential in this scenario because a diverse and changing list of people are authorized to modify any given site.

Most Internet users can identify with the frustrations of having been in these situations. Most have also endured the inadequacies of sending files over email or using FTP. These difficulties dictate a set of requirements.

• WebDAV had to define folders, or directories, since HTTP does not specify how to view directories. Standard directory listings would allow the quilters' software to navigate and present information compatibly.

• WebDAV had to define how metadata, or information about Web server files, could be represented and accessed. Metadata is what allows a project team leader to see when a task list was last updated and who updated it; it allows custom properties such as descriptions and project names to be associated with each document.

• WebDAV had to protect a document from other changes during editing. CM software, file systems, and even databases protect files (or rows) with locks. Locks prevent project team members from accidentally losing each other's changes to task lists.

• WebDAV had to use HTTP addresses to name editable resources, because there was no other way for new Web users, like the quilters, to make changes to the correct Web pages.

• WebDAV had to be an Internet protocol, one that was likely to be allowed by many ISPs and that could be supported on many platforms. This allows Web site design firms to use common tools to edit customers' Web sites remotely.

This isn't a very detailed or exhaustive list of requirements, but rather a list designed to illustrate the problem space. This list of requirements was also generated with the benefit of hindsight, which is why they so neatly define WebDAV. When the working group discussed requirements, many more were brought up and their importance was hotly debated. The process of defining a standard is much messier than the result, as the history of the working group demonstrated.