Раз уж начал тему высказываний заказчиков, от которых текут кровавые слезы, то закину пару камней и в аналитиков. Здесь небольшой список формулировок, которые меня люто триггерят. И да, у меня есть список из 183 пунктов, почему я не зануда.

Пассивный залог
Аналитик: “Список жертв волколаков должен формироваться после каждого полнолуния”

Старейшина: “Кто в нашей деревне составляет список погибших? Кого казнить, если списка не будет?”

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

Не-событие
1. Отец ликанов воззвал к мирозданию: “Что я такое?!”
2. Но оборотень не получил ответ.

Часто, когда рассматриваем конкретное событие А, конструкция NOT A является не противоположным событием, а некоторым множеством событий. Это нормально, если нам важно лишь то, что событие А не произошло. Но иногда мы работаем на более высоком уровне детализации. Тогда надежнее сразу рассматривать конкретные исходы, избегая не-событий

1. Отец ликанов воззвал к мирозданию: “Что я такое?!”
2. Но
2a. мироздание не ответило в течение ночи
2b. мироздание подало знак, окрасив луну в цвет крови. Жаль, что оборотни дальтоники
2c. мироздание грязно выругалось на неизвестном языке

Система не должна
Аналитик: “Охрана не должна пропускать в деревню незнакомцев с признаками ликантропии”

Старейшина: “А что она должна-то делать? Конвоировать к инквизитору? Сжечь на месте? Вежливо указать дорогу к соседям?”

При виде фразы “система НЕ должна”, возникает ощущение, что какой-то инфы нам не додали. Ибо интереснее узнать, что же система должна делать. Также это может быть признаком того, что мы имеем дело с бизнес-правилом, которое мы не зафиксировали в явном виде.

Пользователь может
Аналитик: “Крестьянин может принести жертву богам, чтобы красная луна не взошла”

Старейшина: “Что значит может? Есть вероятность, что принесет? Он способен это сделать? Боги предоставляют такую возможность?”

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

Необходимо реализовать
“Необходимо реализовать трансформацию ликана в волка при свете луны”

Можно назвать вкусовщиной, но это не требование, а постановка задачи на разработку. Нормально, если требования мы используем только для описания задач, но после переноса в документацию будет смотреться очень странно. Плюс, возникает непреодолимое желание использовать пассивный залог, а это опять лишний диалог со старейшиной.

Терминология
В чем главная беда первого оборотня? Нет, не холодное безразличие вселенной. Обидели его аналитики - в документе постоянно называют разными именами: ликан, оборотень, волколак. Это привело к разночтениям и неправильной реализации. Поэтому и вышел дальтоником.