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 non-functional 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.

Non-functional 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.

---

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference? 

---

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.

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 <system name> shall <system response>.

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 <in a specific state> the <system name> shall <system response>.

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 <trigger> the <system name> shall <system response>.

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 <feature is included> the <system name> shall <system response>.

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 <trigger>, THEN the <system name> shall <system response>.

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 <optional feature>, while <precondition(s)>, when <trigger> the <system name> shall <system response(s)>.

Template:   (Unwanted behavior) Where <optional feature>, while <precondition(s)>, if <trigger> then the <system name> shall <system response(s)>.

Example:     While the aircraft is on the ground, when reverse thrust is commanded, the control system shall enable deployment of the thrust reverser.

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 require­ments). 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-func­tional 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 refer­enced 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 them­selves. 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 stipula­tion 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 <Overtemp Alert> to TRUE within 0.5 seconds when <Engine Temp> equals or exceeds 215° F.

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.

---

RELATED POST: Requirements Management Tools and Software

---

What is a Functional Requirements Document?

A function 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.