Для того чтобы помочь экспертам обнаружить типичные ошибки в инспектируемых продуктах, разработайте контрольный список дефектов для каждого типа документа о требованиях, создаваемого в вашей компании. С помощью таких контрольных списков вы привлекаете внимание проверяющих к часто возникающим проблемам с требованиями. На рис. 15-4 показан контрольный список для проверки варианта использования, а на рис. 15-5 контрольный список для проверки спецификации требований к ПО.
Весь длинный контрольный список запомнить невозможно. Сократите списки, сообразуясь с нуждами вашей компании, и измените их в соответствии с тем, какие проблемы в ваших требованиях повторяются чаще всего. Вы можете попросить некоторых инспекторов при подготовке использовать разные поднаборы контрольных списков. Одного проверить, верны ли перекрестные ссылки внутренней документации, другого — могут ли требования служить основой для дизайна, а третьего — оценить проверяемость требований. Проведенные исследования показали, что такое распределение обязанностей— естественно, когда экспертов снабжают четкими указаниями или сценариями, которые помогают им при поиске ошибок— более эффективно, чем когда эксперты работают по одинаковым контрольным спискам. (Porter, Votta и Basili, 1995).
| Является ли конкретный вариант использования продукта автономной и отдельной задачей? | |
| Ясно ли сформулирована цель или измеряемое значение для конкретного варианта использования продукта? | |
| Очевидно ли, кто получит преимущества от этого варианта использования? | |
| Написан ли вариант использования на базовом уровне, без ненужных деталей, связанных с дизайном и реализацией? | |
| Все ли предполагаемые альтернативные направления задокументированы? | |
| Все ли известные условия исключения задокументированы? | |
| Есть ли какие-либо последовательности действий, которые можно разделить на отдельные варианты использования? | |
| Все ли этапы каждого направления записаны в ясной, недвусмысленной и полной форме? | |
| Каждый ли исполнитель и стадия варианта использования продукта соответствуют выполнению конфетной задачи? | |
| Осуществимо ли и поддается ли проверке каждое альтернативное направление, определенное в варианте использования? | |
| Должным ли образом структурируют вариант использования выходные и выходные условия? |
Рис. 15-4. Контрольные списки дефектов для документов о вариантах использования
| Организация и завершенность | |
| Корректны ли все ли внутренние перекрестные ссылки на другие документы? | |
| Написаны ли все ли требования на одном и том же соответствующем уровне детализации? | |
| Обеспечивают ли требования адекватную основу для дизайна? | |
| Указан ли приоритет реализации каждого требования? | |
| Определены ли все внешние интерфейсы оборудования, ПО и взаимодействия? | |
| Определены ли все алгоритмы, соответствующие функциональным требованиям? | |
| Включены ли в спецификацию требований к ПО все известные потребности клиента или системы? | |
| Отсутствует ли в требовании какая-либо необходимая информация? Если да, помечена ли она значком «TBD»? | |
| Задокументировано ли ожидаемое поведение системы для всех предполагаемых ошибочных условий? | |
| Корректность | |
| Конфликтуют ли какие-либо требования с другими требованиями или повторяют их? | |
| Написано ли каждое требования ясным, точным и недвусмысленным языком? | |
| Можно ли проверить каждое требование с помощью тестирования, демонстрации, просмотра или анализа? | |
| He выходит ли какое-либо требование за границы проекта? | |
| Нет ли в каком-либо требовании тематических или грамматических ошибок? | |
| Можно ли реализовать все требования, не выходя за рамки установленных ограничений? | |
| Все ли перечисленные сообщения об ошибках уникальны и выразительны? | |
| Атрибуты качества | |
| Все ли задачи, связанные с производительностью, сформулированы соответствующим образом? | |
| Все ли соображения, касающиеся охраны труда и безопасности, сформулированы соответствующим образом? | |
| Приведены ли все ли соответствующие задачи, связанные с атрибутами качества, ясно задокументированы и подсчитаны, с учетом приемлемых компромиссов? | |
| Возможность отслеживания | |
| Каждое ли требование идентифицировано уникально и корректно? | |
| Прослежено ли каждое функциональное требование до более высокого уровня (например, требования к системе или вариант использования)? | |
| Особые проблемы | |
| Все ли требования можно отнести к именно к требованиям, а не к решениям разработки или реализации? | |
| Идентифицированы ли все функции, зависящие от времени, и определены ли их критерии? | |
| Были ли рассмотрены соответствующим образом все проблемы, связанные с интернационализацией? |
Рис. 15-5. Контрольные списки дефектов для спецификации требований к ПО