Как составить техническое задание на автоматизированную систему

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так вот:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В данной статье приведен пример (образец) проектного документа «Техническое задание на создание автоматизированной системы (АС)» согласно ГОСТ 34.602-89. В качестве примера АС для заполнения разделов использовались требования на разработку информационно-аналитической системы «Корпоративное хранилище данных».

Разделы технического задания:

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

Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных»

1. Общие сведения

1.1. Наименование системы

1.1.1. Полное наименование системы

Например:
Полное наименование: Корпоративное хранилище данных.

1.1.2. Краткое наименование системы

Например:
Краткое наименование: КХД, Система.

1.2. Основания для проведения работ

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

Например:
Работа выполняется на основании договора № … от … между …

1.3. Наименование организаций – Заказчика и Разработчика

1.3.1. Заказчик

Заказчик: ОАО Заказчик
Адрес фактический: г. Москва …
Телефон / Факс: +7 (495) 2222222

1.3.2. Разработчик

Разработчик: ЗАО Разработчик
Адрес фактический: г. Москва …
Телефон / Факс: +7 (495) 3333333

1.4. Плановые сроки начала и окончания работы

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

1.5. Источники и порядок финансирования

Если не целесообразно указывать эти сведения, то дается ссылка на Договор.

1.6. Порядок оформления и предъявления заказчику результатов работ

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

Например:
Работы по созданию КХД сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2. Назначение и цели создания системы

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

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

КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика.
Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика.
В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:
1. анализ финансово-хозяйственной деятельности;
2. информационная поддержка процессов бюджетирования;
3. …

2.2. Цели создания системы

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

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

Приводятся краткие сведения об области деятельности Заказчика (или подразделения организационной структуры Заказчика, для нужд которого разрабатывается система) и сферы автоматизации с указанием ссылок на ранее разработанные документы, содержащие более подробные сведения об организации заказчика.
<Приводится описание организационной структуры>
Как правило, объектом автоматизации являются бизнес-процессы, выполняемые в структурных подразделениях Заказчика. Следовательно, применительно к данному ТЗ, объектами автоматизации будут являться бизнес-процессы, выполняемые в <указать в каком подразделении>.
Выделены следующие процессы в деятельности <указать подразделение Заказчика>, в рамках которых производится анализ информации и вынесены соответствующие выводы о возможности их автоматизации:

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

4.1. Требования к системе в целом

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

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

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

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

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.
Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

Приводятся требования к характеристикам взаимосвязей со смежными системами.

Смежными системами для КХД являются:
— информационные системы оперативной обработки данных Заказчика;
— информационные системы планирования;
— …
Источниками данных для Системы должны быть:
— Информационная система управления предприятием (СУБД MS SQL).
— Информационно-справочная система (СУБД MS SQL).
— Информационная система обеспечения бюджетного процесса (СУБД Oracle).
— …
Перечень предпочтительных способов взаимодействия со смежными системами приведен ниже.
— Информационная система управления предприятием — с использованием промежуточной базы данных (ПБД).
— Информационно-справочная система — обмен файлами ОС определенного формата.
— Информационная система обеспечения бюджетного процесса — интеграция «точка – точка».
— …

Определяются требования к режимам функционирования системы.

Например:
Система должна поддерживать следующие режимы функционирования:
— Основной режим, в котором подсистемы КХД выполняют все свои основные функции.
— Профилактический режим, в котором одна или все подсистемы КХД не выполняют своих функций.
В основном режиме функционирования Система КХД должна обеспечивать:
— работу пользователей в режиме – 24 часов в день, 7 дней в неделю (24х7);
— выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.
В профилактическом режиме Система КХД должна обеспечивать возможность проведения следующих работ:
— техническое обслуживание;
— модернизацию аппаратно-программного комплекса;
— устранение аварийных ситуаций.
Общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (Y часов в месяц).

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

Для обеспечения высокой надежности функционирования Системы как системы в целом, так и её отдельных компонентов должно обеспечиваться выполнение требований по диагностированию ее состояния.
Диагностирование Системы должно осуществляться следующими штатными средствами, входящими в комплект поставки программного обеспечения:
— СУБД — <указывается ПО администратора позволяющее проводить мониторинг>;
— ETL-средство — ..
— средство визуализации — …
Обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР.
Для всех технических компонентов необходимо обеспечить регулярный и постоянный контроль состояния и техническое обслуживание.

4.1.2. Требования к численности и квалификации персонала системы и режиму его работы

4.1.2.1. Требования к численности персонала

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

К квалификации персонала, эксплуатирующего Систему КХД, предъявляются следующие требования.
— Конечный пользователь — знание соответствующей предметной области; знание основ многомерного анализа; знания и навыки работы с аналитическими приложениями..
— Администратор подсистемы сбора, обработки и загрузки данных — знание методологии проектирования хранилищ данных; знание методологии проектирования ETL процедур; знание интерфейсов интеграции ХД с источниками данных; знание СУБД; знание языка запросов SQL.
— Администратор подсистемы хранения данных — глубокие знания СУБД; знание архитектуры «Звезда» и «Снежинка»; опыт администрирования СУБД; знание и навыки операций архивирования и восстановления данных; знание и навыки оптимизации работы СУБД.
— Администратор подсистемы формирования и визуализации отчетности — понимание принципов многомерного анализа; знание методологии проектирования хранилищ данных; знание и навыки администрирования приложения; знание языка запросов SQL; знание инструментов разработки.

4.1.2.3. Требования к режимам работы персонала

Персонал, работающий с Системой КХД и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:
— Конечный пользователь — в соответствии с основным рабочим графиком подразделений Заказчика.
— Администратор подсистемы сбора, обработки и загрузки данных – двухсменный график, поочередно.
— Администратор подсистемы хранения данных – двухсменный график, поочередно.
— Администратор подсистемы формирования и визуализации отчетности – в соответствии с основным рабочим графиком подразделений Заказчика.

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

4.1.3.1. Параметры, характеризующие степень соответствия системы назначению

Система должна обеспечивать следующие количественные показатели, которые характеризуют степень соответствия ее назначению:
— Количество измерений – X.
— Количество показателей – Y.
— Количество аналитических отчетов – Z.

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

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

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

4.1.4. Требования к надежности

4.1.4.1. Состав показателей надежности для системы в целом

Например:
Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.
Надежность должна обеспечиваться за счет:
— применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
— своевременного выполнения процессов администрирования Системы КХД;
— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
— предварительного обучения пользователей и обслуживающего персонала.
Время устранения отказа должно быть следующим:
— при перерыве и выходе за установленные пределы параметров электропитания — не более X минут.
— при перерыве и выходе за установленные пределы параметров программного обеспечением — не более Y часов.
— при выходе из строя АПК ХД — не более Z часов.
Система должна соответствовать следующим параметрам:
— среднее время восстановления Q часов — определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода;
— коэффициент готовности W — определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;
— время наработки на отказ E часов — определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки.
Средняя наработка на отказ АПК не должна быть меньше G часов.

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

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

