Пример тех задания на программу

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

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

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

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

Автоматизированная информационная система «Платежи и взаиморасчеты с кредиторами «.

Условное обозначение системы:

АИС «Платежи и взаиморасчеты с кредиторами «

1.2. Номер договора

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

09 Пример составления технического задания

1.3. Наименования Разработчика и Заказчика работ и их реквизи-ты

Разработчик:

Закрытое акционерное общество » Автоматизированные информационные системы «

Адрес: 103237, Москва, ул. Проспект Вернадского, д.3

Тел.: (095)922-33-55, факс: (095)922-33-44

Банковские реквизиты: ЗАО » Автоматизированные информационные системы «, ИНН 7501004321, р/сч № 40603410800020007021 в АКБ Сбербанк России, БИК 044579857, корр. счет № 30101820400000000335

Закрытое акционерное общество «Оргсинтез»

Адрес: 603000, Нижний Новгород, ул. Московское шоссе, д.12

Тел.:(8312) 44-10-18, факс: (8312)44-10-10

Банковские реквизиты: ЗАО «Оргсинтез», ИНН 7501004321, р/сч № 40603410800020004521 в СКБ Банк «Гарантия», БИК 044573421, корр. счет № 30101820400000001234

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

Основанием для проведения работ по созданию системы АИС «Платежи и взаиморасчеты с кредиторами » являются следующие документы:

Договор № 135426 от 14.05.2005

Приказ №56 от 10.05.2005

Распоряжение №35 от 11.05.2005.

1.5. Сроки начала и окончания работ

Дата начала работ: 01.12.2005

Дата окончания работ: 01.05.2006

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

Финансирование работ осуществляется из средств ЗАО «Оргсинтез». Порядок финансирования работ определяется условиями Договора № 135426 от 14.05.2005 г.

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

Работы по созданию Системы производятся и принимаются поэтапно.

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

«Разработка ТЗ по ГОСТ 34» – Кристина Стец | SoftTeco PM/BA Talks

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

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

АИС «Платежи и взаиморасчеты с кредиторами» — прикладное программное обеспечение, предназначенное для:

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

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

Основными целями внедрения системы являются:

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

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

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

3.1. Работа с отчетами

В приложении АИС «Платежи и взаиморасчеты с кредиторами » предусмотрена возможность построения различных отчетов. Сформированные отчеты выводятся в приложение MS Excel . Пользователь имеет возможность вывести отчет на печать или сохранить отчет на диске.

Основные типы отчетов:

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

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

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

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

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

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

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

Должна обеспечиваться работа в двух режимах:

• сетевой режим взаимодействия;
• автономный.

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

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

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

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

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

4.1.5. Перспективы развития системы

АСУ должна иметь длительный жизненный цикл.

АСУ должна быть построена с использованием стандартизованных и эффективно сопровождаемых решений.

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

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

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

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

Количество пользователей АСУ определяется текущими потребностями ОАО «Оргсинтез».

Количество администраторов АСУ может быть определено по следующей методике: 1 администратор на 20-30 пользователей плюс 1 ведущий специалист или 1 начальник отдела автоматизации.

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

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

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

Пользователи АСУ должны иметь базовые навыки работы с операционными системами Microsoft (любая из версий: Microsoft Windows 95, 98, ME, NT 4.0, 2000, XP), офисным программным обеспечением Microsoft Office.

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

Все администраторы АСУ должны иметь квалификацию «инженер» и обязательные навыки администрирования сети на основе операционной системы Microsoft Windows 2000.

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

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

Время выполнения запросов информации в АСУ определяется на стадии проектирования системы.

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

Прочие показатели назначения АСУ разрабатываются после проведения предпроектного обследования.

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

Показатели надёжности

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

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

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

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

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

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

Должно осуществляться разграничение прав доступа к системе.

Должен вестись журнал событий системы.

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

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

Источник: intuit.ru

Техническое задание — что это и как составить + примеры ТЗ на сайт и ПО

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

1. разработке приложений;
2. проектировании дома;
3. написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

1. Определитесь, кто будет составлять техническое задание
2. Разъясните термины
3. Откажитесь от субъективных терминов

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

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

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

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

