Критерии качества требований с примерами (Часть 2)

Атомарность (или «единичность»)

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

Пример 1: «Если пользователь нажимает ‘Отмена’, он должен вернуться на главную страницу, а изменения должны быть сброшены.»
Здесь объединены два разных сценария: возврат на главную страницу и сброс изменений, которые могут быть реализованы независимо друг от друга.
Атомарные требования: 
— при нажатии ‘Отмена’, все внесенные изменения должны быть сброшены.
— при нажатии ‘Отмена’, пользователь должен вернуться на главную страницу.

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

Необходимость (или «обязательность»)

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

Пример 1: «В приложении должна быть возможность авторизоваться через социальную сеть Line.»
Если продукт ориентирован на российскую аудиторию, доля пользователей из стран Азии составляет мизерный процент, и компания НЕ планирует продвижение в Азии, то поддержка авторизации через соц. сеть, популярную именно в Азии, не добавляет существенной ценности и не соответствует целям компании. Такое требование не является необходимым и обязательным для реализации.

Пример 2: 
Первоначальное требование: «Пользователи должны иметь возможность вернуться на предыдущую страницу с помощью кнопки «Назад».»
Новое требование: «Пользователи должны иметь возможность вернуться на предыдущую страницу с помощью жеста свайпа.»
Кнопка «Назад» становится ненужной после внедрения жеста. Так как жест выполняет ту же функцию, но удобнее и соответствует современным стандартам пользовательского интерфейса. После удаления кнопки «Назад» должно быть удалено и требование о ней. Иначе будет путаница.

Пример 3: «Приложение должно поддерживать браузер Internet Explorer 10.» Это требование стало устаревшим и должно быть удалено, так как Internet Explorer 10 больше не используется и не поддерживается разработчиками.

Прослеживаемость (или «трассируемость»)

Требования должны быть оформлены в структурированном виде и, в идеале, иметь уникальные идентификаторы. В контексте тестирования прослеживаемые (или «трассируемые») требования — это те, которые удобно связать с тестами. Для этого используются матрицы трассировки. В общем виде такая матрица выглядит так:

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

Пример 1: 
«Приложение должно обеспечивать высокую безопасность, поддерживать различные уровни доступа для пользователей и администраторов, иметь возможность интеграции с внешними системами, такими как системы управления проектами; также оно должно работать на мобильных устройствах и поддерживать уведомления. Пользовательский интерфейс должен быть интуитивно понятным, с возможностью настройки тем, а производительность должна быть достаточной для работы с большими объемами данных. Важно обеспечить стабильную работу системы при одновременном подключении большого количества пользователей.»

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

Модифицируемость

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

Пример 1: 
В разделе «Авторизация» в Notion: «Все пользователи системы должны проходить двухфакторную аутентификацию для доступа к личным данным.»
В разделе «Безопасность» в Confluence: «Все пользователи системы должны проходить двухфакторную аутентификацию для доступа к личным данным.»

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

Понятность

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

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

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