Functional and Nonfunctional Requirements: Specification and Types

Clearly defined requirements are essential signs on the road to a successful project. They establish a formal agreement between clients and providers that they are both working to reach the same goal. High-quality, detailed requirements also help mitigate financial risks and keep the project on schedule. According to the definition found in the Business Analysis Body of Knowledge (BABOK), requirements are a usable representation of a need.

In this article, we’ll discuss the requirements for software products and provide recommendations for their use.

Types of requirements

BABOK, a recognized set of business analysis industry standards, offers the following classification of requirements.

Business requirements

These include high-level statements of goals, objectives, and needs. Business requirements do not have any details or specific features. They just state the problem and the business objective to be achieved, such as

• increased revenue/throughput/customer reach,
• reduced expenses/errors,
• improved customer service, etc.

User (stakeholder) requirements

This group of requirements reflects the needs of discrete stakeholder groups (top-level managers, nonmanagement staff, customers, etc.) and defines what they expect from a particular solution. They serve as a bridge between generalized business requirements and specific solution requirements. They are outlined in a User Requirements Specification and can include, for example, the ability to create various reports, view order history and status, manage customer databases, etc.

Solution requirements

Solution requirements describe specific characteristics that a product must have to meet the needs of the stakeholders and the business itself. They fall into two large groups.

• Functional requirements define what a product must do and what its features and functions are.
• Nonfunctional requirements describe the general properties of a system. They are also known as quality attributes.

Transition requirements

An additional group of requirements defines what an organization needs to successfully move from its current state to its desired state with the new product. They are only necessary for a short time while the transition takes place. Examples include “users must pass the training to operate the system” or “previous data must be migrated to the cloud storage.”

This article explores functional and nonfunctional types of requirements. So let’s compare them side by side.

Functional vs nonfunctional requirements

Functional and nonfunctional requirements are two fundamental categories of requirements in software development. Each type plays a vital role in defining the characteristics and operation of the solution.

What are functional requirements?

Functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks. So it’s essential to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions.

Functional requirements examples

Functional requirements will vary for different types of software. For example, functional requirements for a website or mobile application should define user flows and various interaction scenarios.

The system sends a confirmation email when a new user account is created.

The system sends an approval request after the user enters personal information.

A search feature allows users to search content/items by entering the query in the search bar.

The user can review items in the cart, change their number, or remove them before checkout.

The app should allow users to create accounts and log in using credentials like email and password or through social media integration.

The app can send notifications to users for updates, reminders, or promotional content.

Users should be able to provide feedback or rate services/products within the app.

These are some common functional requirements. More specialized software systems will have more specific requirements. For example, a hotel property management system will include such requirements as “the user should be able to view and update room status” or “the system must aggregate bills from all points of service in a folio.”

What are nonfunctional requirements?

Nonfunctional requirements are not related to the system's functionality but rather define how the system should perform. They are crucial for ensuring the system's usability, reliability, and efficiency, often influencing the overall user experience. We’ll describe the main categories of nonfunctional requirements in detail further on.

Nonfunctional requirements examples

Some examples of nonfunctional requirements are:

The website pages should load in 3 seconds with the total number of simultaneous users <5 thousand.

The system should be able to handle 20 million users without performance deterioration.

The payment processing gateway must be PCI DSS compliant.

A program running on Windows 10 must be able to run on Windows 11 without any change in its behavior and performance.

Functional requirements types

Functional requirements differ by feature functions they describe. According to this classification approach, we can distinguish the following types of functional requirements.

Authentication. This group is about verifying the identity of a user before allowing access to the system, including entering usernames and passwords, biometric verification, or multifactor authentication.

Authorization levels. These requirements aim to define and control the access levels of different users within a system. For example, an admin may have complete system access, while a regular user has limited access to certain features.

Data processing. These requirements can include data entry, validation, storage, and retrieval.

User interface and user experience (UI/UX). These are the requirements related to the design and interaction elements of the system. Their goal is to ensure that it’s user-friendly and meets users’ needs.

