2024-11-21 20:08

Требования к ПО: что это, какими бывают и почему именно так — подробный гайд (часть 3)

Бизнес-анализ

Это продолжение статьи "Требования к ПО: что это, какими бывают и почему именно так — подробный гайд". Первую и вторую часть см. здесь и здесь.

Еще один аспект НФТ — требования к внешним интерфейсам (External Interfaces).

Для начала тут стоит вспомнить, что интерфейс в глобальном понимании — это механизм взаимодействия системы с внешним миром. Например, человек — это сложная система с такими интерфейсами, как глаза, рот, уши, кончики пальцев и пр. Программные системы также могут иметь и, как правило, имеют интерфейсы, то есть механизмы общения как с другими программными или аппаратными системами, так и с пользователем. Пользовательский интерфейс (User Interface, UI) — это механизм, с помощью которой пользователь может взаимодействовать с системой, причем он может быть не только графическим (командный текстовый интерфейс и голосовой интерфейс, как примеры). Помимо пользователей, программные системы могут также общаться и с другими программными системами (чаще всего через API, Application Programming Interface), а также с аппаратными устройствами. Аппаратные интерфейсы в типовой практике аналитика встречаются гораздо реже (не путаем только систему, с которой нашему решению необходимо взаимодействовать, и операционную среду решения — например, сервер, на котором размещено веб-приложение), но как пример — ваше ПО управляет принтером напрямую или общается с устройством для считывания банковских карт. Лейтмотив тут в том, что нам как аналитикам обязательно нужно понимать внешние объекты, программные и аппаратные, которые необходимы решению для выполнения своих функций, и корректно описывать механизм общения в требованиях.

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

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

Какие есть внешние интерфейсы (с чем решению необходимо взаимодействовать).
Каковы точки взаимодействия с каждым из них (например, все методы API, которые решению необходимо использовать, плюс моменты в функциональных поведенческих требованиях, в которые решение должно обращаться к этим методам).
Как нужно общаться в рамках каждой точки взаимодействия: протоколы, форматы данных, маппинг (соответствие) данных между данными решения и форматом запроса/ответа для сторонней системы, алгоритмы преобразования этих данных в процессе. Часть этой информации может присутствовать в описании механизма взаимодействия, который предоставляет сторонняя система (например, практически все популярные продукты, предоставляющие публичный API, имеют описание этого API в Интернете), поэтому дублировать подобный текст не стоит — лучше сослаться на уже существующее описание.
Как решение должно реагировать на ошибки со стороны внешних систем (например, если получен ответ из API о том, что данные отсутствуют).

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

И снова примеры, но очень вкратце, ибо мы не спецификацию тут пишем:

Вы покупаете себе микроволновку

Микроволновка должна быть оборудована USB-разъемом для подключения к системе диагностики.

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

Система должна регулярно импортировать меню из веб-приложения «Cafe Menu Aggregator».

Система должна осуществлять импорт ежедневно в 8.00 (GMT +3).

Метод API (cм. его описание по этой ссылке): GetDailyMenu

Данные для запроса:

Date = дата на момент вызова

Данные из ответа:

Для каждого Meal в ответе: Name (= Наименование блюда), Price (= Цена блюда), Img (= Фото блюда).

В случае, если код ответа = «152 Menu not found», система должна отобразить на странице «Меню» сообщение «Извините, меню на сегодня недоступно.»

Как прорабатывать:

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

Как по итогу выглядят:

Описанные по чеклисту выше требования в рамках отдельного раздела в документе Software Requirements Specification. Точки взаимодействия с внешними интерфейсами также будут фигурировать в функциональных поведенческих требованиях (в детализациях соответствующих Features или Use cases).
Отдельные странички/набор информации в Confluence или иной системе, где аналитик хранит требования. Также вместо этого можно сразу описать точечные взаимодействия со сторонними системами в виде критериев приемки в рамках тех User Stories, в которых эти взаимодействия будут осуществляться.

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

