Как проверить, что вы не забыли про нефункциональные требования: мой чек-лист

Лет 14 назад, когда я работала аналитиком,  нефункциональные требования были моим самым страшным кошмаром. Было очень сложно ничего не забыть и при этом придумать, как на бумаге сформулировать примитивное “пользователю должно быть удобно” или или “система не должна часто ломаться”, поэтому эти разделы ТЗ я заполняла хоть как-то, лишь бы не было пусто. Ну и результаты были соответствующие – доказать подрядчику было почти ничего нельзя, постоянно возникали конфликты на тему “к пуговицам претензии есть?”. Первое, что я сделала при переходе на позицию руководителя проектов – написала чек-лист, по которому потом принимала все ТЗ. Там есть кусок и про функциональные и про нефункциональные требования, но с функциональными все намного проще, пиши себе и пиши, главное, на полноту и непротиворечивость проверить.

Чек-лист для проверки полноты нефункциональных требований вы найдете в этой статье ниже, как и всегда в управлении проектами – на 146% использовать необязательно, достаточно выбрать те нефункциональные требования, без которых результат вашего проекта может оказаться…ну, скажем, неожиданным.

Итак, поехали.

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

А, и мое самое любимое – чем конкретнее нефункциональные требования, тем (внезапно) качественнее результат. И написать в требованиях к надежности «99,99% доступности», но не пояснить, как это должно достигаться – не лучшая идея. Как впрочем, и написать в требованиях к юзабилити «пользователю должно быть комфортно».

• Надежность (Reliability) – «умение» системы работать в нужном режиме нужное время. Условно, для какой-нибудь системы управления контрактами и три дня простоя – не проблема (что, грубо, дает нам примерно 90% надежности), а вот для системы мониторинга АСУТП – все 99,5%. Но указать только процент – значит, отдать решение на откуп подрядчику. Хорошим решением тут будет прописать конкретные требования, принятые в вашей компании (или не принятые, тогда вы будете первым), например, обязательный автоматический мониторинг ключевых компонентов и систему триггеров.
• Сквозной проактивный мониторинг (End-to-end Pro-active Monitoring) – наличие механизма мониторинга, который не просто скажет «ой, база отвалилась», а сможет проанализировать всю связку компонентов и заранее выдать рекомендацию, например, «ты там загрузил 5000 записей, давай быстренько перезагрузим, а то память забита, иначе я зависну».
• Уведомления (Alerting) – наличие механизмов уведомлений в принятом в компании формате (почта, мессенджеры, вывод на мониторы и т.д.) о состоянии системы, возникших проблемах, отказах и т.д.
• Восстановление (Restart) – наличие механизмов, которые могут восстановить систему автоматически, без участия человека, требования к количеству шагов по восстановлению с участием человека и проч..
• Архивация (Archiving)– нефункциональное требование, про которое почти всегда забывают. Если, опять же, это система на три сотни контрактов – можно и без него, а если система электронного документооборота с 1000+ документов в сутки – лучше не забыть описать превентивные меры, чтобы не допустить неконтролируемого роста объема данных.
• Удаление мусора (Housekeeping) – наличие механизма автоматического удаления временных файлов, логов и т.д., опять же для экономии места и упрощения работы по расследованию инцидентов.
• Аварийное восстановление и обеспечение непрерывности (Disaster recovery и Business Continuity) – на эту тему есть целый пост, повторяться не буду.
• Производительность (Performance) – требования к времени отклика системы (причем они могут быть разными при обращении к разным компонентам системы), ну и сюда же неплохо бы прописать требования к нагрузочному тестированию, если оно предполагается.
• Сквозное логирование (End-to-end Logging) – требования к записи всех (или не всех) действий в системе, их агрегирование, возможность выгрузки из системы и т.д.
• Работа с ошибками (Error Handling) – тоже незаслуженно забываемый пункт про то, какую информацию писать в логи при возникновении ошибок в системе, какие уведомления и куда слать и т.д. Но будем честными, вживую я нефункциональные требования, где это было нормально описано, видела буквально пару раз.
• Требования к коду (Code Design) – в правильном мире розовых пони тут должна быть ссылка на утвержденный в вашей компании стандарт кодирования, но чаще всего его нет (но у нас, кстати, есть!). Если вам не повезло – придется писать руками про то, что код нужно документировать, следовать общепринятым паттернам, исключать дублирование и т.д.
• Решение инцидентов (Troubleshooting) – необходимость документировать возможные типовые инциденты и способы их разрешения. Я сама о такой штуке узнала на позапрошлой работе и до сих пор в восторге от того, насколько это облегчает передачу на поддержку и прохождение ОПЭ.
• Выполнение настроек (Configuration) – как это должно работать, чтобы максимально упростить эксплуатацию системы. Например, можно предусмотреть конфигурационный файл, а можно -–каждый раз менять параметры в коде (например, ip сервера, написала, и самой страшно стало, а ведь кто-то так делает!).
• Пользовательский интерфейс для администрирования и обслуживания (Administration and Maintenance through system frontend) – наличие возможности выполнять типовые задачи типа выдачи прав или очистки логов через интерфейс системы, а не лезть руками в конфигурационные файлы, базы данных или код. Вроде бы элементарно, но если подрядчик будет криворукий, а этого пункта в ТЗ не будет – очень вероятны сюрпризы.
• Удобство пользователя (Usability) – требования к количеству кликов до ключевых сценариев, количеству цветов (чтобы не было цыганщины), шрифтам, количеству элементов на экране, наличию (или отсутствию) выпадающих списком, ограничений для длинных строк и т.д. Сюда же – требования к языку, дизайну, прототипированию, доступу пользователей с ограниченными возможностями (что, к слову, обязательно по ФЗ для государственных организаций) и т.д. Кстати, есть даже тестирование юзабилити, очень прикольная и полезная вещь, если бюджет проекта позволяет, а юзабилити имеет критическую важность в проекте.
• Безопасность (Security) – все, что связанно c обеспечением информационной и физической (если применимо) безопасности – протоколы, версии платформ, внутренние требования службы безопасности и т.д. С этим разделом обычно проблем нет, особенно после февраля 2022г.
• Совместимость (Interoperability) – с какими внешними системами, компонентами, версиями БД, браузеров, мобильными ОС и т.д. система должна работать бесперебойно.
• ИТ-ландшафт (Landscape) – как должен быть организован дев-тест-прод, кто имеет туда доступ, как переносятся тестовые данные и т.д.

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

Ну и еще несколько пунктов, которые впрямую (по стандарту ISO) к нефункциональным требованиям не относятся, но про которые тоже часто забывают:

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

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

Расскажите в комментах, насколько подробно описываете нефункциональные требования?