Writing Clear Functional and Non-functional Requirements: Tips and Best Practices from Apriorit Experts

When you start working on a new project, you need a clear plan. Usually, this plan specifies what you expect the product to do or how the software should perform. Explaining these expectations clearly can be critical to your project’s success. 

This article will help you understand how to create clear and useful requirements for the software you want to build. It breaks down the essentials of functional and non-functional requirements, offering insights into their specific roles in a project. It also includes seven steps for a systematic approach to requirements gathering and documentation. 

Once requirements have been gathered and documented, business analysts translate them from business language to more technical language. By leveraging these insights, project stakeholders can anticipate a more streamlined and efficient development process.

This article will be useful for product owners who need to create comprehensive software requirements specifications for their software development projects. By leveraging the expertise of Apriorit’s skilled business analysts, you can ensure seamless translation of business needs into clear and actionable requirements. 

Understanding requirements in software development

If you want a product that will meet your expectations in the long run, you should invest time in formulating detailed requirements. You might have a general idea of what you want to achieve but may struggle to define specific, measurable objectives. When you aren’t clear on your project’s goals, it can be hard to articulate precise requirements. This is where business analysts come into play. Clear and well-defined requirements help development teams and clients ensure they share the same goals for the project. 

There is a direct correlation between effective communication and project success. According to IAG Consulting, 68% of projects with efficient communication and well-defined requirements meet quality standards. At the same time, 32% of IT projects fail because of unclear requirements at the planning stage. Poorly formulated requirements can increase the project timeline and budget by up to 60%. Meanwhile, 41% of the global IT development budget may go towards projects with unclear requirements.

Before we dive into types of requirements, let’s define what a requirement is in software development. A requirement states how particular functionality or a particular product feature should work. You’ll need a few types of requirements to create a good product:

1. Business requirements describe a project’s high-level goals, objectives, and needs.
2. Stakeholder requirements include information about what stakeholders expect from a particular solution.
3. Solution requirements include product characteristics that meet the client’s expectations and business needs. These can be divided into two types: functional and non-functional.
4. Transition requirements define actions to be taken to move an organization from its current state to the desired state.

In this guide, we focus on how Apriorit business analysts craft effective solution requirements. They describe what the system should do (functional) and outline qualities the system should possess (non-functional). The discovery phase in software development is the perfect time to create a list of both functional and non-functional project requirements. 

Functional and non-functional requirements help you:

• Define terms and roles. Requirements help to avoid misunderstandings between the development team and stakeholders.
• Reduce communication time. Good communication with a business analyst results in clearly defined requirements and a shorter development timeframe. Communication can help to reduce the time required for communication during the development stage.
• Estimate the project more precisely. Clear and detailed requirements lead to more accurate estimates of the development time and cost.
• Spot possible mistakes. Functional and non-functional requirements can help you identify certain errors during the initial stages of development, saving you time and money.
• Create more predictable projects. High-quality, detailed requirements and wireframes help to predict results and build a project that meets your expectations.

But what is the difference between functional and non-functional requirements? Let’s take a closer look.

Functional requirements

What are functional requirements? They describe how a system should behave under specific conditions. Functional software requirements capture the system’s intended behavior and should be aligned with business needs to avoid project failure. 

Essentially, functional requirements describe what a software product should do. They focus on outlining the system’s expected behavior and include technical details, calculations, data manipulation and processing, and other functionalities that characterize what a product should achieve. Here is how to write functional requirements so that they are clear and effective.

Functional requirements should include technical specifics, such as operations conducted on each screen, system reports and outputs, comprehensive system workflows, and specifics regarding permissions for creating, modifying, and deleting data. As you are creating functional requirements, it’s important to consider these aspects:

• Business objectives. Align the system’s objectives with overarching business goals. This includes workflows, authorization levels, and approval processes.
• Administrative data. Define routine system operations, especially in reporting and data management.
• User capabilities. Outline the actions available to users, such as placing orders or browsing catalogs.
• System parameters. Describe software and hardware specifications, system responses, and system actions.

