Tag Archive for: Functional Requirements

non-functional requirements
In this post, we look at non-functional requirements are tracked by agile product teams and how they impact the product development cycle.


Imagine that you’re in the market for a new car. As you shop, you have a couple of non-negotiable features or attributes in mind, such as saving destinations within the car’s built-in GPS navigation system or that the car must be black. Although you may consider these to be “must-have” features, they would be considered non-functional requirements tied to the user experience.

What are Non-Function Requirements (NFR)?

Non-functional requirements are global constraints on a software system e.g., development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability, and portability.

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Non-functional requirements may be found in adverbs or modifying clauses, such as “The system prints invoices quickly” or “The system prints invoices *with confidentiality.”

Software has non-functional requirements that are essential to creating a positive experience for the user. And if you miss the mark on these requirements, you may have scheduling delays, budget setbacks and unsatisfied clients.

A project that lacks non-functional requirements may also lack clarity, which can result in vague project scope and a disconnect between the designer and client expectations.

Non-functional requirements bridge the gap between what developers believe customers want and what customers really want.

One study found that 60 to 80 percent of the cost of software development involves rework. And when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.

So, now that we’ve defined non-functional requirements, how do you integrate them effectively into your product development process?

Non-functional requirements focus on the “ilities” of the product

The “ilities” of a product include quality, reliability, manufacturability, usability, serviceability, upgradeability, etc. See SEAri MIT for more information.

Non-functional requirements focus on the user experience. A non-functional requirement is a statement defining a system quality, constraint, or external interface. For example, you might want to build a system that can manage expansion in the future. But saying so isn’t enough. You need to be specific. Instead, you might define that as “building a system that can manage at least 50,000 users over the next 24 months, so customers don’t experience the frustration of system crashes.”

Additionally, a non-functional requirement may:

  • Follow any legal or adherence rules.
  • Define quality attributes of the software.
  • Ensure performance in key areas such as reliability, availability, scalability, and more.
  • Focus on the user experience so the system is easy to operate and the risk for potential rework is minimized.

Just as with car shopping, not everyone needs the same features to make their user experience great. You might want warming seats in a new car, but somebody else might want a third row of seats. So, the non-functional requirements that you define for your project will vary based on client expectations. A list of potential categories, however, can give you a starting point to consider which non-functional requirements need to be on your list.

What are the different types of non-functional requirements?

Think about non-functional requirements as buckets that hold attributes important to the user experience. Remember, it’s not what a product will do (which are its functional requirements), but it’s what a project will be.

If you have selected the right buckets and measured the right things, then you can feel confident that you’re handing over a product that will meet customer expectations – because you’ve clearly defined these expectations up front. Everyone is on the same page, which is even further enhanced when you centralize your requirements management, which we’ll touch on shortly.

For now, let’s look at some of the potential categories for non-functional requirements:

  • Performance and scalability. What are the required response times, benchmark specifications, and other attributes related to performance? How fast does the system provide results, and how will the performance change with higher workloads?
  • Operating constraints. Operating constraints may include any required software requirements, system requirements, and run-time constraints that need to be considered in product development.
  • Platform constraints. Most projects include some sort of platform constraints. Clearly define these upfront.
  • Modifiability. How much effort is required to make changes to the software? Defining this upfront can help the customer better plan for any potential changes.
  • Portability requirements and capability. How difficult will it be to move the software to a different platform? What hardware and operating system does the software run on? Does it conflict with other processes or applications within these environments? Clearly define these elements.
  • Reliability. How often does the software fail? Outline any consequence of software failure and strategies for detecting errors, plans for error correction, and more.
  • Security. Security focuses on the requirements for protecting the system and data. How much time and effort does it take to break into the system, and how can you mitigate these exposures?
  • Usability. Usability is focused on the user experience. How difficult is it to learn and operate the system, and how can you improve any potential uses?
  • Legal. There may be legal issues around data privacy, intellectual property rights and more.

Categories vary by project, yet some common categories include availability, capacity, reliability and security. Using a few of the more common ones to start and then expanding to other areas can help you build a template for new product development projects.

Functional vs. non-functional requirements: What’s the difference?

