Functional Requirment
Functional Requirment
The matter of writing functional requirements is nothing short of writing a message to somebody about a
task 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 terminology has 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.
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 user feedbacks as you can, and test your own
comprehension by presenting the facts gathered, back to the user. That way, all unclear issues can be
threshed out as early as possible.
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
functional requirements needed by the system that will enable it to produce the reports that the user
expects.
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.
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.
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 alloted 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