2.8 Требования к программному обеспечению

Обзор и мотивация

Требование к программному обеспечению это утверждение о возможности или условии, которое система должна обеспечивать, удовлетворять или иметь, чтобы быть приемлемой для её заинтересованных сторон. Инженерия требований, дисциплинированная работа по выявлению, анализу, описанию, проверке и управлению этими утверждениями, находится в самом начале цепочки создания ценности. Всё последующее, от архитектуры до кода и приёмочного тестирования, попытка удовлетворить требования. Поэтому когда требования неверны, неполны или неоднозначны, все усилия, потраченные на правильное построение не того, чистая потеря, и это самая дорогая потеря, потому что обнаруживается позже всех. Область знаний «Требования к программному обеспечению» в своде знаний по программной инженерии (SWEBOK) рассматривает это как настоящую инженерную дисциплину, а не канцелярскую прелюдию к настоящей работе.

Для больших команд требования это общее понимание, позволяющее многим людям строить одну связную систему. Один разработчик может держать замысел в голове; сотни людей в многих командах не могут. Требования становятся контрактом между теми, кому нужна возможность, и теми, кто её строит, основой для распределения работы между командами и мерилом для суждения, когда что-то «готово». Они напрямую связаны с исследованием (глава 11.1), где выходят на поверхность проблемы и возможности; с основами UX (глава 5.1), где вы понимаете потребности пользователей; с API и проектированием интерфейсов (глава 2.3), где фиксируются обязательства интерфейсов; с архитектурой и атрибутами качества (глава 3.1), где нефункциональные требования определяют структуру; и с управлением проектами (глава 10.6), где вокруг них планируются объём, стоимость и график.

В корпоративной и государственной среде требования несут юридический, контрактный вес и вес безопасности. Регулируемая система должна показать, что каждое предписанное обязательство (доступность, приватность, безопасность, хранение записей, финансовый контроль) зафиксировано как требование, реализовано и проверено свидетельствами. Государственные закупки часто строятся вокруг спецификации требований, а оплата, аудит и сертификация зависят от прослеживания каждого требования до свидетельств его выполнения. Здесь требования больше, чем хорошая практика: они хребет подотчётности.

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Лучше всего для	Плюсы	Минусы
Формальная спецификация заранее	Высокогарантийных, регулируемых контрактов с фиксированным объёмом	Сильная прослеживаемость; ясная основа приёмки; проверяемо	Медленно меняется; риск перестараться с описанием до обучения
Гибкий бэклог	Развивающихся продуктов с вовлечёнными заинтересованными сторонами	Быстрая обратная связь; адаптация к обучению; меньше потерь на непостроенном объёме	Слабее долгосрочная прослеживаемость; труднее аудит и контракт
Гибрид (формальные ограничения + гибкое поведение)	Корпораций со смешанными обязательствами	Строгость там, где важно, гибкость в остальном	Требует суждения о том, какие части какие

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

Вопросы для обсуждения с командой

