Как составить тех задание на программное обеспечение

Стандарты и шаблоны для ТЗ на разработку ПО

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1. Введение

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы
  • 1. Содержание системы
  • 2. Функции системы
  • 3. Характеристики пользователей
• 4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

1. Введение

• 1. Назначение
• 2. Содержание (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения
• 4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами:

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

ТЗ на разработку программного обеспечения

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

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

Что такое ТЗ на разработку ПО?

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

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

Правильно составленное техническое задание дает четкую связку заказчик-исполнитель,
что позволяет обеим сторонам понимать друг друга. Грамотное ТЗ устанавливает следующее:

• Главное назначение разрабатываемого ПО.

• Характеристики и функциональность.

• Технико-экономические обоснования разработки.

• Предписание по выполнению стадий, этапов работы.

Чем детальнее составлено техническое задание, тем лучше. Благодаря этому заказчик понимает,
что именно ему нужно, может контролировать исполнителя на предмет соответствия продукта ТЗ.
Исполнитель в свою очередь получает точные сведения относительно задачи, может спланировать
проект, а также персональный план по ее воплощению.

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

Особенности технического задания в новых условиях

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

• 1.

  Прикладное ПО. Софт, предназначенный для решения конкретного круга прикладных задач, которые используются в разных областях человеческой деятельности.

• 2.

  Системное ПО. Программы, ведущая задача которых – обеспечение работы компьютера, LAN сетей.

• 3.

  Инструментальное ПО. Средства, создаваемые для отладки, редактирования софта.

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

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

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

2. Технический проект. Документ, в котором подробно прописывается последовательность действий для софта.

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

Информационный комплекс и структура технического задания

Как отмечалось выше, техническое задание должно быть четким и понятным обеим сторонам. На первом этапе должны быть
сформулированы правила к разрабатываемой информационной системе. Все непонятные вопросы проясняются, что позволяет
избежать недопонимания. Практика подтверждает, что на разработку ТЗ уходит до 25-30% от всех затрат. Это связано
с потребностью в техническом проектировании, глубокой аналитической и технической работе.

Многое в ТЗ зависит от языка программирования, на котором будет создана программа. К примеру, если софт
разрабатывается на языке С++, то требуется детальное техническое проектирование. Что касается софта, создаваемого
на платформе 1С, ее проектируют по классической схеме. Все правила прописываются в отдельном разделе. К каждому из
них прикладывается план, предусматривающий выполнение с поэтапной структурой. Таким образом, создание
ТЗ – сложная работа, требующая затрат сил, времени.

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

• 1.

  Общая информация.

• 2.

  Цели разработки (развития), назначение.

• 3.

  Характеристика объектов автоматизации.

• 4.

  Главные нормы будущего софта.

• 5.

  Состав, содержание работ по созданию системы.

• 6.

  Порядок контроля, приемки готового ПО.

• 7.

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

• 8.

  Нормы к документированию процесса.

• 9.

  Источники для выполнения поставленной цели.

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

ГОСТы к техническому заданию на разработку программного обеспечения

Техническое задание позволяет четко разделить обязанности, согласовать работу между всеми специалистами. Благодаря
этому можно обеспечить командную работу. Проконтролировать выполнение поставленной задачи в оговоренные сроки, без
затрат трудовых ресурсов. Существуют разные примеры ТЗ на разработку программного обеспечения, в основе каждого из
которых лежит определенный ГОСТ.

Для лучшего понимания отличий методологии при составлении ТЗ, стоит подробнее рассмотреть эти ISO и нормы, которые
используются для выполнения поставленной задачи. Это позволит лучше понять отличия и пользоваться тем ГОСТом,
который подходит наилучшим образом.

ГОСТ 34

Используется для разработки систем, предусматривающих не только разработку ПО, но также подбор нужного аппаратного
обеспечения. Это позволяет также выгодно автоматизировать информационные процессы на предприятии. По данному ГОСТу
при разработке ТЗ предусматриваются такие разделы:

• 1.

  Сведения общего характера.

• 2.

  Цели и задачи создания системы (софта).

• 3.

  Характеристика главных объектов автоматизации.

• 4.

  Нормы к разрабатываемой системе.

• 5.

  Состав с содержанием работ по созданию программы.

• 6.

  Порядок приемки системы с контролем со стороны заказчика.

• 7.

  Требования к содержанию работ по подготовке к вводу системы в действие.

• 8.

  Нормы к документированию.

• 9.

  Источники для создания софта.

Обычно данного стандарта придерживаются при выполнении государственных проектов.
В проект могут быть внесены корректировки и изменения по согласованию с клиентом.

ГОСТ 19

Документом определяются государственные стандарты, которые устанавливают общие правила создания,
оформления и обращения программного обеспечения, создания документация. ГОСТом также устанавливается
Единая система программной документации (сокр. ЕСПД). Согласно стандарта, в проект входят такие разделы:

• 1.

  Введение.

• 2.

  Основания.

• 3.

  Назначение.

• 4.

  Требования к софту (программному изделию).

• 5.

  Особенности программной документации.

• 6.

  Технико-экономические показатели.

• 7.

  Стадии, этапы создания ПО.

• 8.

  Порядок контроля, приемки.

• 9.

  Приложения.

Данные ГОСТы используются далеко не всеми программистами. Ведь они были разработаны свыше 30 лет назад.
Для этого будет полезным рассмотреть более актуальные, новые стандарты,
применяемые для создания современного софта.

IEEE STD 830-1998

Данным документом определяются качественные характеристики, содержание, спецификация, нормы, которые
предъявляются к программному обеспечению. В документе даны конкретные определения основных понятий и терминов.
Чаще всего документ применяется при разработке задания для современного софта. Согласно стандарту,
ТЗ по IEEE STD 830-1998 включает в себя такие разделы:

1. Введение

• Назначение

• Область действия

• Определения, акронимы, сокращения

• Ссылки

• Краткий обзор

2. Общее описание

• Взаимодействие продукта (с другими продуктами и компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователя.

• Ограничения.

• Допущения и зависимости.

3. Детальные требования

• Требования к внешним интерфейсам.

• Интерфейсы пользователя.

• Интерфейсы аппаратного обеспечения.

• Интерфейсы программного обеспечения.

• Интерфейсы взаимодействия.

• Функциональные требования.

• Требования к производительности.

• Проектные ограничения (и ссылки на стандарты).

• Нефункциональные требования (надежность, доступность, безопасность и пр.).

• Другие требования.

4. Приложение

5. Алфавитный указатель

Данный стандарт разработан американским Комитетом по стандартам программного обеспечения и системной инженерии C / S2ESC.

ISO/IEC/ IEEE 29148-2011

Наиболее современный стандарт, который обеспечивает единый способ трактовки в процессах при разработке ТЗ для ПО.
Оригинал IEEE доступен на английском языке. В состав входит 2 шаблона, каждый из которых рассмотрим подробней:

System requirements specification (SyRS)

Стандарт определяет тех. требования для системы. Содержит концептуальные разработки для разных сценариев,
рабочих процессов. Имеет разделы:

1. Введение

• Назначение системы.

• Содержание системы (границы системы).

• Обзор системы.

• Содержание системы.

• Функции системы.

• Характеристики пользователей.

• Термины и определения.

2. Ссылки

3. Системные требования

• Функциональные требования.

• Требования к юзабилити.

• Требования к производительности.

• Интерфейс (взаимодействие) системы.

• Операции системы.

• Состояния системы.

• Физические характеристики.

• Условия окружения.

• Требования к безопасности.

• Управление информацией.

• Политики, правила.

• Требования к обслуживанию системы на протяжении ее жизненного цикла.

• Требования к упаковке, погрузке-разгрузке, доставке и транспортировке.

4. Тестирование и проверка (список нужных приемочных тестов, которые отражают зеркально раздел 3)

5. Приложение

• Предположения, зависимости.

• Аббревиатуры и сокращений.

Software requirements specification (SRS)

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

1. Введение

• Назначение.

• Содержание (границы).

• Обзор продукта.

• Взаимодействие продукта (с другими продуктами, компонентами).

• Функции продукта (краткое описание).

• Характеристики пользователей.

• Ограничения.

• Терминология, определение со значениями.

2. Ссылки

3. Детальные нормы

• Требования к внешним интерфейсам.

• Функции продукта.

• Параметры юзабилити.

• Нормы производительности.

• Требования к логической структуре БД.

• Ограничения проектирования.

• Системные свойства ПО.

• Дополнительные требования.

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложение

• Предположения, зависимости.

• Аббревиатуры и сокращений.

Такой стандарт пришел на смену IEEE STD 830-1998. Он также был разработан в США и сегодня
используется разными специалистами разных стран мира.

Заключение

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

Почему ТЗ — это важно

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

Если кратко, ТЗ — определяет структуру и цель вашей системы. Без него сложно представить качественную разработку программного обеспечения. Правильно составленное ТЗ поможет вам сэкономить время, бюджет и нервы.

В статье я расскажу:

1. почему оформлению ТЗ нужно уделить особое внимание,
2. какие разделы включить в ТЗ и что в них должно быть;

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

ТЗ — это ваша гарантия

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

Первый сценарий — это работа с недобросовестным подрядчиком, когда он делает «тяп-ляп».

Второй сценарий — это когда вы работаете с нормальным подрядчиком, но из-за нечетких требований в ТЗ вы с исполнителем встречаетесь с недопониманием, что в результате влияет на конечный вид системы.

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

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

ТЗ — это фундамент вашего приложения

Представьте, что ваше приложение — это дом. Этот дом должен стоять на крепком фундаменте. Так вот, техническое задание и есть этот фундамент для вашего программного обеспечения.

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

Всё ТЗ описывается «бизнесовым языком», то есть, как должна вести себя система с точки зрения пользователя (о пользователях и их ролях расскажу позже). Такое описание упрощает компании разработчику его вычитку, а в дальнейшем и оценку, так как, вероятно именно бизнес-аналитик будет вычитывать ТЗ, а затем собирать оценку на выполнение задач у команды разработчиков.

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

ТЗ помогает лучше спланировать работу системы

Перечитывать свое ТЗ — не такая плохая идея. Даже так — это замечательная идея!

Приведу пример. Автомобильной дилерской сети нужна корпоративная система, в которой будет учитываться количество принятых автомобилей с завода с разбивкой на комплектации, количество предварительных продаж, отработанных часов автомеханика, продаж, закрепленных за менеджером и др.

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

Но что, если вы не заметили очевидных вещей, которые должны быть предусмотрены?

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

В случае с примером, отсутствие возможности корректировать введенные данные — это существенный недостаток в системе, а виной всему — непроработанное ТЗ.

Конечно, можно вносить правки в ТЗ во время разработки. Тот же метод работы по Agile способствует этому. Однако, случается и так, что для внесения правок нужно затронуть архитектуру и переписать уже готовый функционал. Получается уже какая-то доработка системы. Время, затраченное на введение такой фичи в процессе разработки больше, чем если бы вы указали её сразу в ТЗ.

ТЗ позволяет сокращать расходы

Представьте, что на разработку приложения выделено 5 миллионов. Вы присылаете ТЗ некоторому количество разработчиков и получаете оценку в 7-8 миллионов.

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

У вас есть 5 миллионов и точка, а система очень нужна. С проработанным ТЗ вы можете поступить следующим образом: самостоятельно, или обратившись к разработчику убрать требования к функциональности, которые не будут мешать основному назначению и целям системы. Назначение и цели системы прописываются в ТЗ. Об этом расскажу чуть позже.

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

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

Обязательно ли делать ТЗ своими силами

Отличная идея! Почему бы не поступить также? У вас нет подходящего сотрудника, который сможет простым и понятным языком описать систему, при этом не упустив важных деталей? Тогда обратитесь к сторонней компании.

Практически любая аутсорсинговая компания разработчик может разработать за вас ТЗ. Конечно, в 9 из 10 случаев за это придется заплатить. Зато вы получите отличное, полное техническое задание! Более того, вы можете не обращаться к тому же подрядчику за разработкой, а начать исследования рынка и найти того вендора, который вам понравится.

В дальнейшем, если возникнут новые задачи на разработку, вы сделаете новое ТЗ по шаблону старого. Это очень удобно, не правда ли?

Как должно выглядеть ТЗ

Обратите внимание, что мы описываем структуру ТЗ по нашему шаблону. Наше ТЗ — гибрид из стандарта по ГОСТу и собственных предпочтений. Можно сказать, что этот шаблон — тот документ, который мы видим у «идеального» заказчика. По нашему мнению, такая структура ТЗ максимально удобна для описания системы, и поверьте, технических заданий за 10 лет работы мы видели не малое количество…

Документ состоит из основных разделов:

1. общие сведения,
2. назначение и цели создания,
3. требования к системе в целом,
4. функциональные требования,
5. виды, состав, объем и методы испытаний системы,
6. общие требования к приёмке,
7. статус приемочной комиссии;

Раздел Общие сведения

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

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

Не забудьте добавить требования, которые не относятся к реализации проекта. Требования касаются регулирования работы двух сторон, например:

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

Резюмируем. Добавьте:

1. Реквизиты исполнителя и заказчика.
2. Сроки начала и окончания проекта (вплоть до разбивки по этапам).
3. Опишите требования, которые не касаются разработки приложения.

Цели и назначение проекта.

Помните, это то, о чём мы ранее говорили в разделе «ТЗ позволяет сокращать расходы»? Так вот, цель проекта — это основная причина, почему вам нужно разработать приложение, и примерно, что оно будет из себя представлять.

Пример содержимого цели. Наша компания занимается логистикой и сейчас мы пользуемся коробочным продуктом, который раньше нас устраивал. После того, как предприятие начало расти, коробочный продукт не смог автоматизировать новые бизнес-процессы. Доработка не подходит, так как она слишком дорогая. Вдобавок, если мы согласимся на доработку, тогда права на продукт мы всё равно не получим.

После прочтения цели мы понимаем, зачем вам нужна кастомная разработка (в данном случае нужно автоматизировать бизнес-процессы), и, если вы укажите «прототип» того, что нравится — это упростит дальнейшую разработку.

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

Что такое назначение? Назначение заключается в том, как будет использоваться продукт.

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

Резюмируем.

1. Цель — это то, зачем нужен проект и какую роль он будет выполнять.
2. Назначение — это то, как потом мы будем его использовать.

Раздел Требования к системе в целом

В этом разделе нужно зафиксировать все нефункциональные требования. Давайте поделим раздел на следующие пункты:

1. Требования к защите от влияния внешних воздействий
2. Требования к патентной чистоте
3. Требования к стандартизации и унификации
4. Дополнительные требования
5. Требования к функциям и задачам системы
6. Требования к видам обеспечения

Требования к структуре и функционированию системы

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

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

Показатели назначения

Ранее мы уже разобрали, что такое назначение. Давайте разберём это простыми словами на примере.

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

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

Чтобы достичь нашего назначения нам нужно:

1. Создать систему регистрации / авторизации, верификации, заполнения профиля
2. Создать систему поиска пары
3. Разработать и внедрить игры в приложение.
4. Разработать систему подбора игроков.
5. Добавить функционал общения во время игры.
6. Создать систему матчей (совпадение лайков профилей) в игре и вне игры.
7. Создать чат

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

Выполнив 1 пункт, мы можем создать анкету. Чтобы найти другого человека, а в дальнейшем играть и общаться с ним, нужно выполнить 2 пункт.

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

Показатели надёжности

В этом разделе можно встретить следующие формулировки:

1. приложение должно выдерживать одновременно более N тысяч пользователей, при этом не тормозить,
2. приложение должно хранить данные пользователя в БД на отдельном сервере,
3. если система по разным причинам перестала работать (что-то с хост-машиной, либо сбой в системе), то она должна перезапуститься автоматически в течение 10 минут
4. система не должна быть нагружена более чем на 80 процентов, при превышении лимита нужно закрывать доступ новым пользователям, чтобы снизить нагрузку;

В общем, здесь рекомендую прописать, какие экстренные аварийные ситуации могут произойти и как система должна отреагировать.

Системные требования

Показатели надёжности и системные требования могут вас запутать. Давайте раз и навсегда разделим эти определения!

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

Системные требования охватывают вопросы:

1. какие характеристики серверов или ПК должны быть,
2. как они должны работать,
3. как предотвращать перегрузки,
4. как обслуживать эти сервера,
5. какая ОС должна быть на сервере и т.д;

Требования к эргономике и технической эстетике

Замудренная формулировка, не правда ли? На самом деле здесь всё просто.

Этот раздел посвящен UX интерфейсу, т.е. как человек должен взаимодействовать с нашим ПО: какие кнопки, поля, ссылки, таблицы будут находиться на странице приложения, и, как они будут работать при взаимодействии пользователя с этими элементами.

На примере страницы регистрации, описание UX выглядит примерно так…

Для начала напишем какие элементы находятся на этой странице.

На странице регистрации будет три обязательных поля и чекбокс, а также две кнопки.

1. Поле ввода логина
2. Поле ввода емейла
3. Поле для ввода пароля
4. Чекбокс подтверждения обработки персональных данных.
5. Кнопка Зарегистрироваться
6. Кнопка Вернуться на главную

Теперь опишем расположение этих элементов…

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

В дальнейшем UX описание понадобится дизайнеру для создании макета, а разработчикам для вёрстки.

Требования к транспортабельности для подвижных АС

В разделе указываете способы транспортировки оборудования.

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Этот раздел относится к серверам. Часто здесь дают ответы на следующие вопросы:

1. кто будет обслуживать сервера,
2. как часто их нужно обслуживать,
3. каким образом это делать,
4. как всё настроить и всё в таком духе;

Этот раздел будет важен для вас, если вы планируете размещать программное обеспечение на ваших серверах или ПК (допустим это десктоп приложение).

Требования к защите информации от несанкционированного доступа

Судя по нашему опыту работы с банками, (а работаем мы преимущественно с фин. организациями) именно они уделяют особое внимание этому разделу. Они наиболее детально описывают:

1. кому предоставлены доступы,
2. к каким разделам предоставлены доступы,
3. кто может изменить все креды,
4. как быть, если кто-то извне вошёл в систему,
5. как заблокировать подозрительного пользователя,
6. кто и при каких условиях может изменять параметры доступа,
7. какие требования к аутентификации,
8. как запретить вход в систему сторонним лицам, даже при наличии кредов;

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

Требования по сохранности информации при авариях

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

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

Требования к защите от влияния внешних воздействий

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

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

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

Требования к патентной чистоте

Этот раздел носит юридический характер. Давайте кратко и для общего познания обговорим, что это такое.

Патентная чистота — это исключительные права на ваше приложение, которые еще называются «интеллектуальной собственностью».

В зависимости от законодательства страны правила о патентном праве могут различаться.

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

В случае отсутствия нарушений, вы в полном праве использовать приложение сколько угодно, без нарушения чужих прав (а значит сможете продавать его и тд)

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

В результате продукт выстрелил… Отличный старт! Пора расти. Больше всего популярна криптовалюта за рубежом, поэтому будем продвигать своё приложение на иностранном рынке. Здесь то мы и встречаемся с проблемой.

Оказалось, что в этих странах уже запатентована система сдачи биткоинов в аренду. Вы никак не сможете иметь на приложение исключительные права, и в лучшем случае вам придётся платить процент за использование запатентованной идеи.

Именно юристы составляют требования для оформления патентной чистоты приложения. Если у вас Наполеоновские планы, не забудьте «потыкать» юриста, чтобы он добавил всю необходимую информацию в этот раздел.

Требования к стандартизации и унификации

Если в процессе работы для вас очень важно соблюдать ГОСТ или другие стандарты, тогда зафиксируйте их в этом разделе.

Приведу пару возможных формулировок:

1. нужно реализовать систему безопасности в приложении по ГОСТу,
2. разработка должна проводиться по методологии waterfall,
3. корпоративная система должна быть построена по методологии ERP 2;

Дополнительные требования

В разделе фиксируется всё, что не касается предыдущих и следующих разделов.

Часто сюда прописывают следующие пункты:

1. какой уровень владения ПК должен быть у пользователя, чтобы он комфортно мог использовать систему,
2. список ролей в системе (сюда можете просто добавить список, а их описание будет в функциональных требованиях к продукту),
3. требования к контурам — это техническая информация. Обычно контуры делятся на dev, prod, или dev, test, prod. Кому как удобно;

Требования к функциям и задачам системы

Мы всё ближе к функциональным требованиям! Потерпите ещё чуть-чуть.

В этот раздел заполните общую информацию о том, какие возможности в системе должны быть, но без подробностей.

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

Сюда же можете записать временные регламенты — когда должна отрабатывать какая-нибудь функция.

Пример. Ваше приложение — маркетплейс. Вам нужно, чтобы с 04:00 до 05:00 утра по МСК обновлялась цена по нижнему уровню стоимости каждого товара, взятая из других маркетплейсов.

Если ваше приложение выполняет множество расчетов, то для каждой функции пропишите алгоритм вычислений.

Если у вас есть пожелание к тому, как должна выглядеть информация в интерфейсе, тогда зафиксируйте логику вывода информации в этот раздел.

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

Требования к видам обеспечения

Совместный для заполнения исполнителем и заказчиком раздел. В нём фигурируют пункты:

1. математическое обеспечение,
2. информационное обеспечение,
3. лингвистическое обеспечение,
4. программное обеспечение системы,
5. техническое обеспечение,
6. требования к метрологическому обеспечению,
7. организационное обеспечение,
8. методическое обеспечение,
9. требования к численности и квалификации персонал;

Математическое обеспечение системы — это математические модели и алгоритмы, которые исполнитель будет использовать. Здесь могут быть ранее не прописанные вами алгоритмы вычислений, к которым пришёл исполнитель в процессе изучения ТЗ. Это достаточно важный пункт, так как на основе прописанных здесь моделей будут производиться вычисления в системе.

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

Перечислю всё, что должен написать исполнитель:

1. как организовано хранение данных (какую информацию будем сохранять в базу данных и в какие поля её записывать),
2. как построена взаимосвязь между компонентами системы (например, после успешного оформления покупки, компонент, отвечающий за оплату, тыкает компонент корзины, что покупка совершена успешна и можно её очистить.),
3. как компоненты приложения связаны с внешними сервисами и как они должны обмениваться информацией. Например, после успешной оплаты, отвечающий за это компонент передает информацию во внешний сервис, который занимается рассылкой SMS, чтобы тот в свою очередь выслал код подтверждения обратно в систему и пользователю для получения товара)

Лингвистическое обеспечение — это перечень всех технологий, которые будут использоваться: языки программирования (C#, TypeScript), базы данных (mongoDB, SQL Lite), библиотеки (React, Angular)

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

Например, для сайтов можно указать перечень браузеров, а для десктопных приложений — операционные системы.

Вот ещё один пример. Вам нужно шифровать данные, тогда укажите ПО, с помощью которого нужно это делать (например, Валидата).

Техническое обеспечение — это требования к серверу или ПК, на котором будет работать ПО

Например, технические характеристики серверов, если это веб-приложение, или технические характеристики компьютера, на котором будет работать десктопное приложение.

Требования к метрологическому обеспечению — пункт, касающийся аппаратной разработки. Здесь указываются те приборы, которыми можем проверить корректность работы ПО.

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

Организационное обеспечение — пункт, в котором вы указываете, кто будет пользоваться приложением и какие права доступа будут у этих пользователей.

Пример. Для вашего отеля разработано мобильное приложение, с помощью которого посетители отеля могут заказывать еду в номер, планировать время уборки номера, наблюдать за растущим счётом за пребывание в отеле и др. Тогда посетитель отеля — пользователь, а персонал — администраторы и модераторы с разными правами доступа.

Для каждой группы пользователей нужно разбить роли и права доступа. Условно, если даже у уборщика и менеджера роль называется «администратор», то админские права могут отличаться. Уборщик не может забронировать номер для клиента, а менеджер не может отметить, что в номере завершили уборку.

Методическое обеспечение — сюда входит техническая и пользовательская документация. По необходимости может быть создан документ «пользовательские сценарии».

Техническая документация — это инструкция для разработчиков. В ней содержатся любые технические детали: описание API, комментирование кода, описание архитектуры.

Пользовательская документация (руководство пользователя) — это документ, в котором описано как пользователю начать работать с системой, и какие возможности приложения он может использовать.

Пользовательские сценарии — это описание действий пользователя. Т.е. описывается порядок действий пользователя.

Пример пользовательского сценария. Пользователь зашёл на сайт. На экране появляется модальное окно для входа или регистрации. По умолчанию пользователь в модальном окне видит вкладку с авторизацией Чтобы начать работу в системе, пользователю нужно войти или зарегистрироваться. В зависимости есть у него аккаунт или нет, он выбирает нужную вкладку и вводит свой Email и Пароль.).

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

Требования к численности и квалификации персонала. В разделе прописываются минимальные требования к умениям пользователя для работы в системе. Например:

1. навык владения компьютером (допустим, десктоп приложение на Linux, а пользователь никогда не работал в этой ОС)
2. умение работать с Excel (допустим, рекламная система умеет импортировать .csv формат для управления ставками в поисковой рекламной кампании. Для корректного импорта, нужно создать определенные поля с ключевыми словами, где для ключевого слова прописать специальную формулу с помощью которой система поймёт, какую ставку выставить. Пользователь может не знать, как оформлять документ так, чтобы система его поняла.),
3. умение администрировать операционную систему (допустим, разработано сложное ПО, для перезапуска которого нужно использовать командную строку);

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

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

Функциональные требования к продукту

В этом разделе описываются все функции системы. Уделите разделу особое внимание. Не забудьте перечитать его в своём ТЗ несколько раз.

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

Я бы предложил описывать систему, используя один из двух вариантов:

1. Описание функционала постранично.
2. Описание системы, используя метод логического разделения функций.

Описание функционала постранично. Если вам нужно разработать веб-приложение, тогда составьте список страниц и опишите их содержание с точки зрения пользователя: что должно там находиться и как работать. Например, что может делать пользователь в своём личном кабинете (страница личного кабинета).

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

На странице со списком проектов вверху слева находится поле для ввода. В это поле вы можете ввести номер (идентификатор), который присваивается проекту или ввести его название.

Справа сверху вы можете нажать на иконку своего профиля, чтобы зайти в личный кабинет.

Правее от профиля находится кнопка, по нажатию на которую всплывает модальное окно. В модальном окне есть три кнопки:

1. Выйти — выход из системы.
2. Помощь — открытие страницы с пользовательской документацией.
3. Войти в ЛК — переход на страницу с личным кабинетом.

В центре экрана находится список проектов, оформленный в виде таблицы со столбцами:

1. Проект — указывается название проекта. По нажатию на название пользователь переходит на страницу с проектом.
2. ID — указывается идентификатор проекта.
3. Статус — Активен / Неактивен
4. Настройки проекта — кнопка настроек для проекта. По нажатию открывается новая страница с настройками проекта
5. Экспорт отчёта — кнопка выгрузки отчёта. По нажатию на кнопку всплывает модальное окно (о нём писать здесь не нужно, т.к. это может быть отдельная крупная модалка)

Если вы используете этот вариант, то не забудьте добавить общее описание системы. Обычно это то, что не содержится на самой странице, например:

1. Какие роли нужны, а также какие возможности доступны для каждой из ролей.
2. Нужна ли мультиязычность

Логическое разделение функций. Будьте осторожны с этим способом. Если у вас ещё мало опыта, то лучше описывайте требования к функционалу постранично. Самое главное в этом способе точно определить, какую цель выполняет данная функция.

Пример разделения функций. Функция регистрации выполняет цель добавления пользователя в систему.

Функция входа позволяет пользователю получить определенную роль и работать в системе. Функция загрузки отчёта…. Правильно, загружает отчёт в систему. Функция корзины — сохраняет за пользователем определенные объекты, которые он выбрал.

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

Оформляйте этот раздел как вам удобно. Главное, чтобы это было понятно вам и тому, кому направите ТЗ. Мне было бы удобно составлять требования следующим образом:

1. [Название функции/страницы]
2. [Краткое описание]
3. [Элементы на экране]
4. [Детальное описание возможностей функции]
5. [Список функций, взаимодействующих с ней]

Виды и состав испытаний системы

В этом разделе мы описываем:

1. как сдаём проект,
2. как оцениваем его,
3. как делим работу на этапы,
4. при каких условиях проводим тестирование. Например, на dev ветке — сайт доступен только для разработчиков, или на prod — сайт доступен к использованию всеми пользователями,
5. когда планируем графики релизов;

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

Общие требования к приёмке работ

Здесь заказчик, либо исполнитель прописывает, как будут проходить этапы сдачи, из чего они будут состоять, что будет требоваться при сдаче каждого этапа, как определить, что все требования выполнены.

Пример. Ваш проект поделен на 4 этапа разработки. Для каждого этапа вы составляете перечень требований, которые необходимо выполнить, а затем указываете, что этап будет считаться сданным, если будет работать минимум 90% заявленных функций.

Ещё здесь можно указать документы, которые будут участвовать в приёмке. Допустим, вам по регламенту нужно составить документ программы и методики испытаний

Статус приёмочной комиссии

В этом разделе указывается:

1. ФИО и должности тех, кто будет принимать каждый этап. Не забудьте обосновать, почему именно они должны принимать сдачу (какое отношение имеют к проекту),
2. ФИО и должность ответственного лица, который будет принимать проект полностью,
3. список сотрудников, которые будут сдавать проект. (обычно это тестировщик, менеджер проекта и аналитик);

Финальная реплика

Вот вы и дочитали статью до конца. Я очень надеюсь, что статья поможет вам в написании ТЗ. Как и обещал, шаблон ТЗ вы можете скачать, нажав СЮДА. Желаю вам удачи в написании крепких ТЗ и в поиске подходящего вендора!

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается “как получится”. Как сказал Генри Шоу “Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи”.

О чем эта статья?

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?».  Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.  В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:  

• В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.

• Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос  интересует тех, кто спрашивает «Как разработать техническое задание?»  Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания.   О каких вариантах я говорю:

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной  IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную  IT-службу. Решили поступить так:  разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;

• Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.

• IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:

  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;

  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);

  • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);

  • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.

  • Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