4.1.4.3. Требования к надежности технических средств и программного обеспечения

Например:
К надежности оборудования предъявляются следующие требования:
— в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;
— применение технических средств соответствующих классу решаемых задач;
— аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.
К надежности электроснабжения предъявляются следующие требования:
— с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее X минут;
— система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;
— система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает Y минут;
— должно быть обеспечено бесперебойное питание активного сетевого оборудования.
Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:
— предварительного обучения пользователей и обслуживающего персонала;
— своевременного выполнения процессов администрирования;
— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
— своевременное выполнение процедур резервного копирования данных.
Надежность программного обеспечения подсистем должна обеспечиваться за счет:
— надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;
— проведением комплекса мероприятий отладки, поиска и исключения ошибок.
— ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.

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

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

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

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

Например:
Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.
Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система «Человек-машина». Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.
Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).
Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

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

4.1.7.1. Требования к информационной безопасности

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

4.1.7.2. Требования к антивирусной защите

Например:
Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы КХД. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:
— централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;
— централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов;
— централизованное автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов;
— ведение журналов вирусной активности;
— администрирование всех антивирусных продуктов.

4.1.7.3. Разграничения ответственности ролей при доступе к <указать объект ограничения (например, отчет, показатель, измерение)>

Требования по разграничению доступа приводятся в виде матрицы разграничения прав.

Матрица должна раскрывать следующую информацию:
— код ответственности: Ф — формирует, О – отвечает, И – использует и т.п.;
— наименование объекта системы, на который накладываются ограничения;
— роль сотрудника/единица организационной структуры, для которых накладываются ограничения.

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

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

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

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

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

Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий.
Требования к радиоэлектронной защите:
— электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК Системы, не должны приводить к нарушениям работоспособности подсистем.
Требования по стойкости, устойчивости и прочности к внешним воздействиям:
— Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % — 30 %);
— Система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
— Система должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
— Система должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

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

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

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должнен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.
Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) должны использоваться встроенные возможности ПО <указывается название BI приложения>, а также, в случае необходимости, языки программирования <указываются языки программирования и их версии>.
В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

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

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

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

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

Специальные требования по усмотрению разработчика или заказчика системы.

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

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

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

При внедрении, эксплуатации и обслуживании технических средств системы должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей».
Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.
Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:
— 50 дБ — при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
— 60 дБ — при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

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

КСА системы являются стационарными и после монтажа и проведения пуско-наладочных работ транспортировке не подлежат.

4.2. Требования к функциям, выполняемым системой

В данном подразделе приводят:
1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди — перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования к одновременности выполнения групп функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

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

4.3.1 Требования к математическому обеспечению

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

Не предъявляются.

4.3.2. Требования к информационному обеспечению

Приводятся требования:
1) к составу, структуре и способам организации данных в системе;
2) к информационному обмену между компонентами системы;
3) к информационной совместимости со смежными системами;
4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
5) по применению систем управления базами данных;
6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
7) к защите данных от разрушений при авариях и сбоях в электропитании системы;
к контролю, хранению, обновлению и восстановлению данных;
9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

4.3.3. Требования к лингвистическому обеспечению

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

При реализации системы должны применяться следующие языки высокого уровня: SQL, Java и д.р.
При реализации системы должны применяться следующие языки и стандарты взаимодействия КХД со смежными системами и пользователей с КХД: должны использоваться встроенные средства диалогового взаимодействия BI приложения; Java; Java Script; HTML; др.
Должны выполняться следующие требования к кодированию и декодированию данных: Windows CP1251 для подсистемы хранения данных; Windows CP1251 информации, поступающей из систем-источников.
Для реализации алгоритмов манипулирования данными в ХД необходимо использовать стандартный язык запроса к данным SQL и его процедурное расширение <например для Oracle DB это Oracle PL/SQL>.
Для описания предметной области (объекта автоматизации) должен использоваться Erwin.
Для организации диалога системы с пользователем должен применяться графический оконный пользовательский интерфейс.

4.3.4. Требования к программному обеспечению

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

4.3.5. Требования к техническому обеспечению

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

Система должна быть реализована с использованием специально выделенных серверов Заказчика.
Сервер базы данных должен быть развернут на HP9000 SuperDome №1, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; Network Card: 2 (2 Gbit); Fiber Channel: 4.
Сервер сбора, обработки и загрузки данных должен быть развернут на HP9000 SuperDome №2, минимальная конфигурация которого должна быть:
CPU: 8 (16 core); RAM: 32 Gb; HDD: 100 Gb; Network Card: 2 (1 Gbit); Fiber Channel: 2.
Сервер приложений должен быть развернут на платформе HP Integrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; Network Card: 3 (1 Gbit).
Приведенные сервера должны быть подключены к дисковому массиву HP XP с организацией сети хранения данных. Минимальный объем свободного пространства для хранения данных на дисковом массиве должен составлять 100 Тб.

4.3.6. Требования к метрологическому обеспечению

В требованиях к метрологическому обеспечению приводят:
1) предварительный перечень измерительных каналов;
2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;
3) требования к метрологической совместимости технических средств системы;
4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;
5) требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы;
6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

Не предъявляются.

4.3.7. Требования к организационному обеспечению

Приводятся:
1) требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию.
2) требования к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.
3) требования к защите от ошибочных действий персонала системы.

4.3.8. Требования к методическому обеспечению

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

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

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

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

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

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

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

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

В разделе указывают:
1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

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

В перечень основных мероприятий включают:
1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
2) изменения, которые необходимо осуществить в объекте автоматизации;
3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
4) создание необходимых для функционирования системы подразделений и служб;
5) сроки и порядок комплектования штата и обучения персонала.

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

В данном разделе приводят:
1) согласованный Разработчиком и Заказчиком перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли Заказчика;
перечень документов, выпускаемых на машинных носителях;
требования к микрофильмированию документации;
2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

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

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

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:
— Договор № … от … между …
— ГОСТ 24.701-86 «Надежность автоматизированных систем управления».
— ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды».
— ГОСТ 21958-76 «Система «Человек-машина». Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
— ГОСТ 12.1.004-91 «ССБТ. Пожарная безопасность. Общие требования».
— ГОСТ Р 50571.22-2000 «Электроустановки зданий».
— и т.д.

МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ. МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

Информационные технологии

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Техническое задание на создание автоматизированной системы

Издание официальное

Москва

Российский институт стандартизации 2021

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1    РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

2    ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3    ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 22 декабря 2020 г. № 58)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. Nfl 1522-ст межгосударственный стандарт ГОСТ 34.602-2020 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2022 г.

5 ВЗАМЕН ГОСТ 34.602-89

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

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

© Оформление ФГБУ «РСТ», 2021

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

Редактор Л. В. Корвтиикова Технический редактор В.Н. Прусакова Корректор О.В. Лазарева Компьютерная верстка И.А. Налейкиной

Сдано в набор 22.11.2021. Подписано в печать 30.11.2021. Формат 60*84%. Гарнитура Ариал. Уел. печ. л. 1.40. Уч.-изд. л. 1,12.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении о ФГБУ «РСТ» для комплектования Федерального информационного фонда стандартов. 117418 Москва. Нахимовский пр-т. д. 31. к. 2. www gosUnfo.ru mfo@gostmfo ru

ГОСТ 34.602-2020

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Информационные технологии

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Техническое задание на создание автоматизированной системы

Information technology. Set of standards for automated systems.

Technical assignment for developing of automated system

Дата введения — 2022—01—01

1    Область применения

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

2    Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий межгосударственный стандарт:

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

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

3 Общие положения

3.1    ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка.

ТЗ на другие виды работ (развитие, модернизация и т. п.) может быть оформлено в соответствии с требованиями настоящего стандарта. При этом название вида работ отражается в наименовании ТЗ.

3.2    ТЗ на АС разрабатывают на систему в целом. АС может функционировать самостоятельно или в составе другой автоматизированной системы.

Издание официальное

3.3    В АС могут выделяться составные части (СЧ), для которых могут разрабатываться ТЗ на составные части (далее — ТЗ на СЧ).

Могут разрабатываться ТЗ на следующие составные части:

—    на подсистемы АС. комплексы задач АС. функции АС и т. п.;

—    на отдельные объекты АС. подлежащие автоматизации в рамках создания АС;

—    на комплектующие изделия, средства технического обеспечения и программно-технические комплексы в соответствии со стандартами Единой системы конструкторской документации (ЕСКД) и Системы разработки и постановки продукции на производство (СРПП);

—    на программные средства в соответствии со стандартами Единой системы программной документации (ЕСПД);

—    на информационные изделия в соответствии с ГОСТ 19.201 и нормативно-технической документацией (НТД). действующей в ведомстве заказчика АС.

Примечание —В ТЗ на АС для группы взаимосвязанных объектов следует включать только общие для группы объектов требования. Специфические требования отдельного объекта следует отражать в ТЗ на СЧ.

3.4    Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

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

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

3.5    Изменения к ТЗ на АС оформляют дополнением. Дополнение является неотъемлемой частью ТЗ на АС.

Порядок согласования и утверждения дополнения к ТЗ на АС должен быть аналогичен порядку согласования и утверждения ТЗ на АС.

4 Состав и содержание

4.1    ТЗ на АС содержит следующие обязательные разделы:

—    общие сведения;

—    цели и назначение создания автоматизированной системы:

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

—    требования к автоматизированной системе;

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

—    порядок разработки автоматизированной системы;

—    порядок контроля и приемки автоматизированной системы;

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

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

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

В ТЗ на АС могут быть включены приложения.

Примечание — В случае отсутствия требований по разделу, соответствующий раздел сохраняется, и в нем приводится запись об отсутствии требований.

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

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

В ТЗ на СЧ не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

4.3    В разделе «Общие сведения» указывают следующее:

—    полное наименование АС и ее условное обозначение;

—    шифр темы (при наличии);

—    наименование организации — заказчика АС, наименование организации-разработчика (при наличии сведений о ней);

—    перечень документов, на основании которых создается АС, кем и когда утверждены эти документы;

•    плановые сроки начала и окончания работ ло созданию АС;

•    общие сведения об источниках и порядке финансирования работ.

Примечание — К документам, на основании которых или в соответствии с которыми создается АС, могут относиться, например, следующие:

—    договорные документы на создание АС;

—    нормативно-правовые и нормативно-технические документы, регламентирующие создание АС;

—    техническое задание на создание ранее разрабатывавшейся АС.

4.4    Раздел «Цели и назначение создания автоматизированной системы» состоит из следующих подразделов:

—    цели создания АС;

—    назначение АС.

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

4.4.2    В подразделе «Назначение АС» указывают вид автоматизируемой деятельности (управление. проектирование и т. п.) применительно к объекту автоматизации в целом.

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

4.5    В разделе «Характеристика объекта автоматизации» приводят следующую информацию:

—    основные сведения об объекте автоматизации или ссылки на документы, содержащие такие сведения;

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

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

4.6    Раздел «Требования к автоматизированной системе» состоит из следующих подразделов:

—    требования к структуре АС в целом;

—    требования к функциям (задачам), выполняемым АС;

—    требования к видам обеспечения АС;

—    общие технические требования к АС.

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

4.6.1    В подразделе «Требования к структуре АС в целом» указывают следующее:

—    перечень подсистем (при их наличии), их назначение и основные характеристики. Дополнительно могут быть приведены требования к числу уровней иерархии и степени централизации АС;

—    требования к способам и средствам обеспечения информационного взаимодействия компонентов АС;

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

—    требования к режимам функционирования АС;

—    требования по диагностированию АС;

—    перспективы развития, модернизации АС.

4.6.2    В подразделе «Требования к функциям (задачам), выполняемым АС», приводят перечень функций (задач), подлежащих автоматизации для АС в целом или для каждой подсистемы (при их наличии). В перечень включаются в том числе функции (задачи), обеспечивающие взаимодействие частей АС.

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

При необходимости дополнительно могут быть указаны следующие данные:

—    временной регламент реализации каждой функции (задачи);

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

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

4.6.3 В подразделе «Требования к видам обеспечения АС» приводят требования к математическому. информационному, лингвистическому, программному, техническому, метрологическому, организационному. методическому и другим видам обеспечения АС.

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

4.6.3.2    Для информационного обеспечения АС приводят следующие требования:

—    к составу, структуре и способам организации данных в АС;

—    к информационному обмену между компонентами АС и со смежными АС:

—    к информационной совместимости со смежными АС;

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

—    по применению систем управления базами данных;

—    к представлению данных в АС;

—    к контролю, хранению, обновлению и восстановлению данных.

4.6.3.3    Для лингвистического обеспечения АС приводят следующие требования:

* к языкам, используемым в АС, и возможности расширения набора языков (при необходимости):

—    к способам организации диалога;

—    к разработке и использованию словарей, тезаурусов;

—    к описанию синтаксиса формализованного языка.

4.6.3.4    Для программного обеспечения АС приводят следующую информацию:

—    требования к составу и видам программного обеспечения;

—    требования к выбору используемого программного обеспечения;

—    требования к разрабатываемому программному обеспечению;

—    перечень допустимых покупных программных средств (при наличии).

4.6.3.5    Для технического обеспечения АС приводят следующие требования:

—    к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в АС;

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

4.6.3.6    В требованиях к метрологическому обеспечению АС приводят следующую информацию:

—    количественные значения показателей метрологического обеспечения;