Reporting. These requirements define generating reports, e.g., data sources, formats, etc.

System integration. These requirements describe how the system interacts and integrates with other systems or third-party services.

Transaction handling. This group contains requirements for handling transactions. They are especially important in systems that deal with financial processes or require record-keeping of transactions.

Error handling and logging. These requirements specify how the system should handle errors and log them, e.g., defining error messages, troubleshooting steps, and maintaining logs for system activities.

Backup and recovery. These are the requirements for data backup and system recovery processes, ensuring data integrity and system availability in case of failure.

Nonfunctional requirements types

As we already mentioned, nonfunctional requirements describe how a system must behave and establish constraints on its functionality. This type of requirements is also known as the system’s quality attributes.

If you want detailed information about types of nonfunctional requirements and how to approach and document them, check out our dedicated article or watch our video.

Here, we’ll just briefly describe the most typical nonfunctional requirements.

Usability

Usability defines how difficult it will be for a user to learn and operate the system. We can assess usability from different points of view:

Efficiency of use: the average time it takes to accomplish a user’s goals, how many tasks a user can complete without help, the number of transactions completed without errors, etc.

Intuitiveness: how simple it is to understand the interface, buttons, headings, etc.

Low perceived workload: how many attempts users need to accomplish a particular task.

Example: Usability requirements can consider language barriers and localization tasks: People with no understanding of French must be able to use the product.

Or you may set accessibility requirements: Keyboard users who navigate a website using <tab>, must be able to reach the “Add to cart” button from a product page in 15 <tab> clicks.

Security

Security requirements ensure there is protection from unauthorized access to the system and its stored data. It considers different levels of authorization and authentication across different user roles. For instance, data privacy is a security characteristic that describes who can create, see, copy, change, or delete information. Security also includes protection against viruses and malware attacks.

Example: Only the system’s data administrator can change access permissions for the particular system information may only be changed by the system’s data administrator.

Reliability

Reliability defines how likely it is for the software to work without failure for a given time. Reliability decreases because of bugs in the code, hardware failures, or problems with other system components.

Example: The database update process must roll back all related updates when any update fails.

Performance

Performance is a quality attribute that describes the system's responsiveness to various user interactions. Poor performance leads to a negative user experience. It also jeopardizes system safety when it’s overloaded.

Example: The front-page load time must be no more than 2 seconds for users that access the website using an LTE mobile connection.

Availability

Availability reflects the time that the system’s functionality and services are available for use with all operations. So scheduled maintenance periods directly influence this parameter. And it’s important to define how the impact of maintenance can be minimized. When writing the availability requirements, the team has to define the system's most critical components that must be available at all times. You should also prepare user notifications in case the system or one of its parts becomes unavailable.

Example: New module deployment mustn’t impact the front page, product pages, and checkout page availability and mustn’t take longer than one hour. The rest of the pages that may experience problems must display a notification with a timer showing when the system is going to be up again.

Scalability

Scalability requirements describe how the system must grow without negatively impacting its performance. It means serving more users, processing more data, and doing more transactions. Scalability has both hardware and software implications. For instance, you can increase scalability by adding memory, servers, or disk space. On the other hand, you can compress data, use optimizing algorithms, etc.

Example: The website attendance limit must be scalable enough to support 200,000 users at a time.

Now that we've discussed what functional and nonfunctional requirements are, let’s talk about how to gather, document, and manage them throughout the project.

Requirements gathering and management

Requirements gathering and requirements management are two crucial phases in any project.

Requirements gathering (or requirements elicitation) involves defining stakeholders' specific needs and expectations for a new system, software application, or any other project. Basically, it’s about understanding what needs to be done.

In a nutshell, the requirements gathering process has three main parts.

1. Identify stakeholders – determine who will be affected by the project and who should provide input.
2. Collect information – use interviews, surveys, workshops, and other methods to gather information about the needs and expectations of stakeholders.
3. Document requirements – record the collected information in the documentation formats described above.

Usually, business analysts are responsible for requirements gathering, though sometimes product owners or product managers are also involved.