Кто считается заинтересованной стороной для нашей самой рискованной системы и кого мы постоянно упускаем до приёмки? В большой программе пропускаются редко очевидные пользователи: операторы, запускающие систему в три часа ночи, аудиторы, которым предстоит её сертифицировать, персонал поддержки, принимающий сбои, и затронутые непользователи, которые никогда не входят в систему, но чьи данные вы храните. Упустите их, и обнаружите их требования в самый дорогой момент, во время приёмки или после вопроса регулятора. Принесите на встречу конкретную карту заинтересованных сторон и проверьте её на прочность: для каждого предписанного обязательства (доступность, приватность, хранение записей, безопасность) назовите человека, владеющего им, и требование, его фиксирующее. Если вы не можете назвать владельца, вы нашли пробел, и исправление состоит в добавлении этой стороны в выявление сейчас, а не в дооснащении её потребностями зафиксированной архитектуры позже.
Когда требование меняется, можем ли мы ответить, что оно затрагивает, до одобрения изменения? Это практическая проверка того, реальна ли ваша двунаправленная прослеживаемость или декоративна. В большой или регулируемой системе одно изменение правила может отозваться рябью в проекте, коде, тестах и свидетельствах приёмки, а одобрение вслепую это способ выпустить выглядящую соответствующей систему, тихо нарушающую правило, которое она раньше выполняла. Принесите недавний запрос на изменение и попробуйте проследить его вперёд на встрече: если это занимает день раскопок, ваша прослеживаемость не выполняет задачу. Ответ должен перестроить ваш процесс изменений так, чтобы оценка влияния была быстрым запросом к живому следу, а не ручными поисками, а базовые уровни и версионирование давали стабильную точку, относительно которой менять.
Где живёт единый авторитетный источник наших требований и сколько истины разбросано вне его? Расползание требований (настоящая спецификация, живущая в письмах, тикетах, слайдах и чьей-то памяти) один из самых частых провалов больших команд и фатален в проверяемых системах, где нужно показать, что было согласовано. Решите вслух, какая система записи каноническая, и воспринимайте всё сказанное в другом месте как черновик, пока оно не окажется там с прикреплёнными источником и обоснованием. Принесите свидетельства: сосчитайте, сколько недавних споров об объёме свелось к двум людям, цитировавшим разные «окончательные» версии. Если число больше нуля, действие в том, чтобы консолидироваться к одному источнику и записать обоснование каждого требования, потому что знание, почему требование существует, именно то, что позволяет безопасно его изменить или отбросить позже.
Фиксируются ли наши нефункциональные требования достаточно рано, чтобы определять архитектуру, или мы продолжаем обнаруживать их после того, как структура зафиксирована? Обязательства по производительности, доступности, безопасности и доступности для людей с инвалидностью формируют архитектуру больше, чем большинство функций, и в большой программе это требования, чаще всего выходящие на поверхность слишком поздно, когда структура, которая должна их удовлетворять, уже залита в бетон. Противоположное тяготение реально: функциональное поведение то, о чём заинтересованные стороны просят вслух и что хорошо демонстрируется, тогда как требование «менее секунды отклика при пиковой нагрузке» или «соответствие стандарту WCAG» невидимо, пока не нарушено. Принесите текущий список нефункциональных требований вашей самой рискованной системы, момент на временной шкале, когда каждое было написано, и получила ли архитектура (глава 3.1) их как явные драйверы или вывела. В корпоративной и государственной среде добавьте предписанные обязательства по качеству (шифрование, хранение записей, закон о доступности) и проверьте, что каждое письменное измеримое требование, переданное в проектирование, а не допущение, потому что дооснащение атрибута качества после приёмки то место, где бюджеты и графики тихо умирают.
Какой уровень формальности правилен для каждой системы, которой мы владеем, и выбираем ли мы его по риску или по привычке? Одна большая организация обычно ведёт целый спектр систем, от одноразового внутреннего инструмента до регулируемой платформы, от которой зависят жизнь и безопасность, и применение одной церемонии ко всем либо хоронит малорисковую работу в бумагах, либо оставляет высокорисковую недоописанной. Напряжение между проверяемостью и твёрдой основой приёмки формальной спецификации заранее и быстрой обратной связью и сниженными потерями эволюционирующего бэклога, а честный ответ для большинства корпораций это намеренное смешение: формализовать и прослеживать стабильные высокогарантийные обязательства, итеративно прорабатывая поведение продукта. Принесите короткую опись ваших систем, ранжированных по последствиям отказа, регуляторному риску и скорости изменений, и для каждой назовите формальность, которую вы используете, против формальности, которой оправдан риск. Для государственной программы, привязанной к заявке на закупку и стандарту вроде IEEE 29148, формальность отчасти диктуется контрактом, поэтому обсуждение о том, где можно наложить гибкую проработку сверху, не разрушив прослеживаемость, от которой зависит аудит.
Можно ли проверить каждое требование в нашей самой рискованной системе и несёт ли каждое критерии приёмки, написанные в момент написания требования? Требование, которое нельзя проверить, не требование, а пожелание, а скользкие слова вроде «быстро», «безопасно» или «удобно» проходят ревью именно потому, что никто не может их провалить. Для большой команды это важно вдвойне: непроверяемые требования порождают споры об объёме при приёмке и делают невозможным сказать, когда функция действительно готова. Противоположное соображение это скорость, поскольку прикрепление измеримого критерия и метода проверки к каждому требованию медленнее заранее, чем написание прозы, но это самая дешёвая защита от самой дорогой поздней переделки. Принесите выборку недавних требований и проверьте каждое по простой планке: атомарно ли оно, измеримо ли и называет ли, как будет проверено. В регулируемом и государственном контексте продлите проверку до свидетельств: требование без прослеженного, проходящего свидетельства приёмки не считается поставленным, что бы ни казалось делающим программное обеспечение, поэтому критерии приёмки зародыш записи соответствия, которую вам в итоге придётся предъявить.

Взгляд по секторам

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

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

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

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Начальный. Требования неявны или устны, фиксируются непоследовательно и реактивно. Споры об объёме и переделки обычны; нет ни прослеживаемости, ни критериев приёмки, ни определённого процесса.
Уровень 2, Развитие. Некоторые команды записывают требования и отслеживают их по проектам с базовой приоритизацией и стихийной обработкой изменений. Практики существуют, но различаются по командам и людям, поэтому категории, формальность и качество непоследовательны по организации.
Уровень 3, Стандартизация. Стандартный процесс требований задокументирован и соблюдается по всей организации: определённые категории, практики выявления и валидации, критерии приёмки, прикрепляемые при написании, единый авторитетный источник и двунаправленная прослеживаемость от потребности до теста, последовательно адаптированные к гибкому или плановому контексту.
Уровень 4, Управление. Процесс измеряется и контролируется данными. Волатильность требований, происхождение дефектов, охват прослеживаемостью и доля поставленной работы, прослеживаемая до валидированной потребности, отслеживаются относительно базовых значений; прослеживаемость продлена до свидетельств приёмки и соответствия; а метрики требований питают прогнозирование проектов (глава 10.6), так что решения об изменениях и качестве опираются на свидетельства, а не на мнения.
Уровень 5, Оркестрация. Практика требований непрерывно улучшается и интегрирована по организации. Формальность адаптивно настраивается по риску и результату, инструменты выявления и прослеживаемости связаны с исследованием, архитектурой и поставкой, а организация использует собственную историю измерений, чтобы предотвращать повторяющиеся дефекты требований до того, как они попадут в код.

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
Karl Wiegers and Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
Suzanne Robertson and James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (requirements engineering chapters)

2.8 Требования к программному обеспечению

Обзор и мотивация

Ключевые принципы

Рекомендации

Определяйте требования ясно и категоризируйте их

Выявляйте из реальных источников, а не из допущений

Анализируйте, согласовывайте и расставляйте приоритеты

Описывайте на правильном уровне формальности

Валидируйте до построения

Управляйте требованиями и поддерживайте прослеживаемость

Адаптируйтесь к гибким и плановым контекстам