Comments 6
В XP ТЗ не делают.
… в приведенном выше примере таблицы ролей, нет описания целей заинтересованных лиц и т.п. Эти подробности важны для аналитика на этапе формирования требований, но практически бесполезны для разработчиков.
В данном случае — для кодеров, а не для разработчиков. Потому что разрабатывать тут уже нечего.
Вообще, в этой части подробно описано, как аналитик ворует работу у программистов и архитекторов, принимая за них все решения. А потом аналитики собирают митапы, чтобы обсудить вопрос "Почему программисты не читают требования".
Отличная статья, все разложено по полочкам, чувствуется вдумчивость и многолетний опыт. Спасибо автору! Рассмотренный пример наглядный и релевантный.
На мой взгляд, требует комментариев применяемая классификация требований FR1.3.1, поскольку из названия типа требования (например, рамки качества) не совсем понятно, что имеется в виду.
Ещё интересно, как используется система тегов идентификаторов для управления требованиями. Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?
На мой взгляд, требует комментариев применяемая классификация требований FR1.3.1, поскольку из названия типа требования (например, рамки качества) не совсем понятно, что имеется в виду.
Ещё интересно, как используется система тегов идентификаторов для управления требованиями. Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?
интересно, как используется система тегов идентификаторов для управления требованиями.
Об этом упомянуто в 3 части.
Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?
Это уже инструмент, конечно он должен быть в каждом конкретном технологическом процессе. Я же в данной статье обращаю главное внимание на форму составления спецификаций.
Статьи (3 части) хорошо разобраны и вполне применимы, имхо. Имеют полное право быть! Но неужели «отображению на визуальных формах» описывается без прототипов форм?
2) Да и в целом, посыл прост (он есть у вас в первой части) — договоритесь со своими разработчиками о форме требований, удобных для них. В разных проектах для разных разработчиков — все по-разному.
2) Да и в целом, посыл прост (он есть у вас в первой части) — договоритесь со своими разработчиками о форме требований, удобных для них. В разных проектах для разных разработчиков — все по-разному.
Но неужели «отображению на визуальных формах» описывается без прототипов форм?
Как договоритесь. Нужны прототипы форм, подключите дизайнера и вставьте плоды его тркда в раздел описания форм. Я позволил себе упустить эти нюансы, договорившись заранее, что мы будем использовать платформу, в которой есть готовые компоненты (шаблоны) и маневра для дизайна не так уж много.
Sign up to leave a comment.
О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 2