In this column, David Gelperin presents a problem familiar to many of us—what is the best way to record requirements? Given the limitations of static templates, how can we best manage high-volume, multidimentional requirements information? Read on and then share your experiences.
We're planning a new project and I've been thinking about our past struggles with requirements. We have always created a requirements document, but that may not be our best approach this time.
Documents have worked fine on our smaller projects, where requirements could be specified in twenty or thirty pages. We even expect to "write requirements" and our language reflects this expectation. In addition, multiple templates are available within our organization and on the Web. The templates provide various information layouts for requirements documents; however, the effectiveness of documents does not scale up.
Large documents are hard to check and hard to use. Because a document's organization is fixed, authors must choose the single best way to arrange information. Unfortunately, for large aggregates, there is no single best way or even one pretty good way. The same requirements information needs to be organized in different ways to satisfy different needs including the need to check accuracy and completeness. As page count and number of stakeholders increase, the need increases to develop information with a fluid, rather than fixed, organization; i.e., a database.
For example, my wife Sharon and I recently created our guest list for our son's wedding. We could have used a word processor, which would have worked well for twenty or thirty people. Since we were inviting about 130 people, we used a spreadsheet program. Along with names, addresses, and relationships, we entered response and meal preference information. The spreadsheet's sort capability enabled us to easily determine (1) the number of people choosing vegetarian, fish, or meat dinners, and (2) the list of out-of-towners and exactly where they were from. The spreadsheet's computational capability provided an important derived value, the total number of acceptances.
While sorting by relationship, we noticed that some cousins who we planned to invite were not on the list. While the missing cousins might have been detected from an alphabetical list, aggregating by relationship made their absence much easier to spot. Requirements information, too, needs to be aggregated in various ways. Examples include (1) all critical requirements, (2) all requirements from a single stakeholder, (3) all unfinished requirements, and (4) all interface requirements. Higher volume, multidimensional information is best managed by a processor that can calculate, query, and reorganize.
Computational capability supports the use of derived (virtual) information. For example, explicit links from a test to its source requirements, permit the derivation of links from the source requirements to the tests. This significantly increases the manageability of multiple aggregates of linked information that change frequently.
Since larger scale requirements should be developed using either a spreadsheet or a database, I must now decide whether a document or database will best serve our new project.
I think of a spreadsheet as a limited function database (with extra computational capabilities). The choice is again a matter of scale. With dozens of requirement properties, a spreadsheet becomes too hard to use—as a document did. So we have a usage spectrum with documents and databases at the endpoints and spreadsheets in the middle. What do you think? I'd like to hear what you use and how you decided to use it.