—    требования к методам (методикам) измерений и измерительного контроля параметров и их характеристик;

—    требования к средствам измерений и измерительного контроля;

—    требования к метрологическому обеспечению испытаний АС;

—    требования к программе метрологического обеспечения АС;

—    требования к метрологической совместимости технических средств АС;

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

4.6.3.7    Для организационного обеспечения АС приводят следующие требования:

—    к структуре и функциям подразделений, участвующих в функционировании АС или обеспечивающих эксплуатацию;

—    к организации функционирования АС и порядку взаимодействия персонала и пользователей АС;

—    к организации функционирования АС при сбоях, отказах и авариях;

—    к порядку обеспечения нормативными документами, необходимыми для разработки АС.

4.6.3.8    Для методического обеспечения АС приводят следующую информацию;

—    перечень применяемых при разработке и функционировании АС нормативно-технических документов (стандартов, нормативов, методик, профилей и т. п.);

—    порядок и правила обеспечения разработчиков АС нормативно-технической документацией.

4.6.4 В подразделе «Общие технические требования к АС» указывают следующее:

—    требования к численности и квалификации персонала и пользователей АС;

—    требования к показателям назначения;

—    требования к надежности;

—    требования по безопасности;

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

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

—    требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов АС;

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

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

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

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

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

—    дополнительные требования.

4.6.4.1    В требованиях к численности и квалификации персонала и пользователей АС приводят следующее:

—    требования к численности персонала и пользователей АС;

—    требования к квалификации персонала и пользователей АС. порядку их подготовки и контроля знаний и навыков;

—    требуемый режим работы персонала и пользователей АС.

4.6.4.2    В требованиях к показателям назначения АС приводят значения параметров, характеризующих степень соответствия АС ее назначению (при их наличии).

4.6.4.3    В требования к надежности включают:

—    состав и количественные значения показателей надежности для АС в целом или ее подсистем (составных частей);

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

—    требования к надежности технических средств и программного обеспечения.

—    требования к методам оценки и контроля показателей надежности на разных стадиях создания АС в соответствии с действующими нормативно-техническими документами.

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

4.6.4.5    В требования к эргономике и технической эстетике включают следующие требования:

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

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

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

4.6.47 В требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов АС включают:

—    условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) и программно-технических средств (ПТС) АС с заданными показателями;

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

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

—    требования к составу, размещению и условиям хранения комплекта запасных частей, инструментов и принадлежностей, а также к нормам расхода запасных частей;

—    требования к регламенту обслуживания.

4.6.4.8    В требования к защите информации от несанкционированного доступа включают требования. установленные в НТД. действующей в отрасли (ведомстве) заказчика.

4.6.4.9    В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе — потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в АС.

4.6.4.10    В требованиях к защите от внешних воздействий приводят:

—    требования к радиоэлектронной защите средств АС;

—    требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

4.6.4.11    В требованиях к патентной чистоте и патентоспособности указывают требования по патентной чистоте и патентоспособности АС и ее частей, включая требования по проведению патентных исследований.

4.6.4.12    В требования к стандартизации и унификации включают показатели, устанавливающие следующее:

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

—    требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.

4.6.4.13    В дополнительные требования включают:

•    требования к оснащению АС учебно-тренировочными средствами и документацией на них;

—    требования к сервисной аппаратуре, стендам для проверки элементов АС;

—    требования к АС. связанные с особыми условиями эксплуатации;

—    специальные требования по усмотрению разработчика или заказчика АС.

4.7    Раздел «Состав и содержание работ по созданию автоматизированной системы» должен содержать перечень этапов работ по созданию АС и сроки их выполнения.

4.8    В разделе «Порядок разработки автоматизированной системы» приводят следующее:

—    порядок организации разработки АС;

—    перечень документов и исходных данных для разработки АС;

—    перечень документов, предъявляемых по окончании соответствующих этапов работ;

•    порядок проведения экспертизы технической документации;

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

—    порядок разработки, согласования и утверждения плана совместных работ по разработке АС;

—    порядок разработки, согласования и утверждения программы работ по стандартизации;

—    требования к гарантийным обязательствам разработчика;

—    порядок проведения технико-экономической оценки разработки АС;

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

4.9    В разделе «Порядок контроля и приемки автоматизированной системы» указывают следующую информацию:

—    виды, состав и методы испытаний АС и ее составных частей;

—    общие требования к приемке работ, порядок согласования и утверждения приемочной документации;

—    статус приемочной комиссии (государственная, межведомственная, ведомственная и др.).

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

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

В перечень мероприятий включают следующее:

—    создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой АС требованиям, содержащимся в ТЗ на АС;

—    проведение необходимых организационно-штатных мероприятий;

—    порядок обучения персонала и пользователей АС.

4.11    В разделе «Требования к документированию» приводят следующую информацию:

—    перечень подлежащих разработке документов;

—    вид представления и количество документов;

—    требования по использованию ЕСКД и ЕСПД при разработке документов.

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

4.12    В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании АС.

5 Правила оформления

5.1    Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разделе 4.

5.2    ТЗ на АС оформляют в виде текстового документа.

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

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

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

«Окончательное требование (значение) уточняется… и согласовывается …». При этом в текст ТЗ на АС изменений не вносят.

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

5.5    При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли отметки, например: гриф секретности, код работы, регистрационный номер ТЗ и другие отметки.

5.6    Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования «Техническое задание» пишут «Дополнение № … к ТЗ на АС … ».

5.7    На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения (при необходимости).

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

УДК 004:006.354    МКС    35.240

01.040.35

Ключевые слова: информационные технологии, автоматизированные системы, техническое задание

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

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

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

1. О чем статья

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

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

Кстати, ТЗ — это не первый документ, который разрабатывается в ходе проекта автоматизации. Об этом прямо говорится в пункте 1.5. ГОСТ 34.602-89: «ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии “Исследование и обоснование создания АС”». Подробнее см. в моей статье

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

.

ВНИМАНИЕ: ЦЕЛЬ ЭТОЙ СТАТЬИ — НЕ ЗАМЕНИТЬ ГОСТ, А РАЗЪЯСНИТЬ НЕКОТОРЫЕ ЕГО ПОЛОЖЕНИЯ.

2. Характерные особенности Технического задания по ГОСТ 34

2.1. По какому стандарту составляется ТЗ?

Полное наименование стандарта на ТЗ по ГОСТ 34 следующее: ГОСТ 34.602-89 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

Действительно, в стандарте используется много непонятных терминов. Что, например, имеется в виду под лингвистическим обеспечением? Для прояснения использующихся понятий следует обратиться к ГОСТ 34.003-90 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».

2.2. Зачем нужен ГОСТ на Техническое задание?