Here are some examples of functional requirements: 

• The user should be able to add multiple line items to the invoice.
• The user should be able to edit any invoice that is not in the finalized status.
• The system should display the delete confirmation dialog when the user initiates the deletion of a profile.
• The system should send a confirmation email when a new user profile is created.
• The user should be able to export report results in CSV format.

Now, let’s see what non-functional requirements are and what their role is in your project. 

Non-functional requirements

By definition, a non-functional requirement indicates how the system performs a particular function. It also describes how the system should behave and the limits of its functionality. Non-functional requirements answer all the specifications that were not covered when defining functional requirements. As a result, you can improve the user experience by defining the system’s behavior, features, and general characteristics. Here is how to write non functional requirements so they are easily understandable.

When non-functional requirements are well-defined and well-executed, they can make the system easy to use and enhance its performance. Non-functional requirements are product properties, so they mostly focus on user expectations. Here are some things to consider when writing non-functional requirements:

• Usability. Focus on the appearance of the user interface and how people interact with it. Describe colors, screen size, button size, etc.
• Reliability and availability. Determine expected system availability (if the system needs to function 24/7/365, for example).
• Scalability. Determine if the system will be able to handle future needs. For physical installations, this includes the availability of spare hardware, system capacity, and space to install it.
• Performance. Determine how fast the system needs to operate.
• Supportability. Specify if support will be provided in-house or if remote access is required to external resources.
• Security. Set security requirements both for the physical installation and from the cybersecurity perspective: for example, database security and password policies.

Here are some examples of non-functional requirements: 

• Maximum video opening time in the video player: 5 seconds
• Number of concurrent user sessions: 1 to 10000
• Supported browsers: Google Chrome, Safari, Microsoft Edge, Firefox
• Performance: Each request to the server must be processed within 5 seconds.

While understanding the what of your project is crucial, crafting clear and precise hows through effective requirements is equally important. Let’s see what approaches Apriorit business analysts use to write both functional and non-functional requirements, helping you translate your vision into a successful project.

Approaches to writing functional and non-functional requirements

You can write functional and non-functional requirements for your project in a few different ways, each serving a specific purpose. By exploring these methods, you can better understand your project’s core needs. Here are some of the most common:

Software requirements specification. Using a software requirements specification is one of the most common ways to write functional and non-functional requirements. It describes the functionality required in written form, as well as a general project description, assumptions, dependencies, design and security considerations, etc. At Apriorit, we adapt the IEEE 830 recommended practices for software requirements specifications to the needs of each project, sometimes skipping sections or adding new ones if needed.

Requirements visualization. In some cases, instead of creating a long document with requirements, you can use mind maps or other graphical tools to show requirements, their hierarchy, and their relations. This is a great way to group requirements by features and make a great presentation for stakeholders. Some of our customers prefer this way of working with requirements as they find it more comprehensible.

User stories represent an alternative approach to formulating requirements. These are descriptions of functionality from the end user’s perspective, accurately describing the user’s expectations from the system. One of the benefits of user stories is their accessibility, as they don’t require a lot of technical expertise to write. User stories can serve as a precursor to detailed requirements specifications.

User stories are typically structured using the following formula, providing a user-centric view of functionality:

“As a (type of user), I want (goal) so that (reason).”

User stories must always be followed by correctly formulated acceptance criteria. Traditionally, user stories are considered an attribute of Agile development, but they can be successfully used with other methodologies.

Use cases are similar to user stories, focusing on describing user actions during specific tasks. Use cases describe in detail what users do when completing a task. They are irreplaceable for describing complex multi-step actions. Sometimes, they can be combined or used interchangeably with workflow diagrams. The choice of a textual approach (use cases) or visual approach (workflow diagrams) will depend on project specifics as well as the team’s and customer’s preferences. At Apriorit, we use both approaches depending on project needs.

