Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
09 ноября 2022 Все для начинающего РМа
0

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

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM

Лет 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 пункта лучше, конечно, выносить в отдельные разделы или делать приложениями, но если очень хочется – можно и в раздел с нефункциональными требованиями, главное – чтобы эти требования в ТЗ в принципе были.

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: