Как правильно составить тех задание на исследование

Что такое ТЗ?

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

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

Для чего требуется ТЗ?

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

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

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

Кто должен составлять ТЗ?

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

Заказчик

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

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

Исполнитель

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

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

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

Совместно

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

Стоимость ТЗ

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

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

Как составить ТЗ?

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

Что потребуется?

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

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

Пошаговый план

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

Рекомендации по составлению

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

1. Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
2. Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
3. Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
4. Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
5. Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
6. Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.

Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.

О стандартах

Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.

Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.

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

Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.

Порядок документирования требований

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

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

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

В каком случае ТЗ не нужно?

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

Шаблоны для скачивания и примеры

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

FAQ

Что такое ТЗ?

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

Для чего необходимо техническое задание?

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

Что следует включить в ТЗ?

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

Кто занимается составлением ТЗ?

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

Какие типичные ошибки допускаются при разработке технического задания?

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

Подведем итоги

1. Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
2. Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
3. Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
4. Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.

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

Содержание

1. Что такое цель исследования?
2. Что такое задачи исследования?
3. Как написать цель исследования?
4. Как определить задачи исследования?
5. Как правильно сформулировать цели и задачи в курсовой – примеры
6. Как составить цели и задачи в дипломной работе – примеры
7. Примеры написания цели и задач в диссертации
8. Ошибки при формулировке целей и задач в научной работе
9. Как проверить уникальность текста?
10. Как повысить уникальность текста?

01 Что такое цель исследования?

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

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

Например, работа по лингвистике «Речевая агрессия в языке СМИ».

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

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

02 Что такое задачи исследования?

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

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

03 Как написать цель исследования?

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

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

Перечислим, что именно может выражать цель:

• Исследование явление или какого-либо процесса
• Разработка методологической основы для решения научной проблемы
• Изучение отношений между элементами объекта, научными понятиями
• Систематизация протекания процессов
• Организация структурных элементов
• Выявление особенностей какого-либо объекта
• Подготовка характеристики какого-либо явления или предмета.

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

Используйте такие шаблоны:

• Целью явления является…
• Цель исследования заключается в том, чтобы …
• Цель исследования объясняется тем, чтобы…
• Цель исследования ‒ это…
• В цель исследования входит…
• Цель работы состоит в том, чтобы…

Лайфхак
Анти-антиплагиат.рф рекомендует проверять студенческую работу в Антиплагиат ВУЗ. Это специальная разработка для университетов, которую не найти в свободном доступе сети. 
Пройти любой антиплагиат можно с помощью повышения уникальности. Мы поможем вам набрать 80-90% оригинальности, обработав документ через программу Антиплагиат Киллер. Всего за 5 минут с отправления заказа мы обработаем ваш файл. Гарантируем вам отличный результат без изменений в тексте. 
Также поможем оформить работу по ГОСТ без ошибок в кратчайшие сроки.

Таким образом, вам осталось подставить в шаблон подходящее слово из представленного списка, затем название вашего предмета исследования – ваша цель исследования готова.

04 Как определить задачи исследования?

Для того, чтобы определить задачи исследования, достаточно понять следующее.

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

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

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

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

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

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

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

05 Как правильно сформулировать цели и задачи в курсовой – примеры

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

Тема курсовой работы по психологии: «Факторы, обусловливающие выбор профессии психолога».

«Целью данного исследования является изучение факторов, влияющих на выбор профессии психолога».

В задачи исследования входит:

• «Проведение теоретического исследования специфики профессии психолога;
• Выделение и описание направлений деятельности психолога;
• Изучение и описание “субъектных” и сценарных предпосылок;
• Разработка схемы эмпирического исследования;
• Поиск и разработка методического обеспечения исследования;
• Проверка предположения о том, что выбор направления деятельности психологом имеет сценарные предпосылки;
• Статистическая обработка полученных данных».

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

Тема курсовой работы по социологии: «Роль и место женщин в современном обществе».

«Цель исследования заключается в том, что определить перспективы развития женского движения и становления равноправия».

В задачи исследования входит следующее:

• «выявить специфику женского движения как социально-политического явления;
• определить основные этапы и особенности развития женского движения в странах Европы и США;
• рассмотреть идейные основы женского движения в государствах Ближнего Востока;
• на основе анализа нормативно-правовой базы, регулирующей положение женщин в государствах Ближнего Востока определить текущие возможности и ограничения для развития женского движения;
• определить факторы, способствующие развитию женского общественного движения в странах Ближнего Востока;
• выявить общее и частное в развитии женского общественного движения в странах Ближнего Востока и в европейских странах в ходе сравнительного анализа».

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

06 Как составить цели и задачи в дипломной работе – примеры

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

