Виды требований к программному продукту

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

Давайте более подробно рассмотрим, какие бывают виды требований. Мы воспользуемся классификацией, которую предложил Карл Вигерс. Вероятно, вы уже знакомы с этой классификацией. Мы не просто повторим данные Вигерсом определения, а для каждого вида требований я приведу примеры.

Есть такая схема от Вигерса, где он раскладывает все виды требований. Эти названия уже стали своего рода классикой, многие аналитики их применяют в работе. Но иногда всё равно бывает путаница. Поэтому давайте разберем каждый из них по отдельности.

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

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

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

Так в чем же смысл бизнес-требований? Они описывают бизнес-идею, без реализации которой создаваемый продукт не будет нужен потребителю. В бизнес-требованиях мы находим описание всех тех проблем, которые создаваемый продукт должен решать, и возможностей, которые он должен реализовать.

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

Для посетителей сайта это возможность быстро и легко найти самый выгодный по цене маршрут и таким образом сэкономить деньги. Кроме того, сайт помогает сэкономить время на планирование поездки, так как вам не нужно просматривать разные сайты разных авиакомпаний и сравнивать цены. Именно это и делает такие сервисы популярными — они помогают людям экономить время.

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

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

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

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

Часто бизнес-требования путают с бизнес-правилами из-за общего префикса «бизнес» в названии. Что такое бизнес-правило? Это положение, которое определяет или ограничивает определенные аспекты бизнеса. Вместо того чтобы просто перечитать определение Вигерса, давайте сразу перейдем к примерам, чтобы прояснить, что это означает.

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

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

Бизнес-правила также могут быть общепринятыми или стандартными функциями и алгоритмами, которые должны быть реализованы в системе. Простой пример — алгоритм расчета НДС, который также является бизнес-правилом.

Таким образом, бизнес-правила — это требования, установленные в бизнес-практике, законодательстве или отрасли, которым мы обязаны следовать при реализации нашей системы.

Недавно стали актуальны два федеральных закона, касающихся практически всех сайтов, осуществляющих продажи в интернете.

Первый — это закон о персональных данных. Он накладывает требования на сайты, касающиеся хранения и обработки персональных данных клиентов.

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

Это очевидный пример того, как бизнес-правила влияют на требования к веб-сайту. Для реализации этих правил потребуется разработка более детализированных требований, включая определенные интерфейсы, функции и специфическое поведение сайта в различных ситуациях.

Следующий вид требований: пользовательские требования.

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

Многие существующие методы разработки требований относятся именно к этому уровню. Сюда входят такие подходы как Use Cases (варианты использования), User Stories (пользовательские истории), метод «персон» и некоторые другие, менее распространенные методы. Эти методы наиболее глубоко проработаны и концептуально завершены, так как они относятся к уровню взаимодействия людей с продуктом и описывают его видимое поведение.

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

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

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

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

Атрибуты качества — это еще один вид требований, который мы рассмотрим подробнее в этом курсе.

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

Существует понятие «качества программного обеспечения» или «качества программного продукта». Для этого понятия существуют стандарты, своя теория, методы оценки и обеспечения качества. И в основе этого всего лежит множество разных точек зрения на то, как должен работать программный продукт.

Мы обсудим эти точки зрения позже в этом курсе, а пока давайте рассмотрим примеры, которые представляют различные подходы к пониманию качества.

Стоит подчеркнуть, что приведенные здесь примеры — это не атрибуты качества в чистом виде, а требования, которые представляют эти атрибуты качества в контексте создаваемого продукта.

Рассмотрим некоторые из них. Время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества, такие как «производительность» (время загрузки страницы) и «надежность» (способность сайта справляться с определенной нагрузкой). Эти характеристики, очевидно, важны для пользователя продукта.

Другое требование: база данных сайта должна устанавливаться на серверах MySQL, MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Здесь проявляется атрибут качества «переносимость», который подразумевает возможность установки сайта в различные среды без дополнительных модификаций. Этот атрибут качества важен для разработчиков системы, а не для конечных пользователей, которые обычно даже не знают, как СУБД используется в продукте.

И последний пример: сайт должен быть адаптирован для мобильных устройств. Это требование отражает атрибут качества «удобство использования» или «юзабилити», который подчеркивает важность комфорта пользователя при работе с продуктом.

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

Хотел бы отметить, что книга Вигерса, которая была упомянута ранее, пережила уже три издания, и в каждом из них он немного изменял эту схему. Он перемещал отдельные виды требований между разными уровнями и менял их взаимосвязи. Это нормально и отражает тот факт, что все требования тесно связаны друг с другом. Например, раньше бизнес-правила были размещены на втором уровне, а сейчас они были перемещены на уровень бизнес-требований.

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

Наиболее известными нам являются, вероятно, технические ограничения, которые часто фиксируются в техническом задании, исходя из возможностей, которыми обладают заказчик или разработчик.

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

Другой похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

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

Следующий вид требований: внешние интерфейсы. Это описание интерфейса между системой и пользователем, другой системой или оборудованием.

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

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

Вот несколько примеров внешних интерфейсов:

1. API социальных сетей для автоматического репоста публикаций с сайта на страничку компании в Facebook. Таким образом, нет необходимости вручную копировать новости, специальное приложение сделает это автоматически.

2. Спецификация взаимодействия с платежным агрегатором для обработки онлайн-платежей на сайте интернет-магазина. Это описание внешнего интерфейса представляет собой определенную спецификацию передачи данных.

3. Протоколы взаимодействия с серверами транспортных компаний для резервирования и оплаты билетов. Например, единый сервис для сравнения и покупки авиабилетов разных авиакомпаний требует наличия внешних интерфейсов для взаимодействия с различными сервисами резервирования и оплаты билетов.

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

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

Однако, в практике многих компаний термин «системные требования» часто применяется для обозначения требований третьего уровня. Большинство специалистов понимают, что такое бизнес-требования и пользовательские требования. Но когда речь идет о третьем уровне, мнения расходятся. Я предпочитаю использовать термин «требования к реализации», Вигерс же предлагает «функциональные требования». В то же время, некоторые компании используют для этого уровня термин «системные требования».

В контексте терминологии Вигерса, системные требования можно проиллюстрировать на следующем примере. Допустим, у нас есть интернет-банк, и требуется, чтобы доступ к операциям со счетом осуществлялся через единый сервер приложений. С этим сервером могут взаимодействовать различные клиентские приложения: интернет-банк в браузере пользователя, мобильное приложение или отдельное Java-приложение на компьютере пользователя. Это требование описывает систему в целом, и дает нам понимание, что есть несколько вариантов клиентской части приложения, но все они должны работать с единым сервером.

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

Вигерс определяет функциональные требования как «описание функциональности, которую следует реализовать в разрабатываемой системе, чтобы пользователь мог выполнить свои задачи в рамках бизнес-требований». Такое определение помогает лучше понять, почему в данном контексте используется слово «функциональные».

Вот примеры функциональных требований.

1. На сайте должен быть реализован поиск статей по ключевым словам и по проставляемым тегам. Это требование описывает необходимую функцию «поиск» на сайте.

2. Операции оплаты со счета должны быть доступны только с использованием двухфакторной авторизации. Это функциональное требование ограничивает возможные методы работы с счетом в интернет-банке.

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

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

Предыдущий урок: Уровни требований к программному продукту

Следующий урок: Функциональная и нефункциональная стороны программного продукта