Теоретические основы экспертизы сайта на соответствие техническому заданию 📚

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

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

Объектом экспертизы выступает сайт как программный продукт, рассматриваемый одновременно в нескольких измерениях.

1. Первое измерение — функциональное: сайт есть совокупность реализованных возможностей, доступных пользователю и администратору.
2. Второе измерение — структурное: сайт есть организованная система страниц, разделов, связей и маршрутов перемещения.
3. Третье измерение — содержательное: сайт есть носитель информации, представленной в текстовой, графической, мультимедийной форме.
4. Четвёртое измерение — техническое: сайт есть комплекс программных, серверных и сетевых решений, обеспечивающих его работоспособность.
5. Пятое измерение — эксплуатационное: сайт есть объект сопровождения, обновления и развития.

Экспертиза, ограниченная лишь одним из этих измерений, неизбежно даёт неполную картину и потому не может считаться добросовестной.

Предмет экспертизы образуют отношения соответствия и несоответствия между требованиями технического задания и фактическими характеристиками сайта. Эти отношения не сводятся к бинарной оппозиции «выполнено — не выполнено». Между полным соответствием и полным несоответствием располагается широкий спектр промежуточных состояний: частичное соответствие, соответствие с оговорками, неоднозначное соответствие, соответствие при условии истолкования, формальное соответствие при содержательном расхождении. Теория экспертизы должна располагать аппаратом для различения этих состояний, иначе её выводы окажутся огрублёнными и практически малопригодными.

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

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

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

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

Нормативная и договорная база как критериальная основа экспертизы сайта на соответствие ТЗ ⚖️

Критериальная основа экспертизы сайта формируется из нескольких взаимосвязанных слоёв, каждый из которых задаёт собственный уровень требований.

1. Первый слой образуют нормы общего характера, определяющие обязательные условия существования любого сайта как информационного ресурса.
2. Второй слой составляют договорные условия, фиксирующие взаимные обязательства сторон, участвующих в создании и передаче сайта.
3. Третий слой образует само техническое задание, выступающее непосредственным и главным критериальным документом.
4. Четвёртый слой образуют внутренние регламенты организации, если сайт создаётся или эксплуатируется в её интересах.

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

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

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

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

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

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

Особого внимания заслуживает вопрос о приоритете критериев при их коллизии. Возможны ситуации, когда договор и техническое задание расходятся, когда внутренний регламент противоречит договору, когда профессиональное требование вступает в конфликт с прямым указанием технического задания. Эксперт не устраняет такие коллизии произвольно; он фиксирует их, указывает, какие выводы следуют из каждого варианта приоритета, и предлагает сторонам определить порядок разрешения. Тем самым критериальная основа экспертизы остаётся прозрачной, а само заключение — воспроизводимым и защищённым от упрёков в субъективности.

Архитектура, структура и навигация сайта в контексте экспертизы на соответствие ТЗ 💻

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

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

Отдельным предметом проверки выступает глубина вложенности. Техническое задание может устанавливать предельное число уровней, и превышение этого предела является несоответствием, даже если сам по себе продукт остаётся работоспособным. Аналогично проверяется количество элементов в навигационных блоках, поскольку избыточное их число затрудняет ориентирование, а недостаточное — лишает пользователя доступа к части содержания. Здесь важно избегать оценочных суждений вкусового характера: эксперт устанавливает соответствие или несоответствие числовым и структурным параметрам, заданным в техническом задании, а не оценивает красоту решения.

Навигация рассматривается в трёх аспектах.

1. Первый аспект — глобальная навигация, обеспечивающая доступ к основным разделам с любой страницы.
2. Второй аспект — локальная навигация, обеспечивающая перемещение внутри раздела.
3. Третий аспект — контекстная навигация, связывающая содержательно близкие материалы.

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

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

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

Наконец, архитектура оценивается с точки зрения её расширяемости, если техническое задание содержит соответствующие указания. Если предусмотрено дальнейшее развитие сайта, эксперт проверяет, допускает ли фактическая структура добавление новых разделов без перестройки существующих. Экспертиза программного продукта на соответствие ТЗ в этой части требует особой аккуратности: вывод о недостаточной расширяемости должен опираться на конкретные требования, а не на общие соображения о желательности запаса. Только при таком подходе заключение по третьей части органично соединяется с выводами предыдущих и последующих разделов.

Функциональная экспертиза сайта на соответствие ТЗ 🌐

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

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

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

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

Проверке подлежат также функции обработки данных и формирования отчётности. Если техническое задание предусматривает получение отчётов, эксперт устанавливает, соответствуют ли фактически формируемые отчёты заданному составу показателей, порядку их представления и условиям формирования. Расхождение в составе показателей является несоответствием, даже если отчёт в целом работоспособен.

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

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

Контентная и визуальная экспертиза сайта на соответствие ТЗ 📋

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

Контентная проверка начинается с установления перечня материалов, предусмотренных техническим заданием. Материалы подразделяются на обязательные и факультативные, на постоянные и обновляемые, на текстовые, графические и мультимедийные. Для каждой категории определяется, какие требования к ней предъявлены: требования к наличию, к объёму, к периодичности обновления, к структуре, к языку изложения, к оформлению ссылок и пояснений. Затем производится фактическая проверка: устанавливается, какие материалы присутствуют, какие отсутствуют, какие представлены в ином объёме или в иной форме, чем предусмотрено.

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

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

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

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

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

Техническая и эксплуатационная экспертиза сайта на соответствие ТЗ 🌐

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

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

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

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

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

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

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

Документирование результатов экспертизы сайта на соответствие ТЗ 📄

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

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

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

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

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

Структура итогового документа включает несколько обязательных частей. Вводная часть содержит сведения об объекте проверки, о документах, принятых в качестве критериев, об условиях проведения. Основная часть содержит результаты проверки по каждому требованию. Заключительная часть содержит сводную оценку, в которой указывается, какие требования выполнены полностью, какие выполнены частично, какие не выполнены, а какие не могут быть оценены в силу неопределённости самих требований. Такая сводка даёт сторонам ясную картину состояния продукта.

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

Заключение ✅

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

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

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

Наконец, работа показала, что доказательственная основа является неотъемлемым условием экспертизы. Наблюдения должны быть описаны так, чтобы их можно было повторить; выводы должны быть связаны с требованиями; условия проверки должны быть зафиксированы. Только при соблюдении этих условий заключение приобретает характер документа, пригодного для практического использования. Экспертиза программного продукта на соответствие ТЗ в применении к сайту предстаёт как дисциплинированная аналитическая процедура, соединяющая строгость формального сопоставления с вниманием к особенностям веб-продукта как объекта, существующего в изменчивой среде и предназначенного для постоянного взаимодействия с пользователем.