Reading time: 11 minutes
Clearly defined requirements are essential signs on the road that leads to a successful project. They establish a formal agreement between a client and a provider that they are both working to reach the same goal. High-quality, detailed requirements also help mitigate financial risks and keep the project on a schedule. According to the Business Analysis Body of Knowledge [BABOK] definition, requirements are a usable representation of a need.
Creating requirements is a complex task as it includes a set of processes such as elicitation, analysis, specification, validation, and management. In this article, we’ll discuss the main types of requirements for software products and provide a number of recommendations for their use.
Types of requirements
BABOK, which is 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 include 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
The needs of discrete stakeholder groups [top-level managers, nonmanagement staff, customers, etc.] are specified to define what they expect from a particular solution. This group serves as a bridge between the generalized business requirements and specific solution requirements. They are outlined in a User Requirements Specification and can include, for example, 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, 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 is needed from an organization to successfully move from its current state to its desired state with the new product. They are only necessary for the short period of time while the transition takes place. Examples can be “users must be trained to operate the system” or “previous data must be migrated to the cloud storage.”
To learn more about software documentation and planning, consider checking our video explainer.
Software documentation and planning in 11 minutes or less
This article is focused on functional and nonfunctional types of requirements. Before diving into the detailed description, let’s compare them side by side.
Functional vs nonfunctional requirements
Functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks. So, it’s important to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions. For example:
The system sends an approval request after the user enters personal information.
A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.
The system sends a confirmation email when a new user account is created.
Nonfunctional requirements, not related to the system functionality, rather define how the system should perform. Some examples are:
The website pages should load in 3 seconds with the total number of simultaneous users Sub-function -> Process -> Activity
The features should be decomposed to the point at which the lowest level parts can’t be broken down any further.
Example:
An example of a functional decomposition
Software prototypes
Software prototype is an umbrella term for different forms of early stage deliverables that are built to showcase how requirements must be implemented. Prototypes help bridge the vision gaps and let stakeholders and teams clarify complicated areas of products in development. Traditionally, prototypes represent how the solution will work and give examples of how users will interact with it to accomplish their tasks.
Prototypes can be cheap and fast visual representations of requirements [throwaway prototypes] or more complex ones [evolutionary prototypes]. The latter can even become the early versions of the product that already have some pieces of the final code. Effectively, evolutionary prototypes may even turn into minimum viable products or MVPs that we’ve described in a separate article.
Design documents and prototypes
Design requirements are usually collected and documented using three main formats that morph into one another:
Wireframes. Wireframes are low-fidelity graphic structures of a website or an app. They help map different product pages with sections and interactive elements.
Wireframe example
Mockups. Once wireframes are ready, they are 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.
Design prototypes. These documents contain visuals and allow for some interface interactions, like scrolling, clicking on links, or filling in forms. Design prototypes can be built from scratch using HTML and CSS, but most UX teams use prototyping services like InVision.
Example:
To learn more about how UX design processes are handled, check our case study about building a travel management solution for Cornerstone, a corporate SaaS provider, in which we used all three types of design requirements.
Flight Status interface design of the 4site platform
Nonfunctional requirements examples
As we already mentioned, nonfunctional requirements describe how a system must behave and establish constraints of 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 our dedicated article or watch our video.
Non-functional requirements explained
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. Usability can be assessed 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 any 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 , must be able to reach the “Add to cart” button from a product page within 15 clicks.
Security
Security requirements ensure that the software is protected from unauthorized access to the system and its stored data. It considers different levels of authorization and authentication across different users 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: 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 period of time. Reliability decreases because of bugs in the code, hardware failures, or problems with other system components. To measure software reliability, you can count the percentage of operations that are completed correctly or track the average period of time the system runs before failing.
Example: The database update process must roll back all related updates when any update fails.
Performance
Performance is a quality attribute that describes the responsiveness of the system to various user interactions with it. Poor performance leads to 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 is gauged by the period of 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 most critical components of the system 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 front page, product pages, and check out pages 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 negative influence on its performance. This 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.
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 also 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 your requirements are stated in a concise manner that doesn’t contain ambiguity or allow 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 each other. 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 in the same way.
Requirements have to be testable. Write requirements in such a way 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 actually need. Remember that requirements have to reflect higher-level business objectives.