Requirements management is about ensuring that all requirements are met during the development process and that any changes are carefully controlled and documented. The key components of requirements management are

• prioritization – determining which requirements are most essential and should be implemented first;
• change management – handling changes to requirements in a controlled manner to prevent scope creep;
• traceability – keeping track of all requirements and ensuring that they are being addressed throughout the project lifecycle; and
• verification and validation – ensuring that the developed system meets all the identified requirements and that these requirements fulfill their intended purpose.

The next big question to explore is which documents and formats you can use to capture requirements.

Functional and nonfunctional requirements documents 

Requirements are usually written in text, especially for Agile-driven projects. However, they may also be visuals. The most common document to describe the system and list the requirements is the SRS.

Software requirements specification document

We can formalize functional and nonfunctional requirements in the software requirements specification (SRS) document. The SRS contains descriptions of functions and capabilities that the product must provide. It also defines constraints and assumptions. 

You can learn more about software documentation in general from our detailed post or the video below.

We don’t recommend composing SRS for the entire solution before the development kick-off, but you should document the requirements for every feature before building it. Once you receive the initial user feedback, you can update the document.

SRS must include the following sections:

Purpose. Definitions, system overview, and background.

Overall description. Assumptions, constraints, business rules, and product vision.

Specific requirements. System attributes, functional requirements, and database requirements.

It’s essential to make the SRS clear and comprehensible for all stakeholders. Use templates with visuals that help structure the information and make it more understandable. If you have requirements stored in other document formats, provide a link to them so readers can find the needed information.

Example: If you’d like to see an actual document, here’s a downloadable SRS example created at Michigan State University. It includes all points mentioned above plus use cases to illustrate product parts. Or you can also use our SRS template below.

Functional decomposition and Work Breakdown Structures (WBS)

A functional decomposition is a process of breaking down a complex problem, system, or structure into simpler, more understandable parts. In software engineering, functional decomposition helps create a detailed, visual representation of the system functionality – a Work Breakdown Structure.

A Work Breakdown Structure, or WBS, is a document that illustrates how complex processes break down into their simpler components. A WBS is an effective approach to allow for an independent analysis of each part. It also helps capture the full picture of the project.

We suggest the following logic of functional decomposition:

1. Find the most general function.
2. Find the closest subfunction.
3. Find the next level of subfunction.
4. Check your diagram.

Or the decomposition process may look like this:

High Level Function ->Subfunction -> Process -> Activity

We should decompose the features to the point where the lowest-level parts can’t be broken down further.

It’s important to understand that the WBS only reflects functional requirements, so you should deal with it along with a list of nonfunctional requirements to have the complete, accurate picture.

Requirements formats: use cases and user stories

Since we have to make functional and nonfunctional requirements understandable for all stakeholders, we must capture them in an easy-to-read format. The two most typical formats are use cases and user stories.

Use cases

Use cases describe the interaction between the system and external users that leads to achieving particular goals.

Each use case includes three main elements:

Actors. These are the external users that interact with the system.

System. The system is described by functional requirements that define the intended behavior of the product.

Goals. The purposes of the interaction between the users and the system are outlined as goals.

There are two ways to represent use cases: a use case specification and a use case diagram.

A use case specification represents the sequence of events and other information related to this use case. A typical use case specification template includes the following information:

• Description, 
• Pre- and Post- interaction condition,
• Basic interaction path,
• Alternative path, and
• Exception path.

A use case diagram doesn’t contain a lot of details. It shows a high-level overview of the relationships between actors, different use cases, and the system.

The use case diagram includes the following main elements.

• Use cases. Usually drawn with ovals, use cases represent different interaction scenarios that actors might have with the system (log in, make a purchase, view items, etc.).
• System boundaries.  Boundaries are outlined by the box that groups various use cases in a system.
• Actors. These are the figures that depict external users (people or systems) that interact with the system.
• Associations. Associations are drawn with lines showing different types of relationships between actors and use cases.

User stories