• А почему нельзя разрабатывать Техническое задание всегда одинаково?

• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?

• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?

• Как понять, хорошо составлено Техническое задание или нет?

• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли.  Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах.  Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

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

Что такое техническое задание?

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись.  Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.  Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что  в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации – далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;

• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;

• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения ): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ.  А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

И так, как следует из определения, основное назначение Технического задания – сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;

• Требования к безопасности и правам доступа;

• Требования к квалификации персонала;

• …. И т.д. Вы можете  прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования.  Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома.  Красота!).  Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат  нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

1. Требование должно быть понятным;

2. Требование должно быть конкретным;

3. Требование должно быть тестируемым;

Причем последнее свойство невозможно без двух предыдущих, т.е. является этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. Когда разберешься.

На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание? 

• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?

• А что такое техническое  проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

Так вот:

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

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально).  А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований.  Что, знакомая ситуация?  И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между  ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично  это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени – это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах

Уметь настраивать и вести управленку — значит быть полезным для руководителей. Научитесь понимать, откуда приходят и куда уходят деньги компании на курсе повышения квалификации от «Клерка».

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей  так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так  что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.  Должен ли с ним знакомиться  Заказчик? Если хочет, почему нет, но настаивать  и утверждать данный документ нет никакой необходимости, он будет только сдерживать и  мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы  и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий.  По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично!  Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю?  Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

