Базовая версия
2026-03-20T18:37:01+00:00
НИЯУ МИФИ
Программные требования
низкого уровня
к системе управления требованиями
Москва, 2026
Команда №3
Ссылки
Системные требования.
План разработки ПО.
Стандарт на разработку требований к ПО.
Программные требования (высокого уровня).
Принятые соглашения
Формат идентификаторов LLR: LLR_<Component><UseCase>[_<NN>]
Тип: Б (backend), Ф (frontend).
1. Требования связанные с регистрацией и авторизацией
Ссылается на: Программные требования (высокого уровня) раздел 3, Таблица1. Требования к процессу регистрации и Таблица 2. Требования к процессу авторизации
Название компонента: Component_AuthService
LLR_AuthService_RegisterClient
Название: Поля регистрации на стороне UI
Описание: Компонент UI регистрации должен формировать http запрос для отправки на сервер, в котором payload содержит следующие поля: first_name, last_name, login, email, password, password_repeat, is_admin.
Основание: DER-REQ-1-001; DER-REQ-1-003.
Тип: Ф
LLR_AuthService_RegisterClient_FormatValidation
Название: Проверка заполнения формы регистрации на стороне UI
Описание: Компонент регистрации UI должен блокировать отправку формы, если хотя бы одно обязательное поле пустое.
Основание: DER-REQ-1-003.
Тип: Ф
LLR_AuthService_RegisterServer_01
Название: Проверка заполнения формы регистрации на сервере
Описание: Перед сохранением пользователя или добавлением учетной записи пользователя функция register_user(payload: dict) должна проверять входные данные по правилам: (1) first_name, last_name — только кириллица, (2) email — корректный формат, (3) password == password_repeat, (4) login уникален. При нарушении любого правила функция должна прекращать операцию и возвращать ERR_FORMAT_VALIDATION с полями: field, message.
Основание: DER-REQ-1-002.
Тип: Б
LLR_AuthService_RegisterServer_02
Название: Проверка уникальности логина при регистрации
Описание: Перед вставкой записи функция register_user принимающая на вход данные необходимые для регистрации в формате “ключ” - “значение” должна выполнить запрос в БД на существование пользователя со значением поля login идентичным тому, которое было передано в register_user в качестве входных данных . При обнаружении дублирования операция должна быть прекращена с возвратом ERR_CONFLICT(code='DUPLICATE_LOGIN').
Основание: DER-REQ-1-002.
Тип: Б
LLR_AuthService_RegisterServer_03
Название: Сохранение пользователя в базе данных
Описание: При успешной валидации register_user() должна создать в БД в таблице users новую запись с информацией о зарегистрировавшимся пользователе и вернуть user_id. Операция записи должна выполняться в транзакции со следующими шагами: начало транзакции, проверка отсутствия уже созданной записи с такими данными(проверка по логину), выполнение операции вставки, завершение транзакции в случае, если нет ошибок. При ошибке транзакция должна быть отменена, а изменения не сохранены и возвращён ERR_CONFLICT.
Основание: DER-REQ-1-004.
Тип: Б
LLR_AuthService_RegisterServer_04
Название: Отправка уведомления с подтверждением email
Описание: После успешного создания пользователя register_user() должна инициировать отправку письма на email, содержащего ссылку подтверждения с токеном вида confirm_email_token. Токен должен сохраняться в БД с временем истечения 300 секунд и булевым флагом использования со значением False.
Основание: DER-REQ-1-005.
Тип: Б
LLR_AuthService_ConfirmEmail
Название: Обработка подтверждения email
Описание: Функция confirm_email(string_of_confirmation: str), принимающая на вход токен в виде строки для подтверждения адреса электронной почты, должна: (1) проверить существование токена, (2) проверить срок действия, (3) проверить что токен не был использован, (4) установить пользователю признак email_confirmed=true, (5) пометить токен использованным(изменить значение булевого флага использования с False на True). При повторных переходах по ссылке проверить email_confirmed=true. При ошибке проверки возвращать ERR_VALIDATION(code='INVALID_TOKEN'). Функция вызывается при входе пользователя в систему с помощью ссылки, полученной им на электронную почту при регистрации. При переходе по ссылке формируется http запрос для отправки на сервер, содержащий токен.
Основание: DER-REQ-1-006.
Тип: Б
LLR_AuthService_RegisterServer_05
Название: Назначение прав администратора по флагу
Описание: Если во входных данных для функции register_user полю is_admin соответствует значение True, то функция register_user должна назначить пользователю роль администратора (минимум на уровне системы или первого проекта по принятой модели) и сохранить это назначение в БД. При ошибке назначения роли возвращать ERR_CONFLICT(code='ROLE_ASSIGN_FAILED').
Основание: DER-REQ-1-007.
Тип: Б
LLR_AuthService_LoginClient
Название: Поля авторизации на стороне UI
Описание: Компонент UI авторизации должен предоставлять кнопки «Вход» и «Регистрация». При нажатии на кнопку «Вход» на сервер должен отправляться http запрос содержащий поля login и password. При нажатии на кнопку «Регистрация» должен выполняться переход на экран регистрации.
Основание: DER-REQ-2-001; DER-REQ-2-002; DER-REQ-2-005.
Тип: Ф
LLR_AuthService_LoginServer
Название: Проверка учётных данных при входе
Описание: Функция login_user(login: str, password: str) должна выполнить запрос в БД в таблицу users для поиска записи, в которой login совпадает с тем, который был передан на вход функции. После этого должна инициироваться проверка корректности пароля через сравнение хеша. В случае успеха функция должна вернуть session_token (или JWT) и user_id, в противном случае — ERR_UNAUTHORIZED.
Основание: DER-REQ-2-003; DER-REQ-2-004.
Тип: Б
2. Требования связанные с изменением данных личного кабинета
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 3. Требования к процессу изменения данных личного кабинета
Название компонента: Component_ProfileService
LLR_ProfileService_View
Название: Отображение данных профиля и уведомлений
Описание: UI личного кабинета должен отображать права пользователя и список уведомлений об изменениях артефактов с ссылками на соответствующие сущности. UI должен отображать поля: first_name, last_name, login, email.
Основание: DER-REQ-3-001; DER-REQ-3-002.
Тип: Ф
LLR_ProfileService_Edit
Название: Редактируемость полей профиля
Описание: UI должен разрешать редактирование только полей first_name, last_name, email, поле login должно быть read-only. UI должен отображать кнопку «Сохранить», при нажатии на которую будет вызвана функция update_profile, на вход которой подаются данные из полей first_name, last_name, email, login в формате “ключ” - “значение”.
Основание: DER-REQ-3-003; DER-REQ-3-004.
Тип: Ф
LLR_ProfileService_SaveButton
Название: Логика активности кнопки «Сохранить»
Описание: UI должен делать кнопку «Сохранить» неактивной, если пользователь не изменил ни одно из полей first_name, last_name, email. UI должен делать кнопку активной, если изменено хотя бы одно из этих полей.
Основание: DER-REQ-3-005; DER-REQ-3-006.
Тип: Ф
LLR_ProfileService_EditValidation
Название: Проверка корректности полей профиля при сохранении
Описание: Перед отправкой изменений UI должен валидировать: first_name, last_name — только кириллица, email — корректный формат. При ошибке валидации UI должен отображать сообщение и не отправлять запрос.
Основание: DER-REQ-3-007.
Тип: Ф
LLR_ProfileService_Update
Название: Сохранение изменений профиля в БД
Описание: Функция update_profile(user_id: str, patch: dict) должна обновлять в БД только разрешённые поля (first_name, last_name, email) и отклонять попытки обновления login с ERR_FORBIDDEN(code='FIELD_IMMUTABLE'). Обновление должно выполняться транзакционно.
Основание: DER-REQ-3-008; DER-REQ-3-003.
Тип: Б
LLR_ProfileService_AdminZoneButton
Название: Отображение кнопки «Настройки проектов»
Описание: UI должен отображать кнопку «Настройки проектов» только если сервер в профиле пользователя возвращает признак наличия доступа к админ-зоне (has_project_admin_access=true).
Основание: DER-REQ-3-009.
Тип: Ф
3. Требования к администрированию проекта
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 4. Требования к администрированию проекта
Название компонента: Component_AdminService
LLR_AdminService_Tabs
Название: Вкладки администрирования
Описание: UI администрирования должен отображать вкладки: «Проекты», «Пользователи проекта», «Роли и функции», «Управление артефактами», «Журнал действий».
Основание: DER-REQ-4-001.
Тип: Ф
LLR_AdminService_CreateProjectButton
Название: Видимость кнопки «Создать проект»
Описание: UI должен отображать кнопку «Создать проект» только пользователям, у которых сервер возвращает право администрирования ( permission project.create).
Основание:REQ_SW-4-002.
Тип: Ф
LLR_AdminService_CreateProject
Название: Создание проекта и артефакта «Проект»
Описание: Функция create_project(user_id: str, name: str, description: str) должна: (1) создать запись проекта, (2) создать артефакт типа «Проект», (3) связать артефакт с проектом, (4) вернуть идентификатор проекта. После создания изменение описания проекта должно выполняться через update_project_description(project_id, description).
Основание: REQ_SW-4-003.
Тип: Б
LLR_AdminService_ProjectMembersTable
Название: Таблица пользователей проекта (структура)
Описание: Функция list_project_members(project_id: str) должна возвращать список строк с полями: full_name, login, email, roles, status. UI должен отображать кнопки «Добавить» и «Удалить» только для администратора проекта.
Основание: REQ_SW-4-004.
Тип: Б
LLR_AdminService_AddRemoveMember
Название: Добавление и удаление пользователей проекта
Описание: Функция add_project_member(project_id: str, actor_id: str, target_user_id: str, roles: list) должна добавлять пользователя в проект и назначать роли. Функция remove_project_member(project_id: str, actor_id: str, target_user_id: str) должна удалять пользователя из проекта; обе операции должны записывать событие в audit_log.
Основание: REQ_SW-4-004; REQ_SW-4-007.
Тип: Б
LLR_AdminService_SetPermissions
Название: Отметка разрешённых действий
Описание: Функция set_member_permissions(project_id: str, actor_id: str, target_user_id: str, permissions: list) должна сохранять список разрешённых функций пользователя в проекте, которые задаются администратором в виде списка. При попытке изменения прав без прав администратора проекта возвращать ERR_FORBIDDEN.
Основание: REQ_SW-4-005.
Тип: Б
LLR_AdminService_CustomAttrEditor
Название: Редактор пользовательских атрибутов артефактов
Описание: Функции create_custom_attribute(project_id, artifact_type, attr_type, field_key, comment), update_custom_attribute(attr_id, patch), delete_custom_attribute(attr_id) должны управлять атрибутами и возвращать ERR_CONFLICT(code='DUPLICATE_ATTRIBUTE') при дубле field_key в пределах (project_id, artifact_type).
Основание: REQ_SW-4-006.
Тип: Б
LLR_AdminService_AuditLog_Record
Название: Журналирование действий пользователей
Описание: Компонент должен записывать в audit_log все действия, влияющие на состояние артефактов: создание/изменение/удаление, изменение версии, изменение трассировки, участие в ЗИ и ФИ, создание СП. Запись журнала должна включать: timestamp_utc, actor_user_id, action_type, entity_type, entity_id, project_id.
Основание: REQ_SW-4-007.
Тип: Б
LLR_AdminService_AuditLog_Filter
Название: Фильтрация журнала действий
Описание: Функция query_audit_log(project_id: str, user_id: str, action_type: str, artifact_id: str, date_from: datetime, date_to: datetime) должна возвращать отфильтрованные записи с пагинацией.
Основание: DER-REQ-4-002.
Тип: Б
4. Требования к процессу управления проектами
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 5. Требования к процессу управления проектами
Название компонента: Component_ProjectService
LLR_ProjectService_OpenDescription
Название: Открытие описания проекта
Описание: При клике на проект UI должен выполнять запрос get_project(project_id) и отображать описание проекта. Сервер должен возвращать ERR_FORBIDDEN, если проект недоступен текущему пользователю.
Основание: DER-REQ-5-003.
Тип: Б
LLR_ProjectService_ConfigState
Название: Загрузка состояния конфигурации проекта
Описание: Функция get_project_config_state(project_id: str) должна возвращать агрегированные значения: количество артефактов по типам, статистику ЗИ, открытые СП, список несоответствий, протоколы и список ФИ.
Основание: REQ_SW-5-004.
Тип: Б
5. Требования к управлению артефактами и трассировочными ссылками.
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 6. Требования к управлению артефактами и трассировочными ссылками.
Название компонента: Component_ArtifactService
LLR_ArtifactService_FilterPanel
Название: Панель фильтров и поиска артефактов
Описание: UI раздела «Артефакты» должен предоставлять фильтры: artifact_type, status, author, version, custom_attributes, а также поиск по title и description. При загрузке раздела UI должен применять текущие значения фильтров и отображать отфильтрованный список.
Основание: REQ_SW-6-001.
Тип: Ф
LLR_ArtifactService_ListArtifacts
Название: Возврат таблицы артефактов проекта
Описание: Функция list_artifacts(project_id: str, filters: dict, search: str) должна возвращать строки с полями: artifact_type, external_id, title, baseline_version, has_working_version, lifecycle_status.
Основание: REQ_SW-6-002.
Тип: Б
LLR_ArtifactService_RowActions
Название: Действия в строке таблицы артефактов
Описание: UI должен отображать действия: «Посмотреть подробнее», «История версий», «Посмотреть трассировку», «Создать ЗИ», «Удалить». UI должен скрывать действие «Создать ЗИ», если сервер не возвращает право на создание ЗИ для пользователя. При нажатии на кнопку «Посмотреть подробнее» должна вызываться функция get_artifact_card. При нажатии на кнопку «История версий» должна вызываться функция get_artifact_versions. При нажатии на кнопку «Посмотреть трассировку» должна вызываться функция get_traceability_table. При нажатии на кнопку «Создать ЗИ» должна вызываться функция create_change_request. При нажатии на кнопку «Удалить» для базовой версии артефакта должна вызываться функция create_change_request, а для рабочей версии артефакта должна вызываться функция delete_artifact.
Основание: REQ_SW-6-003.
Тип: Ф
LLR_ArtifactService_ViewCard
Название: Карточка артефакта (состав данных)
Описание: Функция get_artifact_card(artifact_id: str, user_id: str) должна возвращать: данные базовой версии, данные рабочей версии (если есть), значения пользовательских атрибутов, а также список трассировочных связей.
Основание: REQ_SW-6-005.
Тип: Б
LLR_ArtifactService_ViewVersions
Название: История версий артефакта
Описание: Функция get_artifact_versions(artifact_id: str, user_id: str) должна возвращать данные из таблицы artifact_versions в БД находя запись с artifact_id идентичным artifact_id во входных данных функции.
Основание: REQ_SW-6-003.
Тип: Б
LLR_ArtifactService_CreatePermission
Название: Видимость кнопки «Создать артефакт»
Описание: UI должен отображать кнопку «Создать артефакт» только пользователям, которым администратор дал право создавать конкретный тип артефакта. Проверка должна выполняться по правам, полученным от сервера (can_create_types).
Основание: REQ_SW-6-006.
Тип: Ф
LLR_ArtifactService_CreateArtifact
Название: Создание артефакта с внутренним и внешним ID и рабочей версией
Описание: Функция create_artifact(project_id: str, user_id: str, artifact_type: str, title: str, description: str, custom_attrs: dict) должна в рамках одной транзакции: (1) проверить право создания данного типа, (2) сгенерировать уникальный internal_id (UUIDv4), (3) сгенерировать external_id по активному шаблону (проверка уникальности), (4) создать запись в artifacts (status='ACTIVE', deleted_flag=False, created_by=user_id), (5) создать запись в artifact_versions (version_kind='working', content=description, author_id=user_id), (6) сохранить custom_attrs. При конфликте external_id возвращать ERR_CONFLICT(code='EXTERNAL_ID_CONFLICT'). При ошибке прав - ERR_PERMISSION. При любой ошибке выполнять ROLLBACK.
Основание: REQ_SW-6-006.
Тип: Б
LLR_ArtifactService_DeleteArtifact
Название: Удаление рабочей версии артефакта
Описание: Функция delete_artifact(internal_id: str, user_id: str) должна в рамках одной транзакции: (1) найти артефакт по internal_id (проверка существования и deleted_flag=False), (2) проверить право удаления данного артефакта, (3) изменить запись в artifact_versions установив version_kind='archived', (4) установить deleted_flag=True в таблице artifacts, (5) зафиксировать изменения. При отсутствии прав возвращать ERR_PERMISSION. При отсутствии артефакта - ERR_NOT_FOUND. При уже удаленном артефакте - ERR_ALREADY_DELETED. При любой ошибке выполнять ROLLBACK.
Основание: REQ_SW-6-003.
Тип: Б
LLR_TraceLinkService_ViewTraceTable
Название: Таблица трассировки артефакта
Описание: Функция get_traceability_table(artifact_id: str, version_id: str) должна возвращать входящие и исходящие связи, каждая связь должна содержать: link_type, related_artifact_type, related_external_id, related_title, related_version.
Основание: REQ_SW-6-007.
Тип: Б
6. Требования к процессу управления версиями артефактов и ЗИ
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 7. Требования к процессу управления версиями артефактов и ЗИ.
Название компонент: Component_ChangeRequestService, Component_VersioningService
LLR_ChangeRequestService_ListCR
Название: Список ЗИ по проекту или выбранному артефакту
Описание: UI ЗИ должен отображать список запросов на изменение, связанных с текущим проектом или выбранным артефактом. Серверная функция list_change_requests(project_id: str, artifact_id: str) должна: (1) проверить право пользователя на просмотр ЗИ в проекте, (2) выбрать записи из change_requests соответствующие переданному в функцию project_id, (3) выбрать среди полученных записей только те, в которых artifact_id идентично переданному на вход функции artifact_id (4) отсортировать результаты по убыванию даты создания, (5) вернуть список объектов с основными полями. При отсутствии прав возвращать ERR_PERMISSION. При невалидном project_id — ERR_NOT_FOUND. Пустой результат возвращать как пустой массив.
Основание: REQ_SW-7-001.
Тип: Б
LLR_ChangeRequestService_HistoryTable
Название: Таблица истории ЗИ для артефакта
Описание: UI должен отображать таблицу истории ЗИ, созданных для выбранного артефакта. Сервер должен возвращать поля минимум: cr_id, status, created_at, author, goal.
Основание: REQ_SW-7-002.
Тип: Б
LLR_ChangeRequestService_CreateCR
Название: Создание ЗИ с обязательными атрибутами
Описание: Функция create_change_request(project_id: str, author_id: str, justification: str, goal: str, affected_artifact_ids: list[str], planned_changes: str, assignee_ids: list[str]) должна создавать ЗИ и валидировать непустоту обязательных полей justification, goal, affected_artifact_ids. При отсутствии любого из обязательных полей возвращать ERR_VALIDATION(code='MISSING_REQUIRED_FIELD', field=...).
Основание: REQ_SW-7-003.
Тип: Б
LLR_VersioningService_SaveWorkingVersion
Название: Создание новой рабочей версии артевакта при сохранении изменений
Описание: Функция save_artifact_content(artifact_id: str, user_id: str, content: dict, custom_attrs: dict) должна создавать новую рабочую версию артефакта с фиксацией автора, времени, содержимого и значений пользовательских атрибутов. Операция должна сохранять историю версий и не перезаписывать существующую версию «на месте».
Основание: REQ_SW-7-004.
Тип: Б
LLR_ChangeRequestService_ReadyForFI
Название: Кнопка «Готово к ФИ»
Описание: Функция mark_ready_for_fi(cr_id: str, user_id: str) должна установить ЗИ статус «Ожидает ФИ» в таблице change_requests у запроса с cr_id идентичным тому, который передан на вход функции
Основание: DER-REQ-7-001.
Тип: Б
7. Требования к процессу ФИ
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 8. Требования к процессу ФИ
Название компонент: Component_FormalInspectionService , Component_ProblemReportService
LLR_FormalInspectionService_List
Название: Список ФИ и состав полей
Описание: UI ФИ должен отображать список ФИ с полями: protocol_id, status, date, participants, artifact_links, change_request_description. Серверная функция list_formal_inspections(project_id: str) должна возвращать эти поля.
Основание: REQ_SW-8-001.
Тип: Б
LLR_FormalInspectionService_Details
Название: Детали выбранной ФИ
Описание: Функция get_fi_details(fi_id: str) должна возвращать: изменённые артефакты и версии, список несоответствий, СП (если создавалось), id протокола, комментарий, итоговое решение.
Основание: REQ_SW-8-002.
Тип: Б
LLR_FormalInspectionService_NavigateFromNotification
Название: Переход ведущего из уведомления к подготовке ФИ
Описание: После получения уведомления о готовности ЗИ к ФИ UI должен позволять ведущему перейти по ссылке на ЗИ и открыть экран подготовки ФИ по кнопке «Подготовить ФИ».
Основание: REQ_SW-8-003.
Тип: Ф
LLR_FormalInspectionService_InviteForm
Название: Состав письма-приглашения на ФИ
Описание: UI подготовки ФИ должен обеспечивать заполнение приглашения, включающее: ссылку на ЗИ, список участников и их роли, пользовательские атрибуты, определённые администратором проекта.
Основание: DER-REQ-8-004.
Тип: Ф
LLR_FormalInspectionService_LoadChangedArtifacts
Название: Загрузка данных изменённых артефактов для ведения протокола
Описание: При старте ФИ функция load_fi_scope(cr_id: str) должна загружать изменённые артефакты, их версии и описание изменений и предоставлять участникам с правами возможность ведения протокола.
Основание: REQ_SW-8-005.
Тип: Б
LLR_FormalInspectionService_OpenProtocolPanel
Название: Кнопка «Создать протокол ФИ» открывает панель протокола
Описание: UI должен по нажатию «Создать протокол ФИ» вызывать create_fi_protocol(fi_id: str) и открывать панель ведения протокола ФИ для текущей ФИ.
Основание: DER-REQ-8-006.
Тип: Ф
LLR_FormalInspectionService_SaveProtocolOnDecision
Название: Сохранение протокола при принятии/отклонении ФИ
Описание: Функция decide_fi(protocol_id: str, decision: str, user_id: str) должна сохранять протокол ФИ с: перечнем проверенных ЕК из ЗИ и их версий, списком несоответствий, ссылками на СП (если возникли), итоговым решением, датой и участниками.
Основание: REQ_SW-8-007.
Тип: Б
LLR_FormalInspectionService_BaselineGate
Название: Запрет создания базовой версии при «открыто»/«не устранено»
Описание: При decision='Принято' функция decide_fi() должна проверять наличие несоответствий по артефакту со статусом «открыто» или «не устранено». При наличии таких несоответствий система не должна создавать новую базовую версию ЕК и должна вернуть ERR_STATE_TRANSITION(code='NC_BLOCKS_BASELINE').
Основание: REQ_SW-8-008.
Тип: Б
LLR_FormalInspectionService_CreateBaseline
Название: Создание базовой версии при «устранено»/«заметка»
Описание: При decision='Принято' и при наличии несоответствий только со статусами «устранено» и/или «заметка» функция decide_fi() должна создавать новую базовую версию ЕК в БД.
Основание: REQ_SW-8-009.
Тип: Б
LLR_FormalInspectionService_NotifyAuthor
Название: Уведомление автора и статус ЗИ после решения ФИ
Описание: После нажатия «Отклонить ФИ» или «Принять ФИ» система должна отправить уведомление автору и установить ЗИ статус «Отклонено ФИ» или «Принято ФИ».
Основание: REQ_SW-8-010.
Тип: Б
LLR_FormalInspectionService_NC_Table
Название: Формат таблицы несоответствий в протоколе
Описание: UI протокола ФИ должен отображать несоответствия в виде таблицы с полями: id, reviewed_ci, artifacts, description, status, comment, related_artifacts_and_versions_links. Серверная функция list_nonconformities(protocol_id) должна возвращать данные в этом формате.
Основание: REQ_SW-8-011.
Тип: Б
LLR_ProblemReportService_DecisionHistory
Название: Создание решений по СП и хранение истории
Описание: Функция add_problem_report_decision(pr_id: str, user_id: str, decision_text: str) должна создавать запись решения с обязательными полями: дата, принявший решение, описание решения. Функция list_problem_report_decisions(pr_id) должна возвращать историю решений по СП.
Основание: REQ_SW-8-013.
Тип: Б
LLR_ProblemReportService_Reject
Название: Отклонение СП с уведомлением участников ФИ
Описание: Функция reject_problem_report(pr_id: str, council_user_id: str) должна установить статус «отклонено» и инициировать уведомление участников ФИ.
Основание: REQ_SW-8-014.
Тип: Б
LLR_ProblemReportService_Accept
Название: Принятие СП с уведомлением автора
Описание: Функция accept_problem_report(pr_id: str, council_user_id: str) должна установить статус «принято» и отправить уведомление автору о необходимости внесения изменений в артефакты.
Основание: REQ_SW-8-015.
Тип: Б
LLR_NotificationService_BaselineChanged
Название: Уведомления после создания новой базовой версии
Описание: Функция notify_baseline_created(project_id: str, artifact_ids: list[str], recipients: list[str]) должна создать уведомления в личном кабинете и инициировать отправку email всем пользователям, участвовавшим в создании/изменении ЕК и рассмотрении ЗИ.
Основание: REQ_SW-8-016.
Тип: Б
8. Требования к процессам поиска и фильтрации отчётов
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 9. Требования к процессам поиска, фильтрации, созданию отчётов и их экспорта.
Название компонента: Component_SearchService
LLR_SearchService_ContextSearch
Название: Контекстный поиск в «Артефактах»
Описание: UI должен предоставлять строку контекстного поиска по названию, описанию и значениям пользовательских атрибутов. Серверная функция search_artifacts(project_id: str, query: str) должна предоставлять возможность искать по всем перечисленным полям.
Основание: REQ_SW-9-001.
Тип: Б, Ф
LLR_SearchService_FilterButton
Название: Кнопка «Настроить фильтры»
Описание: UI должен отображать кнопку «Настроить фильтры» рядом со строкой поиска и открывать панель фильтрации.
Основание: DER-REQ-9-002.
Тип: Ф
LLR_SearchService_FilterPanel
Название: Элементы фильтрации артефактов
Описание: При нажатии «Настроить фильтры» UI должен отображать элементы фильтрации по параметрам: тип артефакта, статус, пользователь, пользовательские атрибуты.
Основание: REQ_SW-9-003.
Тип: Ф
LLR_SearchService_ListFiltered
Название: Фильтрация, поиск и пагинация артефактов
Описание: Фукнция list_filtered(filter_criteria : {param : string}, search_query : string, page : int (default = 10) , size : int (default :1)) должна создать спецификацию к БД по параметрам, произвести и вернуть выборку артефактов.
Основание: REQ_SW-9-003.
Тип: Ф
9. Требования к процессу экспорта отчётов
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 9. Требования к процессам поиска, фильтрации, созданию отчётов и их экспорта.
Название компонента: Component_ExportService
LLR_ExportService_ExportScope
Название: Экспорт выбранной спецификации или её части
Описание: Функция export_specification(spec_id: str, section_ids: list[str]|, format: str) должна поддерживать экспорт всей спецификации или выбранной части.
Основание: REQ_SW-9-004
Тип: Б
LLR_ExportService_ExportButtons
Название: Кнопки экспорта PDF/DOCX/CSV
Описание: UI экспорта должен отображать кнопки: «Экспорт в PDF», «Экспорт в DOCX», «Экспорт в CSV». Нажатие кнопки должно вызывать export_specification(..., format=...).
Основание: DER-REQ-9-005.
Тип: Ф
LLR_ExportService_ExportGenerateDownload
Название: Формирование файла и загрузка
Описание: При выборе формата функция export_specification() должна сформировать файл соответствующего формата и вернуть результат так, чтобы клиент мог скачать файл на локальное устройство. При ошибке формирования возвращать ERR_EXPORT_FAILED.
Основание: REQ_SW-9-006.
Тип: Б
10. Требования к процессу установления трассировочных связей между требованиями, кодом и тестами.
Ссылается на: Программные требования (высокого уровня) раздел 3 Таблица 10. Требования к процессу установления трассировочных связей между требованиями, кодом и тестами.
Название компонента: Component_GitHubTraceService
LLR_GitHubTraceService_CodeTabTable
Название: Таблица связей «артефакт—код»
Описание: При открытии вкладки «Код» UI должен отображать таблицу связей для выбранной версии артефакта со столбцами: repository, file, line_range, link_type, commit, comment, branch (по умолчанию main).
Основание: REQ_SW-10-001.
Тип: Ф
LLR_GitHubTraceService_TableActions
Название: Действия «Просмотреть» и «Удалить» в таблице
Описание: UI должен предоставлять действия: (1) «Просмотреть» — для открытия просмотра фрагмента кода, (2) «Удалить» — для удаления связи.
Основание: DER-REQ-10-002.
Тип: Ф
LLR_GitHubTraceService_AddLinkButton
Название: Кнопка «Добавить связь с кодом»
Описание: UI над таблицей должен отображать кнопку «Добавить связь с кодом», которая инициирует создание новой связи для текущей версии артефакта.
Основание: DER-REQ-10-003.
Тип: Ф
LLR_GitHubTraceService_EmptyState
Название: Сообщение при отсутствии связей с кодом
Описание: Если сервер возвращает пустой список связей для версии артефакта, UI должен отображать сообщение «Связи с кодом не заданы».
Основание: REQ_SW-10-004.
Тип: Ф
LLR_GitHubTraceService_VersionIsolation
Название: Изоляция связей по версии артефакта
Описание: Функция list_code_links(artifact_id: str, artifact_version_id: str) должна возвращать только связи выбранной версии. UI при переключении версии должен запрашивать связи заново и не показывать связи другой версии.
Основание: REQ_SW-10-005; REQ_SW-10-006.
Тип: Б, Ф
LLR_GitHubTraceService_ViewSnippet
Название: Просмотр фрагмента кода по сохранённым параметрам связи
Описание: Функция view_code_snippet(code_link_id: str) должна, используя сохранённые параметры связи (repo, path, commit/branch, start_line, end_line), запросить содержимое файла из GitHub и вернуть только указанный диапазон строк. При ошибке обращения к GitHub возвращать ERR_EXTERNAL_SERVICE_UNAVAILABLE.
Основание: REQ_SW-10-007.
Тип: Б
LLR_GitHubTraceService_DeleteLink
Название: Удаление связи «артефакт—код» из БД
Описание: Функция delete_code_link(code_link_id: str, user_id: str) должна удалить запись связи из БД и записать событие в audit_log. При попытке удалить несуществующую связь возвращать ERR_NOT_FOUND.
Основание: REQ_SW-10-008.
Тип: Б
LLR_GitHubTraceService_OpenSelectDialog
Название: Открытие окна «Выбор фрагмента кода»
Описание: При нажатии кнопки «Добавить связь с кодом» UI должен открыть окно «Выбор фрагмента кода», связанное с текущим артефактом и выбранной версией ЕК.
Основание: REQ_SW-10-009.
Тип: Ф
LLR_GitHubTraceService_SelectDialogFields
Название: Состав окна «Выбор фрагмента кода»
Описание: Окно должно содержать: выпадающий список репозиториев, дерево файлов/каталогов, панель просмотра файла с нумерацией строк, поля start_line и end_line, выбор типа связи, поле комментария (опционально).
Основание: DER-REQ-10-010.
Тип: Ф
LLR_GitHubTraceService_SelectDialogVersionInfo
Название: Отображение версии артефакта в окне выбора
Описание: UI окна выбора фрагмента кода должен отображать информацию о версии артефакта, к которой будет привязана выбранная часть кода.
Основание: DER-REQ-10-011.
Тип: Ф
LLR_GitHubTraceService_SelectDialogButtons
Название: Кнопки «Сохранить связь» и «Отмена»
Описание: Окно выбора фрагмента кода должно содержать кнопки «Сохранить связь» и «Отмена». При нажатии «Сохранить связь» UI должен вызвать create_code_link(artifact_version_id, repo, path, start_line, end_line, link_type, comment) и обновить таблицу связей. При нажатии на «Отмена» окно должно быть скрыто.
Основание: DER-REQ-10-012.
Тип: Ф