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

Пример ТЗ и ТП на небольшую доработку

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

Техническое задание:

УТВЕРЖДАЮ ПРЕДСТАВЛЯЮ НА УТВЕРЖДЕНИЕ

» «______________ 2010 г. » «_______________ 2010 г.

Автоматизированная

система «СБЫТ».

Техническое задание

Действует с «__» ____________ 2010 г.

» _» ______________ 2010 г.

Наименование автоматизированной системы

Заказчик

Исполнитель

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

Плановые сроки начала и окончания работ по созданию системы

Начало работ: 01.09.2010

Окончание работ: 31.12.2010

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

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

Разрабатываемая автоматизированная система предназначена для автоматизации процессов сбыта предприятия..

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

Цели создания автоматизированной системы

Целями разработки «АС СБЫТ»являются:

3.1 Бизнес процессы предприятия

3.1. 1 Бизнес процесс «Заключение договора»

3.1.2. Бизнес процесс «Начисление оплаты»

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

4.1.1. Разрабатываемые в АС методы и программные модули должны содержать возможности дальнейшего развития системы.

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

5.1.2. Разрабатываемая АС должна обеспечивать простоту настройки автоматизированного рабочего места (АРМ) каждого конкретного исполнителя в соответствии со сложившейся системой учета.

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

5.1.4. Защита информации от несанкционированного доступа должна быть реализована с использованием следующих механизмов:

1. Ограничениями прав доступа на уровне платформы 1С:Предприятие 8.1.

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

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

5.1.4.2.Защита информации на уровне платформы

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

· Все права доступа должны быть систематизированы в соответствующие наборы – Роли информационной системы.

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

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

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

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

5.1.4.3. Защита информации на уровне среды исполнения

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

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

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

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

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

5.1.6.2.Терминология, используемая для обозначения объектов и действий пользователей в системе должна соответствовать стандартной терминологии предметной области.

5.2.Требования к структуре и функционированию АС «СБЫТ».

5.2.1. АС «СБЫТ» должна состоять из следующих автоматизированных подсистем:

— Подсистема ввода первичной информации об абоненте (заключения договора);

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

— Подсистема связи с системой АСКУЭ;

— Подсистема связи с платежными терминалами.

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

— Документ «Договор с абонентом»;

5.2.3. Состав Подсистемы формирования документов на оплату должен быть следующим:

— Документ «Начисление штрафных санкций»

— Документ «Потребленная энергия»

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

5.2.4. Состав Подсистемы связи с системой АСКУЭ должен быть следующим:

— модуль Связь с системой АСКУЭ.

5.2.5. Состав Подсистемы связи с платежными терминалами должен быть следующим:

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

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

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

— Ввод и хранение информации об установленной мощности контрагента (в дальнейшем абонента);

— Ввод и хранение информации об установленных счетчиках абонента;

— Ввод и хранение информации о тарифах абонента;

— Ввод и хранение информации о условиях начисления штрафных санкций абонента;

— Ввод и хранение информации о сроках действия договора;

5.4. Требования к функциям Подсистемы формирования документов на оплату

5.4.1. Подсистема формирования платежных документов должна выполнять следующие функции:

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

— Формирование документов на оплату (квитанций или счетов на оплату).

5.5. Требования к функциям Подсистемы связи с системой АСКУЭ

5.5.1. Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:

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

5.6.1. Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:

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

6.1.Устанавливается следующий порядок предъявления и сдачи Заказчику результатов работ:

6.1.1. Исполнитель демонстрирует работоспособность ПО на контрольном примере.

6.1.2. Данные для контрольного примера готовят представители Заказчика.

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

6.1.4. По результатам решения контрольного примера должен быть подготовлен Акт о передаче ПО в опытную эксплуатацию.

6.1.5. В случае несоответствия функциональных возможностей ПО требованиям ТЗ Исполнитель выполняет устранение замечаний в рамках общей стоимости разработки АС.

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

6.1.7. Наличие дополнительных требований Заказчика не должно являться основанием отказа от подписания Акта о передаче ПО в опытную эксплуатацию.

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

6.1.9. При внедрении ПО (опытной эксплуатации) Заказчик осуществляет:

— ввод необходимой НСИ;

— ввод фактических данных;

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

