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

Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.

Итак, что точно не нужно делать:

1. Не пытайтесь выполнить работу за один день. Хотя на практике, как правило, вам и того меньше времени выделит Заказчик, ведь «что там сложного?» - скажет он. Уверен, каждый с этим сталкивался хотя бы раз. И всем заинтересованным сторонам нужно понятно и терпеливо объяснить, что разработка ТЗ – долгий, итерационный процесс.

2. Не нужно в требования к функциям писать все, что «рядом лежит», т.е. приводить подробный атрибутивный состав, с которым должна (!) а может быть и не будет никогда работать функция, писать пользовательский сценарий «под диктовку» Заказчика и многое, многое другое.

3. Не стоит вообще приступать к работе с требованиями, не проведя предпроектное обследование, хотя бы в самом упрощенном виде (анализ нормативных документов, проектных решений, опрос пользователей).

4. Не переписывайте слово в слово то, что Заказчик выдает за «требования» (это могут быть отдельные фразы или несвязанные предложения со словами «Система должна» или «Функция должна…» в Контракте, или технические требования). На деле это в 70% случаев просто «набор слов»

5. Не используйте неоднозначные формулировки. Это будет размыто и абстрактно, а значит не проверяемо.

6. Не смешивайте требования с решениями. Если в процессе реализации будут небольшие отличия от зафиксированных в ТЗ требований, то вариантов два: «делать, как написано» или… страдать.

 И таких «НЕ» - очень много.

Не поддавайтесь на уговоры Заказчика или кого-то еще, что сейчас самое главное «быстренько выдать» документ ТЗ, а потом все равно все поменяется, ведь есть еще этап Частного ТЗ, проектирования.

Для быстрой проверки качества разработанных требований составили небольшой чек-лист ниже.

Чек-лист проверки качества функциональных требований

Смысл и структура

• Понятно, что делает система

• Указана роль (кто)

• Есть контекст / условие (когда)

Однозначность

• Нет слов: быстро, удобно, иногда

• Нет двусмысленности

• Нет «и/или»

Атомарность

• Одно требование — это одно действие

• Нет объединённых требований

Тестируемость

• Понятно, как проверить

• Есть критерии приёмки

• Есть измеримые параметры

Альтернативные сценарии

• Описаны ошибки

• Учтены негативные сценарии

Согласованность

• Нет противоречий

• Нет дублирования

Описаны требования, а не решения

• Описано ЧТО, а не КАК

• Нет лишних технических деталей

Быстрая самопроверка

• Есть ли конкретика (что, кто, когда)?

• Можно ли это протестировать?

• Нет ли двусмысленности?

• Это что делает система, а не как и через что она реализована?

• Разбито ли на атомарные части?

Присоединяйтесь к нам в Telegram и в VK