Верификация требований

Практика систематической проверки спецификаций сложилась в 1970-е годы в корпорации IBM, где М. Фейган разработал и внедрил методику формальных инспекций программных артефактов. Методика задавала фиксированные роли участников и последовательность шагов от планирования до контроля устранения замечаний; команды с инспекциями выпускали программы с заметно меньшим числом дефектов, доходивших до эксплуатации^[7]. Методика Фейгана стала одной из основ формализованного рецензирования программных артефактов. Принципы инспекций впоследствии широко применялись и к спецификациям требований, наряду с кодом и проектной документацией^[8]. Инспекции вошли в классику инженерии программного обеспечения и описаны в основных учебниках дисциплины^[9][10].

В 1984 году Б. Боэм опубликовал работу, специально посвящённую проверке спецификаций требований и проекта, где разграничил верификацию и валидацию и сформулировал принцип раннего и непрерывного подтверждения требований^[1]. В 1991 году К. Форсберг и Х. Муз представили V-модель жизненного цикла, в которой каждой ступени декомпозиции соответствует ступень интеграции и испытаний^[11]. В 1994 году О. Готел и Э. Финкельштейн проанализировали проблему трассируемости требований — способности проследить судьбу каждого требования от источника до испытаний — и показали, что обеспечение трассируемости существенно облегчается и удешевляется при её организации с самого начала проекта^[5].

К концу 1990-х годов сложилась нормативная база проверки требований: институт инженеров электротехники и электроники (IEEE) выпустил рекомендованную практику IEEE 830—1998 по составлению спецификаций требований^[12], а конференции по требованиям превратились в самостоятельное научное направление^[13]. Позднее практика IEEE 830—1998 утратила силу — её заменил международный стандарт ISO/IEC/IEEE 29148 в действующей редакции 2018 года^[6]. В России состав и содержание требований к автоматизированным системам регламентирует комплекс стандартов серии 34, действующая редакция документа о техническом задании — ГОСТ 34.602-2020, введённая с 1 января 2022 года взамен ГОСТ 34.602-89^[14].

Для самих требований различают верификацию и валидацию. Верификация проверяет качество и внутреннюю корректность спецификации требований — однозначность, согласованность, полноту, осуществимость и проверяемость. Валидация устанавливает, отражают ли требования реальные потребности, цели и ограничения заинтересованных сторон. На последующих стадиях жизненного цикла термин «верификация» применяется также к проверке соответствия проектных и реализованных решений установленным требованиям^[1][2][15].

Проверка требований охватывает два уровня. Первый — верификация самих требований как документов: спецификация до реализации анализируется на полноту, непротиворечивость, однозначность и проверяемость; средства — инспекции, рецензии, чек-листы. Второй — верификация системы по отношению к требованиям: на последующих этапах жизненного цикла испытания и другие методы проверки подтверждают соответствие реализованной системы требованиям соответствующего уровня^[11].

Основным статическим методом остаётся групповое чтение спецификации. Различают неформальный просмотр, управляемое рецензирование и формальную инспекцию; последняя отличается фиксированными ролями, метриками и обязательным контролем исправлений^[7]. Инспекции требований выявляют не только локальные ошибки формулировок, но и пропуски целых сценариев, противоречия между разделами и неосуществимые требования; их эффективность объясняется тем, что участники читают документ с разных позиций^[10]. Сравнительные эксперименты показали, что формы инспекций различаются стоимостью и охватом, а решающим фактором служит подготовка проверяющих и распределение ролей^[16].

Помимо чтения, применяют средства повышения выявляемости дефектов. Прототипирование позволяет показать заказчику обозримую модель будущего поведения системы и обнаружить неверные или упущенные требования до реализации; формальные модели — таблицы решений, конечные автоматы, сценарии — делают противоречия видимыми инструментально^[13]. Для систем, управляемых моделями, спецификации проверяются аналитическими средствами; в имитационном моделировании требования проверяются по единым принципам валидации, верификации и тестирования^[2]. Дополняют перечень аналитические чек-листы: «можно ли написать испытание, которое опровергнет это утверждение»^[4].

Динамическим подтверждением требований служат испытания. Каждое требование получает идентификатор, а между требованиями, проектными элементами и проверками строятся матрицы трассируемости; без них часть требований остаётся непроверенной^[5]. Промышленные исследования показали, что поддержание трассируемости требует систематических усилий на протяжении всего проекта и окупается лишь при ранней организации^[17]. Трассируемость ведут в обе стороны: от источников требований к утверждениям и от утверждений к проекту, коду и испытаниям^[5].

Стандарт ISO/IEC/IEEE 29148 формулирует характеристики, которым должно отвечать каждое отдельное требование (необходимость, однозначность, полнота, единственность, осуществимость и проверяемость), а также характеристики набора требований (согласованность, непротиворечивость и прослеживаемость)^[6]. Практические руководства переводят эти характеристики в рабочие критерии: требование считается качественным, если его одинаково понимают заказчик и разработчик и оно допускает объективную проверку^[4]. Слабые формулировки вида «система должна быть удобной» подлежат замене на измеримые утверждения^[4].

