Printer Friendly Version

Are your requirement specifications too haphazard or too formal to truly be useful? Do you find it more form over function and so you either avoid doing them or do it in a slipshod manner?

In my previous article, "Requirements Gathering: Lose Your Ego and Ask Away" I discussed some of the challenges inherent in gathering requirements and the exponential costs of missing the mark. So, by now you should be convinced of the value of getting requirements right. However, you may find yourself wondering how to do this efficiently and thoroughly. If this sounds familiar, continue reading and discover a thorough yet usable recipe for requirements.

Every food recipe consists of a number of ingredients that must be included in the correct proportion and border for the end result to end up tasting like it should. The same holds true for an intranet application to end up working as expected. If you use the following key ingredients in your requirement specifications, you can rest assured you've addressed all the major factors crucial to the application's success. That's the good news. The even better news is that you can customize this recipe so it is as simple or as complex as your system project, company culture, or personal working style dictates.

Introduction and Background
This section of your requirements contains the business perspective for your project. In language that is easily understood by business and technical audiences alike, it contains the following:

• Purpose of the system.
• Necessary approvals of the requirements specification.
• Audience and end users of the system.
• Definitions of acronyms and terminology.
• References to existing policies, procedures, and documentation.

System Overview
In layperson's terms, this section gives an overview of what the system is, why it needs to exist (business perspective), what it does (functions), and who the users are.

Functional Requirements
This section is the meat and potatoes of the requirements. It answers the questions: What will the system do? What will the system not do? It addresses all the functions the system must be able to perform and how it should perform them (what validation must occur, what information must be displayed, the order of operations, etc.).

It is important to write and reference the individual requirements in such a way that each can be properly traced and tested. Find a numbering scheme that works for you and stick with it throughout the document. You will be referring to it when you write your test plans.

Interface Requirements
What system dependencies exist? With what other systems does it need to interface? Do these interfaces need to be real-time or could batch processing be used? Any and all details related to required interfaces should be included in this part of the requirements specification.

Data Requirements
Data makes the world go round. Without data, you would have no application. Data requirements can be as simple as a delimited text file to track some basic information or as complex as a multi-tiered, enterprise-wide relational database. Either way it is important that you document:

• What information does the application require (in layperson terminology)?
• Where will this data reside?
• Who will provide and maintain the data?
• What database technologies will be used?