I understand the difference between the two, but I get questioned by my colleagues of the benefit of labeling requirements as functional or nonfunctional (or transitional). Why bother to do so? He spent what he said was two days going through a list of requirements for one project, and saw no benefit to it, because the end result was to submit the document to another business entity with the edict, "Do it all."

What I fear is requirements lumped together in one document. I tried to explain the benefit in practical terms, but couldn't sell it. How do I sell the benefit of documenting which requirements are functional and which are nonfunctional.

  • There's an interesting discussion at c2.com/cgi/wiki?NonFunctionalRequirements but I haven't found anything that provides a definitive answer.
    – Thomas Owens
    Commented Jun 9, 2011 at 15:44
  • Listing functional and non-functional requirements seperately makes 'requirements-traceability' easier. In my experience, there have been some batch-processes that did not have functional impacts but non-functional requirements only.In such cases this clear demarcation has helped a lot. Each should have a different identifier added to it to ensure smoother verification and validation of the requirements.
    – Abi
    Commented Jun 10, 2011 at 10:30

5 Answers 5


Explicitly separating requirements will make it easier to design the right system.

With nonfunctional requirements (I prefer the concept/term quality attributes - should provide new insights beyond functional vs. not functional), you are more concerned with the properties of the software rather than the functionality. That is how the system performs some function, not simply what the system does. Quality requirements have a significant influence on the architecture of the system in ways that the functional requirements do not and for this reason they should be treated differently.

Keeping the quality attributes separate from functional requirements allows you to analyze, specify, and prioritize different kinds of requirements in different ways. For example, quality attributes are normally specified using a quality attribute scenario while functional requirements might take the form of stories, use cases, shall statements, or any other number of formats. Most of the systems I've worked on had less than a dozen quality attributes and many, many more functional requirements.

I would actually introduce another kind of requirements - technical constraints. Again, explicitly separating the requirements into these three buckets gives you cues for how to make the right trade-offs while building the system. Functional requirements are often quite negotiable, quality attributes will heavily influence your architecture and the structures you choose, technical constraints are non-negotiable.

If this were my team, I would tell them the requirements should be clearly annotated by type to make sure we don't miss something important in the architecture. Think about the architectural drivers, not just the functionality.

Anthony Lattanze in Architecting Software Intensive Systems: A Practitioners Guide gives a practical overview of architectural drivers and why they should be treated differently, much more comprehensive than my summary here.

  • +1 for NFRs being tied to architecture. It's harder to make them happen if you don't look at the system as a whole. Performance and fault tolerance are great examples of NFRs that often need to be designed at the system level. Commented Oct 28, 2014 at 21:53

When every requirement has an equal priority/weight (particularly "Mandatory") then you probably have more to worry about than just splitting up Functional and Nonfunctional requirements.

Nevertheless, there are several reasons to separate The two categories of requirements:

Responsibility for Implementation I have found that many non-functional requirements - particularly those focused on performance, are only moderately applicable to the developer. Although a design can support scalability and speed (and specific code sections can be tuned) in general being able to meet any performance requirements is dependent on the Architecture and often time the hardware configuration.

Responsibility for Testing How adept is the User or QA team at vetting that Security, Fault Tolerance, Safety and Reliability requirements are met?

Don't Repeat Yourself Documentation should follow the same DRY principle as code. Common UI styling requirements should be grouped together. If the person responsible for the requirements really wants to, they can reference non-functional requirements (individually or as a group) in the functional requirements.

Versioning If you are in a corporate environments with a lot of "standards" - you could Write specific UI or Security (to name a couple) requirements documents which can be versioned. That way you could write in the application specific requirements (mostly Functional Requirements) : "Application must adhere to V2.3 of Security Requirements defined in XYZ-Company-SecReq-DocumnentNamingStandard.docx".


Why bother differentiating between functional and nonfunctional requirements?

One reason for differentiating is the level of abstraction between the two types. Nonfunctional requirements are at a system level, and say how the system as a whole must behave. Functional requirements refer to a specific feature and what features and functionality must be provided to clients.

Nonfunctional requirements also constrain the system, while functional requirements say what the system must do. The nonfunctional requirements provide limitations as to how the functional requirements are to be designed and implemented later. By separating them, it becomes possible to clearly identify the features from the constraints and limitations.

What I fear is requirements lumped together in one document. I tried to explain the benefit in practical terms, but couldn't sell it. How do I sell the benefit of documenting which requirements are functional and which are nonfunctional.

In my experiences, functional and non-functional requirements are actually grouped into the same document or tracked in the same system. However, they are given their own, separate sections of the document as well as success criteria for meeting each one.


Generally, you categorize requirements to help the team deliver against them. If there is a requirement specifically targeted at an architectural need, calling it an "Architecture" requirement should help the team when working on the architecture.

A large single document of all the requirements isn't necessarily a bad thing... Spending 2 days reviewing it also isn't bad. The problem typically is that once one person has reviewed the requirements, -they- understand them, but it is no easier for anyone else to do the same. It can be a big help to start labeling requirements with metadata that will help the other people who join the project.

Maybe try to describe it as an abstraction problem. If you need to work in a legacy code base, you don't just read through all the existing lines of code then start to work. You follow the structure of the code to help you. Having some structure in the requirements helps in the same way.


There are multiple benefits to the separation.

  1. Save time on Testing (ie only test the functional requirements)
  2. Saves time on future changes to the requirements (ie non-functional requirements will take less time to review/approve/implement/test)
  3. In a regulated (ie FDA,etc.) world, non-functional requirements require 1/10th of the amount of paperwork that a functional requirement requires.
  4. Gives the team the ability to divide up the work between senior (functional) and junior (non-functional) team members.

I could go on...

On the surface two days seems like a long time, in the long run it could save weeks or even months of future work.

  • an example of a non-functional requirement would be "loads in less than 10 seconds". It doesn't describe what the system needs to do (that'd be a functional req), it describes some other aspect of the system. I wouldn't give that requirement to the junior team members :)
    – gbjbaanb
    Commented Jun 10, 2011 at 9:11
  • "only test the functional requirements" -- how about a non-functional requirement that says the "system should tolerate database failures" (good luck not testing that and see how your client likes it). I agree with @gbjbaanb that Nonfunctional requirements (which are usually handled at an architectural level!) are not going to be given to junior team members. Do you understand really what NFRs are? Commented Oct 28, 2014 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.