Non-functional Vs Functional Requirements, How to be Successful?

Avoid Scope Creep, save time & money with The Accurate Definition of Requirements.

When I have started working in the project world eight years ago, I had no clue about the differences between functional and non-functional requirements (table below). Through years and gained experience, I now know how important it is to see the difference to avoid missteps, missed expectations, and manage the project well.

Category	Functional Requirements	Non-Functional Requirements
Questions	Answers the questions, “What the system should accomplish?” “What is the functionality?”	Answers the questions, “How should the system complete its function?” “What should be the performance?”
End-result	Defines a system or its component (feature)	Define the quality trait of a system (property)
Stakeholders	The business or user is specifying functional requirements	Technical people are specifying Non-functional requirement, e.g. Data Architect, Technical leaders, Project Team and Software Developers
Defining	Easy to define	More difficult to define
Criticality	The project has to meet requirements, or the project/product will fail	You do not have to meet the requirements to succeed. Yet, the quality may be affected
Level	Functionality defined at a specific component level	Non-Functional requirements often are at the whole system level
Objective	Features and functions of the system	Properties of the system like performance
Focus	User Requirements	User Expectations
Type of Testing	Common Testing Types: Integration, End to End, User Acceptance, etc.	Common Testing Types: Performance, Stress, Usability, Security testing, etc.
Test Execution	Before the non-functional testing	After the functional testing
Examples	1) Authentication of a user 2) A button to extract reports 3) Dropdown filters for data	1) Process 1Gb of data per hour 2) Up-time should be no less than 99% 3) Complete 1M calculations under 3 seconds

I hope the table above will give you a head start, especially if you are new to the project world. In the post, we will dive deeper into each of the requirements as only understanding differences might not make your project successful. 

Plus, we will use a case study to illustrate what each requirement means to the business outcome. Functional & Non-functional requirements are also known as Solution Requirements, and you will see why next.

What are Solution Requirements?

Solution requirements describe the system’s or solution’s qualities, which enables to achieve business objectives and meet stakeholder expectations. In other words, it looks into what we will build and how it will feel and behave to meet our goals. 

It also serves other essential function. In a way, solution requirements represent a “To Do” list for individuals who will build the solution. Furthermore, the team will be interested in where they can make concessions. The requirement documents through prioritisation will definitely help with that.

Right! So you only need to collate what stakeholders want, expect and need into an excellent document, and start building. Not so fast! The solution needs to fit well with business. 

If you have read my previous post, “Business Requirements “, you already know about the importance of starting with business constraints or requirements in the project. After you know business requirements and capabilities, you can start thinking about the solution, which the team can build to address business needs within those given constraints.

Post title suggests that we will contrast Functional & Non-functional. The table above definitely helps to do that. Yet, in reality, non-functional requirements are compliments for functional ones. Thus, we will continue on that premises.

Functional & Non-Functional Requirements Business Case

I will explore Functional (i.e. “What”) and Nonfunctional (i.e. “How”) requirements through the electric bicycle shop business case. We will also understand why both are highly important. Ultimately, all solution requirements will need to tie-in with business requirements and broader objectives for the project.

I will start by looking in-depth into our two types of solution requirements. We will then split them into more detail bits using our business case.

Business Case: Company Description

Bicycle manufacture with the original name “Two-Wheels” is a medium-sized business based in the EU. There are around 50 staff members, including engineers, administration and sales staff. It is leading in recreational and city bicycles in central EU. But they see electric bikes (e-bikes) gaining popularity and would like to keep with the trend. The aim is to have a 65% automated robotics line to assemble these new bicycles.

Business Case: Project Description

The business has established a plan to address the increasing demand for electric bicycles. The project is at an early stage of exploration and feasibility. The project’s first step is to evaluate the business’s needs and present them to the committee. The ultimate goal is to build the prototype and test it in the market. If successful, continue with establishing an assembly line.

What Are Functional & Non-Functional Requirements?

Our project team started working on the requirements’ document but got a little bit confused. They were not clear on the differences between Functional and Non-functional requirements; well, let’s help them out. The fact is that I have seen even experienced Business Analysts and Project Managers mixing the two up.

In most cases, not knowing the difference will not break a project, mainly if the project is small, like baking a cake. Yet any more extensive, and it is essential to have a clear understanding if you want to have a more targeted discussion with the user or sponsor about their needs. Thus, you will have a chance to deliver the project the first time round and uncover unknowns. Failing to understand the latter is one of the main reasons for scope creep and increased costs or time.

