Качество требований

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

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

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

В BABOK – своде знаний по бизнес-анализу от IIBA – проверка требований описывается как отдельная задача. Её цель – убедиться, что требования достаточно качественные для проектирования, разработки, тестирования и согласования. Похожий подход есть и в IEEE 830 – стандарте IEEE по спецификации требований к программному обеспечению. BABOK IEEE 830

1Что такое качество требований

Качество требований – это то, насколько требование понятно, полно и удобно для дальнейшей работы. Хорошее требование должно помогать при ответе на шесть простых вопросов:

Пример: «быстро» – это сколько?

Для обычного бытового разговора фраза «система должна быстро загружать список документов» нормальная. Но для разработки – нет. Слово «быстро» каждый понимает по-своему.

2Хорошее и плохое требование

Хорошее требование

Хорошее требование помогает всем участникам проекта одинаково понять задачу. Оно обычно отвечает всем этим критериям:

Здесь понятно: кто выполняет действие · какое действие · когда доступно · какие условия должны быть выполнены.

Плохое требование

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

Требование и готовое решение – не одно и то же

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

3Основные дефекты требований

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

⚠️ Важно: описывайте не только успешный сценарий

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

4Почему плохие требования дорого стоят

Может показаться, что плохое требование – это просто «плохая формулировка». Ну написали не очень точно, потом поправим. На самом деле проблема глубже.

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

Накопительная стоимость дефекта

Как это происходит на практике

Плохое требование не всегда сразу приводит к заметной проблеме. Обычно всё происходит незаметно.

Плохие требования – это не только плохие формулировки

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

Сами по себе изменения – это нормально. Проблема начинается, когда они бесконтрольно добавляются в уже согласованную задачу. Тогда команда теряет границы работ, сроки становятся нереалистичными, а качество решения падает.

5BA vs SA: как проверяют требования

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

Как может выглядеть проверка на практике

6Как вручную находить неоднозначность

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

6.1 Размытые слова – красные флаги в тексте

Слова, которые стоит искать в своих требованиях и каждый раз останавливаться, чтобы уточнить смысл:

6.2 Стоп-слова в требованиях

Некоторые слова и формулировки должны сразу привлекать внимание аналитика. Они не всегда запрещены, но почти всегда требуют уточнения. Стоп-слова показывают место, где нужно остановиться и уточнить смысл – иначе команда начнёт додумывать правило сама.

6.3 Неясные роли

Слово «пользователь» без уточнения роли – один из самых распространённых источников путаницы. В системе одновременно могут работать авторы документов, согласующие, руководители отделов, администраторы. Разные роли имеют разные права, и требование должно это отражать.

6.4 Неясные местоимения

Местоимения «он», «она», «они», «это» делают требование неоднозначным, если из контекста не очевидно, к кому или к чему они относятся. Особенно опасно, когда в одном предложении упоминаются несколько участников – пользователь, система, согласующий. Читающий должен угадать, кто именно совершает действие.

6.5 Неопределённые термины

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

6.6 Фразы «как в другой системе» без уточнений

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

Опасные формулировки: «сделать как в Кадровом портале», «повторить как на старом экране», «сделать аналогично текущей системе», «как сейчас, только лучше».

7Чек-лист ревью качества требований

Используйте перед тем, как отдавать требования в разработку, тестирование или на согласование. Чек-лист основан на классических характеристиках качества требований из BABOK и IEEE 830. Отмечайте выполненные пункты.

Итоговая самопроверка

8Тест по материалу

Проверьте, как усвоили материал. Три блока: одиночный выбор, множественный выбор и группировка. После каждого вопроса нажмите «Проверить».