2024-11-21 19:50

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

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

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

Продолжение примера для функциональных требований:

Типовая ошибка: основная ошибка, которую тут можно сделать и которая не только не особо критична, но и является ошибкой лишь в контексте аналитика-пуриста, работающего по типовому усредненному подходу (т. е. это может вовсе и не быть ошибкой для аналитика, у которого в силу обязанностей смещены дефолтные грани работы) — это переступить грань между данным уровнем требований и следующим. Но следующего же нет, заметите вы. И будете правы, а потому мы будем говорить о границе между требованиями и деталями реализации (design specifics). Я уже ссылался на статью, в которой это подробно описано, но если вкратце: на базе требований эксперты из команды разработки будут реализовывать решение. Как понять, что требования закончены и дальнейшее уже — это их стезя и их область знаний? Если упрощенно, то как только вы лезете в ту область, для которой в команде разработки есть свой эксперт, вы сдвигаетесь из области требований в область деталей решения (за которые этот эксперт отвечает).

Пара примеров, которые в определенном контексте являются анти-примерами:

Если в команде есть UX-специалист или проектировщик User Interface (UI), то требование следующего вида будет неверным:
1.1. Когда пользователь открывает систему, система должна отобразить страницу «Вход», где пользователю необходимо ввести логин и пароль для входа в систему под своей учетной записью.
Почему неверным? Вы как аналитик оперируете в нем «страницами» и «вводом», а за концепцию UI и механизма взаимодействия пользователя с решением отвечаете не вы. Дав такое требование на вход упомянутому человеку, вы ограничите его в подборе решений. Более корректный вариант в таком случае — абстрагироваться от привязки к UI в требованиях и формулировать нечто в таком духе:
1.1. Когда пользователь открывает систему, система должна предоставить пользователю возможность указать логин и пароль для входа в систему под своей учетной записью.

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

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

Взять набор User Stories или Use Cases из предыдущего этапа (т. е. то, что пользователи должны иметь возможность сделать в решении) и сформировать на их базе функциональные возможности решения (Features). Это не обязательный этап — многие аналитики прекрасно обходятся и с исходными User Stories/Use Cases в качестве «единичек, на которые распилено решение» и по которым они будут группировать детальные поведенческие требования.
Наполнить User Stories/Use Cases/Features детальным описанием поведения решения: его реакциями на действия пользователей или иные события (например, автоматические действия системы по таймеру), не забыв учесть все возможные негативные сценарии (детальнее об этом тут и тут).

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

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

Для информационных систем есть еще один подвид функциональных требований — требования к данным (Data Requirements). Информационные системы работают с информацией (спасибо, капитан!), т. е. большинство функций таких систем оперируют какими-то данными. Без описания этих данных сложно всесторонне описать саму функцию. Большинство фич программной системы — это так или иначе работа с информацией: ее просмотр, создание, редактирование или удаление (CRUD(L) — Create, Read, Update, Delete, List — одна из наиболее полезных техник в арсенале аналитика). Требования к данным суммируют то, какой информацией решение оперирует, а также описывают ее детали: тип, формат, обязательность и пр.

Покажем на упрощенных примерах, что такое требования к данным:

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

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

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

Данные:
1. Замер температуры
1.1. Дата замера (обязательный параметр, формат: DD/MM/YYYY)
1.2. Температура (обязательный параметр, формат: в градусах по шкале Цельсия, диапазон значений: от -100 до +100)

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

Данные:
1. Учетная запись пользователя
…
2. Меню на день
…
3. Блюдо из меню
…
4. Заказ
4.1. Автор заказа (обязательный параметр, ссылка на учетную запись).
4.2. Дата заказа (обязательный параметр, формат: DD/MM/YYYY).
4.3. Набор блюд в заказе (обязательный параметр, массив ссылок на блюда из меню).
4.4. Количество порций для каждого блюда (обязательный параметр, массив целых положительных чисел).
4.5. Итоговая стоимость (обязательный параметр, дробное положительное число с двумя знаками после запятой).

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

Нарисовать контекстную диаграмму для решения (Context Diagram), показывающую обмен данными между решением и его пользователями и внешними системами. Взять из нее куски информации, которые «летают» между системой и внешними участниками.
Дополнительно: проанализировать и выудить из функциональных возможностей решения и детализации их поведения куски информации, которыми решение оперирует.
Сформировать на базе всей этой информации классы/сущности (entities) данных и их атрибуты. Описать для каждого атрибута важные для команды разработки параметры: обязательность, тип, формат и т. п.

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

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

Теперь, полностью описав функции и поведение решения, нас ждет «увлекательный» мир его дополнительных аспектов — нефункциональные требования (Non-Functional Requirements). Аналитики не любят эти требования — они не настолько просты в проработке, как функции и поведение решения, в особенности, когда дело касается их качественной формулировки. Тем не менее, упускать их опасно, а потому обсудим.

