Functional requirements (often also referred to as Conceptual Requirements) address the needs of a user that interacts with the business environment (business, department etc and their systems.). System requirements address the needs of a user that interacts with the computer systems, ONLY. In one instance the business is the boundary and another instance the system is the boundary. Therefore an oversimplified equation is Functional Requirement = Workflow + System Requirements. What is key to this definition is the boundary.
To illustrate: lets say you want to join a library. As a prospective member you interact with the library where the boundary includes all systems, books, librarians etc. However, after you’ve filled in and submitted your application forms, the librarian enters your details into the computer system.Back to our little equation: Functional Requirement (Member must be able to join library) = Workflow (member fills in form) + Systems requirement (Librarian enters details from form into computer/our system must be able to maintain member details).
Lets say you work in the account receivable department (which is one boundary) and you have a debtor system (which is the other boundary). Therefore paying an invoice becomes: Functional Requirement (Clerk must be able to record invoice payments) = Workflow (clerk prepares remittance advice and cheques) + System Requirements (Clerk enters remittance information/our system must be able to accept invoice payment).
The reason why you get different answers from different people is, the boundaries are unclear. For those of us who work with use-cases, the difference is obvious, because the square box we draw illustrates the boundary. Sometimes the square box represents the business, sometimes the department, and sometimes the systems. For the use case aficionados, it’s a box within a box within a box. This has smacks of the old Venn diagrams that we did at school. It’s a circle within a circle within a circle.
For those of us familiar with DFDs. We would draw bubbles for the workflow and the entry of details (as in the library case above). At some point we would draw an automation boundary around those areas we deem as system requirements.
Boundaries are important things.One of the questions to ask your colleagues and your supervisor, is, “please define the boundary for each of the columns on the traceability matrix”.
This answer is oversimplified, but I trust this helps a little bit.
Time permitting today I’ll answer your second implied question about the traceability matrix that you received from your supervisor.
Warm regards,
K