Лучшие DevOps практики и кейсы

Управление требованиями


Большинство IT систем являются малыми или средними, поэтому не стоит тратить на планирование месяцы с дорогим ПО, но перед разработкой нового продукта или даже функционала стоит задумываться как это повлияет на всю систему. Избежать сжигания денег и траты времени поможет процесс управлениями требованиями. Его можно разделить на сбор, спецификацию, анализ и проверку требований.

Сбор требований

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

Можно купить рыбу в магазине, а можно потратить сотни на покупку всего необходимого для рыбалки. Определитесь - вы рыбак или просто хотите съесть рыбу? 

Спецификация требований

Разобравшись с проблемой мы начинаем определять функциональные и нефункциональные требования. С функциональными требованиями знакомы почти все, например,нужно удалить нескольких элементов - прописывается логика работы:
  • зажимаем элемент
  • элемент выделяется и в левом верхнем углу появляется чекбокс (убирается повторным нажатием)
  • наверху появляется иконку удаления
  • после нажатия на иконку удаления открывается диалог с подтверждением
  • в случае согласия элементы перемещаются в корзину
К текстовому описанию выше прикладывается проработанный дизайн, например в figma или mockup, сделанный в draw.io

На подводные камни часто можно натолкнуться в нефункциональных требованиях, потому что их просто забывают уточнить, разделим на такие типы:
  • Ограничения: в качестве облачному провайдера должен использоваться AWS; максимальный размер передаваемого файла - 100MB
  • Бизнес-правила: файл удаляется после 30 дневного нахождения в корзине
  • Внешние интерфейсы: приложение взаимодействует с API по протоколу http
  • Юридические требования: сервис должен соответствовать требованиям GDPR и HIPPA
Для лучшего составления нефункциональных требований можно воспользоваться нужными пунктами из ISO 9126 или Volere Template

Также, могут пригодится диаграммы потока данных (DFD) и реже декомпозиции функций (FDD) для того чтобы видеть картину целиком.

Проверка и анализ

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

Существующие

Если пользователь или заказчик попросил сделать уже существующий вариант, то есть 2 варианта:
  • стоит подсказать где искать и как добиться нужного результата
  • если речь идет о графическом интерфейсе, то стоит пересмотреть UX, что станет отдельной задачей
Как правило, все ограничится 1 вариантом, однако подходите с умом к навигации и удобству вашего веб или мобильного приложения.

Повторяющиеся

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

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

Противоречивые

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

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

После обработки требований можно определять приоритетность, формулировать задачи и добавлять в backlog.

Вывод

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