[docs] eng: Fix requirements how-to section

[Sebastian Huber]

Requirements depending on application configuration should use the
described approach.

Update #3715.
---
 eng/req/howto.rst | 67 +++++++++++++++++------------------------------
 1 file changed, 24 insertions(+), 43 deletions(-)

diff --git a/eng/req/howto.rst b/eng/req/howto.rst
index ea4a57d..ad2b962 100644
--- a/eng/req/howto.rst
+++ b/eng/req/howto.rst
@@ -440,61 +440,42 @@ of :c:func:`rtems_signal_catch`:
 Requirements Depending on Application Configuration Options
 -----------------------------------------------------------
 
-Requirements which depend on application configuration options such as
+Requirements depending on application configuration options such as
 :c:data:`CONFIGURE_MAXIMUM_PROCESSORS` should be written in the following
 :ref:`syntax <ReqEngSyntax>`:
 
     **Where** <feature is included>, the <system name> shall <system response>.
 
-Use these clauses with care.  Make sure all feature combinations are covered.
-Using a truth table may help.  If a requirement depends on multiple features,
-use:
-
-    **Where** <feature 0>, **where** <feature 1>, **where** <feature ...>, the
-    <system name> shall <system response>.
-
-For application configuration options, use the clauses like this:
-
-:c:data:`CONFIGURE_MAXIMUM_PROCESSORS` equal to one
-
-   **Where** the system was configured with a processor maximum of exactly
-   one, ...
-
-:c:data:`CONFIGURE_MAXIMUM_PROCESSORS` greater than one
-
-   **Where** the system was configured with a processor maximum greater than
-   one, ...
-
-Please have a look at the following example used to specify
-:c:func:`rtems_signal_catch`.  The example is a post-condition state
-specification of an action requirement, so there is an implicit set of
-pre-conditions and the trigger:
-
-   **While** <pre-condition(s)>, **when** rtems_signal_catch() is called, ...
-
-The *where* clauses should be mentally placed before the *while* clauses.
+For action requirements, the **where** clauses should be added to the head of
+pre-conditions list.  Please have a look at the following example used to
+specify :c:func:`rtems_task_construct`.  The example is a pre-condition state
+specification of an action requirement:
 
 .. code-block:: yaml
 
-    post-conditions:
-    - name: ASRInfo
+    pre-conditions:
+    - name: CPUs
       states:
-      - name: NopNoPreempt
+      - name: One
         test-code: |
-          if ( rtems_configuration_get_maximum_processors() > 1 ) {
-            CheckNoASRChange( ctx );
-          } else {
-            CheckNewASRSettings( ctx );
+          if ( rtems_scheduler_get_processor_maximum() != 1 ) {
+            ${.:skip}
           }
         text: |
-          Where the scheduler does not support the no-preempt mode, the ASR
-          information of the caller of ${../if/catch:/name} shall not be
-          changed by the ${../if/catch:/name} call.
-
-          Where the scheduler does support the no-preempt mode, the ASR
-          processing for the caller of ${../if/catch:/name} shall be done using
-          the handler specified by ${../if/catch:/params[0]/name} in the mode
-          specified by ${../if/catch:/params[1]/name}.
+          Where the system does not need inter-processor interrupts,
+          where the scheduler does support the no-preempt mode.
+      - name: More
+        test-code: |
+          if ( rtems_scheduler_get_processor_maximum() == 1 ) {
+            ${.:skip}
+          }
+        text: |
+          Where the system needs inter-processor interrupts,
+          where the scheduler does not support the no-preempt mode.
+
+The test case needs to run in all required configurations.  This requires that
+the test case is added to multiple test suites.  Use the ``${.:skip}``
+substitution to skip conditions not supported by the current configuration.
 
 Action Requirements
 -------------------
-- 
2.35.3