Расскажем, как на наш взгляд не стоит писать функциональные требования для Технического Задания.
Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.
Итак, что точно не нужно делать:
1. Не пытайтесь выполнить работу за один день. Хотя на практике, как правило, вам и того меньше времени выделит Заказчик, ведь «что там сложного?» - скажет он. Уверен, каждый с этим сталкивался хотя бы раз. И всем заинтересованным сторонам нужно понятно и терпеливо объяснить, что разработка ТЗ – долгий, итерационный процесс.
2. Не нужно в требования к функциям писать все, что «рядом лежит», т.е. приводить подробный атрибутивный состав, с которым должна (!) а может быть и не будет никогда работать функция, писать пользовательский сценарий «под диктовку» Заказчика и многое, многое другое.
3. Не стоит вообще приступать к работе с требованиями, не проведя предпроектное обследование, хотя бы в самом упрощенном виде (анализ нормативных документов, проектных решений, опрос пользователей).
4. Не переписывайте слово в слово то, что Заказчик выдает за «требования» (это могут быть отдельные фразы или несвязанные предложения со словами «Система должна» или «Функция должна…» в Контракте, или технические требования). На деле это в 70% случаев просто «набор слов»
5. Не используйте неоднозначные формулировки. Это будет размыто и абстрактно, а значит не проверяемо.
6. Не смешивайте требования с решениями. Если в процессе реализации будут небольшие отличия от зафиксированных в ТЗ требований, то вариантов два: «делать, как написано» или… страдать.
И таких «НЕ» - очень много.
Не поддавайтесь на уговоры Заказчика или кого-то еще, что сейчас самое главное «быстренько выдать» документ ТЗ, а потом все равно все поменяется, ведь есть еще этап Частного ТЗ, проектирования.
Для быстрой проверки качества разработанных требований составили небольшой чек-лист ниже.
Чек-лист проверки качества функциональных требований
Смысл и структура
Понятно, что делает система
Указана роль (кто)
Есть контекст / условие (когда)
Однозначность
Нет слов: быстро, удобно, иногда
Нет двусмысленности
Нет «и/или»
Атомарность
Одно требование — это одно действие
Нет объединённых требований
Тестируемость
Понятно, как проверить
Есть критерии приёмки
Есть измеримые параметры
Альтернативные сценарии
Описаны ошибки
Учтены негативные сценарии
Согласованность
Нет противоречий
Нет дублирования
Описаны требования, а не решения
Описано ЧТО, а не КАК
Нет лишних технических деталей
Быстрая самопроверка
Есть ли конкретика (что, кто, когда)?
Можно ли это протестировать?
Нет ли двусмысленности?
Это что делает система, а не как и через что она реализована?
Разбито ли на атомарные части?
