Пример технического задания на автоматику. А нужно ли вообще техническое задание? А технический проект? Что с этим делать на практике

129kb. 09.12.2011 03:33

1.doc

^ Дата введения с 01.01.1990г.

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

Рекомендуемый порядок разработки, согласования и утверждения ТЗ на АС приведен в приложении 1.
^

1. ОБЩИЕ ПОЛОЖЕНИЯ

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

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

Дополнительно могут быть разработаны ТЗ на части АС:

• 
  на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта;
• 
  на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП;
• 
  на программные средства в соответствии со стандартами ЕСПД;
• 
  на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

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

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

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

1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с... ».
^

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

• 
  1) общие сведения;
• 
  2) назначение и цели создания (развития) системы;
• 
  3) характеристика объектов автоматизации;
• 
  4) требования к системе;
• 
  5) состав и содержание работ по созданию системы;
• 
  6) порядок контроля и приемки системы;
• 
  7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• 
  8) требования к документированию;
• 
  9) источники разработки.

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

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

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

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

• 
  1) полное наименование системы и ее условное обозначение;
• 
  2) шифр темы или шифр (номер) договора;
• 
  3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
• 
  4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
• 
  5) плановые сроки начала и окончания работы по созданию системы;
• 
  6) сведения об источниках и порядке финансирования работ;
• 
  7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

• 
  1) назначение системы;
• 
  2) цели создания системы.

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

2.5. В разделе «Характеристики объекта автоматизации» приводят:

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

Примечание : Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

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

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

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

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

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

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

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

2.6.1.2. В требованиях к численности и квалификации персонала на АС приводят:

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

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

Для АСУ указывают:

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

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

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

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

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

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

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

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

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

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

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

• 
  1) требования к радиоэлектронной защите средств АС;
• 
  2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

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

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

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

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

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

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

 2) временной регламент реализации каждой функции, задачи (или комплекса задач);

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

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

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

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

2.6.3.2. Для информационного обеспечения системы приводят требования:

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

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

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

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

2.6.3.5. Для технического обеспечения системы приводят требования:

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

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

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

2.6.3.7. Для организационного обеспечения приводят требования:

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

 2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

 3) к защите от ошибочных действий персонала системы.

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

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

В данном разделе также приводят:

• 
  1) перечень документов, по ГОСТ 34.201-89 , предъявляемых по окончании соответствующих стадий и этапов работ;
• 
  2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
• 
  3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
• 
  4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

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

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

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

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

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

Например, для АСУ приводят:

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

2.10. В разделе «Требования к документированию» приводят:

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

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

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

• 
  1) расчет ожидаемой эффективности системы;
• 
  2) оценку научно-технического уровня системы.

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

3. ПРАВИЛА ОФОРМЛЕНИЯ

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

3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

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

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

«Окончательное требование (значение) уточняется в процессе...

И согласовывается протоколом с... на стадии...».

При этом в текст ТЗ на АС изменений не вносят.

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

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

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

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

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

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

ПРИЛОЖЕНИЕ 1
Рекомендуемое
^

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).

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

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

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

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

5. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий (форма произвольная) и конкретное решение принимается в установленном порядке.

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

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

9. Копии, утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы или ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501.

______________________________________________________ Наименование организации - разработчика ТЗ на АС УТВЕРЖДАЮ Руководитель (должность, наименование предприятия - заказчика АС) Дата УТВЕРЖДАЮ Руководитель (должность, наименование предприятия - разработчик" АС) Личная подпись Расшифровка подписи Наименование вида АС ________________________________________________________ Наименование объекта автоматизации ________________________________________________________ Сокращенное наименование АС ^ ТЕХНИЧЕСКОЕ ЗАДАНИЕ На ____ листах Действует с СОГЛАСОВАНО Руководитель (должность, наименование согласующей организации) Личная подпись Расшифровка подписи

СОСТАВИЛИ

СОГЛАСОВАНО

ПРИЛОЖЕНИЕ 4
Справочное
^

ПОЛОЖЕНИЯ ПО СОЗДАНИЮ ЕДИНОГО КОМПЛЕКСА СТАНДАРТОВ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

1. Исходные предпосылки создания комплекса

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

1.2. В период принятия Госстандартом СССР решения о совершенствовании межотраслевых комплексов стандартов действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС:

• 
  1) единая система стандартов автоматизированных систем управления (24-я система), распространяющаяся на АСУ, АСУП, АСУ ТП и другие организационно-экономические системы;
• 
  2) комплекс стандартов (система 23501); распространяющихся на системы автоматизированного проектирования;
• 
  3) четвертая группа 14-й системы стандартов, распространяющаяся на автоматизированные системы технологической подготовки производства.

1.3. Практика применения стандартов на АСУ, САПР, АСУ ТП, АСТПП показала, что в них применяется одинаковый понятийный аппарат, имеется много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия по обозначению, составу, содержанию и оформлению документов и пр.

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

1.5. В настоящее время осуществляется переход к созданию сложных АС (за рубежом системы CAD - САМ), включающих в свой состав АСУ технологическими процессами и производствами, САПР - конструктора, САПР - технолога, АСНИ и др. системы. Использование противоречивых правил при создании таких систем приводит к снижению качества, увеличению стоимости работ, затягиванию сроков ввода АС в действие.

1.6. Единый комплекс стандартов и руководящих документов должен распространяться на автоматизированные системы различного назначения: АСНИ, САПР, ОАСУ, АСУП, АСУТП, АСУГПС, АСК, АСТПП, включая их интеграцию.

1.7. При разработке межотраслевых документов следует учитывать следующие особенности АС как объектов стандартизации:

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

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

2. Взаимосвязь ЕКС АС с другими системами и комплексами стандартов

