In this article, we’ll break down technical requirements, explain the difference between various types of software specifications, and show how they work together.
The key differences between functional and technical requirements
Functional vs technical requirements: how they differ in a nutshell
Among all the documents describing software products, functional requirements are the ones that most closely resemble how an average user would determine what they want and what the solution must do to satisfy their needs.
Imagine you're a teenager again and writing your wish list for Santa before Christmas, fully expecting your parents to handle the payment and delivery. You might say, "I want a bike that has various speeds for climbing steep hills and riding cross-country, handbrakes because I didn't like driving into a fence last time, and a USB-rechargeable headlight so I can ride my bike till late at night." That’s essentially a perfect example of functional requirements.
Technical requirements, on the other hand, are the details that ordinary users typically don’t think about and often don’t even know exist. Engineers leverage these specifications to figure out how to make functional requirements a reality. For instance, your dream bike must have a frame made from aluminum alloy 6061, a 12-speed manual transmission, and a particular model of disc brakes.
Now, let's see how this distinction works regarding software rather than bicycles.
What are the functional requirements?
According to the business analysis bible, Business Analysis Body of Knowledge (BABOK), functional requirements are capabilities that a solution must have in terms of the behavior and information it will manage. They go hand in hand with non-functional requirements, which define the solution's quality attributes, constraints, and performance standards (e.g., speed, scalability, security) to meet business and user needs. Functional and non-functional requirements are two complementary types of software requirements specification.
We mention non-functional requirements here for a reason: We will return to them when dealing with technical requirements. For now, let's focus solely on functional requirements.
What functional requirements describe
According to International Organization for Standardization (ISO), “functional requirements describe the system or system element functions or tasks to be performed” to handle inputs, process data, and generate outputs. In this context, the system refers to both the software and the hardware it runs on.
These are very generic examples of functional requirements for a travel app:
- “The system shall allow users to input travel dates, departure, and destination locations, as well as the number of passengers to search for available flights.”
- “The system shall display flight options sorted by price, duration, or departure time based on the user’s preference.”
Functional requirements are the largest and the most important part of the Software Requirements Specification (SRS). A collection of functional requirements forms a scope of tasks to implement to build a solution.
Who is responsible for creating functional requirements?
Depending on company policy and team composition, a business analyst or, in some cases, a product manager is responsible for creating this part of the software documentation. If they work together, a business analyst gathers requirements from stakeholders and documents functional specifications, and a product owner/manager prioritizes functionality aligned with business goals.
Types of functional requirements
The last version of the Software Engineering Body of Knowledge (IEEE SWEBOK) identifies several main types of functional requirement specifications based on how they are documented.
Unstructured natural language specifications describe requirements in plain language without formal structure, often using “The system shall...” statements, as mentioned above. They are easy to understand but may lack precision.
Structured natural language specifications apply formatting rules to improve clarity. Below are the most common formats.
User story – a textual description of the feature in the format As a [role], I want [feature], so that [goal]. “As a user, I want to see all the available flights for the specific dates on the page so that I can choose the flight that suits me.” A collection of user stories forms a product backlog. Story points are leveraged to estimate the time needed to implement a user story.
Gherkin scenario – a specification using keywords of a plain-text programming language Gherkin. The main keywords are given, when, and then. For example: “Given a user has never logged in, when a user inputs their credentials, then a user is redirected to the main dashboard page, and the community rules are displayed.”
Use case – a detailed representation of how a system interacts with users (actors) to achieve a specific goal. It defines a sequence of actions or events capturing the user’s perspective and the system’s functionality.
Acceptance criteria-based specifications rely on test cases that define how the functionality will be validated. Before implementation, developers, business experts, and testers agree on test cases to ensure the system meets requirements. The list of such test cases can supplement a user story. Here is an example of acceptance criteria for validation of a password field:
“The system shall enforce password complexity rules, requiring at least 8 characters, including one uppercase letter, one number, and one special character.”
Model-based specifications visually represent requirements. A data-flow diagram might illustrate how user input flows through the system to generate reports, or a use-case diagram might be another example.
Use case diagram is one of the model-based specification types.
Functional requirements can also be typed based on the workflows covered. Read more about functional requirements in software development in our article.
What are the technical requirements?
Although technical requirements aren’t explicitly mentioned in BABOK or SWEBOK, they are widely and commonly used in the IT industry. Their meaning is intuitive: a technical specification outlines the solution tech attributes and constraints. For example, “The system should allow file uploads up to 10 MB and store them in AWS cloud storage.”
What technical requirements describe
Technical requirements refer to how a product is built. While functional requirements describe a product or system as a black box, focusing only on incoming and outgoing data, technical requirements show how everything should work inside that box. While functional requirements reflect the needs and expectations of businesses and end users, technical ones are primarily for developers, providing the guidance necessary to implement the solution.
Note that multiple technical requirements may be needed to fulfill a single functional requirement.
Who is responsible for creating technical requirements?
Technical requirements are created at different stages of SDLC.
At the design stage, a software architect determines the main programming languages (e.g., Java for the backend and JavaScript framework React for the frontend), as well as the technologies to be used for the future product (e.g., Elasticsearch engine, MongoDB, integration with Apache Kafka streaming platform, etc.).
At the stage of creating the product backlog, a business analyst may mention some technical details in user stories in coordination with the technical lead or solution architect, as well as QA specialists.
At the sprint backlog creation stage, a BA should initiate a meeting with external stakeholders, developers, and testers so that the engineers can discuss and fully understand the user stories and decide how to implement them. Then, the lead software engineer/tech lead, responsible for the design of the features, writes technical requirements. It can be done directly in the backlog task, or, in case of complex features, a dedicated document (technical specification) should be created and attached to the task.
Technical requirements vs non-functional requirements
It is common to see technical requirements mentioned as part of, or even synonymous with, non-functional requirements describing how the system should work. Here is how technology constraints are represented in SWEBOK.
Categories of software requirements according to SWEBOK
Indeed, non-functional requirements for the solution architecture, or technology constraints, which SWEBOK defines as "mandating—or prohibiting—the use of specific technologies or defined infrastructures,” are also technical requirements.
However, non-functional requirements may describe portability, usability, reliability, productivity, maintainability, performance, security, etc., without technical details. For example, "The system shall load the booking page and display search results within 3 seconds on standard broadband connections," "The system shall support up to 100,000 concurrent users”, or “All buttons shall have a minimum size of 44x44 pixels and use contrasting colors for accessibility compliance”.
The technical requirements will supplement these descriptions and specify precisely how to achieve the desired results: “Use a Content Delivery Network (CDN) to minimize latency and speed up static asset delivery” or “Use WCAG-compliant color contrast ratios (minimum 4.5:1 for normal text and 3:1 for large text) between the button background and text. For buttons, use Hex color #28a745.”
So, while there’s some overlap between technical and non-functional requirements, they’re not the same. We can safely conclude that software specifications work best when complemented with technical requirements, giving developers the most comprehensive and detailed understanding of the desired application behavior and quality.
Besides functional, non-functional, and technical requirements, other important technical documentation types define the characteristics and quality of the future product. Read about business requirements documents, code documentation, and API documentation in our dedicated articles.
Functional vs technical requirements examples
Below, we’ve provided some examples of paired functional and technical requirements for key features of a simple travel app to illustrate their alignment. Note that in real life, there are a lot more technical requirements and acceptance criteria for each user story.
Feature: Registration
User story: As a new user, I want to create an account by providing my personal details so that I can manage my bookings.
Acceptance criteria:
- The system shall display specific error messages if password input doesn’t match the requirements (e.g., “Password must contain at least one special character”).
- Upon successful registration, the system shall display a confirmation message and send a verification email with an activation link.
Technical requirements:
- Implement input field validation using regular expressions on both the front end (JavaScript) and the back end (server-side validation).
- Store user credentials securely using BCrypt for password hashing and salted encryption.
- Use an email service, like SendGrid, to send verification emails with a time-limited activation link.
Feature: Authorization
User story: As a registered user, I want to log in using my email and password so that I can securely access my account and bookings.
Acceptance criteria:
- The system shall support account lockout after five consecutive failed login attempts and notify the user with a message such as “Too many failed attempts. Your account is temporarily locked.”
- The system shall support a “Remember Me” checkbox to maintain login sessions for up to 30 days or until the user logs out.
Technical requirements:
- Implement secure login using OAuth 2.0 with JSON Web Tokens (JWT) for session management.
- Use HTTPS for secure communication between the client and server.
- Configure session timeouts with token expiration (15 minutes for inactivity and 30 days for “Remember Me” sessions).
Feature: Filtering for travel options
User story: As a user, I want to filter search results by criteria like price, departure time, and airline so that I can narrow down options to fit my preferences.
Acceptance criteria:
- The system shall allow users to filter search results by price range, departure time, arrival time, layovers, and specific airlines.
- Filter selections shall be dynamically applied, updating the results in real time without requiring a page reload.
- The system shall display the number of matching results for each filter and allow users to reset all filters with a single action.
Technical requirements:
- Use client-side filtering with JavaScript frameworks (e.g., React or Vue.js) to dynamically update results.
- Fetch filter options from the backend dynamically based on available data.
- Optimize server-side search with indexed database queries to reduce latency for complex filter combinations.
Feature: Booking
User story: As a user, I want to book my chosen flight and receive a confirmation so that I can finalize my travel plans.
Acceptance criteria:
- Upon successful booking, the system shall generate a unique booking reference.
- Upon successful booking, the system shall email the user confirmation with the flight details.
- If a booking attempt fails due to seat unavailability, the system shall display an appropriate error message and allow the user to select a different option.
Technical requirements:
- Implement transactional database operations using PostgreSQL.
- Integrate inventory management APIs from flight providers to verify seat availability during booking.
- Use a message queue (e.g., RabbitMQ) to process booking confirmations and send transactional emails asynchronously.
Of course, these examples are purely illustrative. In practice, functional and technical specifications should be created by people who understand your organization's unique challenges and have deeply studied your customers' and users' needs.