Category list

Formalize Requirement (Process Notes 3.4)

Refer to the requirements shell that is packaged with the requirements template. For each requirement, use the shell as a guide and define each of the components defined on the shell.

For detailed advice and examples of each type of requirement, refer to the requirements template.

Formalize System Constraints (Process Notes 3.5)

Refer to the requirements shell that is packaged with the requirements template. For the product purpose and the project constraints, use the shell as a guide and define each of the components defined on the shell. For other types of system constraints (e.g., client, customer, user ) refer to the requirements template.

For detailed advice and examples of each type of system constraint, refer to the requirements template.

Identify Nonfunctional Requirements (Process Notes 3.6)

You can use the functional requirements as a trigger to help you find the nonfunctional requirements by using the following approach:

I. For each use case

A. For each functional requirement

1. For each type of nonfunctional requirement listed in the requirements template

a. Should there be one or more of these nonfunctional requirements to support this functional requirement?

You can also use a higher-level approach and look for nonfunctional requirements by comparing the use case with each of the types of nonfunctional requirements.

Write Functional Fit Criteria (Process Notes 3.7)

The objective of this process is to take a requirement and use the work knowledge to produce a requirement fit criteria for a functional requirement. The process looks for unambiguous criteria that make it possible to classify any solution to the requirement as either "fits the requirement" or "does not fit the requirement."

The template contains many examples of how to determine requirement measurements.

For each requirement, fit criteria for a functional requirement specify how you will know that the product has successfully completed the required action, provided that you have defined the terms (refer to section 5 of the requirements specification template) used in the description and purpose/ rationale of the requirement. Then your fit criteria will take the following form:

The specified retrieved data will agree with the specified data that was input.
The specified checked data will agree with the specified checking rules.
The result of the calculation will agree with the specified algorithm.
The specified recorded data will agree with the specified retrieved data.

In other words, if your terminology is unambiguously defined, it is part of the definition of the fit criteria for functional requirements.

You might consider writing the test case as an alternative to the fit criterion for a functional requirement.

Write Nonfunctional Fit Criteria (Process Notes 3.8)

The objective of this process is to take a requirement and use the work knowledge to produce a requirement fit criteria for a nonfunctional requirement. The process looks for unambiguous criteria that make it possible to classify any solution to the requirement as either "fits the requirement" or "does not fit the requirement."

The template contains many examples of how to determine requirement measurements.

Decide what type of requirement you are dealing with; the template will help with this task.
Is it really a requirement? Requirements are often mistakenly stated as solutions. If this is the case, then you need to ask the stakeholders what the real requirement is, independent from how you might solve it.
If the requirement is concerned with something that you can touch, see, smell, hear, or taste, then it is easier to find an objective measurement.
If a noun is not concerned with something that you can touch, see, smell, hear, or taste, then you have a nominalization. A nominalization is created when a verb describing an ongoing process is turned into a noun.
Suppose you come across this requirement: Maintenance must be reliable. "Maintenance" is a nominalization. You can clarify a nominalization by trying to place bounds on the meaning. Turn the nominalization back into a verb and ask this question: Who is nominalizing about what, and how are they doing it? In the preceding example, ask: Who is maintaining what, and how are they doing it? This technique will help you to identify the real meaning of the requirement; from there you will be able to define an appropriate fit criterion.
Some requirements are vague nominalizations because no one really knows what they mean or want.