Requirements management software offers specialized tools for collecting, storing, and categorizing requirements in a user-friendly format while also defining their attributes. Such tools are highly beneficial for effectively tracing requirements and their re-use. Also, requirements management software allows for linking requirements directly to test cases, thus improving requirement testability. However, it’s important to consider how you will share such requirements with your clients. You can either grant access to the software or export requirements in a document format to present them effectively.

In most Apriorit projects, we use a combination of these approaches to ensure that requirements are fully documented and understandable for both the team and the client. Larger projects usually require more elaborate requirement representations. For example, Apriorit business analysts usually prepare use cases to ensure that not only are requirements understandable but the general flow across the system makes sense. User stories might have use cases as part of their acceptance criteria. Mind maps might be combined with workflow diagrams.

The more detailed your functional and non-functional requirements, the better they will align with the perspectives and expectations of everyone involved in the project.

How to meet criteria for effective requirements

Whether your requirements are functional or non-functional, whether they are written as user stories or drawn as a mind map, they must meet several criteria to be considered clear requirements that will be effective in the long run. Let’s take a look at the characteristics of effective requirements with examples of what you should and shouldn’t do.

Atomic. Each requirement must contain a description of one need or one limitation. In most cases, if the requirement contains “and,” it should be separated into several requirements. Here’s a practical example to help you understand how to format such a requirement: 

Don’t:	Do:
The system must be available 24/7, except during scheduled maintenance windows, and the maximum allowable downtime for unplanned outages is 1 hour per month.	1. The system must be available 24/7, except during scheduled maintenance windows.  2. The maximum allowable downtime for unplanned outages is 1 hour per month.

Consistent. The requirements must not clash with one another.

Don’t:	Do:
All users with Report generation permission must be able to generate reports.	1. All users must be able to generate reports. 2. Access to all parts of the system depends on user permissions.

Accurate. It goes without saying that requirements must contain only correct, verified information. All names, numbers, and assumptions must be validated with stakeholders, as once they are documented, they become the outline for the product.

Don’t:	Do:
There must be integration with Facebook for logging in.	There must be integration with Facetime for logging in.

Feasible. Requirements must describe something that actually can be done. That is why before being documented, requirements generally go through several rounds of discussion with a team and customers.

Don’t:	Do:
The system must predict a user’s attempts to access malicious sites before the user tries accessing such sites.	When a user tries accessing a malicious site, the system must detect it.

Implementation-free. Requirements must not contain unnecessary details related to feature implementation or design. In some cases, such details may be necessary; for example, when they were specifically outlined by stakeholders or are crucial features of the system. But if not, most implementation details should be left to the development team and design details to the designer.

Don’t:	Do:
Parameters must be saved in a text file in %LOCALAPPDATA%.	Parameters must be saved so that they can be used during future application sessions.

Independent. Requirements must be independent of one another. If one requirement is linked to another, the link might be added, or requirements can be grouped, but they must be clear and understandable as independent requirements.

Don’t:	Do:
1. The administrator must be able to temporarily block users.  2. Blocked users cannot access the system for 24 hours after the time of blocking.	1. The administrator must be able to temporarily block users.  2. They cannot access the system for 24 hours after that.

Necessary. Requirements must outline only what is really required by stakeholders during this iteration. 

Don’t:	Do:
Also add a dancing unicorn in the bottom left corner as an easter egg.	If nobody really asked for this, then this requirement must be omitted.

Simple. Use simple words, avoid long sentences, and avoid difficult constructions. The shorter and simpler the requirement, the easier it is to understand.

Don’t:	Do:
The application must demonstrate a transaction throughput capability that satisfactorily accommodates the upper echelon of operational demand, ensuring a performance threshold of no less than 1000 transactions per second during periods characterized by peak usage scenarios.	The application must support a minimum of 1000 transactions per second during peak use.

Testable. Each requirement must be verifiable so the QA team can check it and confirm that it has been implemented. This is especially important for non-functional requirements, as they tend to be formulated vaguely.

Don’t:	Do:
Many users must be able to use the application simultaneously.	2000 users must be able to use the application simultaneously without performance degradation.