Проверяемость занимает особое место среди атрибутов, поскольку связывает документ с будущими испытаниями. Требование проверяемо, если существует объективный способ показать его выполнение — испытание, анализ, демонстрация или осмотр — и известны критерии успеха; иначе требование превращается в недоказуемое пожелание^[6]. Не поддающиеся проверке утверждения возвращаются на переформулирование до начала проектирования, что дешевле, чем выяснить невозможность подтверждения на приёмочных испытаниях^[4]. Для внутреннего контроля проекта можно использовать долю требований, для которых определён способ проверки:

${\displaystyle d={\frac {n_{v}}{N}},}$

где ${\displaystyle n_{v}}$ — число требований с установленным методом верификации, а ${\displaystyle N}$ — число требований в рассматриваемом наборе. Такая доля характеризует покрытие требований запланированными проверками, но сама по себе не является достаточной мерой качества или готовности спецификации.

Проверке предшествует приведение требований в документальную форму, регламентированную стандартами. Международный стандарт ISO/IEC/IEEE 29148 задаёт содержание спецификаций требований к системам и программному обеспечению, типовые разделы и шаблоны записей^[6]. Утратившая силу американская практика IEEE 830—1998 закрепляла классическую структуру спецификации требований к программному обеспечению с разделами о функциональных и нефункциональных требованиях, внешних интерфейсах и критериях приёмки; её схемы десятилетиями служили образцом документа^[12]. В российской практике требования к создаваемой системе фиксируются техническим заданием, состав которого определён ГОСТ 34.602-2020 и включает характеристики объекта, требования к функциям и видам обеспечения, стадии и этапы разработки, порядок контроля и приёмки^[14].

В V-модели жизненного цикла верификация требований задаёт симметрию левой и правой ветвей: спуск по левой ветви сопровождается планированием испытаний по правой, где каждому уровню соответствует свой уровень подтверждения^[11]. В V-модели требования и проектные решения на левой ветви служат основой для планирования соответствующих проверок на правой. Сами требования рецензируются и верифицируются как спецификация; позднее испытания и другие методы проверки подтверждают соответствие реализованной системы требованиям соответствующего уровня^[11][18]. Модель закрепила в инженерной практике правило «планируй проверку одновременно с формулированием», ставшее основой большинства регламентов разработки^[11].

Экономическое обоснование ранней проверки требований опирается на исторические оценки стоимости разработки, которые показывали, что дефекты, обнаруженные на поздних стадиях, нередко требуют более дорогой переделки, чем дефекты, найденные при анализе требований и проектировании^[3]. Конкретное соотношение затрат зависит от типа системы, процесса разработки, автоматизации тестирования и характера дефекта; его не следует считать универсальным постоянным коэффициентом^[1]. Эмпирические исследования подтверждают, что заметная часть ошибок, обнаруживаемых при тестировании, восходит к этапам требований и проектирования^[19][9][10].

Основным международным документом по инженерии требований служит ISO/IEC/IEEE 29148, действующая редакция которого принята в 2018 году; стандарт устанавливает характеристики требований, содержание спецификаций и процессы их проверки^[6]. Рекомендованная практика IEEE 830—1998, два десятилетия задававшая структуру спецификации требований, отозвана и упоминается лишь как историческая ступень^[12].

В Российской Федерации состав требований к автоматизированным системам определяется комплексом стандартов ГОСТ 34. Действующая редакция стандарта на техническое задание — ГОСТ 34.602-2020, утверждённая приказом Росстандарта в 2021 году и введённая с 1 января 2022 года взамен ГОСТ 34.602-89. Стандарт предусматривает, в частности, требования к системе, составу и содержанию работ, а также раздел «Порядок контроля и приемки системы». Не следует отождествлять формулировки ГОСТ непосредственно с терминологией requirements verification без отдельного нормативного основания^[14][20]. Прежняя редакция 1989 года утратила силу и упоминается только в историческом контексте^[14].

Верификация требований не гарантирует правильности самих потребностей: можно исчерпывающе проверить спецификацию и всё равно построить не ту систему, поэтому верификация дополняется валидацией и вовлечением пользователей^[1]. Групповые методы зависят от квалификации участников, трассируемость без инструментальной поддержки быстро теряет достоверность, а часть знаний о предметной области остаётся неявной^[13].

В промышленной практике проверка требований поддерживается специализированными программными средствами управления требованиями, которые хранят требования с идентификаторами и версиями, строят матрицы трассируемости и фиксируют статус каждого требования^[4]. Языковые шаблоны снижают двусмысленность спецификаций уже на этапе записи требований^[21], а автоматический анализ текстов дополняет ручные инспекции, отмечая двусмысленные слова и отсутствие проверяемых величин^[22][4].

Изменчивость требований создаёт особую трудность: проверенная на старте проекта спецификация устаревает, и каждое изменение требует повторной проверки затронутых требований и обновления матриц трассируемости^[17].