Наверное, когда вам нужно составить какой-то новый для вас документ, вы ищете в Интернете шаблон такого документа или просите его у коллег. Так вот, ЛЮБОЙ стандарт на документы или процессы — это шаблон. Причем шаблон очень сильно упрощает разработку документа: за тебя уже продумали структуру и содержание, кроме того, в таком шаблоне учитываются такие моменты, про которые вы бы и не вспомнили.

2.3. Какую роль Техническое задание занимает в проекте?

Согласно пункту 1.7 стандарта РД 50-682-89, «техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком». И это действительно главный документ. В нем должно описываться все, что необходимо для разработки и внедрения системы.

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

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

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

Концепцию системы

, об этом мы говорили в самом начале статьи.

2.4. Насколько ГОСТ 34.602-89 устарел и есть ли более новые стандарты?

Ни насколько не устарел. Мне почти не удалось найти каких-то неактульных вещей. И никто из тех, кто заявляет об устаревании ГОСТ 34, не могут привести ни одного примера (наверное, просто не хватило квалификации для его прочтения?) Дело в том, что ГОСТ описывает общий подход к проекту автоматизации, там не идет речь о программировании, ГОСТ 34 не об этом.

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

• IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению.
• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
• ISO/IEC/IEEE 29148-2011. Systems and software engineering — Life cycle processes — Requirements engineering.
• ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.
• Ну и ГОСТы серии 34.

3. Общие принципы составления ТЗ по ГОСТ 34

3.1. Какой специалист должен составлять Техническое задание по ГОСТ 34?

Часто разработчики сильно ругаются при составлении ТЗ по ГОСТ 34. Почему? Да потому что это не дело программистов. Техническое задание по ГОСТ 34 вообще можно программистам не показывать. Для этого существуют документы технического проекта. Техническое задание — это документ, который согласовывается с заказчиком, который постоянно на столе у руководителя проекта. ТЗ отвечает на два вопроса: ЧТО должна делать система, и КАК она должна создаваться. Технический же проект отвечает на вопрос: КАК должны быть выполнены требования ТЗ. Например, в ТЗ вы прописываете, что должна быть авторизация по логину и паролю, а в ТП приводите макеты интерфейса, сценарии, структуру базы данных. Почему существует деление на разные этапы и почему не следует сразу делать задание для программистов, смотрите в моих статьях

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы

и

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

.

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

3.2. Какая сторона должна составлять Техническое задание?

В основном Техническое задание составляется исполнителем? Почему?

Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34-602-89. На самом деле, у заказчика, как правило, отсутствуют соответствующие специалисты. Но ТЗ в обязательном порядке прорабатывается и согласовывается заказчиком. И вот здесь нужно обязательно добиться того, чтобы согласование не было формальным. Я всегда стараюсь настоять на том, чтобы мы вместе с заказчиком подробно разобрали каждый пункт. Ваша цель — вовлечь заказчика в проект. Иначе он так и не сформирует свои ожидания от системы, а значит, во-первых, будет недоволен любым результатом, а, во-вторых, не сможет провести необходимые организационные мероприятия.

3.3. Насколько далеко можно отходить от ГОСТ 34?

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

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

Не верите? Тогда читайте пункт 2.2 ГОСТ 34.602-89 (кстати, цифры после дефиса — год публикации стандарта или его редакции): «В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы».

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

3.4. Зачем в ТЗ по ГОСТ 34 описывается так много требований, напрямую не относящихся к функциям системы?

Действительно, в ТЗ из 30-и страниц может только 7-10 страниц быть посвящено функциям. У этого есть объяснение. Дело в том, что разработчики ГОСТ 34 совершенно по-другому смотрели на проект автоматизации, чем мы. И смотрели более правильно, более комплексно.

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

Во-вторых, составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система — это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. И правда, отбери у бухгалтеров компьютеры, они с трудом, но смогут выполнять свою работу, пусть и с бумажными реестрами. А вот 1С без бухгалтера самостоятельно работать не будет. Отсюда и множество разделов ТЗ, посвященных организационным мерам. Как говорят, ИТ-система на 20% — это ИТ, все остальное — организационные мероприятия. То есть ТЗ — это документ, в котором прописывается все необходимое для внедрения системы, от А до Я.

В-третьих, обратите на само название ГОСТа 34.602-89: «Техническое задание на создание автоматизированной системы». ТЗ не на систему, а на создание системы. В чем отличие? Отличие в том, что ТЗ устанавливает не только требования к самой системе, но и регламентирует процесс ее создания, то есть в документе приводятся требования ко всем организационным мерам, выполнение которых необходимо для достижения результата. Ведь при реализации проекта автоматизации зачастую следует перестроить ряд процессов, обучить персонал, подготовить аппаратную часть.

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

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

3.5. Зачем в разных разделах говорится об одном и том же?

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

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

3.6. Нужно ли качественно оформлять ТЗ?

Хотя требования к оформлению ТЗ приводятся в пункте 3 ГОСТ 34.602-89, скажем несколько слов о данном аспекте.

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

Приведем несколько пожеланий к оформлению больших документов, как ТЗ.

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

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

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

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

Заметим, что, по строгим правилам, ТЗ оформляется без рамки (об этом сказано в п. 3), а вот остальные документы — с рамкой. Это установлено в ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов (с Изменениями № 1, 2)». Данный стандарт устанавливает правила оформления всех документов, кроме ТЗ и документов, создаваемых на предпроектных стадиях. Хотя лично мне рамка не нравится ни в каких документах.

4. Раздел 1. «Общие сведения» /п. 2.3 ГОСТ 34.602-89/

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

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

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

5. Раздел 2. «Назначение и цели создания (развития) системы» /п. 2.4 ГОСТ 34.602-89/

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

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

С целью все по-другому. Цель — это ради чего мы затеваем проект. Можно назвать это бизнес-целями. Я выделяю следующие возможные цели проектов автоматизации:

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

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

6. Раздел 3. «Характеристики объекта автоматизации» /п. 2.5 ГОСТ 34.602-89/

Очень важный, и при этом часто описываемый чисто формально раздел. Хотя, на мой взгляд, это самый важный раздел ТЗ, без него мы просто не понимаем, о чем вообще создаваемая система.

Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.

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

В данном разделе следует приводить:

1. Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
2. Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
3. Описание автоматизируемых объектов. Например, если мы автоматизируем склад, то должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
4. Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии — обязательно. Только тогда нам становится ясно, какие должны иметься функции.
5. Перечень документов, в которых приводится подробное описание объекта автоматизации.

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

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

В ТЗ по ГОСТ 34 имеется один гигантский раздел: раздел 4 «Требования к системе». В нем имеется три подраздела:

• Требования к системе в целом.
• Требования к функциям (задачам), выполняемым системой.
• Требования к видам обеспечения.

Эти подразделы мы рассмотрим по отдельности.

7.1. Подраздел 4.1. «Требования к системе в целом» /п. 2.6.1 ГОСТ 34.602-89/