Тема дипломной работы по экономике: «Учет затрат на производство и реализацию продукции».

«Цель работы ‒ выявить пути улучшения финансовой отчётности и финансового состояния предприятия в условиях рыночной экономики».

Для написания работы поставлены следующие задачи:

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

Тема дипломной работы по педагогике: «Развитие чувства ритма у младших школьников».

«Цель дипломной работы: разработать методику развития чувства ритма у младших школьников».

Задачи исследования:

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

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

07 Примеры написания цели и задач в диссертации

Примеры написания цели и задач в диссертации аналогичны дипломной работе. Давайте рассмотрим их.

Тема диссертационной работы по юриспруденции: «Защита прав работников в условиях неплатежеспособности работодателя».

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

Для достижения указанной цели поставлены следующие задачи:

• «рассмотреть основные тенденции в изменении роли труда в современном обществе, прежде всего, в условиях кризиса как на микро, так и на макроуровне;
• на основе имеющихся научных разработок исследовать понятие «неплатежеспособность» применительно к статусу работодателя;
• изучить международные акты, правовые предписания и судебную практику Европейского Союза по вопросам защиты прав работников неплатежеспособного работодателя;
• проанализировать законодательство РФ, главным образом в сфере труда, на предмет его способности регулировать трудовые отношения в условиях неплатежеспособности работодателя;
• дать оценку ряду законопроектов по вопросам защиты прав работников неплатежеспособного работодателя».

Диссертационная работа по философии: «Культ богоматери в современной России».

«Целью диссертационного исследования является анализ основных тенденций формирования и развития православного культа Богоматери в современной России».

«Цель определила основные задачи исследования:

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

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

08 Ошибки при формулировке целей и задач в научной работе

Существуют ошибки, которые часто допускают студенты при формулировке целей и задач.

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

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

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

09 Как проверить уникальность текста?

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

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

В личном кабинете вы сможете загрузить свой документ только в ПДФ или ТХТ формате. Доступный модуль поиска только один – интернет. Это значит, что поиск плагиата проводится через открытые источники сети.

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

На этом возможности бесплатной версии Антиплагиат ру заканчиваются.

Также вы можете увидеть процент уникальности «глазами преподавателями» На сервисе анти-антиплагиат.рф доступна услуга проверки документа через Антиплагиат ВУЗ.

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

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

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

10 Как повысить уникальность текста?

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

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

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

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

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

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

Если у вас нет времени на бесплатные методы, воспользуйтесь «кодировкой» на сайте анти-антиплагиат.рф. Все, что вам понадобится сделать – это нажать на кнопку «повысить уникальность». Затем нужно загрузить свой документ на сервис и указать адрес электронной почты. Через пару минут готовый результат придет на ваш электронный адрес бесплатно, без предоплаты.

Когда вы откроете обработанный документ, то не увидите никаких изменений в тексте. Дело в том, что специальная программа «перекодирует» внутреннюю часть файла, повышая уникальность до 85-95%. Убедитесь в эффективности программы самостоятельно, проверив уровень антиплагиата. Только после этого мы пришлем чек на оплату.

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

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

Полезные ссылки:

Как обмануть антиплагиат – 12 бесплатных методов

Как написать курсовую работу – пошаговая инструкция

Как написать дипломную работу самостоятельно: советы

Как написать введение к дипломной работе – пример

Как начать писать дипломную или курсовую работу

Как написать теоретическую часть курсовой и диплома

Как пройти нормоконтроль дипломной работы: ГОСТ 2023

Как подготовиться к защите диплома за 24 часа

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

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

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?».  Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.  В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 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% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

Ликбез по техническому заданию

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Жутко правда? Бюджет уже потрачен и срок истек.

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

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

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

Рецепт грамотного ТЗ

Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:

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

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

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

Концептуальная модель

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

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

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

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

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

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

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

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

Путь пользователя

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

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

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

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

Пользовательский интерфейс

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

• ukraine.craigslist.org
• www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
• www.art.yale.edu

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

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

Нефункциональные требования

Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

Юлия Ходакова

Начальник управления анализа и развития банковских технологий

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

Изучить аудиторию

• Для кого пишется документ? Кто его целевая аудитория (ЦА)? — Чаще всего это бизнес-заказчики, разработчики и тестировщики.
• Какой уровень подготовки у читателей? Насколько хорошо они знают предметную область? Насколько технически подкован бизнес-заказчик? — Тут всё зависит от само́й аудитории.
• Что хочет получить целевая аудитория от документа? — Заказчики хотят увидеть, что их требования учтены и как планируется их реализовать. Разработчики и тестировщики — понять, что делать.
• Что оценивает ЦА при согласовании документа? — Разработчики оценивают в ТЗ, насколько требования понятны и реализуемы; тестировщики — полноту описания для создания тест-кейсов; заказчик — полноту фиксации бизнес-требований и их реализации.

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