A user story is a documented description of a software functionality seen from the end-user perspective. The user story describes what exactly the user wants the system to do. In Agile projects, user stories are organized in a backlog. Currently, user stories are considered the best format for backlog items.

A typical user story looks like this:

As a <type of user>, I want <some goal> so that <some reason>.

Example:

As an admin, I want to add product descriptions so that users can later view these descriptions and compare the products.

User stories must be accompanied by acceptance criteria. These are the conditions the product must satisfy to be accepted by a user, stakeholders, or a product owner.

Each user story must have at least one acceptance criterion. Effective acceptance criteria must be testable, concise, and completely understood by all team members and stakeholders. We can write them as checklists, in plain text, or using the Given/When/Then format.

Here’s an example of the acceptance criteria checklist for a user story describing a search feature.

• A search field is available on the top bar.
• A search starts when the user clicks Submit.
• The default placeholder is a grey text Type the name.
• The placeholder disappears when the user starts typing.
• The search language is English.
• The user can type no more than 200 symbols.
• It doesn’t support special symbols. If the user has typed a special symbol in the search input, it displays the warning message: Search input cannot contain special symbols.

Finally, all user stories must fit the INVEST quality model:

•         I – Independent
•         N – Negotiable
•         V – Valuable
•         E – Estimable
•         S – Small
•         T – Testable

Independent. You can schedule and implement each user story separately. It’s very helpful if you employ continuous integration processes.

Negotiable. All parties agree to prioritize negotiations over specification. Details will be created constantly during development.

Valuable. A story must be valuable to the customer. You should ask yourself from the customer’s perspective “why” you need to implement a given feature.

Estimable. A quality user story can be estimated. It will help a team schedule and prioritize the implementation. The bigger the story is, the harder it is to estimate it.

Small. Good user stories tend to be small enough to plan for short production releases. Small stories allow for more specific estimates.

Testable. If we can test a story, it’s clear and good enough. Tested stories mean that requirements are done and ready for use.

Best practices for documenting requirements

Creating documentation is an integral part of any software development project. Well-documented requirements ensure that stakeholders and developers are on the same page and help define project scope and budget. Here are a few useful tips on how to make great documentation.

Requirements have to be clear and understandable. Make sure you state requirements concisely, without ambiguity or different interpretations. Also, try to avoid technological jargon. Remember that each audience is different, and stakeholders might not be familiar with specialized tech terminology. Instead, enrich your documents with visuals, diagrams, and graphs to support the information and make it easier to perceive. Adding glossaries and cross-links is also helpful.

Requirements have to be specific, accurate, and complete. When writing your documentation, be consistent with the language and make sure that your requirements are accurate. They should cover every scenario but never contradict one another. Avoid vagueness and weak phrases such as “system has to be fast” or “when something happens.” Be specific and quantify the terms so that all the readers can understand them similarly.

Requirements have to be testable. Write requirements so that after the product is created, testing can show whether they are delivered successfully.

Requirements have to be feasible and sensible. Focus on the functionality and quality attributes that users need. Remember that requirements have to reflect higher-level business objectives.

Prototypes: understanding and testing requirements

Before the product is ready, there’s often a need to see how functional requirements are implemented – or how the future product will work. That’s why prototypes, wireframes, and mockups are created. They represent how the solution will look and give an idea of how users will interact with it. This way, they help bridge the vision gaps and let stakeholders and teams get a shared understanding of products in development.

Software prototype is actually an umbrella term for different early-stage deliverables that are built to showcase how requirements can be implemented. Its most basic form is a wireframe.

Wireframes. Wireframes are low-fidelity graphic structures of a website or an app. They help map different product pages with sections and interactive elements.

Mockups. Wireframes can be turned into mockups – visual designs that convey the look and feel of the final product. Eventually, mockups can become the final design of the product.

Prototypes. The next stage is a product prototype that allows teams and stakeholders to understand what’s missing or how the product may be improved. Often, after interacting with prototypes, the existing list of requirements is adjusted.

To learn more about how requirements and prototypes can be handled, check our case study about building a travel management solution for Cornerstone, a corporate SaaS provider.