Нефункциональные требования (НФТ) — это свойства/характеристики решения, в рамках которых решение должно функционировать. Т. е., грубо говоря, каким решение должно быть (в отличие от того, что оно должно уметь и как должно себя вести в соответствии с функциональными требованиями). Виды нефункциональных требований могут варьироваться в зависимости от типа решения — например, для каких-то устройств актуальными могут быть такие (не особо применимые для ПО) категории, как материал, из которого оно изготовлено, форма и т. п. В то же время для некоторых видов ПО будут актуальными такие моменты, как целостность данных (Data Integrity) или легкость установки (Installability), что не будет иметь смысла для других видов решений. Ряд моментов, при этом, может быть общим: безопасность использования, удобство использования и пр. И так как мы сфокусировались на требованиях к ПО как IT-аналитики, схему НФТ для ПО мы и рассмотрим.

Первый подвид НФТ — атрибуты качества (Quality Attributes). Атрибуты качества описывают качественные характеристики решения. Грубо говоря, это то, насколько хорошо (что бы это ни значило в разных преломлениях для различных стейкхолдеров) система должна функционировать. Эти параметры могут оказывать весомое влияние на то, насколько удачно решение позволит пользователям и иным стейкхолдерам выполнять те или иные задачи касательно решения. Например, отображение меню с блюдами может занимать 10 секунд, а может — пять минут, если производительность системы в силу тех или иных причин низка.

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

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

Внешние атрибуты качества:

Удобство использования (Usability) — то, насколько решение должно быть дружелюбным к пользователю, удобным для использования.
Производительность (Performance) — то, насколько быстро или в каком объеме решение выполняет свои функции.
Доступность (Availability) / Надежность (Reliability) — то, насколько решение обязано быть доступным или недоступным для использования (временные интервалы, время простоя и т. п.), а также степень его надежности.
Безопасность (компьютерная) (Security) — насколько решение безопасно в контексте предотвращения утечек информации и несанкционированного доступа.
Легкость установки (Installability) — насколько решение легко в плане приведения в рабочий вид.
Безопасность (для здоровья/имущества) (Safety) — то, насколько решение безопасно для здоровья или имущества пользователей.

Внутренние атрибуты качества:

Эффективность (Efficiency) — не для всех решений это будет внешним атрибутом качества, т. к. зачастую является важным именно для конечных пользователей, но в целом это о том, насколько решение эффективно потребляет ресурсы, необходимые ему для работы.
Переносимость (Portability) — аналогично предыдущему внутренним является не всегда; то, насколько систему легко перенести в иное операционное окружение (среду, в которой система должна функционировать).
Степень повторного использования (Reusability) — то, с какой степенью компоненты решения можно использовать для разработки иных решений.
Масштабируемость (Scalability) — насколько решение легко адаптировать к росту нагрузок.
Изменяемость (Modifiability) — насколько легко внести изменения в функции или иные аспекты решения.
Проверяемость (Verifiability) — насколько легко проверить, что решение работает так, как нужно.

Давайте попробуем сформулировать примеры на каждый вид:

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

Usability: Ручка микроволновки должна позволять ухватиться за нее всей рукой полностью (хорошо бы сюда еще размеры руки добавить, ага).
Performance: Микроволновка должна вмещать емкость не менее 30 см. в диаметре и не менее 20 см. высотой. Микроволновка должна нагреть блюдо весом X до температуры Y на мощности Z.
Availability/Reliability: Микроволновка должна выдерживать до 1 часа непрерывного разогревания на максимальной мощности.
Security: -
Installability: Упаковка микроволновки должна позволять распаковать ее голыми руками, без применения иных средств.
Safety: Ручка микроволновки не должна обжигать руки при любой мощности и длительности разогрева.
Efficiency: Микроволновка должна потреблять не более X электроэнергии в Y единицу времени в рабочем состоянии на максимальной мощности.
Portability: -
Reusability (для производителя): Ручка микроволновки должна соответствовать стандарту X, чтобы мы могли одни и те же ручки производить для всей нашей линейки микроволновок.
Scalability: -
Modifiability (хотя более корректно было бы обозвать Maintainability): Нагревательный элемент микроволновки должен соответствовать стандарту Z для облегчения сервисного обслуживания.
Verifiability: -

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

Usability: Термометр должен иметь кнопку запуска измерения размером 4*4 см., чтобы пользователи могли пользоваться ей в защитных перчатках.
Performance: Термометр должен выводить на дисплей температуру не позднее 3 сек. с точки инициации измерения.
Availability/Reliability: Термометр должен сохранять работоспособность в диапазоне температур окружающей среды от -100 до +100 градусов по Цельсию.
Security: -
Installability: -
Safety: -
Efficiency: Термометр должен потреблять не более 1% батареи за одно измерение температуры.
Portability: Термометр должен быть оборудован шнуром для переноски.
Reusability: -
Scalability: Термометр должен поддерживать батареи различной емкости (стандартов X, Y и Z)
Modifiability: -
Verifiability: -

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

Usability: Пользователь должен иметь возможность открыть меню за не более, чем 3 действия, с момента открытия стартовой страницы системы.
Performance: Время загрузки страниц не должно превышать 2-х секунд при пропускной способности локальной сети >= 100 Mbps.
Availability/Reliability: Система должна быть доступна 100% времени с 12 до 14 по рабочим дням.
Security: Система должна позволять просматривать созданные заказы только их авторам и пользователям с ролью «Отдел учета зарплаты».
Installability: -
Safety: Блюда, представленные в системе, должны иметь маркировку потенциальных аллергический реакций.
Efficiency: Данные системы должны занимать не более 1 Гб памяти на жестком диске сервера.
Portability: -
Reusability: Модуль аутентификации должен быть компонентом, пригодным для использования в будущих корпоративных веб-приложениях заказчика.
Scalability: Хостинг системы должен позволять увеличить количество одновременных пользователей до 300 без необходимости его смены или апгрейда.
Modifiability: Внесение изменений в цены блюд со стороны команды разработки должно быть возможным без остановки работы системы.
Verifiability: В системе должна быть скрытая для обычных пользователей возможность тестирования корректности отображения на различных устройствах.

Типовая ошибка: Как и с функциональными требованиями (и в той же степени (не)критичности), лучше абстрагироваться от реализации («как») и оставлять на переднем плане ценность требования для стейкхолдеров («что»). Это весьма размытая грань, но во всех анти-примерах ниже логика в том, что компетентно решат, верное ли очерчено решение внутри требования, эксперты из команды разработки, а не аналитик (если это выходит за рамки его зон ответственности).
Страница «Меню» должна быть доступна как пункт меню системы первого уровня.
Загрузка JS-скриптов не должна превышать 1,5 секунд при пропускной способности локальной сети >= 100 Mbps, а размер изображений не должен превышать 1 Mb в формате PNG.
При разработке системы необходимо использовать убермегаязык ProgrammingScript2.0, позволяющий обеспечить максимальную безопасность в контексте неавторизованного доступа к страницам.
Цены блюд должны храниться в XML-файлах, подхватываемых на лету без необходимости пересборки кода.

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

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

Как по итогу выглядят:
Если мы работаем «по документам» (Software Requirements Specification, Техническое Задание и т. п.), то атрибуты качества — это отдельный раздел в документе, где эти требования перечислены и сгруппированы по типам.
Если мы работаем в контексте бэклога и User Stories, есть несколько вариантов:

Те атрибуты качества, которые можно отнести к одной или нескольким User Stories (т. е. они актуальны только лишь для конкретных единиц функциональности) — выносим в критерии приемки (совокупность требований к решению) для этих User Stories.
Если это отдельная работа, которую можно выполнить за относительно небольшой срок, вполне можно оформить такие атрибуты качества как самостоятельные User Stories.
Если не уверены в том, как лучше оформить, то как минимум это отдельный список требований на страничке/набор информации в Confluence или иной системе, где аналитик хранит требования. А уже то, как создать задачи (элементы бэклога) на базе этих требований, подскажет команда.

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

Следующий вид НФТ — ограничения реализации (Design Constraints). Т. к. это весьма своеобразные требования, для того, чтобы их полноценно понять, мозг должен щелкнуть определенным образом, поэтому более детальное описание можно найти тут. Тем не менее, если вкратце:

Когда внешние стейкхолдеры (т. е. не на стороне исполнителя — заказчик, пользователи, государство и пр.) либо какие-то внешние обстоятельства (бизнес-правила, требования от внешних программных решений) диктуют что-то из области реализации решения (design specifics — да-да, из той самой области, которую мы помечали как то, куда аналитику лезть не надо), это стоит считать требованием и называть ограничением реализации (ограничением, которое внешние обстоятельства вне зоны контроля нашей команды налагают на выборы команды). Мы вели речь о том, что детали реализации — это то, что в области креатива у команды: у них есть свобода действий принимать решения самостоятельно на базе требований от аналитика — это UI (при наличии в команде разработки дизайнера), архитектура решения, технологический стек, структура базы данных и прочие детали того, как разрабатывать решение по требованиям от аналитика. Тем не менее, в ряде случаев (которые для исполнителя нежелательны, т. к. любое ограничение в свободе едва ли в плюс) в эту зону свободы могут влезать внешние обстоятельства и диктовать команде, как и что делать. Например, заказчик говорит, что ему нужна база данных, основанная на SQL, т. к. на их стороне с ней непосредственно будет работать его специалист. И вот нам как аналитикам стоит иметь в виду, что существует такой особый вид требований, и зафиксировать их, чтобы передать вместе с другими «инструкциями извне» команде разработки.

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

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

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

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

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

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

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

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

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

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

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

Продолжение — в третьей части.