Базовая версия
2026-03-20T18:37:01+00:00
НИЯУ МИФИ Системные требования к системе управления требованиями Команда №3 Москва, 2025 Глоссарий. Понятие Определение 1 Системное требование Требования, предъявляемые к системе, понимаемой как программно-аппаратный комплекс. Некоторые системные требования могут реализовываться исключительно программно (например, протокол транспортного уровня), некоторые– аппаратно (например, требования по электропитанию или внешним воздействиям), но возможна и совместная программно-аппаратная реализация(например, измерение атмосферного давления). 2 Спецификация Совокупность требований, определяющих функции и свойства, которые должны быть реализованы в разрабатываемом программном обеспечении. Спецификация требований может быть организована как один или несколько логически связанных документов (файлов), либо как совокупность записей в специализированной базе данных, либо иным способом 3 Раздел требований Структурный компонент внутри спецификации, группирующий требования по тематическому или логическому признаку. 4 Пользователь Лицо или организация, которые непосредственно будут эксплуатировать разрабатываемую систему. Пользователями, например, могут быть члены IT команд, руководители . Предполагается, что взаимодействие с пользователями находится в компетенции Заказчика. Пользователям будет предоставлен доступ к разным функциям системы, в зависимости от этого они будут обладать одной или несколькими ролями. 5 Базовая версия Утвержденная и неизменяемая версия требования, раздела или спецификации, которая является основой для дальнейшей разработки и трассировки. Установление и изменение базовой версии возможно только через процесс ЗИ. 6 Запрос на изменение (ЗИ) Формальное предложение на модификацию текущей базовой версии требования, раздела или спецификации. Реализуется через создание новой "Рабочей версии" единицы конфигурации. 7 Формальная инспекция Формальный процесс проверки и оценки артефакта (требования, раздела, спецификации) уполномоченным инспектором на соответствие установленным критериям качества перед утверждением в качестве базовой версии 8 Инспектор Пользователь, уполномоченный проводить формальную инспекцию артефакта. 9 Трассировка Связь между требованиями, позволяющая отслеживать их взаимное влияние 10 Действие (Вход) Любое событие или команда, инициируемая пользователем или внешней системой для взаимодействия с системой управления требованиями. 11 Результат (Выход) Ответ системы на действие, который может быть представлен в виде данных, изменения состояния или уведомления. 12 Артефакт Любой объект, управляемый в системе: спецификация, требование, запрос на изменение, проект, раздел спецификации, тест для требования, результат теста, протокол инспекции. 13 Проект Высокоуровневая сущность, объединяющая все артефакты, спецификации и пользователей, участвующих в разработке одного продукта или системы. 14 Рабочая версия Версия требования, раздела или спецификации, созданная на основе Базовой версии в рамках Запроса на изменение (ЗИ). В этой версии ведутся все правки, обсуждаются замечания. После утверждения инспектором Рабочая версия становится новой Базовой версией. 15 Версия ЕК Конкретное сохраненное состояние ЕК в определенный момент времени. Система хранит полную историю всех версий каждого артефакта. 16 Единица конфигурации Артефакт, версией которого управляет система 17 Тип артефакта Категория артефакта, определяющая его назначение, структуру данных и правила обработки в системе. Фиксированный перечень: Спецификация, Требование, Раздел спецификации, Запрос на изменение, Проект, Тест, Результат теста, Протокол ФИ. 18 Тип связи Категория отношения между двумя артефактами, определяющая характер их взаимного влияния. Примеры: реализует, тестирует, зависит от, влияет на, уточняет. 19 Сообщение о проблеме (СП) Артефакт, фиксирующий несоответствие, выявленное в процессе Формальной инспекции. Содержит описание проблемы, ссылки на рассматриваемые артефакты и участников спора. 20 Несоответствие Выявленное отклонение артефакта от установленных требований, стандартов, правил оформления, полноты, корректности или непротиворечивости, обнаруженное в ходе формальной инспекции. Несоответствие фиксируется в системе как отдельный объект, содержащий описание проблемы, ссылки на артефакт и его версию, источник обнаружения и текущее состояние. Статусы: открыто: Несоответствие выявлено, зарегистрировано и ожидает анализа или решения. Оно считается «нерешенным» и блокирует утверждение базовой версии. устранено: Несоответствие было устранено путем внесения изменений, и изменения прошли проверку. Артефакт соответствует требованиям. снято: Несоответствие признано нерелевантным, ошибочным или больше не требующим действий. Статус устанавливается по результатам анализа и обоснования. «заметка» : Несоответствие признаётся не критичным и не влияющим на утверждение базовой версии, однако рекомендуется к исправлению в дальнейшем. не устранено: Несоответствие подтверждено и требует исправления, но изменения еще не внесены или не проверены. Системные требования REQ-SYS-001. Система должна позволять авторизованному пользователю создавать артефакты разных типов(после разрешения администратором проекта), определенных в глоссарии: спецификация, требование, раздел спецификации, запрос на изменение, проект, протокол формальной инспекции. REQ-SYS-002. Система должна присваивать каждому артефакту уникальный неизменяемый внутренний идентификатор. После удаления артефакта этот идентификатор не должен использоваться повторно. REQ-SYS-003. Система должна позволять пользователю после создания ЗИ вносить изменения в содержимое артефакта и сохранять эти изменения как новую «рабочую версию» этого артефакта, которая должна включать: автора изменения время изменения содержимое версии значения пользовательских атрибутов на момент изменения (опционально) REQ-SYS-004. Система должна позволять пользователю инициировать удаление артефакта, находящегося в состоянии «базовая версия», только через создание запроса на изменение (ЗИ). Окончательное удаление артефакта должно выполняться системой после утверждения ЗИ и прохождения артефактом процесса формальной инспекции. Удалённые артефакты не должны использоваться повторно, но должны сохраняться в истории изменений в виде архивных версий. REQ-SYS-005. Система должна позволять пользователю добавлять, изменять, удалять пользовательские атрибуты для любого типа артефакта, если он имеет доступ к этим функциям системы. REQ-SYS-006. Система должна сохранять всю историю изменений любого артефакта или набора артефактов как ЕК, содержащую информацию о пользователе, который внес изменение, времени создания и последнего изменения, предыдущих версиях, а также значения пользовательских атрибутов на момент изменения. REQ-SYS-007. Система должна создавать рабочую версию ЕК при внесении изменений в содержимое артефактов после создания ЗИ и создании артефакта без ЗИ. Система должна создавать базовую версию артефакта после проведения ФИ, если не было найдено несоответствий и не возникло конфликтов между инспекторам(и) и автором. Система должна хранить рабочие и базовые версии всех ЕК. REQ-SYS-008. Система должна позволять администратору проекта определять шаблоны для генерации идентификаторов артефактов. Система должна присваивать идентификаторы вновь создаваемым артефактам в соответствии с активным шаблоном. REQ-SYS-009. Система должна предоставлять пользователям доступ к данным проекта и функциям системы в зависимости от того, какими функциями администратор проекта разрешил пользоваться. REQ-SYS-010. Система должна позволять пользователю с ролью администратор проекта создавать, просматривать и удалять связи трассировки между артефактами. Система должна предоставлять возможность создавать пользовательский тип связи. REQ-SYS-011. Система должна позволять создавать ЗИ с встроенными атрибутами: обоснование изменения цель изменения список затрагиваемых артефактов описание планируемых изменений исполнитель(и) изменений Система должна позволять пользователю создавать ЗИ с пользовательскими атрибутами опционально. REQ-SYS-012. Система должна позволять проводить ФИ артефактов и фиксировать её результаты в протоколе ФИ. Система должна сохранять протокол ФИ, содержащий: проверенные артефакты и версии, выявленные несоответствия, принятые решения, участников и дату дополнительно пользовательские атрибуты Система должна позволять инспекционной группе принять одно из решений: «принять» (утверждение базовой версии) «доработать» (нахождение несоответствий или создание СП) Система должна позволять пользователям вносить изменения в артефакты, для которых ещё не установлена ни одна базовая версия, без создания ЗИ. Для артефактов, имеющих базовую версию, изменение должно быть возможно только после создание ЗИ. REQ-SYS-013. Система должна: обеспечивать создание СП при возникновении разногласий между инспектором и автором обеспечивать передачу СП на рассмотрение Совету по управлению изменениями позволять создавать ЗИ для принятых СП для сохранения альтернативного решения обеспечивать трассируемость между СП, ЗИ, артефактами и протоколами ФИ блокировать утверждение базовых версий при наличии неразрешенных СП хранить историю решений по каждому СП REQ-SYS-014. Система должна позволять администратору проекта настраивать жизненный цикл для всех управляемых артефактов, включая: набор состояний артефакта правила переходов между состояниями ограничения на выполнение переходов на основе функций/прав доступа пользователей автоматические действия, выполняемые при переходах REQ-SYS-015. Система должна перевести рабочие версии всех измененных ЕК в новые базовые версии, если в процессе ФИ было разрешено внести изменения, нет конфликтов и несоответствий. REQ-SYS-016. Система должна сохранять протокол проведенной ФИ как отдельный артефакт, содержащий: список проверенных ЕК и их версий, перечень выявленных несоответствий, ссылки на созданные по результатам несоответствий СП, итоговое решение ФИ («принято», «отклонено»), дату и участников инспекции. REQ-SYS-017. Система должна вести учет состояния конфигурации и предоставлять данные для отчетов, отражающие состояние управляемых артефактов проекта. REQ-SYS-018. Система должна позволять пользователю искать артефакты по названию, описанию и значениям пользовательских атрибутов. REQ-SYS-019. Система должна позволять пользователю фильтровать артефакты по типу, статусу, пользователям и пользовательским атрибутам. REQ-SYS-020. Система должна позволять пользователю экспортировать спецификации и отчёты в PDF, DOCX и CSV. REQ-SYS-021. Система должна позволять администратору проекта добавлять/удалять пользователей проекта и предоставлять им доступ к функциям системы. REQ-SYS-022. Система должна во время проведения ФИ предоставлять пользователям, участвующим в инспекции, следующие функции: просмотр рабочей и базовых версий проверяемых артефактов просмотр связанных артефактов по трассировочным связям создание и редактирование несоответствий создание сообщений о проблеме (СП) при спорных ситуациях просмотр и анализ ЗИ, относящихся к проверяемым артефактам принятие решения по несоответствиям принятие итогового решения по ФИ REQ-SYS-023. Система должна уведомлять пользователей, которые принимали участие в создании, изменении и рассмотрении изменений артефакта, о смене его базовой версии. REQ-SYS-024. Система должна хранить тесты, результаты тестов и связывать их с версиями требований и кода. REQ-SYS-025. Система должна журналировать действия пользователей, влияющие на состояние артефактов. REQ-SYS-026. Система должна позволять регистрировать несоответствия, связанные с проверяемыми артефактами, в ходе ФИ. Система должна поддерживать следующие состояния несоответствия: «открыто» «снято» «заметка» «устранено» «не устранено» Система должна хранить текущее состояние каждого несоответствия и историю изменений состояний. REQ-SYS-027. Система должна запрещать установление базовой версии артефакта, если по данному артефакту существуют несоответствия со статусом «открыто» или «не устранено». Система должна разрешать установление базовой версии артефакта при наличии несоответствий со статусом «устранено», «снято» или «заметка» , если по ним не требуется внесение изменений. REQ-SYS-028. Система должна обеспечивать возможность создания запроса на изменение (ЗИ) для устранения несоответствий, выявленных в ходе формальной инспекции позволять создать ЗИ артефактов с несоответствиями со статусом «открыто» или «не устранено» предлагать создание ЗИ после завершения формальной инспекции, если в ходе проверки были выявлены несоответствия, требующие исправления