К. Вигерс. Глава 15. Утверждение требований

Глава про экспертизу требований. Можно выделить три способа проведения экспертизы:

1) Проверка «за столом» – просьба к одному коллеги исследовать вашу спецификацию требований;

2) Коллективная проверка – то же самое, что и выше, только несколько коллег;

3) Критический анализ – автор описывает создаваемый продукт и просит его прокомментировать.

Проведение экспертизы:

• участники: ГИП, разработчики, технолог, РП смежных систем. Главное не созывать много людей;
• входные критерии: 
• док должен соответствовать шаблону; 
• выполнить проверку правописания; 
• пронумеровать требования; 
• все дополнительные материалы (на которые ссылаются требования); 
• пометить требования, требующие уточнения.
• Этапы экспертизы:
• Планирование;
• Обзорная встреча;
• Подготовка экспертов (изучение предметной области);
• Совещание (не стоит начинать если эксперты не подготовлены);
• Переработка;
• Заключительный этап.
• Выходные критерии:
• Все вопросы сняты;
• Все изменения внесены;
• Правописание проверено;

Также есть возможность проверки контрольными списками:

Таблица 2. Контрольные списки дефектов для документов о вариантах использования

1	Является ли конкретный вариант использования продукта автономной и отдельной задачей?
2	Ясно ли сформулирована цель или измеряемое значение для конкретного варианта использования продукта?
3	Очевидно ли, кто получит преимущества от этого варианта использования?
4	Написан ли вариант использования на базовом уровне, без ненужных деталей, связанных с дизайном и реализацией?
5	Все ли предполагаемые альтернативные направления задокументированы?
6	Все ли известные условия исключения задокументированы?
7	Есть ли какие-либо последовательности действий, которые можно разделить на отдельные варианты использования?
8	Все ли этапы каждого направления записаны в ясной, недвусмысленной и полной форме?
9	Каждый ли исполнитель и стадия варианта использования продукта соответствуют выполнению конфетной задачи?
10	Осуществимо ли и поддается ли проверке каждое альтернативное направление, определенное в варианте использования?
11	Должным ли образом структурируют вариант использования выходные и выходные условия?

 Таблица 3. Контрольные списки дефектов для спецификации требований к ПО

Организация и завершенность
1	Корректны ли все ли внутренние перекрестные ссылки на другие документы?
2	Написаны ли все ли требования на одном и том же соответствующем уровне детализации?
3	Обеспечивают ли требования адекватную основу для дизайна?
4	Указан ли приоритет реализации каждого требования?
5	Определены ли все внешние интерфейсы оборудования, ПО и взаимодействия?
6	Определены ли все алгоритмы, соответствующие функциональным требованиям?
7	Включены ли в спецификацию требований к ПО все известные потребности клиента или системы?
8	Отсутствует ли в требовании какая-либо необходимая информация? Если да, помечена ли она значком «TBD»?
9	Задокументировано ли ожидаемое поведение системы для всех предполагаемых ошибочных условий?
Корректность
1	Конфликтуют ли какие-либо требования с другими требованиями или повторяют их?
2	Написано ли каждое требования ясным, точным и недвусмысленным языком?
3	Можно ли проверить каждое требование с помощью тестирования, демонстрации, просмотра или анализа?
4	He выходит ли какое-либо требование за границы проекта?
5	Нет ли в каком-либо требовании тематических или грамматических ошибок?
6	Можно ли реализовать все требования, не выходя за рамки установленных ограничений?
7	Все ли перечисленные сообщения об ошибках уникальны и выразительны?
Атрибуты качества
1	Все ли задачи, связанные с производительностью, сформулированы соответствующим образом?
2	Все ли соображения, касающиеся охраны труда и безопасности, сформулированы соответствующим образом?
3	Приведены ли все ли соответствующие задачи, связанные с атрибутами качества, ясно задокументированы и подсчитаны, с учетом приемлемых компромиссов?
Возможность отслеживания
1	Каждое ли требование идентифицировано уникально и корректно?
2	Прослежено ли каждое функциональное требование до более высокого уровня (например, требования к системе или вариант использования)?
Особые проблемы
1	Все ли требования можно отнести к именно к требованиям, а не к решениям разработки или реализации?
2	Идентифицированы ли все функции, зависящие от времени, и определены ли их критерии?
3	Были ли рассмотрены соответствующим

Кроме того, описан процесс тестирования требований.