In response to your questions/statement on "Functional Requirements”:
I think you are using the term "Functional Requirements" in the context of a collection of requirements types that are documented as part of a section in a business requirements document, where other sections might be "Nonfunctional Requirements", "Operational Requirements" and "Transitional Requirements. On some projects, the Use Cases are contained in a document that is called the Functional Requirements.
I have found generally that Functional Requirements are defined by an attribute called “Requirement Type” and Functional is just one of several types of specific requirements that elaborate or support the steps in the use case.
An example is a Functional type requirement such as "The System must provide a list of values for the state abbreviation code". This elaborates the requirements for the step "The system prompts for the state".
The choice and definitions of the types of requirements are really up to the needs of the project. The intent of each Type must be clear and unambiguous to the stakeholders, developers, testers and operation Support team.
I would personally restrict to a small number of types, say 7 or less. The number 7 is that magical number of complexity beyond which people are generally unable to internalize. As you can see from my lists at the end of this response, if all of these Types and Classes were allowed, the project would probably suffer under the weight of managing them.
MY CHOICE OF REQUIREMENTS TYPES
BUSINESS RULE – All requirements set by the business to include limits, calculations, exclusions, inclusions. These should stem from business policies. Business Rules should be stated in a verbal manner that is understandable by the business. If there is the need for specific mathematical notation and expression, then consider a Technical Requirement.
TECHNICAL - Technical requirements are used only when there is some constraint that must be followed either due to system or business needs. Technical requirements are really a violation of the “What not How” rule of good requirements and should be used very sparingly. An example might be a very complex calculation from a business economic model that is very difficult to express in business terms. Another example is a particular data type that must be used because of an interface that can only accept data in a certain form. Consider alternate ways of capturing design or implementation types of requirements such as appendices with reference from a Business Rule or Functional requirement. The use of and specific instances of technical requirements should always be carefully reviewed and risks managed.
FUNCTIONAL - Desired behavior such as presentation and usability. Functional requirements should reflect the project style standards. These should replace step descriptions in the Use Cases such as “The System Presents a Pull-down list of state abbreviation codes” with “The System Prompts for the state code” and a Functional Requirement “The state code shall be selectable from a pull-down list of standard postal abbreviations”.
NONFUNCTIONAL – Nonfunctional requirements support the application or system with requirements such as those for response time, licensing requirements, help desk support and hours of operation.
OPERATIONAL – Requirement for operation of the application or system such as business process steps or scripts that must be run to load the monthly data for report generation. “Business process” does not mean application enabled transactions, but the business process may have a step in the Use Case where transaction data is entered. An example is “The clerk must obtain the approval code from the manager before approving the order”. Sometimes the operational requirement is more of the form “A process must be designed where the clerk obtains the approval code from the manager”.
TRANSITIONAL - Requirements to initialize or migrate from existing applications and systems. Often these requirements are executed one time as part of the deployment. Also, transitional requirements may include management controls on sign-off before deployment, but that may be covered already in the Project Management Methodology.
A QUICK COMMENT ON TESTABILITY
All requirements and requirement types should be considered to be testable. When the test plan and test case writers determine that a test cannot be reasonably stated, then this should be noted and a standard for Pass/Fail established to allow tracking of all requirements tests. Criteria for good requirements (that includes “must be testable”) is a separate discussion.
SOME EXAMPLES I’VE COLLECTED OF REQUIREMENT TYPES
Functional – Required functionality
Nonfunctional or non-functional – Required capability such as must be able to print to all local printers.
Business Rule – Derived from a policy or business rule statement such as a formula for profit.
Constraint – Minimum or maximum limits such as hours of operation and legal standards.
Domain - Is constraints due to the market or legal environment.
Performance – Response time, capacity or other needs that can be influenced by work load or system. These are often defined in terms of response time so that a performance team can monitor and tune.
Change Request – Indicates the requirement is driven by a change request. This should be a separate attribute so that the requirements type is visible.
Technical - This is a "How" in the requirements. Example might be "The system must generate the reports with leading zeros in all numeric fields and underscores where there a blanks in textual fields". This is used only where there is no option for design or implementation.)
Product - An example might be "The application executable must be no more than 1.5 MB".
Organizational – Requirements for process or roles must be defined such as “the approver is a higher level grade than the requestor".
External – Like environmental, such as “the system must adhere to the Privacy Act".
Operational – Requirements for process such as “the requestor must notify the approval that action is required”.
Transitional – Requirements for actions or process that must be conducted to initialize or migrate the system such as “the initial table of values must be entered before the legacy data is loaded”.
CLASS OF REQUIREMENTS – A SEPARATE ATTRIBUTE
Control – Requirements that automate data controls or other aspects of the system that ensure auditability such as “the total number of records in the output file must match the total number of records in the input file and all input record IDs must match those in the output file”.
Mandatory – Requirement to ensure various audits or controls are automated. Mandatory is similar to control type requirement.
Optional - Is often like "Should allow viewing as matrix or individual sets of attributes".
Desirable - Like Optional, but probably more general like "should automate email generation for notices."
Core – Is an essential requirement that supports all of the other requirements to provide the total desired functionality.