Easy Approach to Requirements Syntax?

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Jul 11 05:56:10 UTC 2019


On 10/07/2019 16:10, Joel Sherrill wrote:
> Replying to myself.. see below.
> 
> On Wed, Jul 10, 2019 at 8:18 AM Joel Sherrill <joel at rtems.org 
> <mailto:joel at rtems.org>> wrote:
> 
> 
> 
>     On Tue, Jul 9, 2019 at 12:34 AM Sebastian Huber
>     <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>         On 08/07/2019 08:42, Sebastian Huber wrote:
>          > Hello,
>          >
>          > I work currently on a requirements engineering section for
>         RTEMS in the
>          > RTEMS Software Engineering manual:
>          >
>          > https://docs.rtems.org/branches/master/eng/index.html
>          >
>          > There should be some recommendations on how to formulate
>         requirements.
>          > What do you thing about the: Easy Approach to Requirements
>         Syntax
>          > (EARS)? Has someone used this before? Is it something to
>         recommend?
>          >
>          >
>         https://www.researchgate.net/publication/224079416_Easy_approach_to_requirements_syntax_EARS
> 
>          >
>          >
> 
>         Just for reference, there is also a follow-up paper:
> 
>         https://www.researchgate.net/publication/224195362_Big_Ears_The_Return_of_Easy_Approach_to_Requirements_Engineering
> 
> 
>     These papers were nice to read. I like their categorization of
>     requirements and providing
>     templates with preferred language. I think their rules on complexity
>     are probably on point.
>     Whether we agree or disagree with the specific words isn't as
>     important as having those
>     words and templates.
> 
> 
> I was asking around and apparently other OAR folks knew that EARS was 
> being adopted
> as is by some of the large organizations we deal with. These 
> organizations do large safety
> critical systems. With that knowledge, I am willing to say we should 
> adopt it. If there is
> an authoritative reference, we need to find it.

I guess it will be difficult to find references. These large 
organizations tend to keep things secret.

I found a reference that Intel uses it too:

https://www.iaria.org/conferences2013/filesICCGI13/ICCGI_2013_Tutorial_Terzakis.pdf

> 
> 
>     FWIW we have had similar heated discussions on the FACE Technical
>     Standard. The EARS
>     guys did a more formal job with patterns but we also ended up with
>     preferred wording patterns
>     for requirements.
> 
> 
> I guess I need to suggest we consider adopting EARS for the next major 
> revision.
> 
> 
>     I agree with having requirements templates/examples. I would take it
>     further than the generic
>     patterns of EARS. We need some for specific areas like configuration
>     parameters, set for
>     a Classic API method, set for a POSIX API method, a scheduler, etc.
> 
> 
> These would be more detailed examples and still needed.

Yes, we should add specialized templates if necessary. I will propose to 
use EARS in my draft.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list