Запротоколированные требования служат источником проведения дальнейшего анализа. Для чего над ними проделываются следующие операции:

- очистка требований от позиций, не являющимися таковыми; - отыскиваются и устраняются противоречия в требованиях; - уточняются непонятные и неоднозначно трактуемые требования; - детализируются высокоуровневые требований; - удаляются дубли требований.

Открытые вопросы прорабатываются со всеми вовлеченными сторонами, однако в отличие от процедуры сбора и выявления требований, проводимой в формате семинаров, обсуждение ведется точечно и по мере необходимости. Здесь же дается предварительная оценка технической реализуемости выявленных требований. Далее осуществляется приоритизация требований. В работе [1] описаны различные способы приоритизации:

- трехуровневая шкала приоритетов; - MuSCoW; - на основе ценности, стоимости и рисков.

В практике внедрения платформенных программных решений наиболее используемым является метод трехуровневых шкал, присваивающий каждому требований низкий, средний или высокий приоритет. Ранжирование потребностей ведется, принимая во внимание следующее:

- наивысший приоритет отдается требованиям, реализация которые обязательна согласно законодательству РФ; - высокий приоритет имеют требования, обеспечивающие значительное снижение трудозатрат сотрудников; - высоким приоритетом обладают системные требования, без которых программное решение не сможет полноценно работать.

Установка средних и низких приоритетов проводится интуитивно, однако, финализация является ответственностью владельцев процессов или же ключевых бизнес-пользователей организации.

Проанализированные и приоритизированные требования подлежат дальнейшему документированию. Выделяют два основных документа, позволяющих описывать и контролировать требования на протяжение жизненного цикла программного обеспечения:

- спецификация требований; - матрица отслеживания требований.

Спецификация требований (Software Requirement Specification, SRS) содержит детальное описание потребностей, понятное как бизнес-пользователям, так и техническим специалистам.

Другими наименованиями этого документа могут служить: спецификация требований к программному продукту, функционально-технические требования и ФТТ. Обычно ведется отдельный документ спецификации требований для каждого функционального направления. Не лишним будет отметить то, что документ создается преимущественно на фазе анализа при имплементации программного продукта. В последующем содержание документа переносится в проектные решения и/или функциональные спецификации на разработку. Довольно часто в последних дается лишь ссылка на конкретный пункт документа спецификации требований, что исключает дублирование данных.

Матрица отслеживания требований (Requirement Traceability Matrix, RTL) представляет собой список верхнеуровневых требований, обогащенный информацией по:

- взаимозависимостям требований; - тому, как потребность будет реализовываться в программной системе; заявителю; - дате регистрации; - статусе исполнения и др.

Следуя названию, матрица позволяет контролировать ход реализации требования от момента его регистрации до реализации в информационно-программной системе (рис. 3). Существенным является то, что требованию при создании его в матрице отслеживания присваивается уникальный идентификатор, используемый во всех последующих проектных документах и активностях.

Содержание спецификации требований, а также часть атрибутов матрицы отслеживания требований подлежат обязательному согласованию со стороны бизнес-пользователей, которыми чаще всего являются владельцы процессов. Проверка требований перед их утверждением позволяет убедиться ...

--

Демьянов Н.А. Требования к программному обеспечению: от подготовки до управления изменениями (часть 2) // Корпоративные информационные системы. – 2024. – №3 (27) – С. 7-11. – URL: https://corpinfosys.ru/archive/2024/issue-27/274-2024-27-requirements.