Наилучшая практика использования обязательности при написании требований

Ранее я отправил электронное письмо с напоминанием нашим разработчикам, что использование слова «Должен» в ваших производных требованиях не должно соответствовать вашим функциональным требованиям. При написании функциональных требований слово «должен» используется для описания функции, которую должно выполнять производное требование.
Производный = Система должна быть требованием
Функциональная = Система должна выполнить требование

Один из наших старшеклассников отослал его обратно, что это неправильно и должно использоваться в каждом требовании.

Я ошибаюсь здесь и должен быть использован в каждом требовании. Я не смог найти ничего, чтобы это подтвердить.

requirements

— Тим Либерман
источник

Мы используем «должны» в каждом обязательном требовании. Но «должен» и «должен» означать более или менее одно и то же. См. Также tynerblain.com/blog/2009/04/22/dont-use-shall

— Роберт Харви

Возможно, вы думаете о MUSTпротив SHOULDв RFC? ietf.org/rfc/rfc2119.txt

— user10326

См. Также plainlanguage.gov/howto/wordsuggestions/shallmust.cfm

— Арсений Мурзенко,

Не для того, чтобы быть участником вечеринки, но что вы выигрываете, когда все используют правильное слово в правильной ситуации?

— Питер

Требования к документации: Will vs Shall

— KMan

Ответы:

В RFC 2119 «Ключевые слова для использования в RFC для указания уровней требований» подробно рассматриваются значения различных слов в требованиях.

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе интерпретироваться как описано в RFC 2119.

Из этого документа:

MUSTэквивалентно REQUIREDи SHALLуказывает, что определение является абсолютным требованием.
MUST NOTэквивалентно SHALL NOTи указывает, что это абсолютный запрет спецификаций.
SHOULDэквивалентно RECOMMENDEDозначает, что есть веские причины игнорировать конкретное требование, но последствия должны быть взвешены.
SHOULD NOTи NOT RECOMMENDEDозначает, что конкретное поведение может быть приемлемым или полезным, но опять же, последствия должны быть взвешены.
MAYозначает OPTIONALи то, что требование действительно необязательно. Должна быть обеспечена совместимость с различными системами, которые могут реализовывать или не реализовывать необязательные требования.

После этого SHOULDследует сделать RFC, чтобы обеспечить согласованность коммуникации между внутренними документами и мировыми стандартами.

твердый ответ; реквизит для выкапывания RFC

@ GlenH7 Я знал об этом (мне нравится читать 1 апреля RFC, и некоторые из юмора находятся в «должны» и «должны», а 2119 его даже на странице википедии ) Я искал его, нашел его, а затем прочитал комментарий, который я собирался сделать - два выше это снова был RFC. Так что не совсем огромные реквизиты для раскопок.

Я думал, что Must требования / функциональные требования должны потребовать все функциональные возможности для производного объекта, который должен существовать. Но учитывая, должны и должны определения и как все остальные используют их, я был просто неправ

— Тим Либерман

Не уверен, откуда вы пришли к выводу, что shallи относитесь к mustотдельным уровням документации. Это довольно произвольное различие, которое не поддерживается ни одним из известных мне источников.

Shallи mustлексически эквивалентны. Это действие, которое требуется.

Используете ли вы shallили mustдействительно зависит от остальной части документа, в котором вы пишете, и от того, что имеет грамматическое значение для этого конкретного предложения.

Так что да, ты ошибаешься. Но вы также не правы всегда использовать shallвместо must. Они представляют одинаковую степень обязательства.

Shouldи mayне совсем эквивалентны. Они оба обозначают необязательные функции, но should, в отличие от них may, подразумевают, что у вас должна быть веская причина не реализовывать ее. Я согласен с тобой shallпротив must.

— Кит Томпсон,

@KeithThompson - это хороший момент, и вы правы. Я вытащил эту строку из ответа.

Я подумал, что функциональные требования должны использовать должны, потому что, если производный объект должен существовать, все его функции должны функционировать.

— Тим Либерман

Я предполагаю, что в какой-то момент я встроил в голову новый объект и должен был выполнять функцию.

— Тим Либерман

@TimLieberman - это неплохой взгляд на вещи, тем более что он связывает два уровня спецификаций. Это действительно полезно, поскольку некоторые люди путаются в семантике терминов. Тем более, что я исправил документацию по процессу, где слово «должен» чаще всего использовалось в качестве замены слова «должен». Тем не менее, это не совсем полезно, чтобы требовать этого в качестве отдельного стандарта.

Если вы работаете в рамках руководящих принципов DO-178 или DO-254 , у них есть свои собственные определения требований в целом и производных требований . Эти руководящие принципы, однако, не определяют, какое слово, например , должно, должно , должно быть использовано для определения требований.

Если в вашем инструменте управления требованиями автоматически не указаны производные требования для вас, то отличить их от функциональных требований с помощью обязательного вместо обязательного может быть, например, для демонстрации того, что цели проверки для производных требований также были выполнены. Это может быть возможной причиной, казалось бы, произвольного требования к документации.

Обратите внимание, что в DO-178 и DO-254 производное требование фактически означает требование, которое не было получено из требования более высокого уровня. Поэтому производные требования, по сути, инициируют новую цепочку прослеживаемости.

Как DO-178, так и DO-254 являются коммерческими руководящими документами, используемыми для разработки программного обеспечения авионики и электроники, и доступны только за плату на сайте www.rtca.org .

— Schedler
источник