Functional requirements and nonfunctional requirements in software engineering explained
Clearly defining both functional and nonfunctional requirements in software engineering projects is important from both a business perspective and a performance perspective. In this expert response, Sue Burk offers definitions and examples for both functional requirements and nonfunctional requirements.
What is the difference between functional and nonfunctional requirements in software engineering? Can you give examples of each?
The International Institute of Business Analysis (IIBA) defines functional requirements as “the product capabilities, or things that a product must do for its users.”1 Functional requirements define how software behaves to meet user needs. For example, imagine a health insurance company designing a claims system. There will be functional requirements such as “Determine Claimant Eligibility,” “Adjudicate Claim,” and “Pay Claim.” These high-level functional requirements will also include many detailed functional requirements. For example, “Pay Claim” might include the functional requirement “Determine Payee” (the insured or the service provider).
The IIBA defines nonfunctional requirements as “the quality attributes, design and implementation constraints, and external interfaces which a product must have.”2 Quality attributes are often affectionately called the “ilities” because the names of many of them end in “ility.” Examples of quality attributes include availability, maintainability, performance, portability, reliability, robustness, security, scalability, testability, usability, and others. Many nonfunctional requirements are global in nature; they apply to an entire system. Performance requirements -- such as requirement for response time or throughput -- are often global. Some nonfunctional requirements may apply to (or vary by) specific usages of the system. For example, 24×7 availability may be needed for some, but not all, of the users of the system.
Depending on your organization’s approach to software development, functional requirements may be expressed as requirements statements, use cases, scenarios, or user stories. Nonfunctional requirements may be captured as narrative statements, formatted templates, or acceptance criteria.
Whatever approach you use to define requirements, it’s important to express functional and nonfunctional requirements precisely enough, from a business perspective, to make them testable. For example, stating that the system must be able to “Pay Claim,” or from a performance perspective, that “the system must be fast,” says everything and nothing at the same time. You can’t test either one objectively.
To make the functional requirement “Pay Claim” testable, you need to refine it by working with business subject matter experts to understand all its steps, along with the applicable data and rules. You also need to explore its variations; “Pay the insured” or “Pay the service provider” may have some differing steps, data, and rules. To turn the vague nonfunctional requirement for a “fast” system into a testable requirement, business subject matter experts need to provide measurable expectations for performance. A testable version of the performance requirement might read, “for <a specific usage> with <specific network load and concurrency>, the maximum amount of time between a user’s click of an “enter” key and the start of a response delivered to the user will be no more than six seconds 80% of the time, and never longer than nine seconds.”
1. International Institute of Business Analysis, Guide to Business Analysis Body of Knowledge® (BABOK®), 2nd edition. This definition, along with a major portion of the BABOK® glossary, is taken with permission from The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements by Ellen Gottesdiener (GOAL/QPC, 2005).
2. Ibid.
