Проверка правильности требований

Поскольку требования есть основа любого проекта, то специалисты, вовлеченные в работу над этим проектом, должны одинаково понимать критерии хорошего (правильно сформированного) требования. Опыт показывает, что наилучшим требованием считается такое, которое может быть охарактеризовано как [18]:

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

Каждое требование должно выглядеть как законченное предложение, содержащее подлежащее и сказуемое, другими словами - содержать предметную часть и утверждение (логическое условие или высказывание). При этом в зависимости от обстоятельств в этом предложении необходимо использовать либо глагол «должен», чтобы подчеркнуть, что требование является обязательным, либо «может», чтобы показать дополнительность или факультативность данного требования. Не возбраняется использовать и смысловые вариации этих глаголов, но при соблюдении смысловых мер предосторожности, чтобы не исказить сути требования.

Помимо того что законченное требование должно точно формулировать конечную цель или определять желаемый результат, оно должно содержать критерии и оценки его успешной реализации или другие аналогичные индикаторы качества, которые можно было бы измерить, поскольку невозможно контролировать то, что нельзя измерить. Все требования должны быть поддающимися проверке. При этом пользователь несет ответственность за проверку требований на полноту и точность, а разработчик - за проверку осуществимости и понятности. Общепринятая методика проверки - тесты. Если проверка тестами невозможна, должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

Но некоторые требования (как и ассоциированные с ними тесты) должны также отображать и то, что система не должна делать ни в коем случае, или описывать, как должна функционировать система, если будет достигнуто какое-либо из оговоренных ограничений (режим ограниченного функционирования). По аналогии это правило применимо и к ограничениям (нефункциональным требованиям), в отношении которых бывает затруднительно построить тест в прямом смысле слова. Но если найти возможность сформулировать нефункциональное требование таким образом, что его можно было бы проверить, то это и будет наилучшим способом работы с требованиями. Так, вместо требования «Приложение должно обеспечить высокую степень использования» будет лучше и правильнее написать, например, следующее: «Неподготовленный пользователь должен иметь возможность создать отчет менее чем за 3 минуты».

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

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

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

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

Большинство специалистов, работающих с требованиями, находят моделирование весьма удобным и полезным дополнением к текстовым требованиям. Причем в данном случае совершенно непринципиально, что именно подразумевается под термином «моделирование»: это могут быть и рисунок, схема, алгоритм, нарисованные на доске или листке бумаги, и использование МБ РоуегРопй, и создание реальной модели (программное приложение, мнемонический прототип и т.д.). Необходимо лишь соблюдать одно важное условие: эти модели и представления должны существовать в тесной связи (параллели) с требованиями, чтобы гарантировать их общую совместимость, корректность, трассируе-мость и изменяемость (если последнее вдруг потребуется).

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

 
< Пред   СОДЕРЖАНИЕ     След >