В подразделе 4.1 «Требования к системе в целом» приводят так называемые нефункциональные, общие, требования, которые описывают создаваемую систему с разных сторон.

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

7.1.1. Пункт 4.1.1. «Требования к структуре и функционированию системы» /п. 2.6.1.1 ГОСТ 34.602-89/

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

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

В данном пункте я обычно привожу:

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

Если вы планируете микросервисную архитектуру, то имеет смысл перечень и описание функциональности сервисов.

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

… или так:

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

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

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

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

4. Требования к режимам функционирования системы.
Режимы функционирования могут иметь несколько классификаций:

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

5. Требования по диагностированию системы.

Требования по постоянному или периодическому диагностированию следует предъявлять к системам, основанным на микросервисной (разнесенной) архитектуре, системам, в состав которых входит оборудование: датчики, системы управления, терминалы и т.д. Конечно, если разрабатывается только программное обеспечение, которое работает на одном сервере, указанные требования излишни: и так узнаете, если что-то перестанет работать.

6. Перспективы развития, модернизации системы.

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

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

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

7.1.2. Пункт 4.1.2. «Требования к численности и квалификации персонала» /п. 2.6.1.2 ГОСТ 34.602-89/

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

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

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

7.1.3. Пункт 4.1.3. «Требования к показателям назначения» /п. 2.6.1.3 ГОСТ 34.602-89/

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

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

К показателям назначения можно отнести:

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

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

7.1.4. Пункт 4.1.4. «Требования к надежности» /п. 2.6.1.4 ГОСТ 34.602-89/

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

Основным понятием, которое можно применить для автоматизированных систем, является коэффициент готовности: 99%, 99,9%, 99,99%. Каждое количество «девяток» обеспечивается определенными мерами.

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

7.1.5. Пункт 4.1.5. «Требования к безопасности» /п. 2.6.1.5 ГОСТ 34.602-89/

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

7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/

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

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

Material Design

для Android и

Human Interface Guidelines

для iOS.

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

7.1.7. Пункт 4.1.7. «Требования к транспортабельности для подвижных АС» /п. 2.6.1.7 ГОСТ 34.602-89/

Скажете, какое-то устаревшее требование. Сейчас сервера на грузовиках, как раньше большие ЭВМ, не возят. Тем не менее, представьте себе, у вас какая-то суперзащита, внутренний контур за DMZ и… необходимость удаленной работы через ноутбук. Да, VPN настраивается в любой момент, но лучше, если это будет отражено в Руководстве по администрированию, а сама возможность предусмотрена конфигурацией сети.

7.1.8. Пункт 4.1.8. «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению» /п. 2.6.1.8 ГОСТ 34.602-89/

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

7.1.9. Пункт 4.1.9. «Требования к защите информации от несанкционированного доступа» /п. 2.6.1.9 ГОСТ 34.602-89/

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

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

Так, для финансовых систем следует использовать «Стандарт безопасности данных индустрии платежных карт» (PCI DSS). Для систем, в которых хранятся персональные данные, — Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». В вашей предметной области могут иметься и другие стандарты.

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

1. Средства, обеспечиваемые создаваемым программным продуктом.
2. Меры, обеспечиваемые системным администратором.
3. Меры физической защиты.
4. Общие организационные меры.
5. Меры, принимаемые в процессе разработки программного обеспечения.

1. Средства защиты, обеспечиваемые создаваемым программным продуктом:

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

2. Меры, обеспечиваемые системным администратором:

• Применение межсетевых экранов (файерволов).
• Документирование и мониторинг используемых служб и протоколов.
• Конфигурирование демилитаризованной зоны (DMZ).
• Контроль выполнения правил использования портативных компьютеров: подключение к внутренней сети, использование межсетевых экранов.
• Отключение учетных записей по умолчанию перед подключением в сеть оборудования и систем.
• Настройка устройств беспроводного доступа: установка паролей и изменение настроек доступа, установленных по умолчанию.
• Установка обновлений, устраняющих выявленные уязвимости оборудования и программного обеспечения.
• Обеспечение безопасности при удаленном доступе в систему (например, использование VPN).
• Установка, обновление и мониторинг работы антивирусного программного обеспечения.
• Проведение периодического сканирования сети и сканирования после внесения важных изменений.
• Назначение каждому работнику уникальной учетной записи, периодические проверки на наличие неудаленных учетных записей уволенных сотрудников, смена паролей. Выдача и учет токенов электронной подписи.
• Настройка ограничения доступа к базам данных.
• Контроль синхронизации времени на всех серверах и рабочих станциях (с целью обеспечения корректности времени, регистрируемого в журналах регистрации событий).
• Настройка журналов регистрации событий.
• Периодическая инвентаризация точек беспроводного доступа и другого оборудования, установленного программного обеспечения.

3. Меры физической защиты:

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

4. Общие организационные меры:

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

5. Меры, принимаемые в процессе разработки программного обеспечения:

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

7.1.10. Пункт 4.1.10. «Требования по сохранности информации при авариях» /п. 2.6.1.10 ГОСТ 34.602-89/

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

• потеря питания;
• выход из строя сервера;
• выход из строя устройства хранения (жесткого диска).

7.1.11. Пункт 4.1.11. «Требования к защите от влияния внешних воздействий» /п. 2.6.1.11 ГОСТ 34.602-89/

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

7.1.12. Подраздел 4.1.12. «Требования по патентной чистоте» /п. 2.6.1.12 ГОСТ 34.602-89/

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

7.1.13. Пункт 4.1.13. «Требования к стандартизации и унификации» /п. 2.6.1.13 ГОСТ 34.602-89/

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

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

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

7.1.14. Пункт 4.1.14. «Дополнительные требования» /п. 2.6.1.14 ГОСТ 34.602-89/

С данным пунктом следует ознакомиться в самом тексте ГОСТа. В комментариях он не нуждается.

7.2. Подраздел 4.2. «Требования к функциям (задачам), выполняемым системой» /п. 2.6.2 ГОСТ 34.602-89/

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

7.2.1. Структура функционального описания

Сначала рассмотрим структуру функциональных требований к системе: подсистема — комплекс функций — функция — задача. Задача — это часть функции, причем задача может быть описана в виде отдельной функции. Например, для функции входа в систему в качестве одной из задач мы приводим ввод пароля. А процедуру ввода пароля мы можем расписать уже как отдельную функцию: проверка на правильность, восстановление пароля, отображение подсказок и т.д. Комплекс — это то, что объединяет функции. Например, «Учет основных сведений», «Проведение аукциона» и т.д. В Комплексе две и более функции.

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

7.2.2. Виды функций с точки зрения их выполнения

По сути, все функции (или их задачи; в функции может присутствовать сразу несколько задач) можно разделить на следующие типы:

• Ввод сведений. Иногда называют также «учет сведений».
• Вывод информации.
• Автоматическая обработка информации.

