Pointers for Documenting the Functional Requirements

The matter of creating a document that details the technical functionalities required for a software development project is nothing short of writing a message to a team member about the technical tasks which you want him to do. The difference, however, is that you will be giving out instructions that are based, not on your own purpose, but for a third-party user—the customer.

You have to make sure, of course, that the person to whom the message is addressed gets the right idea on how the end-product should work as a functional tool or system, based on the user's point of view. Otherwise, the person performing the job will end up doing guess-work or basing things on his own level of user-capability.

Your objective, therefore, is to write technical instructions on behalf of a user who may be considered computer literate but not exactly technologically capable. Your task is to write in detail the exact requirements based on the end-user's purpose and capability.

Still, stating the requirements in a written form is different from that of delivering the instructions verbally. Another issue is the reader's understanding of the user's requirements outside of technical words. It cannot be helped that some terminologies have different meanings if used in a different perspective.

This is one of the reasons why some projects tend to take a long time to accomplish. The final outcome has to go through several adjustments or revisions, until the "nail is hit right on the head", so to speak.

In line with this, consider the following tips for writing functional requirements, to serve as a useful guide to whomever will be tasked to develop the functional aspects of the project being worked on.

Double-Check Your Facts

Accuracy of information is the first important aspect to consider when writing instructions on behalf of the end-user, and the only one who can judge this is the user himself. Make it a point to check if your own understanding of the user's wants is correct. Use illustrations if you have to, make a diagram or draw a prototype and present it to the user. Get as much feedback as you can, ask as many questions and test your own comprehension by presenting the facts you gathered, back to the user. That way, all unclear issues can be threshed out as early as possible.

 

Use Plain and Simple Words

Use plain and simple English to describe the user's needs and requirements. As an example, let's take into consideration a function that is expressed differently in accounting terminology --- the "aging of accounts receivable."

As far as you're concerned, you are able to grasp that the user wants an accounts receivable system that has the capability to automatically calculate the length of time that an account has been outstanding as a receivable item. Hence, the user wants a system that can automatically generate an "accounts receivable aging report."

In this case, you should not presume that the developer of the accounts receivable system understands the entire concept of "aging" in its accounting sense. Instead, describe in plain and simple English the data needed and the mathematical equations required. That way, the developer will be able to interpret the functional requirements that will be demanded from the system in accordance with the user's expectations.

Illustrate or Use Diagrams

Illustrate or draw diagrams that will depict the computational and reportorial requirements of a system, thus, enabling the developer to understand the objectives. That way, he can visualize at what point the functional requirements should be worked out in the system.

You can also make use of sample inputs (calculations) and outputs (reports), as exact examples of what the user wants to know and see.

 

Organize Your Presentation

Present all requirements in an organized and systematic manner. The systems developer will base his comprehension on the way the requirements are presented. This is where diagrams or illustrations will be most useful, as a means for presenting the inputs and outputs in the proper functional areas.

Observe Time Frames

Keep in mind that in writing functional requirements, another team member is also expected to perform work within a specific time frame. Any delay on your part is a delay for the entire team. By forwarding a clear and concise functional requirements document as early as possible, you are also giving time for the systems developer to work on his job under less pressing conditions.

Part of the project's allotted time is for getting feedback that may require revisions and adjustments. This does not mean, however, that this particular time allotment should be fully maximized. A customer who becomes satisfied with the team's output at the soonest time possible, indicates a job well done.