Самое полное руководство по управлению требованиями и отслеживаемости
Словарь терминов
Содержание
|
Сокращения
|
Условия использования
|
Определение
|
|---|---|---|
|
RM
|
Управление требованиями
|
Процесс выявления, документирования, анализа, отслеживания, определения приоритетов, утверждения и поддержания требований к проекту или продукту.
|
|
BRD
|
Документ бизнес-требований
|
Официальный документ, описывающий бизнес-требования высокого уровня для проекта или продукта. Обычно он включает информацию о бизнес-потребностях, масштабах, заинтересованных сторонах, функциональных требованиях, нефункциональных требованиях, предположениях, ограничениях, рисках и графике проекта.
|
|
FRD
|
Документ о функциональных требованиях
|
Подробный документ, описывающий конкретные функциональные требования к проекту или продукту. Обычно он включает информацию о функциях системы, требованиях пользователей, вариантах использования, сценариях, требованиях к данным и критериях приемки.
|
|
НФРД
|
Документ о нефункциональных требованиях
|
Подробный документ, описывающий конкретные нефункциональные требования к проекту или продукту. Обычно он включает информацию о производительности системы, масштабируемости, доступности, надежности, безопасности, ремонтопригодности, удобстве использования и доступности.
|
|
SRS
|
Спецификация требований к программному обеспечению
|
Всеобъемлющий документ, описывающий функциональные и нефункциональные требования к программной системе. Обычно он включает информацию об архитектуре системы, дизайне, реализации, тестировании и развертывании.
|
|
Кейсы
|
Кейсы
|
Метод сбора и описания функциональных требований к системе путем определения взаимодействий между системой и ее пользователями или другими системами. Обычно он включает описание шагов, предпринятых пользователем или системой для достижения конкретной цели или задачи.
|
|
Матрица прослеживаемости
|
Матрица прослеживаемости
|
Документ, обеспечивающий прослеживаемую связь между требованиями, проектированием, реализацией, тестированием и развертыванием системы. Обычно он включает информацию о взаимосвязи между требованиями и другими системными артефактами, такими как тестовые случаи, дефекты и запросы на изменение.
|
|
Совет по контролю за изменениями
|
Совет по контролю за изменениями
|
Группа заинтересованных сторон, ответственных за оценку, утверждение и управление изменениями в требованиях, проектирование, реализацию, тестирование и развертывание системы. Обычно в него входят представители различных отделов, таких как бизнес, разработка, тестирование и эксплуатация.
|
|
Выявление требований
|
Выявление требований
|
Процесс сбора и документирования требований к проекту или продукту от заинтересованных сторон, пользователей и других источников. Обычно это включает в себя такие методы, как интервью, опросы, наблюдения, фокус-группы и сеансы мозгового штурма.
|
|
Акционеры
|
Акционеры
|
Человек или группа людей, заинтересованные в успехе проекта или продукта. Обычно это клиенты, пользователи, спонсоры, владельцы бизнеса, разработчики, тестировщики и вспомогательный персонал.
|
|
Приоритизация требований
|
Приоритизация требований
|
Процесс ранжирования требований к проекту или продукту в порядке важности или срочности. Обычно это включает в себя определение критических требований, которые должны быть рассмотрены в первую очередь, и назначение уровня приоритета каждому требованию на основе его ценности для бизнеса, технической осуществимости и риска.
|
|
Инструменты управления требованиями
|
Инструменты управления требованиями
|
Программное приложение, используемое для поддержки процесса управления требованиями. Обычно включает такие функции, как сбор требований, отслеживаемость, контроль версий, совместная работа, отчетность и аналитика. Примерами инструментов управления требованиями являются Visure Solutions, IBM Rational DOORS и HP ALM.
|
|
Базовая линия
|
Базовая линия
|
Набор утвержденных требований, формирующих основу для дальнейшей разработки и тестирования системы. Обычно он включает функциональные и нефункциональные требования, которые были согласованы заинтересованными сторонами и утверждены комиссией по контролю за изменениями.
|
|
Проверка
|
Проверка
|
Процесс оценки полноты, точности и соответствия требований к системе потребностям и ожиданиям заинтересованных сторон. Обычно это включает в себя просмотр документов с требованиями, проведение обзоров заинтересованных сторон и проверку соответствия системы указанным требованиям с помощью тестирования и других методов.
|
|
Проверка
|
Проверка
|
Процесс оценки того, соответствует ли система заданным требованиям. Обычно это включает в себя тестирование системы на соответствие критериям приемлемости, определенным в документах с требованиями, и проверку того, что все требования были реализованы правильно.
|
|
Объем
|
Объем
|
Границы и цели проекта или продукта. Обычно он включает информацию о характеристиках, функциях и возможностях системы, а также ограничениях, которые необходимо учитывать.
|
|
Анализ воздействия
|
Анализ воздействия
|
Процесс оценки потенциальных последствий изменения требований, дизайна, реализации, тестирования или развертывания системы. Обычно это включает в себя определение затронутых областей системы, оценку рисков и преимуществ изменения, а также определение ресурсов и сроков, необходимых для внедрения изменения.
|
|
Обзор требований
|
Обзор требований
|
Формальный процесс оценки документов с требованиями, чтобы убедиться, что они полны, точны и соответствуют потребностям и ожиданиям заинтересованных сторон. Обычно он включает в себя проверку группой заинтересованных сторон, включая разработчиков, тестировщиков, бизнес-аналитиков и профильных экспертов, которые обеспечивают обратную связь и выявляют любые проблемы или проблемы, которые необходимо решить.
|
|
Прослеживаемость требований
|
Прослеживаемость требований
|
Возможность отслеживать и управлять взаимосвязью между требованиями и другими системными артефактами, такими как проектная документация, тестовые случаи, дефекты и запросы на изменение. Обычно это включает в себя создание матрицы прослеживаемости или другого инструмента, чтобы гарантировать, что все требования учитываются на протяжении всего процесса разработки и что любые изменения требований должным образом управляются и документируются.
|
|
Базовый уровень требований
|
Базовый уровень требований
|
Набор требований, одобренный заинтересованными сторонами и формирующий основу для дальнейшей разработки и тестирования системы. Обычно он включает функциональные и нефункциональные требования, а также любые выявленные ограничения, допущения и риски. Базовый план требований используется в качестве ориентира для управления изменениями требований на протяжении всего процесса разработки.
|
|
Разработка требований
|
Разработка требований
|
Систематический и дисциплинированный подход к выявлению, анализу, спецификации, проверке и управлению требованиями к проекту или продукту. Обычно это включает использование различных методов, таких как интервью, опросы, варианты использования, сценарии и прототипы, чтобы гарантировать, что требования полны, точны и соответствуют потребностям и ожиданиям заинтересованных сторон.
|
|
Документация по требованиям
|
Документация по требованиям
|
Набор документов, описывающих требования к системе, включая документ с бизнес-требованиями, документ с функциональными требованиями, документ с нефункциональными требованиями, варианты использования, пользовательские истории и другие связанные документы. Документация по требованиям обеспечивает всестороннее понимание характеристик, функций и возможностей системы, а также ограничений, допущений и рисков, которые необходимо учитывать на протяжении всего процесса разработки.
|
|
BR
|
Бизнес-требования
|
Цели и задачи высокого уровня, которым должна соответствовать система, чтобы удовлетворить потребности и ожидания заинтересованных сторон. Бизнес-требования обычно сосредоточены на бизнес-процессах, политиках и правилах, которые система должна поддерживать или улучшать, а не на технических деталях того, как система будет реализована.
|
|
FR
|
Функциональные требования
|
Подробное описание свойств, функций и возможностей, которыми должна обладать система, чтобы удовлетворить потребности и ожидания заинтересованных сторон. Функциональные требования обычно определяют, как система будет вести себя или реагировать на определенные входные данные или события, и они могут включать ограничения, допущения и критерии приемлемости, которые должны быть соблюдены, чтобы гарантировать, что система соответствует требованиям заинтересованных сторон.
|
|
NFR
|
Нефункциональные требования
|
Описание производительности, надежности, безопасности, удобства использования и других качеств системы, необходимых для удовлетворения потребностей и ожиданий заинтересованных сторон. Нефункциональные требования обычно определяют атрибуты или характеристики системы, а не ее конкретные свойства или функции, и они могут включать ограничения, допущения и критерии приемки, которые должны быть соблюдены, чтобы гарантировать, что система соответствует требованиям заинтересованных сторон.
|
|
История пользователя
|
История пользователя
|
Краткое неформальное описание свойства или функции, которыми должна обладать система, чтобы удовлетворить потребности и ожидания заинтересованных сторон. Пользовательские истории обычно следуют простому шаблону, например: «Как [пользователь], я хочу [функцию], чтобы [выгода]». Пользовательские истории используются для фиксации требований в простом и понятном формате, который может быть легко передан и расставлен по приоритетам заинтересованными сторонами и командой разработчиков.
|
|
Критерии приема
|
Критерии приема
|
Критерии, которым должна соответствовать система, чтобы заинтересованные стороны считали ее приемлемой или удовлетворительной. Критерии приемлемости обычно определяют ожидаемое поведение или результаты системы в конкретных сценариях или вариантах использования, и они могут включать количественные или качественные показатели, которые должны быть соблюдены, чтобы гарантировать, что система соответствует потребностям и ожиданиям заинтересованных сторон. Критерии приемки используются для проверки соответствия системы функциональным и нефункциональным требованиям и обеспечения ее соответствия требованиям заинтересованных сторон.
|
|
ALM
|
Управление жизненным циклом приложения
|
Управление жизненным циклом приложения — это процедура определения, проектирования, документирования и тестирования приложения. Он охватывает весь жизненный цикл от начала до конца проекта. Он начинается с идеи приложения на протяжении всей разработки, переходит к тестированию, развертыванию, поддержке и, наконец, пользовательскому опыту.
|
|
CMMI
|
Модель зрелости интеграции
|
CMMI определяет набор лучших практик для разработки программного обеспечения, управления проектами и организационного управления, которые могут помочь организациям повысить качество, эффективность и результативность своих процессов разработки программного обеспечения.
|
|
MBSE
|
Модельно-ориентированная системная инженерия
|
Подход к системной инженерии, который использует модели для представления, анализа, проектирования и проверки сложных систем. MBSE включает в себя создание набора моделей, отражающих требования, поведение, архитектуру и другие ключевые аспекты системы, а также использование этих моделей для управления процессом разработки.
|
Не забудьте поделиться этим постом!
