Общие рекомендации по разработке технического задания

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

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

В разделе ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ обязательно необходимо перечислить все те документы которые были использованы для разработки технического задания (Описания бизнес-процессов, заключение аудита, служебные записки, протоколы, договор, официальные письма), в том числе и ГОСТ 19.201-78

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

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

ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНЫМ ХАРАКТЕРИСТИКАМ в большей части должны быть представлены Заказчиком. В этом подразделе приводятся все выполнимые пожелания и требования к программному продукту. Вы должны будете выполнить все требования указанные в нем. Не стоит включать в данный подраздел то, что вы не сможете осуществить.

В подразделе УСЛОВИЯ ЭКСПЛУАТАЦИИ важно помимо прочих условий, обратить внимание на требования к квалификации персонала. Чем точнее они будут описаны, тем меньше проблем с заказчиком у вас возникнет. Так же следует в подразделе ТРЕБОВАНИЯ К ИНФОРМАЦИОННОЙ И ПРОГРАМНОЙ СОВМЕСТИМОСТИ указать, на каких платформах может работать ваш программный продукт (в т.ч. серверная часть и клиент при наличии такого деления).

Раздел ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ следует заполнить общими фразами о том «как лучше станет жить» с вашей системой. Не стоит включать конкретные цифры если вероятность их достижения менее 70%.

Документация которая будет передана заказчику по результатам разработки (внедрения) системы должна быть приведена в соответствующем разделе ТРЕБОВАНИЯ К ПРОГРАМНОЙ ДОКУМЕНТАЦИИ. Это третье ограничение к объему работ и по сути является соглашением о том, какие документы получит заказчик в тот момент когда вы будете резать красную ленточку окончания внедрения на предприятии. Стоит перечитать договор перед составлением данного раздела, перечень требований к документации может уже быть включен в его текст.

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

СТАДИИ И ЭТАПЫ РАЗРАБОТКИ должны обязательно содержать сроки работ. При этом стоит указывать сроки в рабочих днях, начало каждого этапа или стадии должно начинаться после выполнения какого либо условия (наступления события). Чем детальней будет этапность работ, тем проще в дальнейшем будет ее контролировать. Если вы можете указать для каждого этапа или стадии условия их выполнения уже на стадии написания технического задания, это будет большим плюсом данного документа.

ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РАБОТ это последний раздел технического задания и является самым важным его составляющим. Нельзя выделять этот раздел в отдельный документ и ссылаться на него в техническом задании как иногда поступают не слишком дальновидные руководители. Он должен быть неотъемлемой частью документа и согласован одновременно со всем техническим заданием. Так же следует в данном разделе указать точные требования к приемке работ и виды испытаний ( с указанием их последовательности).

Пример разработки гипотетической АИС - Единая автоматизированная система учета кадров всех государственных предприятий "АС Кадры".

Структура технического задания:

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

1.1 Полное наименование системы и ее условное обозначение

1.2 Определения, обозначения и сокращения

2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

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

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

3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

4 ТРЕБОВАНИЯ К СИСТЕМЕ

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

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

4.1.1.1 Перечень подсистем, их назначение и основные характеристики

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

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