Собрать вводные от заказчика

На встрече с клиентом аналитик собирает информацию:

• Какими заказчик видит цели и задачи у проекта? Кто его целевая аудитория (пользователи)?
• На что в бизнесе заказчика повлияет достижение этих целей и выполнение задач?
• Делал ли уже заказчик что-то для закрытия этих потребностей бизнеса?
• Какой он видит реализацию проекта?

Как провести встречу

• Перед встречей с заказчиком, в идеале, стоит подготовиться: посмотреть вводные по проекту — возможно, заказчик уже предоставил описание и сопутствующие документы, — поговорить с коллегами и руководителем, которые наверняка смогут дать общие вводные. И ознакомиться с предметной областью и законодательством, например, если речь о реализации новых регуляторных требований. Это поможет разговаривать с заказчиком на понятном ему языке на известную вам тему.
• Заранее сформулируйте заказчику цель встречи и постарайтесь прислать вопросы, которые хотите обсудить. Так, у него будет время подготовить ответы и дополнительно пригласить на встречу других экспертов — если такие нужны.
• На первом интервью обязательно представьтесь, объясните свою роль на проекте и цель встречи.
  Например, я, Иван Иванов, аналитик, буду разрабатывать техническое задание по вашему проекту…
• Не полагайтесь на свою память: конспектируйте и записывайте встречу на диктофон. Но вначале обязательно предупредите собеседника о записи и получите согласие на неё.
• Сперва дайте слово заказчику — чтобы он подробно объяснил, в чём суть проблемы, которую должен решить проект, и что он хочет получить в итоге. И потом уточняющими вопросами дособерите информацию.
• В ходе беседы переспрашивайте, если что-то непонятно, но не злоупотребляйте этим, несколько раз задавая вопросы об одном и том же. Если нужно, уточните, где и у кого можно получить более подробную информацию.
• Уважайте время заказчика и соблюдайте тайминг. Если необходимо, запросите повторную встречу для обсуждения оставшихся вопросов.
• Поблагодарите заказчика за уделённое вам время и конструктивную беседу, зафиксируйте договорённости о коммуникациях и принципиальные вводные протоколом встречи.
• Не все заказчики одинаковы. Кто-то представляет себе, как должен быть реализован проект и готов в деталях рассказать о нём, кто-то может только сформулировать саму проблему. В любом случае сформулируйте один или несколько вариантов реализации и вернитесь к заказчику — чтобы тот выбрал вариант, который и пойдёт в работу.

«Дизайн на салфетке»

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

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

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

Как написать ТЗ для разработчика и заказчика

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

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

Если же продукта ещё нет, то он пишет для разработчика и тестировщика полное ТЗ на информационную систему, в котором описывает:

• общую информацию о ИС;
• предполагаемый технологический стек, на котором будет реализована система или ссылку на архитектурное решение, где это определяется;
• описание выполняемых бизнес-процессов;
• описание интерфейсов (пользовательских и интеграционных) и алгоритмов обработки объектов/данных, используемые справочники и формы отчётов;
• роли пользователей и доступные им функции, статусные модели объектов учёта.

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

Принцип 1. Структурированность информации

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

Структуру ТЗ на можно разделить на 2 части:

• организационную;
• основную (тело ТЗ).

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

В организационную часть входят:

• Титульный лист — наименование компании, кем утверждается документ (опционально), наименование документа, год создания документа.
• Оглавление — маршрутизация по документу. В Word есть удобный функционал для вставки и обновления Оглавления, используйте его.
• История изменений — нужный раздел ТЗ, который покажет разработчику и заказчику историю внесения изменений в документ. Например:

или

• Глоссарий — список сокращений и профессиональных терминов, которые используются в компании и документе — с пояснениями или ссылками на определения.

К основной части обычно относят:

• блок общей информации о ИС;
• детальное описание функциональных требований;
• нефункциональные требования.

Принцип 2. От общего к частному

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

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

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

Как работает принцип «от общего к частному» покажу на примере расширенной структуры ТЗ.

В Блоке общей информации о ИС описывается:

• общая информация (цель создания ИС, её основное назначение и процессы какой предметной области должны быть реализованы в ИС);
• предполагаемый технологический стек, на котором будет реализована система или ссылка на архитектурное решение, где это определяется;
• перечисление выполняемых в ИС процессов/крупных функций;
• перечисление функциональных модулей ИС;
• интеграция  — принципы интеграции; дополнительно опционально можно перечислить ИС, с которыми требуется интеграция.

