Когда я начинал в разработке бизнес-приложений, я имел ошибочное представление, что некие общие форматы технических заданий могут быть применены по отношению к большинству ситуаций.
Мой поиск идеального ТЗ
Я хотел иметь широко применимый понятный мне стандарт, пытаясь:
- Обобщать форматы ТЗ интеграторов, которые были успешно применены (где я участвовал на стороне заказчика).
- Адаптировать национальные стандарты (ГОСТ).
- Адаптировать международные стандарты (ISO).
Тут я имею ввиду, что убирая редко-используемое, добавляя обязательное, минимизируя возможное непонимание в ожидаемом наполнении разделов (за счёт выбора наиболее понятных заголовков и структуры), я пытался получить мой собственный идеальный формат, который я мог бы дать аналитику или использовать самостоятельно и иметь (в обоих случаях) приблизительно одинаковый результат.
Такие попытки случались со мной много раз, я бы сказал постоянно.
Однако, эти попытки, по большей части, провалились потому, что:
- Разные системы используют разную терминологию (которая используется пользователями и разработчиками).
- В проектах по доработке имеющейся или покупной системы (не разработка с нуля), не имеет смысла записывать в форме требований вещи, изначально присущие имеющейся / приобретаемой системе. Каждая такая система оставляет ограниченную зону, где аналитик должен выработать и описать решение.
- С целью лучшей оценки времени и стоимости проекта, вещи, которые специфичны и важны, не должны быть потеряны разработчиками из поля зрения из-за большого объема спецификации. В то же время, стандартные форматы вводят много готовых разделов, зачастую заполняемых информацией, мало влияющей на конечный результат. Люди теряют фокус, читая такие ТЗ.
Даже наличие формата, который я мог применить путём исключения или модификации отдельных частей, не означало, что любой аналитик мог так же применить его (практика показала, любой другой человек всё понимает по-своему). Это показывает, насколько важен опыт аналитика по сравнению с форматом требований.
Классификация спецификаций и документов, описывающих требования
То, что я описываю далее, вероятно, есть в книгах. Во всяком случае, часть из этого мне рассказали (в процессе собеседований, кстати) аналитики, которые их читали. В то же время, разные аналитики называют одни и те же вещи разными словами. Поэтому, пусть нижеследующая классификация будет моей собственной.
Предлагаю, в целом, разделить спецификации на два уровня (против такого простого деления спорить невозможно):
- Высокоуровневые спецификации, которых достаточно для понимания конечного результата.
- Детальные спецификации, которые полностью описывают, что и как должно быть сделано.
Вторые не нужны, если в проекте работают опытные разработчики, находящиеся в бизнес-контексте (внутренняя команда разработки).
Вторые обязательны, если Вы работаете с внешним подрядчиком или фиксируете стоимость проекта. А это, обычное дело, если Вы закупаете услуги по конкурсной процедуре.
Разбираясь глубже, можно было бы выделить массу видов спецификаций, но есть сложности не только с именованием как таковым, а что во что входит. Например, варианты использования и другие UML-диаграммы это могут быть отдельные документы, а могут включаться в ТЗ. Причём, иногда как отдельные части (например, раздел ТЗ "Варианты использования"), а иногда внутри других разделов (например, варианты использования в разделе ТЗ "Введение"). Тоже самое происходит с текстовыми частями. Некоторые поставщики, помимо исходного ТЗ, настаивают на собственном ТЗ и на различных видах исполнительной документации. Это всё порождает многообразие того, как комплект технической документации может быть составлен. Тут, на практике, стандарта не получается.
Что я однозначно разделяю по разным документам:
- Функциональные требования (или ТЗ), которые описывают изменения и доработки в имеющейся или приобретаемой системе.
- Требования (или ТЗ), которые описывают отдельно взятое новое программное обеспечение, которое должно быть разработано.
- Спецификации, которые описывают форматы взаимодействия / обмена данными.
- Документы, которые описывают нечто над вышеперечисленным (в пунктах 1, 2 и 3).
Документы третьего и четвёртого пункта, как ни крути, отличаются от первых двух тем, что не относятся ни к одной из систем (третьи между, четвёртые над). Системы же должны описываться по отдельности друг от друга.
Что касается последнего пункта, это могут быть:
- Бизнес-требования
- Протоколы согласований
- Описание архитектурного решения
- Различные прочие документы обоснований
Описание архитектурного решения является документом обоснования для той части требований ТЗ, которые касаются реализации.
Аналитики из крупных банков (разные) рассказывали мне, что у них есть три категории документов:
- Документы, относящиеся к бизнес-требованиям (они их называют BRD — Business Requirements Document).
- Архитектурный документ.
- Спецификации (они их называют 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, в зависимости от важности различных входящих в неё частей, может выливаться в несколько последовательных разделов.
Формат не претендует на пригодность во всех случаях жизни, но во многих из них поможет.
Можно скачать шаблон ТЗ с примерами заполнения.