About CprimeCprime, a Goldman Sachs and Everstone Capital portfolio company, is more than just a full-service consulting firm – we are your strategic partner for driving innovation and agility in your business. With over two decades of experience, we have honed our expertise to help organizations adapt at the speed the market demands.
Enterprise AgilityNeed to respond to
change faster? To do more with less? To surpass your
competition? Adopting a holistic approach to change and continuous
improvement across the organization can achieve all that and
more Learn more >
Global TalentElevate your pool of talent to beat
the global tech talent shortage and remain competitive in the marketplace with
end-to-end solutions for enhancing your tech teams Learn more >
DevelopmentSupport lean, cost-effective workflows focused on delivering
value to your customer by leveraging individual specialists or entire teams of
experienced software engineers to build custom applications and integrations
Learn more >
Business TechnologyEstablish the optimal tool
stacks to streamline workflows, data capture, and transparency across the
organization, supporting decision making and agility Learn more >
TrainingFrom new ways of working to deeply technical tools-based topics, leverage 30 years of experience to bridge skills gaps, empower excellence, and foster innovation for unmatched growth. Cprime Learning >
When you build a product or solution using Agile approach, you will likely need to deal with a variety of requirements from different sources. The two most common types of requirements that you will likely encounter are Functional Requirements (FRs) and Non-Functional Requirements (NFRs). Many teams struggle to gain a clear understanding of these two types of requirements, which can often lead to less-than-desirable performance and output.
Let’s take a look at both of these types of requirements so we can gain a solid understanding.
In its simplest form, a functional requirement describes the user’s desired experience with the system. For example, able to conduct some type of business process and/or transaction. On the other hand, Non-Functional Requirements are much more subtle; they usually describe system-level behavior and/or performance (such as system availability, scalability, performance, etc.), which is usually assumed or not explicitly stated. For example, Consumers often assume a cloud-based web application would be secure and responds within a few seconds.
This table below describes a few of the common characteristics for both FRs and NFRs. Let’s take a closer look and see what similarities and differences there are.
Characteristic
Functional
Non-Functional
Source
Contract, scope document, customers, stakeholders, users, etc.
Architects, engineering teams, support teams, etc.
Format
User stories, Epics, Features
User stories, technical specifications
Ownership
Product Manager, Product Owner, Business Analyst
Architect, Project Lead
Typical Level of Detail
Low to medium
Low to high
Source
The originating point for functional requirements is usually the end consumer or paying customer. The people who have a need for a product or service usually has a problem that needs to be solved, and these are usually expressed in the form of functional requirements. This information is commonly recorded and tracked in different forms of documentation.
As for Non-Functional Requirements, the source is not quite as predictable. Many times, these requirements are generated by internal technical staff, possibly a System Administrator, Architect, or Systems Engineer who has a broader view of the overall system. These experts can often drive Non-Functional Requirements to ensure the product meets security and/or performance needs of the customers.
Format
The format used to capture FRs and NFRs are generally very similar. System behavior is usually easier to describe and articulate in the form of technical specifications, but they may be written as User Stories as well.
Ownership
Ownership and management of requirements can vary significantly depending on the organization, but the most common practice for Functional Requirements is through Product Management or Business Analysis specialists. Non-Functional Requirements can also be managed by the same staff but are often handled by the product development team.
Level of Detail
The level of detail for FRs and NFRs can also vary drastically depending on what type of product/system is being built, but in most cases, Non-Functional Requirements tend to have more specificity due to the need to quantify system behavior. For example, if a system is required to have an uptime of 99.99% instead of 99.9%, the seemingly small different can represent significant amount of effort and cost. Hence, the level of detail for Non-Functional Requirements is generally more critical than Functional Requirements which can be broader in scope.
In closing, both Functional and Non-Functional Requirements are important pieces of data to develop and maintain effectively because they are central to the value that your team needs to deliver and realize for the customers.
In its simplest form, a functional requirement describes the user’s desired experience with the system. For example, able to conduct some type of business process and/or transaction. On the other hand, Non-Functional Requirements are much more subtle; they usually describe system-level behavior and/or performance (such as system availability, scalability, performance, etc.), which is usually assumed or not explicitly stated. For example, Consumers often assume a cloud-based web application would be secure and responds within a few seconds.