2.1. Стандартизация в области АС является составной частью работ по обобщенной проблеме «Информационная технология».

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

2.3. ЕКС АС должен охватывать специфические для автоматизированных систем направления стандартизации и распространять традиционные направления стандартизации на программно-технические, программно-методические комплексы и автоматизированные системы в целом.

2.4. Направления и задачи стандартизации при нормативно-техническом обеспечении процессов создания и функционирования АС группируют следующим образом:

• 
  1) установление технических требований к продукции;
• 
  2) регламентация методов испытаний и правил аттестации и сертификации продукции;
• 
  3) регламентация правил и порядка разработки;
• 
  4) установление правил документирования;
• 
  5) обеспечение совместимости;
• 
  6) регламентация организационно-методических вопросов функционирования систем.

Направления 1-4 являются традиционными при разработке, изготовлении и поставке продукции. Направления 5, 6 являются специфичными и вытекают из особенностей, присущих АС.

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

Компоненты технического, программного и информационного обеспечений, как продукцию производственно-технического назначения, рассматривают, соответственно, как конструкторские, программные и информационные изделия. На эти изделия распространяются действующие комплексы стандартов ЕСКД, СРПП, ЕСПД, СГИП, УСД, классификаторы и кодификаторы технико-экономической информации, комплексы стандартов вида «ОТТ», «Методы испытаний», «ТУ», а также ОТТ заказчика.

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

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

2.5.3. Информационные изделия в настоящее время не обеспечены НТД, хотя отдельные вопросы проработаны в рамках УСД, классификаторах и кодификаторах технико-экономической информации.

2.6. Программно-технические и программно-методические комплексы рассматриваются как сложные изделия, не имеющие аналогов в машиностроении. Учитывая статус ПТК и ПМК как продукции производственно-технического назначения, правила и порядок их разработки должен быть аналогичен требованиям, установленным стандартами системы разработки и постановки продукции на производство (СРПП).

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

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

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

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

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

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

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

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

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• На каком языке (в смысле сложности понимания) должно быть написано техническое задание?
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с техническим заданием?

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

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

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

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

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

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

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

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

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

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

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

Формулирование требований к информационной системе. Структура ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полное наименование системы и ее условное обозначение;	Тут все понятно: пишем, как будет называться система, ее краткое наименование
Шифр темы или шифр (номер) договора;	Это не актуально, но можно и указать, если требуется
Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;	Указывают, кто (какие организации) будет работать над проектом. Можно указать и их роли. Можно вообще удалить этот раздел (достаточно формальный).
Перечень документов, на основании которых создается система, кем и когда утверждены эти документы;	Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую вам предоставили для ознакомления с определенной частью требований
Плановые сроки начала и окончания работы по созданию системы;	Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы
Сведения об источниках и порядке финансирования работ;	Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников)
Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.	Не вижу необходимости в этом пункте, требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы.

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

	Что с этим делать на практике
Назначение системы	С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Заказчик всегда может говорить, что под качеством он имел в виду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном техническом задании».
Цели создания системы	Цели – это, безусловно, важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, при разворачивании дерева целей (дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит. Вообще, умение выделять цели, формулировать их, строить дерево целей – это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.

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

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

	Что с этим делать на практике
Требования к системе в целом. ГОСТ расшифровывает перечень таких требований: требования к структуре и функционированию системы; требования к численности и квалификации персонала системы и режиму его работы; показатели назначения; требования к надежности; требования безопасности; требования к эргономике и технической эстетике; требования к транспортабельности для подвижных АС; требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; требования к защите информации от несанкционированного доступа; требования по сохранности информации при авариях; требования к защите от влияния внешних воздействий; требования к патентной чистоте; требования по стандартизации и унификации;	Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным: Требования к квалификации. Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п. Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правило, такие требования инициирует IT-служба заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.; Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное техническое задание – эти требования могут оказаться достаточно сложными. Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.
Требования к функциям (задачам), выполняемым системой	Вот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.
Требования к видам обеспечения ГОСТ выделяет такие виды: Математическое Информационное Лингвистическое Программное Техническое Метрологическое Организационное Методическое и другие…	На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования: Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято; К системе предъявляются требования мультиязычного интерфейса (например, русский/английский) Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники; Для функционирования системы у заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы; Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.) Возможны другие ситуации, все зависит от конкретных целей проекта.

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

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

Что с этим делать на практике

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

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

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

	Что с этим делать на практике
Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;	Весьма важный момент. К примеру, для функционирования системы так, как задумано, может потребоваться использование каких-либо отраслевых или общероссийских справочников и классификаторов. Эти справочники должны каким-то образом появляться в системе, обновляться и правильно использоваться. Могут быть и любые другие правила ввода информации, принятые в компании (или планируемые). Например, информация о договоре раньше заносили текстовой строкой в произвольном виде, а теперь требуется номер отдельно, дату отдельно и т.д. Таких условий может быть очень много. Часть из них может быть воспринята с сопротивлением персонала, поэтому лучше все такие случаи прописать на уровне требований к порядку ввода данных
Изменения, которые необходимо осуществить в объекте автоматизации Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ	Любые изменения, которые могут потребоваться. Например, в компании отсутствует локальная сеть, устаревший парк компьютеров, на которых система не заработает. Возможно, какая-то необходимая информация обрабатывалась на бумаге, а теперь ее необходимо вводить в систему. Если этого не делать, то какой-либо модуль не заработает. Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам. Этот перечень может быть длинным, смотрите на конкретный случай своего проекта.
Создание необходимых для функционирования системы подразделений и служб; Сроки и порядок комплектования штатов и обучения персонала	Про это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй.

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

Что с этим делать на практике

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

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

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

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

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

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

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

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

Вид требования

Неправильная формулировка