Attributes of Functions vs Nonfunctional Requirements

Functional requirements are focused on how the software needs to perform or the desired behavior of the system. For example, if a specific condition is met, a system will send a new user a welcome email. A functional requirement is focused on what the system does when a requirement is met. Other functional requirements might involve business rules, reporting requirements, audit tracking, and more.

A non-functional requirement focuses on properties and characteristics of the product that are generally passive. Non-functional requirements are focused on attributes such as privacy, portability, reliability, stability, and more.

What is a non-functional requirements document?

Non-functional requirements are one component of the software requirements specification document (SRS document). This document focuses on what the software is expected to do and how it’s expected to perform. It also addresses what is required in terms of functionality from a user perspective.

The SRS documents include a few sections, such as:

  • Overview of the system. The overview includes high-level details about the system. Any useful terms are defined upfront in a glossary-like format.
  • General description. This section outlines any assumptions about the project and the overarching vision or theme.
  • Specific requirements. This section is where the functional and non-functional requirements are included.

If you haven’t written an SRS document before, or if you want to improve on your existing document, check out examples as a starting point. These also provide inspiration for how non-functional requirements examples flow into the entire document.

What templates exist for tracking and managing a non-functional requirement?

Software and hardware teams collaborate throughout the entire development process as they define functional and non-functional requirements. However, this collaboration becomes problematic when teams use different tools. Centralizing requirements management allows you to save time, align more effectively, and ensure the quality and compliance of product development. Using a single solution enables you to effectively:

  • Experience a single source of truth. A single source of truth offers greater visibility throughout the entire product development cycle.
  • Benefit from real-time iteration. Working within a requirements management platform that has visibility and communication across all development teams enables more informed decisions and improves collaboration abilities.
  • Enjoy stronger visualization. You can more effectively visualize how tests trackback to requirements, resulting in higher quality and compliance.
  • Reuse validation requirements. Reuse validated requirements to quickly replicate features across products.

Centralizing requirements management allows you to build stronger and more effective non-functional requirements, which improves product development. A single source of truth empowers you to connect data, conversations, and decisions – all within a single system.

The result is that you can collaborate and communicate critical pieces of information around product development, resulting in less rework, fewer missed deadlines and happier clients.

See How Jama Connect Streamlines Tracking and Tracing Requirements. 



Functional Requirements

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:

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.



functional vs nonfunctional requirements

If you’ve ever started a new project only for it to transform into a huge challenge later in the process, you know that upfront, clearly defined requirements are critical to success. Defining requirements upfront allows you to effectively manage client expectations and create an implementation process that is smooth and seamless.

A project that lacks this upfront clarity, however, can lead to a vaguely defined project scope and results that miss the mark. A study by the Carnegie Mellon Software Engineering Institute found that 60 percent to 80 percent of the cost of software development is in the rework. Furthermore, successful requirements management can eliminate 50 percent to 80 percent of project defects.

So, how can you ensure that your requirements are more accurately and clearly defined? It starts with understanding the key differences between functional and non-functional requirements and understanding the role that each plays in the success of your project.

Functional vs. nonfunctional requirements: What’s the difference?

Functional requirements focus on what the project should do, and non-functional requirements focus on how it should be. Let’s break it down a little further.

What are different uses cases of functional requirements and non-functional requirements? 

functional vs nonfunctional requirements

What is a functional requirement?

Functional requirements focus on how the software must perform and specify the desired behavior of the system; for example, when specific conditions are met, the system will send a new user an email. Another example is that only employees on the management level can view salary data. More examples of functional requirements include those related to the following:

  • Audit tracking
  • Reporting requirements
  • Authorization levels
  • Legal or regulatory requirements
  • Business rules
  • Administrative functions
  • Certification requirements
  • Reporting requirements
  • External interfaces

RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships


What is a non-functional requirement?

Non-functional requirements are critical to the usability of a software system, and if you don’t define them carefully, the end users’ experience can be adversely affected. An example of non-functional requirements is defining how fast a website must load or specifying that a website must handle 10 million users without having any performance challenges. Non-functional requirements can also be related to security; for example, a user must change their initial login password upon logging in the first time. More examples include those related to:

  • Compliance
  • Documentation
  • Privacy
  • Portability
  • Quality
  • Reliability
  • Resilience
  • Response time
  • Scalability
  • Stability

