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

Мой поиск идеального ТЗ

Я хотел иметь широко применимый понятный мне стандарт, пытаясь:

  • Обобщать форматы ТЗ интеграторов, которые были успешно применены (где я участвовал на стороне заказчика).
  • Адаптировать национальные стандарты (ГОСТ).
  • Адаптировать международные стандарты (ISO).

Тут я имею ввиду, что убирая редко-используемое, добавляя обязательное, минимизируя возможное непонимание в ожидаемом наполнении разделов (за счёт выбора наиболее понятных заголовков и структуры), я пытался получить мой собственный идеальный формат, который я мог бы дать аналитику или использовать самостоятельно и иметь (в обоих случаях) приблизительно одинаковый результат.

Такие попытки случались со мной много раз, я бы сказал постоянно.

Однако, эти попытки, по большей части, провалились потому, что:

  1. Разные системы используют разную терминологию (которая используется пользователями и разработчиками).
  2. В проектах по доработке имеющейся или покупной системы (не разработка с нуля), не имеет смысла записывать в форме требований вещи, изначально присущие имеющейся / приобретаемой системе. Каждая такая система оставляет ограниченную зону, где аналитик должен выработать и описать решение.
  3. С целью лучшей оценки времени и стоимости проекта, вещи, которые специфичны и важны, не должны быть потеряны разработчиками из поля зрения из-за большого объема спецификации. В то же время, стандартные форматы вводят много готовых разделов, зачастую заполняемых информацией, мало влияющей на конечный результат. Люди теряют фокус, читая такие ТЗ.

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

Классификация спецификаций и документов, описывающих требования

То, что я описываю далее, вероятно, есть в книгах. Во всяком случае, часть из этого мне рассказали (в процессе собеседований, кстати) аналитики, которые их читали. В то же время, разные аналитики называют одни и те же вещи разными словами. Поэтому, пусть нижеследующая классификация будет моей собственной.

Предлагаю, в целом, разделить спецификации на два уровня (против такого простого деления спорить невозможно):

  1. Высокоуровневые спецификации, которых достаточно для понимания конечного результата.
  2. Детальные спецификации, которые полностью описывают, что и как должно быть сделано.

Вторые не нужны, если в проекте работают опытные разработчики, находящиеся в бизнес-контексте (внутренняя команда разработки).

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

Разбираясь глубже, можно было бы выделить массу видов спецификаций, но есть сложности не только с именованием как таковым, а что во что входит. Например, варианты использования и другие UML-диаграммы это могут быть отдельные документы, а могут включаться в ТЗ. Причём, иногда как отдельные части (например, раздел ТЗ "Варианты использования"), а иногда внутри других разделов (например, варианты использования в разделе ТЗ "Введение"). Тоже самое происходит с текстовыми частями. Некоторые поставщики, помимо исходного ТЗ, настаивают на собственном ТЗ и на различных видах исполнительной документации. Это всё порождает многообразие того, как комплект технической документации может быть составлен. Тут, на практике, стандарта не получается.

Что я однозначно разделяю по разным документам:

  1. Функциональные требования (или ТЗ), которые описывают изменения и доработки в имеющейся или приобретаемой системе.
  2. Требования (или ТЗ), которые описывают отдельно взятое новое программное обеспечение, которое должно быть разработано.
  3. Спецификации, которые описывают форматы взаимодействия / обмена данными.
  4. Документы, которые описывают нечто над вышеперечисленным (в пунктах 1, 2 и 3).

Документы третьего и четвёртого пункта, как ни крути, отличаются от первых двух тем, что не относятся ни к одной из систем (третьи между, четвёртые над). Системы же должны описываться по отдельности друг от друга.

Что касается последнего пункта, это могут быть:

  1. Бизнес-требования
  2. Протоколы согласований
  3. Описание архитектурного решения
  4. Различные прочие документы обоснований

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

Аналитики из крупных банков (разные) рассказывали мне, что у них есть три категории документов:

  1. Документы, относящиеся к бизнес-требованиям (они их называют BRD — Business Requirements Document).
  2. Архитектурный документ.
  3. Спецификации (они их называют SRD — Software Requirements Document).

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

Формат спецификации (ТЗ)

Мой личный более-менее универсальный формат выглядит так:

1. Введение
2. Термины и определения
3. Общие требования к реализации
3.1. Среда выполнения
3.2. Управление исходным кодом
3.3. Серверная часть (Back-end)
3.4. Браузерная часть (Front-end)
3.5. Интеграция с внешними системами
3.6. Журналирование и телеметрия
4. Контроль доступа и аудит
4.1. Аутентификация и авторизация
4.2. Права доступа и роли
4.3. Аудит
5. Пользовательский интерфейс
5.1. Концепция
5.2. Разделы и экранные формы
5.2.x. Раздел [Название раздела]
6. Модель предметной области
6.x. Объект | Перечисление [Название]
7. Периодические задания
7.x. Задание [Название]
8. Интеграция и API
8.x. Процедура | Метод [Название]

Список можно продолжать другими разделами, например "Отчёты".

Я не группирую требования на верхнем уровне на функциональные и не функциональные — это не вносит значимой структуры. Поскольку большая часть требований является функциональными, стоит просто начать с не функциональных.

Функциональные требования можно разделить на три более-менее большие группы:

I) Те, которые относятся к поведению модели предметной области.

II) Те, которые относятся к пользовательскому интерфейсу.

III) Прочие, типа периодических заданий, отчётов, и описание API.

Что бы делать иерархию структуры документа чересчур глубокой, группа III, в зависимости от важности различных входящих в неё частей, может выливаться в несколько последовательных разделов.

Формат не претендует на пригодность во всех случаях жизни, но во многих из них поможет.

Можно скачать шаблон ТЗ с примерами заполнения.