Functional requirements examples and templates
The Essential Guide to Requirements Management and Traceability
Functional requirements examples and templates
When we buy a new cell phone or TV or computer, do we buy-in for what it is?
Of course not. We buy it for what it will do for us.
Likewise, when companies or governments buy new systems or new enterprise software products, they couldn’t care less about the products themselves. What they care about is how those products will help them accomplish their goals, make them more efficient, and positively impact their bottom line or use of budget.
It’s what the product does that’s important.
In general, the first step in determining what a product does—what its functions are—is to determine its functional requirements.
What are functional requirements? And what is their role in product development?
In this article, we’ll answer those questions, provide examples of typical functional requirements and types of requirements, and offer tips for crafting good functional requirements and good functional requirement specifications.
What are functional requirements in product development?
A functional requirement is a statement of what a product (system, subsystem, system component, device or software program) must do.
Types of functional requirements include prescriptions of (rules for):
- Operations and workflows the product must perform (i.e., the functional details of the product’s features)
- Formats and validity of data to be input and output by the product
- User interface behavior
- Data integrity and data security requirements
- What the product must do to meet safety and other regulatory requirements
- How the system validates user access/authorization for use and modification of the system
The difference between functional requirements and nonfunctional requirements
The term functional requirements implies there must also be a group classified as non-functional requirements. That is indeed the case. Here are definitions of both:
A functional requirement is a statement of what a product (system, subsystem, device, or software program) must do.
Example: The control system shall prevent engine overspeed.
A non-functional requirement is a statement of what a product is or how it will be constructed, or a constraint on how the product will be designed or will behave.
Example: Serial-digital communication between the system’s subsystems shall be accomplished via MIL-STD-1553B bus(es).
Functional Requirements
As mentioned, functional requirements state what the product must do. In other words, they define the operation of the product. As such, they should normally be stated in terms of what the product’s outputs do in response to its inputs.
In product development, functional requirements are typically decomposed into more detailed requirements at progressive levels of the design process. Their fulfillment is verified and validated through functional testing (software testing, integration testing, etc.). Functional requirements are always mandatory; they must be met by the product unless the requirement is changed.
Nonfunctional Requirements
Non-functional requirements state constraints on the design and construction of the product. They are often dictated by contractual or regulatory requirements, which may include, among others:
- Standardization requirements
- Compatibility requirements
- In-service support requirements
- End-of-life disposal requirements.
Non-functional requirements are not often decomposed into more detailed requirements. They are typically verified by inspection of the product and its documentation. Non-functional requirements will be mandatory if dictated by contractual or regulatory requirements. They may not be mandatory, however, if dictated by marketing goals or other internal objectives, as often occurs in consumer product development.
Forms and examples of functional requirements
Functional requirements can come in many forms. Some forms, however, are better than others. A general requirements engineering (RE) best practice is to write requirements that are as clear and concise as possible.
Engineer Alistair Mavin, developer of the Easy Approach to Requirements Syntax (EARS), has identified five requirements archetypes—and a simple template for each—that can be used to craft clear, concise requirement statements that cover practically all functional specification needs.
Real-World Examples of Functional Requirements Across Industries
Functional requirements are vital for defining what a product must do to meet user and organizational needs. To truly bring this concept to life, here are real-world examples of functional requirements across various industries, including software development, automotive, healthcare, and e-commerce.
1. Software Development
Functional requirements in software development often define how a system operates, controls, or interacts with users.
Example 1:
Requirement: The system shall display search results within 0.5 seconds of the user entering a query.
Context: For a search engine or content management platform, fast response time is critical to ensure a smooth user experience.
Example 2:
Requirement: When a user attempts to log in with incorrect credentials three times, the system shall lock the user account for 10 minutes.
Context: This is designed to enhance security by preventing unauthorized access through brute-force attacks.
2. Automotive Industry
The automotive sector often focuses on safety, performance, and user interaction. Functional requirements here ensure vehicles meet regulatory and customer expectations.
Example 1:
Requirement: The vehicle’s lane assist system shall alert the driver with an audible beep when the car drifts from its lane without signaling.
Context: This feature enhances safety by providing drivers with real-time feedback to avoid accidents.
Example 2:
Requirement: When the airbags deploy, the vehicle shall automatically notify emergency services with the GPS location within 30 seconds.
Context: This functionality supports rapid response during accidents, potentially saving lives.
3. Healthcare
Healthcare applications, whether software-based or medical devices, have stringent functional requirements to ensure patient safety and compliance with regulatory standards.
Example 1:
Requirement: The electronic health record (EHR) system shall retrieve a patient’s medical history within 3 seconds upon request.
Context: This is essential for healthcare professionals to access critical information quickly, especially in emergencies.
Example 2:
Requirement: The insulin pump shall deliver the prescribed insulin dosage within a tolerance of ±1% to the specified volume at the programmed time intervals.
Context: Precision is critical to ensure patient safety and maintain blood sugar levels effectively.
4. E-Commerce
Functional requirements in e-commerce focus on usability, security, and efficient transactions to enhance customer satisfaction and trust.
Example 1:
Requirement: The e-commerce platform shall process credit card payments and provide a transaction confirmation within 5 seconds of user submission.
Context: This ensures a seamless checkout experience and reinforces customer trust.
Example 2:
Requirement: When a product is out of stock, the system shall display an out-of-stock notification and disable the “Add to Cart” button.
Context: This helps manage customer expectations and prevents frustration caused by unfulfilled orders.
Common Mistakes to Avoid When Writing Functional Requirements
Crafting functional requirements is a crucial step in the product development process. However, even experienced teams can fall into common pitfalls, leading to miscommunication, delays, and costly errors. To help you avoid these issues, here are some typical mistakes and their potential impacts, along with practical examples.
1. Writing Vague or Ambiguous Requirements
One of the most common mistakes is failing to write clear and specific requirements. Ambiguity can lead to confusion among developers, testers, and stakeholders, resulting in inconsistent implementations.
Example Mistake
Requirement: The system should process requests quickly.
Impact: Without a measurable standard, “quickly” could mean seconds to one person and minutes to another, leading to unmet expectations.
How to Avoid
Be precise. Rephrase the requirement to something like:
- The system shall process requests and deliver a response within 0.3 seconds.
2. Combining Multiple Requirements into One
Overloading a single requirement statement can make it hard to implement, understand, or test properly.
Example Mistake
Requirement: The system shall validate user credentials, display a welcome message, and send a verification email.
Impact: This statement covers several actions that should be distinct, making traceability and testing difficult.
How to Avoid
Break it into multiple requirements:
- The system shall validate user login credentials.
- If login is successful, the system shall display a welcome message.
- The system shall send a verification email upon successful registration.
3. Mixing Functional and Non-Functional Requirements
Another frequent error is combining functional requirements (what the system does) with non-functional requirements (how the system performs).
Example Mistake
Requirement: The system shall process up to 1,000 transactions per second and ensure user data security.
Impact: Performance requirements (non-functional) and security measures (functional) are conflated, complicating design and verification.
How to Avoid
Separate these into distinct requirements
- Functional requirement:
- The system shall ensure user data is encrypted during transmission.
- Non-functional requirement:
- The system must process up to 1,000 transactions per second.
(See Functional vs. nonfunctional requirements: What’s the difference?)
4. Ignoring Testability
Requirements that cannot be verified lead to inefficiencies in the development and testing process.
Example Mistake
Requirement: The system shall provide an exceptional user experience.
Impact: “Exceptional user experience” is subjective and not directly testable.
How to Avoid
Define measurable criteria:
- The system shall achieve a score of 90 or higher on standardized usability testing.
5. Overloading with Technical Jargon
Using overly technical or niche language can alienate non-technical stakeholders and create barriers to collaboration.
Example Mistake
Requirement: The application’s backend must support asynchronous message queuing through a JMS-compliant interface.
Impact: This phrasing might confuse stakeholders unfamiliar with these terms, delaying approvals.
How to Avoid
Use clear and straightforward language without losing technical accuracy:
- The system shall enable message queuing with support for asynchronous processing.
6. Failing to Include Rationale
When the purpose of a requirement isn’t clear, it leaves room for misinterpretation or challenges during implementation.
Example Mistake
Requirement: The system shall log every user action.
Impact: Developers might implement extensive logging that impacts performance because the reason for detailed logs isn’t explained.
How to Avoid
Include rationale:
- The system shall log every user action for security auditing and compliance purposes.
7. Not Regularly Reviewing Requirements
Requirements that are not reviewed and updated throughout the project lifecycle risk becoming outdated or incomplete.
Example Mistake
Failing to account for regulatory changes that require adjustments to existing requirements.
Impact: This can lead to costly rework if requirements need updates late in the development process.
How to Avoid
Schedule regular reviews with key stakeholders to ensure requirements remain relevant and consistent with the project’s goals.
8. Over-Engineering the Requirements
Including excessive detail or edge cases in requirements can burden the development process and extend timelines unnecessarily.
Example Mistake
Requirement: The system shall display 20 different font styles for every text field customization.
Impact: Overly complex requirements can divert resources from critical functionality and strain timelines.
How to Avoid
Focus on core needs and gather user feedback to determine reasonable scopes.
Ubiquitous Requirements
The first of these archetypes is the ubiquitous requirement.
Ubiquitous functional requirements are always active. They are not invoked by an event or input, nor are they limited to a subset of the system’s operating states.
Template: The shall.
Example: The control system shall prevent engine overspeed.
State-driven Requirements
State-driven functional requirements are active throughout the time a defined state remains true. In Mavin’s EARS method, state-driven requirements are identified with the keyword WHILE.
Template: WHILE the shall .
Example: While the aircraft is in-flight and the engine is running, the control system shall maintain engine fuel flow above ?? lbs/sec.
Event-driven Requirements
Event-driven functional requirements require a response only when an event is detected at the system boundary. In other words, they are triggered by a specific event. The EARS method identifies event-driven requirements with the keyword WHEN.
Template: WHEN the shall .
Example: When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition.
Optional Feature Requirements
Optional feature functional requirements apply only when an optional feature is present as a part of the system. These requirements are identified by the EARS method with the keyword WHERE.
Template: WHERE the shall.
Example: Where the control system includes an overspeed protection function, the control system shall test the availability of the overspeed protection function before aircraft dispatch.
Unwanted Behavior Requirements
Unwanted behavior functional requirements cover all undesirable situations. Good systems engineering (SE) practice anticipates undesirable situations and imposes requirements to mitigate them.
Unwanted behavior requirements are often imposed when the system must respond to a trigger under less than optimum conditions. The EARS method uses the keyword combination IF/THEN to identify requirements aimed at mitigating unwanted behavior.
Template: IF, THEN the shall.
Example: If the computed airspeed is unavailable, then the control system shall use modeled airspeed.
Complex Requirements
Often, a specific set of one or more preconditions (states or optional features) must be present before the occurrence a specific event for that event to trigger a required system response. In such cases, the EARS templates may be combined, using a combination of the keywords.
Complex requirements can be composed for desired behavior or for unwanted behavior. The EARS method provides a template for each.
Template: (Desired behavior) Where, while <precondition(s)>, when the shall .</precondition(s)>
Template: (Unwanted behavior) Where, while <precondition(s)>, if then the shall .</precondition(s)>
Example: While the aircraft is on the ground, when reverse thrust is commanded, the control system shall enable deployment of the thrust reverser.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started with a free 30-day trial, or book a demo!
Tips for writing good functional requirements
Writing clear, accurate functional requirements is a valuable engineering skill that requires some practice to develop. That’s why many engineering organizations compile guidance on writing requirements, like the Guide for Writing Requirements published by the International Council on Systems Engineering (INCOSE).
An exhaustive list of such guidelines is beyond the scope of this article, but here are six important tips to bear in mind when composing functional requirements:
1. Be consistent in the use of modal verbs
A modal verb, modal or modal auxiliary is a word such as “shall,” “must,” “will,” or “should” which is used with a main verb to express ideas such as necessity, intention, expectation, recommendation, or possibility.
In engineering specifications, modal verbs are used to distinguish between binding requirements, non-binding recommendations, and the expected behavior of the system’s operational environment. As such, it is important that requirements authors be consistent in their use of modal verbs and that they convey to developers, testers, quality assurance engineers, and regulatory authorities exactly how each modal verb is intended to be interpreted within their specification.
The use of modal verbs in specifications has long been a subject of debate in the SE/RE community. The consensus, however, is that “shall” and “must” are the best modal verb choices for expressing requirements, while “will” should be used to express expected external behavior or declarations of purpose. Non-binding recommendations or provisions can be expressed with “should” or “may.”
Also, many organizations use the word “must” to express constraints and certain quality and performance requirements (non-functional requirements). The use of “must” allows them to express constraints without resorting to passive voice and to easily distinguish between functional requirements (expressed with “shall”) and non-functional requirements (expressed with “must”).
It is good SE/RE practice to define exactly how certain terms will be used within the document itself, and how they should be interpreted when found in non-requirements documents referenced by the document. This is usually done in a dedicated section toward the beginning of the specification.
2. Tag each requirement with a unique identifier
Another SE/RE best practice is to tag each requirement with a unique ID number or code.
In fact, requirement identifiers are often a requirement themselves. Systems purchased under a contract between a customer and a supplier—as in the case of most government-purchased systems, for example—are normally developed following an accepted industry standard like IEEE/EIA 12207 as a stipulation of the contract. Such standards typically require that each requirement in every requirements document be tagged with a project unique identifier (PUI).
Assigning unique identifiers to requirements conveys a big benefit to the system developer.
Tagging each requirement with a PUI facilitates and simplifies traceability between requirements at successive design levels and the tests that verify them. Brief identifiers make it easy to build traceability tables that clearly link each requirement to its ancestors in higher-level documents, and to the specific tests intended to verify it. Traceability tables simplify the process of demonstrating to the customer and internal stakeholders that the system has been developed to, and proven to comply with, the agreed top-level requirements.
Automated requirements management tools typically include an automatic method of assigning unique identifiers, which streamlines this process.
3. Write only one requirement in each requirement statement
Beware of long, complex requirement statements that include the word “and” and more than one modal verb.
When trying to define a complicated functionality, it’s easy to fall into the trap of describing it all in a single paragraph or, worse yet, in a single sentence. Take the time to analyze long requirement statements. If they contain the word and or multiple “shalls” or other modals, they likely contain more than one requirement. Re-write them to obtain two or more simple requirement statements, each with its own shall. Then, give each its own unique identifier.
4. Write requirements statements as concisely as possible
Another reason to analyze and re-write long requirements, even those with a single shall, is that long requirements are more likely to be misinterpreted than short, concise requirements.
It is good SE/RE practice to write requirements that are as concise as possible. Requirements templates, like the EARS patterns described earlier, can be of great assistance in meeting this objective.
5. Make sure each requirement is testable.
Each time you write a new functional requirement, you should ask yourself the following question:
How will the successful implementation of this requirement be verified?
Writing requirements with a specific test scenario in mind helps ensure both design and test engineers will understand what they have to do.
The specific test case will influence how detailed the requirement will need to be. High-level requirements are often tested by inspection or through user testing and thus may be broad in scope. Lower-level requirements that will be verified through software testing or system integration testing will necessarily be specified to a finer degree of detail.
For example, a best practice for ensuring testability is to specify a maximum reaction time for any output the software must produce in response to a specific input condition, as in this example:
3.8.5.3.1: The Engine Monitor shall set
6. Clearly segregate requirement statements from rationale and other explanations.
In requirement specifications, it’s useful to include the rationale for the requirement, its relationship to other requirements, and other explanation to provide context for developers and testers.
Context can help prevent misinterpretation by clearing away possible ambiguities. It can help others fully understand the intent of the requirement and provide feedback that can help refine the requirement and make it even more unambiguous.
But contextual information should not be included in the requirement statement itself. It’s important to segregate the two to keep the requirement itself clear and concise, and to avoid making the additional information subject to implementation and test. It’s a best practice to put contextual implementation in a separate paragraph that does not contain a unique identifier.
A good Functional Requirements Document template or Requirements Management tool can make this goal easier to achieve.
What is a Functional Requirements Document?
A functional requirements document (FRD)—also known as a functional requirements specification, functional specification, or functional specification document—is a more technically detailed follow-on to the higher-level Product Requirements Document (PRD).
The FRD describes what is needed by the system user, typically in terms of the system’s outputs as functions of its inputs. It is built to provide precise functional requirements—along with guidance to developers and testers—following analysis and decomposition of the requirements in the PRD.
An FRD does not define the inner workings of the system to be developed or how the system’s functions will be implemented. Instead, it focuses on what various external agents (users, peripherals, other systems or subsystems) should observe when interacting with the system. It communicates:
- To developers: what they need to build
- To testers: what tests they need to perform
- To stakeholders: a detailed description of what they’re going to get
For highly complex systems, functional requirements may be decomposed through a series of functional specifications that may include:
- System specification
- Subsystem specifications
- System component specifications
- Software requirements specifications
In some industries and organizations, the functional specification will normally be part of a larger specification that also contains the non-functional requirements applicable to the system or subsystem to be designed. Nevertheless, those non-functional requirements will typically be segregated from the functional requirements.
Tips for compiling a good FRD
Putting together a cohesive, usable and easily navigable and FRD can be a challenge. Here are a few guidelines that can be helpful.
1. Organize the document in a hierarchical structure
To make your FRD easy to understand and use, organize it using a hierarchical structure. Suitable hierarchies can include (among others):
- Mission/phase/function
- Function/subfunction
- Feature/use case
A hierarchical specification structure provides several benefits, including:
- Helps contributors focus on each specific domain that needs to be addressed
- Helps contributors easily find areas they need to modify when adding functionality to an existing system
- Helps users (developers, testers) quickly drill down to the exact functional area they are looking for
2. Standardize your requirements language
Spoken languages are full of words that have multiple definitions and which evoke subtle shades of meaning, depending on context. While great for self-expression, such broad flexibility can lead to confusion and disagreement when it comes to specifying and interpreting requirements.
A good way to reduce ill-definition and misinterpretation of requirements is to standardize some of the language used to express them. Create a glossary of standardized terms toward the beginning of your requirements document. In this glossary, define exactly how certain terms will be used within the document itself, and how they should be interpreted when found in non-requirements documents referenced by the document.
Strictly defining terms and adhering strictly to your definitions will not only reduce confusion among those tasked with interpreting your requirements; with practice, using standardized language will also save you time in writing requirements.
3. Use a good FRD template or a dedicated RM platform
When building any type of structure, it’s wise to start from a solid foundation or a proven model. When building a functional requirements document, it’s best to start from a good template.
A good template will include standardized sections such as:
- Guidelines for the use of modal verbs
- Glossary of standardized terms
- Guidelines for documenting requirements
- Guidelines for managing requirements documentation
- Other guidelines your organization follows
Standardized sections—or “boilerplate”—promote and facilitate consistency across projects, which is a major benefit of templates. These sections tend to remain little changed from project to project, and from team to team within a company. They evolve only slowly over time with changes in methodology and lessons learned. Thus, they provide a stable platform for consistent requirements development, employee education, and communication with customers.
There are many general FRD templates available on the web. If you develop commercial products you may find one of the following can be tailored to your company’s practices and procedures:
- https://almooc.com/downloads/FRDTemplate.doc
- https://doit.maryland.gov/SDLC/Documents/func_req_doc.doc
- https://www.sampletemplates.com/business-templates/functional-requirement-document.html
If your company develops systems or software for the U.S. Department of Defense, on the other hand, you might prefer a system specification template built to MIL-STD-961E (Department of Defense Standard Practice: Defense and Program-Unique Specifications Format and Content). QRA Corp offers one on their website: https://qracorp.com/requirements-document-templates/.
The drawbacks of templates
One caveat to the last tip: using a template in a general documentation platform has a couple of drawbacks. First, documenting requirements in Word, Excel or Google Docs tends to make collaboration cumbersome. Second, those platforms are not built to support clear and systematic requirements traceability.
Gartner says that one of the main reasons companies struggle to achieve adequate visibility and traceability in their requirement specifications is reliance on general document software rather than a collaborative requirements management platform.
“The most widely adopted tools for requirements continue to be general document software such as Microsoft Office or Google Docs (40% to 50% of the market) due to cost, availability, and familiarity. Yet these often lead to poorly managed requirements, thus eliminating and exceeding any cost benefit the tools themselves have. Requirements end up captured in a variety of documents and spreadsheets supplemented by post-it notes in unmanaged versions with no traceability or reuse. This creates a more costly user acceptance testing cycle, both in the time to execute as well as remediation of issues found late in the process, where they are far more costly to address.” – Gartner Research
Successful development, verification, and validation of good functional requirements are critical to product success. To achieve these goals system, software, hardware, test, and integration teams all must work closely together to assure the project’s functional requirements, non-functional requirements, test cases, and verification/validation procedures are all adequately defined. Visibility and traceability are critical to this process.
A good requirements management (RM) platform will provide fields, formatting, and structural relationships to facilitate:
- Portability of boilerplate sections from project to project
- Requirements definition and identification
- Traceability to higher-level (parent) and lower-level (child) requirements
- Traceability to test cases
Beyond those basic facilities, a state-of-the-art RM platform will also facilitate team collaboration by allowing all users access to your latest requirements baseline and all pending changes to it. This makes requirements tracking, traceability, and test coverage assurance far easier to accomplish than can be done using a document or spreadsheet.
Learn more about how Jama Connect streamlines tracking and tracing requirements. See the solution.
In This Webinar, Learn the Difference Between Functional & Non-Functional Requirements
Book a Demo
See Jama Connect in Action!
Our Jama Connect experts are ready to guide you through a personalized demo, answer your questions, and show you how Jama Connect can help you identify risks, improve cross-team collaboration, and drive faster time to market.