ARadzishevskiy19 авг 2017 в 10:50

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

8 мин

17K

Анализ и проектирование систем * Проектирование и рефакторинг * Промышленное программирование * Тестирование IT-систем * Функциональное программирование *

+13

Комментарии 6

Carburn 20 авг 2017 в 11:19

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

Greesha 20 авг 2017 в 15:23

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

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

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

Vladimir_Sklyar 20 авг 2017 в 22:37

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

ARadzishevskiy 21 авг 2017 в 07:23

интересно, как используется система тегов идентификаторов для управления требованиями.

Об этом упомянуто в 3 части.

Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?

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

a3aquB 22 авг 2017 в 10:51

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

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

ARadzishevskiy 22 авг 2017 в 11:01

Но неужели «отображению на визуальных формах» описывается без прототипов форм?

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий