Вещи, которые действительно должны волновать архитекторов, лидов и разработчиков.
Сегодня мы собираемся обсудить важные различия между функциональными и нефункциональными требованиями и почему нефункциональные требования должны беспокоить каждого технического специалиста, от архитектора до разработчика.
Функциональные и нефункциональные требования
Вероятно, каждый сложный программный продукт является результатом реализации функциональных и нефункциональных (иногда называемых кросс-функциональными или неповеденческиетребования).
Чтобы понять разницу между функциональными и нефункциональными требованиями, давайте представим, что мы — разработчики, которые собираются разработать и внедрить Instagram с нуля. Вот как могут выглядеть некоторые высокоуровневые функциональные требования:
- Пользователи могут загружать фотографии.
- Пользователи могут подписываться на других пользователей.
- Пользователь может отправлять личные сообщения другому пользователю.
- Пользователи могут видеть ленту новостей, которая включает фотографии других пользователей.
И вот некоторые возможныенефункциональные требования:
- Генерация новостной ленты должна занимать в среднем 500 мс, а в худшем случае не более 1 с.
- Фотографии, которые загружают пользователи, никогда не должны теряться (надежность системы).
- Доступность системы составляет 99,99% времени.
Как видно из примера с Instagram, функциональные требования описывают, что должна делать система, а нефункциональные требования определяют, как система должна себя вести.
Другими важными различиями между функциональными и нефункциональными требованиями являются:
- Система может работать, если выполняются только функциональные требования. Обычно некоторые простые продукты или PoC не заботятся о нефункциональных требованиях. Нефункциональные требования не могут быть реализованы без функциональных требований.
- Функциональные требования легко согласовать, в отличие от нефункциональных требований. Например, легко договориться, что пользователь Instagram может загружать фото (функциональное требование), но как быстро договориться о проценте доступности (нефункциональное): 99,99%?, почему бы не 99,95%?
- Функциональные требования документируются как Случаи использования системы, а нефункциональные требования документируются как Атрибуты качества.
- Бизнес-аналитики несут ответственность за выявление и документирование функциональных требований. Архитекторы программного обеспечения (а частично руководители и каждый разработчик) несут ответственность за выявление и документирование нефункциональных требований.
- И самое важное отличие с технической точки зрения заключается в том, что нефункциональные требования влияют на архитектуру, а функциональные — нет.
Функциональные требования и архитектура
Давайте вспомним, пожалуй, самую простую из возможных архитектур приложений, которая представляет собой трехуровневую архитектуру:
Дело в том, что простейшая 3-уровневая архитектура может реализовать любое количество очень сложных функциональных требований (все функциональные требования Instagram могут быть реализованы с использованием 3-уровневой архитектуры). Экземпляр базы данных потенциально может содержать сотни таблиц, а кодовая база может содержать сотни тысяч строк кода. Конечно, ремонтопригодность такой монолитной системы может снизиться по мере появления новых функций.
Однако трехуровневая архитектура успешно реализует функциональные требования, если она правильно структурирована и качество кода поддерживается на хорошем уровне. Реализация новых функций в основном потребует создания новых таблиц базы данных, расширения модели предметной области, написания новых бизнес-правил и некоторого другого вспомогательного кода.
Основной вывод заключается в том, что когда речь идет о реализации только функциональных требований, архитектура программного обеспечения и дизайн системы не имеют большого значения.
Просто, верно?
Нефункциональные требования и архитектура
Когда дело доходит до реализации нефункциональных требований, архитектура может быть очень важна. Некоторые нефункциональные требования невозможно реализовать без существенных изменений в архитектуре или дизайне системы.
Как было сказано ранее, трехуровневая архитектура позволяет успешно реализовать все функциональные требования, предусмотренные заказчиком. Представьте, что 3-уровневая система уже реализована и находится в производстве:
Но теперь появилось новое нефункциональное требование, которое ранее не рассматривалось: Все конечные точки GET должны занимать в среднем 500 мс и не более 1 с в худшем случае для 5000 одновременных пользователей.
В этом случае разработчики, конечно, могут попытаться достичь цели, оптимизировав запросы к базе данных, внедрив кэширование в памяти, сократив выделение управляемой кучи и другие оптимизации. Однако, скорее всего, в больших монолитных системах такие простые шаги не помогут.
Достижение такого сильного нефункционального требования может потребовать перепроектирования системы (что может стать кошмаром для производственной системы), например, реализации шаблона CQRS на уровне архитектуры, который также будет включать масштабирование служб чтения, наличие отдельного экземпляра кэша и другие сложные вещи:
Система программного обеспечения может потребовать изменения архитектуры, если некоторые нефункциональные требования, такие как производительность, доступность, надежность, полностью игнорируются на этапах сбора требований и проектирования. Кроме того, даже если все нефункциональные требования были зафиксированы как можно раньше, очень важно обращать внимание на цифры. Например, для реализации системы с доступностью 99,9 % и 99,95 % могут потребоваться две разные архитектуры. Кроме того, стремление к 99,95% повлечет за собой гораздо более высокие счета от поставщика облачных услуг.
- Действительно ли системе нужна доступность на уровне 99,95 %? Что стоит за этой цифрой? Почему 99,9% мало?
- Действительно ли каждая конечная точка GET должна отвечать через 500 мс? Что стоит за этой цифрой? Может быть, только одна конечная точка GET должна возвращать данные через 500 мс?
- …
Своевременное задавание этих и других вопросов может сэкономить много усилий вашей команде и денег вашим клиентам.
Почему разработчики должны заботиться о нефункциональных требованиях?
Нефункциональные требования также беспокоят технических руководителей и разработчиков, а не только архитекторов.
Когда разработчик получает историю для работы, нефункциональные требования могут вообще не упоминаться.
Например, история может быть о реализации новой конечной точки API с некоторой новой бизнес-логикой и новыми таблицами базы данных. Если нефункциональное требование, такое как максимальное время отклика API 300 мс, не упомянуто в статье и никто не разъяснил его заранее, разработчик может использовать неэффективные алгоритмы, неэффективную схему базы данных, отсутствие кэширования и т. д. только для выполнения функционала. требованиям и как можно скорее передать историю в QA.
Позже будет риск переделывать реализацию, когда QA-инженер или заказчик увидят, каково реальное время отклика. Таким образом, всего один вопрос от разработчика или технического руководителя "Какое должно быть среднее/максимальное время отклика для этого API?" заранее может помочь избежать двойной работы.
Основные выводы
- Функциональные требования могут быть реализованы с помощью простой архитектуры. Новые функциональные требования не повлияют на архитектуру системы.
- Нефункциональные требования могут оказать существенное влияние на архитектуру системы. Как архитектор, убедитесь, что важные нефункциональные требования зафиксированы как можно раньше, прежде чем проектировать и внедрять систему.
- Нефункциональные требования могут оказать существенное влияние на дизайн отдельного веб-сервиса или микросервиса, алгоритмы, структуры данных… Как технический руководитель или разработчик, уточните нефункциональные требования, такие как производительность, масштабируемость, пропускная способность, функциональная совместимость или для истории до приступить к его реализации, чтобы избежать возможных переделок в будущем.
Спасибо за прочтение. Если вам понравилось то, что вы прочитали, ознакомьтесь с этой историей ниже:
Также подумайте о том, чтобы стать участником Medium.
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу
