Перевірка та вимірювання вимог

Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято

считать, что требования описаны не полностью, если для них не заданы правила V&V (verification&validation - проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.

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

Если стандарты жизненного цикла описывают как правильно создавать продукт, то стандарты (в том числе, внутрикорпоративные) отвечают за создание правильного продукта, то есть того продукта, который соответствует ожиданиям пользователей и других заинтересованных лиц. Для достижения этой цели применяется ряд практик, в том числе, представленных ниже.

Обзор требований (Requirements Review)

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

Вопросы обзора требований, вообще говоря, имеют непосредственное отношение к теме качества.

Прототипирование (Prototyping)

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

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

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

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

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

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

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

Утверждение модели (Model Validation)

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

Приемочные тесты (Acceptance Tests)

Требования должны быть верифицируемы. Требования, которые не могут быть проверены и аттестованы (утверждены) - это всего лишь "пожелания". Именно так они буду восприниматься разработчиками, даже в случае их высокой значимости для пользователей. Если описанное требование не сопровождается процедурами проверки - в большинстве случаев говорят о недостаточной детализации или неполном описании требования и, соответственно, спецификация требований должна быть отправлена на доработку и если необходимо, должны быть предприняты дополнительные усилия, направленные на сбор требований.

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

Идентификация и разработка приемочных тестов для нефункциональных требований часто оказывается наиболее трудоемкой задачей. Для ее решения обычно "ищут точку опоры", то есть возможность взгляда на описываемые требования с количественной точки зрения, в плоть до переформулирования и большей степени детализации описания таких требований.