Frage

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?

War es hilfreich?

Lösung

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.

Andere Tipps

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.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top