What does it do and how does it work?
These two questions should be top of mind for every business analyst embarking on a new project. That’s because, at a very basic level, these two questions will guide you towards the functional and non-functional requirements that are critical for ensuring a successful end result.
Functional vs. Non-Functional: What’s the Difference?
As the questions above imply, functional requirements identify what the product should do, while non-functional requirements define how the product should work.
But those definitions probably have you asking more questions, like: Does…works—what’s the difference? and Why does it even matter?
One of the easiest ways to understand the difference between functional and non-functional requirements is to look at a real product.
For example, consider the cell phone and what it does. There are lots of bells and whistles that have become standard expectations, like calling, emailing, texting, photography, voice activation and notifications.
These are all functional requirements. They describe the cell phone’s behavior based on the user’s interaction with it.
Typical areas associated with functional requirements include:
- Business rules
- Transaction corrections, adjustments and cancellations
- Administrative functions
- Authentication
- Authorization levels
- Audit tracking
- External interfaces
- Certification requirements
- Reporting requirements
- Historical data
- Legal or regulatory requirements
Now think about how today’s cell phones work. They need to have access to a network, good battery life, robust data bandwidth, plenty of internal memory and other features.
These are all non-functional requirements. They tell more of the product’s story by describing how the phone should perform in the user’s environment.
When you think about how cell phones have evolved over the years, these non-functional requirements have proven to be important capabilities in our day-to-day lives, despite the somewhat negative connotations of the term “non-functional.”
Typical areas associated with non-functional requirements include:
- Performance
- Scalability
- Capacity
- Availability
- Reliability
- Recoverability
- Maintainability
- Serviceability
- Security
- Regulatory
- Manageability
- Environmental
- Data integrity
- Usability
- Interoperability
Identifying Functional and Non-Functional Requirements
Functional requirements are pretty easy to come up with because they’re driven by imagination: Anything you can imagine or dream that you want this product to do can become a functional requirement.
Non-functional requirements, on the other had, are driven by experience. The product does what it’s supposed to do, but now you’re looking at how it needs to work in order to make a permanent impact on the user’s life.
This is where you take into consideration the experiential aspects, like whether or not it’s efficient, effective, user-friendly, accurate, stable. The cell phone has a camera, but is the image quality high enough? You can stream video, but is the data bandwidth sufficient enough to avoid herky jerky playback and buffering? Often these requirements don’t become evident until the product or service is being used on a regular basis.
The Shifting Balance as Product Categories Mature
Immature product categories have functional requirements when they first come out. That’s because the product is a novelty; everyone’s just happy to have the capability. You can anticipate non-functional requirements when you’re working with an entirely new category, but it’s harder to do simply because you don’t have the benefit of experience.
As categories mature, however, non-functional requirements become more important. Once the product becomes a part of people’s day-to-day lives, the non-functional requirements will build on what it does and increase its value.
So keep in mind, if you’re dealing with a new category, there’s only so much you can possibly know about the experience that will drive the non-functional requirements. Don’t get stuck here or beat yourself up for not being able to predict the future. Anticipate what you can, but realize you’ll be limited until the user experience reveals the rest of the story.