Non-functional requirements are focused on the system’s operation rather than its behaviors; for example, data must be updated for users during access within three seconds. Non-functional requirements can also be defined by metrics and relate to aspects of the system that evolve over time, such as manageability or documentation.

Attributes of Functions vs Nonfunctional Requirements

functional vs nonfunctional requirements

When comparing functional vs. non functional requirements, consider that a functional requirement might ensure the system loads a specific web page when the user clicks on a button. The non-functional requirement might dictate how fast the site loads. A website that loads slowly can adversely affect the user experience, which is why non-functional requirements are critical.


RELATED POST: 8 Do’s and Don’ts for Writing Requirements


What are user stories and how do they help?

When considering requirements and defining those requirements, you’ll find it helpful to consider integrating user stories. A user story is basically the description of a software feature from the user’s perspective. The story defines what you want the system to do and how that affects the overall experience. A basic formula might look like the following:

  • A <define user type> wants <specify the specific goal> so that <include a specific reason>

Acceptance criteria should also be included with user stories, which are the conditions the product needs to address to be acceptable to the client. Create at least one acceptance criterion for each user story. A few examples may include:

  • A search field needs to be placed on the top bar of the website
  • A search is started once the user hits the “submit” button
  • The display language is English
  • No more than 150 characters can be typed into the search box

User stories are helpful in the context of non-functional requirements, as they allow you to take a deeper dive into the user experience and see how to make that process smoother.

Why are metrics used more in nonfunctional vs. functional requirements?

Non-functional requirements help companies measure the success of a system, so they must be measurable. The metrics must be qualitative and quantitative. You might require, for example, that a system be able to handle expansion in the future. That’s a qualitative goal, but let’s take it a step further and make it quantitative as well. You might require that the system handle at least 30,000 users within the next three years.

The benefit of focusing on quantitative goals is that the goal is easily measured and you and the client can agree on what success looks like.


RELATED POST: Checklist: Selecting a Requirements Management Tool


What are requirement specifications? What is a requirements specification document? 

A software requirements specification document, also known as an SRS document, addresses what the software will do and expectations with regard to its performance. The document also highlights what the product needs in terms of user functionality. Most documents include an overarching purpose and define functional and non-functional requirements. A few sections that you may want to include in your SRS document include:

  • Include a brief overview of the system, along with any relevant background details and terms that need definition upfront.
  • Overall description. Include any assumptions made about the project, its business values, and the overarching project vision.
  • Specific requirements. Define specific attributes to be included in the system, functional requirements, and any relevant database requirements.

If you want to view an example of an SRS document, Michigan State University has one that can give you a starting point for creating your own document.

Tracking Requirements: Why Traditional Documents May Miss the Mark

Traceability is critical to project success. Gartner highlights one of the main reasons why companies struggle to achieve the benefits of traceability:

“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

Software and hardware teams must work together and collaborate throughout the development process to define market requirements, functional vs. non functional requirements, test cases, and other critical pieces of information. This becomes a challenge, however, when teams use different tools and terminology and work with different methodologies.

The answer is to connect data, conversations, and decisions in a single system in the product development process. This gives you the ability to consult and collaborate with people about requirements within the system, capture decisions and actions, and keep that information associated with the requirement. Down the road, if you need to revisit decisions, all data is stored and easy to find.

Moving Forward with Functional vs. Nonfunctional Requirements

Every software project has a vision, a goal, and a destination that you want to reach. Functional and non-functional requirements help you to reach that goal more easily through setting clear boundaries. These requirements help you answer the most critical questions and ensure that products are developed with success in mind.

Functional requirements vs. non functional requirements are critically important, but since non-functional goals are focused heavily on the user experience, these are arguably more critical. Understanding the role of each category empowers you to define and track each with greater success and create a road map that delivers on your client’s expectations.


Learn more about how Jama Connect streamlines tracking and tracing requirements.

SEE THE SOLUTION