Информация в данном блоке излагается крупно, ёмко, без деталей. Разделите Блок на подразделы. Как правило, Блок общей информации занимает в ТЗ не более 1,5–2 страниц.

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

Это самый объёмный раздел ТЗ. По сути, его структура уже заложена списками бизнес-процессов/крупных функций и функциональных модулей, но теперь она расширяется и детализируется:

• Справочники — здесь описываются принципы использования справочников и списков, даётся список, справочников используемых в ИС. На этом уровне их можно разделить на группы: например, внутренние (ведётся в ИС, импортируется) и внешние. Описание каждого справочника, кроме наименования включает в себя: наименования атрибутов, коды атрибутов, их связь с другими справочниками.
• Роли — описываются ролевая модель: роли, функционал, кем и как администрируется.
• Функциональные модули — описываются принципы функционирования по каждому модулю из перечисленных в разделе «Блок общей информации —> Функциональные модули».
• Принципы построения интерфейсов ИС — описываются главное меню, если оно используется в системе. Также можно описать стандартные элементы экранных форм ввода и поиска.
• Список электронных сообщений, которыми система обменивается с другими системами. Раздел опциональный, информацию удобно оформлять в таблице — с явным указанием признака «входящее сообщение/исходящее сообщение».
• Реализуемые процессы — описываются алгоритмы выполнения каждого процесса в ИС из перечисленных в разделе «Блок общей информации —> Процессы». Описание процессов лучше всего располагать в логической последовательности.

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

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

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

Минимальное описание ЭФ включает

• Наименование поля на ЭФ.
• Тип и длина данных (на ЭФ и в базе данных, если отличаются).
• Обязательность (используют три варианта: О — обязательное, Н — необязательное, УО — условно/обязательное). Для УО в обязательном порядке прописать условие, при котором поле становится обязательным.
• Способ заполнения поля:
  • ручное, автоматическое;
  • выбор из выпадающего списка — перечисляем значения списка или даём гиперссылку на описание;
  • выбор из справочника — даём гиперссылку на описание;
  • чекбокс — описываем значения чекбокса;
• Проверки — описываются бизнес- и автоматические проверки поля.
• Маппинг на физическую модель данных (при необходимости).

Описание экранных форм (ЭФ) удобно давать в табличной форме.

Требования к печатным формам должны содержать

• шаблон печатной формы (со статической частью и динамической частью с маппингом на данные);
• алгоритм и режим формирования отчёта.

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

Нефункциональные требования

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

Принцип 3. Убрать информационный шум

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

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

• В ТЗ не должно быть несогласованных предложений, бесконечных причастных и деепричастных оборотов, лексических и орфографических ошибок. Перечитывайте написанное перед отправкой документа на согласование. Хорошо, если дополнительно это будут делать коллеги, у которых не замылен глаз.
• Единое форматирование текста в документе и его приложениях обязательно. Разные шрифты, внезапный капслок или курсив, разные отступы и выравнивание абзацев, необоснованное цветовое выделение текста, отсутствие единого оформления заголовков и таблиц — всё это создаёт сильный информационный шум.
• Технические правки в документе, визуализируемые редактором в режиме рецензирования (например, форматирование, обновление ссылок или нумерации), нужно принимать перед отправкой на согласование документа.
• Описания однотипных объектов (например, справочников, ЭФ и ПФ) должны быть одинаковыми по форме и по составу данных. Массивные описания ЭФ и ПФ могут стать информационным шумом для описания реализуемого процесса. Решение одно — группируем и выносим в отдельный раздел или приложение.

Дополнительные артефакты ТЗ

Если разрабатываемая система будет обеспечивать выполнение STP-процессов с использованием электронного документооборота с внешними контрагентами удобно приложить DocFlow обмена электронными сообщениями:

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

В некоторых ТЗ рисуют user story. Это помогает описать клиентский путь, адекватно спроектировать действия пользователя в системе и сделать user friendly интерфейс. С user story проще согласовывать ТЗ с заказчиком и делать тест-кейсы.

Полезно будет привести для разработчика в ТЗ диаграммы статусов пользователя и/или объекта учёта:

Что ещё важно

• ТЗ должно быть полным, нельзя пропустить раздел, потому что «тут и так всё понятно».
• Язык должен быть простым — насколько это возможно. «Хардовой» профессиональной лексики — немного, а все термины — объясняться в глоссарии. Помним, что уровень экспертизы потребителей документа может быть разным.
• В предложениях не должно быть двусмысленности, иначе появятся избыточные вопросы и замечания на этапе согласования. И велик риск, что разработчик реализует по ТЗ «как понял», а тестировщик «протестирует не то и не так».

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