Easy Approach to Requirements Syntax?

Joel Sherrill joel at rtems.org
Wed Jul 10 14:10:46 UTC 2019


Replying to myself.. see below.

On Wed, Jul 10, 2019 at 8:18 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Jul 9, 2019 at 12:34 AM Sebastian Huber <
> 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.


>
> 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.

>
>
>> --
>> 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.
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190710/04f3cf6b/attachment-0002.html>


More information about the devel mailing list