6.1.10. В процессе внедрения Исполнитель должен оказывать помощь Заказчику в рамках Графика внедрения.

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

6.2.Порядок дальнейшего сопровождения задач АС «СБЫТ».

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

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

6.2.2. Исполнитель обязуется поддерживать телефонную «горячую линию» по сопровождению программного обеспечения.

6.2.3. По желанию Заказчика, Исполнитель может осуществлять сопровождение программного обеспечения непосредственно у Заказчика, которое должно производиться на основании дополнительного договора по сопровождению ПО.

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

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

6.2.5. Заказчик, в течении года после покупки 1С: Предприятие, имеет право на бесплатное получение всех обновлений от фирмы 1С, связанное с развитием программ 1С и изменением законодательства. Установка изменений должна производиться силами АСУ Заказчика.

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

Технический проект:

УТВЕРЖДАЮ ПРЕДСТАВЛЯЮ НА УТВЕРЖДЕНИЕ

» «______________ 2010 г. » «_______________ 2010 г.

Приложение к техническому заданию от «____» ________ 2010

Автоматизированная

система «СБЫТ».

Технический проект

Действует с «__» ____________ 2010 г.

Варианты штрафных санкций. 3

Регистры сведений. 4

Значение Тарифов. 4

Тарифы абонентов. 4

Регистры накопления. 5

Потребление энергии. 5

Договор с абонентом.. 6

Потребленная Энергия. 6

Начисление штрафных санкций. 9

Получение данных из системы АСКУЭ. 10

Получение данных из платежной системы.. 11

Справочники

Счетчики

Справочник «Договоры Контрагентов»

Хранение информации о счетчиках абонентов

Реквизиты:

Адрес установки счетчика

Признак трех фазного счетчика

Признак двухтарифного счетчика

Тарифы

Назначение

Хранение информации о типах тарифов системы

Реквизиты: нет

Подстанции

Назначение

Хранение информации о подстанциях для связи с системой АСКУЭ

Реквизиты: нет

Варианты штрафных санкций

Назначение

Хранение вариантов начисления штрафов и пеней

Реквизиты: нет

Перечисления

Виды начислений

Значения:

По показаниям счетчика

Начисление оплаты по показаниям счетчика

По установленной мощности

Начисление оплаты по установленной мощности

Регистры сведений

Сроки действия договоров

Назначение: Предназначен для хранения сроков действия договоров с абонентами

Справочники Договор Контрагента

Ссылка на договор абонента

Дата начала действия договора

Дата окончания действия договора

Значение Тарифов

Назначение: Предназначен для хранения тарифов и дат, с которых тарифы начинают действовать их действия

Ссылка на организацию

Стоимость дневного тарифа

Стоимость ночного тарифа (может быть не задан)

Тарифы абонентов

Назначение: Предназначен для хранения тарифов назначенных абоненту согласно договорам

Справочник Договоры контрагентов

Ссылка на договор с абонентом

Ссылка на номенклатуру с типом «Услуга» для учета взаиморасчетов с контрагентом

Ссылка на организацию

ПоказанияСчетчиков

Назначение: Предназначен для хранения показаний счетчиков для последующего начисления оплаты

Ссылка на счетчик абонента

Ссылка на организацию

Регистры накопления

Потребление энергии

Назначение: Предназначен для хранения информации о потреблении энергии для последующего начисления оплаты

Тип регистра: оборотный

Ссылка на счетчик абонента

Ссылка на организацию

Документы

Договор с абонентом

Назначение: Предназначен для отражения факта заключения договора с абонентом

Ссылка на абонента

Справочник Договоры контрагентов

Ссылка на договор с абонентом

Тариф абонента согласно договора

Хранение установленной мощности абонента в КВТ

Дата с которой действует договор

Дата окончания действия договора

Ссылка на собственное юридическое лицо

Справочник Варианты Начисления штрафных санкций

Ссылка на вариант начисления штрафов и пеней согласно договора

Ссылка на номенклатуру с типом «Услуга» для учета взаиморасчетов с контрагентом

Признак ручной корректировки проводок документа

Табличная часть: Счетчики и Тарифы

Ссылка на счетчик абонента

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

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

Проведение документа

— по регистру сведений «Показания счетчиков» куда прописывает счетчики абонента и начальные показания счетчиков;

