diff options
| author | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2021-03-17 10:29:48 +0100 |
|---|---|---|
| committer | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2021-03-19 08:20:16 +0100 |
| commit | 239644be82bf36a1263741d6c6bfee6b81adbea3 (patch) | |
| tree | 63b935329327b423a7b0ee1b577270cdfa5bcce0 /eng/req/req-for-req.rst | |
| parent | c-user: Remove obsolete constraint (diff) | |
| download | rtems-docs-239644be82bf36a1263741d6c6bfee6b81adbea3.tar.bz2 | |
eng: Update EARS syntax
The document used the EARS syntax from 2009 which slightly changed in
2016, see "Listens Learned (8 Lessons Learned Applying EARS)". The
optional pre-conditions moved to the state-driven pattern. This refined
syntax fits better to the action requirements.
Update #3715.
Diffstat (limited to '')
| -rw-r--r-- | eng/req/req-for-req.rst | 32 |
1 files changed, 22 insertions, 10 deletions
diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst index 9225e95..0c05ed6 100644 --- a/eng/req/req-for-req.rst +++ b/eng/req/req-for-req.rst @@ -171,9 +171,9 @@ Syntax Use the Easy Approach to Requirements Syntax (:term:`EARS`) to formulate requirements. A recommended reading list to get familiar with this approach is -:cite:`Mavin:2009:EARS`, :cite:`Mavin:2010:BigEars`, and -:cite:`Mavin:2016:LLEARS`. Please also have a look at the EARS quick reference -sheet :cite:`Uusitalo:2012:EARS`. The sentence types are: +:cite:`Mavin:2009:EARS`, :cite:`Mavin:2010:BigEars`, +:cite:`Mavin:2016:LLEARS`, and `Alisair Mavin's web site +<https://alistairmavin.com/ears/>`_. The patterns are: * Ubiquitous @@ -181,22 +181,34 @@ sheet :cite:`Uusitalo:2012:EARS`. The sentence types are: * Event-driven - *When* <optional preconditions> <trigger>, the <system name> shall <system response>. + **When** <trigger>, the <system name> shall <system response>. * State-driven - *While* <in state>, the <system name> shall <system response>. + **While** <pre-condition>, the <system name> shall <system response>. * Unwanted behaviour - *If* <optional preconditions> <trigger>, *then* the <system name> shall <system response>. + **If** <trigger>, **then** the <system name> shall <system response>. * Optional - *Where* <feature>, the <system name> shall <system response>. + **Where** <feature is included>, the <system name> shall <system response>. -The optional sentence type should be only used for application configuration -options. The goal is to use the *enabled-by* attribute to enable or disable +* Complex + + **Where** <feature 0 is included>, **where** <feature 1 is included>, ..., + **where** <feature *n* is included>, **while** <pre-condition 0>, **while** + <pre-condition 1>, ..., **while** <pre-condition *m*>, **when** <trigger>, + the <system name> shall <system response>. + + **Where** <feature 0 is included>, **where** <feature 1 is included>, ..., + **where** <feature *n* is included>, **while** <pre-condition 0>, **while** + <pre-condition 1>, ..., **while** <pre-condition *m*>, **if** <trigger>, + **then** the <system name> shall <system response>. + +The optional pattern should be only used for application configuration +options. The goal is to use the ``enabled-by`` attribute to enable or disable requirements based on configuration parameters that define the RTEMS artefacts used to build an application executable (header files, libraries, linker command files). Such configuration parameters are for example the architecture, the @@ -345,7 +357,7 @@ Justification of Requirements ----------------------------- Each requirement shall have a rationale or justification recorded in a -dedicated section of the requirement file. See *rationale* attribute for +dedicated section of the requirement file. See ``rationale`` attribute for :ref:`ReqEngSpecificationItems`. .. _ReqEngValidation: |