I'm studying for the CPRE Foundation Level exam from the International Requirements Engineering Board. In the exam, there is a statement:

Quality Requirements are elicited after the Functional Requirements.

The answer to this statement is provided as false. Does this mean that quality requirements should be elicited before the functional requirements or at the same time as the functional requirements?

  • See also here softwareengineering.stackexchange.com/questions/71621/… Commented Nov 5, 2016 at 15:48
  • 5
    My question is from the Requirements Engineering perspective. I think that since no dedicated Requirements Engineering community exists, Software Engineering is the closest field. I do not think my question has anything to do with Quality Assurance and Testing. The only common thing is the quality keyword. I am more interested in the requirements elicitation process.
    – vkoukou
    Commented Nov 5, 2016 at 15:51
  • 3
    This question is on-topic here, and I can provide an answer that I can justify, but I have no idea what the IREB says is the correct answer. When you're taking a certification exam, you need to know the answer that is considered correct for the certification exam, not what actually works in the world. So it doesn't matter that my knowledge of requirements engineering says you elicit requirements at the same time if the IREB says something else.
    – Thomas Owens
    Commented Nov 5, 2016 at 17:40
  • 1
    Do my edits properly capture your question? Based on your comments, I think that is what you are really trying to figure out.
    – Thomas Owens
    Commented Nov 5, 2016 at 17:50
  • 1
    Yes they are very helpful! I should have stated the question in more detail and with the appropriate background.
    – vkoukou
    Commented Nov 5, 2016 at 17:51

3 Answers 3


I'm not familiar with how the IREB teaches requirements engineering or the content that they recommend for learning about requirements engineering. I'm familiar with software requirements engineering from the works of Karl Wiegers and Joy Beatty, Anthony Chen and Joy Beatty, and Stephen Withall in addition to my own experiences gathering and analyzing requirements.

Since you know that the statement that quality requirements are elicited after the functional requirements is false, there are only two possible meanings. Either all requirements should be elicited concurrently or the quality requirements are elicited before the functional requirements.

Looking at what is considered a non-functional requirement or quality attribute, some quality attributes are specifically related to specific functionality. Examples of these may include performance and stability - a given function needs to complete in a specified amount of time or the system must be measurably responsive under certain loads or when performing certain work. Other quality attributes are more likely to affect the system as a whole - disaster recovery, fault tolerance, maintainability, security. A third set of quality attributes applies to the product and processes used - configuration management, escrow, licensing.

The statement that quality requirements are elicited before the functional requirements doesn't make sense. It's hard to talk about specific performance requirements in a manner that makes for a good requirement unless you are talking about functionality either first or concurrently.

Therefore, the intention is the recognize that quality attributes should be elicited from stakeholders concurrently with functional requirements. However, discussing some characteristics of requirements (such as completeness or consistency) must be done in a context that includes all of the requirements - functional and non-functional.

  • Thank you for the detailed explanation and the thought process of deducting the most possible/logical answer. My question is answered!
    – vkoukou
    Commented Nov 5, 2016 at 18:37

The NFR should be elicited before the functional as it presents the scope needed for the functional requirements.

It does not mean that it cannot change over the course of time.

Let's think of a practical example of what happens when you do the reverse.

Functional requirement. Retrieve all records in the database so the user can scroll through an accurate list online.

Without an NFR stating how long a typical transaction time should be given a load. The above requirement is easy to implement with a query and can be readily approved.

Now let's add a few of NFRs.

  1. The page load time may not be more than 300ms.
  2. The concurrent user load is 10000 at a time.
  3. There is at maximum of 100000 records in any result set.

If you combine them the solution design changes dramatically from something simple to something that requires a bit more engineering or negotiation.

By having the NFRs first you can push back on the FRs or change the NFRs to be more reasonable.

NFRs are also easier to define and understand outside the development zones as it is just target numbers.


You must have functional requirements first of course. You can only start thinking about quality once you know what you will be thinking about. Quality without a subject is meaningless.

  • 1
    Do you have any references to back this up? Preferably one of the sources recognized by the IREB, since that's the organization that is responsible for the certification exam the asker is taking.
    – Thomas Owens
    Commented Nov 5, 2016 at 17:44
  • Does the IREB recognize common sense and logic? A functional requirement could be "must allow change of address". A quality requirement could be "the transaction must complete within 2 seconds". It would not make a lot of sense to know "within 2 seconds" before knowing the feature, would it? Commented Nov 5, 2016 at 18:11
  • And that's one example. I can talk about documentation requirements, fault tolerance, disaster recovery, reliability, compliance, privacy, and usability requirements without talking about functionality and those are also quality attributes. Saying that the system needs three nines of uptime, compliance to SOX or HIPPA, or compatibility with existing infrasturcture doesn't depend on knowing your functional requirements at all.
    – Thomas Owens
    Commented Nov 5, 2016 at 18:20
  • Most of the things you mention need a definition of the part of the system they relate to (function). None of them are core system attributes, they are circumstantial, administrative, organisational, infrastructure related. From a software engineering perspective those are, possibly important but not primary concerns that only exist in relation to the system which is functional by nature. You may have a different perspective but if you do, you would not have your programmers cap on, now would you? Commented Nov 5, 2016 at 19:46
  • I'm looking at this from a software systems level, and not as a programmer. Someone who is just a programmer cares about a very narrow slice of the quality attributes of the system that it's not a useful perspective to consider, especially based on the context of the question.
    – Thomas Owens
    Commented Nov 5, 2016 at 21:01

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.