— по регистру сведений «Тарифы абонентов» куда прописывает тариф установленный абоненту с даты начала действия договора

Потребленная Энергия

Назначение: Предназначен для отражения показаний счетчиков на определенную дату

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «Получение данных из системы АСКУЭ»

Ссылка на собственное юридическое лицо

Ссылка на подстанцию для связи с системой АСКУЭ

Признак ручной корректировки проводок документа

Табличная часть: Показания счетчиков

Ссылка на счетчик абонента

Проведение документа

— по регистру сведений «Показания счетчиков» куда прописывает показания счетчиков на дату документа;

— по регистру накоплений «Потребленная энергия по следующему алгоритму:

1. Берутся показания счетчиков из регистра сведений «Показания счетчиков» на дату документа и предыдущее значения показания счетчиков.

2. Разницы значений показаний заносятся в соответствующие ресурсы регистра накопления.

Печатные формы

Реестр показаний счетчиков

Квитанция

Назначение: Предназначен для отражения начислений абонентам

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление оплаты»

Ссылка на собственное юридическое лицо

Признак ручной корректировки проводок документа

Табличная часть: Показания счетчиков

Ссылка на абонента

Справочник Договоры контрагентов

Ссылка на договор с абонентом

Ссылка на номенклатуру с типом «Услуга» для учета взаиморасчетов с контрагентом

Тариф абонента согласно договора

Ссылка на счетчик абонента

Ссылка на вид начисления (по показания счетчика или по установленной мощности)

Значение тарифа на дату документа

Сумма начисленная абоненту

Проведение документа

— по плану счетов хозрасчетный :

— по плану счетов налоговый :

Печатные формы

Квитанция на оплату со штрих кодом

Штрих-код формируется при помощи шрифта «Infograftbarcode»

Алгоритм формирования Строка «0000»+Код договора абонента+Начислено

Макет квитанции прилагается в файле КВ_1.mxl

Алгоритм заполнения

Алгоритм проведения

Для каждой строки табличной части «Показания счетчиков» должны быть сделаны следующие проводки:

Кт. 90.01 с аналитикой СубконтоКт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоКт2 – Номенклатура.СтавкаНДС.

Сумма проводки – значение реквизита «Начислено»;

Если есть Кредитовое сальдо По счету 62.02, то проводится зачет аванса с проводкой

Сумма проводки – минимальное значение из кредитового сальдо по счету 62.02 и значения реквизита «начислено»)

Дт. 90.03 с аналитикой СубконтоДт1 – Номенклатура.НоменклатурнаяГруппа, СубконтоДт2 – Номенклатура.СтавкаНДС

Начисление штрафных санкций

Назначение: Предназначен для отражения начислений штрафов абонентам

Заполнение документа

Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление штрафов »

Ссылка на собственное юридическое лицо

Справочник Прочие доходы и Расходы

Ссылка на статью прочих доходов

Признак ручной корректировки проводок документа

Табличная часть: Показания счетчиков

Ссылка на абонента

Справочник Договоры контрагентов

Ссылка на договор с абонентом

Справочник Варианты Начисления штрафных санкций

Ссылка на вариант начисления штрафов и пеней согласно договора

Сумма начисленная абоненту

Проведение документа

— по плану счетов хозрасчетный :

— по плану счетов налоговый :

Печатные формы

Квитанция на оплату со штрих кодом

Штрих-код формируется при помощи шрифта «Infograftbarcode»

Алгоритм формирования Строка «0000»+Код договора абонента+Начислено

Макет квитанции прилагается в файле КВ_1.mxl

Алгоритм проведения

Для каждой строки табличной части «Показания счетчиков» должны быть сделаны следующие проводки:

Кт. 91.01 с аналитикой СубконтоКт1 – Прочие доходы.

Сумма проводки – значение реквизита «Начислено»;

Источник

Порядок планирования разработок ПО

Обновим 1С с гарантией сохранности базы

Поможем с 1С 24/7, без выходных

Установим сервисы 1С бесплатно

Оперативно решим любые задачи по 1С

Порядок планирования разработок/доработок программного обеспечения

1. Общие положения.

1.1. Назначение документа.

Настоящий документ описывает порядок формирования плана разработок/доработок программного обеспечения в интересах Общества.

Участниками выполнения данного документа являются:

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