И так, ГОСТ рекомендует следующие разделы:

1. общие сведения;

2. назначение и цели создания (развития) системы;

3. характеристика объектов автоматизации;

4. требования к системе;

5. состав и содержание работ по созданию системы;

6. порядок контроля и приемки системы;

7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8. требования к документированию;

9. источники разработки.

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Раздел 2. назначение и цели создания (развития) системы.

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Раздел 8. Требования к документированию

Раздел 9. Источники разработки

И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.

Но вот без главного: функциональных требований ни одно грамотно  Техническое задание не обходится.  Хочу  заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег  именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.

Во второй статье  будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

• Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.

• Следует стараться не использовать длинных предложений;

• Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;

• Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;

• Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др.  Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:

• онлайн-калькулятор;
• программу рассылки;
• анализатор статистики;
• парсер и так далее.

Или вы хотите создать какой-то уникальный сервис для пользователей.

В таких случая не всегда получается воспользоваться готовыми решениями и приходится нанимать программиста.

Составление вакансии и ТЗ для программиста

Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

1. Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
2. Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
3. Штрафы и правки.
4. Подробное описание того, как вы видите результат работы.
5. Техническая информация.
6. Тестирование

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

Желаемый результат

Чтобы при принятии готовой программы не было разногласий, лучше подробно описать, что вы хотите получить.

Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:

