О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 2

В XP ТЗ не делают.

… в приведенном выше примере таблицы ролей, нет описания целей заинтересованных лиц и т.п. Эти подробности важны для аналитика на этапе формирования требований, но практически бесполезны для разработчиков.

В данном случае — для кодеров, а не для разработчиков. Потому что разрабатывать тут уже нечего.

Вообще, в этой части подробно описано, как аналитик ворует работу у программистов и архитекторов, принимая за них все решения. А потом аналитики собирают митапы, чтобы обсудить вопрос "Почему программисты не читают требования".

Отличная статья, все разложено по полочкам, чувствуется вдумчивость и многолетний опыт. Спасибо автору! Рассмотренный пример наглядный и релевантный.
На мой взгляд, требует комментариев применяемая классификация требований FR1.3.1, поскольку из названия типа требования (например, рамки качества) не совсем понятно, что имеется в виду.
Ещё интересно, как используется система тегов идентификаторов для управления требованиями. Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?

Статьи (3 части) хорошо разобраны и вполне применимы, имхо. Имеют полное право быть! Но неужели «отображению на визуальных формах» описывается без прототипов форм?

2) Да и в целом, посыл прост (он есть у вас в первой части) — договоритесь со своими разработчиками о форме требований, удобных для них. В разных проектах для разных разработчиков — все по-разному.