When you Google "Requirements Documentation Template" you will get over 270,000 hits! That's alot of "templates".... Over the last few decades various IT think tanks have deviced methods, based on impirical evidence, of what makes a good "Software Requirements Specification" (SRS), or "Functional Specification" as some like to call it, or whatever name you wish to give it; which, by the way, is part of the problem....

No doubt, one-size-fits-all does not work, as projects differ, organizational structures differ, etc, etc, etc....

Any organization - private enterprise, governmental, non-profit - has some way of operating.

To "operate" means to "to work, perform, or function", or "to act effectively; produce an effect", or "to perform some process of work", or "to carry on transactions", etc.

All these definitions have as a focal point the concept of a process. A process, of course, is based on some organizational rules, governmental policies, customer needs, organizational goals, etc. Furthermore, a process can't exist by itself; i.e. it needs something to process. In the IT industry (but certainly not limited to IT), that "something" is information, or data. Any IT process receives data, manipulates data, and provides data - otherwise you don't need the process.

I am currently working on a Traceability Matrix (Excel Template), that begins with a "Business Rule" column. A business rule is a precise statement of intent expressed in terms like "The user must be able to..." or "The application must manage client information in accordance with...", etc. A business rule is expected to be atomic, so that only one action is possible and ambiguity is elimintated. I quote the following definition I read earlier today on a website: "Business rules can be anything your organization uses to make an operational decision. ...enterprise, divisional, corporate and line of business policies, ... calculations and formulas, risk thresholds adn regulatory authorizations."