7.2.3. Виды функций с точки зрения их роли

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

7.2.4. Требование, а не сценарий

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

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

7.2.5. Оформление функциональных требований

Приведем некоторые рекомендации по тому, как оформлять описание функций:

1. Требования к функциям и задачам обычно следует выносить в приложение. Таким образом документ органично делится на нефункциональную и функциональную части. Кроме того, приложение всегда можно распечатать и рассматривать отдельно.
2. Избегайте больших абзацев. Лучше всего, если требования разбиты по пунктам и подпунктам: так легче их воспринимать и контролировать их выполнение (галочки ставить). Если приводится перечень требований или сведений, пусть он приводится нумерованным или маркированным списком.
3. Для функций, назначение которых не очевидно из их названия, следует обязательно указать цель и решаемую задачу. В противном случае даже составитель ТЗ рискует забыть, зачем он описывал ту или иную функциональность.

7.2.6. Пример описания функции

5.6. Регистрация транспортного средства в Системе

Предъявляются следующие требования:

1) Система должна позволять учитывать следующие общие сведения:

• государственный регистрационный знак (ГРНЗ);
• ФИО собственника;
• адрес собственника;
• данные от сервиса получения данных о ТС (см. п. 3.3, Приложение Б);
• примечание.

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

• текущий класс ТС (см. п. 3.3, Приложение А);
• текущий тариф (см. п. 5.1, Приложение А);
• текущий договор (см. п. 5.5, Приложение А);
• класс ТС по сведениям из системы МВД РК;
• сведения о лицевом счете и его состоянии (см. п. 3.6, Приложение А);
• сведения о нахождении в реестре ТС с льготным проездом (см. п. 3.5, Приложение А).

3) Система должна позволять регистрировать и изменять сведения о ТС следующими способами:

• вручную оператором;
• при поступлении сведений из системы регистрации RFID-меток (см. п. 1.1, Приложение Б);
• при идентификации ТС с помощью камеры ГРНЗ.

4) При регистрации в системе нового ТС система должна запрашивать данные о ТС от сервиса получения данных о ТС (см. п. 3.3, Приложение Б). Должна иметься возможность обновить указанные сведения отдельного ТС.

7.3. Подраздел 4.3. «Требования к видам обеспечения» /п. 2.6.3 ГОСТ 34.602-89/

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

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

При чтении данного подраздела задаешься вопросом, что имели в виду составители стандарта под «математическим обеспечением», «лингвистическим обеспечением», «информационным обеспечением» и т.д. Ответы следует искать в ГОСТ 34.003-90, где расшифровываются все эти термины.

7.3.1. Пункт 4.3.1 «Математическое обеспечение» /п. 2.6.3.1 ГОСТ 34.602-89/

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

7.3.2. Пункт 4.3.2 «Информационное обеспечение» /п. 2.6.3.2 ГОСТ 34.602-89/

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

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

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

7.3.3. Пункт 4.3.3 «Лингвистическое обеспечение» /п. 2.6.3.3 ГОСТ 34.602-89/

В данном пункте приводятся:

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

7.3.4. Пункт 4.3.4 «Программное обеспечение» /п. 2.6.3.4 ГОСТ 34.602-89/

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

7.3.5. Пункт 4.3.5 «Техническое обеспечение» /п. 2.6.3.5 ГОСТ 34.602-89/

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

7.3.6. Пункт 4.3.6 «Метрологическое обеспечение» /п. 2.6.3.6 ГОСТ 34.602-89/

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

7.3.7. Пункт 4.3.7 «Организационное обеспечение» /п. 2.6.3.7 ГОСТ 34.602-89/

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

7.3.8. Пункт 4.3.8 «Методическое обеспечение» /п. 2.6.3.8 ГОСТ 34.602-89/

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

7.3.9. Другие виды обеспечения

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

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

.

8. Раздел 5 «Состав и содержание работ по созданию (развитию) системы» /п. 2.7 ГОСТ 34.602-89/

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

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

• Наименование этапа (подэтапа).
• Содержание работ (краткое описание, перечень задач).
• Результат работ (утвержденные документы, разработанные и сданные решения).
• Проектная, рабочая или отчетная документация.
• Ответственные (кто выполняет данную работу: заказчик, исполнитель или иное лицо). Если обе стороны должны выдать совместный результат, указываются роли.
• Длительность (сроки, даты, начало отсчетов сроков).

Пример содержания данного раздела приведен в таблице ниже.

9. Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

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

9.1. Подраздел 6.1. «Виды, состав, объем и методы испытаний системы и ее составных частей» /п. 2.8.1 ГОСТ 34.602-89/

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

Остановимся подробнее на видах испытаний. Виды испытаний, их состав, требования к документам устанавливаются ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Поэтому при разработке данного раздела и технического проекта обязательно обращайтесь к этому стандарту, здесь мы разъясним только основные моменты.

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

1. Испытания делятся на следующие виды:

• Предварительные.
• Опытная эксплуатация.
• Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

• Автономные (без интеграции со смежными системами).
• Комплексные (в комплексе со смежными системами).

Зачем испытания делятся на разные стадии? Во-первых, потому что ГОСТ 34.603-92 не разделяет внутреннюю приемку и внешнюю, часть испытаний может проводиться без заказчика. Во-вторых, описывается последовательный процесс тестирования, часть за частью, а потом уже все в комплексе.

Давайте попробуем описать процесс испытаний простыми словами:

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

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

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

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

5. Приемочные испытания. Это последний вид проверки. Скажете, а почему опытная эксплуатация после устранения всех недостатков плавно не перейдет в промышленную? Так оно обычно и происходит. Но ведь высоким дядям надо увидеть, что система реально работает, «пощупать» ее. Для них, для высокой комиссии и предназначены приемочные испытания. Таким образом, приемочные испытания отличаются от предварительных в первую очередь статусом комиссии.

Также в этом пункте указываются документы, в которых будут приведены методы испытаний:

• Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце — в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно — в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
• Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

В данном разделе я обычно указываю:

1. На чьей территории и на чьем оборудовании будут проводиться испытания: заказчика или исполнителя.
2. Общее описание, каким образом будут проводиться испытания (например, что будут проверяться документы, наличие элементов пользовательского интерфейса, отрабатываться сценарии).
3. Список участников.
4. Перечень документов, которыми оформляют результат испытаний:
   • Для предварительных и приемочных испытаний это протокол испытаний, в котором приводится перечень проверок и их результаты.
   • Для опытной эксплуатации — журнал опытной эксплуатации.

10. Раздел 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» /п. 2.9 ГОСТ 34.602-89/

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

5 «Состав и содержание работ по созданию (развитию) системы»

. Но, в разделе 5 они лишь кратко упоминаются, здесь же приводится подробное описание.

При подготовке объекта, как правило, следует выполнить следующие работы:

