Лекция «Формализация требований и ТЗ — как написать то, по чему систему можно принять»

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

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 52 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Порядок тем взят не из учебника, а из трудовой функции B/01.5 действующего профессионального стандарта «Бизнес-аналитик» (приказ Минтруда от 22.11.2023 № 821н, в силе с 01.09.2024): классификация, формальное описание, атрибуты, критерии качества, верификация и валидация, управление изменениями. Начало — четыре типа требований и отдельная тема про переходные: единственные, у которых есть срок годности, и те, из-за пропуска которых система оказывается принятой, но нерабочей — данные не перенесены, люди не обучены, старый контур выключить нечем. Дальше формулировка: пять шаблонов EARS из практики Rolls-Royce с правилом «ровно одно имя системы» и честными границами — больше трёх предусловий подход не держит, нефункциональные требования в него не ложатся. Для них — девять характеристик качества продукта ISO/IEC 25010:2023 как чек-лист охвата, где производительность распадается на время отклика, использование ресурсов и ёмкость. Середина лекции — документ: десять обязательных разделов ГОСТ 34.602-2020 и примечание, по которому пустой раздел не выбрасывают, а пишут в нём запись об отсутствии требований; правило «для каждой функции указан результат её выполнения»; восемь видов обеспечения, один из которых описывает работу людей и регламенты; механизм пункта 5.3 — как подписать задание, в котором часть чисел ещё неизвестна; и граница со вторым стандартом, ГОСТ 19.201-78 на программу, которая проходит по наличию персонала и организационного обеспечения. Вторая половина — управление: одиннадцать атрибутов требования с методом проверки как мостом к приёмке, трассируемость вверх и вниз с тремя проверяемыми вопросами, шесть характеристик требования по пункту 3.4 ГОСТ против девяти в ISO 29148 с расхождением по актуальности, восемь языковых дефектов и эмпирика их автоматического поиска: средняя точность детектора 59% при полноте 82%, у поиска слабых слов — 12%. Отдельная тема — исследование 171 проекта за 2006–2014 годы, не нашедшее эффекта отложенного дефекта: обещать экономию от раннего контроля нельзя, а вот требование без способа проверки по-прежнему нельзя принять. Финал — изменение задания дополнением и четыре слова, которыми оно описывается.

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

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