Post #342

Знаете ли вы, что уровни обязательности требований стандартизированы? Ну, хотя бы в Интернете: есть RFC 2119, где перечислены следующие модальные глаголы: MUST (необходимо) — а также требуется (REQUIRED) и нужно (SHALL), означают абсолютную необходимость. MUST NOT (недопустимо), SHALL NOT (не позволяется) — соответственно, абсолютный запрет. SHOULD (следует) и RECOMMENDED (рекомендуется) — требования, от выполнения которых можно отказаться при наличии разумных причин. SHOULD NOT (не следует) и NOT RECOMMENDED (не рекомендуется) — эти вещи допустимы, но могут вызвать проблемы. MAY (возможно) и OPTIONAL (опционально) — можно включать (для полноты), можно не включать (для упрощения) — в целом, все должны быть готовы к тому, что у кого-то эта функция может быть не реализована. Конечно, все эти уровни имеют смысл, когда одна спецификация может иметь несколько реализаций — как при реализации интернет-протоколов разными вендорами. Когда же мы сами можем столкнуться с подобной ситуацией? Конечно, когда мы разрабатываем общедоступное API! Помимо самой спецификации, в этом случае хорошо бы выпустить описание протокола взаимодействия, в котором перечислить — что является абсолютно необходимым, что — желаемым, а что — только опциональным. Соответственно, на своей стороне быть готовым обрабатывать запросы, в которых опущены опциональные параметры и данные. Например, такую спецификацию я разрабатывал для открытого протокола приёма цифрового следа о действиях обучающегося для Университета 20.35 (подмножество протокола xAPI). Понятно, что мы не можем ожидать от всех клиентов, что они в полной мере реализуют весь протокол, и стоит в явном виде им сказать — что обязательно, а что можно опустить. А вот в RFC 6919 от 1 апреля 2013 были добавлены дополнительные уровни требований: MUST (BUT WE KNOW YOU WON'T) — необходимо(но мы знаем, что вы всё равно не сделаете). Думаю, тут не нужно объяснять, очень полезный уровень требований в реальных проектах! В реальной практике выражение в скобках очень часто опускается. SHOULD CONSIDER (следует рассмотреть) — когда авторы спецификации хотели бы, чтобы тут что-то было сделано, но пока не придумали — что именно. REALLY SHOULD NOT (действительно не следует) — когда мы знаем, что что-то нежелательное всё равно будет сделано, и поэтому не можем написать "недопустимо". OUGHT TO (сделать это — ваш долг) — когда речь идёт скорее о моральных обязательствах, но мы не можем требовать этого по контракту. WOULD PROBABLY (вероятно стоило бы) — когда четкого обоснования требования нет, на автор спецификации хочет надавить на разработчика, используя пассивную агрессию. MAY WISH TO (могут пожелать) — описание почти бессмысленной функциональности, которую запросил кто-то из второстепенных согласующих и которую точно никто не будет делать, но намек на неё остается, чтобы не затягивать согласование документа. COULD (может) — тонкий намек на критически важную функцию, но без жестких требований. POSSIBLE (возможно) — авторы спецификации не пришли к единому мнению насчет этого. Кто-то считает, что такое вообще никогда не может произойти, но, скорее всего, это фундаментальная функция, и ситуация будет случаться очень часто. MIGHT — не знаю, как перевести, я уже запутался в уровнях и тонкостях английских модальных глаголов. По-русски это тоже "может", но слабее, чем COULD и имеет оттенок просьбы. На русском, конечно, стоило бы составить свой список. Я точно видел в документах "следует рассмотреть", "должно быть определено", "может потребоваться" и "возможно". А вы с какими уровнями обязательности сталкивались?