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

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

Управление статусами помещений Требования: ● В основном справочнике помещений должны быть реализованы статусы: "Виртуальное", "Планируемое", "Действующее". ● Перевод статуса из "Виртуального" в "Планируемое" осуществляется: ○ Вручную, по нажатию кнопки "Перевести в планируемое" из документа Сквозное планирование/инвентаризация вместе с дочерними помещениями если они есть. ○ При смене статуса все данные, введенные на предыдущем этапе, должны быть сохранены, а также актуализированы и дополнены необходимые данные по помещению. Проверка договоров помещений-источников Требования: ● При установке или изменении "Даты начала" действия помещения система должна проверять даты окончания договоров у всех помещений, указанных в поле "Помещения-источники". ● Если дата окончания договора у любого из помещений-источников позже новой "Даты начала", система должна: ○ Вывести сообщение с указанием конкретного помещения-источника и даты окончания его договора. ● Данная проверка должна выполняться при создании нового помещения, изменении его даты начала, при переводе виртуального помещения в планируемое, а также при автоматическом переходе статуса из Планируемого в "Действующее" система должна создавать задание на расторжение действующих договоров у помещений источников. Влияние сдвигов сроков Требования: ● При сдвиге Дата начала аренды у договора (РУДА) на помещение "Планируемое" или "Действующее"-бывшее Планируемое, система должна выдавать предупреждение о необходимости сдвига сроков по данному помещению, дат окончания его предков и дат начала братьев и должна позволять ответственному одной кнопкой перенести даты по всем этим помещениям. ● "Даты начала" или "Даты окончания" у помещения со статусом "Планируемое" или "Действующее" система должна анализировать влияние этого изменения на связанные помещения ("предки" и "дочерние"). ● Пользователь должен получать предупреждение о потенциальных конфликтах и подтверждать изменение. ● Система должна предлагать каскадное применение изменений к связанным объектам. Фиксация согласования коммерческих условий (КУ) Требования: ● После согласования КУ в карточке помещения должна быть возможность зафиксировать факт согласования. ● Для этого в карточке должен быть добавлен реквизит (например, группа полей или отдельная вкладка), содержащий: ○ Дата согласования КУ создания/вывода из ГЛА. ○ Номер протокола совета. ○ Наименование совета (например, "Совет или Форум по Аренде согласованию КУ") ○ Ссылка на Решение по аренде в ДО. ● Эта информация должна быть доступна для просмотра в карточке после сохранения. 

1: Работа с виртуальным помещением Я как пользователь хочу работать с виртуальным помещением, которое является аналогом действующего помещения и никак не влияло на текущие помещения, хочу работать как с одним помещением, но с разными статусами "Виртуальное", "Планируемое" и "действующее". Я как пользователь хочу создавать различные варианты разделения и объединения помещений для выбора оптимального сценария. 2: Просмотр статуса помещения Я как пользователь хочу видеть статус этого помещения. 3: Перевод виртуального помещения в планируемое Я как пользователь хочу, чтобы виртуальное помещение становилось планируемым после ручных действий (Кнопка или другое действие) со всей уже введенной информацией. Также хочу, чтобы всем ответственным приходили задания на актуализацию информации в карте помещения перед переводом его в статус "Планируемое". 4: Влияние сдвигов сроков на связанные помещения Я как пользователь хочу, чтобы при сдвиге сроков в Договоре (РУДА) или в самом помещении (как до, так и после подписания договора) эти сроки влияли на предков и братьев планового или действующего помещения. 5: Проверка договоров помещений-источников Я как пользователь хочу, чтобы на всех этапах была проверка на то, закончится ли договор на помещениях-источниках (предках) к началу действия нового помещения. 6: Фиксация согласования коммерческих условий Я как пользователь хочу, чтобы после согласования КУ (коммерческие условия) в карточке помещения отмечалось, на каком совете и когда было утверждено (На схеме это блок "совет согласовать КУ"). 7. Администрирование карты помещения Я, как администратор базы данных объектов аренды, хочу, чтобы всем ответственным сотрудникам из системы автоматически на определенных этапах уходили задания на необходимые действия, внесение информации, актуализация данных, подготовку рисунков конфигурации помещения и расположение на плане.

1: Работа с виртуальным помещением Критерии приемки: В системе создается запись о помещении со статусом "Виртуальное". Данные виртуального помещения не влияют на учет и отчетность по действующим помещениям. Возможность сценарного планирования и определения основного оптимального по коммерции, срокам и арендаторам сценария. 2: Просмотр статуса помещения Критерии приемки: Статус помещения ("Виртуальное", "Планируемое", "Действующее") отображается в карточке помещения и в общем списке помещений. 3: Перевод виртуального помещения в планируемое Критерии приемки: В карточке виртуального помещения есть кнопка "Перевести в планируемое". Которое появляется там только после согласования на совете КУ. Все данные, введенные для виртуального помещения, полностью переносятся в планируемое и актуализируются ответственными (на предмет номера помещения, даты начала, тех/кадровой информации и рисунка (плана) для договора аренды). 4: Влияние сдвигов сроков на связанные помещения Критерии приемки: При изменении дат начала или окончания действия помещения, а также Даты начала аренды у договора (РУДА) на данное помещение в системе выполняется проверка связанных помещений ("предков" и "братьев"). На братьях также проверяются дата начала аренды в созданных на них договорах (РУДАх) Пользователь получает уведомление о потенциальных конфликтах сроков. Система предлагает варианты для согласования изменений across all related records. 5: Проверка договоров помещений-источников Критерии приемки: При попытке установить дату начала действия для нового помещения система проверяет даты окончания договоров у помещений-источников. Если договор помещения-источника не истекает до начала действия нового выдает предупреждение. Проверка выполняется при создании виртуального помещения, его переводе в планируемое и при любом изменении дат. Также при автоматическом переходе статуса из «Планируемого» в «Действующее» система проверяет действующие договоры на помещениях-источниках и, если находит договоры с пересечением сроков, должна создавать задание ответственным с датами расторжений на расторжение действующих договоров у помещений-источников. 6: Фиксация согласования коммерческих условий Критерии приемки: В карточке помещения появляется раздел/поле "История согласования КУ" с ссылкой в ДО на Решение по аренде. Эта информация становится доступной только для просмотра после сохранения. 7. Администрирование карты помещения Критерии приемки: В карточке помещения техническая возможность строительства проверена и подтверждена, данные своевременно обновлены (номер помещения, даты), заполнена при необходимости информация технического/кадастрового паспорта или данных БТИ, выполнены задания по расторжению на действующие договоры у помещений источников, подготовлены рисунки помещения.

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

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

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

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

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

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

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