Что такое частное техническое задание
Частные технические задания
Понятие ТЗ
Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.).
В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.
Слово «проект» в области деятельности «управление проектами» и «управление проектированием» применяется в значении «программа», «план действий», «комплекс работ».
Участников проектных работ разделяют на потребителей (заказчиков этих работ) и поставщиков (исполнителей этих работ, подрядчиков). Исполнителя-специалиста называют проектировщиком или разработчиком. Поставщиком, как и потребителем продукции, может быть организация (юридическое лицо) или конкретный человек (физическое лицо).
Объектом проектирования может быть материальное устройство, или выполнение работы, или оказание услуги, например, сооружение или промышленный комплекс, техническое устройство (прибор, машина, аппарат), система управления,информационная система
, нормативная документация (например, стандарт) и т. д.
Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков.
Место ТЗ в структуре проектирования
Проектирование— это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
Стадии проектирования регламентированы стандартами. Это следующая последовательность:
· Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
· Стадии рабочего проекта.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования, которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, это и есть главная цель ТЗ, обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком. Фактически это означает, что работа исполнителя над проектом уже началась.
В машиностроении этот этап иногда называют внешним проектированием.
Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Частные технические задания
В процессе проектирования сложного объекта (системы), требующего участия нескольких разработчиков, создаются частные технические задания на подсистемы.
В соответствии с полученными техническими требованиями разработчик системы формирует ТЗ и на стадии технического предложения выполняет декомпозицию объекта и подготавливает частные технические задания на подсистемы. После выполнения всех этапов технического предложения разработчик согласовывает и утверждает его у заказчика системы, при этом они совместно уточняют исходное ТЗ.
После утверждения технического предложения разработчик системы распределяет по соисполнителям частные ТЗ, на основании которых могут вырабатываться частные ТЗ для подсистем более низких уровней. Если подсистемы второго уровня отсутствуют, то техническое предложение для подсистем часто не выполняется, поскольку практически было завершено на уровне системы.
По завершении этапа распределения ТЗ разработчики системы и её подсистем приступают к выполнению стадии эскизного проекта. Проработка структуры на этой стадии ведется при тесном взаимодействии всех разработчиков. В процессе такой работы увязываются между собой отдельные части, согласовываются основные параметры проектируемого объекта. Качество проектирования зависит от широты видения разработчиком проблемы, то есть от его кругозора и способности учесть все связи рассматриваемого объекта, и наличия у него знаний, захватывающих смежные области. В процессе эскизного проектирования и согласования частных решений с общим возможна корректировка ТЗ.
После завершения эскизного проектирования, согласования и утверждения полученных технических решений у заказчика переходят к стадии технического проектирования. Здесь выполняется вся основная конструктивная проработка объекта и его частей. Возможно уточнение технических решений с возвратом на предыдущие стадии. Техническое проектирование ведется при тесном взаимодействии всех разработчиков.
Необходимость ТЗ
Исходное задание выдаётся заказчиком. Основными причинами, заставляющими его обратиться к разработчику, являются отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования).
Задание может быть чётко определено, например, когда всю работу ведет один человек, либо оно выдано авторитетным специалистом, либо не может быть подвергнуто сомнению (госзаказ). Но чаще оно формулируется в общих чертах на языке потребителя-неспециалиста, далёким от языка разработчика и терминов предметной области. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разработанного изделия. Также, разработчик должен понимать, что заказчик может не знать (или знает частично) специальных требований, что не снимает с разработчика ответственности и обязательности выполнения требований надзорных органов независимо от их наличия в задании. Таким образом, не только заказчик, но и разработчик (исполнитель) являются ответственными за постановку целей разработки и полезность ее результата.
Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).
Специалисты считают, что грамотное ТЗ — это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, — одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам — главным конструкторам, руководителям проектов и работ и т. п.
Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!
Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:
· представить (вообразить) готовый продукт,
· выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
· уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
· осознать, что именно ему нужно,
· в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
· требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
· понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта илиавтоматизированной системы
· спланировать выполнение проекта и работать по намеченному плану,
· отказаться от выполнения работ, не указанных в ТЗ.
Содержание ТЗ
Регламентированное ТЗ
Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ, ОСТ).
· ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению[5] (кратко изложено содержание ТЗ);
· ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы[6] (достаточно подробно изложены состав и содержание ТЗ);
· ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления[1] (приведен порядок построения ТЗ).
В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:
· ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
· Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу[7] (приложен образец технического задания на разработку в рамках ГОЗ)
Что такое частное техническое задание
Система разработки и постановки продукции на производство
Требования к содержанию и оформлению
System of products development and launching into manufacture. Technical assignment. Requirements to contents and form of presentation
Дата введения 2017-09-01
Предисловие
Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»
Сведения о стандарте
1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)
2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии
3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)
За принятие проголосовали:
Краткое наименование страны по МК (ИСО 3166) 004-97
Сокращенное наименование национального органа по стандартизации
Минэкономики Республики Армения
4 Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. N 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.
6 ПЕРЕИЗДАНИЕ. Июль 2020 г.
Информация о введении в действие (прекращении действия) настоящего стандарта и изменений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.
В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»
1 Область применения
Настоящий стандарт устанавливает требования к построению, содержанию, изложению, оформлению, порядку согласования и утверждения технического задания на выполнение научно-исследовательских и опытно-конструкторских работ в области изделий машиностроения и приборостроения.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:
ГОСТ 2.001 Единая система конструкторской документации. Общие положения
ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов
ГОСТ 2.103 Единая система конструкторской документации. Стадии разработки
ГОСТ 2.105 Единая система конструкторской документации. Общие требования к текстовым документам
ГОСТ 2.116 Карта технического уровня и качества продукции
ГОСТ 2.118 Единая система конструкторской документации. Техническое предложение
ГОСТ 2.119 Единая система конструкторской документации. Эскизный проект
ГОСТ 2.120 Единая система конструкторской документации. Технический проект
ГОСТ 2.301 Единая система конструкторской документации. Форматы
ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы*
* В Российской Федерации действует ГОСТ Р 2.601-2019.
ГОСТ 3.1001 Единая система технологической документации. Общие положения
ГОСТ 3.1102 Единая система технологической документации. Стадии разработки и виды документов. Общие положения
ГОСТ 14.201 Обеспечение технологичности конструкции изделий. Общие требования
ГОСТ 15.012 Система разработки и постановки продукции на производство. Патентный формуляр
ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 27.003 Надежность в технике. Состав и общие правила задания требований по надежности
ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ 16504 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения
ГОСТ 19433 Грузы опасные. Классификация и маркировка
ГОСТ 21964 Внешние воздействующие факторы. Номенклатура и характеристики
ГОСТ 28934 Совместимость технических средств электромагнитная. Содержание раздела технического задания в части электромагнитной совместимости
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 техническое задание (ТЗ): Исходный технический документ для проведения работы, устанавливающий требования к создаваемому изделию (его СЧ или КИМП) и технической документации на него, а также требования к объему, срокам проведения работы и форме представления результатов.
3.2 заказчик: Предприятие (организация, объединение или другой субъект хозяйственной деятельности), по заявке или договору с которым производится разработка (модернизация), производство и (или) поставка продукции, в том числе научно-технической.
3.3 разработчик: Предприятие (организация, объединение, юридическое или физическое лицо), осуществляющее разработку продукции в установленном порядке.
3.4 изделие: Любой предмет или набор предметов производства, подлежащих изготовлению на предприятии, количество которых может исчисляться в штуках или экземплярах.
3.5 радиоэлектронные средства: Технические средства, предназначенные для передачи и (или) приема радиоволн, состоящие из одного или нескольких передающих и (или) приемных устройств либо комбинации таких устройств и включающие в себя вспомогательное оборудование.
живучесть: Свойство объекта, состоящее в его способности противостоять развитию критических отказов из дефектов и повреждений при установленной системе технического обслуживания и ремонта, или свойство объекта сохранять ограниченную работоспособность при воздействиях, не предусмотренных условиями эксплуатации, или свойство объекта сохранять ограниченную работоспособность при наличии дефектов или повреждений определенного вида, а также при отказе некоторых компонентов.
[ГОСТ 27.002-89, пояснение к термину «Надежность»]
3.7 эскизный проект (ЭП): Вид проектной конструкторской документации на изделие, содержащей принципиальные конструкторские решения, дающие общее представление о конструкции и принципе работы изделия, а также данные, определяющие его соответствие назначению.
3.8 технический проект (ТП): Вид проектной конструкторской документации на изделие, содержащей окончательные технические решения, дающие полное представление о конструкции разрабатываемого изделия и включающей данные, необходимые и достаточные для разработки рабочей конструкторской документации.
техническое предложение: Совокупность проектных КД, которые должны содержать технические и технико-экономические обоснования целесообразности разработки документации изделия на основании анализа ТЗ и различных вариантов возможных решений изделий, сравнительной оценки решений с учетом конструктивных и эксплуатационных особенностей разрабатываемого и существующих изделий, а также патентные исследования.
3.10 рабочая конструкторская документация (РКД): Совокупность конструкторских документов, предназначенных для изготовления, контроля, приемки, поставки, эксплуатации и ремонта изделия.
3.11 головной исполнитель: Предприятие (организация, объединение), выполняющее работу по созданию изделия (комплекса, системы), координирующее деятельность исполнителей составных частей этой работы и отвечающее за выполнение работы в целом.
4 Сокращения
В настоящем стандарте применены следующие сокращения:
Всегда ли нужен ГОСТ при разработке крупных проектов?
При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19.
Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее.
Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов.
Кому будет полезна статья:
представителям заказчиков (в первую очередь государственных), заинтересованным в получении результата, а не кипы бумаг;
тендерным специалистам со стороны как заказчика (специалистам по закупкам), так и исполнителя;
заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).
Если у вас есть опыт в этом вопросе, мы рекомендуем перейти к части второй, где мы расскажем, “откуда растут ноги” у ГОСТа и так ли он неизбежен при работе с госзакупками.
Часть 1. Общие понятия
Что такое техническое задание (ТЗ) и зачем оно нужно?
Представим себе абстрактную ситуацию: заказчику нужно произвести некий продукт. Для того, чтобы донести свою потребность исполнителю, заказчик фиксирует требования в следующем виде: “Система должна автоматизировать процесс получения услуги Х”. Заказчик считает необходимым указать лишь эти детали, возможно, считая всё остальное очевидным — но здесь есть риск ошибиться.
Отдельные вопросы очевидны для заказчика потому, что он живёт и работает в определённой парадигме, свойственной именно его роду занятий. При этом картина мира разработчиков будет кардинально отличаться от представлений заказчика, а значит, они могут иначе понять требования к продукту.
Если требования не проработаны совместно, возможна ситуация, когда продукт будет соответствовать восприятию разработчика, а не заказчика. В этом случае заказчик будет настаивать на изменениях в рамках оговоренного бюджета, а разработчик окажется недоволен тем, что должен за свой счет вносить изменения в продукт, который отвечает всем формально заявленным требованиям.
Однако, квалифицированный разработчик, скорее всего, не возьмется за выполнение слишком абстрактной задачи или, как минимум, разъяснит все минусы и риски такого подхода.
Для того, чтобы избежать недопонимания, одной из сторон следует задать уточняющие вопросы, а ответы зафиксировать в виде тезисов (как правило, эту роль берет на себя разработчик с необходимой экспертизой). Таким образом, он создает документ, детально описывающий требования к будущей системе, комплексно и с учётом всех “да, но” и “что, если”. Этот документ сочетает две парадигмы, заказчика и разработчика, помогая им говорить на одном языке и правильно понимать друг друга.
Между тем, «как это должно быть» (по требованию заказчика) и «как меня просят сделать» (в восприятии исполнителя) может быть огромная разница. Задача ТЗ — свести её к нулю.
Проекты без технического задания
Существуют задачи, которые не требуют полноценного ТЗ – например, когда проект сравнительно невелик или нужно лишь доработать часть готовой системы. В этом случае детализация требований может зависеть от методологии разработки, времени, погруженности каждого участника в проект и прочих сопутствующих факторов.
Тем не менее документация НУЖНА, даже если это просто описание user stories. Иногда команде достаточно иметь определенные паттерны, чтобы понимать, что определенная user story предполагает наличие функции, которая должна быть реализована тем или иным способом.
Таким образом, требования необходимы практически на любой стадии производства продукта и в конечном счете напрямую влияют на его качество.
Часть 2. ГОСТ: необходимость или неизбежность?
История вопроса
Начнём с того, что, исходя из здравого смысла, ТЗ всегда должно иметь структуру. Это непреложное правило: иначе невозможно ни управлять требованиями, ни качественно их реализовывать.
Помимо этого, требования должны быть подробными и исчерпывающими. В ином случае на стадии разработки будет больше простора для «творчества», и как следствие, есть большой риск получить продукт, не соответствующий поставленной задаче.
Для того, чтобы требования были максимально понятны всем участникам и детализированы в достаточной степени, требуются правила (стандарты). Исторически сложилось так, что при производстве информационных систем, по большей части в государственном секторе, для описания требований, используется ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
В СССР система ГОСТов была призвана сформулировать требования государства к производству продуктов, которые имеют важное межотраслевое значение. ГОСТы описывали требования к качеству и правилам производства таких продуктов. На сегодняшний день применение ГОСТов преимущественно добровольное, за некоторым исключением в части оборонзаказа.
Так как же получилось, что ГОСТ 34.602-89 стал практически обязательным для государственного заказчика?
Серия ГОСТ 34 рассматривает не только производство ТЗ. Она была создана как единый комплекс стандартов и регламентирует все стадии производства ИС, а также артефакты, которые в результате появляются.
Серия ГОСТ 34 описывает правила проведения испытаний при приемке работ. Исходным документом для программы и методики испытаний является ТЗ. При этом для госзаказчика проведение испытаний – очень важная часть контракта.
Стандарт используют по инерции, потому что долгое время не было других альтернатив. Стандарт имел государственное значение, разрабатывался на основе бесценного опыта при участии целых НИИ, а отрасль создания АИС являлась одной из важнейших для государства.
Существуют мнения, что работа над ГОСТ 34 не была доведена до своего логического завершения, тем не менее эта серия приобрела широкую популярность и до сих пор широко используется в России.
Недостатки ГОСТ
Наряду с бесспорными плюсами, ГОСТы серии 34 имеют ряд недостатков:
ГОСТы устарели морально. За время, прошедшее с их выпуска, изменились технологии и подход к процессу разработки, и появились новые более гибкие методологии.
ГОСТы избыточны. Современные гибкие подходы к разработке требуют того, чтобы с документацией можно было работать быстро и с удобством, а требования были понятны каждому члену команды.
В ГОСТ отсутствуют отдельные понятия IT-отрасли, связанные с управлением проектами и рисками.
ГОСТы серии 34 долгое время не актуализировали, они имеют незавершенный вид и зачастую недостаточно подробно рассматривают процессы сопровождения и обслуживания.
Так нужно ли писать ТЗ именно по ГОСТ 34.602-89?
В нашей практике мы придерживаемся мнения, что писать ТЗ исключительно по ГОСТ — как правило, нецелесообразно и даже вредно. Например, если у вас продуктовая разработка, в первую очередь ориентированная на клиента и его текущие потребности, стоит найти более гибкий подход к документации — для того, чтобы быстро реагировать на изменения рынка, в том числе конкурентной среды и потребительского спроса.
Если говорить о ТЗ как о юридическом документе для договора между сторонами, то соблюдать ГОСТ целесообразно, но с некоторыми оговорками. А вот на стадии производства такой документ будет практически бесполезен, так как большинство методологий разработки требуют других подходов и к взаимодействию в команде, и к основному фокусу. Как правило, в центре продукта — пользователь, его инсайты, его реакция на приложение в целом и каждый отдельный элемент.
Что же с госсектором?
ТЗ по ГОСТ 34 для госзаказчиков — это преимущественно юридический документ. Однако, в составе конкурсной документации нет понятия «Техническое задание» — этот документ правильнее называть “техническими требованиями”.
Посмотрим внимательно на состав ТЗ по ГОСТ 34, а именно:
Согласно этим документам, до формирования ТЗ проводится предпроектное обследование, а ТЗ — это неотъемлемая часть уже готового технического проекта. А значит, писать его нужно именно после обследования, но перед выполнением работ.
В ином случае будет сложно и бесполезно писать ТЗ к тому, что еще пока неизвестно. В составе конкурсной документации, как правило, такой документ будет содержать очень много “воды” и подобных формулировок: «Требования будут уточнены на стадии проектирования и зафиксированы в частном техническом задании (ЧТЗ)».
С другой стороны, в нашей практике были случаи, когда заказчик, чтобы снизить возможные риски, стремился создать ТЗ даже более подробное, чем предполагалось по ГОСТу.
В разработке, в отличие от конкурсной документации, ТЗ обычно используют в более развернутом виде (как частное техническое задание). Такой подход нацелен на более быстрое согласование формальностей, например, при проведении государственных торгов. Причина в том, что для госзаказчиков зачастую очень важны сроки, а торги занимают достаточно много времени.
В составе же техпроекта может быть больше документации, описывающей информационную систему такой, какой она должна быть (или такой, какая она есть на текущий момент).
Примеры: руководство пользователя, администратора, описание технических решений, пояснительная записка к проекту, программа и методика испытаний и так далее.
Также бывают случаи, когда на старте полная проработка системы не нужна. Например, для MVP не всегда возможно детально и точно описать всю систему, если нет детальной информации о тех модулях, которые будут добавлены в дальнейшем.
Что же делать?
Многие команды разработки стремятся найти гибкие решения для проектирования, подстраиваясь под пожелания крупного бизнеса и госсектора писать ТЗ по ГОСТ 34.
В частности, разработчики могут сформировать для заказчика отдельный документ (например, на один из модулей системы) по ГОСТ 34, как ЧТЗ. В некоторых случаях подобный документ называют “описанием постановки задачи” (ОПЗ), и он содержит в своем составе описание бизнесовой части, схемы бизнес-логики на основании требований законодательства (НПА). В таком виде документация презентуется заказчику.
Если документация согласована, для команды разработки зачастую пишут новый документ, который имеет в своем составе больше технических деталей, описания алгоритмов, логики автоматизации, схемы логических моделей, интеграцию. Иначе говоря, это вопросы, которые могут не интересовать заказчика, но будут необходимы разработчикам.
Этот документ может быть оформлен не по ГОСТ 34 (так называемая «дельта» для разработки), в нем нет общих формулировок и «воды». Естественно основной документ в базе знаний постоянно актуализируется, после мержа туда таких вот «дельт».
Такой подход тоже не всегда эффективен, как правило, он применим после того, как общая архитектура приложения согласована и уже определены подходы, выбраны методы разработки, стек технологий. (Кстати, подозреваем, что, скорее всего, отсюда и пошло деление на бизнес-анализ и системный анализ).
Другие стандарты
Помимо ГОСТ, существуют международные стандарты по проектированию требований, зачастую более современные:
Также есть стандарты и нотации практически для любой области разработки, например, по управлению услугами в сфере IT (SERVICE DESK) — ITIL Foundation.
На такие стандарты опираются международные сертификационные организации, например, IREB (International Requirements Engineering Board). В нашей команде аналитики по желанию проходят сертификацию IREB, и по нашим наблюдениям, многие заказчики обращают на это внимание (хотя если у специалиста нет сертификации, он все равно может иметь глубокие знания).
Выводы
По нашему мнению, стандарты – вещь, безусловно, полезная. На них можно и нужно опираться. Но делать ГОСТ “священной коровой” и считать его единственно верным стандартом составления технической документации – ошибочно, поскольку стандарты постепенно устаревают морально, технически и лексически.
Как правило, разработчики понимают, что следование ГОСТ в некоторых проектах имеет некую традиционную, “церемониальную” ценность, и к этому просто нужно адаптироваться. Однако, не следует забывать о здравом смысле. Как мы описали выше, можно сохранить гибкость и в жёстких условиях ГОСТа. Это справедливо как для заказчиков, так и для исполнителей.
Следуете ли вы ГОСТу или свободны в составлении документации, важно придерживаться нескольких принципов, направленных на качество требований. В их числе:
атомарность (независимость от других требований);
абстрактность (независимость от способов реализации);
Независимо от того, в какой форме нужна документация, будет уместен принцип «чем проще, тем лучше». Даже если ТЗ составлено по весьма избыточному ГОСТу, «текст ради текста» недопустим – нужно стремиться к полноте и простоте.
Спасибо за внимание! Будем рады услышать ваши мнения в комментариях.