4. Анализ требований
Запротоколированные требования служат источником проведения дальнейшего анализа. Для чего над ними проделываются следующие операции:
- очистка требований от позиций, не являющимися таковыми;
- отыскиваются и устраняются противоречия в требованиях;
- уточняются непонятные и неоднозначно трактуемые требования;
- детализируются высокоуровневые требований;
- удаляются дубли требований.
Открытые вопросы прорабатываются со всеми вовлеченными сторонами, однако в отличие от процедуры сбора и выявления требований, проводимой в формате семинаров, обсуждение ведется точечно и по мере необходимости. Здесь же дается предварительная оценка технической реализуемости выявленных требований. Далее осуществляется приоритизация требований. В работе [1] описаны различные способы приоритизации:
- трехуровневая шкала приоритетов;
- MoSCoW;
- на основе ценности, стоимости и рисков.
В практике внедрения платформенных программных решений наиболее используемым является метод трехуровневых шкал, присваивающий каждому требований низкий, средний или высокий приоритет. Ранжирование потребностей ведется, принимая во внимание следующее:
- наивысший приоритет отдается требованиям, реализация которые обязательна согласно законодательству РФ;
- высокий приоритет имеют требования, обеспечивающие значительное снижение трудозатрат сотрудников;
- высоким приоритетом обладают системные требования, без которых программное решение не сможет полноценно работать.
Установка средних и низких приоритетов проводится интуитивно, однако, финализация является ответственностью владельцев процессов или же ключевых бизнес-пользователей организации.
5. Документирование требований
Проанализированные и приоритизированные требования подлежат дальнейшему документированию. Выделяют два основных документа, позволяющих описывать и контролировать требования на протяжение жизненного цикла программного обеспечения:
- спецификация требований;
- матрица отслеживания требований.
Определение 2. Спецификация требований (Software Requirement Specification, SRS) содержит детальное описание потребностей, понятное как бизнес-пользователям, так и техническим специалистам.
Другими наименованиями этого документа могут служить: спецификация требований к программному продукту, функционально-технические требования и ФТТ. Обычно ведется отдельный документ спецификации требований для каждого функционального направления. Не лишним будет отметить то, что документ создается преимущественно на фазе анализа при имплементации программного продукта. В последующем содержание документа переносится в проектные решения и/или функциональные спецификации на разработку. Довольно часто в последних дается лишь ссылка на конкретный пункт документа спецификации требований, что исключает дублирование данных.
Определение 3. Матрица отслеживания требований (Requirement Traceability Matrix, RTL) представляет собой список верхнеуровневых требований, обогащенный информацией по:
- взаимозависимостям требований;
- тому, как потребность будет реализовываться в программной системе;
- заявителю;
- дате регистрации;
- статусе исполнения и др.
Следуя названию, матрица позволяет контролировать ход реализации требования от момента его регистрации до реализации в информационно-программной системе (рис. 3). Существенным является то, что требованию при создании его в матрице отслеживания присваивается уникальный идентификатор, используемый во всех последующих проектных документах и активностях.
6. Утверждение требований
Содержание спецификации требований, а также часть атрибутов матрицы отслеживания требований подлежат обязательному согласованию со стороны бизнес-пользователей, которыми чаще всего являются владельцы процессов. Проверка требований перед их утверждением позволяет убедиться в том, что:
- в спецификации требований правильно описаны возможности и характеристики будущего программного продукта, удовлетворяющие всем заинтересованным сторонам;
- зафиксированные требования отражают бизнес-требования, требования пользователей, системные требования, а также функциональные и нефункциональные;
- требования являются полными, реализуемыми и проверяемыми;
- требования согласуются друг с другом в рамках функционального направления и между ними;
- приоритет требований соответствует выгодам, получаемым от их реализации;
- требования описаны со степенью детализации, достаточной для старта работ по проектированию и/или реализации.
Матрица отслеживания содержит минимально достаточную информацию о потребностях, включая приоритет и верхнеуровневое техническое решение, совокупность подобных требований задает объем последующего проекта имплементации ...
Полный текст статьи: https://corpinfosys.ru/archive/2024/issue-27/274-2024-27-requirements
