Requirements are written statements that describe what is needed. The real question is, how detailed should requirements be? Below are four ways that define how detailed requirements can be. They aren’t necessarily industry standard, just a way to get us all on the same page.

To maximize your understanding of Drupal and how planning can be effective, in this online book we are going to assume the third option below, specification.

Purpose

Minimal description of what is needed and can carry with it many assumptions. For instance, the requirement is to build a community site. This is okay if you are buying a prepackaged product where it is understood what you will get. On the flip side, the lack of detail can bring a site development project to a halt.

Simple use case

A documented task is often referred to as a Use Case. “The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.”1

For instance the requirement could be to build a community site where users can add content and comment. In a system where these two tasks can only be formed one way, one could argue this simple statement is a use case. In Drupal, simply by installing core accomplishes this requirement. You need more detailed information, more detailed use cases.

Specifications

You’ve seen specs before. When you buy a computer you look to see its specs – its memory, processor, storage, and so on. Computer specs are details of what you are getting. For instance, an Intel Core 2 Quad processor is just that, not much confusion. Requirements at the spec level should leave little room for misunderstanding. Or they should at least provide enough information to allow for design and development discussion and decisions.

So, an example might be the requirement to build a community site where an authenticated user can add three types of content (page, story, and blog), categorize the nodes using two specific vocabularies (topic and section), create node reference relationships between each type of content, and so on. The number of options to choose from is huge. Until you walk through the requirements analyses offered below and you might over look a requirement or two.

Configuration

You can take specifications to the next level of detail by spelling out which technology should be used in order to meet a requirement. If you are the type to explore Drupal.org and read up on the modules that are available, you might find yourself tempted to explain to the developer how you think a requirement should be satisfied. You might go as far as to say “the requirement is to create a site with organic groups.” This is not always a good practice unless you are a Drupal developer and you know what you are doing.

Why, you might ask? There is often more than one way to satisfy a requirement and you don’t know what other modules will be needed and whether the module(s) you select will conflict. A good developer will wait and see all the requirements and consider all the modules that can satisfy the requirements before committing to any one module combination.

Conclusion

Not everyone understands "requirements" to mean the same thing. These levels of requirements can be a useful tool when communicating with your client. Most issues arise when two parties don't share the same understanding of expectations.

1. 1. Wikipedia.org, Use Case http://en.wikipedia.org/wiki/Use_case