Базовая версия
2026-03-20T18:37:01+00:00
Вкладка 1 НИЯУ МИФИ Программные требования к системе управления требованиями Команда №3 Москва, 2025 1. Введение 1.1 Назначение Документ определяет программные требования к веб-системе управления требованиями (далее – Система), предназначенной для: хранения и версионирования артефактов (требования, спецификации, разделы, ЗИ, тесты, результаты тестов, протоколы ФИ и др.); управления запросами на изменение; проведения формальной инспекции; управления несоответствиями и СП; ведения трассировки между артефактами; настройки жизненного цикла артефактов и прав доступа пользователей. 1.2 Общее положение Спецификация описывает требования к отдельным процессам/интерфейсам, аналогично примеру спецификации для учебной платформы SQL (таблицы с требованиями FE/BE и макеты интерфейсов). 2.1. Функции системы управления требованиями. Создавать артефакты разных типов. Просматривать артефакты. Вносить изменения в артефакты. Удалять артефакты (через ЗИ). Просматривать историю изменений артефакта. Добавлять пользовательские атрибуты к артефактам. Изменять атрибуты. Удалять атрибуты. Вносить изменения, создавая новую версию артефакта. Настраивать шаблоны идентификаторов. Добавлять пользователей. Удалять пользователей. Назначать права пользователям. Создавать связи трассировки. Просматривать связи. Удалять связи. Создавать пользовательские типы связей. Создавать запросы на изменение. Указывать встроенные атрибуты ЗИ. Добавлять пользовательские атрибуты в ЗИ. Проводить формальную инспекцию артефактов. Просматривать рабочие и базовые версии артефактов. Просматривать связанные артефакты. Создавать несоответствия. Редактировать несоответствия. Создавать сообщения о проблеме (СП). Просматривать относящиеся ЗИ. Принимать решения по несоответствиям(присваивать статусы). Принимать итоговое решение по ФИ (принять/доработать). Создавать сообщения о проблеме. Отправлять СП на рассмотрение. Создавать ЗИ из СП (по результатам). Настраивать состояния артефактов. Настраивать правила переходов. Настраивать ограничения по ролям. Настраивать автоматические действия. Просматривать состояние конфигурации. Просматривать отчёты. Искать артефакты по названию. Искать артефакты по описанию. Искать артефакты по атрибутам. Фильтровать артефакты по типу. Фильтровать артефакты по статусу. Фильтровать артефакты по пользователю Фильтровать артефакты по атрибутам Экспортировать спецификации в PDF Экспортировать спецификации в DOCX Экспортировать спецификации в CSV Получать уведомления об изменении базовой версии Просматривать тесты Просматривать результаты тестов Просматривать журнал действий Регистрировать несоответствия Изменять статус несоответствия Создавать ЗИ для устранения несоответствий 2.2. Глоссарий. Понятие Определение 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. 3. Программные требования Таблица1. Требования к процессу регистрации (соответствует интерфейсу 1) Идентификационный номер Требование Обоснование/ ссылки DER-REQ-1-001 Форма регистрации должна содержать следующие поля для ввода данных: Поле для ввода: Ваше имя (п. 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 Введенные в форме регистрации данные должны проверяться инструментами валидации на соответствие следующим условиям: Отсутствие запрещенных символов в полях 1.1.1 и 1.1.2 (только кириллица) Данные в поле 1.1.5 должны соответствовать шаблонам написания электронной почты Данные в полях 1.1.5 и 1.1.6 должны совпадать Данные в поле 1.1.3 не должны были использоваться ранее Обоснование: для обеспечения безопасности данных пользователя и его проектов DER-REQ-1-003 Страница регистрации должна содержать кнопку для регистрации нового пользователя (п. 1.1.8) Обоснование: для отправки данных в БД DER-REQ-1-004 Информация из формы регистрации должна сохраняться в базе данных, и должен отправляться соответствующий запрос на изменение БД Обоснование: информация о новом пользователе должна сохраняться в системе DER-REQ-1-005 После успешного создания учетной записи на указанный адрес электронной почты должно отправляться автоматическое уведомление, содержащее ссылку для подтверждения адреса электронной почты. Обоснование: для подтверждения личности пользователя DER-REQ-1-006 После перехода по ссылке для подтверждения адреса электронной почты должна открываться соответствующая страница с профилем - личный кабинет (интерфейс 3) Обоснование: после подтверждения личности должен создаться аккаунт для пользователя DER-REQ-1-007 В случае наличия флага администратора (1.1.7) система должна предоставлять пользователю права администратора Обоснование: аккаунт с правом администратрора должен создаваться при регистрации Таблица 2. Требования к процессу авторизации (соответствует интерфейсу 2) Идентификационный номер Требование Обоснование/ ссылки DER-REQ-2-001 Форма аутентификации должна содержать следующие поля для ввода данных: Поле для ввода: Логин (п. 2.1.1) Поле для ввода: Пароль (п. 2.1.2) Обоснование: для предоставления доступа пользователя к данным проекта DER-REQ-2-002 Страница аутентификации должна содержать кнопки для входа (п. 2.1.3) и регистрации (п. 2.1.4) Обоснование: для проверки данных при входе, если аккаунт существует и перехода на страницу регистрации, если аккаунта не существует DER-REQ-2-003 После нажатия кнопки Вход (2.1.3) сервер должен отправлять запрос в БД для проверки существования введенных данных Обоснование: для проверки логина и пароля пользователя DER-REQ-2-004 В случае существования введенных для аутентификации данных система должна открывать страницу личного кабинета (интерфейс 3). В противном случае должна отобразиться ошибка. Обоснование: для входа в систему DER-REQ-2-005 При нажатии на кнопку Регистрации (2.1.4) должен осуществляться переход на страницу регистрации (интерфейс 1) Обоснование: для создания нового аккаунта Таблица 3. Требования к процессу изменения данных личного кабинета (соответствует интерфейсу 3) Идентификационный номер Требование Обоснование/ ссылки DER-REQ-3-001 Страница личного кабинета должна содержать информацию о правах пользователя и уведомления об изменениях артефактов с ссылками на них. Обоснование: для отображения данных, касаемых пользователя DER-REQ-3-002 Страница личного кабинета должна содержать следующие данные: Поле с данными: Имя (3.1.1) Поле с данными: Фамилия (3.1.2) Поле с данными: Логин (3.1.3) Поле с данными email (3.1.4) Обоснование: для просмотра данных о пользователе другими пользователями в случае необходимости связаться DER-REQ-3-003 Поля с данными 3.1.1, 3.1.2, 3.1.4 должны быть доступными для редактирования Обоснование: для предоставления пользователю возможности редактировать данные DER-REQ-3-004 Страница личного кабинета должна содержать кнопку “Сохранить” (3.1.5) Обоснование: для обновления данных в БД DER-REQ-3-005 При отсутствии изменений в полях (3.1.1, 3.1.2, 3.1.4) кнопка (3.1.5) должна быть неактивной Обоснование: так как нет данных для обновления, кнопка не нужна DER-REQ-3-006 В случае изменений хотя бы в одном из полей (3.1.1, 3.1.2, 3.1.4) кнопка (3.1.5) должна быть активной Обоснование: так как появляются данные для обновления в БД DER-REQ-3-007 Измененные данные должны проверяться инструментами валидации на соответствие следующим условиям: Отсутствие запрещенных символов в полях “Ваше имя” и “Ваша фамилия” (только кириллица) Правильность написания адреса электронной почты Обоснование: для обеспечения корректности данных DER-REQ-3-008 В случае изменений в полях и при нажатии на кнопку (3.1.5) в БД должен отправляться соответствующий запрос на изменение данных Обоснование: для обновления данных в БД DER-REQ-3-009 Если пользователь имеет доступ к админ-зоне проекта, то у него должна быть кнопка "Настройки проектов" (3.1.6.) Обоснование: для предоставления возможности настраивать пользовательские атрибуты артефактов, удалять и добавлять людей, настаивать их права и тд Таблица 4. Требования к администрированию проекта (соответствует интерфейсу 4) Идентификационный номер Требование Обоснование/ ссылки DER-REQ-4-001 Раздел «Администрирование» должен включать вкладки: "Проекты" (4.1.0) "Пользователи проекта"(4.1.1), «Роли и функции»(4.1.2), «Управление артефактами»(4.1.3), «Журнал действий»(4.1.4). Обоснование: для разделения логики для раздела Администрирование REQ_SW-4-002 Для пользователей с правом администрирования должна отображаться кнопка «Создать проект» в подразделе (4.1.0) . REQ-SYS-001 REQ_SW-4-003 ПО (4.1.0) при создании проекта должно предоставить форму с полями: название, описание, и создать артефакт «Проект». После создания Проект появится на боковой панели слева, где можно будет редактировать Описание, Спецификации (см. ). REQ-SYS-001 REQ_SW-4-004 ПО (4.1.1) должно отображать таблицу пользователей с полями: ФИО, логин, email, назначенные функции/роли, статус, кнопки «Добавить» и «Удалить», обеспечивать администратору проекта возможность добавления и удаления пользователей, связанных с проектом, в (4.1.1). REQ-SYS-021 REQ_SW-4-005 ПО (4.1.2) должно обеспечить возможность отметить разрешенными функции (права) для каждого участника проекта. REQ-SYS-009 REQ_SW-4-006 ПО (4.1.3) должно предоставлять редактор пользовательских атрибутов для каждого вида артефакта в виде таблицы с полями: тип атрибута, поле, комментарий. REQ-SYS-005 REQ_SW-4-007 ПО (4.1.4) должно журналировать действия пользователей, влияющие на состояние артефактов (создание/изменение/удаление, изменение версии или трассировочной ссылки, участие в ЗИ, ФИ, создание СП). REQ-SYS-025 DER-REQ-4-002 ПО (4.1.4) должно предоставлять фильтрацию по пользователю, типу действия, артефакту, диапазону дат. Обоснование: для обеспечения удобства просмотра данных журналирования Таблица 5. Требования к процессу управления проектами (соответствует интерфейсу 5 ) Идентификационный номер Требование Обоснование/ ссылки DER-REQ-5-001 ПО должно отображать в боковой панели список проектов, доступных текущему пользователю. Обоснование: для быстрой навигации по существующим проектам DER-REQ-5-002 В разделе Проекты ПО должно отображать пользователю список доступных ему проектов. Список проектов должен содержать для каждого проекта следующую информацию : наименование проекта код проекта Обоснование: для отображения информации о проекте DER-REQ-5-003 ПО должно открывать описание проекта при нажатии на него левой кнопкой мыши. Обоснование: для загрузки данных о проекте из БД REQ_SW-5-004 При открытии описания проекта система должна загружать его состояние конфигурации (количество артефактов по типам, статистика ЗИ, открытые СП, список несоответствий, протоколы и список ФИ). Интерфейс проекта должен содержать горизонтальное меню со следующими разделами: «Артефакты» (5.1.1); «Запросы на изменение» (5.1.2); «Формальные инспекции» (5.1.3); «Сообщения о проблеме» (5.1.4); «Отчёты» (5.1.5); "Трассировка Github"(5.1.6.) REQ-SYS-017 Таблица 6. Требования к управлению артефактами и трассировочными ссылками. (соответствует интерфейсу 6) Идентификационный номер Требование Обоснование/ ссылки REQ_SW-6-001 ПО (5.1.1.) должно предоставлять пользователю панель фильтров и поиска артефактов, включая: фильтры по типу артефакта, статусу, автору, версии и пользовательским атрибутам; поиск по наименованию и описанию артефакта. При загрузке раздела «Артефакты» система должна применять заданные пользователем фильтры и параметры поиска и отображать отфильтрованный список артефактов. REQ-SYS-019, REQ-SYS-005 REQ_SW-6-002 В разделе «Артефакты» ПО должно отображать таблицу артефактов проекта. Для каждого артефакта в таблице должны отображаться: тип артефакта; идентификатор (по шаблону); наименование; текущая базовая версия; наличие рабочей версии; статус жизненного цикла REQ-SYS-001, REQ-SYS-002, REQ-SYS-014 REQ_SW-6-003 Для каждой строки таблицы артефактов ПО должно отображать доступные действия: «Посмотреть подробнее» (6.1.1); «История версий» (6.1.2);«Посмотреть трассировку» (6.1.3); «Создать ЗИ» (6.1.4) — при наличии соответствующих прав Удалить (6.1.5) REQ-SYS-009 REQ_SW-6-005 При нажатии на действие (6.1.1) ПО должно отображать карточку артефакта с информацией о текущей рабочей и базовой версиях, пользовательских атрибутах и трассировочных связях. REQ-SYS-001, REQ-SYS-005, REQ-SYS-010 REQ_SW-6-006 Кнопка «Создать артефакт» (6.1.6) должна быть видна только пользователям, которым администратор дал право на создание именно этого типа артефакта. При создании артефакта система обязана: предоставить форму с названием, типом артефакта, описанием, пользовательскими атрибутами, определенными администратором проекта присвоить уникальный внутренний ID и внешний ID по активному шаблону артефакта создать рабочую версию REQ-SYS-009, REQ-SYS-001, REQ-SYS-002, REQ-SYS-008 REQ_SW-6-007 ПО (6.1.3) должно отображать данные артефакта как таблицу трассировки: список входящих и исходящих связей с указанием типа связи, типа связанного артефакта, ID, название, версия. REQ-SYS-010 Таблица 7. Требования к процессу управления версиями артефактов и ЗИ. (соответствует интерфейсу 7) Идентификационный номер Требование Обоснование/ ссылки REQ_SW-7-001 В Запросах на изменение ПО должно отображать список запросов на изменение, связанных с текущим проектом или выбранным артефактом. REQ-SYS-011 REQ_SW-7-002 ПО (5.1.2) должно содержать таблицу с историей запросов на изменение, созданных для выбранного артефакта. REQ-SYS-011 REQ_SW-7-003 При создании ЗИ кнопкой (6.1.2.) ПО должно создать «ЗИ» с атрибутами: обоснование, цель, список затрагиваемых артефактов, описание планируемых изменений, исполнитель(и). REQ-SYS-011 REQ_SW-7-004 При сохранении измененного содержимого артефакта ПО должно создавать новую рабочую версию ЕК с фиксацией автора изменения, времени, содержимого и значений пользовательских атрибутов. REQ-SYS-003 DER-REQ-7-001 После нажатия на кнопку "Готово к ФИ" (7.1.1.) ПО должно отправлять уведомление ведущему и в подразделе (5.1.2) должно появляться новое ЗИ со статусом "Ожидает ФИ". Обоснование: для информирования ведущего, который отвечает за подготовку ФИ Таблица 8. Требования к процессу ФИ(соответствует интерфейсу 8) Идентификационный номер Требование Обоснование/ ссылки REQ_SW-8-001 ПО (5.1.3) должно содержать список ФИ с полями: идентификатор протокола, статус («в процессе», «принято», «отклонено», «на доработке»), дата, участники, ссылки на артефакты, описание ЗИ. REQ-SYS-013 REQ_SW-8-002 Интерфейс ПО выбранной из списка ФИ должен содержать данные из протоколов ФИ : измененные артефакты, версии, список несоответствий, СП(если создавалось ведущим), id протокола, комментарий, решение по ФИ(отклонено, принято). REQ-SYS-013 REQ_SW-8-003 После получения ведущим уведомления о готовности ЗИ к ФИ ПО должно предоставить возможность ведущему перейти из личного кабинета по ссылке на ЗИ в подраздел (5.1.2), заполнить письмо-приглашение на ФИ для всех участников, которых он добавит в это письмо по кнопке "Подготовить ФИ".(8.1.0) REQ-SYS-013 DER-REQ-8-004 Интерфейс подготовки ФИ ПО должен обеспечивать заполнение письма-приглашения, включая: ссылку на запрос на изменение; список участников и их роли; пользовательские атрибуты, определённые администратором проекта. для организации и документирования процесса проведения формальной инспекции. REQ_SW-8-005 Во время проведения формальной инспекции ПО должно загружать данные об изменённых артефактах и описании изменений и обеспечивать участникам с соответствующими правами возможность ведения протокола ФИ. REQ-SYS-013, REQ-SYS-009 DER-REQ-8-006 Кнопка «Создать протокол ФИ» ПО (8.1.1) должна открывать панель ведения протокола формальной инспекции. для фиксации результатов формальной инспекции. REQ_SW-8-007 При нажатии на кнопку "Отклонить ФИ"(8.1.2) или "Принять ФИ"(8.1.3.) ПО должно сохранить протокол ФИ с перечнем проверенных ЕК(из ЗИ) и их версий, списком несоответствий, ссылками на СП(если возникли), итоговым решением(принято / отклонено), датой и участниками. REQ-SYS-013 REQ_SW-8-008 При наличии несоответствий со статусом «открыто» или «не устранено» по артефакту ПО должно не создавать новую базовую версию ЕК в БД. REQ-SYS-004 REQ_SW-8-009 При наличии несоответствий со статусом «устранено» и «заметка» ПО должно создавать новую базовую версию. REQ-SYS-004 REQ_SW-8-010 После нажатия на кнопки (8.1.2) и (8.1.3) ПО должно отправлять уведомление автору о том, что ЗИ было отклонено и присвоить ЗИ статус "Отклонено ФИ" или "Принято ФИ" в разделе (5.1.2.) REQ-SYS-013 REQ_SW-8-011 В протоколе ФИ несоответствия должны отображаться в виде таблицы с полями: ID рассмотренная ЕК список артефактов описанием несоответствий, статус («открыто», «снято», «заметка» , «устранено», «не устранено»), комментарием связанные артефакты и ссылки на версии REQ-SYS-013 REQ_SW-8-012 В Сообщениях о проблемах ПО должны отображаться данные в виде таблицы с полями : ID СП краткое описание инициатор связанные артефакты один из статусов рассмотрения Советом по управлению изменениями (далее Совет ): «на рассмотрении», «принято», «отклонено», опционально могут быть пользовательские статусы связанные ЗИ REQ-SYS-013 REQ_SW-8-013 ПО должно позволить создавать решения проблемы в случае принятия СП и хранить их историю по каждому СП. (REQ-SYS-013). Обязательные поля: дата, принявший решение, описание решения REQ-SYS-013 REQ_SW-8-014 При нажатии на кнопку "Отклонить СП"(8.1.4) (по решению Совета) ПО должно уведомить участников ФИ об их согласии с автором. REQ-SYS-013 REQ_SW-8-015 При нажатии на кнопку "Принять СП"(8.1.5) ПО должно отправить уведомление автору о решении Совета для внесении им изменений в артефакты REQ-SYS-013 REQ_SW-8-016 После создания новой базовой версии ЕК (по результатам ФИ) ПО должно уведомить в личном кабинете и по почте всех пользователей, участвовавших в создании, изменении ЕК и рассмотрении ЗИ. REQ-SYS-023 Таблица 9. Требования к процессам поиска, фильтрации, созданию отчётов и их экспорта. (Интерфейс 9) Идентификационный номер Требование Обоснование/ ссылки REQ_SW-9-001 В верхней части Артефактов ПО должно быть поле контекстного поиска по названию, описанию и значениям пользовательских атрибутов REQ-SYS-019 DER-REQ-9-002 Рядом со строкой поиска должна быть кнопка "Настроить фильтры"(9.1.1) Обоснование: для обеспечения удобного доступа пользователя к расширенным возможностям фильтрации. REQ_SW-9-003 При нажатии на кнопку «Настроить фильтры» (9.1.1) ПО должна отображать элементы фильтрации артефактов по следующим параметрам: тип артефакта; статус; пользователь; пользовательские атрибуты. REQ-SYS-019 REQ_SW-9-004 ПО (5.1.5.) должно предоставить пользователю возможность экспорта выбранной спецификации или её части. REQ-SYS-020 DER-REQ-9-005 Для экспорта должны быть доступны следующие кнопки: «Экспорт в PDF»(9.1.2), «Экспорт в DOCX»(9.1.3.), «Экспорт в CSV» (9.1.4.) Обоснование: для предоставления пользователю выбора формата экспорта данных. REQ_SW-9-006 При выборе формата экспорта ПО должно формировать файл соответствующего формата и обеспечивать его загрузку на локальное устройство пользователя. REQ-SYS-020 Таблица 10. Требования к процессу установления трассировочных связей между требованиями, кодом и тестами. (соответствует интерфейсу 10.) Идентификационный номер Требование Обоснование/ ссылки REQ_SW-10-001 При открытии вкладки «Код» ПО должно отображать таблицу связей между артефактом системы и кодом для выбранной версии артефакта со следующими столбцами: репозиторий; файл; диапазон строк; тип связи; коммит; комментарий; ветка (по умолчанию main). REQ-SYS-010, REQ-SYS-024 DER-REQ-10-002 В таблице связей ПО должны быть доступны действия: «Просмотреть» — для просмотра фрагмента кода; (10.1.1) «Удалить» — для удаления связи. (10.1.2) Обоснование: для обеспечения управления трассировочными связями пользователем. DER-REQ-10-003 Над таблицей связей ПО должны отображаться кнопки « Добавить связь с кодом» (10.1.3) Обоснование: для управления созданием и актуализацией связей. REQ_SW-10-004 При отсутствии связей с кодом для выбранной версии артефакта ПО должно отображать сообщение: «Связи с кодом не заданы» REQ-SYS-010 REQ_SW-10-005 При переключении версии артефакта и повторном открытии вкладки «Код» ПО должно отображать связи, относящиеся только к выбранной версии артефакта. REQ-SYS-006, REQ-SYS-007, REQ-SYS-010 REQ_SW-10-006 При открытии вкладки «Код» ПО должно загружать из базы данных только связи между артефактом системы и кодом для текущего артефакта и выбранной версии ЕК. Загружаемые данные по каждой связи: идентификатор связи; идентификатор артефакта и версии; репозиторий; путь файла; диапазон строк; тип связи; идентификатор коммита; комментарий; автор; дата создания. REQ-SYS-006, REQ-SYS-010 REQ_SW-10-007 При нажатии кнопки «Просмотреть» ПО должно, используя сохранённые параметры связи, запрашивать содержимое файла из GitHub и отображать пользователю только указанный диапазон строк. REQ-SYS-024 REQ_SW-10-008 При нажатии кнопки «Удалить» ПО должно удалить запись связи между артефактом системы и кодом из своей базы данных. REQ-SYS-010 REQ_SW-10-009 При нажатии кнопки (10.1.3) ПО должно открывать окно «Выбор фрагмента кода», связанное с текущим артефактом и выбранной версией ЕК. REQ-SYS-010 DER-REQ-10-010 Окно «Выбор фрагмента кода» должно содержать: выпадающий список репозиториев проекта; дерево файлов и каталогов репозитория; панель просмотра содержимого выбранного файла с нумерацией строк; поля ввода начальной и конечной строки; поле выбора типа связи; поле комментария (опционально). Обоснование: для обеспечения удобного выбора фрагмента кода пользователем. DER-REQ-10-011 В окне «Выбор фрагмента кода» ПО должно предоставить пользователю информацию о версии артефакта, с которой будет связана выбранная часть кода. Обоснование: для предотвращения ошибок трассировки по версиям. DER-REQ-10-012 В окне «Выбор фрагмента кода» ПО должны быть доступны кнопки «Сохранить связь» и «Отмена». Обоснование: REQ_SW-4-006. для управления процессом создания связи. 4. Макеты интерфейсов в веб-приложении 1) Интерфейс “Регистрация” 2) Интерфейс “Авторизация” 3) Интерфейс "Личный кабинет" 4) Интерфейс “Администрирование” REQ_SW-9-00 5) Интерфейс боковой панели и “Проект” (сводная информация о состоянии ЕК проекта для REQ_SW-9-003 пользователя ) 6) Интерфейс "" 7) Интерфейс "" 8) Интерфейс "" 9) Интерфейс "" 10) Интерфейс "Трассировка с кодом": РевьюПрограммные требования не имеют больших логических дыр в сравнении с системными требованиями, поэтому в ходе ревью были в основном исправления синтаксических неточностей и неоднозначных моментов трактовки требований. Больше всего реализационных вопросов вызвали требования отправки уведомлений по почте в процессе регистрации для подтверждения корректности почты. Осложнения связаны с тем, что на данном этапе разработки нет пошагово продуманной реализации исполнения этой функции, как и более уточняющих прописанных требований. В связи с этим принято решение убрать из ближайшего приоритета кодирование этой функциональности. Основные изменения в программных требованиях - исправили ошибки и неточности, выявленные на прошлом совместном семинаре, прописали “ПО должно” в требованиях.