• в какое поле пользователь может вставлять текст;
• должен ли он проверяться в режиме реального времени;
• как будут выделяться ошибки;
• будут ли комментарии к ошибкам;
• будет ли ограничение на объем или количество попыток;
• какой объем текста можно проверить за один раз или за один день;
• как пользователи будут оплачивать дополнительные попытки или объем;
• какие бонусы будут получать пользователи;
• нужно ли измерять грамотность текста в баллах;
• нужно ли сохранять текст в базу данных и так далее.

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

Техническая информация

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

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

Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.

Стандарты оформления кода

Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.

Я спросил Ольгу Безматерных, HR-директора TexTerra, что она думает по поводу работы с чужим кодом. Она ответила, что он замедляет выполнение задач, а один раз в ее практике был случай, когда работать с кодом было невозможно – пришлось вернуть деньги.

Поэтому если над проектом работает несколько человек, нужно составить стандарты оформления кода – что-то вроде редполитики для программистов.

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

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

Поэтому, чтобы потом эту программу легко мог исправить любой другой программист, нужно чтобы у нее был какой-то стандартизированный вид. Доверить составление стандартов можно первому программисту, с которым вы работали.

Подключение и тестирование

Перед подключением программы лучше проверить код на наличие лазеек – предумышленных или нет. Если их нет, можно подключать. Дальше идет тестирование и открытие доступа для всех пользователей.

Заключение

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