Unambiguous. If a requirement can be misinterpreted, it will be misinterpreted. So make sure there is only one way to understand it.

Don’t:	Do:
The application must allow payment via an online payment system (preferably PayPal).	The application must allow payment via PayPal.

Understandable. Requirements must be easy to understand. If they contain rarely used terms, you might want to add a glossary or explain terms. If there is a link to a certain resource or document, it must be there.

Don’t:	Do:
PHI must be encrypted (according to the Health Insurance Portability and Accountability Act).	Patient health information (PHI) must be encrypted (see https://www.hipaajournal.com/considered-phi-hipaa/)

Now, let’s see what steps our business analysts take to gather better requirements.

4 stages of the requirements engineering cycle

Navigating the requirements engineering cycle involves strategic handling of functional and non-functional requirements, which are crucial for the success of any project. At Apriorit, we always think of this cycle as a roadmap that explores the what and the how of your project and simplifies the development process. 

Let’s take a closer look at each of these stages.

Stage 1. Feasibility assessment

This stage is important for every project. It examines the project’s viability and potential success factors.

During feasibility analysis, you should answer two main questions: 

1. Will this approach work? 
2. Will the benefits outweigh the costs? 

To answer both of these questions, we try to understand the high-level business requirements (a broad overview of the goals, objectives, and intended outcomes) for the solution, as they eventually translate into functional and non-functional requirements. While functional requirements might be unclear initially, non-functional aspects like quality attributes can be distinctly articulated, influencing the feasibility analysis. For example: 

• Business requirement: “We want a very secure system, but we do not want to use any encryption as lost keys usually bring headaches to users.” If this is a non-functional requirement in the security section, it makes us question the project’s feasibility. 
• Feasibility question raised: “Is a secure system feasible without encryption?”

As soon as our business analyst confirms your project’s viability, we can move to requirements elicitation.  

Stage 2. Requirements elicitation and analysis

Multiple techniques can be used during this stage to elicit requirements, from interviews and questionnaires to brainstorming and workshops. The primary objective of requirements elicitation and analysis is to understand the main stakeholder needs.

Slightly different approaches are required when eliciting functional and non-functional requirements. Functional requirements rely on answering questions about system actions, outcomes, and user behavior. Non-functional requirements are often tricky, relying on best practices, regulations, and well-framed questions.

For functional requirements, we usually concentrate on such questions as:  

• What should the product do? 
• How will the product be used? 
• What is the outcome of the specified action? 
• What is needed from the user?
• What system behavior is unacceptable?  

Question	Answer
How will the user access the system?	The user can access the system through a Google account.
Do we need any filters for the report?	Data in the report will be filtered by date and time.
What should the system do if the user makes too many requests?	The Administrator must be notified and the user’s access to the system may be limited.

Functional requirements can be collected from such techniques as analyzing the existing solution/process or shadowing and observations.  

Here are some Apriorit tips on eliciting functional requirements:

• Select the requirements elicitation technique that works best for your project.
• Understand business requirements and project objectives and move from a high level to a low level.
• Do not overthink technical details when eliciting initial requirements. At this point, you need to understand what is to be done, but too many technical details might overwhelm stakeholders. 
• Define system users.

Non-functional requirements might be less obvious, so eliciting them can be challenging. Some non-functional requirements can be formulated based on business rules or regulations to which the solution must comply. 

During interviews, discussing non-functional requirements tends to puzzle stakeholders, leading to vague or unhelpful responses. For instance, queries about acceptable application load times might yield replies like “quick” or estimations such as “10 seconds” or “1 second” that lack contextual meaning. 

There are several ways to avoid this situation. For some non-functional requirements, we rely on best practices and established guidelines for clarity. For example, at Apriorit, our designers always follow Microsoft or Apple guidelines for usability requirements. 

Another approach involves considering the negative effects of failing to meet non-functional requirements. By exploring scenarios where an application’s load time exceeds tolerance, stakeholders can gauge criticality. For instance, while extended loading times might inconvenience general users, for medical applications, they could impact patient care. This is why it’s important to specify specific thresholds, such as a 15-second load time.

Question	Answer
How securely should user data be stored?	User data must be encrypted using AES-256 encryption standards.
How scalable should the system be to accommodate future growth?	The system must support an increase from 10,000 to 50,000 simultaneous users without performance degradation.
What is the maximum acceptable downtime for system maintenance?	Scheduled system maintenance should not exceed 2 hours per month, preferably during off-peak hours.

Non-functional requirements, particularly those related to time, are prone to oversight. For example, if you collect requirements in March, you might overlook future scenarios, such as an increase in system load due to the generation of large annual reports at the year’s end.

Here are some Apriorit tips for collecting non-functional requirements:

• Analyze business rules 
• Follow best practices, guidelines, and regulations 
• Ask the right questions 
• Think about time and any other periodical changes. What will happen next month, next quarter, at the end of the year, during holidays?

After defining all requirements, you can move to their documentation.

Stage 3. Requirements documentation

Once you have gathered, analyzed, and clarified all requirements, you need to properly document them. There are several approaches to organizing functional and non-functional requirements in your documentation: 

• Separate section for non-functional requirements. No matter which approach to documenting requirements our business analysts choose (system requirements specification, use cases, etc.), they can always make a separate section in one document and move all non-functional requirements there. This section can contain subsections like accessibility, availability, compatibility, compliance, and so on. Having a template to follow will help you make sure that all requirements are filled out.

With the help of this approach, you will receive a systematic arrangement that allows for a comprehensive review. If some portion of requirements do not apply to your system, you can just remove them. For example, network architecture is not applicable for an application that will be used locally, so there’s no need for it.  

• Separate document for non-functional requirements. In certain methodologies like the classic Agile user story approach, non-functional requirements are gathered in the Definition of Done checklist, while functional requirements stay in user stories. This checklist usually contains the set of conditions necessary to consider a feature fully done, ensuring all non-functional aspects are thoroughly documented and verified. However, you need to be cautious to make sure that the team consistently reviews this checklist before implementing user stories. 
• Unification of functional and non-functional requirements. If non-functional requirements closely align with functional aspects, you can benefit from combining them within the same document. For example, security-related non-functional requirements such as password encryption might be added to registration and login use cases, as they obviously belong to these features. This method allows for contextual association between related functional and non-functional requirements.

By adopting these varied approaches, Apriorit business analysts systematically organize the documentation of both functional and non-functional requirements, boosting understanding of requirements and reducing scrutiny during development.

Stage 4. Requirements validation  

After requirements are documented, they need to be validated by all stakeholders to ensure they are correct and ready for implementation. 

Different requirements validation techniques are applicable to different types of requirements.   

• Requirement reviews and walkthroughs. These techniques involve stakeholders inspecting requirements either by walking through them or conducting reviews. They are suitable for both functional and non-functional requirements as they enable detailed inspection and clarification.
• Prototyping. This is a very effective method for validating functional requirements. A built prototype allows stakeholders to assess the intended functionality. However, as prototypes represent models rather than final systems, validating non-functional requirements through this method might be challenging. 
• Testing (test case generation). This is a very important technique where QA specialists validate requirements by creating test cases or plans. This technique can be applied to both functional and non-functional requirements. It’s particularly crucial for the latter, as it prompts the raising of critical questions early on. For example, if there is a requirement that the system can be accessed by geographically dispersed users, the QA might question how they are supposed to test the system from another country. 

After requirements validation is done, business analysts either return to stage two and repeat requirements gathering and analysis to clarify all missing points or, if the requirements are validated, the team moves to the development phase.

Conclusion

To create effective and impactful software requirements, a team of expert business analysts needs to understand the nuances of your project. You also need to find experts who can craft functional and non-functional requirements for your software product with clarity and precision. Both types of solution requirements are crucial in guiding the development process, ensuring that software not only offers the desired functionality but delivers the necessary performance and user experience.

At Apriorit, we have a team of expert business analysts who can make sure that your software requirements align with your business objectives and users’ expectations.