<div dir="ltr"><div>Replying to myself.. see below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 8:18 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 12:34 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/07/2019 08:42, Sebastian Huber wrote:<br>
> Hello,<br>
> <br>
> I work currently on a requirements engineering section for RTEMS in the <br>
> RTEMS Software Engineering manual:<br>
> <br>
> <a href="https://docs.rtems.org/branches/master/eng/index.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/index.html</a><br>
> <br>
> There should be some recommendations on how to formulate requirements. <br>
> What do you thing about the: Easy Approach to Requirements Syntax <br>
> (EARS)? Has someone used this before? Is it something to recommend?<br>
> <br>
> <a href="https://www.researchgate.net/publication/224079416_Easy_approach_to_requirements_syntax_EARS" rel="noreferrer" target="_blank">https://www.researchgate.net/publication/224079416_Easy_approach_to_requirements_syntax_EARS</a> <br>
> <br>
> <br>
<br>
Just for reference, there is also a follow-up paper:<br>
<br>
<a href="https://www.researchgate.net/publication/224195362_Big_Ears_The_Return_of_Easy_Approach_to_Requirements_Engineering" rel="noreferrer" target="_blank">https://www.researchgate.net/publication/224195362_Big_Ears_The_Return_of_Easy_Approach_to_Requirements_Engineering</a><br>
<br></blockquote><div><br></div><div>These papers were nice to read. I like their categorization of requirements and providing </div><div>templates with preferred language. I think their rules on complexity are probably on point.</div><div>Whether we agree or disagree with the specific words isn't as important as having those</div><div>words and templates.</div></div></div></blockquote><div><br></div><div>I was asking around and apparently other OAR folks knew that EARS was being adopted</div><div>as is by some of the large organizations we deal with. These organizations do large safety</div><div>critical systems. With that knowledge, I am willing to say we should adopt it. If there is</div><div>an authoritative reference, we need to find it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>FWIW we have had similar heated discussions on the FACE Technical Standard. The EARS</div><div>guys did a more formal job with patterns but we also ended up with preferred wording patterns</div><div>for requirements.</div></div></div></blockquote><div><br></div><div>I guess I need to suggest we consider adopting EARS for the next major revision. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>I agree with having requirements templates/examples. I would take it further than the generic</div><div>patterns of EARS. We need some for specific areas like configuration parameters, set for</div><div>a Classic API method, set for a POSIX API method, a scheduler, etc.</div></div></div></blockquote><div><br></div><div>These would be more detailed examples and still needed. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
</blockquote></div></div>