Опишите сайт

Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.

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

Расскажите о структуре

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

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

Пример простейшей структуры в виде блок-схемы

Опишите, что будет на каждой из страниц

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

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

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

Выдвините требования к дизайну

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

1. Укажите, какие корпоративные цвета можно использовать в дизайне, а какие оттенки — категорически нет
2. Предоставьте логотип, который обязательно должен присутствовать в шапке сайта
3. Укажите шрифты, которые желательно использовать для оформления страниц, меню, футера, контента

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими — нет. Опишите отдельным блоком:

1. На какой CMS будет разработан сайт — Вордпресс, Джумла, Модэкс и так далее
2. Какой язык программирования можно использовать — PHP, JavaScript, HTML, другие
3. На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
4. Какую программную платформу можно использовать — .NET, OpenGL, DirectX
5. И так далее

Если клиент не понимает ничего в используемых терминах — объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне .ru от домена в зоне .com. Вместе составьте требования так, чтобы они устроили клиента.

Уточните требования к работе сайта

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

1. Приемлемую для вас скорость загрузки сайтов или стандартное значение — 1–5 секунд
2. Кроссбраузерность — распишите, в каких браузерах сайт должен открываться
3. Адаптивность — укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
4. Устойчивость к нагрузкам — сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
5. Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

1. Уникальности текста — не меньше 95% по Адвего, Текст.ру, Контент.Вотч
2. Тошноте (заспамленности)— не более 10% по Адвего иди 65% по Текст.ру
3. Баллам по Главреду — не менее 6,5 или 7 баллов

Конечно, разные сервисы — не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

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

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования — ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

1. Линк
2. Название статьи
3. Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы — по 10 на каждой.

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

Сроки: до 15.09.2018.

Естественно, это ТЗ можно улучшить — мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?

Источник: quasa.io

Пример тех задания на программу

24.12.2014

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

Специалисты компании «ПроТекст» будут рады разработать техническое задание для Вашей компании с учётом всех нюансов. Подробности на этой странице.

Техническое задание на разработку мобильного приложения

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

1.1 Идея проекта – Дайте поставщику услуг максимально много деталей о вашем проекте разработки мобильных приложений.

1.2 Определите основную цель своего мобильного приложения – краткое, но точное объяснение того, чего вы хотели бы достичь.

1.3 Укажите, на каких платформах должно работать ваше мобильное приложение: Android, iPhone, BlackBerry или любой другой, должно ли оно быть кросс-платформенным или нет.

1.4 Графический дизайн – Уточните, будет ли разработка дизайна передана на аутсорсинг (если да, укажите, кто будет работать над проектной задачей: подрядчик или фрилансер…), или всё будет выполнено в рамках компании.

1.5 Бюджет проекта – Расскажите о рамках бюджета.

1.6 Желаемые сроки поставки продукции – Укажите дату поставки и этапы развития проекта мобильного приложения.

2. Детали проекта

2.1 Экраны – экраны (вкладки) должны быть представлены отдельно, с имеющимися изображениями, презентациями и всеми другими визуальными материалами.

2.2 Интеграция с социальными медиа – Уточните, должно ли мобильное приложение быть интегрировано с социальными медиа (Facebook, Twitter….).

2.3 Ландшафтный режим – Уточните, хотите ли вы реализовать в вашем мобильном приложении ландшафтный режим.

2.4 Автономная работа – Упомяните, должно ли мобильное приложение сохранять любые данные на устройстве.

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

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

2.7 Встроенные покупки – Упомяните, должны ли пользователи мобильного приложения иметь возможность покупать контент внутри приложения, и если да, то какой тип контента будет продаваться.

2.8 Услуги геолокации – Укажите, будет ли у вашего мобильного приложения функциональность гео-данных.

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

3. Рыночная информация

3.1 Целевая группа – Представьте свои идеи о потенциальных пользователях вашего мобильного приложения.

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

4. Разные вопросы

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

4.2 Связь – Опишите желаемый метод(ы) общения с вашим поставщиком услуг.

4.3 Дополнительные сведения – Любые другие подробности проекта, вопросы и т.д.

Источник: protext.su