1.2. Термины и определения.

Термины, определения и сокращения, используемые в настоящем документе:

1.2.1. Общество – ООО «12 ИСТОРИЙ».

1.2.2. ПО – программное обеспечение.

1.2.3. ТЗ – техническое задание.

1.2.4. ЭПС – электронная почтовая система.

2. Порядок планирования разработок/доработок программного обеспечения.

2.1. Формирование ТЗ.

С целью повышения эффективности деятельности Общества путем улучшения и автоматизации бизнес процессов, повышения производительности труда, сотрудники ИТ выполняют работы по разработке ПО.

Разработка ПО выполняется на основании ТЗ, согласованного Руководителем процесса разработки и утвержденного руководителем ИТ одела.

Заказчик формирует ТЗ в соответствии с формой технического задания на разработку и создает задачу в Яндекс.трекере в очередь ODINSDEV.

К ТЗ предъявляются следующие требования:

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

Согласование Руководителем процесса разработки ТЗ на доработку/разработку ПО.

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

2.2. Планирование разработки.

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

1) круг специалистов, входящих в группу тестирования и способ тестирования разработанного ПО,

2) перечень этапов и работ, входящих в общий комплекс работ по разработке ПО,

3) ответственного по каждой работе,

4) приоритеты по каждой работе,

5) план возврата к исходному состоянию,

6) потребность в привлечении дополнительных ресурсов.

7) контрольные точки.

В случае необходимости привлечения дополнительных ресурсов Руководитель процесса разработки согласовывает их с руководителем ИТ отдела. Принимается решение о целесообразности привлечения дополнительных ресурсов.

2.3. Формирование графика выполнения работ.

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

На основе этих данных Руководитель процесса разработки составляет график выполнения работ по разработке ПО.

2.4. Ознакомление исполнителей с планом-графиком работ.

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

3. Порядок корректировки плана разработок.

Корректировка плана разработок производится в следующих случаях:

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

4. Порядок приемки разработок.

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

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

ФОРМА

ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ/ДОРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

В данном пункте необходимо указать:

-наименование программного обеспечения (1С: Документооборот, 1С: КА, 1С: БП, 1С: ЗУП),

-наименование подразделения Заказчика,

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

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

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

2. Экономическое обоснование.

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

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

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

В данном пункте нужно указать:

— режим функционирования программного обеспечения и персонала его использующего (24*7, 8*5 и т.д.),

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

— требуется ли дополнительная защита информации или ограничения прав доступа,

В данном пункте можно дополнительно указать:

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

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

В данном пункте нужно указать:

— перечень функций, задач, подлежащих автоматизации,

— необходимость создания дополнительных групп, ролей,

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

— реакцию ПО на неверные действия пользователя,

— общую схему работы ПО,

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

3.3. Порядок приемки.

В данном разделе можно указать:

— программа и методика испытаний программного обеспечения,

— группу, на которой будет проводиться тестирование,

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

ПРИМЕР

ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ/ДОРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Наименование программного обеспечения: 1С: УПП

Наименование подразделения Заказчика: Управление по закупкам и логистике

Вид задачи: разработка

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

Цели, которые будут достигнуты в результате разработки программного обеспечения: повышение эффективности работы сотрудников Розницы

2. Экономическое обоснование.

Сокращение времени на формирование отчета

ПШЕ (общее) =525/1970=0,266

Из расчета формирования отчета в среднем 2 раза в сутки

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

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

Режим функционирования программного обеспечения и персонала его использующего: 24*7

Порядок подготовки персонала (требуется ли разработка инструкций, памяток и т.д.): требуется разработка инструкции для пользователя по работе с функционалом

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

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

Документ «Телефонный справочник»

Вывод в виде отчета списка «Активных» номеров с ФИО, должностью и E-mail (при наличии в карточке сотрудника). Выводятся только записи из карточек номеров с выбранным полем «Отображать в справочнике номеров». Доступ: Доступно для всех.

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

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

3.3. Порядок приемки.

Группа, на которой будет проводиться тестирование: Тестирование функционала будет производить сотрудник розницы Иванов И.И.

Место и способы размещения подготовленной документации: документация должна быть предоставлена по ЭПС ведущему специалисту по закупкам Иванову И.И., а также размещена в Confluence в разделе Инструкции

Источник