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

Введение

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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»

Техническое задание. Принципы написания. — Грамант

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.

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

Структура технического задания

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

1. Оглавление
2. История изменений документа
3. Участники проекта
4. Назначение документа
5. Терминология
6. Общий контекст

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

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.

7. Система размещения баннеров
8. Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

Бизнес vs Функциональные требования

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

Обычно мы включаем

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

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т. п. Фактически, все рекламные кампании состоят из размещений».

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

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

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Опыт в предметной области

Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.

Подготовка технического задания для проекта по развитию ИТ АКА 6 шагов к новой информационной системе, интернет-магазину или сети

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

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

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

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

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

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

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

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

1. Кратко запишите справочную информацию о проекте.

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Подумайте о требованиях к вашему проекту и запишите их.

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

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

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

Чем больше интерфейсов и чем они сложнее, тем выше объем разработок и стоимость проекта.

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

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

4. Затем продумайте и запишите, кто ваши типичные пользователи (персоны).

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

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

5. Если возможно, нарисуйте первоначальный прототип.

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

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

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

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

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

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

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

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

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

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

В Trinidad Wiseman мы можем помочь вам на каждом этапе проекта и провести анализ, дизайн UX / UI, брендинг, разработку, тестирование и обслуживание. В любом случае, я призываю вас написать нам, даже если техническое задание еще не ясно.

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

Шаблон технического задания (ТЗ) по управлению проектом

Содержание

• Техническое задание: определение и цель
• Что включено в ТЗ?
  • • 1. Background
    • 2. Objectives
    • 3. Issues
    • 4. Methodology
    • 5. Expertise
    • 6. Reporting
    • 7. Work Plan
• Wrapping Up

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

В следующем шаблоне представлен обзор основных разделов технического задания по проекту. В этом руководстве я описываю определение и содержание ТЗ. Шаблон доступен для бесплатного скачивания в виде файла .doc.

Шаблон технического задания Скачать бесплатно
(файл DOC, 48Kb)

Техническое задание: определение и цель

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

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

ТЗ проекта содержит четкое описание следующей важной информации:

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

Что входит в ТЗ?

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

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

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

Общий формат содержания Технического задания на проект предлагается ниже:

• Предыстория проекта
• Цели проекта
• Вопросы, которые необходимо изучить и проанализировать в соответствии с определенными критериями
• Применяемая методология реализации

20 Необходимый опыт Требования к отчетности

• Рабочий план, включая графики мероприятий

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

1. Предыстория

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

Раздел «Основные сведения» шаблона ТЗ обычно включает несколько параграфов, в которых рассматриваются следующие вопросы:

• Опишите проект в контексте связанных с ним деловых потребностей
• Укажите общую роль заинтересованных сторон в выполнении проектной деятельности
• Выделите краткий обзор проекта на сегодняшний день

2. Цели

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

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

Тип работы/этап проекта	Общий объектив
– Завершение проекта	Увеличить продажи продукта «А» на 15% за 3 месяца
– ТЭО	Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия или отклонения предложенного проекта
— Мониторинг	Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия обоснованных суждений о выполнении проекта
– Аудит	Чтобы проект оставался актуальным и обоснованным с юридической, экономической и технической точек зрения

3.

Вопросы

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

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

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

4. Методология

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

Таким образом, раздел «Методология» шаблона технического задания по проекту должен включать описание следующих пунктов:

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

5.

Опыт

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

В разделе «Экспертиза» шаблона технического задания на проект должно быть указано следующее:

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

6. Отчетность

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

В разделе «Требования к отчетности» шаблона технического задания должны быть четко указаны требования к процессу отчетности и могут быть указаны следующие сведения:

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

7. Рабочий план

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

This entry was posted in Популярное