Functional requirements are the obvious day-to-day requirements which end-users and stakeholders will have for the product. They revolve around the functionality that must be present in the project for it to be of use to them.
A functional requirement typically states as “the system X must perform function Y”. This is known as an ‘assertion’. An assertion asserts or affirms a necessary or desirable behaviour for the system or product in the eyes of a stakeholder.
Without clear assertions requirements are nothing more than vague discussions which have a regrettable tendency to clutter up your desk and your mind.
Compare the two following, contrasting, functional requirements:
- The financial system must produce a detailed customer invoice as per Appendix A.
- Producing an invoice for customers is important. Invoices should contain all the pertinent information necessary to enable a customer to supply payment for goods.
The first is a functional requirement stated as an assertion. It indicates that the financial system is responsible for producing a detailed customer invoice which contains all the information in Appendix A. While it could be more specific, the reader is left in no doubt as to what the financial system must do in order to be a successful financial system.
The second could be the introduction for a chapter in an accounting book. Although it states that invoices are important it gives no indication of who or what is responsible for producing them. It then rambles on about what goes in an invoice which everyone already knows anyway. Such a statement does not belong in a requirements specification.
The second ‘requirement’ compounds the problem by looking solid but really being vague and ambiguous. What does pertinent information mean? To enable a customer to supply payment is superfluous since that’s what an invoice is for. The statement, while accurate, contributes nothing towards our understanding of what the system must do to be successful.
Here are some more ‘better’ statements of requirements:
- A customer account record must contain a unique account reference, a primary contact name, contact details and a list of all sales to the customer within the past sales year
- Contact details must consist of a phone number, an address and an optional email address
- For each contact up to five separate phone numbers should be catered for
Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.