1. Проведение реорганизации, набор нового персонала, в случае необходимости.
2. Обучение персонала.
3. Для веб-приложений: разработка общих разделов сайта и пользовательского соглашения (согласия на обработку персональных данных).
4. Заполнение справочников и иных исходных сведений.
5. Перенос данных из прежней системы.
6. Развертывание системы на промышленных серверах.
7. Настройка интеграции со смежными системами.
8. Настройка системы доступа и создание учетных записей.

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

11. Раздел 8 «Требования к документированию» /п. 2.10 ГОСТ 34.602-89/

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

Документирование проекта автоматизации по ГОСТ 34 регламентируется следующими стандартами:

• ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем.
• РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
• Для Технического задания — ГОСТ 34.602-89, который мы сейчас и обсуждаем.

В первом стандарте (ГОСТ 34.201-89) приводится перечень и структура документации. Во втором — РД 50-34.698-90 — указывается содержание следующих документов:

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

11.1 Особенности структуры документации

При составлении перечня необходимых документов обычно просматривают РД 50-34.698-90 и выбирают требуемые. При этом делается немало ошибок, поскольку документация имеет довольно сложную структуру, которая описывается в ГОСТ 34.201-89.

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

1. Для каждого из этапов предназначен свой комплект документации.

Для каждого из этапов предназначен свой комплект документации. Это очень важно уяснить. Не надо прописывать разработку эксплуатационных документов на проектных стадиях и наоборот. Получаются чисто формальные бумаги, на которые вы потратите значительное время. И если «Руководство пользователя» до окончания разработки системы обычно никто не составляет (хотя встречал и таких деятелей), то «Описание автоматизированных функций», в котором обычно приводятся сценарии для программистов, постоянно составляют уже после окончания разработки. Также при чтении РД 50-34.698-90 может создаться впечатление, что у некоторых документов содержание пересекается: это тоже связано с тем, что документы предназначаются для различных этапов.

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

Чтобы не запутаться, я составил

таблицу Excel

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

2. Документы делятся на темы (части проекта).

В ГОСТе 34 имеются документы, описывающие общесистемные решения, а также организационное, техническое, математическое, программное, информационное обеспечение (о видах обеспечения мы говорили выше). В РД 50-34.698-90 данные документы приводятся именно с разбивкой по частям проекта (темам). На это всегда следует обращать внимание, чтобы определить предназначение документа.

3. Документы можно объединять.

В ГОСТ 34.201-89 прямо указывается, в каких случаях один документ включается в состав другого. Это сделано для того, чтобы не оставалось вырожденных документов, с одной или двумя страничками. Если что-то требуется описать, но объем очень маленький, лучше всего включить текст в другой документ. В большинстве случаев имеется такой документ как «Пояснительная записка к техническому проекту», в который можно добавлять разделы.

4. Эксплуатационная и проектно-сметная документация выделены отдельно.

Составители ГОСТ 34.201-89 в отдельных столбцах таблицы с перечнем документов обозначили принадлежность к эксплуатационной и проектно-сметной документации.

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

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

11.2 Особенности оформления списка документов

Как вы уже заметили ранее, при описании этапов работ в разделе 5 «Состав и содержание работ по созданию (развитию) системы» также приводится перечень документации. Двойной список документов приводится по простой причине: мало указать наименование документа, необходимо еще пояснить его назначение и привести краткое содержание (конечно, для «Руководства пользователя» указывать содержание смысла нет). Иначе будет не определить, какое значение у того или иного документа в управлении проектом. ГОСТ гостом, а на каждом проекте содержание и роль документов может отличаться. Кроме того, в перечне могут иметься документы, не регламентируемые ГОСТ 34, которые нуждаются в пояснениях в обязательном порядке.

В правилах документирования обычно я привожу таблицу со следующими столбцами:

• Этап.
• Наименование документа.
• Примечание: указывается стандарт разработки, назначение, краткое содержание и основные особенности документа.

11.3 Пример перечня документации

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

12. Раздел 9 «Источники разработки» /п. 2.11 ГОСТ 34.602-89/

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

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

• Материалы с описанием аналогов (прототипов) разрабатываемой системы.
• Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
• Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
• Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
• Материалы и стандарты, содержащие требования к общей и информационной безопасности.

Заключение

Конечно, составление Технического задания по ГОСТ 34 нельзя назвать легким и простым. И не потому, что ГОСТ плохой, — просто ГОСТ заставляет продумывать весь проект целиком, расписать все мелочи. Зато хорошо составленное ТЗ — половина успеха проекта.

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

Читайте другие статьи автора:

• Предпроектное обследования при разработке информационной системы.
• Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы.
• Некоторые заметки по проектированию информационных систем.

Что такое техническое задание на доработки 1С? С точки зрения ГОСТов*, в которых регламентирована деятельность по разработке программного обеспечения и автоматизированных систем (АС) – это основной документ, определяющий требования и порядок развития или модернизации (далее – создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

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

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

Зачем нужно техническое задание

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

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

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

Кто разрабатывает техническое задание

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

Типовые ошибки при разработке технического задания

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

• Излагаются не системно, без привязки к какой-либо структуре (модули системы, бизнес-процессы);
• Дублируются;
• Относятся к различным уровням детализации.

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

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

• Излишняя детализация;
• Требования, противоречащие друг другу;
• Неточные формулировки.

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

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

Как избежать ошибок при составлении ТЗ

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

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

Руководствоваться нужно следующими правилами:

• Формирование ТЗ – это совместная работа исполнителя и заказчика;
• Риски исполнителя должны быть минимизированы и не должны превышать аналогичные для заказчика (иначе это приведет к увеличению стоимости проекта);
• Требования формируются объективными, использование субъективного виденья заказчика не рекомендуется;
• Не допускается использование терминов, принятых в широком деловом общении, но противоречащих принятым в отрасли и стандарте;
• Основное внимание уделяется описанию результатов, требуемых заказчиком. Например, заказчику необходимо получать отчет о движении товара в соответствующих аналитических разрезах, тогда в ТЗ должны быть подробно описаны параметры отчета (строки, аналитика, период, за который составляется отчет) и источники данных для его формирования. Самое главное здесь – не допустить расширенного толкования технического задания, иначе, если вы не указали период или источник данных, конечный результат может сильно отличаться от требований заказчика, а доработка потребует дополнительных средств и времени.

Разработка, например, «правильного» ТЗ программисту 1С, подразумевает полное погружение в тему, знание всех ее аспектов и тонкостей. ТЗ должно давать ответ не только на вопрос «что должен сделать программист», но в первую очередь – «какие задачи должна решать система 1С:Предприятие после выполнения работ». Требования должны быть сформулированы подробно, но без лишней информации. Это уменьшит вероятность появления неточностей и ошибок. Именно поэтому привести универсальный пример технического задания 1С не представляется возможным – каждый случай ТЗ на разработку 1С уникален.