Базовая версия
2026-03-20T18:37:01+00:00
НИЯУ МИФИ
Описание проекта ПО
к системе управления требованиями
Команда №3
Москва, 2026
Содержание
1 Введение4
1.1 Назначение4
1.2 Область применения5
1.3 Ссылки5
1.4 Термины, определения и сокращения6
2 Роль документа в жизненном цикле и связь с процессами11
2.1 Связь с процессом разработки и верификации11
2.2 Трассируемость в жизненном цикле12
2.3 Управление конфигурацией12
3 Архитектура системы12
3.1 Назначение и основные функции12
3.2 Архитектурный стиль и развертывание13
3.3 Среда разработки и верификации13
3.4 Основные сущности данных14
4 Структура ПО16
4.1 Компоненты верхнего уровня16
4.2 Соглашения о требованиях НУ и ошибках17
5 Общие проектные решения17
5.1 Идентификация артефактов17
5.2 Версионирование и история изменений17
5.3 Запросы на изменение (ЗИ)17
5.4 Модель данных (логическая)18
5.5 Обработка ошибок и коды ошибок20
6 Подробное описание компонентов22
6.1 Компонент аутентификации (AuthService)22
6.1.1 Назначение компонента22
6.1.2 Основные операции (Backend)22
6.1.3 Требования низкого уровня (LLR)24
6.1.4 Поток управления (ключевые сценарии)25
6.2 Компонент личного кабинета (ProfileService)26
6.2.1 Назначение компонента26
6.2.2 Основные операции (Backend)26
6.2.3 Требования низкого уровня (LLR)27
6.2.4 Поток управления (ключевые сценарии)28
6.3 Компонент администрирования проектов (AdminService)28
6.3.1 Назначение компонента28
6.3.2 Основные операции (Backend)28
6.3.3 Требования низкого уровня (LLR)32
6.3.4 Поток управления (ключевые сценарии)33
6.4 Компонент работы с проектами (ProjectService)33
6.4.1 Назначение компонента33
6.4.2 Основные операции (Backend)33
6.4.3 Требования низкого уровня (LLR)34
6.4.4 Поток управления (ключевые сценарии)35
6.5 Компонент управления артефактами и версиями (ArtifactService)35
6.5.1 Назначение компонента35
6.5.2 Основные операции (Backend)35
6.5.3 Требования низкого уровня (LLR)40
6.5.4 Поток управления (ключевые сценарии)42
6.6 Компонент формальной инспекции и СП (FormalInspection/ProblemReport/Notifications)43
6.6.1 Назначение компонента43
6.6.2 Основные операции (Backend)43
6.6.3 Требования низкого уровня (LLR)48
6.6.4 Поток управления (ключевые сценарии)50
6.7 Компонент поиска и фильтрации (SearchService)51
6.7.1 Назначение компонента51
6.7.2 Основные операции (Backend)51
6.7.3 Требования низкого уровня (LLR)52
6.7.4 Поток управления (ключевые сценарии)52
6.8 Компонент экспорта (ExportService)53
6.8.1 Назначение компонента53
6.8.2 Основные операции (Backend)53
6.8.3 Требования низкого уровня (LLR)53
6.8.4 Поток управления (ключевые сценарии)54
6.9 Компонент трассировки с кодом (GitHubTraceService)54
6.9.1 Назначение компонента54
6.9.2 Основные операции (Backend)54
6.9.3 Требования низкого уровня (LLR)56
6.9.4 Поток управления (ключевые сценарии)58
7 Трассируемость требований59
7.1 Связь производных требований с требованиями низкого уровня59
7.2 Распределение системных требований по компонентам65
8 Связь с планами проекта75
8.1 План разработки75
8.2 План верификации75
8.3 План управления конфигурацией75
1 Введение
1.1 Назначение
Документ «Описание проекта ПО» (далее — ОП ПО) описывает архитектуру и проектные решения для реализации веб‑системы управления требованиями. ОП ПО включает: (а) структурную декомпозицию ПО на компоненты, (б) описание ключевых сущностей данных и потоков данных, (в) распределение требований низкого уровня (LLR) по компонентам и связь LLR с требованиями более высокого уровня (DER‑REQ).
ОП ПО является выходом процесса проектирования ПО и используется как основной вход при кодировании, а также при верификации (формальная инспекция, анализ трассировки, подготовка тестов).
1.2 Область применения
Документ применяется в рамках проекта «Система управления требованиями» и обязателен для участников процессов проектирования, кодирования, интеграции, верификации и управления конфигурацией. Изменения в ОП ПО выполняются только через процедуры управления изменениями и фиксируются в системе управления конфигурацией.
1.3 Ссылки
[1] КТ-178B. Квалификационные требования. Часть 178В. Требования к ПО бортовой аппаратуры и систем при сертификации авиационной техники.
[2] Системные требования к системе управления требованиями
[3] Программные требования (высокого уровня) к системе управления требованиями
[4] Программные требования низкого уровня к системе управления требованиями
[5] План разработки ПО
[6] План верификации ПО
[7] План управления конфигурацией
[8] Стандарт на разработку требований к ПО
1.4 Термины, определения и сокращения
Ключевые термины приведены в таблице 1.
№
Понятие
Определение
1
Системное требование
Требования, предъявляемые к системе, понимаемой как программно-аппаратный комплекс. Некоторые системные требования могут реализовываться исключительно программно, некоторые - аппаратно, но возможна и совместная программно-аппаратная реализация
2
Спецификация
Совокупность требований, определяющих функции и свойства, которые должны быть реализованы в разрабатываемом программном обеспечении. Спецификация требований может быть организована как один или несколько логически связанных документов (файлов), либо как совокупность записей в специализированной базе данных, либо иным способом
3
Раздел требований
Структурный компонент внутри спецификации, группирующий требования по тематическому или логическому признаку
4
Пользователь
Лицо или организация, которые непосредственно будут эксплуатировать разрабатываемую систему. Пользователями, например, могут быть члены IT команд, руководители . Предполагается, что взаимодействие с пользователями находится в компетенции Заказчика. Пользователям будет предоставлен доступ к разным функциям системы, в зависимости от этого они будут обладать одной или несколькими ролями
5
Базовая версия
Утвержденная и неизменяемая версия требования, раздела или спецификации, которая является основой для дальнейшей разработки и трассировки. Установление и изменение базовой версии возможно только через процесс ЗИ
6
Запрос на изменение (ЗИ)
Формальное предложение на модификацию текущей базовой версии требования, раздела или спецификации. Реализуется через создание новой "Рабочей версии" единицы конфигурации
7
Формальная инспекция
Формальный процесс проверки и оценки артефакта (требования, раздела, спецификации) уполномоченным инспектором на соответствие установленным критериям качества перед утверждением в качестве базовой версии
8
Инспектор
Пользователь, уполномоченный проводить формальную инспекцию артефакта
9
Трассировка
Связь между требованиями, позволяющая отслеживать их взаимное влияние
10
Действие (Вход)
Любое событие или команда, инициируемая пользователем или внешней системой для взаимодействия с системой управления требованиями
11
Результат (Выход)
Ответ системы на действие, который может быть представлен в виде данных, изменения состояния или уведомления
12
Артефакт
Любой объект, управляемый в системе: спецификация, требование, запрос на изменение, проект, раздел спецификации, тест для требования, результат теста, протокол инспекции
13
Проект
Высокоуровневая сущность, объединяющая все артефакты, спецификации и пользователей, участвующих в разработке одного продукта или системы
14
Рабочая версия
Версия требования, раздела или спецификации, созданная на основе Базовой версии в рамках Запроса на изменение (ЗИ). В этой версии ведутся все правки, обсуждаются замечания. После утверждения инспектором Рабочая версия становится новой Базовой версией
15
Версия ЕК
Конкретное сохраненное состояние ЕК в определенный момент времени. Система хранит полную историю всех версий каждого артефакта
16
Единица конфигурации
Артефакт, версией которого управляет система
17
Тип артефакта
Категория артефакта, определяющая его назначение, структуру данных и правила обработки в системе. Фиксированный перечень: Спецификация, Требование, Раздел спецификации, Запрос на изменение, Проект, Тест, Результат теста, Протокол ФИ
18
Тип связи
Категория отношения между двумя артефактами, определяющая характер их взаимного влияния. Примеры: реализует, тестирует, зависит от, влияет на, уточняет
19
Сообщение о проблеме (СП)
Артефакт, фиксирующий несоответствие, выявленное в процессе Формальной инспекции. Содержит описание проблемы, ссылки на рассматриваемые артефакты и участников спора
20
Несоответствие
Выявленное отклонение артефакта от установленных требований, стандартов, правил оформления, полноты, корректности или непротиворечивости, обнаруженное в ходе формальной инспекции.Несоответствие фиксируется в системе как отдельный объект, содержащий описание проблемы, ссылки на артефакт и его версию, источник обнаружения и текущее состояние. Статусы: открыто: Несоответствие выявлено, зарегистрировано и ожидает анализа или решения. Оно считается «нерешенным» и блокирует утверждение базовой версии.устранено: Несоответствие было устранено путем внесения изменений, и изменения прошли проверку. Артефакт соответствует требованиям.снято: Несоответствие признано нерелевантным, ошибочным или больше не требующим действий. Статус устанавливается по результатам анализа и обоснования.«заметка» : Несоответствие признаётся не критичным и не влияющим на утверждение базовой версии, однако рекомендуется к исправлению в дальнейшем.не устранено: Несоответствие подтверждено и требует исправления, но изменения еще не внесены или не проверены
21
Github
Веб-сервис для хранения программного кода и истории его изменений
22
Репозиторий
Корневая папка с файлами проекта в Github, которая хранит исходный код и дополнительные материалы
23
Коммит
ЕК в Github, отражающая состояние проекта в определённый момент времени и сохранённая в истории репозитория
24
Ветка(в Github)
Копия кода проекта в которой можно работать над новыми функциями и исправлениями без внесения изменений в основную кодовую базу. Базовая версия кода обычно хранится в главной ветке, называемой main или master
Таблица 1 — Термины и определения
2 Роль документа в жизненном цикле и связь с процессами
2.1 Связь с процессом разработки и верификации(удалить подпункт)
В принятой каскадной схеме ЖЦ ПО данный документ является ключевым результатом этапа проектирования. Таблица 2 показывает входы/выходы процессов разработки и подтверждает роль ОП ПО как выход проектирования и вход кодирования.
Процесс
Вход
Выход
Разработка требований ПО
Требования к системеСтандарт на разработку требованийЗНИ
Требования к ПОСообщение о проблемах
Проектирование ПО
Требования к ПОПлан разработкиСтандарт на проектированиеЗНИ
Описание проекта ПОСообщение о проблемах
Написание кода
Описание проекта ПОСтандарт на кодированиеЗНИ
Исходный кодСообщение о проблемахИнструкция по запуску
Интеграция ПО
Исходный кодЗНИ
Исполняемый кодСообщение о проблемах
Таблица 2 — Процессы разработки и артефакты ЖЦ ПО
2.2 Трассируемость в жизненном цикле(удалить подпункт)
В системе фиксируется минимальная цепочка трассируемости между данными ЖЦ ПО (требования → требования НУ → код → испытания). Таблица 3 отражает установленные связи трассируемости.
Трассируемые данные (входные)
Трассируемые данные (выходные)
Требования к системе
Требования к ПО высокого уровня
Требования к ПО высокого уровня
Требования к ПО низкого уровня
Требования к ПО низкого уровня
Модуль исходного кода
Требования к ПО высокого уровняТребования к ПО низкого уровня
Процедура испытаний ПО
Таблица 3 — Трассируемость данных ЖЦ ПО
2.3 Управление конфигурацией
Все данные ЖЦ ПО являются единицами конфигурации и хранятся в Gitlab. Gitlab обеспечивает историю изменений (коммиты) и процедуру внесения изменений через issue и merge request с ревью и тестированием. Базовые версии данных ЖЦ ПО устанавливаются по результатам верификации.
3 Архитектура системы
3.1 Назначение и основные функции
Система управления требованиями предназначена для хранения и версионирования артефактов, управления запросами на изменение, проведения формальной инспекции, управления несоответствиями и сообщениями о проблеме, ведения трассировки, настройки жизненного цикла артефактов и прав доступа пользователей.
3.2 Архитектурный стиль и развертывание
Архитектурный стиль — клиент‑серверное веб‑приложение. Пользователь работает в браузере (Frontend). Frontend взаимодействует с Backend через HTTP(S) API. Backend обеспечивает бизнес‑логику и хранение в БД, а также обращение к внешним сервисам (email‑уведомления, GitHub API).
3.3 Среда разработки и верификации
Среда разработки и верификации определяется планом разработки и планом верификации. В таблицах 4–5 приведены используемые инструменты.
Название
Разработчик
Назначение
Linux Ubuntu
Canonical Ltd.
Операционная система
Yandex Wiki
Yandex
Подготовка документов, подготовка тест-планов
Draw.io
JGraph Ltd.
Создание схем, рисунков, диаграмм
PyCharm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на Python
JetBrains WebStorm
ООО “ИНТЕЛЛИДЖЕЙ ЛАБС “
Написание, отладка кода на JavaScript, CSS & HTML
PostgreSQL
Opensource-проект
Система управления базами данных
pgAdmin
Opensource-проект
Клиент для упрощения использования PostgreSQL
Git
Opensource-проект
Система контроля версий
React
Opensource-проект
Набор готовых библиотек для построения пользовательских интерфейсов
Flask
Opensource-проект
Набор готовых библиотек для разработки серверной части веб-приложения
Таблица 4 — Инструменты разработки
Название инструмента
Предназначение инструмента
Docker/systemd
Стенд для отладки и испытаний
VS Code
Среда разработки кода бэкенд части
Pytest
Средство для автоматизированного тестирования
Pytest-cov
Средство для отслеживания покрытия тестами
TestRail
Средство для хранения ручных и автоматизированных тестов
Таблица 5 — Инструменты верификации
3.4 Основные сущности данных
Сущность
Назначение
Пользователь
Учётная запись пользователя, роли и права доступа
Проект
Высокоуровневая сущность, объединяющая спецификации и участников
Артефакт
Объект ЖЦ ПО (требование, раздел, спецификация, тест, протокол ФИ и др.)
Версия артефакта
Сохранённое состояние артефакта (рабочая/базовая/архивная)
Запрос на изменение (ЗИ)
Формальный объект для внесения изменений в базовые версии
Формальная инспекция (ФИ)
Процесс и объект контроля качества артефактов перед установлением базовой версии
Несоответствие
Замечание, выявленное в ходе ФИ, имеющее статус и требующее решения
Сообщение о проблеме (СП)
Артефакт, фиксирующий проблему/несоответствие и историю решений
Трассировочная связь
Связь между артефактами, а также между артефактом и кодом/тестами
Уведомление
Сообщение пользователю о событиях (изменение базовой версии, приглашение на ФИ и т.п.)
Запись журнала
Audit log записи действий пользователей и изменений данных
Таблица 6 — Основные сущности
4 Структура ПО
4.1 Компоненты верхнего уровня
Компонент (название)
Идентификатор
LLR (шт.)
Компонент аутентификации (AuthService)
Component_AuthService
10
Компонент личного кабинета (ProfileService)
Component_ProfileService
6
Компонент администрирования проектов (AdminService)
Component_AdminService
9
Компонент работы с проектами (ProjectService)
Component_ProjectService
5
Компонент управления артефактами и версиями (ArtifactService)
Component_ArtifactService
12
Компонент формальной инспекции и СП (FormalInspection/ProblemReport/Notifications)
Component_FormalInspectionService
16
Компонент поиска и фильтрации (SearchService)
Component_SearchService
4
Компонент экспорта (ExportService)
Component_ExportService
3
Компонент трассировки с кодом (GitHubTraceService)
Component_GitHubTraceService
11
Таблица 7 — Компоненты и объём требований НУ
4.2 Соглашения о требованиях НУ и ошибках
LLR имеют формат идентификатора LLR_<Component>_<UseCase>_<NN> и тип: Ф (Frontend) или Б (Backend). Требования описывают поведение функций/экранов и включают ссылки «Основание: DER‑REQ‑…».
В требованиях используются типовые коды ошибок: ERR_CONFLICT, ERR_EXPORT_FAILED, ERR_EXTERNAL_SERVICE_UNAVAILABLE, ERR_FORBIDDEN, ERR_NOT_FOUND, ERR_STATE_TRANSITION, ERR_UNAUTHORIZED, ERR_VALIDATION. Их смысл и правила применения приведены в разделе 5.5.
4.3 Взаимодействие компонентов
Компоненты верхнего уровня взаимодействуют друг с другом через вызовы внутренних API (функций, реализованных на стороне Backend) и через общую базу данных. Ниже описаны основные логические связи, определяющие архитектуру системы и потоки управления/данных.
Компонент
Взаимодействует с
Характер взаимодействия
AuthService
Все компоненты
Предоставляет функции проверки аутентификации (authenticate, get_current_user) и авторизации (check_permission). Каждый компонент перед выполнением любой операции вызывает AuthService для получения информации о текущем пользователе и его правах.
ProjectService
ArtifactService, FormalInspectionService, SearchService, ExportService, GitHubTraceService, AdminService
Является источником данных о проектах: список проектов пользователя, описание, метаданные. Другие компоненты используют его для получения идентификатора проекта, проверки принадлежности артефактов к проекту и загрузки шаблонов генерации external_id. AdminService при создании проекта и управлении участниками обновляет данные через ProjectService.
ArtifactService
SearchService, ProjectService, FormalInspectionService, GitHubTraceService, AuthService, AdminService
Центральный компонент управления артефактами и версиями.
– Для фильтрации и поиска артефактов вызывает list_filtered и search_artifacts у SearchService.
– Для получения контекста проекта (шаблоны external_id, права на типы артефактов) обращается к ProjectService.
– При завершении формальной инспекции FormalInspectionService вызывает функции ArtifactService для создания базовых версий (create_baseline).
– При отображении карточки артефакта запрашивает у GitHubTraceService список связей с кодом.
– Все операции проверяют права через AuthService.
– Изменения фиксируются в аудит-логе через вызов log_action у AdminService.
FormalInspectionService (включая ProblemReport и Notifications)
ArtifactService, AuthService, AdminService, (внутренний NotificationService)
Проводит формальные инспекции, управляет несоответствиями и сообщениями о проблемах.
– Загружает изменённые артефакты и их версии через вызовы get_artifact_card у ArtifactService.
– После принятия решения создаёт базовые версии, вызывая соответствующие функции ArtifactService.
– Использует внутренний NotificationService для отправки уведомлений участникам и авторам.
– Проверяет права через AuthService.
– Пишет протоколы и решения в БД, а также фиксирует события в аудит-логе через AdminService.
SearchService
ArtifactService
Реализует механизмы фильтрации и контекстного поиска. Основной потребитель – ArtifactService, который вызывает его для формирования списков артефактов.
ExportService
ArtifactService, ProjectService
При экспорте спецификаций обращается к ArtifactService для получения полных данных об артефактах и их версиях, а к ProjectService – для метаданных проекта. Результат возвращается пользователю через API.
GitHubTraceService
ArtifactService, AdminService, внешний GitHub API
Обеспечивает трассировку «артефакт—код».
– Для создания связи вызывает ArtifactService, чтобы зафиксировать текущую версию артефакта (save_artifact_content).
– При просмотре фрагмента кода обращается к GitHub API по сохранённым параметрам (repo, path, commit, lines).
– Операции создания/удаления связей логируются через AdminService.
AdminService
ProjectService, AuthService, все компоненты
Предоставляет сквозные функции:
– управление проектами, участниками, пользовательскими атрибутами (используется ProjectService и ArtifactService);
– централизованное журналирование: все компоненты вызывают log_action для записи действий пользователей в таблицу audit_log.
ProfileService
AuthService, NotificationService
Относительно независим. Для отображения уведомлений обращается к NotificationService (в составе FormalInspectionService), а для редактирования профиля проверяет права через AuthService.
Таблица 8 — Взаимодействия компонентов
5 Общие проектные решения
5.1 Идентификация артефактов
Каждый артефакт получает уникальный неизменяемый internal_id, который не переиспользуется после удаления. Для пользовательского представления используется внешний идентификатор external_id, который генерируется по активному шаблону проекта. Шаблоны задаются администратором проекта; при генерации external_id выполняется проверка уникальности.
5.2 Версионирование и история изменений
Система хранит историю изменений артефактов в виде последовательности версий. Версия фиксирует: автора, время, содержимое версии и (опционально) значения пользовательских атрибутов. Создание новой рабочей версии выполняется добавлением новой записи версии (не перезаписью).
5.3 Запросы на изменение (ЗИ)
Запрос на изменение (ЗИ) фиксирует необходимость изменения базовых версий и содержит обязательные атрибуты: обоснование, цель, список затрагиваемых артефактов, описание планируемых изменений и исполнителей. После создания ЗИ в рамках него создаются рабочие версии затрагиваемых артефактов.
5.4 Модель данных (логическая)
Данный раздел фиксирует логическую модель данных, достаточную для реализации требований. Физическая схема БД (типы, индексы) уточняется при реализации, но должна обеспечивать требования по уникальности идентификаторов, истории версий и трассируемости.
Сущность/таблица
Ключевые поля (логически)
users
user_id, first_name, last_name, login (unique), email, password_hash, email_confirmed, created_at
email_tokens
token, user_id, expires_at, used_flag
projects
project_id, name, description, created_by, created_at
project_members
project_id, user_id, role, added_at
member_permissions
project_id, user_id, permissions (list)
artifacts
internal_id (UUID), project_id, artifact_type, external_id, title, status, created_by, created_at, deleted_flag
artifact_versions
version_id, artifact_internal_id, version_kind (working/baseline/archived), author_id, timestamp_utc, content
custom_attributes
attr_id, project_id, artifact_type, field_key (unique), attr_type, comment
custom_attr_values
version_id, attr_id, value
trace_links
link_id, from_version_id, to_version_id, link_type, created_by, created_at, link_version, project_id
change_requests
cr_id, project_id, author_id, justification, goal, planned_changes, status, created_at
cr_affected_artifacts
cr_id, artifact_internal_id
formal_inspections
fi_id, cr_id, leader_id, status, decision, created_at
fi_protocols
protocol_id, fi_id, stored_at, protocol_content
nonconformities
nc_id, fi_id, artifact_internal_id, description, status, history
problem_reports
pr_id, nc_id, created_by, status
pr_decisions
decision_id, pr_id, decision_text, actor_id, timestamp_utc
notifications
notification_id, user_id, kind, payload, created_at, read_at
audit_log
timestamp_utc, actor_user_id, action_type, entity_type, entity_id, project_id
code_links
code_link_id, artifact_version_id, repo, path, commit_or_branch, start_line, end_line, created_by
Таблица 9 — Логическая модель данных
5.5 Обработка ошибок и коды ошибок
Ошибки операций Backend возвращаются в унифицированном формате: code (тип ошибки), message (текст), и (опционально) поля детализации (field, details). Используемые типы ошибок:
Код
Значение
ERR_VALIDATION
Ошибка валидации входных данных (например, обязательное поле отсутствует, неверный формат)
ERR_CONFLICT
Конфликт данных/уникальности (например, duplicate login, конфликт external_id, конфликт назначения роли)
ERR_FORBIDDEN
Недостаточно прав для выполнения операции
ERR_UNAUTHORIZED
Ошибка аутентификации (неверный логин/пароль, отсутствует токен)
ERR_NOT_FOUND
Запрошенный объект не найден (проект/артефакт/связь)
ERR_STATE_TRANSITION
Недопустимый переход состояния (например, блокирующие несоответствия не дают создать базовую версию)
ERR_EXTERNAL_SERVICE_UNAVAILABLE
Недоступен внешний сервис (например, GitHub)
ERR_EXPORT_FAILED
Ошибка формирования экспортного файла
Таблица 10 — Коды ошибок
6 Подробное описание компонентов
6.1 Компонент аутентификации (AuthService)
6.1.1 Назначение компонента
Обеспечивает регистрацию, подтверждение email и аутентификацию пользователей.
6.1.2 Основные операции (Backend)
Операция
Возвращаемое значение
Назначение (кратко)
Ошибки
Связанные LLR
confirm_email(string_of_confirmation: str) -> dict
{"status": "confirmed"}
Функция confirm_email(string_of_confirmation: str) должна: (1) проверить существование токена, (2) проверить срок действия, (3) проверить что токен не был использован, (4) установить пользователю признак email_confirmed=true, (5) пометить токен использованным
ERR_VALIDATION
LLR_AuthService_ConfirmEmail
login_user(login: str, password: str) -> dict
{"session_token": str, "user_id": str}
Функция login_user(login: str, password: str) должна выполнить запрос в (описать функцию, которая обращается в бд) БД для проверки существования пользователя и корректности пароля через сравнение хеша
ERR_UNAUTHORIZED
LLR_AuthService_LoginServer
register_user(payload: dict) -> dict
{"user_id": str}
Перед сохранением пользователя (добавлением учетной записи пользователя) функция register_user(payload: dict) должна валидировать входные данные по правилам: (1) first_name, last_name — только кириллица, (2) email — корректный формат, (3) password == password_repeat, (4) login уникален
ERR_CONFLICT, ERR_VALIDATION
LLR_AuthService_RegisterServer_01, LLR_AuthService_RegisterServer_02, LLR_AuthService_RegisterServer_03, LLR_AuthService_RegisterServer_04
Таблица 11 — Операции компонента
6.1.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_AuthService_RegisterClient
Ф
DER-REQ-1-001; DER-REQ-1-003
Поля регистрации на стороне UI
LLR_AuthService_RegisterClient_Validation
Ф
DER-REQ-1-003
Валидация формы регистрации на стороне UI (больше проверка на соответствие формату)
LLR_AuthService_RegisterServer_01
Б
DER-REQ-1-002
Валидация ограничений регистрации на сервере
LLR_AuthService_RegisterServer_02
Б
DER-REQ-1-002
Проверка уникальности логина при регистрации
LLR_AuthService_RegisterServer_03
Б
DER-REQ-1-004
Сохранение пользователя в базе данных
LLR_AuthService_RegisterServer_04
Б
DER-REQ-1-005
Отправка уведомления с подтверждением email
LLR_AuthService_ConfirmEmail
Б
DER-REQ-1-006
Обработка подтверждения email
LLR_AuthService_RegisterServer_05
Б
DER-REQ-1-007
Назначение прав администратора по флагу
LLR_AuthService_LoginClient
Ф
DER-REQ-2-001; DER-REQ-2-002; DER-REQ-2-005
Поля авторизации на стороне UI
LLR_AuthService_LoginServer
Б
DER-REQ-2-003; DER-REQ-2-004
Проверка учётных данных при входе
Таблица 12 — LLR компонента
6.1.4 Поток управления (ключевые сценарии)
Сценарий «Регистрация»:
UI (фронтенд) вызывает POST /api/register с телом {first_name, last_name, login, email, password, password_repeat, is_admin_flag}.
Backend (AuthService) получает запрос, вызывает внутреннюю функцию register_user(payload):
Валидирует поля (кириллица, формат email, совпадение паролей).
Проверяет уникальность login через запрос к БД (таблица users).
При успехе создаёт запись в users с email_confirmed=false, хеширует пароль.
Если is_admin_flag=true, назначает права администратора (запись в member_permissions для всех проектов? — уточняется).
Генерирует токен подтверждения email, сохраняет в email_tokens.
Инициирует асинхронную отправку письма (через внешний сервис или очередь).
Возвращает user_id.
UI отображает сообщение об успешной регистрации и предложение подтвердить email.
Сценарий «Подтверждение email»:
Пользователь переходит по ссылке вида https://.../confirm?token=....
Backend (AuthService) вызывает confirm_email(token):
Проверяет наличие токена в email_tokens, его срок действия и признак used_flag.
Если всё корректно, устанавливает email_confirmed=true для соответствующего пользователя и помечает токен использованным.
Возвращает статус confirmed.
UI (страница подтверждения) отображает сообщение об успехе и перенаправляет в личный кабинет.
Сценарий «Вход»:
UI отправляет POST /api/login с {login, password}.
Backend (AuthService) вызывает login_user(login, password):
Ищет пользователя по login в БД.
Сравнивает хеш пароля.
При успехе генерирует сессионный токен (JWT) и возвращает {session_token, user_id}.
При неудаче возвращает ERR_UNAUTHORIZED.
UI сохраняет токен и перенаправляет в личный кабинет.
6.2 Компонент личного кабинета (ProfileService)
6.2.1 Назначение компонента
Обеспечивает отображение и редактирование профиля пользователя и уведомлений.
6.2.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
edit_user(..)
UI должен разрешать редактирование только полей first_name, last_name, email, поле login должно быть read-only
LLR_ProfileService_Edit
update_profile(user_id: str, patch: dict)
Функция update_profile(user_id: str, patch: dict) должна обновлять в БД только разрешённые поля (first_name, last_name, email) и отклонять попытки обновления login с ERR_FORBIDDEN(code='FIELD_IMMUTABLE')
ERR_FORBIDDEN
LLR_ProfileService_Update
Таблица 13 — Операции компонента
6.2.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_ProfileService_View
Ф
DER-REQ-3-001; DER-REQ-3-002
Отображение данных профиля и уведомлений
LLR_ProfileService_Edit
Ф
DER-REQ-3-003; DER-REQ-3-004
Редактируемость полей профиля
LLR_ProfileService_SaveButton
Ф
DER-REQ-3-005; DER-REQ-3-006
Логика активности кнопки «Сохранить»
LLR_ProfileService_EditValidation
Ф
DER-REQ-3-007
Проверка корректности полей профиля при сохранении
LLR_ProfileService_Update
Б
DER-REQ-3-008; DER-REQ-3-003
Сохранение изменений профиля в БД
LLR_ProfileService_AdminZoneButton
Ф
DER-REQ-3-009
Отображение кнопки «Настройки проектов»
Таблица 14 — LLR компонента
6.2.4 Поток управления (ключевые сценарии)
Сценарий 1: Просмотр профиля и уведомлений
Пользователь открывает страницу личного кабинета (интерфейс 3).
UI (Frontend) отправляет GET-запрос к /api/profile, включая сессионный токен в заголовок.
Backend (ProfileService) получает запрос и вызывает внутреннюю функцию get_profile(user_id) (предполагается, что user_id извлекается из токена через вызов AuthService.authenticate(token)).
Функция get_profile запрашивает из БД данные пользователя: first_name, last_name, login, email, роли.
Для получения уведомлений get_profile вызывает NotificationService.list_notifications(user_id).
ProfileService формирует ответ {user_data, notifications} и возвращает его UI.
UI отображает данные профиля и список уведомлений (LLR_ProfileService_View).
Если пользователь имеет права администратора, отображается кнопка «Настройки проектов» (LLR_ProfileService_AdminZoneButton).
Сценарий 2: Редактирование профиля
Пользователь изменяет одно или несколько полей (имя, фамилия, email) в форме редактирования профиля.
UI выполняет валидацию изменённых полей на стороне клиента (LLR_ProfileService_EditValidation):
Имя и фамилия должны содержать только кириллицу.
Email должен соответствовать стандартному формату.
Если валидация пройдена, UI активирует кнопку «Сохранить» (LLR_ProfileService_SaveButton).
Пользователь нажимает «Сохранить».
UI отправляет PATCH-запрос к /api/profile с телом {first_name, last_name, email} (только изменённые поля).
Backend (ProfileService) вызывает функцию update_profile(user_id, patch):
Проверяет через AuthService.check_permission, что пользователь имеет право редактировать свой профиль (обычно разрешено всем аутентифицированным).
Проверяет, что в patch присутствуют только разрешённые поля (first_name, last_name, email); при попытке изменить login возвращает ERR_FORBIDDEN с кодом FIELD_IMMUTABLE.
Валидирует новые значения (аналогично клиентской валидации).
Обновляет запись пользователя в БД.
Возвращает статус {"status": "updated"}.
UI отображает сообщение об успешном сохранении и обновляет отображаемые данные.
6.3 Компонент администрирования проектов (AdminService)
6.3.1 Назначение компонента
Обеспечивает администрирование проектов: создание проекта, управление участниками/правами, настройку пользовательских атрибутов, audit log.
6.3.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
add_project_member(project_id: str, actor_id: str, target_user_id: str, roles: list)
Функция add_project_member(project_id: str, actor_id: str, target_user_id: str, roles: list) должна добавлять пользователя в проект и назначать роли
LLR_AdminService_AddRemoveMember
create_custom_attribute(project_id, artifact_type, attr_type, field_key, comment)
Функции 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)
ERR_CONFLICT
LLR_AdminService_CustomAttrEditor
create_project(user_id: str, name: str, description: str)
Функция create_project(user_id: str, name: str, description: str) должна: (1) создать запись проекта, (2) создать артефакт типа «Проект», (3) связать артефакт с проектом, (4) вернуть идентификатор проекта
LLR_AdminService_CreateProject
delete_custom_attribute(attr_id)
Функции 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)
ERR_CONFLICT
LLR_AdminService_CustomAttrEditor
list_project_members(project_id: str)
Функция list_project_members(project_id: str) должна возвращать список строк с полями: full_name, login, email, roles, status
LLR_AdminService_ProjectMembersTable
query_audit_log(project_id: str, user_id: str, action_type: str, artifact_id: str, date_from: datetime, date_to: datetime)
Функция query_audit_log(project_id: str, user_id: str, action_type: str, artifact_id: str, date_from: datetime, date_to: datetime) должна возвращать отфильтрованные записи с пагинацией
LLR_AdminService_AuditLog_Filter
remove_project_member(project_id: str, actor_id: str, target_user_id: str)
Функция add_project_member(project_id: str, actor_id: str, target_user_id: str, roles: list) должна добавлять пользователя в проект и назначать роли
LLR_AdminService_AddRemoveMember
set_member_permissions(project_id: str, actor_id: str, target_user_id: str, permissions: list)
Функция set_member_permissions(project_id: str, actor_id: str, target_user_id: str, permissions: list) должна сохранять список разрешённых функций пользователя в проекте
ERR_FORBIDDEN
LLR_AdminService_SetPermissions
update_custom_attribute(attr_id, patch)
Функции 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)
ERR_CONFLICT
LLR_AdminService_CustomAttrEditor
update_project_description(project_id, description)
Функция create_project(user_id: str, name: str, description: str) должна: (1) создать запись проекта, (2) создать артефакт типа «Проект», (3) связать артефакт с проектом, (4) вернуть идентификатор проекта
LLR_AdminService_CreateProject
Таблица 15 — Операции компонента
6.3.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_AdminService_Tabs
Ф
DER-REQ-4-001
Вкладки администрирования
LLR_AdminService_CreateProjectButton
Ф
REQ_SW-4-002
Видимость кнопки «Создать проект»
LLR_AdminService_CreateProject
Б
REQ_SW-4-003
Создание проекта и артефакта «Проект»
LLR_AdminService_ProjectMembersTable
Б
REQ_SW-4-004
Таблица пользователей проекта (структура)
LLR_AdminService_AddRemoveMember
Б
REQ_SW-4-004; REQ_SW-4-007
Добавление и удаление пользователей проекта
LLR_AdminService_SetPermissions
Б
REQ_SW-4-005
Отметка разрешённых функций (действий) (прав)
LLR_AdminService_CustomAttrEditor
Б
REQ_SW-4-006
Редактор пользовательских атрибутов артефактов
LLR_AdminService_AuditLog_Record
Б
REQ_SW-4-007
Журналирование действий пользователей
LLR_AdminService_AuditLog_Filter
Б
DER-REQ-4-002
Фильтрация журнала действий
Таблица 16 — LLR компонента
6.3.4 Поток управления (ключевые сценарии)
Сценарий 1: Создание проекта
Администратор переходит на вкладку «Проекты» в разделе администрирования и нажимает кнопку «Создать проект».
UI отображает форму с полями name и description.
Пользователь заполняет форму и нажимает «Создать».
UI отправляет POST-запрос к /api/admin/projects с телом {name, description}.
Backend (AdminService) вызывает функцию create_project(user_id, name, description):
Проверяет через AuthService.check_permission, что у пользователя есть право на создание проекта.
Создаёт запись в таблице projects.
Создаёт артефакт типа «Проект», вызывая ArtifactService.create_artifact с параметрами: project_id (новый), artifact_type='project', title=name, description=description.
Связывает созданный артефакт с проектом (через поле project_id в артефакте).
Записывает действие в аудит-лог через AdminService.log_action.
Возвращает project_id.
UI получает идентификатор и перенаправляет на страницу созданного проекта.
Сценарий 2: Добавление пользователя в проект
Администратор открывает вкладку «Пользователи проекта» для выбранного проекта и нажимает «Добавить участника».
UI отображает форму с полем поиска пользователя и выбором ролей.
Администратор выбирает пользователя (или вводит email) и назначает роли, затем нажимает «Добавить».
UI отправляет POST-запрос к /api/admin/projects/{project_id}/members с телом {target_user_id, roles}.
Backend (AdminService) вызывает функцию add_project_member(project_id, actor_id, target_user_id, roles):
Проверяет через AuthService.check_permission, что у текущего пользователя (actor_id) есть право добавлять участников в данный проект.
Добавляет запись в таблицу project_members.
Обновляет права доступа (если требуется) в member_permissions.
Записывает действие в аудит-лог через AdminService.log_action.
Возвращает статус {"status": "ok"}.
UI обновляет таблицу участников проекта (LLR_AdminService_ProjectMembersTable).
Сценарий 3: Настройка пользовательских атрибутов артефактов
Администратор открывает вкладку «Управление артефактами» и выбирает тип артефакта, для которого хочет добавить атрибут.
UI отображает редактор атрибутов с возможностью добавления нового атрибута.
Администратор заполняет поля: field_key, attr_type (текст, число, дата и т.п.), comment, и нажимает «Сохранить».
UI отправляет POST-запрос к /api/admin/attributes с данными атрибута.
Backend (AdminService) вызывает функцию create_custom_attribute(project_id, artifact_type, attr_type, field_key, comment):
Проверяет уникальность field_key в рамках (project_id, artifact_type). Если дубликат, возвращает ERR_CONFLICT.
Создаёт запись в таблице custom_attributes.
Логирует действие.
Возвращает attr_id.
UI добавляет новый атрибут в список.
6.4 Компонент работы с проектами (ProjectService)
6.4.1 Назначение компонента
Обеспечивает навигацию по проектам и получение состояния конфигурации проекта.
6.4.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
get_project(project_id)
При клике на проект UI должен выполнять запрос get_project(project_id) и отображать описание проекта
ERR_FORBIDDEN
LLR_ProjectService_OpenDescription
get_project_config_state(project_id: str)
Функция get_project_config_state(project_id: str) должна возвращать агрегированные значения: количество артефактов по типам, статистику ЗИ, открытые СП, список несоответствий, протоколы и список ФИ
LLR_ProjectService_ConfigState
Таблица 17 — Операции компонента
6.4.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_ProjectService_SidebarProjects
Ф
DER-REQ-5-001
Список проектов в боковой панели
LLR_ProjectService_ProjectList
Ф
DER-REQ-5-002
Список проектов в разделе «Проекты»
LLR_ProjectService_OpenDescription
Б
DER-REQ-5-003
Открытие описания проекта
LLR_ProjectService_ProjectMenu
Ф
REQ_SW-5-004
Горизонтальное меню проекта
LLR_ProjectService_ConfigState
Б
REQ_SW-5-004
Загрузка состояния конфигурации проекта
Таблица 18 — LLR компонента
6.4.4 Поток управления (ключевые сценарии)
Сценарий «Открытие проекта»
Пользователь на панели навигации или в разделе «Проекты» щёлкает по названию проекта.
UI отправляет GET-запрос к /api/projects/{project_id}.
Backend (ProjectService) вызывает функцию get_project(project_id, user_id):
Сначала через AuthService.get_current_user(token) получает user_id.
Проверяет, является ли пользователь участником проекта (через запрос к project_members). Если нет, возвращает ERR_FORBIDDEN.
Загружает основные данные проекта из таблицы projects.
Вызывает внутреннюю функцию get_project_config_state(project_id) для получения агрегированной статистики:
Количество артефактов по типам (запрос к artifacts).
Количество открытых запросов на изменение (ЗИ) (запрос к change_requests).
Количество открытых сообщений о проблеме (СП) (запрос к problem_reports через связи с проектом).
Список последних формальных инспекций (запрос к formal_inspections).
Формирует ответ, содержащий {project_id, name, description, config_state: {...}}.
Backend возвращает данные UI.
UI отображает описание проекта и состояние конфигурации в соответствии с LLR_ProjectService_OpenDescription и LLR_ProjectService_ConfigState.
6.5 Компонент управления артефактами и версиями (ArtifactService)
6.5.1 Назначение компонента
Обеспечивает управление артефактами, версиями, трассировочными ссылками и запросами на изменение.
6.5.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
create_artifact(project_id: str, user_id: str, artifact_type: str, title: str, description: str, custom_attrs: dict)
Функция 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) создать рабочую версию в artifact_versions со статусом «рабочая», (5) сохранить значения пользовательских атрибутов
ERR_CONFLICT
LLR_ArtifactService_CreateArtifact
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])
Функция 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
LLR_ChangeRequestService_CreateCR
get_artifact_card(artifact_id: str, user_id: str)
Функция get_artifact_card(artifact_id: str, user_id: str) должна возвращать: данные базовой версии, данные рабочей версии (если есть), значения пользовательских атрибутов, а также список трассировочных связей
LLR_ArtifactService_ViewCard
get_traceability_table(artifact_id: str, version_id: str)
Функция get_traceability_table(artifact_id: str, version_id: str) должна возвращать входящие и исходящие связи, каждая связь должна содержать: link_type, related_artifact_type, related_external_id, related_title, related_version
LLR_TraceLinkService_ViewTraceTable
list_artifacts(project_id: str, filters: dict, search: str)
Функция list_artifacts(project_id: str, filters: dict, search: str) должна возвращать строки с полями: artifact_type, external_id, title, baseline_version, has_working_version, lifecycle_status
LLR_ArtifactService_ListArtifacts
list_change_requests(project_id: str, artifact_id: str)
UI ЗИ должен отображать список запросов на изменение, связанных с текущим проектом или выбранным артефактом
LLR_ChangeRequestService_ListCR
mark_ready_for_fi(cr_id: str, user_id: str)
Функция mark_ready_for_fi(cr_id: str, user_id: str) должна: (1) отправить уведомление ведущему, (2) установить ЗИ статус «Ожидает ФИ», (3) обеспечить появление ЗИ в списке в подразделе
LLR_ChangeRequestService_ReadyForFI
save_artifact_content(artifact_id: str, user_id: str, content: dict, custom_attrs: dict)
Функция save_artifact_content(artifact_id: str, user_id: str, content: dict, custom_attrs: dict) должна создавать новую рабочую версию артефакта с фиксацией автора, времени, содержимого и значений пользовательских атрибутов
LLR_VersioningService_SaveWorkingVersion
Таблица 19 — Операции компонента
6.5.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_ArtifactService_FilterPanel
Ф
REQ_SW-6-001
Панель фильтров и поиска артефактов
LLR_ArtifactService_ListArtifacts
Б
REQ_SW-6-002
Возврат таблицы артефактов проекта
LLR_ArtifactService_RowActions
Ф
REQ_SW-6-003
Действия в строке таблицы артефактов
LLR_ArtifactService_ViewCard
Б
REQ_SW-6-005
Карточка артефакта (состав данных)
LLR_ArtifactService_CreatePermission
Ф
REQ_SW-6-006
Видимость кнопки «Создать артефакт»
LLR_ArtifactService_CreateArtifact
Б
REQ_SW-6-006
Создание артефакта с внутренним и внешним ID и рабочей версией
LLR_TraceLinkService_ViewTraceTable
Б
REQ_SW-6-007
Таблица трассировки артефакта
LLR_ChangeRequestService_ListCR
Б
REQ_SW-7-001
Список ЗИ по проекту или выбранному артефакту
LLR_ChangeRequestService_HistoryTable
Б
REQ_SW-7-002
Таблица истории ЗИ для артефакта
LLR_ChangeRequestService_CreateCR
Б
REQ_SW-7-003
Создание ЗИ с обязательными атрибутами
LLR_VersioningService_SaveWorkingVersion
Б
REQ_SW-7-004
Создание новой рабочей версии при сохранении изменений рабочей версии
LLR_ChangeRequestService_ReadyForFI
Б
DER-REQ-7-001
Кнопка «Готово к ФИ»: уведомление ведущему и статус
Таблица 20— LLR компонента
6.5.4 Поток управления (ключевые сценарии)
Сценарий «Создание артефакта»:
UI проверяет видимость кнопки «Создать артефакт» на основе прав пользователя (LLR_ArtifactService_CreatePermission).
Пользователь заполняет форму создания артефакта (тип, заголовок, описание, пользовательские атрибуты) и нажимает «Создать».
UI отправляет POST-запрос к /api/artifacts с телом {project_id, artifact_type, title, description, custom_attrs}.
Backend (ArtifactService) вызывает функцию create_artifact(project_id, user_id, artifact_type, title, description, custom_attrs):
Проверяет через AuthService.check_permission право создания данного типа артефакта в проекте.
Генерирует уникальный internal_id (UUIDv4).
Запрашивает у ProjectService активный шаблон для генерации external_id и генерирует уникальный external_id.
Создаёт запись в таблице artifacts.
Создаёт первую рабочую версию в artifact_versions со статусом working, фиксируя author_id, timestamp_utc, content (начальное содержимое).
Сохраняет значения пользовательских атрибутов в custom_attr_values для созданной версии.
При конфликте external_id (дубликат) возвращает ERR_CONFLICT.
Возвращает artifact_id.
UI перенаправляет на карточку созданного артефакта.
Сценарий «Сохранение рабочей версии»
Пользователь открывает карточку артефакта, вносит изменения в содержимое и/или пользовательские атрибуты, затем нажимает «Сохранить».
UI отправляет PUT-запрос к /api/artifacts/{id}/content с телом {content, custom_attrs}.
Backend (ArtifactService) вызывает функцию save_artifact_content(artifact_id, user_id, content, custom_attrs):
Проверяет через AuthService.check_permission, что пользователь имеет право редактировать артефакт (обычно это разрешено, если есть открытый ЗИ, включающий данный артефакт).
Создаёт новую запись в artifact_versions с новым content, копируя или обновляя custom_attr_values для новой версии.
Фиксирует author_id, timestamp_utc.
Возвращает version_id новой рабочей версии.
UI обновляет отображение карточки артефакта, показывая, что теперь есть новая рабочая версия.
Сценарий «Создание запроса на изменение (ЗИ)»
Пользователь выбирает один или несколько артефактов (например, через таблицу артефактов) и инициирует создание ЗИ.
UI отображает форму создания ЗИ с полями: обоснование, цель, список затрагиваемых артефактов (заполнен автоматически), описание планируемых изменений, исполнители.
Пользователь заполняет обязательные поля и нажимает «Создать ЗИ».
UI отправляет POST-запрос к /api/change-requests с телом {project_id, justification, goal, affected_artifact_ids, planned_changes, assignee_ids}.
Backend (ArtifactService) вызывает функцию create_change_request(project_id, author_id, justification, goal, affected_artifact_ids, planned_changes, assignee_ids):
Валидирует наличие обязательных полей (justification, goal, affected_artifact_ids). При отсутствии возвращает ERR_VALIDATION.
Создаёт запись в таблице change_requests со статусом «Черновик» (или аналогичным).
Создаёт связи в cr_affected_artifacts для каждого указанного артефакта.
Для каждого затронутого артефакта, если у него уже есть базовая версия, система может автоматически создать рабочую версию (или оставить это на момент фактического редактирования). Обычно рабочие версии создаются при первом сохранении после создания ЗИ.
Возвращает cr_id.
UI перенаправляет на страницу созданного ЗИ.
Сценарий «Готовность к формальной инспекции»
После завершения всех изменений в рамках ЗИ автор (или ответственный) нажимает кнопку «Готово к ФИ».
UI отправляет POST-запрос к /api/change-requests/{id}/ready-for-fi.
Backend (ArtifactService) вызывает функцию mark_ready_for_fi(cr_id, user_id):
Проверяет, что пользователь имеет право (например, является автором или исполнителем).
Изменяет статус ЗИ на «Ожидает ФИ».
Вызывает NotificationService.notify для отправки уведомления ведущему инспектору (информация о ведущем может храниться в настройках проекта или ЗИ).
Обеспечивает появление ЗИ в списке ожидающих ФИ в соответствующем разделе.
UI отображает сообщение об успешной отправке на инспекцию.
6.6 Компонент формальной инспекции и СП (FormalInspection/ProblemReport/Notifications)
6.6.1 Назначение компонента
Обеспечивает проведение ФИ, протоколирование, управление несоответствиями и СП, создание базовых версий и уведомления.
6.6.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
accept_problem_report(pr_id: str, council_user_id: str)
Функция accept_problem_report(pr_id: str, council_user_id: str) должна установить статус «принято» и отправить уведомление автору о необходимости внесения изменений в артефакты
LLR_ProblemReportService_Accept
add_problem_report_decision(pr_id: str, user_id: str, decision_text: str)
Функция add_problem_report_decision(pr_id: str, user_id: str, decision_text: str) должна создавать запись решения с обязательными полями: дата, принявший решение, описание решения
LLR_ProblemReportService_DecisionHistory
create_fi_protocol(fi_id: str)
UI должен по нажатию «Создать протокол ФИ» вызывать create_fi_protocol(fi_id: str) и открывать панель ведения протокола ФИ для текущей ФИ
LLR_FormalInspectionService_OpenProtocolPanel
decide_fi(protocol_id: str, decision: str, user_id: str)
При decision='Принято' функция decide_fi() должна проверять наличие несоответствий по артефакту со статусом «открыто» или «не устранено»
ERR_STATE_TRANSITION
LLR_FormalInspectionService_BaselineGate, LLR_FormalInspectionService_CreateBaseline, LLR_FormalInspectionService_SaveProtocolOnDecision
get_fi_details(fi_id: str)
Функция get_fi_details(fi_id: str) должна возвращать: изменённые артефакты и версии, список несоответствий, СП (если создавалось), id протокола, комментарий, итоговое решение
LLR_FormalInspectionService_Details
list_formal_inspections(project_id: str)
UI ФИ должен отображать список ФИ с полями: protocol_id, status, date, participants, artifact_links, change_request_description
LLR_FormalInspectionService_List
list_nonconformities(protocol_id)
UI протокола ФИ должен отображать несоответствия в виде таблицы с полями: id, reviewed_ci, artifacts, description, status, comment, related_artifacts_and_versions_links
LLR_FormalInspectionService_NC_Table
list_problem_report_decisions(pr_id)
Функция add_problem_report_decision(pr_id: str, user_id: str, decision_text: str) должна создавать запись решения с обязательными полями: дата, принявший решение, описание решения
LLR_ProblemReportService_DecisionHistory
load_fi_scope(cr_id: str)
При старте ФИ функция load_fi_scope(cr_id: str) должна загружать изменённые артефакты, их версии и описание изменений и предоставлять участникам с правами возможность ведения протокола
LLR_FormalInspectionService_LoadChangedArtifacts
notify_baseline_created(project_id: str, artifact_ids: list[str], recipients: list[str])
Функция notify_baseline_created(project_id: str, artifact_ids: list[str], recipients: list[str]) должна создать уведомления в личном кабинете и инициировать отправку email всем пользователям, участвовавшим в создании/изменении ЕК и рассмотрении ЗИ
LLR_NotificationService_BaselineChanged
reject_problem_report(pr_id: str, council_user_id: str)
Функция reject_problem_report(pr_id: str, council_user_id: str) должна установить статус «отклонено» и инициировать уведомление участников ФИ
LLR_ProblemReportService_Reject
Таблица 21— Операции компонента
6.6.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_FormalInspectionService_List
Б
REQ_SW-8-001
Список ФИ и состав полей
LLR_FormalInspectionService_Details
Б
REQ_SW-8-002
Детали выбранной ФИ
LLR_FormalInspectionService_NavigateFromNotification
Ф
REQ_SW-8-003
Переход ведущего из уведомления к подготовке ФИ
LLR_FormalInspectionService_InviteForm
Ф
DER-REQ-8-004
Состав письма-приглашения на ФИ
LLR_FormalInspectionService_LoadChangedArtifacts
Б
REQ_SW-8-005
Загрузка данных изменённых артефактов для ведения протокола
LLR_FormalInspectionService_OpenProtocolPanel
Ф
DER-REQ-8-006
Кнопка «Создать протокол ФИ» открывает панель протокола
LLR_FormalInspectionService_SaveProtocolOnDecision
Б
REQ_SW-8-007
Сохранение протокола при принятии/отклонении ФИ
LLR_FormalInspectionService_BaselineGate
Б
REQ_SW-8-008
Запрет создания базовой версии при «открыто»/«не устранено»
LLR_FormalInspectionService_CreateBaseline
Б
REQ_SW-8-009
Создание базовой версии при «устранено»/«заметка»
LLR_FormalInspectionService_NotifyAuthor
Б
REQ_SW-8-010
Уведомление автора и статус ЗИ после решения ФИ
LLR_FormalInspectionService_NC_Table
Б
REQ_SW-8-011
Формат таблицы несоответствий в протоколе
LLR_ProblemReportService_List
Ф
REQ_SW-8-012
Таблица СП и состав полей
LLR_ProblemReportService_DecisionHistory
Б
REQ_SW-8-013
Создание решений по СП и хранение истории
LLR_ProblemReportService_Reject
Б
REQ_SW-8-014
Отклонение СП с уведомлением участников ФИ
LLR_ProblemReportService_Accept
Б
REQ_SW-8-015
Принятие СП с уведомлением автора
LLR_NotificationService_BaselineChanged
Б
REQ_SW-8-016
Уведомления после создания новой базовой версии
Таблица 22 — LLR компонента
6.6.4 Поток управления (ключевые сценарии)
Сценарий «Проведение ФИ и создание базовой версии»
Ведущий инспектор получает уведомление о готовности ЗИ и переходит по ссылке.
UI отправляет GET-запрос к /api/formal-inspections/scope?cr_id=... для загрузки данных инспекции.
Backend (FormalInspectionService) вызывает функцию load_fi_scope(cr_id):
Запрашивает у ArtifactService карточки всех артефактов, связанных с данным ЗИ (через get_artifact_card).
Возвращает список артефактов с их текущими рабочими версиями и описанием изменений.
UI отображает панель ведения протокола ФИ. Ведущий может добавлять участников (через форму приглашения) и начинать инспекцию.
В ходе инспекции участники фиксируют несоответствия:
UI отправляет POST-запрос к /api/protocols/{protocol_id}/nonconformities с данными {artifact_id, description, status} (начальный статус обычно «открыто»).
Backend вызывает функцию add_nonconformity(...) и сохраняет запись в nonconformities.
При возникновении спорной ситуации создаётся сообщение о проблеме (СП):
UI отправляет POST-запрос к /api/problem-reports с {nc_id, created_by}.
Backend создаёт запись в problem_reports и, при необходимости, уведомляет совет по управлению изменениями.
По окончании обсуждения ведущий принимает решение:
UI отправляет POST-запрос к /api/protocols/{protocol_id}/decide с {decision, user_id} (decision = 'accepted' или 'rework').
Backend (FormalInspectionService) вызывает функцию decide_fi(protocol_id, decision, user_id):
Если decision='accepted':
Проверяет наличие несоответствий со статусом «открыто» или «не устранено» для каждого проверяемого артефакта. Если такие есть, возвращает ERR_STATE_TRANSITION.
Для каждого артефакта вызывает ArtifactService.create_baseline(artifact_id, user_id), которая создаёт новую базовую версию.
Сохраняет протокол с итоговым решением.
Вызывает notify_baseline_created(project_id, artifact_ids, recipients) для уведомления авторов и участников.
Если decision='rework':
Сохраняет протокол, базовые версии не создаются.
Отправляет уведомление автору о необходимости доработки (через NotificationService).
UI отображает результат и, в случае успеха, перенаправляет к обновлённому списку артефактов.
6.7 Компонент поиска и фильтрации (SearchService)
6.7.1 Назначение компонента
Обеспечивает поиск и фильтрацию артефактов.
6.7.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
list_filtered(filter_criteria : {param : string}, search_query : string, page : int (default = 10)
Фукнция list_filtered(filter_criteria : {param : string}, search_query : string, page : int (default = 10) , size : int (default :1)) должна создать спецификацию к БД по параметрам, произвести и вернуть выборку артефактов
LLR_SearchService_ListFiltered
search_artifacts(project_id: str, query: str)
UI должен предоставлять строку контекстного поиска по названию, описанию и значениям пользовательских атрибутов
LLR_SearchService_ContextSearch
Таблица 23 — Операции компонента
6.7.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_SearchService_ContextSearch
Б
REQ_SW-9-001
Контекстный поиск в «Артефактах»
LLR_SearchService_FilterButton
Ф
DER-REQ-9-002
Кнопка «Настроить фильтры»
LLR_SearchService_FilterPanel
Ф
REQ_SW-9-003
Элементы фильтрации артефактов
LLR_SearchService_ListFiltered
Ф
REQ_SW-9-003
Фильтрация, поиск и пагинация артефактов
Таблица 24 — LLR компонента
6.7.4 Поток управления (ключевые сценарии)
Сценарий «Фильтрация и поиск артефактов»
Пользователь в разделе «Артефакты» открывает панель фильтров (кнопка «Настроить фильтры») и задаёт критерии (тип артефакта, статус, пользовательские атрибуты) и/или вводит поисковый запрос в строку контекстного поиска.
UI формирует запрос к API: GET /api/artifacts?project_id=...&filters=...&search=...&page=...&size=....
Backend (ArtifactService) получает запрос и, поскольку фильтрация и поиск делегированы SearchService, вызывает функцию SearchService.list_filtered(filter_criteria, search_query, page, size).
SearchService строит параметризованный запрос к БД:
Применяет фильтры к полям artifact_type, status, а также к значениям пользовательских атрибутов через соединение с custom_attr_values.
Выполняет полнотекстовый поиск по полям title, description и значениям пользовательских атрибутов (если задан search_query).
Поддерживает пагинацию.
Возвращает {total, items: [...]} в ArtifactService.
ArtifactService дополняет каждый элемент информацией о наличии рабочей версии (has_working_version) и текущем статусе жизненного цикла (например, через запрос к artifact_versions).
ArtifactService возвращает итоговый список UI.
UI отображает таблицу артефактов с учётом фильтров и поиска.
6.8 Компонент экспорта (ExportService)
6.8.1 Назначение компонента
Обеспечивает экспорт выбранных спецификаций/разделов в PDF/DOCX/CSV.
6.8.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
export_specification(..., format=...)
UI экспорта должен отображать кнопки: «Экспорт в PDF», «Экспорт в DOCX», «Экспорт в CSV»
ERR_EXPORT_FAILED
LLR_ExportService_ExportButtons, LLR_ExportService_ExportGenerateDownload, LLR_ExportService_ExportScope
Таблица 255 — Операции компонента
6.8.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_ExportService_ExportScope
Б
REQ_SW-9-004
Экспорт выбранной спецификации или её части
LLR_ExportService_ExportButtons
Ф
DER-REQ-9-005
Кнопки экспорта PDF/DOCX/CSV
LLR_ExportService_ExportGenerateDownload
Б
REQ_SW-9-006
Формирование файла и загрузка
Таблица 26 — LLR компонента
6.8.4 Поток управления (ключевые сценарии)
Сценарий «Экспорт спецификации»
Пользователь в разделе артефактов выбирает одну или несколько спецификаций (или разделов) и нажимает кнопку экспорта, например «Экспорт в PDF».
UI отправляет POST-запрос к /api/export с телом {project_id, artifact_ids, format='pdf'}.
Backend (ExportService) вызывает функцию export_specification(project_id, artifact_ids, format):
Для каждого artifact_id вызывает ArtifactService.get_artifact_card(artifact_id) для получения полных данных артефакта, включая содержимое текущей версии.
Вызывает ProjectService.get_project(project_id) для получения метаданных проекта (название, описание).
На основе собранных данных генерирует документ в запрошенном формате (используя шаблоны и библиотеки, например ReportLab для PDF).
Если в процессе генерации возникает ошибка (например, недоступность шаблона), возвращает ERR_EXPORT_FAILED.
Возвращает сгенерированный файл в теле ответа с соответствующими HTTP-заголовками (Content-Disposition).
UI принимает файл и инициирует его скачивание браузером.
6.9 Компонент трассировки с кодом (GitHubTraceService)
6.9.1 Назначение компонента
Обеспечивает трассировку «артефакт—код» через GitHub и просмотр фрагментов кода.
6.9.2 Основные операции (Backend)
Операция
Назначение (кратко)
Ошибки
Связанные LLR
create_code_link(artifact_version_id, repo, path, start_line, end_line, link_type, comment)
Окно выбора фрагмента кода должно содержать кнопки «Сохранить связь» и «Отмена»
LLR_GitHubTraceService_SelectDialogButtons
delete_code_link(code_link_id: str, user_id: str)
Функция delete_code_link(code_link_id: str, user_id: str) должна удалить запись связи из БД и записать событие в audit_log
ERR_NOT_FOUND
LLR_GitHubTraceService_DeleteLink
list_code_links(artifact_id: str, artifact_version_id: str)
Функция list_code_links(artifact_id: str, artifact_version_id: str) должна возвращать только связи выбранной версии
LLR_GitHubTraceService_VersionIsolation
view_code_snippet(code_link_id: str)
Функция view_code_snippet(code_link_id: str) должна, используя сохранённые параметры связи (repo, path, commit/branch, start_line, end_line), запросить содержимое файла из GitHub и вернуть только указанный диапазон строк
ERR_EXTERNAL_SERVICE_UNAVAILABLE
LLR_GitHubTraceService_ViewSnippet
Таблица 27 — Операции компонента
6.9.3 Требования низкого уровня (LLR)
LLR ID
Тип
Основание (DER-REQ)
Название
LLR_GitHubTraceService_CodeTabTable
Ф
REQ_SW-10-001
Таблица связей «артефакт—код»
LLR_GitHubTraceService_TableActions
Ф
DER-REQ-10-002
Действия «Просмотреть» и «Удалить» в таблице
LLR_GitHubTraceService_AddLinkButton
Ф
DER-REQ-10-003
Кнопка «Добавить связь с кодом»
LLR_GitHubTraceService_EmptyState
Ф
REQ_SW-10-004
Сообщение при отсутствии связей с кодом
LLR_GitHubTraceService_VersionIsolation
Б
REQ_SW-10-005; REQ_SW-10-006
Изоляция связей по версии артефакта
LLR_GitHubTraceService_ViewSnippet
Б
REQ_SW-10-007
Просмотр фрагмента кода по сохранённым параметрам связи
LLR_GitHubTraceService_DeleteLink
Б
REQ_SW-10-008
Удаление связи «артефакт—код» из БД
LLR_GitHubTraceService_OpenSelectDialog
Ф
REQ_SW-10-009
Открытие окна «Выбор фрагмента кода»
LLR_GitHubTraceService_SelectDialogFields
Ф
DER-REQ-10-010
Состав окна «Выбор фрагмента кода»
LLR_GitHubTraceService_SelectDialogVersionInfo
Ф
DER-REQ-10-011
Отображение версии артефакта в окне выбора
LLR_GitHubTraceService_SelectDialogButtons
Ф
DER-REQ-10-012
Кнопки «Сохранить связь» и «Отмена»
Таблица 28 — LLR компонента
6.9.4 Поток управления (ключевые сценарии)
Сценарий «Просмотр фрагмента кода»
Пользователь в карточке артефакта на вкладке «Связи с кодом» нажимает «Просмотреть» для одной из связей.
UI отправляет GET-запрос к /api/code-links/{id}/snippet.
Backend (GitHubTraceService) вызывает функцию view_code_snippet(code_link_id):
Извлекает из БД параметры связи: repo, path, commit_or_branch, start_line, end_line.
Обращается к GitHub API (с использованием сохранённого токена доступа) для получения содержимого файла по указанному пути и коммиту/ветке.
Выделяет строки с start_line по end_line.
При ошибке доступа к GitHub возвращает ERR_EXTERNAL_SERVICE_UNAVAILABLE.
Возвращает фрагмент кода и диапазон строк.
UI отображает фрагмент кода в модальном окне.
Сценарий «Добавление связи с кодом»
Пользователь нажимает «Добавить связь с кодом» над таблицей связей.
UI открывает диалог «Выбор фрагмента кода», который содержит:
выпадающий список репозиториев проекта;
дерево файлов и каталогов выбранного репозитория;
панель просмотра содержимого выбранного файла с нумерацией строк;
поля ввода начальной и конечной строки;
поле выбора типа связи;
поле комментария (опционально);
информацию о версии артефакта, с которой будет связан код.
Пользователь выбирает фрагмент, заполняет поля и нажимает «Сохранить связь».
UI отправляет POST-запрос к /api/code-links с телом {artifact_version_id, repo, path, start_line, end_line, link_type, comment}.
Backend (GitHubTraceService) вызывает функцию create_code_link(...):
Проверяет существование указанной версии артефакта (через ArtifactService).
Создаёт запись в таблице code_links.
Записывает действие в аудит-лог через AdminService.log_action.
Возвращает code_link_id.
UI обновляет таблицу связей, добавляя новую запись.
Сценарий «Удаление связи с кодом»
Пользователь в таблице связей нажимает «Удалить» для одной из записей.
UI отправляет DELETE-запрос к /api/code-links/{id}.
Backend (GitHubTraceService) вызывает функцию delete_code_link(code_link_id, user_id):
Проверяет, что связь существует (иначе ERR_NOT_FOUND).
Удаляет запись из таблицы code_links.
Логирует действие в аудит-лог.
UI удаляет строку из таблицы.
7 Трассируемость требований
7.1 Связь производных требований с требованиями низкого уровня
Производные требования (DER‑REQ) определены в программных требованиях. НУ требования ссылаются на ПТ в поле «Основание». Таблица 27 содержит матрицу соответствия DER‑REQ и LLR.
DER-REQ
LLR (реализация)
Текст DER-REQ (кратко)
DER-REQ-1-001
LLR_AuthService_RegisterClient
Форма регистрации должна содержать следующие поля для ввода данных: Поле для ввода: Ваше имя (п. 1.1.1) Поле для ввода: Ваша Фамилия (п. 1.1.2) Поле для ввода: Логин (п. 1.1.3) Поле для ввода: Email (п. 1.1.4) Поле для ввода: Пароль (п. 1.1.5) Поле для ввода: Повторение пароля (п. 1.1.6) Флаг: Я администратор (п. 1.1.7)
DER-REQ-1-002
LLR_AuthService_RegisterServer_01, LLR_AuthService_RegisterServer_02
Введенные в форме регистрации данные должны проверяться инструментами валидации на соответствие следующим условиям: Отсутствие запрещенных символов в полях 1.1.1 и 1.1.2 (только кириллица) Данные в поле 1.1.5 должны соответствовать шаблонам написания электронной почты Данные в полях 1.1.5 и 1.1.6 должны совпадать Данные в поле 1.1.3 не должны были использоваться ранее
DER-REQ-1-003
LLR_AuthService_RegisterClient, LLR_AuthService_RegisterClient_Validation
Страница регистрации должна содержать кнопку для регистрации нового пользователя (п. 1.1.8)
DER-REQ-1-004
LLR_AuthService_RegisterServer_03
Информация из формы регистрации должна сохраняться в базе данных, и должен отправляться соответствующий запрос на изменение БД
DER-REQ-1-005
LLR_AuthService_RegisterServer_04
После успешного создания учетной записи на указанный адрес электронной почты должно отправляться автоматическое уведомление, содержащее ссылку для подтверждения адреса электронной почты
DER-REQ-1-006
LLR_AuthService_ConfirmEmail
После перехода по ссылке для подтверждения адреса электронной почты должна открываться соответствующая страница с профилем - личный кабинет (интерфейс 3)
DER-REQ-1-007
LLR_AuthService_RegisterServer_05
В случае наличия флага администратора (1.1.7) система должна предоставлять пользователю права администратора
DER-REQ-2-001
LLR_AuthService_LoginClient
Форма аутентификации должна содержать следующие поля для ввода данных: Поле для ввода: Логин (п. 2.1.1) Поле для ввода: Пароль (п. 2.1.2)
DER-REQ-2-002
LLR_AuthService_LoginClient
Страница аутентификации должна содержать кнопки для входа (п. 2.1.3) и регистрации (п. 2.1.4)
DER-REQ-2-003
LLR_AuthService_LoginServer
После нажатия кнопки Вход (2.1.3) сервер должен отправлять запрос в БД для проверки существования введенных данных
DER-REQ-2-004
LLR_AuthService_LoginServer
В случае существования введенных для аутентификации данных система должна открывать страницу личного кабинета (интерфейс 3). В противном случае должна отобразиться ошибка
DER-REQ-2-005
LLR_AuthService_LoginClient
При нажатии на кнопку Регистрации (2.1.4) должен осуществляться переход на страницу регистрации (интерфейс 1)
DER-REQ-3-001
LLR_ProfileService_View
Страница личного кабинета должна содержать информацию о правах пользователя и уведомления об изменениях артефактов с ссылками на них
DER-REQ-3-002
LLR_ProfileService_View
Страница личного кабинета должна содержать следующие данные: Поле с данными: Имя (3.1.1) Поле с данными: Фамилия (3.1.2) Поле с данными: Логин (3.1.3) Поле с данными email (3.1.4)
DER-REQ-3-003
LLR_ProfileService_Edit, LLR_ProfileService_Update
Поля с данными 3.1.1, 3.1.2, 3.1.4 должны быть доступными для редактирования
DER-REQ-3-004
LLR_ProfileService_Edit
Страница личного кабинета должна содержать кнопку “Сохранить” (3.1.5)
DER-REQ-3-005
LLR_ProfileService_SaveButton
При отсутствии изменений в полях (3.1.1, 3.1.2, 3.1.4) кнопка (3.1.5) должна быть неактивной
DER-REQ-3-006
LLR_ProfileService_SaveButton
В случае изменений хотя бы в одном из полей (3.1.1, 3.1.2, 3.1.4) кнопка (3.1.5) должна быть активной
DER-REQ-3-007
LLR_ProfileService_EditValidation
Измененные данные должны проверяться инструментами валидации на соответствие следующим условиям: Отсутствие запрещенных символов в полях “Ваше имя” и “Ваша фамилия” (только кириллица) Правильность написания адреса электронной почты
DER-REQ-3-008
LLR_ProfileService_Update
В случае изменений в полях и при нажатии на кнопку (3.1.5) в БД должен отправляться соответствующий запрос на изменение данных
DER-REQ-3-009
LLR_ProfileService_AdminZoneButton
Если пользователь имеет доступ к админ-зоне проекта, то у него должна быть кнопка "Настройки проектов" (3.1.6.)
DER-REQ-4-001
LLR_AdminService_Tabs
Раздел «Администрирование» должен включать вкладки: "Проекты" (4.1.0) "Пользователи проекта"(4.1.1), «Роли и функции»(4.1.2), «Управление артефактами»(4.1.3), «Журнал действий»(4.1.4).
DER-REQ-4-002
LLR_AdminService_AuditLog_Filter
ПО (4.1.4) должно предоставлять фильтрацию по пользователю, типу действия, артефакту, диапазону дат
DER-REQ-5-001
LLR_ProjectService_SidebarProjects
ПО должно отображать в боковой панели список проектов, доступных текущему пользователю
DER-REQ-5-002
LLR_ProjectService_ProjectList
В разделе Проекты ПО должно отображать пользователю список доступных ему проектов. Список проектов должен содержать для каждого проекта следующую информацию : наименование проекта код проекта
DER-REQ-5-003
LLR_ProjectService_OpenDescription
ПО должно открывать описание проекта при нажатии на него левой кнопкой мыши
DER-REQ-7-001
LLR_ChangeRequestService_ReadyForFI
После нажатия на кнопку "Готово к ФИ" (7.1.1.) ПО должно отправлять уведомление ведущему и в подразделе (5.1.2) должно появляться новое ЗИ со статусом "Ожидает ФИ"
DER-REQ-8-004
LLR_FormalInspectionService_InviteForm
Интерфейс подготовки ФИ ПО должен обеспечивать заполнение письма-приглашения, включая: ссылку на запрос на изменение; список участников и их роли; пользовательские атрибуты, определённые администратором проекта
DER-REQ-8-006
LLR_FormalInspectionService_OpenProtocolPanel
Кнопка «Создать протокол ФИ» ПО (8.1.1) должна открывать панель ведения протокола формальной инспекции
DER-REQ-9-002
LLR_SearchService_FilterButton
Рядом со строкой поиска должна быть кнопка "Настроить фильтры"(9.1.1)
DER-REQ-9-005
LLR_ExportService_ExportButtons
Для экспорта должны быть доступны следующие кнопки: «Экспорт в PDF»(9.1.2), «Экспорт в DOCX»(9.1.3.), «Экспорт в CSV» (9.1.4.)
DER-REQ-10-002
LLR_GitHubTraceService_TableActions
В таблице связей ПО должны быть доступны действия: «Просмотреть» — для просмотра фрагмента кода; (10.1.1) «Удалить» — для удаления связи. (10.1.2)
DER-REQ-10-003
LLR_GitHubTraceService_AddLinkButton
Над таблицей связей ПО должны отображаться кнопки « Добавить связь с кодом» (10.1.3)
LLR_GitHubTraceService_SelectDialogFields
Окно «Выбор фрагмента кода» должно содержать: выпадающий список репозиториев проекта; дерево файлов и каталогов репозитория; панель просмотра содержимого выбранного файла с нумерацией строк; поля ввода начальной и конечной строки; поле выбора типа связи; поле комментария (опционально)
DER-REQ-10-011
LLR_GitHubTraceService_SelectDialogVersionInfo
В окне «Выбор фрагмента кода» ПО должно предоставить пользователю информацию о версии артефакта, с которой будет связана выбранная часть кода
DER-REQ-10-012
LLR_GitHubTraceService_SelectDialogButtons
В окне «Выбор фрагмента кода» ПО должны быть доступны кнопки «Сохранить связь» и «Отмена»
Таблица 29 — Трассируемость производных требований на требования НУ
7.2 Распределение системных требований по компонентам
Системные требования задают требования к системе в целом. На уровне проектных решений они распределяются по компонентам. Таблица 30 содержит предварительное распределение системных требований по компонентам верхнего уровня.
REQ-SYS
Компоненты (ожидаемо)
Текст требования
REQ-SYS-001
AdminService, ArtifactService, AuthService, ChangeRequest/Versioning, FormalInspection/ProblemReport, ProjectService
Система должна позволять авторизованному пользователю создавать артефакты разных типов(после разрешения администратором проекта), определенных в глоссарии: спецификация, требование, раздел спецификации, запрос на изменение, проект, протокол формальной инспекции
REQ-SYS-002
ArtifactService, FormalInspection/ProblemReport
Система должна присваивать каждому артефакту уникальный неизменяемый внутренний идентификатор. После удаления артефакта этот идентификатор не должен использоваться повторно
REQ-SYS-003
AdminService, ArtifactService, ChangeRequest/Versioning
Система должна позволять пользователю после создания ЗИ вносить изменения в содержимое артефакта и сохранять эти изменения как новую «рабочую версию» этого артефакта, которая должна включать: автора изменения время изменения содержимое версии значения пользовательских атрибутов на момент изменения (опционально)
REQ-SYS-004
ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport
Система должна позволять пользователю инициировать удаление артефакта, находящегося в состоянии «базовая версия», только через создание запроса на изменение (ЗИ). Окончательное удаление артефакта должно выполняться системой после утверждения ЗИ и прохождения артефактом процесса формальной инспекции. Удалённые артефакты не должны использоваться повторно, но должны сохраняться в истории изменений в виде архивных версий
REQ-SYS-005
AdminService, ArtifactService
Система должна позволять пользователю добавлять, изменять, удалять пользовательские атрибуты для любого типа артефакта, если он имеет доступ к этим функциям системы
REQ-SYS-006
AdminService, ArtifactService
Система должна сохранять всю историю изменений любого артефакта или набора артефактов как ЕК, содержащую информацию о пользователе, который внес изменение, времени создания и последнего изменения, предыдущих версиях, а также значения пользовательских атрибутов на момент изменения
REQ-SYS-007
ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport
Система должна создавать рабочую версию ЕК при внесении изменений в содержимое артефактов после создания ЗИ и создании артефакта без ЗИ. Система должна создавать базовую версию артефакта после проведения ФИ, если не было найдено несоответствий и не возникло конфликтов между инспекторам(и) и автором. Система должна хранить рабочие и базовые версии всех ЕК
REQ-SYS-008
AdminService, ArtifactService, FormalInspection/ProblemReport, ProjectService
Система должна позволять администратору проекта определять шаблоны для генерации идентификаторов артефактов. Система должна присваивать идентификаторы вновь создаваемым артефактам в соответствии с активным шаблоном
REQ-SYS-009
AdminService, ArtifactService, ProjectService
Система должна предоставлять пользователям доступ к данным проекта и функциям системы в зависимости от того, какими функциями администратор проекта разрешил пользоваться
REQ-SYS-010
AdminService, ArtifactService, ChangeRequest/Versioning, ProjectService, TraceLink
Система должна позволять пользователю с ролью администратор проекта создавать, просматривать и удалять связи трассировки между артефактами. Система должна предоставлять возможность создавать пользовательский тип связи
REQ-SYS-011
AdminService, ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport
Система должна позволять создавать ЗИ с встроенными атрибутами: обоснование изменения цель изменения список затрагиваемых артефактов описание планируемых изменений исполнитель(и) изменений Система должна позволять пользователю создавать ЗИ с пользовательскими атрибутами опционально
REQ-SYS-012
AdminService, ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport
Система должна позволять проводить ФИ артефактов и фиксировать её результаты в протоколе ФИ. Система должна сохранять протокол ФИ, содержащий: проверенные артефакты и версии, выявленные несоответствия, принятые решения, участников и дату дополнительно пользовательские атрибуты Система должна позволять инспекционной группе принять одно из решений: «принять» (утверждение базовой версии) «доработать» (нахождение несоответствий или создание СП) Система должна позволять пользователям вносить изменения в артефакты, для которых ещё не установлена ни одна базовая версия, без создания ЗИ. Для артефактов, имеющих базовую версию, изменение должно быть возможно только после создание ЗИ
REQ-SYS-013
AdminService, ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport, TraceLink
Система должна: обеспечивать создание СП при возникновении разногласий между инспектором и автором обеспечивать передачу СП на рассмотрение Совету по управлению изменениями позволять создавать ЗИ для принятых СП для сохранения альтернативного решения обеспечивать трассируемость между СП, ЗИ, артефактами и протоколами ФИ блокировать утверждение базовых версий при наличии неразрешенных СП хранить историю решений по каждому СП
REQ-SYS-014
AdminService, ArtifactService, ProjectService
Система должна позволять администратору проекта настраивать жизненный цикл для всех управляемых артефактов, включая: набор состояний артефакта правила переходов между состояниями ограничения на выполнение переходов на основе функций/прав доступа пользователей автоматические действия, выполняемые при переходах
REQ-SYS-015
ArtifactService, FormalInspection/ProblemReport
Система должна перевести рабочие версии всех измененных ЕК в новые базовые версии, если в процессе ФИ было разрешено внести изменения, нет конфликтов и несоответствий
REQ-SYS-016
ArtifactService, FormalInspection/ProblemReport
Система должна сохранять протокол проведенной ФИ как отдельный артефакт, содержащий: список проверенных ЕК и их версий, перечень выявленных несоответствий, ссылки на созданные по результатам несоответствий СП, итоговое решение ФИ («принято», «отклонено»), дату и участников инспекции
REQ-SYS-017
AdminService, ArtifactService, FormalInspection/ProblemReport, ProjectService
Система должна вести учет состояния конфигурации и предоставлять данные для отчетов, отражающие состояние управляемых артефактов проекта
REQ-SYS-018
AdminService, ArtifactService, SearchService
Система должна позволять пользователю искать артефакты по названию, описанию и значениям пользовательских атрибутов
REQ-SYS-019
AdminService, ArtifactService, FormalInspection/ProblemReport, SearchService
Система должна позволять пользователю фильтровать артефакты по типу, статусу, пользователям и пользовательским атрибутам
REQ-SYS-020
ExportService, FormalInspection/ProblemReport
Система должна позволять пользователю экспортировать спецификации и отчёты в PDF, DOCX и CSV
REQ-SYS-021
AdminService, ArtifactService
Система должна позволять администратору проекта добавлять/удалять пользователей проекта и предоставлять им доступ к функциям системы
REQ-SYS-022
ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport, TraceLink
Система должна во время проведения ФИ предоставлять пользователям, участвующим в инспекции, следующие функции: просмотр рабочей и базовых версий проверяемых артефактов просмотр связанных артефактов по трассировочным связям создание и редактирование несоответствий создание сообщений о проблеме (СП) при спорных ситуациях просмотр и анализ ЗИ, относящихся к проверяемым артефактам принятие решения по несоответствиям принятие итогового решения по ФИ
REQ-SYS-023
ArtifactService, ProfileService
Система должна уведомлять пользователей, которые принимали участие в создании, изменении и рассмотрении изменений артефакта, о смене его базовой версии
REQ-SYS-024
ArtifactService, TraceLink
Система должна хранить тесты, результаты тестов и связывать их с версиями требований и кода.
REQ-SYS-025
ArtifactService
Система должна журналировать действия пользователей, влияющие на состояние артефактов
REQ-SYS-026
ArtifactService, FormalInspection/ProblemReport, TraceLink
Система должна позволять регистрировать несоответствия, связанные с проверяемыми артефактами, в ходе ФИ. Система должна поддерживать следующие состояния несоответствия: «открыто» «снято» «заметка» «устранено» «не устранено» Система должна хранить текущее состояние каждого несоответствия и историю изменений состояний
REQ-SYS-027
ArtifactService, FormalInspection/ProblemReport
Система должна запрещать установление базовой версии артефакта, если по данному артефакту существуют несоответствия со статусом «открыто» или «не устранено». Система должна разрешать установление базовой версии артефакта при наличии несоответствий со статусом «устранено», «снято» или «заметка» , если по ним не требуется внесение изменений
REQ-SYS-028
AdminService, ArtifactService, ChangeRequest/Versioning, FormalInspection/ProblemReport
Система должна обеспечивать возможность создания запроса на изменение (ЗИ) для устранения несоответствий, выявленных в ходе формальной инспекции позволять создать ЗИ артефактов с несоответствиями со статусом «открыто» или «не устранено» предлагать создание ЗИ после завершения формальной инспекции, если в ходе проверки были выявлены несоответствия, требующие исправления
Таблица 30 — Системные требования и компоненты
8 Связь с планами проекта
8.1 План разработки
План разработки устанавливает порядок выполнения процессов и перечень входных/выходных данных. ОП ПО обновляется при изменениях требований или при выявлении несоответствий в ходе верификации и используется как основной вход при кодировании.
8.2 План верификации
План верификации определяет методы проверки и входные данные процесса верификации, среди которых присутствует ОП ПО. Для ОП ПО основным мероприятием является формальная инспекция. Результаты верификации (СП, протокол ФИ) могут приводить к повторной итерации проектирования.
8.3 План управления конфигурацией
План УК ПО регламентирует хранение артефактов в Gitlab, роли участников, процедуру работы через issue/merge request, а также установление базовых версий. ОП ПО является единицей конфигурации и подлежит ревью и верификации перед выпуском базовой версии.