Последняя категория НФТ — это условная категория «Прочие», куда входят требования, которые по смыслу сложно уложить в упомянутые уже подвиды НФТ. И тут уместно вспомнить, что учитывая многообразие видов решений, направлений для НФТ может быть много. Типовые вещи, которые входят сюда для программных решений, таковы:

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

Вы покупаете себе микроволновку

Микроволновка должна быть красного цвета (код RGB: #E30F47) — требование к цвету устройства

Шнур питания микроволновки должен обладать вилкой стандарта Z — требование к операционной среде

Собственный продукт для массового потребителя: термометры для измерения экстремальных температур

Термометр должен пройти сертификацию Y перед использованием — требование к сертификации

Термометр будет использован в диапазоне температур от -100 до +100 градусов по Цельсию — требование к операционной среде

Термометр должен быть доступен для продажи в магазинах сети «Extreme Tourism» — можно отнести к требованиям к операционной среде, но можно и трактовать, как атрибут качества Installability.

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

Система должна корректно функционировать в следующих браузерах: Google Chrome (последняя актуальная версия), Firefox (последняя актуальная версия) — требование к операционной среде

Система должна быть доступна по следующему URL: https://meals.bestsolutions.net — требование к операционной среде

Интерфейс системы должен быть представлен на русском и английском языках — требование к локализации (обратите внимание, что подобное требование должно «породить» функциональные требования, описывающие то, как переключать язык, плюс быть сопровождено текстами всех UI-элементов для каждого языка)

Визуальный дизайн системы должен соответствовать корпоративному брендбуку (см. его описание тут) — требование к визуальному дизайну

Последняя категория требований, о которой мы еще не вели речь — это переходные требования (Transition Requirements). Многими аналитиками эти требования игнорируются, но происходит это, скорее, по незнанию, чем осознанно. Из имеющихся видов требований это наиболее «несущественные» требования (в сравнении с другими, естественно). Переходные требования — это временные требования. Все остальные требования постоянны, т. е. мы делаем решение, которое в течение всей жизни должно соответствовать всем описанным нами выше требованиям (если они, конечно, не изменятся). Переходные же требования описывают то, что необходимо разово сделать или делать периодически, чтобы успешно внедрить решение в рабочую среду. Т. е. представив, что у нас есть готовое решение, реализованное в ногу со всеми упомянутыми выше видами требований — надо ли что-то дополнительно сделать в моменты внедрения решения в эксплуатацию, чтобы привести его в полноценно рабочий вид?

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

Типовые примеры:

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

Вы покупаете себе микроволновку

Для микроволновки необходимо написать руководство для пользователей и включить его в комплект поставки.

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

Необходимо создать учетные записи для всех сотрудников компании в системе.

Как прорабатывать: изучить типовые примеры подобных требований (например, тут) и обсудить со стейкхолдерами, задавая наводящие вопросы вида «Нужно ли что-то дополнительно сделать в момент внедрения решения в эксплуатацию из разряда…»

Как по итогу выглядят: сформулированные требования в рамках отдельного раздела в документе Vision and Scope или Software Requirements Specification (с прицелом на то, чтобы вы и иные стейкхолдеры не забыли про них в нужные моменты, когда эти действия нужно будет выполнить), либо отдельные странички/набор информации в Confluence или иной системе, где аналитик хранит требования.

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

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

Буду рад любым комментариям, в особенности мнениям о том, где и что, на ваш взгляд, не совсем корректно или недостаточно полно описывает эту часть (ключевую, напомню) работы IT бизнес-аналитика.

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

для самостоятельного изучения теории (Бизнес-анализ (lite))
для того же, но ещё и с ключевой практикой, моей ее проверкой, плюс периодическими консультациями по любым вопросам (Бизнес-анализ (medium))
полноценное удаленное групповое обучение от меня с нуля до огненного начинающего специалиста (Бизнес-анализ (Online)). В таком варианте мы детально изучаем все описанные аспекты требований и активно прорабатываем их на практике.