What Are The Functional Requirements?

In general, Functional requirements are product or solution features or functions, which need to be implemented to complete a task and achieve business objectives. They will describe system behaviour like calculations or business processes under specific conditions. If we do not meet these, users will think that product is not working. 

Plus, all stakeholders should understand requirements; thus, we need to define them clearly. The project can also specify what the system or solution should not do, highlighting what features should not exist.

When you ask the business what the system should do, you will typically get a functional requirements list. Of course, this is not an accident, as they care about WHAT the system will do for them, what value it will deliver; or how will it respond to user input. Btw, the business may not know how to name these requirements, and it will likely be your job. So, you should have a clear understanding.

Say in our business case, the sponsor may require the user to turn on the electric motor with one hand by having a switch on a handlebar.

What Are Functional Requirements’ Sub-Categories?

There is no one way to give a definitive sub-type list for Functional requirements. It will depend on the actual final deliverable and project. But we will look at a few examples from our business case to get a taster and comprehend what categories we could use.

Business Requirements: That’s right; we have a business requirement within a functional requirement. It could get confusing, but our business constraints could feed into functional requirements. For example, the project team will have to create a braking system to meet EU regulations for safety.

User Requirements: What can the user do with our bike? Well, the customer may want to have a basket to put their belongings on a nice summer day while on their trip to a beach.

Reporting or Admin Requirements: These are routine things the solution will do. We want to link battery sensory information with an app, which could provide some handy info on the road:

• current charge, 
• travelled and available distance, 
• pace, or
• other general battery health characteristics.

System Requirements: These are specific system specifications. Thus, if we think about our bike as a system, we may want to have a requirement to change gears automatically when in electric mode.

Data Requirements: Maintaining data in systems. Suppose our phase also includes a production line. In that case, we could consider the computerised system maintaining a list of resources, customer data, production parts and even destinations of completed products.

When you have your Functional requirements, you can start thinking about the specific properties they should have to achieve business objectives. We will need to understand the bicycle’s max speed or the rate at which it charges 80%. Here, Non-functional requirements come in handy.

What are the Non-functional Requirements?

Non-functional requirements highlight the properties, operation capabilities and constraints that enhance functionality like speed, security, reliability of the solution’s or product’s function or feature and answer HOW question. In other words, we are talking about the quality of the solution.

The thing is, Non-functional requirements do not change Functional requirements at a basic level. Even if the project does not deliver on Non-functional requirements, we will still meet all functional requirements. Hence the name Nonfunctional. 

However, we still may care about Non-functional requirements, even if we get our electric bike. These requirements affect the usability of our system or product. It affects user experience. How well you execute and define Non-functional requirement defines how easy it is for the user to engage with the system or bicycle in our case. Typically, there are some pre-existing user expectations, and you need to align with them.

As businesses work in a competitive market, they must pay attention to Non-functional requirements to keep users satisfied and have their business.

What Are Non-functional Requirements’ Sub-Categories?

We will try to make our users happy by creating a smooth experience using our electric bicycle and meeting their expectations. In the process, we will allocate each Non-functional requirement a specific category and sub-category. So, look for examples below. 

Knowing how to break requirements allows us to cover all bases and to have a relatively complete picture. These tend to be more consistent through different types of projects than Functional requirements. 

What are user constraints in Non-Functional Requirements? 

User constraints are accessibility and usability system requirements and highlight how users will interact with the solution or system. 

Accessibility In Non-Functional Requirements

Accessibility requirements are about evaluating how accessible a solution is to individuals who have, to some extent, Motor, Cognitive, Visual or Hearing impairments. Considered UI design is essential to ensure an application is accessible. The product should also be compatible with accessibility standards set forth by Web Content Accessibility Guidelines 2.1 if this is a web application, which includes things beyond just the UI. For other products like a bicycle, you could explore the UK Government website on accessibility.

As for our electric bicycle example, the design should include features that facilitate disabled people using it. Thus, we would like our bicycle to go 30km without any peddling or additional charge. As a result, we enable people with specific disabilities using bikes for moderate distances like in the city.

Usability In Non-Functional Requirements

Usability is all about the appearance and how easy it is to use a solution or the system. We are talking here about buttons placement or the number of steps between putting items in the basket and paying for them.

In our electric bicycle example, we may want all gages appearing on the bike handlebars and easily accessible by the user without moving around. Also, all gages should have at least three functions, so handlebars are not too crowded.

One other important aspect of electric bikes are the electric motor position, which affects how the bike feels to ride. For our bike, we want to have a mid-hub motor, i.e. in the middle of the cycle, to have equal weight distribution and a more comfortable ride.

What Are System Constraints In Non-functional Requirements? 

Multiple system attributes need to be specified to have a successful system or a solution. These will not be generally provided by users but by a technical team, who understand the technical tradeoffs between the various properties we discuss next.

Performance In Non-Functional Requirements

The team will need to define a system cycle time or response time where the experience is not affected. Often faster systems require more resources and cost more. Business needs to decide what is optimal for the users.

In our bicycle example, we want to know how quickly the bike needs to transition from electric motor to manual. The user may expect an electric motor to instantaneously kick-in. If the bicycle takes 15 seconds before the electric motor starts working, a user might think that it is not usable and will look around for a better performing brand or model.

We have an excellent example in the browser space as well. You may be even using Google Chrome or Internet Explorer to read this post. All browsers read HTML or similar code and provide a nicely formatted webpage, which is the same functionality. But some have handy extensions or optimisations that brings you a page faster. Which one will you use, the fast or slow browser!?

Capacity & Throughput In Non-Functional Requirements 

Here, we would like to define the expected system’s capacity at which it still performs well. The team needs to understand things like potential data volumes, transactions or the number of concurrent users. 

In our bicycle example, we would like to define the expected power output? Our electric bike should have a capacity 10Ah, voltage 36v on all standard models, and engine power output should be 360 Watts / Hour.

Reliability, Availability and Supportability in Non-functional Requirements

When the solution or system is live, you will need to have established structures to support users when there are issues. The team will need to consider the support for standard working times, acceptable system downtimes, or support location (internal or external).

What is the availability to charge the bike’s battery or the total available number of charge cycles? You should be able to fill the battery with any EU or UK standard electric outlet. 

Also, battery replacements should be available in any significant cycle centres. However, you should only require replacement after 1000 cycles.

Scalability In Non-Functional Requirements

When you build a Minimal Viable Product (MVP), a new solution or the whole business, you will also need to consider business capabilities to support the expansion.

Suppose we manage to build a successful prototype. Yet, it will be just the beginning of a great product. We will need to consider scalability after or just before the final version is approved. So, we will need to consider available parts or even the assembly line. 

We could start by evaluating the available standard or required custom parts for the prototype. Thus, we can determine the number of pieces we can buy from the market or need to build ourself’s. Say we are in luck. 

Most of the parts already produced by either Two Wheels company, and the rest is widely available with third-party suppliers. Therefore, the team can concentrate their efforts toward the assembly line rather than the custom attributes’ manufacturing process.

Security, Access Permissions, Backup & Recovery and Archiving

Businesses do not like sharing information with not authorised parties or losing data. Therefore, any new system or solution will need to consider security, access permissions, backup & recovery and archiving. 

Depending on the data you will be dealing with, you may need to have higher or lower consideration on the security aspect. If you are dealing with the individuals’ information, GDPR will kick-in, and security will need to be higher.

How to Document Functional And Non-Functional Requirements?

There are several ways you can document requirements, which will depend on the project execution methodology or framework and accepted practices in the business. The key is to ensure that user needs are documented clearly and are understandable by both technical and non-technical team members. 

If you would like to learn more about what makes a great requirement, check out my other post: WHAT IS A GOOD REQUIREMENT? 14 QUALITIES FOR A SUCCESSFUL PROJECT.

Let’s explore the four most common ways to document requirements.

What is the Requirement Specification Document?

The requirements specification document is the most common way to document your requirements. It is also the most straightforward way as it is merely a written description of the business or user needs. The document will include several sections, and most important are these:

• Project Objective or Purpose: Gives project’s and systems over-view and definition. Plus, it provides background, required context as well as a business opportunity. 
• Description: The document also includes assumptions, constraints, including business ones. If you are building a product, you may have a vision that needs to be highlighted.
• Specific requirements: Finally, we have to document our requirements, which will include but not be limited to system attributes, functional or database needs.

Requirement specification document closely linked with traditional project management. And if you like to learn all you need to know about that process, check out my comprehensive post: HOW TO BE SUCCESSFUL IN PROJECT MANAGEMENT, YOUR GUIDE.

How to use Work Breakdown Structures (WBS) With Project Requirements?

Typically, you would use WBS to break out complex project tasks into smaller bits to plan and evaluate. It also provides a full picture of the project. 

Yet, you can also apply WBS with Functional requirements. You would start with high-level requirements or functions and will drill down step by step of various activities that need to happen to reach a goal. 

For example, you would like to compare month on month revenue growth. You would need to load monthly revenue data, validate information, calculate the difference and generate a report. See the example below.

What Are The User Stories?

The third approach is user stories, which looks into a system and functionality from the end-user perspective. The story defines exactly what a user expects and needs a system or solution to do. It also has a standardised structure the way it is written and follow the below pattern:

• Who? As a… 
• What? I would like…
• Why? So that…

The good thing is that they are simple to write, and you do not need a lot of technical understanding. The project team could also use them in conjunction with the requirements specification document to give that end-user perspective.

A team must include at least one acceptance criteria in each user story. These describe conditions, which would make a user accept a solution and allow to confirm that a story is completed. 

User stories are very popular with Agile methodologies. There are several reasons, which are all linked with quality. For example, anyone story represents the most granular detail of an actionable work for a feature. Each User stories must fit the INVEST quality model:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Finally, when stories are organised in a backlog, which is subsequently ordered based on the priority. The team can quickly pull the highest priority item to work on next. Therefore, users stories that meet INVEST quality criteria and are part of the backlog increasing efficiency and supporting the self-organising mentality of Agile methodology.

If you would like to learn more about Agile methodology and related frameworks, check out my Agile blog posts.

What Are The Use Cases?

Use cases also do not require intricate technical knowledge. They describe how a user (a.k.a. an actor) interacts with the system or tool to reach a goal or execute the task. The case could be anything. For example, a user will need to analyse data outside a solution occasionally. Thus, the use case would describe steps to acquire the extract.

Often you will have a use case diagram accompanying use cases. The diagram shows actors, system boundaries, use cases and associations. 

• System boundaries: It is a box where all use cases take place and represent the system.
• Use cases:  business analysts would indicate use cases in the form of an oval. There are multiple-use scenarios that actors might have within the system, like log-in, filter data, view results, extract, etc.
• Actors: These are figures who represent users who interact with the system. Users could be either individuals or systems. 
• Associations: Finally, we need to show which actors relate to our use cases. Straight lines indicate associations showing different types of relationships.

See the picture below example. 

In my experience, I have used mostly requirement specification documents or user stories. I tend to apply use cases without logging anything to help stakeholders imagine the system’s practical use. Then, I would use either user stories or requirements specification document to record discussions. Depending on what makes sense, you will employ the most appropriate method.

What Is A Requirements Elicitation Reality in Workshop?

In a perfect world, you would want to define Functional requirements first and then dive into Non-functional requirements.

In reality, when you are in the workshop, people will throw at you everything in one go. You need to know the difference between types of requirements and make sure you tag them accurately. Thus, you are ready to go back to the same stakeholders and clarify or discuss them further.

Why Do You Need To Know Functional and Non-Functional Requirements?

Life and projects are not perfect. Even if you have a comprehensive project plan, a business may need to cut costs or scope due to lower demand or external factors.

When looking where to cut, it may be easier to start with Non-functional requirements as they will not affect the final product’s functionality. Though it is a balancing act, the business needs to consider how bad user experience can be before selling it. 

If you cut Non-functional requirements too much, you could lose demand. You may want to can the project altogether or borrow money to maintain the product’s quality and demand in such a case.

Function vs Non-Function Requirement Conclusion

As you can see, the project has multiple ways to define the final deliverable. We need all those ways as a checklist to capture all features and consider all known and unknown requirements. 

Hence, we can get the exhaustive list of features and properties we need to address for our sponsor and users. We can then combine the information with the business operating environment to get the project’s optimal outcome. In turn, it allows us to prioritise the right features, cut cost when needed, or adjust the scope. It gives us a target and precise definition of the completed product we can follow.

Word of caution. When you have official sessions to discuss requirements with stakeholders, they may still not give you the full, exhaustive list. Of course, you can mitigate the risk by considering all types and sub-types in your meetings, but that might not be enough. Keep an eye on passing comments that define some requirements you have not covered yet. These may pop up anywhere. 

It happened to me in the past. A senior stakeholder mentioned a function he must-have on a coffee break after the requirements’ workshop. Do investigate all such comments as they will come up later in the project.

Did you ever get such passing comments that end up with official product requirements? Let me know in the comments below.