The Shell

The first eight sections of the requirements specification, which cover the drivers, constraints, and scope of the project, use a mixture of models and free text. However, the atomic functional and nonfunctional requirements should be written more formally using an agreed structure.

When you write atomic requirements, it is not sufficient to write free-form natural-language statements, as they lack the necessary rigor and are ambiguous. We have found that a number of components are necessary to make a complete requirement, and have implemented these components in what we call a shell.

Snow Cards

Before we discuss the components of the shell, we want to introduce the snow card. It is simply a cardwhite, of coursethat contains the shell components. We borrowed the idea of a card from William Pena, an architect. Members of Pena's architectural firm use cards to record requirements and issues relating to buildings they are designing. The team members tape cards containing unresolved issues to the conference room walls, and then use this visual display to get a quick impression of the progress of the building.

We have found a similar use for these cards when gathering requirements. Figure 10.3 shows an example of a snow card. This low-tech approach to requirements gathering is convenient when trawling for requirements, but at some stage we transfer the requirement to an automated tool.

Figure 10.3.

The Volere Shell in its snow card form. Each 8 inch x 5 inch card is used to record an atomic requirement. The requirements analyst completes each of the items as it is discovered, thereby building a complete, rigorous requirement.

In our requirements seminars, we place small stacks of snow cards on the students' tables. The students use them to record requirements during the workshops. What always surprises us is that, even though the snow card is a low-tech device, the students take away all the unused ones at the end of the seminar. Later we get e-mails telling us how much they like using snow cards for the early part of the requirements-gathering process.

When working on our own projects, we use cards when we are interviewing stakeholders, and record requirements as we hear them. Initially the requirement is not fully formed, so we might simply capture the description and the originator. As time moves on and we have a better understanding of the requirements, we progressively add new components to the cards.

One advantage of loose cards is that they can be distributed among analysts. We have several clients who make use of cards in the early stages of requirements gathering. They find it convenient to pin them to walls, to hand them to analysts for further clarification, to mail them to users (we were intrigued to receive a snow card with our address and postage stamp on the back), and generally to be able to handle a requirement individually.

We were intrigued to receive a snow card with our address and postage stamp on the back.

Automated Requirements Tools

The low-tech approach is certainly feasible in the early stage of requirements gathering. However, if a number of analysts are working on your project, you will find an automated tool pays dividends as the work progresses and the number of requirements grows. The tool does not have to be elaborate. In fact, many of our clients find that a word processor or spreadsheet is satisfactory.

Free tools are also applicable: Blogs spring to mind here. It is easy enough to set up a blog or wiki on your in-house system, or to make use of one of the services available over the Internet. While it is not exactly a blog, your authors use Writely (www.writely.com) as an online collaborative tool. We are currently writing another book involving three authors and this approach works well for us. Other tools are also available, each with its own attractions and each with its own cost. Take your pick.

Requirements tools change constantly. We maintain a list of available tools at www.volere.co.uk/tools.htm.