Кто делает техническое задание. Место ТЗ в структуре проектирования
Разработка технического задания - основа создаваемой автоматизированной системы. На какой же стадии внедрения СЭД следует создавать этот документ и что нужно в него включать? Ответы на эти основополагающие и многие другие важные вопросы, связанные с разработкой технического задания, читайте в настоящей статье.
|
Техническое задание (далее - ТЗ) - это результат анализа процессов организации и концептуальных предложений по автоматизации этих процессов. До начала создания ТЗ необходимо провести информационное обследование процессов, оформляемое в виде отчета об обследовании, и разработать концепцию автоматизации, которая содержит саму идею автоматизации и раскрывает цели автоматизации, а также дает основные предложения по архитектуре и составу системы. При этом отчет об информационных процессах и концепция должны быть составлены в двух парадигмах: «как есть» и «как должно быть». Очень полезным дополнением к этим отчетам будет графическое отображение процессов (так называемое моделирование процессов) в любой выбранной методологии. Самыми распространенными методологиями на сегодня в российской практике являются нотации ARIS * с одноименным инструментарием и UML **. Разработка СЭД - это всегда проектная деятельность, у которой есть начало и конец. Разработка заканчивается передачей системы в промышленную эксплуатацию и началом процесса сопровождения СЭД. |
Перед руководителями проектов по разработке СЭД всегда стоит выбор, какой методикой руководствоваться при создании системы: каскадной моделью или итерационной.
1. Каскадная модель.
Каскадная, или классическая модель разработки (англ. waterfall model - модель водопада) - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
В каскадной модели стадии создания СЭД идут одна за другой, результаты одной стадии перерастают в результаты следующей. При этой модели возврат на предыдущую стадию достаточно проблематичен и требует переработки и переосмысления многих постулатов проекта. Именно по этой методологии построены российские ГОСТы.
2. Итерационная модель.
Итеративный подход (англ. iteration - повторение) - выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. При этом разработка в каждой фазе развития проходит повторяющийся цикл: планирование - реализация - проверка - оценка.
Итерационная модель разработки - это постепенная разработка на каждой стадии, на которой происходит полный процесс создания СЭД, но в ограниченном объеме функционала. Процесс разработки состоит из таких итераций с постоянным наращиванием функционала.
Какой из этих подходов правильный - зависит от конкретного проекта (объема задач проекта) и от пожеланий заказчика.
Тем не менее, независимо от выбранной модели разработки, в каждой из них есть стадия формирования требований к создаваемой СЭД. Эта стадия и правила создания самого ТЗ описаны в российском законодательстве, а именно в ГОСТах 34-й серии. Основные документы - ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы и РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
При итерационном подходе при первом формировании требований создается ТЗ, а при последующих уточнениях требований разрабатываются частные технические задания (ЧТЗ) .
Состав технического задания
Согласно ГОСТ 34.602-89, основными разделами ТЗ являются:
1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.
Все эти разделы могут быть разбиты на подразделы и могут включать приложения, которые приводятся в конце документа и оформляются как приложения к ТЗ. Такой же состав имеет и ЧТЗ, которое может создаваться при итерационном подходе в больших проектах для уточнения требований. ТЗ на СЭД должно оформляться на листах формата А4 по ГОСТ 2.301-68* без рамки, основной надписи и дополнительных граф к ней.
Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на СЭД.
Титульный лист ТЗ содержит следующие реквизиты:
Гриф «Утверждаю»;
Полное наименование СЭД;
Наименование документа (в нашем случае - «Техническое задание» и «Частное техническое задание»);
Код документа;
Количество листов;
Место составления документа.
Также на титульном листе могут проставляться согласующие визы, либо они выносятся на отдельный лист согласования. Следующим после титульного листа идет лист с информацией о разработчиках документа - авторах, составивших текст документа или принявших технические решения, описанные в ТЗ. Лист согласования и информация о разработчиках документа могут оформляться на одном листе ТЗ - последнем, согласно рекомендациям ГОСТ 34.602-89 (Приложение 3 к ГОСТу).
Код ТЗ на СЭД - это обозначение конструкторского документа, которое присваивается заказчиком или разработчиком документа согласно ГОСТ 2.201-80**. Код состоит из следующих частей: первые 4 символа - код организации-разработчика, следующие 6 символов - код классификационной характеристики, следующие 3 цифры - порядковый регистрационный номер. Например, номер ТЗ может выглядеть так:
ЦНТП. 425180.048.
Особенности написания некоторых разделов ТЗ
Раздел «Общие сведения » должен включать сведения о заказчике и возможном исполнителе работ, о способе определения исполнителя, бюджете, из которого финансируется создание СЭД, и примерных сроках и этапах проведения работ по созданию СЭД.
Например, в этом разделе может быть указано, что исполнитель определяется путем заключения государственного контракта.
Раздел «Назначение и цели создания (развития) системы » должен содержать описание основной цели создания системы и результатов, которые заказчик предполагает получить от внедрения системы. Эти результаты должны быть экономически измеримы или могут быть указаны способы их измерения.
Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании.
Раздел «Характеристика объектов автоматизации » содержит описание процессов в организации, требующих автоматизации, и является итогом отчета об информационном обследовании, который составляется при обследовании процессов организации.
Раздел «Требования к системе » является основным разделом ТЗ. Этому разделу следует уделить особое внимание, т. к. именно он регламентирует и закрепляет множество технических особенностей будущей системы.
В данном разделе должны быть описаны следующие требования:
1. Требования к системе в целом, включая требования к архитектуре системы, составу рабочих мест, требования к персоналу системы, требования к надежности, требования к эргономике, требования к обеспечению режима секретности (если конфиденциальные документы обрабатываются в системе), требования к защите информации от несанкционированного доступа, требования к масштабированию системы и другие.
2. Требования к функциям (задачам), выполняемым системой, должны содержать описание функционала подсистем (модулей) СЭД.
3. Требования к взаимодействию подсистем (модулей) СЭД должны описывать механизмы взаимодействия подсистем (модулей).
4. Требования к взаимосвязи со смежными системами организации должны описывать, какие системы являются смежными и как они могут быть связаны с СЭД.
Например, система кадрового учета может предоставлять списки пользователей для СЭД. 5. Требования к режиму функционирования СЭД должны содержать описание режима функционирования (например, 24 часа 7 дней в неделю) и порядок проведения профилактических работ по переустановке системы или по ее обновлению.
Например, обновление системы должно проводиться без остановки функционирования системы.
6. Требования к видам обеспечения должны содержать: лингвистическое обеспечение системы, требования к входным и выходным формам СЭД, требования к базам данных, требования к организационному обеспечению, требования к информационному, программному и техническому обеспечению системы.
7. Требования к администрированию системы с описанием ролей и обязанностей администраторов системы.
Раздел «Состав и содержание работ по созданию системы» целесообразно делать в виде таблицы с указанием наименования этапов работ по созданию СЭД, примерных сроков начала и окончания этапов, а также результатов окончания этих этапов.
Раздел «Порядок контроля и приемки системы» должен определять, какие виды испытаний необходимо провести для приемки системы, включая перечень документации, требуемой для проведения этих испытаний.
Например, для ввода системы в действие могут быть проведены ведомственные испытания согласно разработанной и утвержденной заказчиком программе и методике испытаний.
Раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие » описывает перечень мероприятий по обучению пользователей СЭД, по разработке пособий и методических материалов, требования к проведению конвертации данных или вводу первоначальных данных в СЭД, требования к созданию инфраструктуры для функционирования СЭД.
Раздел «Требования к документированию» описывает общие правила составления рабочей документации к системе и может ссылаться на корпоративные стандарты или ГОСТы.
Раздел «Источники разработки » является заключительным и перечисляет документы, которые послужили основой для разработки системы и принятия тех или иных технических решений.
При этом в тексте ТЗ должны быть проставлены ссылки на все источники разработки. Указание того или иного источника должно быть обоснованным и подтверждаться в тексте ТЗ.
Надеемся, что после прочтения данной статьи вы подробнее познакомились с нормативной базой ТЗ, его составом и содержанием и теперь готовы к работе с этим документом.
* ARIS (англ. Architecture of Integrated Information Systems) – принадлежащие компании Software AG методология и тиражируемый программный продукт
для моделирования бизнес-процессов организаций.
** UML (англ. Unifi ed Modeling Language) – язык графического описания для объектного моделирования в области разработки программного обеспечения; был создан для определения, визуализации, проектирования и документирования в основном программных систем.
Определение содержания проекта, разработка ТЗ
В данном разделе кратко рассмотрен вопрос разработки технического задания (далее ТЗ) . Вначале дано определение ТЗ, описаны преимущества ТЗ как для заказчика, так и для исполнителя, перечислены основные функции ТЗ. Далее рассмотрено, в чем же сущность ТЗ, раскрыты структура и содержание ТЗ, а также приведены примеры структуры ТЗ. В заключение, отмечены особенности ТЗ инновационных проектов.
Поскольку задачи разработки ТЗ инновационного проекта, имея свои особенности, в принципе остаются такими же, как при разработке любого ТЗ, то вначале рассмотрен вопрос разработки ТЗ в целом.
Определение
Следует отметить, что на данный момент времени нет стандартизированного определения технического задания (ТЗ) инновационного проекта. В актуальной базе национальных стандартов имеется три стандарта, имеющих отношение к ТЗ. Все они относятся к сфере информационных технологий:
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления.
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Например в «ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению» дано следующее определение ТЗ: «Техническое задание на автоматизированную систему - утвержденный в установленном порядке документ, определяющий цели, требования и основные исходные данные необходимые для разработки автоматизированной системы и содержащий предварительную оценку экономической эффективности».
В говорится, что ТЗ позволяет:
исполнителю - понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;
заказчику - осознать, что именно ему нужно;
обеим сторонам - представить готовый продукт;
исполнителю - спланировать выполнение проекта и работать по намеченному плану;
заказчику - требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;
исполнителю - отказаться от выполнения работ, не указанных в ТЗ;
заказчику и исполнителю - выполнить попунктную проверку готового продукта (приёмочное тестирование - проведение испытаний );
избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний ).
Таким образом, техническое задание является документом, который содержит набор требований и позволяет как разработчику, так и заказчику представить конечный продукт и впоследствии выполнить проверку на соответствие предъявленным требованиям.
Чем подробнее будет составлено ТЗ, тем меньше спорных ситуаций возникнет между заказчиком и разработчиком во время приемочных испытаний.
ТЗ выполняет четыре основных функции:
Юридическая. ТЗ является юридическим документом, и в виде приложения включается в договор между заказчиком и исполнителем.
Организационная. С помощью ТЗ можно упорядочить дальнейшую работу, превратить ее в очередь (схему) заданий и не тратить усилий на ненужные действия.
Информационная. Грамотно составленное ТЗ может быть хорошим источником информации, необходимым для выполнения проекта. Структурированность ТЗ позволяет иметь информацию, которая действительно интересует, в той форме, которая легче всего воспринимается и в том количестве, которая необходима для выполнения работы .
Коммуникативная. Подробно составленное ТЗ помогает исполнителю лучше узнать потребности заказчика и выполнить работу, отвечающую всем его вкусам. Что также способствует процессу утверждения проекта.
Сущность ТЗ
Работа над ТЗ означает, что предполагается решение какой либо задачи и оно пошагово описывается в этом документе. ТЗ может быть разработано на что угодно: на создание технологии, нового материала, устройства, сайта, программы, стандарта, выполнение мероприятия и т.п.
Конечные результаты, полученные в ходе выполнения проекта, могут выступать в вещественной (материалы, процесс, технология), организационной (норма, стандарт), научно-технической и научно-методической (конструкторская документация, научно-исследовательский отчет, образовательная программа), нематериальной (патенты, монографии, статьи) и других формах.
Сущность ТЗ состоит в успешном выполнении поставленной задачи. Чем лучше и качественнее будет составлено ТЗ, тем эффективнее будет выполнена задача. Причем, это не зависит от ее масштаба. Неправильное составление ТЗ может иметь последствия, например непредсказуемость результата, работа будет выполнена не так как надо было заказчику или вообще не будет выполнена. Заказчик работы не получит того, чего хотел и имеет право не оплачивать сделанную работу.
Работа над ТЗ - сложный и ответственный этап, так как многие данные ещё не известны. Успех выполнения проекта по мнению специалистов на 50 -70% зависит от квалифицированного выполнения этапа разработки ТЗ.
Как правило, этапу разработки ТЗ предшествует проведение исследования предметной области, расчётов и моделирования.
Ответственная работа над ТЗ позволит его разработчикам увидеть сценарий выполнения задачи. Четко понять свои сильные и слабые стороны, как бы прожить процесс выполнения задачи. Определиться с критериями, задаться показателями, характеристиками, суммами, оценить ресурсы.
ТЗ согласуется с заказчиком или разрабатывается совместно.
Несмотря на свою важность, содержание и структура ТЗ практически не регламентирован нормативными документами.
Обычно заказчик задаёт цель (как он её понимает) и ресурсные ограничения (время, деньги). Задача исполнителя, прежде всего,- перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, осмыслить и уточнить исходные данные. В содержание ТЗ должны быть включены сведения, касающиеся целей и выполнения функций, реализующих заданные потребности, которые всегда увязывается с удовлетворением определенных требований.
Работа с требованиями подлежит управлению. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разрабатываемого продукта.
При формировании системы требований необходим анализ доступности ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные, а также учет требований надзорных и лицензионных органов, например, при проектировании технологических комплексов (производств). Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Роспотребнадзора, Росприроднадзора, и др..
Ниже приведены примеры структуры ТЗ из различных источников.
Например ТЗ может содержать разделы :
предмет ТЗ;
цели проводимой работы;
требования к отчету;
порядок организации работы;
Пример из вышеупомянутого ГОСТ 19.201-78.
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
Следующий пример ТЗ на оказание консультационных услуг
общие положения;
цель работы;
квалификационные требования к кандидатам.
Пример ТЗ на выполнение научно-исследовательской работы «Разработка концепции, стратегии развития и технико-экономического обоснования создания технико-внедренческого парка в г. Перми» (далее - НИР)
задачи НИР
исходные данные
основные требования к проведению НИР
календарный план выполнения НИР
предполагаемое использование результатов выполнения НИР
порядок сдачи-приемки результатов НИР
основание для выполнения НИР
исполнитель и соисполнители
Пример структуры шаблона ТЗ на выполнение НИОКР
Основание для проведения работы
Исполнитель
Сроки проведения работ
Цель выполнения работ
Результаты НИОКР
Разрабатываемая продукция
Основные параметры, которые должны быть достигнуты в результате выполнения работы:
Основные конструктивные требования (если применимо)
Требования по видам обеспечения (если применимо)
Требования по стандартизации, унификации, совместимости с сопрягаемыми объектами и взаимозаменяемости.
Требования по обеспечению безопасности для жизни и здоровья людей и охраны окружающей среды
Требования надежности (если применимо)
Требования по безотказности и долговечности.
Требования по эргономике и технической эстетике (если применимо)
Требования к эксплуатации, удобству технического обслуживания и ремонтопригодности (если применимо)
Требования к устойчивости к внешним воздействиям (если применимо)
Требования к эксплуатационным показателям (если применимо)
Требования по сертификации
Прочие требования и специальные требования по отраслям
Требования к патентной чистоте и патентоспособности
Требования к документации
Порядок приемки работ.
Таким образом, анализируя структуру в приведенных примерах можно отметить, что структуру и содержание ТЗ диктует та задача, которую необходимо выполнить.
Особенности разработки ТЗ инновационного проекта
Инновационные проекты – мероприятия уникальные, поскольку, связанны с трансформацией научно-технических идей в новые или усовершенствованные продукты, а также в новые или усовершенствованные технологические процессы, используемые в практической деятельности, либо в новые подходы к социальным услугам. Приходиться делать то, что никогда раньше не делалось. И прошлый опыт может лишь ограниченно подсказывать, чего можно ожидать. Поэтому инновационные проекты имеют высокую степень неопределенности и риска и в этом заключается их особенность.
Разработка инновационного проекта направлена на изыскание решений для получения намеченной конечной идеи проекта и создания комплекса заданий и мероприятий, которых будут связывать воедино время, ресурсы, и исполнителей для осуществления данного инновационного проекта. Любой инновационный проект при его реализации проходит определенный путь: от фазы разработки идеи до фазы неактуальности идеи. Стадия разработки ТЗ относится к начальному этапу инновационного проекта.
В инновационном проекте при создании совершенно нового продукта трудно запланировать заранее все параметры, поэтому предлагается использовать динамическое расширенное ТЗ, которое носит в основном, описательный характер.
Первым шагом после возникновения идеи нового продукта составляется каталог требований, в который могут включатся требования клиентов, сегментирование рынка для нового продукта, нормы, стандарты, общие цели (доля рынка, затраты), время выхода на рынок, длительность жизненного цикла, общая оценка рисков.
Показатели, очерченные в каталоге требований, конкретизируются в документе, который и называют расширенным техническим заданием.
Если каталог требований составляется на «языке клиентов», то расширенное ТЗ – на «языке предприятия». Расширенное ТЗ должно включать помимо традиционных пунктов (объем работ, отчетность, исходные данные, требования к параметрам и т.д.) и некоторые элементы бизнес-плана по проекту (предполагаемая политика ценообразования, планируемая доля рынка, планируемые обороты и т.д.).
Поскольку каталог требований создается, исходя из точки зрения клиента, язык для написания каталога требований выбирается также понятным клиенту (без специфических технических подробностей). В каталоге требований отражаются предложения предприятия в ответ на потребности клиентов.
В состав расширенного ТЗ могут включаются:
1. Описание проекта
2. Рыночные и экономические цели проекта
3. Временные параметры
4. Технические параметры
5. Производственные параметры
8. Требования к дизайну и эргономике
9. Нормы и предписания
Таким образом, основная задача составления расширенного ТЗ – в сборе наиболее полной информации о разрабатываемом продукте, от которой отталкиваются при планировании .
Информация расширенного ТЗ далее конкретизируется в плане структуры продукта, представляющего собой перечень всех компонентов, из которых будет состоять результат проекта. План структуры результата проекта содержит все компоненты, блоки, узлы создаваемого продукта.
Важнейшими элементами ТЗ являются: цель работы, область применения результатов, содержание работы, программа ее выполнения, технико-экономические и другие показатели, требования к работе уровню и способом ее выполнения, результаты работы, научная, научно-техническая и практическая ценность ожидаемых результатов; предполагаемое использование результатов и вид, форма представления отчетных материалов.
Рассмотрим местоТЗ в структуреинновационного процесса в организации (внедрение инноваций в организации) согласно .
Первоначально разрабатывается концепция инноваций. Которой предшествует этап исследований (обследование организации, выбор показателей эффективности её предстоящей инновационной деятельности, обоснование перечня мероприятий, необходимых для реализации инноваций). Концепция инноваций сформированной командой разработчиков разворачивается в задание (ТЗ) на разработку инновационного проекта, в котором должны содержаться все обоснования, исходные установки и параметры, необходимые для последующего проектирования.
Исходя из задания на разработку инновационного проекта, далее выстраивается подробный план мероприятий по разработке и решению отдельных задач, а также по контролю за их исполнением (контрольные точки по срокам, перечень контролируемых параметров, критерии контроля и т.п.). По сути говоря техническое задание, план мероприятия являются основанием для разработки инновационного проекта.
Содержанием проекта являются описание и регламенты плановых мероприятий, расчёты оптимальности расходования ресурсов, оценка предполагаемых результатов реализации, доведённых до количественных значений. Основой инновационного проекта являются его организационная и финансовая части. Далее следуют этапы адаптации и реализации проекта и анализ результатов проекта.
Когда ТЗ как документ утвержден, осуществляется планирование работ по проекту.
| Техническое задание на разработку программы «______________» к Договору №___ 1. Введение 1. Введение 1.1. Наименование программы Наименование программы: «АСУ «______________»» 1.2. Назначение и область применения Программа предназначена для автоматизации обработки данных клиентов кафе/бара. Она оперирует следующими данными:
2.1. Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
2.2.1 Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой. 3.1. Требования к квалификации и численности персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 1 штатной единицы - оператор ПК. В перечень задач, выполняемых оператором ПК, должны входить:
3.2. Требования к составу и параметрам технических средств
3.3.1. Требования к информационным структурам и методам решения Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO.Пользователи работают с базой данных через системный интерфейс. 3.3.3. Требования к исходным кодам и языкам программирования Дополнительные требования не предъявляются. Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP. Требования к защите информации и программ не предъявляются. 3.5. Специальные требования Специальные требования не предъявляются. 4.1. Предварительный состав программной документации Состав программной документации должен включать в себя:
5.1. Экономические преимущества разработки Программа является бесплатным продуктом, финансовые средства не затрачиваются, и преимуществом является ускорение автоматизации обработки данных клиентов кафе/бара 6.1. Стадии разработки Разработка должна быть проведена в три стадии:
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы. На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. 7.1. Виды испытаний:
7.2. Требования к приемке работы При приёмке необходимо проверить соблюдение следующих условий:
|
| Техническое задание на разработку дизайн проекта помещения. Информация | Техническое задание на разработку проектной документации для строительства зоопарка Положения В границах земельного участка ул. Подлесная, шоссе Космонавтов, ул. Малкова, Дзержинского района г. Перми |
||
| Техническое задание на разработку интернет-сайта структура документа Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного… |
Техническое задание на разработку веб-сайта «Объединение Российских Художников Аэрографии» Основной html контейнер, в который вставляются информационные блоки, должен быть полностью доступен для редактирования. Желательно… |
||
| Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных» Гост 34. 602-89 Техническое задание на создание автоматизированной системы (пример) |
2. Техническое задание на разработку ис В данном курсовом проекте приведен процесс выдачи пенсионного страхового свидетельства. Разработанная система предназначена для упрощения… |
||
| Техническое задание на разработку сайта журнала Настоящее тз представляет… Сайт моделируется с учетом ограничений современных систем контент-менеджмента (открытых WordPress, Joomla, LiveStreet и им подобных… |
Программа демонстрации алгоритмов обхода графов Данное техническое задание регламентирует разработку учебного программного продукта предназначенного, для наглядного представления… |
||
| Техническое задание включает в себя: наименование разработки, основание… Технико-рабочий проект: описание предметной области (объектная модель), управление объектами (события, диаграмма взаимодействия),… |
Проектирование программных средств Этап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств |
Технические требования к системе
Технический облик изделия
Теория решения изобретательских задач — это советская методика сильного мышления, получившая широкое как в России, так и в мире. Она позволяет глубоко проанализировать проблему и найти эффективное решение.
Работа над ТРИЗ была начата Генрихом Сауловичем Альшуллером и его соратниками в 1946 году.
Разработка программы: пример технического задания
В 1956 году вышла первая публикация про то, что техника развивается по определенным законам. Чтобы эффективно изобретать, нужно эти законы выявить и эффективно применять
Со временем ТРИЗ развился в большой набор инструментов, помогающие решать ряд актуальных задать:
— создавать новые прорывные продукты,
— повышать потребительские свойства имеющихся решений,
— снижать себестоимость,
— обходить патенты конкурентов.
Ведущие мировые компании, такие как Samsung, Intel, Procter&Gambel, General Electric и другие используют ТРИЗ в своих R&D центрах.
Термины
Для исключения спорных моментов и недопонимания важно пользоваться одинаковым понятийным аппаратом. Для этого мы составили перечень наиболее часто используемых терминов и сокращений.
Когда речь заходит о разработке технической документации для программного обеспечения, чаще всего мы думаем, пожалуй, о таком документе, как Техническое задание (ТЗ). Почему так происходит?
Назначение технического задания
Во-первых, техническое задание – это, как правило, основной документ в рамках проектной документации. Именно в ТЗ описываются все основные требования на разработку программного обеспечения, будь то создание либо простенькой программы или сайта, либо же разработка крупномасштабной информационной системы или программно-аппаратного комплекса. Причем, говоря языком ГОСТов, техническое задание может разрабатываться как в рамках эскизного проекта (это когда только описание функций и структуры системы без рассмотрения технологий реализации решения), так и в дальнейшем «перекочевать» в технический проект (более детальное описание с учетом выбранных технологий).
Во-вторых, техническое задание может быть как поверхностным (например, общеконцептуальное ТЗ, предназначенное для инвесторов проекта), так и более детальным (например, подробное ТЗ для программиста). Посмотрите раздел Проекты, там как раз приведены примеры различных ТЗ. Вы можете выбрать любой уровень детализации – мы подготовим для вас ТЗ любой сложности по доступным ценам.
В-третьих, в некоторых случаях можно обойтись только подготовкой одного технического задания для описания разрабатываемой системы. Разумеется, в этом случае качество разрабатываемого ТЗ играет ключевую роль, поэтому здесь явно не стоит экономить и лучше доверить разработку такого ТЗ профессионалам, имеющим большой опыт в этом деле. Скупой платит дважды, но в случае провала разработки ПО по причине некачественной документации – вдесятеро, а иногда и еще на несколько порядков выше.
Состав типового технического задания
Давайте рассмотрим, что же включает в себя типовое ТЗ.
Техническое задание программного обеспечения оказалось поверхностным?
Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:
1) наименование
– полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение
– то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки
– документы, на основании которых производится разработка ПО;
4) функции
– перечень и описание функций разрабатываемого ПО;
5) структура
– описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс
– в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации
и проч. важные требования;
8) документация
– какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки
– что и в какой последовательности разрабатывается;
10) порядок контроля и приемка
– как именно будет происходить сдача разработанного ПО Заказчику.
Стандарты для технического задания
Существует несколько ГОСТов, регламентирующих разработку ТЗ в нашей области: это ГОСТ 34.602 (автоматизированные системы) и ГОСТ 19.201 (программное обеспечение). Документы, выполненные по этим стандартам, значительно отличаются как по наполнению, так и по содержанию. Оба стандарта представлены на нашем корпоративном портале в разделе Библиотека, вы можете самостоятельно ознакомиться с ними более подробно.
Стоимость разработки технического задания
В целом, составление ТЗ – это достаточно сложная и ответственная задача, но грамотно составленное техническое задание – это уже половина успеха разрабатываемого проекта. Поэтому в процессе разработки ТЗ на ПО вы должны проявить максимальную внимательность и осведомленность в технических и организационных вопросах. Либо можете заказать у нас разработку технического задания «под ключ» прямо сейчас.
Возможно, вас также заинтересует:
– разработка программы и методики испытаний;
– создание пояснительной записки к эскизному и техническому проекту;
– этапы разработки документации.
Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов. В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
Class="fs-13">
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
class="fs-13">
7. Система размещения баннеров
8.
Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
class="fs-13">
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.
Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
class="fs-13">
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта.
Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест).После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Прототипы, уже на стадии разработки, дают заказчику понять, как именно будет выглядеть интерфейс системы.
Требования должны быть написаны «живым человеческим» языком , понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.
Опыт в предметной области
Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.
Поиск Лекций
Техническое задание на объект
При проектировании технического объекта важное место занимает разработка технической и технологической документации: техническое задание (ТЗ) и технические условия (ТУ).
Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.
В качестве технического задания допускается также использовать любой документ (контракт, протокол, эскиз, образец продукции и др.), содержащий необходимые и достаточные требования для разработки и признанный заказчиком и разработчиком.
Утвержденное техническое задание является документом, которым разработчики должны руководствоваться на всех этапах создания системы и проектирования задач. Изменения, вносимые в техническое задание, должны оформляться протоколом, являющимся частью технического задания. Протокол должен утверждаться заказчиком.
При разработке технического задания следует:
· установить общую цель создания технической системы;
· установить общие требования к проектируемой системе;
· определить этапы создания системы и сроки их выполнения;
· провести предварительный расчет затрат на создание системы.
Техническое задание должно содержать следующие разделы:
1) наименование и область применения;
2) код изделия;
3) основания для разработки;
4) цель и технико-экономическое обоснование;
5) источники для разработки;
6) этапы разработки и запуска производства;
7) технические требования.
В зависимости от назначения разрабатываемых средств измерений, условий их изготовления и эксплуатации допускается изменять структуру технического задания, объединяя отдельные разделы и вводя новые.
В разделе Основание для разработки указывают наименование документа (документов), которым предусмотрена данная разработка, организацию, утвердившую этот документ, и дату его утверждения, наименование и шифр темы разработки.
Основанием для разработки является маркетинговые исследования и выход нового стандарта.
В разделе «Цель и технико-экономическое обоснование разработки» указывают:
1. Конкретное функциональное назначение объекта – для снижения токсичности автомобиля.
Техническое задание на разработку программы
Наличие отечественных и зарубежных аналогов и возможность или целесообразность их применения по данному назначению – на рынке присутствуют зарубежные аналоги, но их стоимость и отечественные аналоги.
3. Предполагаемую потребность в данных объектах у потребителей – данный объект необходим потребителю для соблюдения норм стандарта и сохранения здоровья людей и окружающей среды.
В разделе «Источники разработки» приводят перечень научно-исследовательских и других работ, результаты которых используют в данной разработке, а также перечень образцов или макетов, на базе которых выполняют разработку.
В разделе «Этапы разработки» указывают необходимые этапы работ и ориентировочные сроки их выполнения, состав и ориентировочные сроки представления конструкторской технологической документации на метрологическую экспертизу и организацию, которая ее проводит.
Основываясь на этапы жизненного цикла продукции разрабатываем этапы разработки и запуска в производство.
Основные этапы разработки: маркетинговые исследование; разработка ТЗ; — проектирование объекта; испытание; подготовка производства; запуск в производство.
На первой стадии проектирования производится выбор (или разработка) принципиальной схемы объекта. С этой целью на основании справочных данных, рекомендаций и стандартов формируется ряд вариантов объектов – аналогов, в той или иной степени отвечающих требованиям ТЗ. Далее в случае необходимости производится доработка принципиальных схем объектов – аналогов. Если варианты объектов – аналогов не найдены, переходят к процедуре синтеза вариантов объектов, еще не встречавшиеся в практике машиностроения. При это, как уже отмечалось, максимально используются стандартные элементы и узлы.
Следующая стадия проектирования – конструктивное оформление основных элементов и построение математических моделей функционирования приспособления. Последняя стадия проектирования- окончательное конструкторское оформление принятых решений, выполнение чертежей и текстовой части в соответствии с требованиями ЕСКД .
После успешных испытаний, для заказчика проекта, на основе требований технического задания и стандартов, касающихся данного вида продукции, с учетом результатов испытаний разрабатывается техническое условие на приспособление, которое включает в себя:
1.Технические требования
2. Требования безопасности
3. Требования охраны окружающей среды
4. Правила приемки
5. Методы контроля
6. Транспортирование и хранение
7. Указание по эксплуатации
8. Гарантии изготовителя
9. Утилизация
На основе разработанных документов можно приступать к непосредственному проектированию объекта.
В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.
Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста. Однако не каждый пользователь способен изложить свои мысли грамотно и доходчиво.
Приведу несколько советов для написания корректного задания пользователем, по которому можно работать и которое ложится в основу отношения между заказчиком решения и специалистом.
1. Прежде, чем составлять техническое задание, пользователь должен понять, что именно он хочет получить . Следует определить цель задания, ключевые особенности желаемого результата, нарисовать (написать, создать таблицу) для себя желаемый выход работы.
2. Собрать документацию , согласно которой вы выполняете работу, для которой необходимо приложение (программа). Прочитать ее внимательно, с карандашом, отмечая особенности и тонкости.
3. Следует понять, какие параметры следует задавать на входе , какова периодичность работы с желаемой программой (отчетом, приложением, утилитой), сколько данных примерно будет получаться на выходе и все ли они нужны (к примеру, если вам нужна сумма выручки от продаж пяти категорий изделий по категориям без наименований, не стоит требовать создания отчета в миллион строк с указанием каждой продажи с детальными характеристиками). Далеко не каждому специалисту необходима максимально детализированная информация, обработка которой создает значительную нагрузку для вычислительных систем.
4. Подробно описать необходимую информацию , указать ее особенности, исключения, необходимый уровень детализации. Следует продумать все мелочи: формат чисел, округление, доли, ставки и проч.
6. Обсудить написанное задание с непосредственным исполнителем , попытаться разрешить все вопросы, внимательно прислушиваясь к мнению собеседника. Не стоит забывать, что вы свою сферу деятельности знаете лучше и только вы можете точно объяснить, какой инструмент вам необходим для эффективно работы. IT-специалист знает свое дело и не обязан знать нюансы работы каждого отдела в организации.
7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.
8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.
9. Помните, что ваше задание будет служить справочником для вас - в нем всегда можно посмотреть описание информации, вспомнить забытое требование.
Конечно, только лишь умение писать техническое задание не избавит от всех проблем, но оно позволит отношениям с IT-отделом перейти в серьезную плоскость сотрудничества, позволит пользователю повысить свою техническую грамотность и получить требуемое, а специалиста по IT избавит от ряда проблем и ненужных вопросов.
Техническое задание важно и исполнителю, и клиенту. Исполнителю оно помогает лучше понять, что хочет заказчик, застраховаться от внезапных «хотелок» со стороны клиента, ускорить работу по выполнению задачи. Клиенту - рассказать точно о том, что он хочет, упростить контроль качества, получить точную стоимость услуги. Мы расскажем о том, как правильно составить ТЗ и что с ним потом делать.
Что такое техническое задание
Техническое задание - документ, в котором отражены все требования к будущему продукту. В нем описывают все технические требования. Обычно ТЗ составляют в виде текстового документа, редко - в других форматах.
ТЗ используют все разработчики сайтов. Верстальщикам, программистам, дизайнерам оно помогает лучше понять требования клиента и сделать ресурс, соответствующий его ожиданиям. Кроме того, ТЗ используют во всех других сферах, например - в:
- разработке приложений;
- проектировании дома;
- написании текстов и другие.
Если вы работаете по техническому заданию, риск споров и затяжных тяжб сведен к минимуму.
Как составить техническое задание: структура ТЗ на сайт
Прежде чем приступать к работе:
- Определитесь, кто будет составлять техническое задание
- Разъясните термины
- Откажитесь от субъективных терминов
На первый взгляд кажется, что ТЗ на сайт должен составлять клиент , потому что он заказывает ресурс и выдвигает требования к нему. На самом деле в процессе должны участвовать оба: клиент озвучивает требования, а исполнитель записывает их конкретно, точно и понятно. Например, клиент говорит, что хочет сайт, адаптированный под всех пользователей, а разработчик прописывает требования к адаптивности под 4 доступных размера - ПК, ноутбуки, планшеты, смартфоны.
Разъяснение терминов - очень важный момент . Все узкоспециализированные термины желательно объяснить в самом начале - клиенты не всегда знают, что такое подвал (футер), CMS, рыба. Чем проще и понятнее будут объяснения, тем понятнее будет ТЗ для обеих сторон.
Субъективные термины могут вызвать ненужные споры . Не пишите «дизайн должен быть красивым» - понятие красоты у всех разное. То же относится к качественным прилагательным «удобный», «легкий в использовании», «большой». Используйте конкретные цифры и параметры: например, опишите цветовую гамму или расположение элементов.
Структура технического задания может быть любой. В качестве примера мы предлагаем простую структуру ТЗ на сайт.
Опишите сайт
Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.
Если у проекта есть конкретная целевая аудитория, опишите ее. Это поможет создать ресурс, который понравится клиентам - например, использовать подходящие выражения в статьях или дизайн, который нравится молодежи или представителям старшего поколения.
Расскажите о структуре
Без представления о структуре невозможно разработать нормальный сайт. Распишите, какие страницы будут на сайте, и покажите уровни их вложенности. Сделать это можно разными способами:
- Схемой
- Таблицей
- Списком
Главное, чтобы в итоге было понятно, какие страницы будут располагаться в меню, куда они будут вести, какая родительская страница у каждого раздела. Мы рекомендуем использовать блок-схемы - они проще и удобнее в восприятии, чем списки и таблицы, помогают за несколько секунд оценить всю структуру сайта.
Пример простейшей структуры в виде блок-схемы
Опишите, что будет на каждой из страниц
Расскажите, какими видите страницы сайта. Делать это желательно в формате прототипа, чтобы наглядно продемонстрировать расположение каждого элемента. Можно описать требования и списком, например - рассказать, что будет в шапке сайта, где расположена форма обратной связи, что будет в свободной боковой колонке.
Если все страницы сайта примерно схожи - например, вы планируете создать сайт-визитку, можно обойтись двумя прототипами: для главной страницы и остальных разделов. Если есть несколько групп схожих страниц - например, разделы в каталоге интернет-магазина, блог со статьями и описание услуг по доставке/сборке/установке, лучше сделать свой прототип для каждой группы.
Пример прототипа главной страницы сайта: все просто, удобно, понятно
Выдвините требования к дизайну
Если есть разработанный макет, отлично - можно просто вставить его в техзадание. Если нет - нужно расписать требования к цветовой гамме, используемым изображениям, логотипам. Например:
- Укажите, какие корпоративные цвета можно использовать в дизайне, а какие оттенки - категорически нет
- Предоставьте логотип, который обязательно должен присутствовать в шапке сайта
- Укажите шрифты, которые желательно использовать для оформления страниц, меню, футера, контента
Если четких требований нет - то есть клиент сам не может сформулировать свое видение сайта, можно предложить ему несколько типовых макетов на выбор или разработать макет индивидуально, а затем - согласовать. Делать это нужно до утверждения ТЗ, иначе разница во вкусах может существенно затянуть проект.
Опишите требования к инструментам, коду, хостингу, домену
Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:
- На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
- Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
- На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
- Какую программную платформу можно использовать - .NET, OpenGL, DirectX
- И так далее
Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.
Уточните требования к работе сайта
По умолчанию сайт должен работать у пользователей всех устройств, в разных браузерах, выдерживать хакерские атаки и не ложиться при одновременном посещении 1000 пользователями. Но лучше прописать это отдельным блоком. Укажите:
- Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
- Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
- Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
- Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
- Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки
Распишите сценарии работы сайта
Опишите, как пользователь должен взаимодействовать с сайтом, и какие действия на ресурсе должны происходить в ответ. Сделать это можно в форме простого нумерованного списка либо разветвленным алгоритмом, если у пользователей будет выбор между действиями. Если интерактивных сервисов много, распишите сценарий для каждого из них.
Пример простейшего сценария работы сайта
Уточните, кто занимается контентом.
Какие-то разработчики сами пишут тексты, кто-то заказывает их у копирайтеров, кто-то использует рыбу. Сразу уточните, входит ли предоставление контента в услугу разработки. Если да, можно сразу прописать дополнительные требования, например, к:
- - не меньше 95% по Адвего, Текст.ру, Контент.Вотч
- Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
- Баллам по Главреду - не менее 6,5 или 7 баллов
Конечно, разные сервисы - не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.
Укажите сроки
Об этом часто забывают. В большинстве технических заданий должны быть прописаны сроки, иначе разработка может затянуться на несколько месяцев, полугодий, лет. Не используйте некорректные формулировки - например, «через месяц». Пишите точную дату: 1 декабря 2018 года, например.
Лайфхак: техническое задание лучше оформлять как приложение к договору о сотрудничестве. Так вы закрепляете все требования к разработке сайта, и в случае споров сможете выиграть дело в суде.
Запомните: в каждом ТЗ должны быть несколько основных блоков:
- Цели и задачи - о том, для чего вообще вы создали ТЗ, что хотите сделать с продуктом
- Каким должен быть продукт - описание в общих чертах
- Технические требования - площадь дома, объем текста, функционал приложения и так далее
- Сроки - они важны, чтобы исключить споры.
Пример составления ТЗ на программное обеспечение
Нужно создать ПО. Технические требования - ниже.
Описание : программа для поиска статей по ключевому слову на всех авторитетных сайтах, адреса авторитетных сайтов прописывать нужно вручную.
Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:
- Линк
- Название статьи
- Лид-абзац
Если больше 10 совпадений, нужно разделить на страницы - по 10 на каждой.
Технические требования: язык программирования - любой, не принципиально. Главное, чтобы программу потом можно было доработать и вывести в качестве онлайн-сервиса. В идеале сервис должен искать за 10 секунд.
Сроки : до 15.09.2018.
Естественно, это ТЗ можно улучшить - мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?